| *** zoli__ has quit IRC | 00:36 | |
| *** zoli__ has joined #baserock | 00:45 | |
| *** zoli__ has quit IRC | 01:31 | |
| *** zoli__ has joined #baserock | 01:53 | |
| *** zoli__ has quit IRC | 02:46 | |
| *** zoli__ has joined #baserock | 03:35 | |
| *** zoli__ has quit IRC | 05:03 | |
| *** zoli__ has joined #baserock | 05:24 | |
| *** sherm_ has joined #baserock | 07:09 | |
| jjardon | red in http://mason-x86-64.baserock.org/ ! disk full again? | 07:13 |
|---|---|---|
| jjardon | even 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 #baserock | 08:20 | |
| *** grahamfinney__ has joined #baserock | 08:20 | |
| *** grahamfinney_ has quit IRC | 08:21 | |
| paulsherwood | jjardon: migrate to toybox? | 08:32 |
| jjardon | paulsherwood: we can, but the problem here is why the coreutils diff is not being used | 08:33 |
| paulsherwood | ah, ok | 08:34 |
| pedroalvarez | Hm.. Is coreutils diff being installed in the same path as busybox diff? | 08:34 |
| jjardon | same with sed | 08:39 |
| franred | jjardon, does coreutils diff overwrite busybox diff? | 08:42 |
| jjardon | Id expect that, but seems that no | 08:43 |
| jjardon | oh wait, maybe sed and diff are not part of coreutils? | 08:43 |
| *** mariaderidder has joined #baserock | 08:44 | |
| franred | jjardon, coreutils adds the binaries to /usr/bin when busybox adds it in /bin | 08:44 |
| pedroalvarez | jjardon: true, diff has its own chunk iirc | 08:45 |
| paulsherwood | why are you proposing to add linux-stable now? | 08:48 |
| paulsherwood | jjardon: ^^ | 08:48 |
| jjardon | paulsherwood: linux-stable have the different linux branches | 08:49 |
| jjardon | someone can be interested on follow a specific branch | 08:49 |
| jjardon | franred: pedroalvarez and sed its in a different repo as well | 08:50 |
| franred | jjardon, ok, in any case check whether both binaries are installed and if your system has both | 08:52 |
| jjardon | franred: they are not, we do not build sed or diff in any of the baserock strata | 08:53 |
| * pedroalvarez doesn't understand "linux branches" in this context | 08:54 | |
| jjardon | pedroalvarez: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?h=linux-3.18.y | 08:57 |
| paulsherwood | jjardon: 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 it | 08:57 |
| *** mdunford has joined #baserock | 08:57 | |
| jjardon | paulsherwood: "official" baserock dont, some people maybe want to use them (like me) | 08:58 |
| paulsherwood | :) | 08:59 |
| *** grahamfinney__ has quit IRC | 09:00 | |
| jjardon | argh, now I need a Python3 interpreter... | 09:00 |
| jjardon | Is someone working on that? | 09:00 |
| *** gfinney has joined #baserock | 09:00 | |
| *** 7YUAABE5Y has joined #baserock | 09:00 | |
| paulsherwood | i had it working, but it appeared i was alone in wanting it so i didn't push it anywhere | 09:01 |
| 7YUAABE5Y | perhaps I should change it to Albert. That was my nickname at uni | 09:01 |
| 7YUAABE5Y | Ahh what's happened ? | 09:01 |
| 7YUAABE5Y | Opps wrong channel | 09:02 |
| paulsherwood | :) | 09:03 |
| *** bashrc has joined #baserock | 09:04 | |
| jjardon | paulsherwood: maybe its time to push it then? ;) | 09:05 |
| jjardon | lets have a python3 strata to make the split easier? | 09:06 |
| *** rdale has joined #baserock | 09:07 | |
| paulsherwood | yup. i can't get to this now, though. | 09:10 |
| jjardon | sure | 09:11 |
| * jjardon will build a older version of GNOME Shell in the meantime | 09:12 | |
| jjardon | paulsherwood: mind if I assign you this task in the storyboard story? n(only to keep track of things) | 09:13 |
| paulsherwood | me and my big mouth | 09:15 |
| paulsherwood | ok | 09:15 |
| jjardon | paulsherwood: :) done! | 09:18 |
| *** gary_perkins has joined #baserock | 09:18 | |
| jjardon | I think makes sense to add diff and sed in the coreutils-common stratum, any objections? | 09:19 |
| franred | jjardon, +1 just be careful where the binaries landed | 09:21 |
| jjardon | actually, can I lorry sed first? http://paste.baserock.org/vizinocuzo | 09:21 |
| franred | jjardon, that looks ok to me | 09:22 |
| *** jonathanmaw has joined #baserock | 09:24 | |
| pedroalvarez | jjardon: +1 | 09:34 |
| jjardon | franred: pedroalvarez thanks! | 09:34 |
| *** ssam2 has joined #baserock | 09:36 | |
| *** ChanServ sets mode: +v ssam2 | 09:36 | |
| *** edcragg has joined #baserock | 09:46 | |
| *** gfinney has quit IRC | 09:48 | |
| SotK | has anyone managed to build pygobject in Baserock? | 09:52 |
| *** zoli__ has quit IRC | 09:53 | |
| *** zoli__ has joined #baserock | 09:53 | |
| SotK | heh, I'd guess so given its in the virtualization stratum :) | 09:54 |
| pedroalvarez | SotK: if it's there then yes :) | 09:55 |
| franred | SotK, if it is in virtualization.morph, the openstack branch is building it everytime | 09:57 |
| ssam2 | i've removed cached system artifacts from cache.baserock.org again, it was full, now there is 22.1GB | 10:01 |
| ssam2 | we really need to get automated cleanups of that system working soon | 10:01 |
| *** zoli__ has quit IRC | 10:02 | |
| pedroalvarez | ssam2: indeed | 10:03 |
| pedroalvarez | also in mason/distbuild | 10:03 |
| *** zoli__ has joined #baserock | 10:06 | |
| *** zoli__ has quit IRC | 10:14 | |
| paulsherwood | ssam2: i've asked before... isn't that just morph gc by default? | 10:14 |
| * SotK discovers gnome-common is in two strata | 10:16 | |
| *** zoli__ has joined #baserock | 10:17 | |
| ssam2 | paulsherwood: I don't think so. Morph is a build tool, cache.baserock.org is a cache | 10:21 |
| ssam2 | I don't think the 'morph gc' behaviour will also work for a shared remote cache | 10:22 |
| ssam2 | that 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 correctly | 10:22 |
| * paulsherwood is surprised | 10:24 | |
| paulsherwood | :) | 10:24 |
| robtaylor | assumptions in the distbuild code iirc | 10:28 |
| pedroalvarez | yeah, it assumes things like "if this stratum artifact is present in the cache server, then all its dependencies are" | 10:35 |
| pedroalvarez | o something similar | 10:35 |
| straycat | SotK, we need to add pylru before we merge your branch? | 10:37 |
| jjardon | SotK: we can remove soon gnome-common from gtk-deps, it will not needed anymore in the next atk release | 10:37 |
| SotK | straycat: 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 |
| straycat | Oh okay either's fine I think | 10:40 |
| pedroalvarez | this lorry needs fixing: http://paste.baserock.org/ayojiwazil | 10:40 |
| pedroalvarez | tiagogomes_: you may be interested on it ^ | 10:40 |
| persia | I 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 |
| jjardon | Is there a way to telling morph to show me all the compilation output? | 10:41 |
| pedroalvarez | persia: master and releases? | 10:41 |
| pedroalvarez | "releases" > definitions tags | 10:41 |
| persia | That seems a sensible start. | 10:41 |
| straycat | jjardon, --build-log-on-stdout or the logs in the artifact cache | 10:41 |
| persia | I'd like more cache, because I imagine people doing more interesting things, but it might just be me. | 10:42 |
| radiofree | i didn't know about --build-log-on-stdout! | 10:42 |
| persia | Maybe 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 afraid | 10:42 |
| franred | pedroalvarez, +1 to that lorry | 10:42 |
| *** dabukalam has joined #baserock | 10:43 | |
| ssam2 | persia: 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 master | 10:43 |
| jjardon | pedroalvarez: +1 | 10:43 |
| pedroalvarez | jjardon, franred: thanks guys | 10:43 |
| persia | ssam2: 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 |
| jjardon | straycat: thanks!! | 10:45 |
| pedroalvarez | tiagogomes_: ah, ok, I was expecting that the latest release from 2 days ago would work | 10:46 |
| persia | Hrm? Why doesn't the latest release work? | 10:48 |
| pedroalvarez | s/would work/would work on aarch64/ | 10:49 |
| SotK | jjardon: where would you put it, since I don't really think it belongs in virtualization either? | 10:49 |
| jjardon | SotK: Its only a bunch of autoconf macros, so maybe core? | 10:51 |
| paulsherwood | SotK: aren't you already making major improvements to caching? i think i saw pylru in one of your series? | 10:51 |
| jjardon | SotK: there are plans to completely deprecate it, so it wil go away eventually | 10:51 |
| tiagogomes_ | persia kexec-tools is arch dependent. aarch64 is not supported | 10:51 |
| pedroalvarez | One 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 |
| pedroalvarez | would that make sense? | 10:52 |
| persia | pedroalvarez: I think that as long as we have a cache-server config option, that would be confusing for users. | 10:52 |
| paulsherwood | not to me | 10:52 |
| * persia still wants the cache config to default to cache.baserock.org | 10:52 | |
| paulsherwood | ie not making sense to me | 10:52 |
| paulsherwood | +1 to cache.baserock.org | 10:53 |
| SotK | paulsherwood: 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 |
| pedroalvarez | if we want to put cache artifacts in cache.baserock.org too, then we need to think a bit more about this first | 10:53 |
| pedroalvarez | s/cache artifacts/release cache artifacts/ | 10:54 |
| persia | I think more thought would be good. | 10:54 |
| persia | At a high level, I want to have a cache server which contains stuff that is useful to me. | 10:55 |
| paulsherwood | i think it's just one cache, where some artifacts persist (because released, or continuing to be used) | 10:55 |
| persia | So I can branch from a release, and use that efficiently, or I can follow master, and use that efficiently. | 10:55 |
| persia | I'm probably being selfish about this, but expect that most other users have the same class of selfish wants. | 10:55 |
| pedroalvarez | Ah, btw, when I said "2 different locations" I meant 2 different folders on the same cache server, being this one cache.baserock.org | 10:56 |
| pedroalvarez | so we can do clean-ups of artifacts without caring about removing release artifacts | 10:56 |
| mauricemoss_ | Morning, does anyone have experience in altering gcc/config.gcc when building gcc? | 10:58 |
| ssam2 | persia: definitely, it makes sense to cache as much as we can | 10:59 |
| jmacs | A long time ago; I've probably forgotten it all now | 10: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 |
| jmacs | Taking a look now | 11:04 |
| *** sambishop has joined #baserock | 11:07 | |
| jmacs | mauricemoss_: That patch doesn't look like it would apply to the latest gcc master - what's it based on? | 11:13 |
| rdale | is ld.so built as part of glibc? | 11:15 |
| jmacs | Guessing whatever's in g.b.o. for now | 11:15 |
| mauricemoss_ | it's based on gcc 4.9.2, commit b3c9b176c1f10ebeff5700eb3760e9511f23fa06 | 11:17 |
| jmacs | Unfortunately, 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 yours | 11:18 |
| jmacs | Anyone else have any ideas? | 11:18 |
| ssam2 | it's just a huge shell script, right? so, it'll pattern match in exactly the same way as any other shell 'case' statement | 11:19 |
| ssam2 | shell is nightmarish to debug, but it is documented | 11: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 built | 11:20 |
| ssam2 | why 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 |
| rdale | mauricemoss_: 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 properly | 11:21 |
| *** zoli__ has quit IRC | 11:24 | |
| tiagogomes_ | why are we always changing libc implementations? | 11:31 |
| persia | Lots of people like different libcs? | 11:32 |
| persia | Personally, 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 |
| pedroalvarez | Another lorry that needs fixing: http://paste.baserock.org/qozevusili | 11:37 |
| franred | pedroalvarez, is that a mirror of the openstack one or in the other way around? | 11:37 |
| pedroalvarez | I think both repos were from openstack, but they have moved it | 11:38 |
| pedroalvarez | franred: ^ | 11:38 |
| franred | pedroalvarez, aham, +1 to the fix | 11:39 |
| *** paulw has joined #baserock | 11:40 | |
| pedroalvarez | thanks franred, any other? | 11:41 |
| persia | +1 | 11:42 |
| persia | Note that we should expect a lot of these in the future, as more projects complete incubation | 11:42 |
| pedroalvarez | persia: thanks! merged | 11:50 |
| jjardon | help2man build system is a bit "special", seems noone in the world uses git to bootstrap it apart the author | 11:50 |
| radiofree | after doing a baserock-system-config-sync merge, i want to check the merged fstab has the correct UUID | 11:50 |
| radiofree | if i make a change to that /etc/fstab, should i backup the original? | 11:51 |
| radiofree | even though it's incorrect and won't work? | 11:51 |
| ssam2 | no, it's available in the old subvolume anyway | 12:01 |
| pedroalvarez | I think I understand what are you trying to achieve. Is this to support upgrades with a rawimage? | 12:01 |
| radiofree | yes | 12:01 |
| radiofree | that works, i just need to do the fstab checking in baseorkc-system-config-sync now | 12:01 |
| pedroalvarez | radiofree: is not the best thing to do to keep the original fstab? (fstab pre-upgrade) | 12:02 |
| radiofree | basically, after the merge, check the fstab UUID for "/", if that's not what blkid says, change it | 12:02 |
| radiofree | pedroalvarez: wouldn't the merge take care of that (keep any user changes?) | 12:03 |
| radiofree | i 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 that | 12:03 |
| radiofree | maybe a new state directory has been added in the new image or something? | 12:04 |
| pedroalvarez | radiofree: hm.. fair enough | 12:04 |
| radiofree | but probably if that is the case, the upgrade wouldn't work anyway? | 12:05 |
| pedroalvarez | hehe | 12:05 |
| pedroalvarez | I wonder how a normal upgrade works. | 12:05 |
| radiofree | i'm just thinking that maybe someone might deploy a weird fstab that also mounts / to /foo as well | 12:05 |
| pedroalvarez | regarding fstab and UUIDs | 12:05 |
| radiofree | in which case you'd probably want to merge that, then update the UUID, rather than prefer the old fstab | 12:06 |
| radiofree | pedroalvarez: morph generates a fstab using the UUID of the system you're upgrading to | 12:06 |
| radiofree | it assumes there's not going to be any /etc/fstab in the thing you're deploying | 12:06 |
| pedroalvarez | yeah, I think i did that patch | 12:06 |
| pedroalvarez | radiofree: could be possible to change the fstab's UUID before calling baserock-system-config-sync? | 12:08 |
| radiofree | i can, and i did, ssam2 suggested i do it in baserock-system-config-sync though | 12:09 |
| pedroalvarez | :) ok | 12:09 |
| ssam2 | the problem was that it was being done in a specific write extension, which isn't the right place to be merging system configuration stuff | 12:20 |
| ssam2 | we'd have to duplicate the code in each new write extension that did upgrades | 12:21 |
| ssam2 | it could go in system-version-manager instead of baserock-system-config-sync if that's easier, I guess | 12:21 |
| pedroalvarez | yeah, I thought that was the plan | 12:22 |
| pedroalvarez | so you can do something like `system-version-manager deploy --rawdisk /path/to/new/disk.img | 12:22 |
| pedroalvarez | ` | 12:22 |
| pedroalvarez | and IMO it's going to be way easier than playing with baserock-system-config-sync | 12:23 |
| paulsherwood | +1. but couldn't it check the format, so no need for --rawdisk? | 12:24 |
| pedroalvarez | yeah, that should be possible | 12:26 |
| jmalk | OOI, 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 |
| straycat | does seem unfinished doesn't it | 12:34 |
| jmalk | history suggests the section was moved from vm-setup to quick-start, so maybe it made more sense in its previous context | 12:35 |
| *** JPohlmann has quit IRC | 13:02 | |
| jjardon | paulsherwood: seems you actually committed the python3 stuff: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/ps/add-python3 | 13:07 |
| * jjardon testing | 13:07 | |
| *** JPohlmann has joined #baserock | 13:10 | |
| *** JPohlmann has joined #baserock | 13:10 | |
| rjek | hi JPohlmann | 13:12 |
| radiofree | pedroalvarez: so that's approval to modify the fstab from the rawdisk image inside system-version-manager then? | 13:50 |
| radiofree | gbo been a little slow for anyone else recently? | 13:56 |
| rjek | jjardon: Isn't that version of sed GPLv3? | 14:01 |
| jjardon | rjek: yes, probably | 14:02 |
| rjek | That'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-gplv3 | 14:03 | |
| rjek | sed will probably end up in built images and lots of things depend on it at runtime | 14:03 |
| persia | And probably different build systems as well | 14:03 |
| jjardon | Doesn't matter because you can choose to include that stratum or not | 14:03 |
| persia | (with correspondingly many distbuilds, etc.) | 14:03 |
| jjardon | That was the point of putting coreutils in a different stratum | 14:03 |
| jjardon | persia: that's a no-go; you would duplicate all the strata definitions | 14:04 |
| * paulsherwood repeats the suggestion of switching to toybox. | 14:05 | |
| persia | I seem to remember prior discussion on the topic suggesting to just fork definitions to resolve this. | 14:06 |
| persia | Have a definitions that didn't permit GPLv3 and one that did, and be done with the mess. | 14:06 |
| paulsherwood | makes sense, i think | 14:06 |
| persia | paulsherwood: 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 #baserock | 14:06 | |
| paulsherwood | yes, fair enough | 14:07 |
| persia | I 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 |
| franred | jjardon, have you checked if sed end up in /bin/sed? or in /usr/bin/sed? | 14:07 |
| persia | Also, it might make Mason more complex in some way, and we'd want Mason running against both. | 14:07 |
| radiofree | franred: isn't /usr/bin in $PATH first? | 14:08 |
| jjardon | franred: no, but it works | 14:08 |
| franred | I told you because in my openstack system I have sed in /bin/sed | 14:08 |
| franred | radiofree, I think the most of the busybox binaries end up in /bin | 14:09 |
| radiofree | other than it being wasteful, it shouldn't really matter though? | 14:09 |
| radiofree | my $PATH is /usr/bin:/bin:/usr/sbin:/sbin | 14:10 |
| franred | radiofree, it matters depends on which one your PATH takes first | 14:10 |
| jjardon | that reminds me we should kill /bin | 14:10 |
| * radiofree doesn't know what the default PATH is for morph | 14:10 | |
| radiofree | ..builds | 14:10 |
| franred | radiofree, mine is /sbin:/bin:/usr/sbin:/usr/bin | 14:10 |
| jjardon | and /sbin as well | 14:11 |
| franred | so jjardon, in systems with both sed busybox is still the one in use | 14:11 |
| jjardon | persia: what do you mean by "just fork definitions to resolve this" . HAve 2 different branches of definitions? | 14:12 |
| radiofree | that was discussed before, having a genivi branch for definitions | 14:12 |
| jjardon | franred: let me recheck | 14:12 |
| jjardon | si what happen if someone want to build a product that doesnt have any GPLv3 inside? we directly dont support that? | 14:13 |
| radiofree | jjardon: wouldn't that be up to them? | 14:13 |
| persia | jjardon: Yes, two branches of definitions. Folk wanting non-GPLv3 would use the non-GPLv3 branch. | 14:14 |
| jjardon | radiofree: yes, but there will no way to build such a system with baserock, other than using a probably very outdated genivi branch of definitions | 14:14 |
| persia | And 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 |
| jjardon | persia: so the non-GPLv3 will bit rot? | 14:15 |
| radiofree | jjardon: ah i see what you mean | 14:15 |
| persia | jjardon: Why is it hard to build? If we have two up-to-date branches, should we not expect it to just work? | 14:15 |
| persia | I presume that if the folk who need non-GPLv3 really need it, they would keep it from bitrotting. | 14:16 |
| persia | But the split should only happen if there are enough people willing to maintain both branches. | 14:16 |
| jjardon | IMHO they are not | 14:17 |
| persia | I believe there are enough folk willing to maintain a GPLv3 branch. | 14:17 |
| persia | I have yet to see evidence there are enough willing to maintain a non-GPLv3 branch | 14:17 |
| persia | But I only advocate branching *if* there is a sufficient volunteer population. | 14:18 |
| jjardon | we can barelly mantain one, dont think is realistic think about 2 | 14:18 |
| persia | I 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 |
| jjardon | mmm, but maybe its the only option: we _have_ to upgrade to new versions of a lot of GNU libraries to support new architectures | 14:19 |
| persia | And in such a case, I'd expect to make a fuss at them to keep up :) | 14:19 |
| persia | Is there anyone around today that needs non-GPLv3 who could represent that opinion? | 14:20 |
| franred | I imagine that if we need to build genivi baselines with non-GPLv3 software we will have to maintain then non-GPLv3 branch | 14:22 |
| franred | not sure if in this case stripping the GPLv3 parts will make the build non-GPLv3, toughs? | 14:23 |
| persia | stripping is fraught with difficulties, mostly surrounding provenance. | 14:24 |
| persia | gcc has a special exception, but some other tools are less explicit, and I'm not sure it's been tested. | 14:24 |
| persia | For 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 expensive | 14:25 | |
| bwh | It's as expensive as you want it to be | 14:26 |
| bwh | I would think sed is a standard tool and irrelevant to the licence | 14:27 |
| pedroalvarez | radiofree: yeah, modify fstab in system-version-manager before using baserock-system-config-sync makes sense to me | 14:28 |
| * radiofree reverts his changes to system-version-manager | 14:28 | |
| bwh | By the way there was an interesting talk about Samba and the benefits of GPLv3 at FOSDEM | 14:28 |
| radiofree | ok, let me test this for a bit and i'll submit | 14:28 |
| persia | I think GPLv3 is good for developers: I'm less certain it is good for folk trying to commercially exploit open source. | 14:29 |
| bwh | Very briefly, a point in favour of GPLv3 for companies is that it has automatic relicencing if you screw up but come back into compliance | 14:29 |
| persia | bwh: Or rather, as expensive as *someone else* might want it to be, which is why I don't like it. | 14:29 |
| persia | Ooh. Nifty :) | 14:30 |
| bwh | With GPLv2, a copyright holder can add whatever terms (or damages) they like for you to get a new licene | 14: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 gpl | 14:34 |
| persia | ratmice__: 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 |
| persia | It'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 busybox | 14:36 |
| persia | The intent of my overstrict suggestion is to render any argument that there might be anything moot. | 14:37 |
| persia | A 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 |
| bwh | Fuck it, let's use FreeBSD | 14:38 |
| jjardon | ratmice__: linking is not the problem. The problem is that some companies doesnt want _any_ app/library under GPLv3 on its products | 14:38 |
| persia | bwh: 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 |
| pedroalvarez | radiofree: thanks for modiying the implementation, maybe worth checking with ssam2 if he thinks it's the right thing to do | 14:41 |
| jjardon | franred: 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 |
| pedroalvarez | jjardon: that is going to be complex. Is not better to tell sed.morph to install it on /bin? | 14:42 |
| franred | jjardon, I did a hack for dd, I create a softlink from /usr/bin to /bin and remove the busybox dd | 14: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 executables | 14:43 |
| jjardon | pedroalvarez: we can , but eventually /bin, /sbin ... should die | 14:43 |
| franred | jjardon, eventually we do what I told you, we should move everything to /usr/bin /usr/sbin | 14:44 |
| persia | ratmice__: 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 |
| persia | ratmice__: On the bright side, we have an issue tracker now, so things like that can be documented for the future :) | 14:44 |
| pedroalvarez | franred: hm... that may be a good approach | 14:45 |
| jjardon | or we can change the morph PATH to look in /usr/bin before /bin ? | 14:45 |
| pedroalvarez | jjardon: that change (and the busybox change that you suggested) may break build-essential.morph | 14:46 |
| franred | jjardon, what is the implications of that in the early stages? I think we want to use the busybox tools | 14:46 |
| franred | in early stages | 14:46 |
| jjardon | rigth, I will change the sed chunk then | 14:47 |
| pedroalvarez | franred: regarding the coreutils dd "hack". Do you think it's a hack? or a good solution/ | 14:51 |
| pedroalvarez | ? | 14:51 |
| pedroalvarez | I think is not too bad | 14:51 |
| ssam2 | pedroalvarez, 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 |
| franred | pedroalvarez, it is a hack, we should be able to merge /bin /sbin to /usr/bin /usr/sbin as other distributions have done | 14:52 |
| jjardon | ssam2: just created an story here ;) https://storyboard.baserock.org/#!/story/11 | 14: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 license | 14:53 |
| pedroalvarez | ssam2, franred: good to know :) jjardon thanks for creating the story :) | 14:53 |
| jjardon | franred: is the dd "hack" somewhere in definitions? | 14:55 |
| pedroalvarez | jjardon: dca40db0 | 14:56 |
| franred | jjardon, http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=baserock/franred/openstack&id=dca40db051092ddc2022327182cde0578c4a1a7e | 14:56 |
| jjardon | thanks! | 14:56 |
| pedroalvarez | I wonder if we should be doing the same for all of the binaries produced by coreutils that have a busybox implementation | 14:57 |
| jjardon | pedroalvarez: there are a lot of binaries; I think its more productive spending time doing the usrmerge instead | 14:58 |
| pedroalvarez | i agree | 14:58 |
| radiofree | is FSTAB_SRC deprecated? | 15:11 |
| ssam2 | not that I know of | 15:11 |
| radiofree | hmm.. i added FSTAB_SRC: LABEL=src /src auto defaults,rw,noatime,nofail 0 2 to a rawdisk deployment | 15:11 |
| ssam2 | fstab.configure actually lets you do FSTAB_* so you add multiple extra entries to fstab | 15:11 |
| ssam2 | did you have fstab.configure enabled in the system morph ? | 15:12 |
| ssam2 | that gotcha is still there | 15:12 |
| radiofree | i did not, thanks | 15:12 |
| paulsherwood | what's the storyboard url thes days please? | 15:31 |
| pedroalvarez | https://storyboard.baserock.org | 15:31 |
| paulsherwood | thanks | 15:32 |
| pedroalvarez | np :) | 15:32 |
| pedroalvarez | tiagogomes_: 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} scripts | 15:36 |
| *** rdale has quit IRC | 15:36 | |
| pedroalvarez | tiagogomes_: 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 4e45e6d | 15:40 |
| *** rdale has joined #baserock | 15:41 | |
| pedroalvarez | tiagogomes_: I see, cool! | 15:42 |
| *** rdale has quit IRC | 15:42 | |
| *** rdale has joined #baserock | 15:43 | |
| tiagogomes_ | pedroalvarez I also removed some not necessary commits for kexec-tools | 15:44 |
| pedroalvarez | tiagogomes_: I've seen that, much nicer now :) | 15:55 |
| * tiagogomes_ nods | 15:55 | |
| pedroalvarez | I wonder if upstream would be interested on adding support for aarch64 | 15:55 |
| tiagogomes_ | probably, kexec-tools seems actively developed | 15:56 |
| franred | jjardon, do you know why pam is looking for /etc/pam.d/other when calling sudo? see error -> http://paste.baserock.org/ohozagefis | 15:57 |
| franred | also do you know if pam will require more configuration? | 15:57 |
| franred | s/more/other/ | 15:57 |
| tiagogomes_ | now if that patch really makes kexec work on aarch64 is a different story, but at least it builds | 15:57 |
| pedroalvarez | franred: worth noting that also journalctl now doesn't show pretty colours etc | 15:57 |
| pedroalvarez | tiagogomes_: haha | 15:58 |
| franred | yeah, journalctl does not shown colours, bold letters, etch | 15:58 |
| franred | etc | 15:58 |
| jjardon | --build-log-on-stdout doesnt show the install-commands, should I submit this as a bug or is it intended? | 15:59 |
| pedroalvarez | jjardon: submit just a fix :P | 16:00 |
| pedroalvarez | franred: so yeah, adding a /etc/pam.d/other file would fix that, but I wonder if anything else is needed | 16:01 |
| jjardon | ok, I undestand is a bug then :P | 16:01 |
| pedroalvarez | jjardon: not sure, but looks like a bug, yeah | 16:02 |
| pedroalvarez | franred: maybe try adding all the pam.d files from other distro and check if that fixes the problem? | 16:03 |
| franred | pedroalvarez, ?? which ones? all of them? just "other"? | 16:03 |
| jjardon | franred: no idea, but yeah seems that file is needed | 16:03 |
| jjardon | Its the same in ARCH sas well: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/other?h=packages/pam | 16:04 |
| pedroalvarez | franred: I mean, to fix the problem of the nice colours of journalctl | 16:04 |
| franred | ok, I will create a patch to add it | 16:04 |
| pedroalvarez | franred: I know that is the problem with the journal colours | 16:17 |
| franred | pedroalvarez, go ahead :) | 16:17 |
| pedroalvarez | less has been moved to devtools stratum, and jorunalctl uses less, and I guess that now you are using busybox less | 16:18 |
| *** dabukalam has quit IRC | 16:28 | |
| *** dabukalam has joined #baserock | 16:28 | |
| *** tiagogomes_ has quit IRC | 16:30 | |
| *** tiagogomes_ has joined #baserock | 16:31 | |
| *** zoli__ has joined #baserock | 16:57 | |
| *** a1exhughe5 has quit IRC | 17:00 | |
| *** ssam2 has quit IRC | 17:24 | |
| *** zoli__ has quit IRC | 17:28 | |
| *** zoli__ has joined #baserock | 17:29 | |
| *** mariaderidder has quit IRC | 17:33 | |
| pedroalvarez | impressive, the addition of time-zone-data has broken django :/ | 17:33 |
| *** zoli__ has quit IRC | 17:34 | |
| *** zoli__ has joined #baserock | 17:34 | |
| *** zoli__ has joined #baserock | 17:35 | |
| franred | pedroalvarez, jjardon, patch for fixing sudo sent ;-) | 17:43 |
| *** zoli__ has quit IRC | 17:43 | |
| *** zoli__ has joined #baserock | 17:44 | |
| *** zoli__ has quit IRC | 17:48 | |
| *** zoli__ has joined #baserock | 17:53 | |
| *** bashrc has quit IRC | 17:53 | |
| *** zoli__ has quit IRC | 17:53 | |
| *** zoli__ has joined #baserock | 17:54 | |
| *** zoli__ has quit IRC | 17:58 | |
| *** mdunford has quit IRC | 18:07 | |
| *** jonathanmaw has quit IRC | 18:15 | |
| franred | I need to lorry this, it is a qemu submodule: http://paste.baserock.org/hicovakoku | 18:20 |
| pedroalvarez | I think I have already +1ed that | 18:21 |
| franred | pedroalvarez, we left it until we test qemu v2.2.- | 18:21 |
| franred | v2.2.0 | 18:21 |
| pedroalvarez | franred: oh, cool! | 18:22 |
| pedroalvarez | then +2, this is needed | 18:22 |
| *** sherm_ has quit IRC | 18:23 | |
| *** tiagogomes_ has quit IRC | 18:44 | |
| *** franred has quit IRC | 18:48 | |
| *** 7YUAABE5Y has quit IRC | 20:10 | |
| *** edcragg has quit IRC | 20:12 | |
| *** Krin has quit IRC | 20:36 | |
| *** gary_perkins has quit IRC | 21:27 | |
| *** rdale_ has joined #baserock | 21:47 | |
| *** rdale has quit IRC | 21:50 | |
| *** zoli__ has joined #baserock | 23:40 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!