IRC logs for #baserock for Wednesday, 2015-02-11

*** zoli__ has quit IRC00:36
*** zoli__ has joined #baserock00:45
*** zoli__ has quit IRC01:31
*** zoli__ has joined #baserock01:53
*** zoli__ has quit IRC02:46
*** zoli__ has joined #baserock03:35
*** zoli__ has quit IRC05:03
*** zoli__ has joined #baserock05:24
*** sherm_ has joined #baserock07:09
jjardonred in http://mason-x86-64.baserock.org/ ! disk full again?07:13
jjardoneven coreutils is a foundation dependency, morph still uses the busybox "diff" when compiling stuff, any idea how to fix this?08:18
*** grahamfinney_ has joined #baserock08:20
*** grahamfinney__ has joined #baserock08:20
*** grahamfinney_ has quit IRC08:21
paulsherwoodjjardon: migrate to toybox?08:32
jjardonpaulsherwood: we can, but the problem here is why the coreutils diff is not being used08:33
paulsherwoodah, ok08:34
pedroalvarezHm.. Is coreutils diff being installed in the same path as busybox diff?08:34
jjardonsame with sed08:39
franredjjardon, does coreutils diff overwrite busybox diff?08:42
jjardonId expect that, but seems that no08:43
jjardonoh wait, maybe sed and diff are not part of coreutils?08:43
*** mariaderidder has joined #baserock08:44
franredjjardon, coreutils adds the binaries to /usr/bin when busybox adds it in /bin08:44
pedroalvarezjjardon: true, diff has its own chunk iirc08:45
paulsherwoodwhy are you proposing to add linux-stable now?08:48
paulsherwoodjjardon: ^^08:48
jjardonpaulsherwood: linux-stable have the different linux branches08:49
jjardonsomeone can be interested on follow a specific branch08:49
jjardonfranred: pedroalvarez and sed its in a different repo as well08:50
franredjjardon, ok, in any case check whether both binaries are installed and if your system has both08:52
jjardonfranred: they are not, we do not build sed or diff in any of the baserock strata08:53
* pedroalvarez doesn't understand "linux branches" in this context 08:54
jjardonpedroalvarez: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?h=linux-3.18.y08:57
paulsherwoodjjardon: if we had one or more reference systems using branches from there it might make sense. but given we don't, i'm not sure why to add it08:57
*** mdunford has joined #baserock08:57
jjardonpaulsherwood: "official" baserock dont, some people maybe want to use them (like me)08:58
paulsherwood:)08:59
*** grahamfinney__ has quit IRC09:00
jjardonargh, now I need a Python3 interpreter...09:00
jjardonIs someone working on that?09:00
*** gfinney has joined #baserock09:00
*** 7YUAABE5Y has joined #baserock09:00
paulsherwoodi had it working, but it appeared i was alone in wanting it so i didn't push it anywhere09:01
7YUAABE5Yperhaps I should change it to Albert. That was my nickname at uni09:01
7YUAABE5YAhh what's happened ?09:01
7YUAABE5YOpps wrong channel09:02
paulsherwood:)09:03
*** bashrc has joined #baserock09:04
jjardonpaulsherwood: maybe its time to push it then? ;)09:05
jjardonlets have a python3 strata to make the split easier?09:06
*** rdale has joined #baserock09:07
paulsherwoodyup. i can't get to this now, though.09:10
jjardonsure09:11
* jjardon will build a older version of GNOME Shell in the meantime09:12
jjardonpaulsherwood: mind if I assign you this task in the storyboard story? n(only to keep track of things)09:13
paulsherwoodme and my big mouth09:15
paulsherwoodok09:15
jjardonpaulsherwood: :) done!09:18
*** gary_perkins has joined #baserock09:18
jjardonI think makes sense to add diff and sed in the coreutils-common stratum, any objections?09:19
franredjjardon, +1 just be careful where the binaries landed09:21
jjardonactually, can I lorry sed first? http://paste.baserock.org/vizinocuzo09:21
franredjjardon, that looks ok to me09:22
*** jonathanmaw has joined #baserock09:24
pedroalvarezjjardon: +109:34
jjardonfranred: pedroalvarez thanks!09:34
*** ssam2 has joined #baserock09:36
*** ChanServ sets mode: +v ssam209:36
*** edcragg has joined #baserock09:46
*** gfinney has quit IRC09:48
SotKhas anyone managed to build pygobject in Baserock?09:52
*** zoli__ has quit IRC09:53
*** zoli__ has joined #baserock09:53
SotKheh, I'd guess so given its in the virtualization stratum :)09:54
pedroalvarezSotK: if it's there then yes :)09:55
franredSotK, if it is in virtualization.morph, the openstack branch is building it everytime09:57
ssam2i've removed cached system artifacts from cache.baserock.org again, it was full, now there is 22.1GB10:01
ssam2we really need to get automated cleanups of that system working soon10:01
*** zoli__ has quit IRC10:02
pedroalvarezssam2: indeed10:03
pedroalvarezalso in mason/distbuild10:03
*** zoli__ has joined #baserock10:06
*** zoli__ has quit IRC10:14
paulsherwoodssam2: i've asked before... isn't that just morph gc by default?10:14
* SotK discovers gnome-common is in two strata10:16
*** zoli__ has joined #baserock10:17
ssam2paulsherwood: I don't think so. Morph is a build tool, cache.baserock.org is a cache10:21
ssam2I don't think the 'morph gc' behaviour will also work for a shared remote cache10:22
ssam2that said, it would work well enough and I did implement a hack to clean up troves using morph gc. But it seemed to trigger bugs in distbuild, if I recall correctly10:22
* paulsherwood is surprised10:24
paulsherwood:)10:24
robtaylorassumptions in the distbuild code iirc10:28
pedroalvarezyeah, it assumes things like "if this stratum artifact is present in the cache server, then all its dependencies are"10:35
pedroalvarezo something similar10:35
straycatSotK, we need to add pylru before we merge your branch?10:37
jjardonSotK: we can remove soon gnome-common from gtk-deps, it will not needed anymore in the next atk release10:37
SotKstraycat: I was planning to send a patch for that before I update the ref in definitions so I could do that at the same time. I can make it and send it now if you'd prefer though :)10:39
straycatOh okay either's fine I think10:40
pedroalvarezthis lorry needs fixing: http://paste.baserock.org/ayojiwazil10:40
pedroalvareztiagogomes_: you may be interested on it ^10:40
persiaI worry about cache cleaning.  We should probably establish some guidelines on what we expect to be able to build from cache.  It ought be more than just master.10:41
jjardonIs there a way to telling morph to show me all the compilation output?10:41
pedroalvarezpersia: master and releases?10:41
pedroalvarez"releases" > definitions tags10:41
persiaThat seems a sensible start.10:41
straycatjjardon, --build-log-on-stdout or the logs in the artifact cache10:41
persiaI'd like more cache, because I imagine people doing more interesting things, but it might just be me.10:42
radiofreei didn't know about --build-log-on-stdout!10:42
persiaMaybe some LRU algorithm that ensures that master and definitions tags remain cached?10:42
tiagogomes_pedroalvarez that kexec-tools repo will not work for aarch64 I'm afraid10:42
franredpedroalvarez, +1 to that lorry10:42
*** dabukalam has joined #baserock10:43
ssam2persia: yes, using `morph list-artifacts` it'd possible to write a cleanup algorithm that didn't delete artifacts that were needed for tags or for master10:43
jjardonpedroalvarez: +110:43
pedroalvarezjjardon, franred: thanks guys10:43
persiassam2: Would it also be possible to do some LRU ejection (perhaps based on atime), so that we have as many cached objects as possible at any given time?10:44
jjardonstraycat: thanks!!10:45
pedroalvareztiagogomes_: ah, ok, I was expecting that the latest release from 2 days ago would work10:46
persiaHrm?  Why doesn't the latest release work?10:48
pedroalvarezs/would work/would work on aarch64/10:49
SotKjjardon: where would you put it, since I don't really think it belongs in virtualization either?10:49
jjardonSotK: Its only a bunch of autoconf macros, so maybe core?10:51
paulsherwoodSotK: aren't you already making major improvements to caching? i think i saw pylru in one of your series?10:51
jjardonSotK: there are plans to completely deprecate it, so it wil  go away eventually10:51
tiagogomes_persia kexec-tools is arch dependent. aarch64 is not supported10:51
pedroalvarezOne day I thought about the possibility of having 2 different locations for cache artifacts in a cache servers. One for some artifacts that have to be more presistent, and other for some that can be erased. Being the former for artifacts of releases.10:52
pedroalvarezwould that make sense?10:52
persiapedroalvarez: I think that as long as we have a cache-server config option, that would be confusing for users.10:52
paulsherwoodnot to me10:52
* persia still wants the cache config to default to cache.baserock.org10:52
paulsherwoodie not making sense to me10:52
paulsherwood+1 to cache.baserock.org10:53
SotKpaulsherwood: the pylru series is for speeding up the construction of the build graph by caching as many of the things it looks at trove for as possible (specifically tree SHAs and auto-detected build systems)10:53
pedroalvarezif we want to put cache artifacts in cache.baserock.org too, then we need to think a bit more about this first10:53
pedroalvarezs/cache artifacts/release cache artifacts/10:54
persiaI think more thought would be good.10:54
persiaAt a high level, I want to have a cache server which contains stuff that is useful to me.10:55
paulsherwoodi think it's just one cache, where some artifacts persist (because released, or continuing to be used)10:55
persiaSo I can branch from a release, and use that efficiently, or I can follow master, and use that efficiently.10:55
persiaI'm probably being selfish about this, but expect that most other users have the same class of selfish wants.10:55
pedroalvarezAh, btw, when I said "2 different locations" I meant 2 different folders on the same cache server, being this one cache.baserock.org10:56
pedroalvarezso we can do clean-ups of artifacts without caring about removing release artifacts10:56
mauricemoss_Morning, does anyone have experience in altering gcc/config.gcc when building gcc?10:58
ssam2persia: definitely, it makes sense to cache as much as we can10:59
jmacsA long time ago; I've probably forgotten it all now10:59
mauricemoss_jmacs, right now we have to hardcode the default ABI=64 in a gcc header file when building glibc for mips64 otherwise the build fails. `gcc -v` prints: http://paste.baserock.org/xeyisoxoza I've tried this change: http://paste.baserock.org/ufuhoyokoy as well as this change http://paste.baserock.org/ladoqecipi (together `--with-abi=64`), but gcc ignores the changes.11:01
jmacsTaking a look now11:04
*** sambishop has joined #baserock11:07
jmacsmauricemoss_: That patch doesn't look like it would apply to the latest gcc master - what's it based on?11:13
rdaleis ld.so built as part of glibc?11:15
jmacsGuessing whatever's in g.b.o. for now11:15
mauricemoss_it's based on gcc 4.9.2, commit b3c9b176c1f10ebeff5700eb3760e9511f23fa0611:17
jmacsUnfortunately, I can't remember how the pattern matching works in config.gcc and it's not documented. My best guess would be that it's matching the subsequent mips64*-*-linux* rule instead of yours11:18
jmacsAnyone else have any ideas?11:18
ssam2it's just a huge shell script, right? so, it'll pattern match in exactly the same way as any other shell 'case' statement11:19
ssam2shell is nightmarish to debug, but it is documented11:20
mauricemoss_jmacs I tried building only with `mips64*-*-linux-*64` which should match `mips64-bootstrap-linux-gnuabi64`11:20
mauricemoss_I don't know were ld.so is being built11:20
ssam2why not add some 'echo "matched rule at line xxx" > /tmp/debug.1' statements to see if your patterns are actually being matched or not?11:21
mauricemoss_ssam2, that's a good idea :)11:21
rdalemauricemoss_: i'm trying to replace glibc with musl and i'm getting a config problem with ld.so, and so i'm wondering if musl hasn't built it properly11:21
*** zoli__ has quit IRC11:24
tiagogomes_why are we always changing libc implementations?11:31
persiaLots of people like different libcs?11:32
persiaPersonally, I think we should have several build-essential definitions, for a wide variety of libcs, so that folk can select different stacks when they build systems.11:32
pedroalvarezAnother lorry that needs fixing: http://paste.baserock.org/qozevusili11:37
franredpedroalvarez, is that a mirror of the openstack one or in the other way around?11:37
pedroalvarezI think both repos were from openstack, but they have moved it11:38
pedroalvarezfranred: ^11:38
franredpedroalvarez, aham, +1 to the fix11:39
*** paulw has joined #baserock11:40
pedroalvarezthanks franred, any other?11:41
persia+111:42
persiaNote that we should expect a lot of these in the future, as more projects complete incubation11:42
pedroalvarezpersia: thanks! merged11:50
jjardonhelp2man build system is a bit "special", seems noone in the world uses git to bootstrap it apart the author11:50
radiofreeafter doing a baserock-system-config-sync merge, i want to check the merged fstab has the correct UUID11:50
radiofreeif i make a change to that /etc/fstab, should i backup the original?11:51
radiofreeeven though it's incorrect and won't work?11:51
ssam2no, it's available in the old subvolume anyway12:01
pedroalvarezI think I understand what are you trying to achieve. Is this to support upgrades with a rawimage?12:01
radiofreeyes12:01
radiofreethat works, i just need to do the fstab checking in baseorkc-system-config-sync now12:01
pedroalvarezradiofree: is not the best thing to do to keep the original fstab? (fstab pre-upgrade)12:02
radiofreebasically, after the merge, check the fstab UUID for "/", if that's not what blkid says, change it12:02
radiofreepedroalvarez: wouldn't the merge take care of that (keep any user changes?)12:03
radiofreei just want to change the UUID for / (and anything else that matches it), if they've added another HD or something i won't touch that12:03
radiofreemaybe a new state directory has been added in the new image or something?12:04
pedroalvarezradiofree: hm.. fair enough12:04
radiofreebut probably if that is the case, the upgrade wouldn't work anyway?12:05
pedroalvarezhehe12:05
pedroalvarezI wonder how a normal upgrade works.12:05
radiofreei'm just thinking that maybe someone might deploy a weird fstab that also mounts / to /foo as well12:05
pedroalvarezregarding fstab and UUIDs12:05
radiofreein which case you'd probably want to merge that, then update the UUID, rather than prefer the old fstab12:06
radiofreepedroalvarez: morph generates a fstab using the UUID of the system you're upgrading to12:06
radiofreeit assumes there's not going to be any /etc/fstab in the thing you're deploying12:06
pedroalvarezyeah, I think i did that patch12:06
pedroalvarezradiofree: could be possible to change the fstab's UUID before calling baserock-system-config-sync?12:08
radiofreei can, and i did, ssam2 suggested i do it in baserock-system-config-sync though12:09
pedroalvarez:) ok12:09
ssam2the problem was that it was being done in a specific write extension, which isn't the right place to be merging system configuration stuff12:20
ssam2we'd have to duplicate the code in each new write extension that did upgrades12:21
ssam2it could go in system-version-manager instead of baserock-system-config-sync if that's easier, I guess12:21
pedroalvarezyeah, I thought that was the plan12:22
pedroalvarezso you can do something like `system-version-manager deploy --rawdisk /path/to/new/disk.img12:22
pedroalvarez`12:22
pedroalvarezand IMO it's going to be way easier than playing with baserock-system-config-sync12:23
paulsherwood+1. but couldn't it check the format, so no need for --rawdisk?12:24
pedroalvarezyeah, that should be possible12:26
jmalkOOI, is this section of the quick start guide finished? - http://wiki.baserock.org/quick-start/#index7h2 - it ends with "Now use the following cluster morphology..." but doesn't say what you're using it for?12:33
straycatdoes seem unfinished doesn't it12:34
jmalkhistory suggests the section was moved from vm-setup to quick-start, so maybe it made more sense in its previous context12:35
*** JPohlmann has quit IRC13:02
jjardonpaulsherwood: seems you actually committed the python3 stuff: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/ps/add-python313:07
* jjardon testing13:07
*** JPohlmann has joined #baserock13:10
*** JPohlmann has joined #baserock13:10
rjekhi JPohlmann13:12
radiofreepedroalvarez: so that's approval to modify the fstab from the rawdisk image inside system-version-manager then?13:50
radiofreegbo been a little slow for anyone else recently?13:56
rjekjjardon: Isn't that version of sed GPLv3?14:01
jjardonrjek: yes, probably14:02
rjekThat's a no-go then, isn't it?14:02
* persia is increasingly of the opinion that we need build-essential-gplv2 and build-essential-gplv314:03
rjeksed will probably end up in built images and lots of things depend on it at runtime14:03
persiaAnd probably different build systems as well14:03
jjardonDoesn't matter because you can choose to include that stratum or not14:03
persia(with correspondingly many distbuilds, etc.)14:03
jjardonThat was the point of putting coreutils in a different stratum14:03
jjardonpersia: that's a no-go; you would duplicate all the strata definitions14:04
* paulsherwood repeats the suggestion of switching to toybox. 14:05
persiaI seem to remember prior discussion on the topic suggesting to just fork definitions to resolve this.14:06
persiaHave a definitions that didn't permit GPLv3 and one that did, and be done with the mess.14:06
paulsherwoodmakes sense, i think14:06
persiapaulsherwood: Even toybox isn't as feature-filled as coreutils, and there are several things higher in the stack (under GPLv3) that really require GNU coreutils.14:06
*** a1exhughe5 has joined #baserock14:06
paulsherwoodyes, fair enough14:07
persiaI think the idea fell down because none of the folk supporting GENIVI wanted to have a separate repo, and most of the GPLv2 stuff is for the GENIVI images.14:07
franredjjardon, have you checked if sed end up in /bin/sed? or in /usr/bin/sed?14:07
persiaAlso, it might make Mason more complex in some way, and we'd want Mason running against both.14:07
radiofreefranred: isn't /usr/bin in $PATH first?14:08
jjardonfranred: no, but it works14:08
franredI told you because in my openstack system I have sed in /bin/sed14:08
franredradiofree, I think the most of the busybox binaries end up in /bin14:09
radiofreeother than it being wasteful, it shouldn't really matter though?14:09
radiofreemy $PATH is /usr/bin:/bin:/usr/sbin:/sbin14:10
franredradiofree, it matters depends on which one your PATH takes first14:10
jjardonthat reminds me we should kill /bin14:10
* radiofree doesn't know what the default PATH is for morph14:10
radiofree..builds14:10
franredradiofree, mine is /sbin:/bin:/usr/sbin:/usr/bin14:10
jjardonand /sbin as well14:11
franredso jjardon, in systems with both sed busybox is still the one in use14:11
jjardonpersia: what do you mean by "just fork definitions to resolve this" .  HAve 2 different branches of definitions?14:12
radiofreethat was discussed before, having a genivi branch for definitions14:12
jjardonfranred: let me recheck14:12
jjardonsi what happen if someone want to build a product that doesnt have any GPLv3 inside? we directly dont support that?14:13
radiofreejjardon: wouldn't that be up to them?14:13
persiajjardon: Yes, two branches of definitions.  Folk wanting non-GPLv3 would use the non-GPLv3 branch.14:14
jjardonradiofree: yes, but there will no way to build such a system with baserock, other than using a probably very outdated genivi branch of definitions14:14
persiaAnd we can move the GPLv3-OK branch to all the latest things and use more modern tooling (as well as more up-to-date implementations)14:14
jjardonpersia: so the non-GPLv3 will bit rot?14:15
radiofreejjardon: ah i see what you mean14:15
persiajjardon: Why is it hard to build?  If we have two up-to-date branches, should we not expect it to just work?14:15
persiaI presume that if the folk who need non-GPLv3 really need it, they would keep it from bitrotting.14:16
persiaBut the split should only happen if there are enough people willing to maintain both branches.14:16
jjardonIMHO they are not14:17
persiaI believe there are enough folk willing to maintain a GPLv3 branch.14:17
persiaI have yet to see evidence there are enough willing to maintain a non-GPLv3 branch14:17
persiaBut I only advocate branching *if* there is a sufficient volunteer population.14:18
jjardonwe can barelly mantain one, dont think is realistic think about 214:18
persiaI refuse to ban behaviour because of past lack of effort.  That said, as much as I think branching is the right solution, I would only support branching if there were volunteers.14:19
jjardonmmm, but maybe its the only option: we _have_ to upgrade to new versions of a lot of GNU libraries to support new architectures14:19
persiaAnd in such a case, I'd expect to make a fuss at them to keep up :)14:19
persiaIs there anyone around today that needs non-GPLv3 who could represent that opinion?14:20
franredI imagine that if we need to build genivi baselines with non-GPLv3 software we will have to maintain then non-GPLv3 branch14:22
franrednot sure if in this case stripping the GPLv3 parts will make the build non-GPLv3, toughs?14:23
persiastripping is fraught with difficulties, mostly surrounding provenance.14:24
persiagcc has a special exception, but some other tools are less explicit, and I'm not sure it's been tested.14:24
persiaFor example, if a component uses sed as part of build, and it is built with GPLv3 sed (even if the actual requirement is fulfilled by busybox), is the resulting binary safe to redistribute under terms that explicitly exclude GPLv3?14:25
* persia suspects the answer to that question to be very expensive14:25
bwhIt's as expensive as you want it to be14:26
bwhI would think sed is a standard tool and irrelevant to the licence14:27
pedroalvarezradiofree: yeah, modify fstab in system-version-manager before using baserock-system-config-sync makes sense to me14:28
* radiofree reverts his changes to system-version-manager14:28
bwhBy the way there was an interesting talk about Samba and the benefits of GPLv3 at FOSDEM14:28
radiofreeok, let me test this for a bit and i'll submit14:28
persiaI think GPLv3 is good for developers: I'm less certain it is good for folk trying to commercially exploit open source.14:29
bwhVery briefly, a point in favour of GPLv3 for companies is that it has automatic relicencing if you screw up but come back into compliance14:29
persiabwh: Or rather, as expensive as *someone else* might want it to be, which is why I don't like it.14:29
persiaOoh.  Nifty :)14:30
bwhWith GPLv2, a copyright holder can add whatever terms (or damages) they like for you to get a new licene14:30
bwh(In fact that's a deliberate part of many GPLv2/proprietary dual licencing arrangements)14:31
ratmice__persia: are you shipping sed? executing a program doesn't trigger the virality of the gpl, gcc only has a special exception because it produces for example builtins which are linked and absent the exception would render all (or almost anyways) code compiled by gcc gpl14:34
persiaratmice__: Theoretically one isn't shipping sed, as one has removed the sed chunk.  In practice, unless one carefully audits all the build systems along the way, one can't know that something didn't copy some part of the sed chunk somewhere.14:36
persiaIt's as much a provenance problem as a build problem.14:36
ratmice__confused about the busybox reference though so maybe misunderstanding the question e.g. if you were linking gplv3 sed into busybox14:36
persiaThe intent of my overstrict suggestion is to render any argument that there might be anything moot.14:37
persiaA program could use "sed" in a way that busybox sed could fulfill, so clearly not GPLv3, but one could conceivably have a build process that used sed in the same way, but happened to use the GNU implementation.14:38
bwhFuck it, let's use FreeBSD14:38
jjardonratmice__: linking is not the problem. The problem is that some companies doesnt want _any_ app/library under GPLv3 on its products14:38
persiabwh: That solution seems nicer to me, but I've been told that morph can't run under any of the BSD derivatives today.14:41
ratmice__persia: understand now, what you were saying can be read far more subtly than I did :)14:41
pedroalvarezradiofree: thanks for modiying the implementation, maybe worth checking with ssam2 if he thinks it's the right thing to do14:41
jjardonfranred: you were rigth, Im still using the busybox sed. Any familiar with busybox know how to tell him to install the binaries in /usr/bin?14:41
pedroalvarezjjardon: that is going to be complex. Is not better to tell sed.morph to install it on /bin?14:42
franredjjardon, I did a hack for dd, I create a softlink from /usr/bin to /bin and remove the busybox dd14:42
ratmice__persia: one potential solution is something i probably brought up sometime in the past, and that is include the license(es) in a section in the binary and run some pass over all the executables14:43
jjardonpedroalvarez: we can , but eventually /bin, /sbin ... should die14:43
franredjjardon, eventually we do what I told you, we should move everything to /usr/bin /usr/sbin14:44
persiaratmice__: You did, and I seem to remember that everyone liked it, but that it required some patches to land in the toolchain, and possible modification of some build recipes, so nobody actually got around to doing it.14:44
persiaratmice__: On the bright side, we have an issue tracker now, so things like that can be documented for the future :)14:44
pedroalvarezfranred: hm... that may be a good approach14:45
jjardonor we can change the morph PATH to look in /usr/bin before /bin ?14:45
pedroalvarezjjardon: that change (and the busybox change that you suggested) may break build-essential.morph14:46
franredjjardon, what is the implications of that in the early stages? I think we want to use the busybox tools14:46
franredin early stages14:46
jjardonrigth, I will change the sed chunk then14:47
pedroalvarezfranred: regarding the coreutils dd "hack". Do you think it's a hack? or a good solution/14:51
pedroalvarez?14:51
pedroalvarezI think is not too bad14:51
ssam2pedroalvarez, jjardon: merging /bin and /usr/bin would be great, it'd require a bit of tweaking of the bootstrap so would probably take a day or two to get it working (plus fixing any issues that came out of it)14:52
franredpedroalvarez, it is a hack, we should be able to merge /bin /sbin to /usr/bin /usr/sbin as other distributions have done14:52
jjardonssam2: just created an story here ;) https://storyboard.baserock.org/#!/story/1114:52
ratmice__well, you shouldn't need to actually modify the toolchain for this (e.g. a gcc plugin should suffice) that is with a whole install-phase check to purge one license, the only thing you'd really need to modify is glibc in order to check that dlopen'd libs are compatible and build scripts to set the appropriate license14:53
pedroalvarezssam2, franred: good to know :) jjardon thanks for creating the story :)14:53
jjardonfranred: is the dd "hack" somewhere in definitions?14:55
pedroalvarezjjardon: dca40db014:56
franredjjardon, http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=baserock/franred/openstack&id=dca40db051092ddc2022327182cde0578c4a1a7e14:56
jjardonthanks!14:56
pedroalvarezI wonder if we should be doing the same for all of the binaries produced by coreutils that have a busybox implementation14:57
jjardonpedroalvarez: there are a lot of binaries; I think its more productive spending time doing the usrmerge instead14:58
pedroalvarezi agree14:58
radiofreeis FSTAB_SRC deprecated?15:11
ssam2not that I know of15:11
radiofreehmm.. i added FSTAB_SRC: LABEL=src /src auto defaults,rw,noatime,nofail 0 2 to a rawdisk deployment15:11
ssam2fstab.configure actually lets you do FSTAB_* so you add multiple extra entries to fstab15:11
ssam2did you have fstab.configure enabled in the system morph ?15:12
ssam2that gotcha is still there15:12
radiofreei did not, thanks15:12
paulsherwoodwhat's the storyboard url thes days please?15:31
pedroalvarezhttps://storyboard.baserock.org15:31
paulsherwoodthanks15:32
pedroalvareznp :)15:32
pedroalvareztiagogomes_: There isn't a patch to upgrade readline in your new patch series, does that mean that it wasn't needed?15:34
tiagogomes_pedroalvarez 90% of the build failures on armv8 were due outdated config.{guess,sub} scripts. When reasonably straightforward, I updated to newer package versions which included updated config.{guess,sub} scripts. readline was failing due outdated config.{guess,sub} scripts15:36
*** rdale has quit IRC15:36
pedroalvareztiagogomes_: so, given that your patch series doesn't do anything with readline, it won't build on armv8?15:39
tiagogomes_pedroalvarez not building on armv8 is not acceptable :) I worked around that in 4e45e6d15:40
*** rdale has joined #baserock15:41
pedroalvareztiagogomes_: I see, cool!15:42
*** rdale has quit IRC15:42
*** rdale has joined #baserock15:43
tiagogomes_pedroalvarez I also removed some not necessary commits for kexec-tools15:44
pedroalvareztiagogomes_: I've seen that, much nicer now :)15:55
* tiagogomes_ nods15:55
pedroalvarezI wonder if upstream would be interested on adding support for aarch6415:55
tiagogomes_probably, kexec-tools seems actively developed15:56
franredjjardon, do you know why pam is looking for /etc/pam.d/other when calling sudo? see error -> http://paste.baserock.org/ohozagefis15:57
franredalso do you know if pam will require more configuration?15:57
franreds/more/other/15:57
tiagogomes_now if that patch really makes kexec work on aarch64 is a different story, but at least it builds15:57
pedroalvarezfranred: worth noting that also journalctl now doesn't show pretty colours etc15:57
pedroalvareztiagogomes_: haha15:58
franredyeah, journalctl does not shown colours, bold letters, etch15:58
franredetc15:58
jjardon--build-log-on-stdout doesnt show the install-commands, should I submit this as a bug or is it intended?15:59
pedroalvarezjjardon: submit just a fix :P16:00
pedroalvarezfranred: so yeah, adding  a /etc/pam.d/other file would fix that, but I wonder if anything else is needed16:01
jjardonok, I undestand is a bug then :P16:01
pedroalvarezjjardon: not sure, but looks like a bug, yeah16:02
pedroalvarezfranred: maybe try adding all the pam.d files from other distro and check if that fixes the problem?16:03
franredpedroalvarez, ?? which ones? all of them? just "other"?16:03
jjardonfranred: no idea, but yeah seems that file is needed16:03
jjardonIts the same in ARCH sas well: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/other?h=packages/pam16:04
pedroalvarezfranred: I mean, to fix the problem of the nice colours of journalctl16:04
franredok, I will create a patch to add it16:04
pedroalvarezfranred: I know that is the problem with the journal colours16:17
franredpedroalvarez, go ahead :)16:17
pedroalvarezless has been moved to devtools stratum, and jorunalctl uses less, and I guess that now you are using busybox less16:18
*** dabukalam has quit IRC16:28
*** dabukalam has joined #baserock16:28
*** tiagogomes_ has quit IRC16:30
*** tiagogomes_ has joined #baserock16:31
*** zoli__ has joined #baserock16:57
*** a1exhughe5 has quit IRC17:00
*** ssam2 has quit IRC17:24
*** zoli__ has quit IRC17:28
*** zoli__ has joined #baserock17:29
*** mariaderidder has quit IRC17:33
pedroalvarezimpressive, the addition of time-zone-data  has broken django :/17:33
*** zoli__ has quit IRC17:34
*** zoli__ has joined #baserock17:34
*** zoli__ has joined #baserock17:35
franredpedroalvarez, jjardon, patch for fixing sudo sent ;-)17:43
*** zoli__ has quit IRC17:43
*** zoli__ has joined #baserock17:44
*** zoli__ has quit IRC17:48
*** zoli__ has joined #baserock17:53
*** bashrc has quit IRC17:53
*** zoli__ has quit IRC17:53
*** zoli__ has joined #baserock17:54
*** zoli__ has quit IRC17:58
*** mdunford has quit IRC18:07
*** jonathanmaw has quit IRC18:15
franredI need to lorry this, it is a qemu submodule: http://paste.baserock.org/hicovakoku18:20
pedroalvarezI think I have already +1ed that18:21
franredpedroalvarez, we left it until we test qemu v2.2.-18:21
franredv2.2.018:21
pedroalvarezfranred: oh, cool!18:22
pedroalvarezthen +2, this is needed18:22
*** sherm_ has quit IRC18:23
*** tiagogomes_ has quit IRC18:44
*** franred has quit IRC18:48
*** 7YUAABE5Y has quit IRC20:10
*** edcragg has quit IRC20:12
*** Krin has quit IRC20:36
*** gary_perkins has quit IRC21:27
*** rdale_ has joined #baserock21:47
*** rdale has quit IRC21:50
*** zoli__ has joined #baserock23:40

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!