| *** cosm has joined #baserock | 01:17 | |
| *** gtristan has joined #baserock | 06:52 | |
| *** gtristan has quit IRC | 06:58 | |
| *** gtristan has joined #baserock | 07:08 | |
| paulsherwood | gtristan: should i be trying/merging your ybd fork? | 09:10 |
|---|---|---|
| gtristan | paulsherwood, would be great if someone tried it ! | 09:12 |
| gtristan | merging is another story | 09:12 |
| gtristan | its not ready for merging :) | 09:12 |
| paulsherwood | gtristan: 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 |
| gtristan | Certainly not | 09:14 |
| gtristan | https://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2016-March/013492.html | 09:14 |
| gtristan | at the bottom of that mail has HOWTO | 09:14 |
| gtristan | which shows how it can be used, first you need an aboriginal build of the arch you try building | 09:14 |
| gtristan | armv5l is what I've been working with, I suspect mips might work, or armv6l, armv4l | 09:15 |
| paulsherwood | i understand, but what i mean is... can't the aboriginal flow be optional? | 09:15 |
| gtristan | Eh, it's not as it stands | 09:16 |
| paulsherwood | in which case i could merge it as experimental, so long as current workflows are unaffected | 09:16 |
| gtristan | and would probably be a maintenance burden in the long run to support that | 09:16 |
| gtristan | it completely replaces sandbox.py implementation details and removes the sandboxlib dependency | 09:16 |
| paulsherwood | i'll take a look, there *must* be a way... it's only sw :) | 09:16 |
| paulsherwood | ack... introducing several new dependencies, or just one? | 09:17 |
| gtristan | there is certainly a way... but when we successfully complete the cycle, I dont think it makes sense to support both, really | 09:17 |
| paulsherwood | i agree | 09:17 |
| gtristan | introducing only the dependency on the aboriginal stuff (2 currently, 1 which should eventually be eaten up but ybd) | 09:18 |
| gtristan | i.e. the aboriginal-controller repository is probably destined to be eaten up by ybd | 09:18 |
| gtristan | oh well, I guess that also introduces the dependency on qemu | 09:18 |
| paulsherwood | ack. i'll take a look into the code | 09:19 |
| * gtristan has been wondering if it would be feasible to build qemu as a part of the aboriginal build | 09:19 | |
| * paulsherwood has been wondering if it would be possible to build the aboriginal build as part of definitions :) | 09:19 | |
| gtristan | Yeah, that too | 09:20 |
| paulsherwood | definitions all the way down :) | 09:20 |
| gtristan | Well | 09:20 |
| gtristan | When I met with robtaylor ... we talked about that, there are 2 sides of that coin | 09:20 |
| gtristan | one is... it would be nice to have definitions all the way down, sure | 09:20 |
| gtristan | other is, ... it would be nice to collaborate with Rob and gain momentum for both projects | 09:21 |
| gtristan | so, it would be nice to mold the aboriginal build scripts into something we could build as a part of definitions | 09:21 |
| gtristan | without completely changing it | 09:21 |
| paulsherwood | ack | 09:22 |
| gtristan | a patch for upstream might look like... a way to override what downloads.sh downloads: https://github.com/gtristan/aboriginal/blob/master/download.sh | 09:23 |
| gtristan | so that we could run the build using stuff exclusively from the trove | 09:23 |
| paulsherwood | ack. his downloads are configured releases, i guess, not from mainlines? | 09:24 |
| gtristan | That's something we'll never be able to work around, we will never be building those packages from git, I think | 09:24 |
| gtristan | because they become the root of all evil, they are below build essential, at a time where we do not require autotools | 09:25 |
| paulsherwood | never say never :) | 09:25 |
| gtristan | Right, "bad idea" is more appropriate | 09:25 |
| paulsherwood | do you know much about alex's build tool? i don't even know what it's *called* | 09:25 |
| gtristan | keeping those dependencies, which are currently a low denominator of host shell/cc/ld etc... has value | 09:26 |
| gtristan | because it means the whole thing is more easily repeatable from scratch in 10 years | 09:26 |
| gtristan | xdg-app-builder ? | 09:26 |
| paulsherwood | i agree with keeping those dependencies.. but we can still put them in git as foo-tarball | 09:27 |
| gtristan | I see what you mean yeah | 09:28 |
| gtristan | well, 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 downloads.sh script to just shutup and do nothing, it would work | 09:30 |
| gtristan | eh, we'd need just a switch to disable the downloading/patching | 09:30 |
| gtristan | so parted wants perl >= 5.6 | 09:33 |
| gtristan | we have perl 5.22 | 09:33 |
| gtristan | and parted bails out, complaining that "perl version 5 is not new enough, we want 5.6" | 09:33 |
| gtristan | perl --version... which bootstrap checks... says: | 09:34 |
| gtristan | This is perl 5, version 22, subversion 0 (v5.22.0) built for armv5tejl-linux | 09:34 |
| gtristan | Has this come up before ? | 09:34 |
| gtristan | what does perl --version say in *your* build sandbox ? | 09:35 |
| * gtristan stares blankly at the crowd | 09:35 | |
| gtristan | ;-) | 09:35 |
| paulsherwood | sorry... my daughter is telling me how the world works | 09:36 |
| gtristan | Ah :) | 09:36 |
| paulsherwood | gtristan: you want me to get into asandbox and run perl --version? | 09:37 |
| gtristan | paulsherwood, if you can easily do that, it might shed some light on why parted does not detect the version correctly | 09:37 |
| gtristan | assuming yours says something drastically different from mine :-/ | 09:38 |
| gtristan | this is get_version() | 09:39 |
| gtristan | http://paste.baserock.org/iyelitopel | 09:39 |
| * gtristan runs it in steps and tries to figure where the regex goes wrong | 09:40 | |
| paulsherwood | This is perl 5, version 22, subversion 0 (v5.22.0) built for x86_64-linux | 09:46 |
| paulsherwood | (with 1 registered patch, see perl -V for more detail) | 09:46 |
| paulsherwood | http://paste.baserock.org/howufuseku | 09:47 |
| paulsherwood | gtristan: ^^ | 09:47 |
| gtristan | Yeah... looks about right... on my host it seems to get it right | 09:47 |
| gtristan | get_version() extracts 5.20.2 for: http://paste.baserock.org/cajoqijuso | 09:48 |
| gtristan | but it extracts 5 for: http://paste.baserock.org/jexacawojo | 09:49 |
| gtristan | eek, changing the host triple in perl --version output corrects it | 09:51 |
| paulsherwood | that sounds like a bug, somewhere | 09:53 |
| gtristan | in bootstrap | 09:53 |
| gtristan | First part of the sed | 09:53 |
| gtristan | "Move version to start of line" | 09:54 |
| gtristan | it takes "version string ...armv5tejl-linux"... and... and it transforms it to: 5tejl-linux | 09:54 |
| gtristan | it looks for v[0-9]... and finds the v in armv5 | 09:55 |
| paulsherwood | aha | 09:55 |
| paulsherwood | tricky little beggars, these regexes | 09:55 |
| gtristan | anyone ever built parted for armv7lhf ? know what the perl --version is for armv7lhf ? | 09:56 |
| paulsherwood | you mean, which version of perl *we* build on the way to an armv7lhf system? | 09:59 |
| gtristan | I mean, what is the output of perl --version on an armv7lhf system we built ;-) | 09:59 |
| paulsherwood | ybd-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 |
| paulsherwood | i don't have a build arm machine handy, sadly | 10:00 |
| * gtristan seds out perl from bootstrap.conf for now | 10:04 | |
| gtristan | oh | 10:08 |
| gtristan | paulsherwood, obvious | 10:08 |
| gtristan | there is no problem building parted on armv7lhf | 10:09 |
| gtristan | because perl 7 is >= perl 5.6 | 10:09 |
| gtristan | bootstrap just thinks it's perl 7 | 10:09 |
| gtristan | Just because... this is a regular expression | 10:11 |
| gtristan | and because this specifically relates to *perl*s version string | 10:11 |
| gtristan | I feel obligated to plug: http://www.schnada.de/grapt/eriknaggum-perlrant.html | 10:12 |
| gtristan | The famous perl rant ! | 10:12 |
| * gtristan really enjoys this rant | 10:12 | |
| paulsherwood | :-) | 10:21 |
| paulsherwood | wow... there's some deep psychology in that, actually | 10:25 |
| gtristan | yeah, it's a great piece of writing really | 10:33 |
| * paulsherwood wonders what happened to cause lunar to drop out of reproducible-builds | 10:48 | |
| *** cosm has quit IRC | 12:39 | |
| * gtristan is up to compiling both gtk+'s | 13:24 | |
| gtristan | [12/189/435] of gnome.morph | 13:25 |
| *** gtristan has quit IRC | 13:54 | |
| paulsherwood | wow... getting there :) | 14:03 |
| *** gtristan has joined #baserock | 14:18 | |
| paulsherwood | hmmm evolution not building in master? http://paste.baserock.org/loqunuwexu | 14:23 |
| jjardon | paulsherwood: I will take a look | 14:28 |
| paulsherwood | jjardon: do you know much about xdg-app-builder? | 14:29 |
| paulsherwood | i guess it's intended *only* for xdg-app, given the code is inside it/ | 14:29 |
| jjardon | paulsherwood: nope, it's used to build the runtimes/sdk's as well | 14:31 |
| * jjardon grabs his laptop | 14:31 | |
| paulsherwood | is there any documentation for it? it's a long time since i parsed any c | 14:31 |
| paulsherwood | nm... i've found some | 14:33 |
| jjardon | paulsherwood: for example: https://cgit.freedesktop.org/xdg-app/freedesktop-sdk-images/tree/Makefile#n3 | 14:47 |
| jjardon | (they use a yocto image to generate the base system though: https://cgit.freedesktop.org/xdg-app/freedesktop-sdk-base/) | 14:48 |
| jjardon | paulsherwood: some docs: https://wiki.gnome.org/Projects/SandboxedApps and alexl blog post series are useful too: https://blogs.gnome.org/alexl/2016/02/26/building-an-xdg-app-part-5/ | 14:50 |
| *** cosm has joined #baserock | 15:03 | |
| paulsherwood | ack | 15:16 |
| paulsherwood | jjardon: why not just use pre-configure-commands instead of your new boostrap-commands ? | 15:16 |
| jjardon | paulsherwood: 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 ./autogen.sh or bootstrap commands (prepare the module to be able to compile it) is conceptually different from what you do in configure-commands (configure the module | 15:21 |
| jjardon | with the options I need/want) | 15:21 |
| paulsherwood | iiuce we have pre-configure-commands, configure-commands, post-configure-commands already | 15:24 |
| paulsherwood | so i'm suggesting use pre-configure-commands for your bootstrap things | 15:26 |
| jjardon | FYI, 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 conversation | 15:26 |
| paulsherwood | if that's the case, then fine | 15:26 |
| jjardon | paulsherwood: https://gerrit.baserock.org/#/c/820/ | 15:27 |
| paulsherwood | https://gerrit.baserock.org/#/c/2007/ | 17:26 |
| paulsherwood | https://gerrit.baserock.org/#/c/2008/ | 17:26 |
| paulsherwood | jjardon: ^^ | 17:26 |
| pedroalvarez | Patches for morph to support all that welcome | 18:38 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!