*** gary_per- has joined #baserock | 05:13 | |
*** gary_perkins has quit IRC | 05:14 | |
*** gary_per- is now known as gary_perkins | 05:14 | |
*** gtristan has quit IRC | 05:31 | |
*** gtristan has joined #baserock | 05:42 | |
*** gtristan has quit IRC | 07:37 | |
*** paulwaters_ has joined #baserock | 07:42 | |
*** rdale has joined #baserock | 08:00 | |
*** gtristan has joined #baserock | 08:15 | |
*** jonathanmaw has joined #baserock | 08:37 | |
gtristan | Anyone booted any baserock system built of late ? | 08:39 |
---|---|---|
* gtristan finds that the initramfs fails to start systemd | 08:40 | |
gtristan | because of weird symlinkage | 08:40 |
paulsherwood | ooh... | 08:40 |
gtristan | tries /sbin/init, which is actually located at /usr/sbin/init (/sbin being -> usr/sbin) | 08:41 |
gtristan | /usr/sbin/init is -> ../../lib/systemd/systemd or such | 08:41 |
gtristan | and no such file or directory | 08:41 |
paulsherwood | http://imgur.com/a/ALuyS | 08:42 |
paulsherwood | is your problem anythign like that? | 08:42 |
gtristan | nope, dont get that far | 08:43 |
paulsherwood | :/ | 08:43 |
* gtristan can force it with kernel append in writeexts.py | 08:44 | |
paulsherwood | in answer to your original question... since i switched to my current laptop, that's what happens with baserock images for me | 08:44 |
* gtristan already had to modify writeexts.py again to use a built btrfs/extlinux | 08:44 | |
gtristan | btw I found the issue for building stage1-gcc on morern hosts | 08:46 |
gtristan | it's this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959 | 08:46 |
gtristan | stage1-gcc.morph: CXX="g++ -std=gnu++98" ./configure ... <-- fixes that | 08:46 |
paulsherwood | w00t! :) | 08:47 |
gtristan | paulsherwood, I *think* that may have been the issue we were talking about a while ago, where changing runners broke things | 08:47 |
gtristan | this https://gitlab.com/baserock/ybd/issues/257 is really a mess though :-/ | 08:48 |
gtristan | I dont think fixing it would be easy, but better to know what's happening | 08:49 |
paulsherwood | :/ | 08:49 |
gtristan | I wonder if the issue you have booting might have to do with that, it may be random what gets staged in /usr/bin and what gets staged in /bin | 08:49 |
paulsherwood | is it clear what should be the canonical order for moving over the artifacts? | 08:50 |
gtristan | yes | 08:51 |
gtristan | order of dependency | 08:51 |
gtristan | and then something deterministic | 08:51 |
gtristan | could be alphabetic, but at least consistent | 08:52 |
gtristan | paulsherwood, as I mentioned in the last notes... this could be an error in the /usr merge | 08:52 |
gtristan | if all chunks in build-essential stage 3 dont explicitly depend on fhs-dirs stage3, then all bets are off | 08:52 |
gtristan | because the symlinks need to be created before anything else is staged | 08:53 |
gtristan | hmm | 08:55 |
gtristan | ok well, enough with that test | 08:56 |
gtristan | after setting init=/usr/lib/systemd/systemd on kernel command line, I boot to gdm | 08:56 |
gtristan | and then nothing happens | 08:56 |
gtristan | no graphical environment | 08:57 |
* gtristan can safely just say that "we have regressed" | 08:57 | |
gtristan | since last year | 08:57 |
ironfoot | :/ | 08:58 |
paulsherwood | :/ | 09:00 |
* gtristan tries to build a conversion of last year's known working system, but with recently manually converted build-essential (including /usr merge) not sure it will work | 09:00 | |
gtristan | but I'm hopeful | 09:00 |
ironfoot | well, if the /usr merge messed up the systemd symlinking, that bit may still be broken | 09:00 |
ironfoot | but gdm might work | 09:00 |
gtristan | ironfoot, right, I already work around that by specifying the systemd binary in syslinux.conf | 09:01 |
ironfoot | yup yup | 09:01 |
gtristan | strange though, I think the symlinks are correct, does this mean it's possible to setup correct symlinks which make some pathnames unreachable ? | 09:02 |
*** brlogger has joined #baserock | 09:06 | |
SotK | ideally there should be some way to automate checking if things boot | 09:09 |
gtristan | SotK, ironfoot mentioned that the other day too, but before that happens, in the absence of that, we should still be more strict about ensuring the end result works | 09:09 |
ironfoot | of course we don't have to test all the systems | 09:10 |
ironfoot | but also define what systems we have to test | 09:10 |
* SotK assumes that could be sensibly defined as "the contents of ci.morph" | 09:10 | |
gtristan | nod | 09:11 |
paulsherwood | imo this is only feasible with an automated smoke test | 09:11 |
SotK | paulsherwood: +1 | 09:11 |
ironfoot | (ci.morph was kind of deprecated, and now .gitlab-ci is the one) | 09:11 |
gtristan | ironfoot, this situation will also be improved by splitting up the definitions into something more modular of course | 09:11 |
SotK | the other alternative is to make reviewers obliged to test builds of a bunch of stuff | 09:11 |
SotK | which is highly annoying for reviewers | 09:12 |
SotK | and was part of the reason I always wanted CI so much when I was more active here | 09:12 |
gtristan | I.e. then you have the maintainer of the GNOME system *pull* a new core with new systemd and /usr merge, and report bugs back to core maintainers, but not blindly accepting these changes downstream | 09:12 |
gtristan | The onus can fall on the reviewer/maintainer but it can also fall on the patch submitter | 09:13 |
gtristan | if you're making patches to definitions, and you're not building locally and booting vms *already*, then... what *are* you doing anyway ? | 09:14 |
SotK | equally, that makes it frustrating to send a patch | 09:14 |
SotK | since we will likely need more than one system to be tested | 09:14 |
paulsherwood | iiuc the gap is that we need a ci step that can deploy a built system, cause the deployed system to boot, and check some things | 09:14 |
gtristan | Yes, as I said, ironfoot brought that up the other day | 09:15 |
SotK | paulsherwood: indeed | 09:15 |
gtristan | I'm talking about being responsible, in the _absense_ of that | 09:15 |
gtristan | sure, it would be great if we had greater things | 09:15 |
paulsherwood | gtristan: ack | 09:15 |
*** ssam2 has joined #baserock | 09:15 | |
*** ChanServ sets mode: +v ssam2 | 09:15 | |
ironfoot | gtristan: ++ | 09:16 |
*** richard_maw has joined #baserock | 09:17 | |
*** richard_maw has left #baserock | 09:17 | |
*** noisecell has joined #baserock | 09:23 | |
*** locallycompact has quit IRC | 09:27 | |
*** paulwaters_ has joined #baserock | 09:28 | |
jonathanmaw | jjardon, paulsherwood: can either of you review https://gitlab.com/baserock/ybd/merge_requests/334 please? | 09:35 |
*** chrispolin- has joined #baserock | 09:35 | |
jjardon | jonathanmaw please create a branch in our project downstream using the contents of that MR, so we can test before merge | 09:42 |
paulsherwood | jjardon: for 334 shall i 'merge when pipeline succeeds'? | 09:48 |
jjardon | paulsherwood: upstream pipeline doesn't test the rpm creation, so I think it would be better if we can test it in our downstream pipeline as well | 09:56 |
paulsherwood | ok | 09:57 |
*** locallycompact has joined #baserock | 09:58 | |
*** locallycompact has quit IRC | 10:01 | |
*** locallycompact has joined #baserock | 10:01 | |
*** locallycompact has quit IRC | 10:03 | |
*** locallycompact has joined #baserock | 10:03 | |
benbrown_ | jonathanmaw, jjardon: could I get a review of https://gitlab.com/baserock/ybd/merge_requests/331 please | 14:19 |
* jonathanmaw has a gander | 14:19 | |
jjardon | benbrown_: looks good to me | 14:21 |
benbrown_ | thanks guys :) | 14:23 |
*** gtristan has quit IRC | 15:09 | |
*** noisecell has quit IRC | 15:25 | |
*** gtristan has joined #baserock | 15:33 | |
*** ssam2 has quit IRC | 16:15 | |
*** jude has quit IRC | 16:27 | |
*** jonathanmaw has quit IRC | 17:05 | |
*** locallycompact has quit IRC | 17:21 | |
*** paulwaters_ has joined #baserock | 17:42 | |
*** paulwaters_ has quit IRC | 17:44 | |
*** locallycompact has joined #baserock | 19:36 | |
*** rdale has quit IRC | 19:50 | |
*** locallycompact has quit IRC | 23:26 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!