IRC logs for #baserock for Thursday, 2017-04-06

*** rdale has quit IRC00:55
*** gtristan has joined #baserock06:08
*** jude_ has joined #baserock06:59
*** paulwaters_ has joined #baserock07:16
*** ctbruce has joined #baserock07:32
*** paulwaters_ has quit IRC07:40
*** ctbruce has quit IRC07:52
*** noisecell has joined #baserock07:56
*** paulwaters_ has joined #baserock08:11
*** rdale has joined #baserock08:35
*** jonathanmaw has joined #baserock09:01
jonathanmawpaulsherwood, jjardon: can either of you review please?09:11
* benbrown_ resolves comment09:18
*** ssam2 has joined #baserock09:29
*** ChanServ sets mode: +v ssam209:29
*** locallycompact has joined #baserock09:36
*** CTtpollard has quit IRC09:53
*** noisecell has quit IRC10:05
*** CTtpollard has joined #baserock10:06
*** noisecell has joined #baserock10:13
*** ssam2 has quit IRC10:45
*** ssam2 has joined #baserock11:00
*** ChanServ sets mode: +v ssam211:00
ironfootbuildstream is here! \o/11:08
* rjek wonders why the file extension is .bst11:11
ironfootbecause .bs sounds a bit like another thing11:11
tiagogomesoh, the old argument of generic .yml versus custom extensions11:11
ssam2because we're in british summer time rjek11:12
rjekExtensions are not limited to three characters11:16
chrispolinWould someone running the baserock-dev mailing list mind taking a look at why I can't subscribe? It's telling me 'you must supply a valid email address', it apparently doesn't like my codethink address.11:16
rjek.yaml, .jpeg, .midi etc are all preferable to their normal three-character contractions.  We're not using DOS.11:16
rjekchrispolin: That would be me.  Hmm.11:17
gtristanMorning :)11:17
rjekchrispolin: I just managed to do it for you with no problem11:17
gtristanI'm glad that we've started the conversation with the most important topic, the filename extension !11:17
* rjek can't try it because it needs pip11:18
chrispolinNot sure what the story was there rjek, cheers.11:18
gtristanrjek, it doesnt really need pip, but that is what was recommended to me to avoid ever requiring root11:18
gtristanrjek, the pip incantation describes installs everything in local user directory11:18
rjekYeah, but I have a pip ban11:19
gtristanWell then... ./ develop11:19
gtristanwill do it11:19
rjekCan it not just run from a checkout?11:19
gtristanIt probably can, if you install the other deps11:20
gtristanpsutil, ruamel.yaml, pluginbase, Click and blessings are the pythonic deps11:20
gtristanbut no actually you cant11:21
gtristanBecause it'll use the entry point11:21
gtristanrjek, use ./, that's what it's for11:21
rjekpluginbase doesn't appear to be packaged in Debian :-/11:21 is usually for scattering detritus all over my file system :)11:22
gtristanThat's why I recommend `pip install --user -e .`11:22
gtristanIt will do everything in ~/.local/lib/python3.511:23
rjekThat just scatters it over my home directory instead11:23
gtristanYou can safely nuke it, though11:23
rjekOnly if this is the only tool I ever make an exception for11:23
benbrown_rjek: virtualenv?11:24
* rjek doesn't understand why Python programs so rarely just run from a checkout11:25
rjekvirtualenv might be a solution11:25
gtristanrjek, C programs usually don't, either.11:25
rjekC programs, IME, usually do11:25
rjekEven if they're autotooled up to the hilt11:26
ironfootchrispolin: can you /msg me your email address and I will try to subscribe you?11:27
rjekironfoot: I did it for him :)11:27
chrispolinCheers ironfoot, rjek sorted it for me.11:27
ironfootrjek: oh, I searched for him in the subscribers list, but didn't find anythinig11:28
gtristanrjek, PYTHONPATH=`pwd`/install/lib/python3.5/site-packages/ ./ install --prefix=`pwd`/install11:46
gtristanrjek, PYTHONPATH=`pwd`/install/lib/python3.5/site-packages/ ./install/bin/bst11:46
chrispolingtristan, quick update: build failed with this error message:
gtristaneeesh this looks familiar13:32
gtristanchrispolin, did you apply the hack/patch I sent you, I think it was against ?13:33
chrispolinI did, yep.13:34
gtristanWhat you are seeing I believe is because of the usr/ merge13:34
chrispolinI've been scanning back through the mailing list to find out what that is lol.13:34
gtristanAnd ldconfig not existing at sbin/ldconfig13:34
gtristanbut only existing at usr/sbin/ldconfig13:34
gtristanchrispolin, oh I see, this is at system creation time :-/13:56
gtristanSo... what is up with that then13:56
gtristanah yes13:57
gtristanchrispolin, when you do `ls /root/ybd/tmp/tmp4FIQJJ/gnome-system-x86_64.inst/` is there even an sbin/ symlink ?13:58
chrispolinI tried that earlier, no such file or directory.13:58
gtristanis there an sbin symlink ?13:58
gtristansbin -> usr/sbin13:58
gtristanSo then that must be what messed up14:00
gtristanchrispolin, and you _do_ have this applied right ?14:02
gtristanthat's confusing14:02
gtristani.e., what I pasted at
gtristanthe alternative is to try random, re-launch ybd a bunch of times until fhs-dirs is staged first and the symlink gets a chance to be created14:04
chrispolinYep, definitely applied.14:05
chrispolinI've launched it a few times as per your comment before that patch, but it seems to fail at the same point each time.14:05
gtristanyeah if you have the patch, shouldnt need to do that14:05
chrispolinI figured as much.14:05
gtristanok so... in your glibc artifact, what does that look like14:06
gtristanI have /store/BASEROCK/build/artifacts/glibc.2239407db84999e7fecbc94114f45435166f5ef32a59b9df25de46357a0c4be6/glibc.2239407db84999e7fecbc94114f45435166f5ef32a59b9df25de46357a0c4be6.unpacked/sbin/ldconfig14:06
gtristanSo that will get staged into the system... and then I expect at this stage what's happening, is it's moving files from /root/ybd/tmp/tmp4FIQJJ/gnome-system-x86_64.inst/ -> smth else, after integration14:08
gtristanor, hmmm strange, maybe it's moving things from /root/ybd/tmp/tmp4FIQJJ/ -> /root/ybd/tmp/tmp4FIQJJ/gnome-system-x86_64.inst/14:09
gtristanthat makes more sense14:09
gtristanchrispolin, can you paste the build log ?14:09
chrispolinYep, 2 secs.14:12
* gtristan must have encountered that error :-S14:21
gtristandoesnt really make sense14:21
gtristanchrispolin, I suppose that /root/ybd/tmp/tmp4FIQJJ/gnome-system-x86_64.inst/ does not have any sbin/ in it at all ?14:21
gtristanchrispolin, ok let me explain what is happening here first, I think we can just repeat the same hack (in a different place) to get it to pass, but still curious that it didnt work14:22
gtristanwhat's happening is, first, all the files from the artifacts where staged into /root/ybd/tmp/tmp4FIQJJ/14:23
gtristanthen, the system integration commands run14:23
gtristanAnd finally, the manifests of each individual artifact was consulted, to move files from /root/ybd/tmp/tmp4FIQJJ/ -> /root/ybd/tmp/tmp4FIQJJ/gnome-system-x86_64.inst/14:23
gtristanAt that stage, is called with a specific list of files14:24
gtristannow, in _process_list() the _copy_directories() is supposed to take care of creating the leading directories to the file it wants to copy14:24
gtristanso sbin/ *should* be errnonously created as a directory instead of a symlink14:25
chrispolinahhh, hold on. Yes, it is there.14:25
gtristanthe error you're getting, *should* be because the sbin directory is missing14:25
gtristanotherwise, I dont see why it would say "No such file or directory"14:26
ironfootbroken symlink?14:26
chrispolinIt's empty, there's no ldconfig in it.14:26
ironfootisn't sbin supposed to point to usr/bin?14:26
gtristanisnt it supposed to point to usr/sbin ?14:27
ironfoot(or that's the implementation that was done in baserock)14:27
gtristanironfoot, ?14:27
ironfootdon't blame me!14:27
ironfooti can find logs of me asking the same question14:27
gtristanironfoot, usr/sbin or usr/bin ?14:27
ironfooteverything in usr/bin14:27
ironfoothang on14:28
ironfootbut that would mean that /usr/sbin would point to /usr/bin14:28
gtristanah you're right14:28
ironfoot(this may not be the problem, but just in case it saves some time)14:28
gtristanI missed that with my patch14:29
gtristanmy "hack" patch14:29
gtristanthis still doesnt explain it though14:29
gtristanif /root/ybd/tmp/tmp4FIQJJ/gnome-system-x86_64.inst/sbin exists as a directory, there's no reason why _copyfun()'s open() would raise that exception :-S14:30
* gtristan is amazed that this builds, at all, for anyone14:31
*** jude_ has quit IRC14:33
chrispolingtristan, hold up. the symlink is there. I was looking for the tmp* for an earlier build.14:42
gtristanchrispolin, and it points to a directory that exists ?14:44
chrispolingnome-system-x86_64.inst/sbin -> usr/bin14:44
chrispolinAh. No.14:44
chrispolinNo /bin in /usr. Just /include.14:44
gtristanthis is supposed to take care of that:
chrispolinQuick sanity check, the symlink is referring to gnome-system-x86_64.inst/usr/bin, yes?14:49
gtristanchrispolin, it should be14:50
chrispolinand not /usr/bin14:51
gtristanof course not :)14:52
gtristanchrispolin, I added the relative symlink insurance to to make damn sure you never try to write to your host14:52
gtristanwhich, was actually happening14:52
gtristanbut anyway, fhs-dirs creates it as -> usr/bin, not /usr/bin14:53
* gtristan has to leave the midnight closing coffee shop right now :-S14:57
chrispolinMm. No sign of it in there.14:58
*** gtristan has quit IRC15:08
*** jude_ has joined #baserock15:25
*** gtristan has joined #baserock15:33
*** locallycompact has quit IRC15:46
*** jonathanmaw has quit IRC16:29
*** paulwaters_ has joined #baserock16:35
*** locallycompact has joined #baserock16:43
*** locallycompact has quit IRC17:16
*** ssam2 has quit IRC17:20
*** jude_ has quit IRC17:24
*** locallycompact has joined #baserock17:43
*** jude_ has joined #baserock17:59
*** noisecell has quit IRC18:30
*** rdale has quit IRC18:50
*** locallycompact has quit IRC18:53
*** locallycompact has joined #baserock18:53
*** paulwaters_ has joined #baserock19:26
*** paulwaters_ has quit IRC19:28
*** locallycompact has quit IRC21:15

Generated by 2.15.3 by Marius Gedminas - find it at!