| * persia examines PEP-426, and is delighted with the nomenclature of requirements: "run_requires", "build_requires", "test_requires", and "dev_requires". | 00:00 | |
| *** zoli__ has joined #baserock | 00:54 | |
| *** zoli__ has quit IRC | 00:59 | |
| *** zoli__ has joined #baserock | 04:02 | |
| *** zoli__ has quit IRC | 04:22 | |
| *** petefoth has quit IRC | 04:32 | |
| *** tiagogomes has quit IRC | 04:32 | |
| *** nowster has quit IRC | 04:32 | |
| *** flatmush has quit IRC | 04:32 | |
| *** fay_ has quit IRC | 04:32 | |
| *** paulw has quit IRC | 04:32 | |
| *** bashrc has quit IRC | 04:32 | |
| *** sambishop has quit IRC | 04:32 | |
| *** CTtpollard has quit IRC | 04:32 | |
| *** petefoth has joined #baserock | 04:32 | |
| *** nowster has joined #baserock | 04:32 | |
| *** bashrc has joined #baserock | 04:32 | |
| *** paulw has joined #baserock | 04:32 | |
| *** fay_ has joined #baserock | 04:32 | |
| *** franred has quit IRC | 04:33 | |
| *** sambishop has joined #baserock | 04:33 | |
| *** tiagogomes has joined #baserock | 04:33 | |
| *** franred has joined #baserock | 04:33 | |
| *** flatmush has joined #baserock | 04:33 | |
| *** zoli__ has joined #baserock | 04:34 | |
| *** zoli__ has quit IRC | 06:36 | |
| *** zoli__ has joined #baserock | 06:37 | |
| *** zoli__ has quit IRC | 06:41 | |
| *** zoli__ has joined #baserock | 07:03 | |
| *** a1exhughe5 has joined #baserock | 07:30 | |
| *** edcragg has quit IRC | 07:37 | |
| *** mdunford has joined #baserock | 07:43 | |
| SotK | bah, mason-x86-32 has gone kaput | 08:00 |
|---|---|---|
| petefoth | Is it the 'out of disk space' problem again? | 08:01 |
| SotK | I guess so, that was the cause of 503 last time wasn't it? | 08:02 |
| petefoth | From what I gathered by lurking in here :) | 08:02 |
| *** ssam2 has joined #baserock | 08:35 | |
| *** ChanServ sets mode: +v ssam2 | 08:35 | |
| *** jonathanmaw has joined #baserock | 08:36 | |
| ssam2 | I tried setting up a continuous builder with YBD, but it seems to have broken almost as soon as I left instead of building anything :( | 08:40 |
| SotK | :( | 08:40 |
| ssam2 | with: 'OSError: [Errno 18] Invalid cross-device link' | 08:40 |
| ssam2 | oh, it's while trying to hardlink stuff into the sandbox | 08:40 |
| rjek | Oops | 08:41 |
| ssam2 | seems it can't handle won't detect the case where tmp is on a different partition to the cachedir | 08:42 |
| ssam2 | can't handle and won't detect | 08:42 |
| Kinnison | tracebacks FTW | 08:42 |
| *** mariaderidder has joined #baserock | 08:43 | |
| *** jonathanmaw has quit IRC | 08:47 | |
| *** jonathanmaw has joined #baserock | 08:50 | |
| ssam2 | although tracebacks in the systemd journal are slightly less awesome, because journalctl strips the indentation | 08:52 |
| ssam2 | or systemd-journald strips it. They are hard to read, anyway | 08:52 |
| Kinnison | Mmm, I think it's to do with the stdxxx->journal processing | 08:52 |
| Kinnison | this is why morph --log was useful | 08:52 |
| * ssam2 filed https://github.com/devcurmudgeon/ybd/issues/83 | 08:58 | |
| *** edcragg has joined #baserock | 09:00 | |
| * straycat thank SotK for --snapshot | 09:06 | |
| *** gary_perkins has joined #baserock | 09:17 | |
| *** lachlanmackenzie has joined #baserock | 09:18 | |
| *** jonathanmaw has quit IRC | 09:38 | |
| *** jonathanmaw has joined #baserock | 09:39 | |
| richard_maw | The change in https://gerrit.baserock.org/#/c/850/ will work for most people, but not all. I'd prefer if another reviewer could make a judgement call on whether the change is sufficient, so I've +1d rather than +2d | 09:47 |
| mwilliams_ct | hmm, I had thought /etc/morph.conf had to be symlinked to whatever your config file is. til! thanks richard_maw | 09:50 |
| richard_maw | yeah, it can also take drop-in files in /etc/morph/*.conf, or ~/.config/morph/*.conf | 09:51 |
| richard_maw | sorry I didn't think of this in my first review | 09:51 |
| mwilliams_ct | I think it should be changed, will -1 and fix up | 09:52 |
| *** jonathanmaw has quit IRC | 09:58 | |
| *** jonathanmaw has joined #baserock | 09:58 | |
| richard_maw | oh, one thing | 10:02 |
| richard_maw | I think you'll always get a value for tempdir with the output provided by morph | 10:03 |
| richard_maw | but it may be an empty string | 10:03 |
| richard_maw | so you may need to amend your condition to check for that, rather than the option being missing | 10:03 |
| mwilliams_ct | yes, same as it was in earlier versions - use if -z TMPDIR | 10:04 |
| *** zoli__ has quit IRC | 10:10 | |
| *** zoli__ has joined #baserock | 10:10 | |
| nowster | ybd doesn't build well without linux-user-chroot | 10:11 |
| radiofree | it doesn't build at all without it? | 10:11 |
| nowster | ...it gives the crash in either linux-api-headers or fhs-dirs that I experienced yesterday afternoon | 10:12 |
| ssam2 | radiofree: it has a chroot() backend via sandboxlib | 10:12 |
| nowster | change the kernel and reenable linux-user-chroot, and it's building again | 10:12 |
| richard_maw | SotK: You +1'd a previous version of https://gerrit.baserock.org/#/c/581/ , are you available to review the latest version? | 10:12 |
| ssam2 | nowster: do you have a log of the error? | 10:12 |
| SotK | richard_maw: sure | 10:12 |
| radiofree | ssam2: ah, cool! | 10:12 |
| nowster | ssam2: from scrollback : http://paste.baserock.org/jiferuvuni | 10:13 |
| richard_maw | nowster, ssam2: That could possibly be a lack of a chdir after the chroot | 10:14 |
| ssam2 | richard_maw: indeed. the code is there to do that, but maybe it's not working correctly | 10:14 |
| nowster | I notice a lot of stuff left as /src/tmp/tmpXXXXX after a ybd run. | 10:15 |
| ssam2 | as it doesn't use the `chroot` program, but rather a separate thread that calls os.chroot(), os.chdir() and then subprocess.Popen() | 10:15 |
| *** zoli__ has quit IRC | 10:15 | |
| ssam2 | mason-x86-32.baserock.org seems to have lost network connectivity! not seen that before | 10:18 |
| ssam2 | it has an IP, can't ping its own gateway. | 10:18 |
| ssam2 | is there a way to forcefully disconnect and reconnect from the network using `networkctl` ? | 10:20 |
| ssam2 | it's an OpenStack instance, so I can't just pull the wire out | 10:20 |
| ssam2 | ifdown just says 'interface eth0 not configured' | 10:20 |
| richard_maw | ssam2: use `ip` | 10:21 |
| richard_maw | try bringing the interface down then restarting systemd-networkd | 10:21 |
| ssam2 | just doing 'ip link set down dev eth0' then 'ip link set up dev eth0' seems to have fixed it, thanks for the pointer | 10:23 |
| ssam2 | I guess we should remove ifup and ifdown from our busybox config if they don't actually work... although I suppose we only want to remove them in systems that use systemd-networkd, which can't really be expressed in definitions... | 10:24 |
| ssam2 | maybe the systemd chunk could overwrite them with shell scripts that run 'ip link set down/up dev' :) | 10:25 |
| richard_maw | I'd rather not | 10:30 |
| richard_maw | ifup/ifdown are explicitly for interfaces managed by /etc/network/interfaces | 10:30 |
| richard_maw | and theoretically you could still manage some interfaces with ifupdown and others with systemd-networkd | 10:30 |
| *** zoli__ has joined #baserock | 10:37 | |
| perryl | i have a file of components in build-system-x86_64 listing non-deterministic files that i wish to add to WBO, but it's about 9000 lines. would it be best to just put the component names (e.g. ansible, cmake, etc) rather than a full break down of what isn't bit-for-bit? or is there a way of hiding it behind an expand tab to include everything (e.g. .pyo, .pyc, .gz etc) | 10:57 |
| richard_maw | I wouldn't worry about it being 9000 lines and add it to w.b.o anyway | 10:59 |
| wdutch | over 9000?! | 11:00 |
| * richard_maw looks down on wdutch | 11:00 | |
| richard_maw | wdutch: Use interrobangs | 11:00 |
| richard_maw | compose-!-? | 11:00 |
| richard_maw | wdutch: ⸘OVER 9000‽ | 11:00 |
| ssam2 | perryl: I think add the raw data to wiki.baserock.org, but on its own page | 11:01 |
| richard_maw | wdutch: oh, and that's a tired old meme you should be ashamed of too | 11:01 |
| ssam2 | we can worry about making it more readable as a later step, and people may be interested in the raw data anyway to do their own processing of it | 11:01 |
| richard_maw | wdutch: but you know, interrobangs! | 11:01 |
| perryl | ssam2: seems reasonable, will do so! | 11:01 |
| wdutch | if only I had a compose key | 11:01 |
| nowster | wdutch: Shift-AltGr | 11:02 |
| Kinnison | nowster: that depends on the desktop environment | 11:02 |
| richard_maw | ☺ | 11:02 |
| nowster | it's common | 11:02 |
| Kinnison | it's just AltGr for me, and IIRC rjek has a real key marked 'compose' :) | 11:02 |
| * rjek does. | 11:03 | |
| nowster | I've mapped capslock to compose on this laptop | 11:03 |
| rjek | My keyboard has many surprising and unusual keys | 11:03 |
| rjek | It also has a Compose LED which I can't work out how to have X enable | 11:03 |
| richard_maw | rjek: does it have an any key? | 11:03 |
| rjek | richard_maw: It has an Again key. Does that count? | 11:04 |
| nowster | Control-Meta-CokeBottle? | 11:04 |
| petefoth | perryl: yuo could attach a plain text file to an exoisting or new wiki page | 11:04 |
| *** tiagogomes has quit IRC | 11:10 | |
| straycat | richard_maw, can haz review of https://gerrit.baserock.org/877 ? | 11:10 |
| richard_maw | ough, how did I miss that! | 11:12 |
| straycat | probably cause of some mad rush/deadline/cats falling out of the sky/etc | 11:12 |
| richard_maw | straycat: thanks, merged | 11:12 |
| *** sambishop has quit IRC | 11:13 | |
| *** sambishop has joined #baserock | 11:14 | |
| *** tiagogomes has joined #baserock | 11:21 | |
| *** nowster has quit IRC | 11:56 | |
| *** nowster has joined #baserock | 11:59 | |
| jmacs | Getting a failure to build liberasurecode, using morph or ybd | 12:31 |
| tiagogomes | same | 12:32 |
| jmacs | "This is libtool 2.4.6, but the definition of this LT_INIT comes from libtool 2.4.2" | 12:33 |
| *** CTtpollard has joined #baserock | 12:35 | |
| paulsherwood | ssam2: are you around? | 12:37 |
| tiagogomes | jmacs, this should fix it https://gerrit.baserock.org/#/c/879/ | 12:44 |
| jmacs | Thanks tiagogomes, I was digging around with the libtool-tarball changes | 12:46 |
| tiagogomes | is the baserock roadmap on the wiki? I'm a bit lost with what is going on. Should we have a baserock blog where major changes are announced? Or make a better use of news on the wiki | 12:46 |
| tiagogomes | e.g https://gerrit.baserock.org/#/c/872/, will this will remove the support for creating system branches? | 12:47 |
| petefoth | tiagogomes: there's http://wiki.baserock.org/doing-stuff-with-baserock/ which references https://storyboard.baserock.org/ and http://wiki.baserock.org/wishlist/ | 12:48 |
| jmacs | I think the mailing list is the best place for announcements like that | 12:50 |
| franred | tiagogomes, jmacs, 879 is merged | 12:51 |
| tiagogomes | I don't think that is enough | 12:51 |
| SotK | these are my draft release notes, anyone have any comments on them? http://paste.baserock.org/opamenugun | 12:51 |
| petefoth | tiagogomes: it's pretty easy to create a post that will appear in the news section on the home page | 12:51 |
| jmacs | I personally wouldn't read announcements in the 'news' section of a wiki | 12:51 |
| tiagogomes | IMO, I also think the wiki looks bad | 12:52 |
| * petefoth gives up and goes to a meeting | 12:52 | |
| * SotK thinks major changes (such as removing support for system branches) should be announced on baserock-dev | 12:52 | |
| jmacs | Thanks franred | 12:53 |
| franred | +1 to that | 12:53 |
| franred | jmacs, no probs | 12:53 |
| *** petefoth_ has joined #baserock | 12:56 | |
| *** petefoth has quit IRC | 12:56 | |
| *** petefoth_ is now known as petefoth | 12:56 | |
| ssam2 | paulsherwood: i am now | 13:03 |
| straycat | tiagogomes, that topic is aiming to remove workspace/branch/checkout/edit/foreach/... etc | 13:03 |
| straycat | (the topic that change belongs to) | 13:03 |
| tiagogomes | so you can't `morph edit chunk` anymore? | 13:04 |
| ssam2 | tiagogomes: I think of release notes as our main means of communication with the world. But agree that we could do much more to communicate plans | 13:04 |
| straycat | tiagogomes, once 872 is merged you won't be able to | 13:04 |
| straycat | but we clearly need to sort out the docs and communicate the changes before we can do that | 13:05 |
| ssam2 | indeed. we agreed to do that at the meetup we had in february, but it was a while ago and not everyone who is active here/ on baserock-dev was present | 13:05 |
| ssam2 | it's also the first item on http://wiki.baserock.org/wishlist/ | 13:06 |
| ssam2 | but again, that document isn't widely publicised | 13:06 |
| franred | also there are documentation for future changes in storyboard --> https://storyboard.baserock.org/#!/project/list | 13:07 |
| ssam2 | SotK: 'A java-build stratum was added': I think you should point out that it still requires injecting a prebuild JDK binary at build time | 13:09 |
| ssam2 | otherwise people might get excited that the Java work is totally done | 13:09 |
| SotK | makes sense | 13:09 |
| ssam2 | SotK: does binary stripping work in Morph in this release or not? I forget | 13:10 |
| ssam2 | if so, we should mention that | 13:10 |
| SotK | oh, yes it does, good spot | 13:10 |
| *** tiagogomes has quit IRC | 13:12 | |
| ssam2 | might be worth also mentioning *why* we moved the extensions: I think the reason was to decouple deployment from Morph | 13:12 |
| ssam2 | as previously, every change in interface to any deployment extension in morph.git required a new version of the definitions format, which sucked | 13:13 |
| ssam2 | the addition of /etc/inputrc is a big deal for me as well because finally now the delete key should work instead of being ~ | 13:14 |
| ssam2 | :) | 13:14 |
| ssam2 | looks fine other than that | 13:14 |
| franred | where is listed the whishlist ? I couldn't find it until ssam2 has posted here | 13:14 |
| franred | it is not in the wiki index | 13:15 |
| franred | unless Im blind | 13:15 |
| ssam2 | I don't think it's linked anywhere | 13:15 |
| franred | would be nice to have it under community | 13:15 |
| ssam2 | it was produced only by a couple of people, it's not something that reflects the wishes of everyone who contributes stuff to Baserock | 13:15 |
| *** nowster has quit IRC | 13:15 | |
| ssam2 | however, I'd be happy to adopt a version of it as the official wishlist if we consulted with the baserock-dev list first | 13:16 |
| *** nowster has joined #baserock | 13:18 | |
| franred | ssam2, I think that its content are in the same direction as what is reflected in storyboard and the baserock meeting. Im happy either ways: adopted or discussed in the mailing list | 13:18 |
| persia | I seem to recall the wishlist being brought to baserock-dev before, but I don't think we had much discussion, other than that perhaps some of it belonged in storyboard. | 13:18 |
| ssam2 | it was, I don't remember much feedback either | 13:20 |
| ssam2 | but I don't think it was presented as "this is going to be our official wishlist", either | 13:21 |
| persia | I believe it was presented as specifically not that: rather identifying the folk who wrote it, and suggesting that others consider these as potentially interesting. | 13:22 |
| persia | I suspect that it might have worked better if any of the authors had followed up more to try to make it any sort of "official" wislist, or migrate things to storyboard. | 13:22 |
| *** tiagogomes has joined #baserock | 13:25 | |
| SotK | second draft of the release notes: http://paste.baserock.org/xiqisiwala | 13:33 |
| dabukalam | persia: have you sent anything yet? | 13:34 |
| straycat | oh cool we have lm-sensors now | 13:36 |
| Zara | straycat: it doesn't include rrdtool if you need that | 13:36 |
| straycat | that's no problem :) | 13:37 |
| Zara | :) cool, we didn't think we needed it at that point. may have some notes somewhere if you need it in the future, but they're probably just 'argh x depends on y which depends on z which depends on everything ever' | 13:38 |
| straycat | SotK, worth mentioning distbuild stuff? | 13:38 |
| jmacs | This java work seems to be going round in circles | 13:39 |
| *** tiagogomes has quit IRC | 13:39 | |
| straycat | Zara, ack :) | 13:39 |
| franred | SotK, s/arping/iputils/ | 13:40 |
| SotK | straycat: sure, what distbuild stuff in particular? | 13:40 |
| straycat | iirc perryl added a lot of new functionality, distbuild-start, distbuild-cancel, distbuild-list-jobs | 13:41 |
| SotK | I think they were in the previous release | 13:41 |
| * SotK checks | 13:41 | |
| straycat | oh | 13:41 |
| perryl | yeah, they were in 15.19 IIRC | 13:41 |
| SotK | yup, the release notes for 15.19 mention them | 13:42 |
| Zara | straycat: tbf, we've still lorried it all; I just know that the prog/sensord stuff won't build without some extra rrdtool stuff. | 13:43 |
| *** tiagogomes_ has joined #baserock | 13:43 | |
| persia | jmacs: How do you mean? | 13:43 |
| straycat | ahh okay, I thought we'd created 15.19.1 for those changes but I'm mistaken | 13:45 |
| jmacs | persia: Having built gcj, it now appears that it depends on 'ecj.jar' to run, which is a compiled binary from the eclipse project | 13:47 |
| radiofree | ssam2: so about uploading those cache artifacts | 13:47 |
| persia | jmacs: My understanding was that ecj could be compiled by gcj | 13:48 |
| ssam2 | radiofree: yeah. shall I add your ssh key to git.baserock.org so you can rsync them across? | 13:48 |
| radiofree | that would be great, i'll e-mail you | 13:49 |
| radiofree | i don't need to upload the system image right? | 13:49 |
| persia | jmacs: But to be fair, I've never found a canonical location for the gcj-compilable source for ecj (although there is *a* source for this available from Debian, as part of thier bootstrap) | 13:49 |
| *** radiofree has quit IRC | 13:53 | |
| *** radiofree has joined #baserock | 13:53 | |
| ssam2 | radiofree: we usually don't upload the system image | 13:54 |
| persia | Oh, heh. This time I found it more easily: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git | 13:55 |
| persia | 3.10 (in platform 4.4) is known to build with gcj. | 13:55 |
| straycat | richard_maw, does https://gerrit.baserock.org/#/c/878/ seem a reasonable approach for that? i ask because i'd like to base other changes on that change | 13:57 |
| jmacs | I don't see how that's possible if gcj can't produce any executable without ecj in the first place | 13:57 |
| richard_maw | straycat: looking | 14:01 |
| richard_maw | straycat: I'd prefer we had different steps for switching branches and adding definitions | 14:02 |
| richard_maw | straycat: otherwise that looks fine to me | 14:02 |
| * richard_maw goes for a late lunch | 14:03 | |
| persia | jmacs: I think you only need ecj to compile to java bytecode. If you are compiling natively, I think you can skip it, so you can use gcj to compile ecj natively, and then recompile gcj with the native ecj, and use that to compile a bytecode ecj, and use that to ... | 14:03 |
| richard_maw | made a lot of progress on teasing apart some of the different parts of sourceresolver into distinct modules | 14:03 |
| straycat | okay you're referring to "GIVEN a new system... in definitions branch two" i guess | 14:04 |
| straycat | richard_maw, also cool :) | 14:04 |
| * SotK looks forward to the patch for that | 14:04 | |
| richard_maw | SotK: what do you take me for‽ It'll be a bunch of patches forming a series! | 14:05 |
| richard_maw | :þ | 14:05 |
| SotK | :D | 14:05 |
| straycat | heh | 14:05 |
| jmacs | persia: ok, might be worth a try | 14:08 |
| paulsherwood | ssam2: was wondering if you're thinking of proposing anything for ELCE? maybe on b4b, sandboxlib? | 14:09 |
| *** nowster has quit IRC | 14:11 | |
| * richard_maw translates that as "ssam2: How much would you mind proposing b4b or sandboxlib as topics for ELCE" | 14:11 | |
| straycat | I haven't really read devel-with before, it's interesting that the first step is changing into a directory that doesn't exist | 14:11 |
| *** nowster has joined #baserock | 14:11 | |
| paulsherwood | richard_maw: why do you translate it as that? | 14:13 |
| rjek | It's how I read it :) | 14:13 |
| paulsherwood | i'm asking, that's all. if i wanted to push the outcome i wouldn't do it in public on #baserock | 14:14 |
| ssam2 | paulsherwood: I've decided against it, really | 14:14 |
| ssam2 | partly due to lack of time before deadline, partly because i've never actually been to elce and don't really have an idea what it's like | 14:14 |
| paulsherwood | ah, ok. | 14:15 |
| paulsherwood | also maybe not enough to talk about yet? | 14:15 |
| ssam2 | indeed | 14:15 |
| paulsherwood | ssam2: if one of my submissions is accepted, i may mention the work in progress | 14:16 |
| ssam2 | cool | 14:17 |
| ssam2 | hopefully by October there'll be more progress, too | 14:17 |
| paulsherwood | ssam2: any ideas on how useful sandboxlib, b4b might be for automotive? i'm involved in some prep for genivi talks there too | 14:18 |
| ssam2 | hopefully by Friday there will be more progress :) | 14:18 |
| * paulsherwood crosses fingers, toes etc | 14:18 | |
| ssam2 | i'm not sure how useful sandboxlib is outside the realm of build systems | 14:18 |
| ssam2 | if you were trying to sandbox a full app, xdg-app is much more appropriate | 14:19 |
| paulsherwood | s/build systems/integration systems/ | 14:19 |
| ssam2 | ok :) | 14:19 |
| ssam2 | bit for bit reproducibility is interesting for everyone | 14:19 |
| ssam2 | well, mostly in the open source world I guess, where trusting build output is an issue | 14:20 |
| paulsherwood | do you disagree with the distinction? i think autotools, cmake are build systems? | 14:20 |
| ssam2 | i don't mind the distinction, but I think it's a bit more complex | 14:20 |
| Kinnison | I think autotools and cmake are build tooling | 14:20 |
| Kinnison | I think they operate on build systems | 14:20 |
| Kinnison | But i appreciate that the terminology is a bit fuzzy | 14:21 |
| rjek | make is a language in which one writes build systems, a Makefile is a build system? | 14:22 |
| ssam2 | paulsherwood: is there anything else around right now that you'd call an 'integration system' ? | 14:22 |
| rjek | apt? :) | 14:22 |
| rjek | (or yum, etc) | 14:22 |
| paulsherwood | no, they are packaging tools | 14:22 |
| paulsherwood | (imo) | 14:22 |
| rjek | That would be dpkg or rpm | 14:23 |
| rjek | apt and yum take a requirement and calculate how to achieve it before going ahead and doing it | 14:23 |
| paulsherwood | ok package installers, then? | 14:23 |
| rjek | Isn't ybd/morph just a build system and chunk installer? | 14:24 |
| paulsherwood | no - they can deploy sets of whole systems | 14:24 |
| Kinnison | apt and yum are more about dependency resolution and management of recommendations/suggestions, finding and preparing package transactions etc. | 14:24 |
| Kinnison | dpkg and rpm actually handle installing things | 14:24 |
| rjek | debootstrap, for example, can be given a list of pieces of software (and which versions you want, and where to get them from) and integrate them into a working system image | 14:24 |
| Kinnison | debootstrap or FAI is probably as close to an 'integration system' for debian-type stuff | 14:25 |
| paulsherwood | rjek: ok, then debootstrap does some of what i'm calling an integration system | 14:25 |
| rjek | apt and yum only really differ because they mutate an extant system | 14:25 |
| paulsherwood | but actually i think 'integration tool' may be better, since system has other connotations | 14:25 |
| ssam2 | perhaps the comparison should be more with the Debian build servers | 14:26 |
| ssam2 | they only partially integrate things, and leave the rest up to the package managers | 14:26 |
| ssam2 | package management tooling, I mean | 14:26 |
| paulsherwood | radiofree: how are you getting on with the GDP stuff? arthur seems to be struggling with the yocto instructions | 14:28 |
| straycat | richard_maw, ping | 14:30 |
| *** mdunford has quit IRC | 14:31 | |
| paulsherwood | ssam2: i notice on http://wiki.baserock.org/projects/deterministic-builds/ we've said libfaketime is a bad idea for this. is there no way we could fix libfaketime to make it a good idea? | 14:31 |
| radiofree | paulsherwood: uploading the artifacts to gbo now | 14:32 |
| radiofree | oh god x86 | 14:32 |
| paulsherwood | radiofree: you're a star :) | 14:32 |
| radiofree | x86 won't be ready today | 14:32 |
| ssam2 | paulsherwood: will it ever be a good idea to hack things into working vs. collaborating with upstreams? | 14:32 |
| radiofree | well, the definitions will be, it just won't be cache | 14:32 |
| radiofree | d | 14:32 |
| paulsherwood | ssam2: i was thinking about collaborating with libfaketime upstream | 14:32 |
| ssam2 | paulsherwood: we could work around the issue with busybox by making faketime ignore certain binaries, perhaps. So it'd then let 'make' continue to work | 14:33 |
| paulsherwood | it's unlikely we can collaborate with all the upstreams to cause them to make their stuff b4b. there's no clear benefit for them? | 14:33 |
| ssam2 | maybe not on our own | 14:33 |
| petefoth | straycat: if you follow the steps in http://wiki.baserock.org/quick-start/, specifically the 'Configure Morph' section, then the direcroy *should* exist | 14:33 |
| ssam2 | there are ~60 other people in #debian-reproducible | 14:33 |
| petefoth | *directory | 14:33 |
| paulsherwood | not even with an army. most users don't require it? | 14:33 |
| ssam2 | paulsherwood: Debian is up to 80% of packages reproducible without use of libfaketime. | 14:34 |
| ssam2 | it really seems like barking up the wrong tree | 14:34 |
| paulsherwood | by reproducible you mean b4b? | 14:35 |
| ssam2 | yeah | 14:35 |
| ssam2 | with a patched toolchain, build system etc | 14:35 |
| paulsherwood | oh, well you're right and i'm wrong then, simple as that :) | 14:35 |
| * paulsherwood would love to be right about all the things | 14:35 | |
| *** petefoth has quit IRC | 14:36 | |
| * persia reads backscroll, and has different opinons about Debian tool categorisation. | 14:36 | |
| paulsherwood | persia: please elaborate? | 14:37 |
| persia | dpkg-buildpackage (not part of dpkg) is Debian's build sytem. Arguably, sbuild is more properly that, as the build servers use sbuild. | 14:37 |
| persia | live-build is Debian's integration system. | 14:37 |
| Zara | petefoth: I'm working on making that aspect of wiki-navigation clearer, because I don't think the current order of the steps is obvious unless you happen to start on the right page. (though it's certainly better than it used to be) | 14:37 |
| persia | That said, I agree with ssam2 that due to the nature of package management, many of the details of operation of these tools are encoded in ways that are not immediatly obvious in the configuration of these tools. | 14:38 |
| * SotK wonders what tiagogomes_ meant earlier about the wiki looking bad | 14:38 | |
| straycat | Zara, are you currently editing devel-with.mdwn? | 14:39 |
| Zara | straycat: no | 14:39 |
| straycat | cool | 14:39 |
| Zara | :) | 14:39 |
| straycat | cause plain text conflicts :( | 14:39 |
| radiofree | aaah | 14:40 |
| radiofree | ignore that | 14:41 |
| paulsherwood | persia: so, i'm interested in causing our terminology to become consistent here | 14:42 |
| persia | paulsherwood: I don't believe there *can* be consistency between Debian terminology and Baserock terminology. | 14:42 |
| paulsherwood | in both ybd and morph, the code refers to 'build-systems', and those are autotools, cmake etc. | 14:42 |
| jmacs | So ecjsrc-3.8.2 requires java 1.6 to build, but gcj only provides 1.5; this is a problem I had last week with openjdk. | 14:43 |
| paulsherwood | persia: fair enough. but i'd like consistency in baserock if f possible - then we could map to others' terminologies? | 14:43 |
| persia | The main issue being that the tools that one uses in Debian to deal with defining systems, etc. are often not generalised, because almost nobody uses them. As rjek pointed out, the vast majority of folk use debootstrap to create a rootfs. | 14:43 |
| persia | The secondary issue being that the nature of packages and chunks is very intentionally semantically distinct, to the degree that by comparison to chunks, all package systems have broadly similar semantics (whereas when looking at details, there are heaps of arguments about the differences in semantics between .ebuilds, .debs, .rpms, etc.) | 14:44 |
| paulsherwood | so, back to baserock - can/should we agree that 'build system' means autotools and co, or would there be a better term? | 14:45 |
| persia | jmacs: Aha. Hrm. doko worked through it once, years ago, and since has been working off that bootstrap. I can do more archeology if we need. | 14:45 |
| persia | It may be that we need to build ancient versions of things, and then go through more bootstrap cycles than we like. | 14:45 |
| jmacs | I've been doing archeology for weeks now, hence feeling like going in circles. It doesn't seem like a problem anyone else really cares about. | 14:46 |
| *** mdunford has joined #baserock | 14:46 | |
| persia | jmacs: I think there are about three other people in the world who care, but yeah, they all already solved it, or have an environment where they can do a dirty bootstrap once, and then be clean thereafter. | 14:47 |
| paulsherwood | jmacs: that's interesting in itself, i think. go decides to bootstrap on go. why do we care, when no-one else seems to? | 14:47 |
| robtaylor | jmacs: boostrapping java? | 14:48 |
| persia | I thought Debian also cared about bootstrapping go. | 14:48 |
| jmacs | robtaylor: Yes | 14:48 |
| robtaylor | jmacs: http://layers.openembedded.org/layerindex/branch/master/layer/meta-java/ | 14:48 |
| jmacs | I think I would need to know yocto for that to be any use | 14:50 |
| * radiofree seems to spend his life rebuilding from stage1-gcc | 14:52 | |
| robtaylor | jmacs: i can talk you through it if you'd like | 14:52 |
| paulsherwood | persia: ok, us and some folks in debian and a few other folks... let me re-phrase my question.. | 14:52 |
| jmacs | robtaylor: Yes please | 14:52 |
| paulsherwood | if the few folks who care about bootstrapping stop caring about it... what will break? | 14:53 |
| paulsherwood | radiofree: poor you! | 14:54 |
| jmacs | Although maybe just the fact that it uses ecjsrc-3.6.2 might be enough | 14:55 |
| persia | paulsherwood: If we can't bootstrap, then we depend on there being a working system. This is already true, in that we don't have a means to bootstrap from pure source today. | 14:55 |
| paulsherwood | ok, but it's unlikely there will ever not be, for example, a working debian system? | 14:56 |
| persia | There are projects going on to resolve that: I think the combination of 0pf and aboriginal is probably the best start: this ought give us enough that we can then bootstrap Baserock or Debian. | 14:56 |
| ssam2 | it would mean we have to deal wit the fact that different Baserock systems have different requirements to build them from scratch. Mostly important for people who release reference systems and who cross-bootstrap to new architectures. Whether that adds up to more or less work than working out how to bootstrap Java from a C compiler, I have no idea | 14:56 |
| richard_maw | straycat: pong? | 14:57 |
| * paulsherwood googles 0pf | 14:57 | |
| persia | Depends. The classic thought experiment is someone trapped on a desert island with a CD containing lots of source code, and a computer with no software loaded. | 14:57 |
| straycat | richard_maw, hey yeah i wasn't sure exactly what change you wanted me to make to the yarn | 14:57 |
| richard_maw | oh, right | 14:57 |
| richard_maw | it was the "GIVEN a new system to build called expanded-system in new definitions branch two" I preferred to be different | 14:58 |
| richard_maw | we should have a different IMPLEMENTS for creating and changing branch, and adding the new system | 14:58 |
| straycat | hrm, well checking out isn't required here since anchor doesn't actually need a definitions repo, we just keep it around to verify that all the shas got pushed | 15:00 |
| straycat | richard_maw, nonetheless i'm happy to make that change | 15:13 |
| richard_maw | thanks straycat | 15:24 |
| *** mdunford has quit IRC | 15:28 | |
| nowster | persia: is the CD bootable? | 15:33 |
| rjek | It uses http://bellard.org/tcc/tccboot.html | 15:34 |
| SotK | last call for opinions on the release notes: http://paste.baserock.org/elovopemes | 15:35 |
| Kinnison | SotK: erm | 15:36 |
| Kinnison | * Updates to Morph, Baserock's build tool, including: | 15:36 |
| Kinnison | - Support for definitions version 4 (allow symlinks to be | 15:36 |
| Kinnison | created in install-files manifests) | 15:36 |
| rjek | Have we updated OpenSSL? | 15:36 |
| rjek | (Since the 12th of June) | 15:36 |
| Kinnison | SotK: aren't those in definition now, not morph? | 15:36 |
| Kinnison | SotK: or is this why you're doing the release? | 15:37 |
| persia | nowster: Depends on who is telling the story. Sometimes, sometimes not. When not, there is usually some other reader device that can extract the text. | 15:38 |
| rjek | (Latest OpenSSL fixes a downgrading attack) | 15:38 |
| rjek | persia: I would say that somebody stranded on a desert island probably has better things to do than build the copy of Tuxcart on the CD :) | 15:38 |
| SotK | the manifests have always been in them, but when we added the ability to create symlinks in them by modifying install-files we had to bump the definitions version, as old morph would break if it tried to use a new manifest | 15:38 |
| persia | Newer SSL also forces anyone who has been using SSL for a long time to upgrade their certificates, as it gets overexcited by false positives. | 15:38 |
| SotK | we haven't done a release since we implemented that feature, so don't actually use it in definitions master at the moment afaik | 15:39 |
| persia | rjek: Presume they have already undertaken all activities in the Mysterious Island, with the plot twist that Nero's cavern does not exist. | 15:39 |
| rjek | :) | 15:39 |
| SotK | the content of the brackets is just to explain what the "version 4" we support is for | 15:39 |
| Kinnison | SotK: my point was more -- aren't configuration extensions now in definitions and *not* in morph? | 15:40 |
| persia | Kinnison: Isn't that a version 5 thing, so that version 4 still has meaning for install-files in morph? | 15:40 |
| Kinnison | aah, if that's v5 then fine | 15:40 |
| SotK | Kinnison: yes, but I don't see how that affects the meaning of the "version 4" morph supports? | 15:40 |
| * Kinnison finds it very hard to keep track of those things, even with reference to the wikipage | 15:41 | |
| * persia rereads the release notes | 15:41 | |
| SotK | the extensions in definitions thing didn't need a version bump as it wasn't an incompatible change, it just meant that future minor changes to them also wouldn't cause compatibility issues | 15:41 |
| persia | Ah, no. Apparently deployment extensions may be in definitions *OR* morph from version 3, and I don't see any statement that they must be in definitions from some given version. | 15:41 |
| persia | Related to the topic of the version increases: I had an interesting discussion today with someone about the long-term viability of build systems. | 15:43 |
| persia | During this discussion, a team was mentioned that had given up on their build system because they were unable to backport changes for new upstream versions to their old description format. | 15:44 |
| persia | And they were unable to upgrade their tool, because so much of their work was in the old description format, making this onerous. | 15:44 |
| persia | While it seems that morph is supporting multiple definitoins versions, we should keep this story in mind when we consider how fast to change the format. | 15:45 |
| *** mdunford has joined #baserock | 15:47 | |
| SotK | I'd like opinions on how to word the "Support for definitions version 4 (...)" section of the release notes, anyone have any advice? | 15:49 |
| SotK | Kinnison pointed out that since the new behaviour (symlinks in manifests) isn't conditional on the version of the definitions file, its a feature change in morph rather than a version of the definitions format, the version bump happened because we've been using the version to protect against using old morph to build new definitions | 15:50 |
| Kinnison | Which is not what the version in definitions was meant to represent | 15:51 |
| SotK | it would be fine to put symlinks in manifests and leave the definitions version as 3 as far as new morph is concerned | 15:51 |
| * SotK has thought about having a list of "required features" or similar in definitions somewhere for changes like this | 15:52 | |
| SotK | rjek: I don't think we've updated OpenSSL, certainly I didn't notice it in the git log between my release branch and 15.19 | 15:55 |
| *** jonathanmaw has quit IRC | 15:56 | |
| franred | definitions says we are using OpenSSL_1_0_1m which is 3 months old | 15:57 |
| straycat | hi, i've got a draft for an update of the devel-with page can anyone help me proofread it? https://bitbucket.org/richardipsum/baserock-wiki/raw/45e3bbcfd42fb4ec48a577bacdab038f6c47a543/devel-with.mdwn | 15:57 |
| straycat | ssam2, Zara ^ | 15:57 |
| ssam2 | one minute, need to read release notes first | 15:58 |
| * straycat will also look at those | 15:58 | |
| ssam2 | SotK: it's not 'support for symlinks' that is the feature, it's not really a feature addition at all | 15:58 |
| * SotK gets even more confused | 15:58 | |
| ssam2 | the sole purpose of version 4 is to handle this situation: old Morph tries to build definitions that have a manifest file that overwrites a symlink | 15:59 |
| ssam2 | if we merged a patch to definitions.git that caused install-files to install a symlink over the top of an existing file, old morph would crash | 16:00 |
| ssam2 | that will make people trying to build our new definitions with old Morph very sad and confused | 16:00 |
| ssam2 | but if we increment the version of definitions to version 4 before merging that change, they will get an error saying "Your Morph is too old", instead of a crash | 16:00 |
| ssam2 | so hopefully less sad | 16:00 |
| Zara | straycat: looking now. no workspaces anymore? (was aware it was on the cards but didn't realise it was already the case) | 16:00 |
| ssam2 | SotK: I'm not sure how to express that in the release notes | 16:01 |
| SotK | Zara: they can still be used at the moment, but are being phased out | 16:01 |
| SotK | ssam2: neither am I :( | 16:01 |
| straycat | Zara, it's already the case, but you can still use workspaces if you choose, though we're clearly looking to remove them altogether | 16:01 |
| Zara | ah, okay, if they're not neccessary then that's fine. | 16:02 |
| ssam2 | how about "Support for version 4, which is used as a marker to prevent versions of Morph that do not contain the fix from http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/commit/?h=93b034f045a2c7443122d7b082ad4460339907d0 from crashing" | 16:02 |
| SotK | sounds fine to me | 16:03 |
| ssam2 | or maybe "to cause version of Morph ..... to exit with a version error, instead of crashing" | 16:03 |
| ssam2 | the way I worded it there makes it sound like it actually fixes the crash, but it just avoids it | 16:03 |
| ssam2 | with a different error | 16:03 |
| Zara | on 'deploy a raw disk image', I'd like it if 'create a cluster morphology' could be accompanied with a translation of: ('ie: make a file named foo.morph, containing the following, and put it in the clusters directory of the definitions repository)' | 16:04 |
| Zara | I know it doesn't have to be there | 16:04 |
| ssam2 | straycat: git clone git@git.baserock.org:baserock/baserock/definitions won't work I think | 16:04 |
| ssam2 | unless the reader happens to have SSH access to g.b.o | 16:05 |
| ssam2 | git://git.baserock.org/.. would be better | 16:05 |
| straycat | oops | 16:05 |
| Zara | but as a newcomer a phrase like 'create a cluster morphology' would confuse me, because I'd assume it was way more complicated than it is | 16:05 |
| straycat | yes it was quite stupid of me to use the ssh url, thanks | 16:05 |
| ssam2 | I agree it would be nice to avoid using the term 'cluster morphology', but that's kind of a separate task | 16:06 |
| ssam2 | I prefer 'deployment .morph file', but opinions vary :) | 16:06 |
| Zara | I'm just trying to spot things that have changed from the old page; I put a little translation up on the old one so I'd like an equivalent. :P | 16:08 |
| ssam2 | the new 'add something to Baserock' raises the question of what to do if it's not something present in git.baserock.org | 16:08 |
| * bashrc thinks of cluster computing | 16:08 | |
| ssam2 | mentioning how to build from file:/// URLs would be good as well, although maybe it doesn't need to be on that page | 16:09 |
| SotK | any more comments on the release notes? http://paste.baserock.org/ijulogufav | 16:09 |
| ssam2 | beyond that, looks fine at a glance. thanks for doing it | 16:09 |
| franred | ssam2, also you can build from any git repository | 16:09 |
| straycat | yeah i'm not sure, i mentioned aliases but didn't really explain it further, should probably link to somewhere that explains the repo aliases in more detail | 16:09 |
| ssam2 | Sotk: 'Support for version 4' -> 'Support for definitions version 4' | 16:10 |
| ssam2 | SotK: i haven't spotted anything else | 16:10 |
| SotK | oops, good spot | 16:10 |
| SotK | I'll send them in 5 minutes unless there are further objections from anyone then :) | 16:11 |
| straycat | they look fine to me | 16:11 |
| ssam2 | What are people's thoughts on having rough-n-ready versioned documentation on wiki.baserock.org ? | 16:11 |
| ssam2 | by which I mean, move some subset of the pages into a 15.19/ folder, so people using 15.19 can continue to refer to them | 16:12 |
| * straycat was thinking that might be a good idea | 16:12 | |
| * SotK would be fine with that | 16:12 | |
| ssam2 | cool. I'm not sure which pages matter yet, will have a look | 16:12 |
| straycat | at the very least I was thinking we could copy the existing devel-with page and link to it from the new one | 16:12 |
| jmacs | I'm mildly concerned that that will break search even more | 16:13 |
| straycat | but doing it for a number of pages would probably be better, especially since i imagine i'll also need to update at least quick-start | 16:13 |
| Zara | how come the informal definitions spec and the build-failures links have been removed? | 16:13 |
| ssam2 | jmacs: hmm, very good point | 16:13 |
| ssam2 | jmacs: another alternative is move them somewhere else | 16:14 |
| SotK | It would be cool if branchable had a way to view different branches of the repo | 16:14 |
| SotK | like MUSTARD had | 16:14 |
| straycat | yes it would | 16:14 |
| ssam2 | what about setting up a separate branchable wiki for 'stable' docs? | 16:18 |
| ssam2 | have spoke to our sponsors who are OK with doing this | 16:18 |
| SotK | +1 from me | 16:18 |
| jmacs | If it were me making the changes I'd just write separate instructions for older versions on the same page, as we do now | 16:19 |
| ssam2 | my thinking is that we have a customer using docs from the wiki | 16:19 |
| Zara | jmacs: I think the pages could get long fast. | 16:19 |
| Zara | +1 for stable docs | 16:19 |
| SotK | jmacs: I worry that would get very confusing after a while | 16:20 |
| * SotK sends the release notes | 16:20 | |
| jmacs | I can only think of OpenStack that does that; most other projects don't need such complicated documentation | 16:20 |
| straycat | I also think having 2 versions for every use case will be pretty cluttered | 16:20 |
| jmacs | straycat: You will always have 2 version for every use case | 16:21 |
| ssam2 | with a separate wiki, the old versions can be left alone pretty safely | 16:22 |
| ssam2 | if it's in the same wiki there'll be an ongoing cognitive load to maintain the two separate versions, even though 1 version doesn't actually need to change | 16:22 |
| franred | or we can create a file with old documentation and attach to the wiki as a link? | 16:23 |
| straycat | I think I'm in favour of a separate wiki, I'm not sure I understand exactly the setup ssam2 has in mind for this though | 16:23 |
| jmacs | I might agree to a frozen copy of the wiki for old version | 16:23 |
| jmacs | versions | 16:23 |
| jmacs | As long as it's very obvious in the instructions that the people may need to check archived versions | 16:23 |
| straycat | I guess, just a 15.25 wiki and a stable wiki? | 16:24 |
| Zara | could make a wiki for each release, but that's prrrrrobably overkill. | 16:24 |
| Zara | (if you preserved them all, anyway :P) | 16:24 |
| franred | s/wiki/document/ | 16:24 |
| *** petefoth has joined #baserock | 16:25 | |
| Zara | is there a way of seeing the whole wiki as it was in some point in time? | 16:27 |
| *** a1exhughe5 has quit IRC | 16:28 | |
| ssam2 | I was imagining a separate wiki called baserock-stable.branchable.com with the whole contents of the current wiki copied to it, to begin with | 16:28 |
| Zara | if so, then maybe we could just have different versions point to different times. | 16:28 |
| jmacs | Other than cloning it with git, checking out an old revision and reading the .mdwn, not that I can think of | 16:28 |
| mwilliams_ct | Django do that nicely - https://docs.djangoproject.com/en/1.7/intro/tutorial01/ is an example, in the bottom right you can choose the version you're working with | 16:28 |
| ssam2 | later (or hopefully, at the same time) we could get cleverer and (a) remove stuff that it doesn't make sense to archive (stuff that isn't documentation) and (b) add version directories | 16:28 |
| SotK | mwilliams_ct: that is similar to what I was thinking of when mentioning what MUSTARD had | 16:29 |
| ssam2 | mwilliams_ct: I think Django do this by generating all their documentation using Sphinx from files in the django.git repo, then rendering it all as HTML at release time and uploading it to docs.djangoproject.com in a new folder | 16:29 |
| ssam2 | and it'd be great if someone fancies doing that for the Baserock documentation, but I'm not going to volunteer | 16:30 |
| mwilliams_ct | ssam2: sure, didn't mean to suggest it was easy or even appropriate, but thought a quick look at how another project do it might be handy | 16:30 |
| ssam2 | the way they do it is good, indeed | 16:30 |
| mwilliams_ct | most importantly, big difference between a wiki and static html documentation | 16:31 |
| straycat | It's cool but I don't think there's an immediate need for it, this is arguably the largest ui change we've had, and I don't *think* we anticipate any similar large ui changes? | 16:31 |
| jmacs | mwilliams_ct: No 'edit' button? :) | 16:31 |
| straycat | at least not in the near future | 16:31 |
| * SotK updates the wiki, and with that... | 16:31 | |
| SotK | Baserock 15.25 is released! | 16:32 |
| ssam2 | hooray! | 16:32 |
| jmacs | \o/ | 16:32 |
| perryl | \o/ | 16:32 |
| ssam2 | i'll mail baserock-dev about this wiki thing, in fact | 16:32 |
| straycat | awesome :) | 16:32 |
| straycat | (both the release and the email about the wiki) | 16:32 |
| franred | congrats SotK !! | 16:32 |
| straycat | so much awesome :) | 16:32 |
| Zara | would it be possible to clone it, tag retrospectively and rebase, then use some mechanism to let a reader view all pages on a specific git tag? | 16:33 |
| SotK | I don't know if branchable can do that | 16:33 |
| Zara | seems like it would be a simple (albeit probably a bit inaccurate) way to do it if it can. | 16:37 |
| * SotK runs away for the night before anyone finds problems in the release :) | 16:37 | |
| Zara | heh, 'night | 16:37 |
| straycat | o/ | 16:37 |
| jmacs | gcj seems to be asking for ecj1 no matter how I invoke it | 16:38 |
| *** rdale has joined #baserock | 16:43 | |
| *** dabukalam_ has joined #baserock | 16:44 | |
| *** rdale_ has quit IRC | 16:45 | |
| *** dabukalam has quit IRC | 16:45 | |
| ssam2 | Zara: I don't think branchable has a way to view anything other than 'master' | 16:48 |
| ssam2 | otherwise, we probably could do something like that, instead of having a separate wiki | 16:48 |
| Zara | wah :( how hard and/or time-consuming would it be to give branchable that functionality? | 16:49 |
| ssam2 | branchable is a commercial company, so it might not even be possible | 16:51 |
| ssam2 | they are quite friendy, so maybe it would be :) | 16:51 |
| ssam2 | and it is based around ikiwiki, which is open source | 16:52 |
| ssam2 | but also written in Perl | 16:52 |
| Zara | ah, okay. I started looking at ikiwiki plugins, in case there was something useful there, but there are a lot... http://ikiwiki.info/plugins/ | 16:53 |
| Zara | so might look in more detail tomorrow | 16:53 |
| ssam2 | it may be that Kinnison or cttpollard arrive tomorrow and point out there is a much easier way of doing this :) | 16:56 |
| Zara | heh :) | 16:57 |
| *** mariaderidder has quit IRC | 17:01 | |
| *** bashrc has quit IRC | 17:02 | |
| *** ssam2 has quit IRC | 17:10 | |
| CTtpollard | Zara: what exactly are you looking at trying to do | 17:13 |
| robtaylor | jmacs: http://archive.eclipse.org/eclipse/downloads/drops/R-3.6.2-201102101200/ecj-3.6.2.jar | 17:16 |
| persia | robtaylor: That doesn't solve the problem: it's still a blob. | 17:22 |
| persia | I was hoping that there was a way to compile gcj that didn't need ecj to build ecj-native: such a gcj would be *incapable* of producing Java bytecode. | 17:23 |
| *** mdunford has quit IRC | 17:23 | |
| persia | And then using that to stumble forward. | 17:23 |
| persia | One of the things that is different in Baserock than package-based environments is that we want to be able to bootstrap from raw source from an arbitrary system, whereas in a package environment, once you upload the dirty object, you can use that to build successively cleaner ones until you are comfy. | 17:24 |
| persia | In Baserock, you have to presume the cache was wiped, so there are *no* blobs available. | 17:24 |
| robtaylor | persia: not going to happen, i'm afraid | 17:24 |
| robtaylor | persia: we'll have to mirror a bottom-of-the-stack jar or two into | 17:25 |
| robtaylor | - there is no javac you can build with c alone | 17:25 |
| persia | In that case, perhaps the right answer is to do something like I did for fpc (which is impossible to bootstrap with open code), where we have instructions to perform the bootstrap committed to git, so that the human doesn't need to do anything. | 17:25 |
| robtaylor | persia: no human needed, we'll just mirror the jar(s) | 17:26 |
| robtaylor | and then rebuild those components from current source later down the build tree | 17:26 |
| persia | Treat the blobs as source? | 17:27 |
| robtaylor | persia: yep | 17:27 |
| robtaylor | otherwise you'd be trying to http get during build time.. | 17:27 |
| robtaylor | - note it's all open, so not quite the same situation as fpc | 17:28 |
| persia | The way I did it for fpc was to have code that performed the mirror be committed to git, so that someone bootstrapping it could say "do the bootstrap" and work around things. | 17:28 |
| persia | I suppose stuffing the blob into git isn't much worse than that, but somehow it seems wrong. | 17:28 |
| robtaylor | well ideally we'd have lorry do it | 17:29 |
| robtaylor | but its somewhat unecessary as it'd never change (e.g. itd always be ecj-3.6.2.jar with md5sum ....) | 17:30 |
| persia | fpc is now, and has always been, open source. It self-hosts fine. It just can't be built without either a blob or by building an ancient copy with an out-of-print ancient proprietary solution. | 17:30 |
| persia | tarball lorries don't change anyway. Nothing like debian/watch exists (to the best of my knowledge) | 17:30 |
| robtaylor | good point | 17:30 |
| robtaylor | can lorry lorry just a file and not try to extract it? | 17:31 |
| persia | I believe that would need another lorry type, but it ought be trivial to enable a "file" lorry type, based on tarball, but with 99% of the logic removed. | 17:31 |
| *** edcragg has quit IRC | 17:39 | |
| *** bwh has quit IRC | 18:00 | |
| *** benbrown_ has joined #baserock | 18:22 | |
| straycat | hello benbrown_ | 18:22 |
| * benbrown_ has a tail. | 18:23 | |
| straycat | :) | 18:24 |
| *** paulsherwood has quit IRC | 18:31 | |
| *** perryl has quit IRC | 18:31 | |
| *** SotK has quit IRC | 18:31 | |
| *** Zara has quit IRC | 18:31 | |
| *** petefoth1ringham has quit IRC | 18:31 | |
| *** benbrown_ has quit IRC | 18:31 | |
| *** mwilliams_ct has quit IRC | 18:31 | |
| *** pdar has quit IRC | 18:31 | |
| *** jmacs has quit IRC | 18:31 | |
| *** kejiahu_ has quit IRC | 18:31 | |
| *** DavePage has quit IRC | 18:31 | |
| *** sebh has quit IRC | 18:31 | |
| *** bwh has joined #baserock | 18:32 | |
| *** petefotheringham has joined #baserock | 18:32 | |
| *** sebh has joined #baserock | 18:33 | |
| *** gary_perkins has quit IRC | 18:34 | |
| *** gary_perkins has joined #baserock | 18:34 | |
| *** lachlanmackenzie has quit IRC | 18:35 | |
| *** gary_perkins has quit IRC | 18:37 | |
| *** gary_perkins has joined #baserock | 18:38 | |
| *** lachlanmackenzie has joined #baserock | 18:41 | |
| *** lachlanmackenzie has quit IRC | 18:47 | |
| *** bwh has quit IRC | 18:47 | |
| *** zoli__ has quit IRC | 19:14 | |
| *** gary_perkins has quit IRC | 20:13 | |
| *** zoli__ has joined #baserock | 20:16 | |
| *** edcragg has joined #baserock | 20:19 | |
| *** zoli__ has quit IRC | 20:56 | |
| *** zoli__ has joined #baserock | 21:00 | |
| * richard_maw grumps | 21:36 | |
| richard_maw | My https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/morph+branch:master+topic:sourceresolver-objects rework looks great, except for the fact that the memoise is the wrong idea, since I need to cache by something derived from the input, rather than the input itself | 21:37 |
| * richard_maw pre-emptively -1s the offending change | 21:38 | |
| *** mwilliams_ct has joined #baserock | 21:44 | |
| *** edcragg has quit IRC | 22:02 | |
| *** zoli__ has quit IRC | 22:20 | |
| *** zoli__ has joined #baserock | 22:33 | |
| *** edcragg has joined #baserock | 23:15 | |
| *** edcragg has quit IRC | 23:31 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!