IRC logs for #baserock for Tuesday, 2017-04-04

*** gary_per- has joined #baserock05:13
*** gary_perkins has quit IRC05:14
*** gary_per- is now known as gary_perkins05:14
*** gtristan has quit IRC05:31
*** gtristan has joined #baserock05:42
*** gtristan has quit IRC07:37
*** paulwaters_ has joined #baserock07:42
*** rdale has joined #baserock08:00
*** gtristan has joined #baserock08:15
*** jonathanmaw has joined #baserock08:37
gtristanAnyone booted any baserock system built of late ?08:39
* gtristan finds that the initramfs fails to start systemd08:40
gtristanbecause of weird symlinkage08:40
paulsherwoodooh...08:40
gtristantries /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 such08:41
gtristanand no such file or directory08:41
paulsherwoodhttp://imgur.com/a/ALuyS08:42
paulsherwoodis your problem anythign like that?08:42
gtristannope, dont get that far08:43
paulsherwood:/08:43
* gtristan can force it with kernel append in writeexts.py08:44
paulsherwoodin answer to your original question... since i switched to my current laptop, that's what happens with baserock images for me08:44
* gtristan already had to modify writeexts.py again to use a built btrfs/extlinux08:44
gtristanbtw I found the issue for building stage1-gcc on morern hosts08:46
gtristanit's this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6995908:46
gtristanstage1-gcc.morph: CXX="g++ -std=gnu++98" ./configure ... <-- fixes that08:46
paulsherwoodw00t! :)08:47
gtristanpaulsherwood, I *think* that may have been the issue we were talking about a while ago, where changing runners broke things08:47
gtristanthis https://gitlab.com/baserock/ybd/issues/257 is really a mess though :-/08:48
gtristanI dont think fixing it would be easy, but better to know what's happening08:49
paulsherwood:/08:49
gtristanI 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 /bin08:49
paulsherwoodis it clear what should be the canonical order for moving over the artifacts?08:50
gtristanyes08:51
gtristanorder of dependency08:51
gtristanand then something deterministic08:51
gtristancould be alphabetic, but at least consistent08:52
gtristanpaulsherwood, as I mentioned in the last notes... this could be an error in the /usr merge08:52
gtristanif all chunks in build-essential stage 3 dont explicitly depend on fhs-dirs stage3, then all bets are off08:52
gtristanbecause the symlinks need to be created before anything else is staged08:53
gtristanhmm08:55
gtristanok well, enough with that test08:56
gtristanafter setting init=/usr/lib/systemd/systemd on kernel command line, I boot to gdm08:56
gtristanand then nothing happens08:56
gtristanno graphical environment08:57
* gtristan can safely just say that "we have regressed"08:57
gtristansince last year08: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 work09:00
gtristanbut I'm hopeful09:00
ironfootwell, if the /usr merge messed up the systemd symlinking, that bit may still be broken09:00
ironfootbut gdm might work09:00
gtristanironfoot, right, I already work around that by specifying the systemd binary in syslinux.conf09:01
ironfootyup yup09:01
gtristanstrange 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 #baserock09:06
SotKideally there should be some way to automate checking if things boot09:09
gtristanSotK, 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 works09:09
ironfootof course we don't have to test all the systems09:10
ironfootbut also define what systems we have to test09:10
* SotK assumes that could be sensibly defined as "the contents of ci.morph"09:10
gtristannod09:11
paulsherwoodimo this is only feasible with an automated smoke test09:11
SotKpaulsherwood: +109:11
ironfoot(ci.morph was kind of deprecated, and now .gitlab-ci is the one)09:11
gtristanironfoot, this situation will also be improved by splitting up the definitions into something more modular of course09:11
SotKthe other alternative is to make reviewers obliged to test builds of a bunch of stuff09:11
SotKwhich is highly annoying for reviewers09:12
SotKand was part of the reason I always wanted CI so much when I was more active here09:12
gtristanI.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 downstream09:12
gtristanThe onus can fall on the reviewer/maintainer but it can also fall on the patch submitter09:13
gtristanif you're making patches to definitions, and you're not building locally and booting vms *already*, then... what *are* you doing anyway ?09:14
SotKequally, that makes it frustrating to send a patch09:14
SotKsince we will likely need more than one system to be tested09:14
paulsherwoodiiuc the gap is that we need a ci step that can deploy a built system, cause the deployed system to boot, and check some things09:14
gtristanYes, as I said, ironfoot brought that up the other day09:15
SotKpaulsherwood: indeed09:15
gtristanI'm talking about being responsible, in the _absense_ of that09:15
gtristansure, it would be great if we had greater things09:15
paulsherwoodgtristan: ack09:15
*** ssam2 has joined #baserock09:15
*** ChanServ sets mode: +v ssam209:15
ironfootgtristan: ++09:16
*** richard_maw has joined #baserock09:17
*** richard_maw has left #baserock09:17
*** noisecell has joined #baserock09:23
*** locallycompact has quit IRC09:27
*** paulwaters_ has joined #baserock09:28
jonathanmawjjardon, paulsherwood: can either of you review https://gitlab.com/baserock/ybd/merge_requests/334 please?09:35
*** chrispolin- has joined #baserock09:35
jjardonjonathanmaw please create a branch in our project downstream using the contents of that MR, so we can test before merge09:42
paulsherwoodjjardon: for 334 shall i 'merge when pipeline succeeds'?09:48
jjardonpaulsherwood: 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 well09:56
paulsherwoodok09:57
*** locallycompact has joined #baserock09:58
*** locallycompact has quit IRC10:01
*** locallycompact has joined #baserock10:01
*** locallycompact has quit IRC10:03
*** locallycompact has joined #baserock10:03
benbrown_jonathanmaw, jjardon: could I get a review of https://gitlab.com/baserock/ybd/merge_requests/331 please14:19
* jonathanmaw has a gander14:19
jjardonbenbrown_: looks good to me14:21
benbrown_thanks guys :)14:23
*** gtristan has quit IRC15:09
*** noisecell has quit IRC15:25
*** gtristan has joined #baserock15:33
*** ssam2 has quit IRC16:15
*** jude has quit IRC16:27
*** jonathanmaw has quit IRC17:05
*** locallycompact has quit IRC17:21
*** paulwaters_ has joined #baserock17:42
*** paulwaters_ has quit IRC17:44
*** locallycompact has joined #baserock19:36
*** rdale has quit IRC19:50
*** locallycompact has quit IRC23:26

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