*** fay_ [~fay@82-68-191-81.dsl.posilan.com] has joined #baserock | 06:47 | |
*** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has joined #baserock | 07:51 | |
*** ssam2 [~ssam2@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:20 | |
*** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:20 | |
robtaylor | jjardon: can't wait to see it :) | 09:34 |
---|---|---|
richard_maw | jjardon: -E isn't in the version of sed I have on my Debian Laptop, what does it do? | 09:35 |
ssam2 | Kinnison: is there some way I can report a bug in Gitano? | 10:11 |
ssam2 | I'm going through an old list of customer issues and have one that doesn't really belong there | 10:12 |
ssam2 | I could put it on our internal gitlab instance issues, if that's preferred | 10:12 |
ssam2 | the bug in question is that the 'copy' command copies the 'owner' field instead of setting it to the user who did the copy, which means you can create a repo with 'gitano copy' that you are then not permitted to delete | 10:13 |
* persia thought it was "mail the gitano list", but also suspects that if the person highlighted doesn't answer soon, someone else in #gitano may have a better answer. | 10:20 | |
Kinnison | ssam2: Reporting in #gitano and/or on gitano-dev@gitano.org.uk would be best | 10:21 |
liw-orc | (#gitano on this irc network) | 10:21 |
liw-orc | "UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 14-16: truncated \uXXXX escape" :( | 10:42 |
Kinnison | :-( | 10:42 |
ssam2 | I'd like to add this to the Trove Reference Manual, any comments? http://sprunge.us/OiXW | 10:42 |
richard_maw | liw-orc: distbuild? | 10:43 |
liw-orc | ssam2, +2 | 10:43 |
liw-orc | richard_maw, deploy | 10:43 |
richard_maw | ssam2: I thought the write extension already managed that | 10:44 |
richard_maw | liw-orc: eep. That patch has brought nothing but trouble and I regret merging it | 10:44 |
liw-orc | hm, I'm not running latest release (or latest morph), maybe it's fixed already | 10:47 |
ssam2 | richard_maw: what have write extensions got to do with adding a .lorry file ? | 10:50 |
richard_maw | eh? this is for adding an extra upstream trove then? | 10:51 |
* richard_maw was missing context | 10:51 | |
ssam2 | no, this is for importing from $random git server | 10:51 |
ssam2 | which may be internal to a company and require SSH authentication to access | 10:51 |
richard_maw | it's perfectly reasonable then, the write extension only handles the upstream trove | 10:51 |
ssam2 | cool | 10:53 |
liw-orc | right - I couldn't test with current morph (it would have been a full rebuild, and I'm in a hurry), but editing /usr/lib/python2.7/site-packages/morphlib/plugins/deploy_plugin.py in place fixed that deployment-time json encoding problem | 12:26 |
* liw-orc thinks we should just switch to yaml for /baserock/*.meta files | 12:26 | |
jjardon | richard_maw: Its needed for a line to generate the .gir in libgee, let me check the log | 12:27 |
jjardon | richard_maw: /usr/bin/g-ir-compiler -l `/bin/sed -nE "s/^dlname='([A-Za-z0-9.+-]+)'/\1/p" libgee-0.8.la` -o Gee-0.8.typelib Gee-0.8.gir libgee-0.8.la | 12:27 |
richard_maw | ah, -E is a synonim for -r | 12:28 |
richard_maw | commit af0cdeedc699da96e2f38c3f321150cdaa3bb7d6 of busybox adds support for the -E option | 12:29 |
richard_maw | apparently the reason for -E is that it's posix compliant, but that's a recent invention | 12:30 |
richard_maw | -r is what GNU sed and busybox sed have always supported | 12:30 |
jjardon | Also I needed to upgrade to use automake 1.4.1, so it would be good if thats get merged. And I would need a new compiler version for another module but thats another history | 12:31 |
jjardon | richard_maw: nice, any chance we can update busybox? | 12:31 |
richard_maw | jjardon: sure, though I'd prefer to move the morphology out of the repository too. If you take my chunks in definitions branch you could just change the ref in the build-essential morphology | 12:33 |
richard_maw | though you would need to rebuild everything | 12:33 |
jjardon | yeah, move the morphologies out of the repos is a massive improvement, thanks for work on that | 12:36 |
jjardon | bah, this is baserock, we dont fear rebuilding ;) | 12:36 |
liw-orc | I've tested persia's and tlsa's X stratum consolidation work by building and testing it on x86-64 and armv7lhf -- I assume I can merge that now? | 13:04 |
pedroalvarez | richard_maw: oh yeah, we could start moving the morphologies for every component we decide to upgrade | 13:04 |
pedroalvarez | liw-orc: if it builds, then I assume you can | 13:05 |
liw-orc | I will, unless someone objects soon | 13:06 |
pedroalvarez | I'm looking for objections, one sec | 13:06 |
jjardon | liw-orc: FYI, I used that branch too to build the GNOME stuff | 13:08 |
liw-orc | jjardon, cool | 13:08 |
pedroalvarez | liw-orc: seems that nothing is going to change for genivi with this consolidation | 13:12 |
liw-orc | I shall merge and flee the country | 13:12 |
pedroalvarez | we probably shold look at consolidate the other versions of mesa later | 13:13 |
pedroalvarez | liw-orc: agree | 13:13 |
jjardon | I tried to run a baserock image in gnome-boxes but it fails (with a kernel panic). Any idea why or if something baserock-specific is required? | 13:18 |
Kinnison | What is 'gnome-boxes' ? | 13:18 |
Kinnison | and what panic did you get and when? | 13:18 |
liw-orc | is the root disk on /dev/sda (as opposed to /dev/vda or another disk name)? | 13:19 |
jjardon | Kinnison: Sorry: https://wiki.gnome.org/Apps/Boxes basically a GNOME 3 application to access remote or virtual systems | 13:21 |
jjardon | (it can be a problem in gnome-boxes, its a quite new app) | 13:21 |
* pedroalvarez installs gnome-boxes | 13:23 | |
pedroalvarez | jjardon: It doesn't let me choose *.img files | 13:25 |
pedroalvarez | and if I force it, it says: not bootable device | 13:25 |
Kinnison | Right, so it's libvirt | 13:25 |
jjardon | Kinnison: http://imgur.com/VFhY5ud but anyway it was more a curiosity | 13:26 |
Kinnison | jjardon: at what point was that? | 13:26 |
jjardon | pedroalvarez: what version?, it allows me here | 13:26 |
jjardon | Kinnison: just booting | 13:27 |
pedroalvarez | jjardon: 3.4.3 | 13:27 |
jjardon | pedroalvarez: oh wow, thats ancient ;) | 13:28 |
pedroalvarez | jjardon: :) | 13:28 |
pedroalvarez | jjardon: just installed from the debian repos | 13:28 |
jjardon | the QEMU logs if someone interested: http://fpaste.org/120753/94926140/ But anyway I can try to poke around here ;) | 13:30 |
jjardon | pedroalvarez: use Arch! always up-to-date! | 13:30 |
pedroalvarez | heheh | 13:31 |
pedroalvarez | I'll continue usiung baserock ;) | 13:32 |
pedroalvarez | btw, baserock supports virtualization, so maybe you can install also gnome-boxes | 13:33 |
radiofree | that has to be the most disgusting qemu command line i've ever seen | 13:36 |
jjardon | pedroalvarez: yeah, I saw it. it would be good to decouple pygobject from there btw | 13:36 |
radiofree | jjardon: try http://paste.fedoraproject.org/120755/95421140 | 13:37 |
radiofree | hda being your baserock image, hdb is optional i think | 13:37 |
radiofree | you don't need net nic, tap either | 13:37 |
liw-orc | I has merged the X consolidation patches | 13:37 |
jjardon | radiofree: that commands/logs are generated by gnome-boxes, I do not have control on them | 13:37 |
pedroalvarez | liw-orc: yay | 13:38 |
radiofree | jjardon: just use qemu directly then! | 13:38 |
radiofree | if i branch from a release, shouldn't the cache exist for the wandboard image? | 13:40 |
liw-orc | radiofree, yes | 13:40 |
Kinnison | Only if the wandboard image was part of the release and that the artifacts haven't been removed since the release | 13:40 |
jjardon | radiofree: the point was to play with gnome-boxes, I know qemu directly works :P | 13:41 |
Kinnison | And you're using the same morph as was used to make the release | 13:41 |
liw-orc | radiofree, well, not necessarily the system image itself, but all the chukns and strata certainly | 13:41 |
radiofree | well i copied the wandboard devel image, added the wayland stuff, then morph build | 13:42 |
radiofree | wants to know build llvm | 13:42 |
radiofree | s/know/now | 13:42 |
radiofree | which obviously isn't going to happen anytime soon :\ | 13:42 |
liw-orc | radiofree, is llvm in the released wandboard devel image, or is it in the added wayland stuff? | 13:43 |
radiofree | liw-orc: i think it's added by the wayland stuff | 13:44 |
radiofree | but this wayland stuff exists in a genivi baseline image | 13:44 |
liw-orc | we didn't release a genivi baseline image in the last release | 13:44 |
radiofree | so is the cache system dependent, i.e "there's a cache for system-versatile, but if you add it to system-foo it needs to rebuild"? | 13:44 |
radiofree | ah | 13:44 |
radiofree | hmm what's llvm for anyway? | 13:45 |
pedroalvarez | something that take ages to build | 13:45 |
radiofree | part of x-common | 13:45 |
radiofree | what needs llvm to build? | 13:45 |
liw-orc | I don't know, but I think it's something to do with 3D graphics optimisations | 13:46 |
jjardon | radiofree: AFAIK mesa | 13:46 |
radiofree | aaah, right, for llvmpipe | 13:47 |
radiofree | which, one arm, is so slow as to be unusable anyway... | 13:47 |
radiofree | s/one/on | 13:47 |
radiofree | don't need mesa, will just remove it | 13:48 |
pedroalvarez | So, what do the people think about creating baserock/$TAG branches in the repositories to use them in the morphologies? | 14:01 |
pedroalvarez | this is regerding my last mail in the "update glib and gobject..." thread | 14:01 |
richard_maw | pedroalvarez: I'd prefer to use the upstream tag and put the morphology in definitions.git, as it's really rather shameful for upstream to move a tag | 14:07 |
jjardon | pedroalvarez: why you think upstream is going to change/rebase... the tags? | 14:07 |
liw-orc | richard_maw, shameful, but it happens | 14:08 |
liw-orc | (and it happens even in Baserock: our old release process led to that, for example) | 14:08 |
pedroalvarez | jjardon: it can happen | 14:09 |
jjardon | never see a upstream change the tags, and if they do probably is for a very good reason | 14:09 |
Kinnison | a good reason for them is still a failure in our reproducibility | 14:10 |
Kinnison | jjardon: and I've seen upstreams rework tags four or five times over the course of weeks | 14:10 |
Kinnison | jjardon: or worse, have a foo_1.0 tag which they *update* for any 1.0.x releases | 14:10 |
pedroalvarez | and if we point to a sha1, and it dissapears, then morph can't build it! | 14:10 |
Kinnison | indeedy | 14:11 |
Kinnison | hence needing the SHA1 anchored in the unpetrify-ref | 14:11 |
jjardon | ok, understood, I only feel this make everything more complicated to deal with something that its the exception, not the norm | 14:12 |
ssam2 | just realised that my script needs to embed YAML in shell in YAML | 14:48 |
ssam2 | :( | 14:48 |
Kinnison | ssam2: eww | 14:48 |
richard_maw | ssam2: just talk to pedroalvarez about how many levels of escaping he needed for his ansible stuff | 15:03 |
pedroalvarez | 3.. | 15:04 |
*** fay_ [~fay@82-68-191-81.dsl.posilan.com] has quit [Remote host closed the connection] | 15:04 | |
ssam2 | ouch | 15:07 |
*** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 255 seconds] | 15:08 | |
ssam2 | rebuilds from stage1-gcc-bins :( | 15:30 |
ssam2 | this shouldn't happen when building the baserock-14.29 tag, surely ?? | 15:31 |
richard_maw | we changed the cache key algorithm recently | 15:31 |
ssam2 | oh, yes | 15:32 |
ssam2 | does anyone have any system artifacts they could share with me? | 15:32 |
ssam2 | well, and all the chunk artifacts | 15:32 |
* richard_maw will check his devel VM | 15:33 | |
*** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving] | 15:55 | |
*** ssam2 [~ssam2@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving] | 17:13 | |
*** liw-orc` [~liw@access.ducie-dc1.codethink.co.uk] has joined #baserock | 23:21 | |
*** benbrown1 [~benbrown@access.ducie-dc1.codethink.co.uk] has joined #baserock | 23:28 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!