IRC logs for #baserock for Saturday, 2016-03-19

*** cosm has joined #baserock01:17
*** gtristan has joined #baserock06:52
*** gtristan has quit IRC06:58
*** gtristan has joined #baserock07:08
paulsherwoodgtristan: should i be trying/merging your ybd fork?09:10
gtristanpaulsherwood, would be great if someone tried it !09:12
gtristanmerging is another story09:12
gtristanits not ready for merging :)09:12
paulsherwoodgtristan: if i merge, and run the result in my normal way on ci.morph, will it work?09:13
paulsherwood(not your revised definitions, master)09:13
gtristanCertainly not09:14
gtristanat the bottom of that mail has HOWTO09:14
gtristanwhich shows how it can be used, first you need an aboriginal build of the arch you try building09:14
gtristanarmv5l is what I've been working with, I suspect mips might work, or armv6l, armv4l09:15
paulsherwoodi understand, but what i mean is... can't the aboriginal flow be optional?09:15
gtristanEh, it's not as it stands09:16
paulsherwoodin which case i could merge it as experimental, so long as current workflows are unaffected09:16
gtristanand would probably be a maintenance burden in the long run to support that09:16
gtristanit completely replaces implementation details and removes the sandboxlib dependency09:16
paulsherwoodi'll take a look, there *must* be a way... it's only sw :)09:16
paulsherwoodack... introducing several new dependencies, or just one?09:17
gtristanthere is certainly a way... but when we successfully complete the cycle, I dont think it makes sense to support both, really09:17
paulsherwoodi agree09:17
gtristanintroducing only the dependency on the aboriginal stuff (2 currently, 1 which should eventually be eaten up but ybd)09:18
gtristani.e. the aboriginal-controller repository is probably destined to be eaten up by ybd09:18
gtristanoh well, I guess that also introduces the dependency on qemu09:18
paulsherwoodack. i'll take a look into the code09:19
* gtristan has been wondering if it would be feasible to build qemu as a part of the aboriginal build09:19
* paulsherwood has been wondering if it would be possible to build the aboriginal build as part of definitions :)09:19
gtristanYeah, that too09:20
paulsherwooddefinitions all the way down :)09:20
gtristanWhen I met with robtaylor ... we talked about that, there are 2 sides of that coin09:20
gtristanone is... it would be nice to have definitions all the way down, sure09:20
gtristanother is, ... it would be nice to collaborate with Rob and gain momentum for both projects09:21
gtristanso, it would be nice to mold the aboriginal build scripts into something we could build as a part of definitions09:21
gtristanwithout completely changing it09:21
gtristana patch for upstream might look like... a way to override what downloads:
gtristanso that we could run the build using stuff exclusively from the trove09:23
paulsherwoodack. his downloads are configured releases, i guess, not from mainlines?09:24
gtristanThat's something we'll never be able to work around, we will never be building those packages from git, I think09:24
gtristanbecause they become the root of all evil, they are below build essential, at a time where we do not require autotools09:25
paulsherwoodnever say never :)09:25
gtristanRight, "bad idea" is more appropriate09:25
paulsherwooddo you know much about alex's build tool? i don't even know what it's *called*09:25
gtristankeeping those dependencies, which are currently a low denominator of host shell/cc/ld etc... has value09:26
gtristanbecause it means the whole thing is more easily repeatable from scratch in 10 years09:26
gtristanxdg-app-builder ?09:26
paulsherwoodi agree with keeping those dependencies.. but we can still put them in git as foo-tarball09:27
gtristanI see what you mean yeah09:28
gtristanwell, the way the upstream scripts work, there is the tarballs packages/ dir and there is the sources/patches directories... the output of which is build/packages... I think maybe without modifying anything, if we had foo-tarball stuff staged in build/packages, and told the script to just shutup and do nothing, it would work09:30
gtristaneh, we'd need just a switch to disable the downloading/patching09:30
gtristanso parted wants perl >= 5.609:33
gtristanwe have perl 5.2209:33
gtristanand parted bails out, complaining that "perl version 5 is not new enough, we want 5.6"09:33
gtristanperl --version... which bootstrap checks... says:09:34
gtristanThis is perl 5, version 22, subversion 0 (v5.22.0) built for armv5tejl-linux09:34
gtristanHas this come up before ?09:34
gtristanwhat does perl --version say in *your* build sandbox ?09:35
* gtristan stares blankly at the crowd09:35
paulsherwoodsorry... my daughter is telling me how the world works09:36
gtristanAh :)09:36
paulsherwoodgtristan: you want me to get into asandbox and run perl --version?09:37
gtristanpaulsherwood, if you can easily do that, it might shed some light on why parted does not detect the version correctly09:37
gtristanassuming yours says something drastically different from mine :-/09:38
gtristanthis is get_version()09:39
* gtristan runs it in steps and tries to figure where the regex goes wrong09:40
paulsherwoodThis is perl 5, version 22, subversion 0 (v5.22.0) built for x86_64-linux09:46
paulsherwood(with 1 registered patch, see perl -V for more detail)09:46
paulsherwoodgtristan: ^^09:47
gtristanYeah... looks about right... on my host it seems to get it right09:47
gtristanget_version() extracts 5.20.2 for:
gtristanbut it extracts 5 for:
gtristaneek, changing the host triple in perl --version output corrects it09:51
paulsherwoodthat sounds like a bug, somewhere09:53
gtristanin bootstrap09:53
gtristanFirst part of the sed09:53
gtristan"Move version to start of line"09:54
gtristanit takes "version string ...armv5tejl-linux"... and... and it transforms it to: 5tejl-linux09:54
gtristanit looks for v[0-9]... and finds the v in armv509:55
paulsherwoodtricky little beggars, these regexes09:55
gtristananyone ever built parted for armv7lhf ? know what the perl --version is for armv7lhf ?09:56
paulsherwoodyou mean, which version of perl *we* build on the way to an armv7lhf system?09:59
gtristanI mean, what is the output of perl --version on an armv7lhf system we built ;-)09:59
paulsherwoodybd-build-jetson.log:15-08-31 14:12:44 [29/282/282] [perl] Upstream version 70f63a4c v5.22.0 (v5.22.0 + 0 commits)10:00
paulsherwoodi don't have a build arm machine handy, sadly10:00
* gtristan seds out perl from bootstrap.conf for now10:04
gtristanpaulsherwood, obvious10:08
gtristanthere is no problem building parted on armv7lhf10:09
gtristanbecause perl 7 is >= perl 5.610:09
gtristanbootstrap just thinks it's perl 710:09
gtristanJust because... this is a regular expression10:11
gtristanand because this specifically relates to *perl*s version string10:11
gtristanI feel obligated to plug:
gtristanThe famous perl rant !10:12
* gtristan really enjoys this rant10:12
paulsherwoodwow... there's some deep psychology in that, actually10:25
gtristanyeah, it's a great piece of writing really10:33
* paulsherwood wonders what happened to cause lunar to drop out of reproducible-builds10:48
*** cosm has quit IRC12:39
* gtristan is up to compiling both gtk+'s13:24
gtristan [12/189/435] of gnome.morph13:25
*** gtristan has quit IRC13:54
paulsherwoodwow... getting there :)14:03
*** gtristan has joined #baserock14:18
paulsherwoodhmmm evolution not building in master?
jjardonpaulsherwood: I will take a look14:28
paulsherwoodjjardon: do you know much about xdg-app-builder?14:29
paulsherwoodi guess it's intended *only* for xdg-app, given the code is inside it/14:29
jjardonpaulsherwood: nope, it's used to build the runtimes/sdk's as well14:31
* jjardon grabs his laptop14:31
paulsherwoodis there any documentation for it? it's a long time since i parsed any c14:31
paulsherwoodnm... i've found some14:33
jjardonpaulsherwood: for example:
jjardon(they use a yocto image to generate the base system though:
jjardonpaulsherwood: some docs: and alexl blog post series are useful too:
*** cosm has joined #baserock15:03
paulsherwoodjjardon: why not just use pre-configure-commands instead of your new boostrap-commands ?15:16
jjardonpaulsherwood: we are doing that for some modules but I think is kind of a hack: we still running "bootstrap" commands by default in configure-commands, and I think what happen when you running ./ or bootstrap commands (prepare the module to be able to compile it) is conceptually different from what you do in configure-commands (configure the module15:21
jjardonwith the options I need/want)15:21
paulsherwoodiiuce we have pre-configure-commands, configure-commands, post-configure-commands already15:24
paulsherwoodso i'm suggesting use pre-configure-commands for your bootstrap things15:26
jjardonFYI, I have tried to use pre-configure-commands for this but people didnt like the idea (and the idea was to proposse another build step), let me find the conversation15:26
paulsherwoodif that's the case, then fine15:26
paulsherwoodjjardon: ^^17:26
pedroalvarezPatches for morph to support all that welcome18:38

Generated by 2.15.3 by Marius Gedminas - find it at!