IRC logs for #baserock for Monday, 2016-02-22

*** edcragg has quit IRC01:21
*** gtristan has quit IRC05:11
*** gtristan has joined #baserock05:23
*** toscalix has joined #baserock08:06
*** CTtpollard has joined #baserock08:12
*** edcragg has joined #baserock08:19
*** rdale has joined #baserock08:23
*** fay_ is now known as faybrocklebank08:29
*** bashrc has joined #baserock08:55
*** ctbruce has joined #baserock09:14
*** franred has joined #baserock09:24
*** edcragg has quit IRC09:42
*** tiagogomes_ has joined #baserock09:43
*** jonathanmaw has joined #baserock09:47
*** edcragg has joined #baserock09:57
*** ssam2 has joined #baserock10:04
*** ChanServ sets mode: +v ssam210:04
*** Lachlan1975 has joined #baserock10:28
*** gtristan has quit IRC10:30
*** Lachlan1975 has quit IRC10:38
*** Lachlan1975 has joined #baserock10:53
*** gtristan has joined #baserock11:03
richard_mawit's possible to nix the bug where strings are interpreted as numbers by hooking into the YAML parser a bit more cleverly, since we can instruct it to load different object paths differently, even returning a proper object rather than a dict11:18
*** wdutch has quit IRC11:40
*** locallycompact has joined #baserock11:43
*** wdutch has joined #baserock11:53
*** rdale has quit IRC12:21
*** rdale has joined #baserock12:22
*** toscalix has quit IRC12:47
*** toscalix_ has joined #baserock12:47
*** gtristan has quit IRC13:46
*** gtristan has joined #baserock13:52
gary_perkinsArrggh! I'm stuck! :( I've rebuilt the trove system and updated the trove server. Rebooted into the new system, only for it to stop just after init starts because it wants to go into single user mode. There are no useful error messages and the journal contains nothing! Has anyone seen this before?13:59
persiagary_perkins: Did you mount /, or are you still in the initrd?14:02
gary_perkinspersia: / has mounted, the only error is a no such file when it looked for /etc/init.d/rcS14:03
* persia hasn't seen that before14:04
gary_perkinsthere is no /proc14:04
persiaMy experience is limited to bouncing to single-user before the pivot.14:05
ssam2it does seem like it's using the wrong 'init'14:08
ssam2I can't imagine systemd giving that error14:08
gary_perkinsinit started: BusyBox v1.23.1 ()14:08
gary_perkinscan't run '/etc/init.d/rcS': No such file or directory14:08
gary_perkinsPlease press Enter to activate this console.14:08
gary_perkins^^ is what I get14:09
ssam2right. So it is indeed the wrong 'init'14:09
ssam2not sure how that could happen14:09
gary_perkinsssam2: can I select the right init?14:09
ssam2systemd /sbin/init should overwrite busybox /sbin/init14:11
ssam2hmm.. did you use ybd or Morph ?14:11
gary_perkinsI'll try morph14:11
ssam2ah. I think YBD is installing chunks in the wrong order14:11
ssam2Morph installs chunks in a set order, which means that when two chunks install the same file, the later one overrides the earlier one14:12
paulsherwooderk... order should not matter, imo :/14:12
ssam2it's a bit of a hack that the reference systems rely on this to work, but it's not simple to fix, either14:12
ssam2paulsherwood: I agree in principle, but i don't have any idea on how to get there14:12
gary_perkinsok, thx. Worth a try14:12
paulsherwoodfix the overlaps :)14:13
ssam2paulsherwood: be my guest14:13
ssam2start with stage2-gcc vs. gcc, perhaps. We'd need a way to say "stop installing stage2-gcc once you have built gcc"14:13
rdalewe would need to have two variants of build-essential - one that installs bash/system etc in the final phase, and another that installs busy box instead14:14
ssam2yes, variants would solve the problem for the case of busybox init vs. systemd14:14
ssam2Morph used to warn on overlaps, but I think that got removed at some piont14:15
rdalei suppose you could do some artifact splitting rules in the final system to pick up one or the other14:15
persiaThat would be the ideal solution: sufficiently split artifacts to not need to install any files twice, and an error condition if a file is reinstalled.14:21
*** rdale has quit IRC14:25
*** rdale has joined #baserock14:29
ssam2I had an idea for another solution: disallow overlaps, unless the definitions explicitly specify an order15:00
ssam2e.g. ordering: [busybox-bins, systemd-bins] to say that we prefer systemd over busybox15:01
ssam2splitting rules would be a better solution, but i don't know how I'd implement that15:01
persiaThe main reason I favour splitting rules is from a history of working with debian-format tooling, where one had to intentiontionally declare conflicts or the system wouldn't work: that feature, while annoying when integrating a new component, helped me more times than I can count to be confident of what I had installed on a system.15:03
*** ctbruce has quit IRC15:10
*** ctbruce has joined #baserock15:11
paulsherwoodso the current splitting-rules syntax doesn't provide for a solution to this?15:12
ssam2i think it does, if you can be bothered to use it15:13
ssam2but it's rather a pain to use in my experience15:13
paulsherwoodi haven't even been able to comprehend it so far, never mind use it :)15:14
paulsherwoodwin /3515:14
rdaleyou would need to define names for the split components in systemd, bash and busy box instead of using the default names like busybox-bins and then specify two different sets of components in a system according to whether you wanted to use busy box or bash/systemd15:15
paulsherwoodis busybox *required* in trove? if not, why is it there?15:16
persiabusybox is in most things, largely because of the time before we had replacements for the tools in definitions.  Even where there are replacements used in systems, the replacements are often not complete.15:21
pedroalvarezI was going to say, that this problem might not be trove specific15:22
paulsherwoodi expect this problem is more general, but i was hoping for a shortcut for gary_perkins' trove issue15:24
gary_perkinspaulsherwood: I'm afraid I've resorted to morph for now :(15:26
paulsherwoodheh ;)15:26
pedroalvarezI'm not assuming yet that morph won't have that issue though15:26
paulsherwoodwell, i don't think trove definitions have changed, nor morph, to the extent that the problem would surface?15:27
pedroalvarezIt might be something else, related to the current state of that specific trove..15:28
pedroalvarezbut I don't know really :/15:29
paulsherwoodis there a *reason* that build-essential is present in example systems, rather than just a build-depend for the systems?15:41
rdaleit has the gcc and glibc runtimes in it15:42
rdaleso you need build-essential-minimal in order to run anything in a built system15:43
pedroalvarezoh! I might look into not including everything in baseline systems :)15:44
pedroalvarezhehe, so build-essentials also has some runtime-essentials :P15:44
paulsherwoodso specifying build-essential-minimal might fix the trove issue?15:44
rdaleyes, if it isn't a development system15:45
ssam2i would strongly recommend adding some overlaps checks into YBD too15:45
ssam2there might be other cases like this that could ruin someone else's day in future15:45
pedroalvarezI agree15:45
rdaleactually i think build-essential-minimal will still include a busy box init15:51
pedroalvarezoh yes, it should15:51
rdaleso we might want a different split version of build-essential that excluded busybox15:54
gary_perkins\o/ trove has been upgraded! "Linux trove 4.4.0+ #1 SMP Sat Feb 20 01:45:01 UTC 2016 x86_64 GNU/Linux"16:02
paulsherwoodgary_perkins: w00t :)16:02
gary_perkinsone snag was the upgrade wrote a new fstab which tried to mount /home as a btrfs subvolume16:02
gary_perkinswhere I normally have /home as an ext416:03
rjekgary_perkins: strings /lib/x86_64-linux-gnu/|grep "^GNU C Library"16:04
rjek(Change path as appropriate :)16:04
pedroalvarezgary_perkins: oh, I missed the FSTAB bit of your trove configuration16:05
pedroalvarezbut anyway, now that you have done it manually, you shouldn't have more problems in future upgrades16:05
gary_perkinsrjek: version 2.2216:06
pedroalvarez`grep '\"\(sha1\|repo\|original_ref\)\":' /baserock/glibc-bins.meta`16:07
gary_perkinspedroalvarez: "original_ref": "b995d95a5943785be3ab862b2d3276f3b4a22481", "repo": "git://", "sha1": "b995d95a5943785be3ab862b2d3276f3b4a22481",16:08
pedroalvarezhehe, more baserocky  output16:09
pedroalvarezpaulsherwood: might be interesting for you: 4vcpu 8G ram17:06
pedroalvarez2016-02-22 12:56:47 Started building WebKitGtk on ct187-mason:343417:06
pedroalvarez2016-02-22 15:04:01 Finished building WebKitGtk on ct187-mason:343417:06
*** ctbruce has quit IRC17:17
*** franred has quit IRC17:40
locallycompactpaulsherwood, is there a way I can upload things to the baserock/ namespace on dockerhub17:41
*** toscalix_ has quit IRC17:51
*** jonathanmaw has quit IRC18:03
*** ssam2 has quit IRC18:06
*** bashrc has quit IRC18:06
paulsherwoodi'll check18:09
*** locallycompact has quit IRC18:27
*** edcragg has quit IRC18:41
paulsherwoodpedroalvarez: do you think that would be enough information for tracing overlaps in systems?18:52
pedroalvarezthat's nice18:56
paulsherwoodtvm :)18:57
pedroalvarezhaha, I'd love to see all the overlaps of system18:57
persiaWould it be possible to get the full path?18:57
pedroalvarezthey are going to be a lot of them18:57
persiaFor some systems, there are many files with the same name, but different paths, etc.  Knowing which can be tricky.18:58
pedroalvarezIt's useful information18:59
paulsherwood ?18:59
pedroalvareznot sure if the tmpdir path is good in this context19:00
persiaThat's lovely.  Extra points for stripping the prefix, but at least one can easily find the right file.19:00
* paulsherwood => dinner19:00
* pedroalvarez -> home 19:00
persiaAm I interpreting it correctly that these files overlap pre-existing files?  Is there any way to find the chunk that provided the original file?19:00
* persia waits for tomorrow for an answer, and wishes everyone a good night.19:00
pedroalvarezmetadata files should have information about that19:01
pedroalvarezI'm not sure it will be easy/efficient would be to check that in the build tool19:02
*** Lachlan1975 has quit IRC19:24
*** persia has quit IRC20:19
*** persia has joined #baserock20:19
*** persia has quit IRC20:20
*** _longines has quit IRC20:20
*** juergbi has quit IRC20:21
*** juergbi has joined #baserock20:21
*** _longines has joined #baserock20:22
*** persia has joined #baserock20:22
*** cosm has joined #baserock21:08
*** toscalix has joined #baserock21:09
*** toscalix has quit IRC21:09

Generated by 2.15.3 by Marius Gedminas - find it at!