IRC logs for #baserock for Friday, 2014-07-25

*** fay_ [] has joined #baserock06:47
*** tiagogomes [] has joined #baserock07:51
*** ssam2 [] has joined #baserock08:20
*** jonathanmaw [] has joined #baserock08:20
robtaylorjjardon: can't wait to see it :)09:34
richard_mawjjardon: -E isn't in the version of sed I have on my Debian Laptop, what does it do?09:35
ssam2Kinnison: is there some way I can report a bug in Gitano?10:11
ssam2I'm going through an old list of customer issues and have one that doesn't really belong there10:12
ssam2I could put it on our internal gitlab instance issues, if that's preferred10:12
ssam2the 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 delete10: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
Kinnisonssam2: Reporting in #gitano and/or on would be best10: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
ssam2I'd like to add this to the Trove Reference Manual, any comments?
richard_mawliw-orc: distbuild?10:43
liw-orcssam2, +210:43
liw-orcrichard_maw, deploy10:43
richard_mawssam2: I thought the write extension already managed that10:44
richard_mawliw-orc: eep. That patch has brought nothing but trouble and I regret merging it10:44
liw-orchm, I'm not running latest release (or latest morph), maybe it's fixed already10:47
ssam2richard_maw: what have write extensions got to do with adding a .lorry file ?10:50
richard_maweh? this is for adding an extra upstream trove then?10:51
* richard_maw was missing context10:51
ssam2no, this is for importing from $random git server10:51
ssam2which may be internal to a company and require SSH authentication to access10:51
richard_mawit's perfectly reasonable then, the write extension only handles the upstream trove10:51
liw-orcright - 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/ in place fixed that deployment-time json encoding problem12:26
* liw-orc thinks we should just switch to yaml for /baserock/*.meta files12:26
jjardonrichard_maw: Its needed for a line to generate the .gir in libgee, let me check the log12:27
jjardonrichard_maw: /usr/bin/g-ir-compiler -l `/bin/sed -nE "s/^dlname='([A-Za-z0-9.+-]+)'/\1/p"` -o Gee-0.8.typelib Gee-0.8.gir libgee-0.8.la12:27
richard_mawah, -E is a synonim for -r12:28
richard_mawcommit af0cdeedc699da96e2f38c3f321150cdaa3bb7d6 of busybox adds support for the -E option12:29
richard_mawapparently the reason for -E is that it's posix compliant, but that's a recent invention12:30
richard_maw-r is what GNU sed and busybox sed have always supported12:30
jjardonAlso 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 history12:31
jjardonrichard_maw: nice, any chance we can update busybox?12:31
richard_mawjjardon: 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 morphology12:33
richard_mawthough you would need to rebuild everything12:33
jjardonyeah, move the morphologies out of the repos is a massive improvement, thanks for work on that12:36
jjardonbah, this is baserock, we dont fear rebuilding ;)12:36
liw-orcI'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
pedroalvarezrichard_maw: oh yeah, we could start moving the morphologies for every component we decide to upgrade13:04
pedroalvarezliw-orc: if it builds, then I assume you can13:05
liw-orcI will, unless someone objects soon13:06
pedroalvarezI'm looking for objections, one sec13:06
jjardonliw-orc: FYI, I used that branch too to build the GNOME stuff13:08
liw-orcjjardon, cool13:08
pedroalvarezliw-orc: seems that nothing is going to change for genivi with this consolidation13:12
liw-orcI shall merge and flee the country13:12
pedroalvarezwe probably shold look at consolidate the other versions of mesa later13:13
pedroalvarezliw-orc: agree13:13
jjardonI 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
KinnisonWhat is 'gnome-boxes' ?13:18
Kinnisonand what panic did you get and when?13:18
liw-orcis the root disk on /dev/sda (as opposed to /dev/vda or another disk name)?13:19
jjardonKinnison: Sorry: basically a GNOME 3 application to access remote or virtual systems13:21
jjardon(it can be a problem in gnome-boxes, its a quite new app)13:21
* pedroalvarez installs gnome-boxes13:23
pedroalvarezjjardon: It doesn't let me choose *.img files13:25
pedroalvarezand if I force it, it says: not bootable device13:25
KinnisonRight, so it's libvirt13:25
jjardonKinnison: but anyway it was more a curiosity13:26
Kinnisonjjardon: at what point was that?13:26
jjardonpedroalvarez: what version?, it allows me here13:26
jjardonKinnison: just booting13:27
pedroalvarezjjardon: 3.4.313:27
jjardonpedroalvarez: oh wow, thats ancient ;)13:28
pedroalvarezjjardon: :)13:28
pedroalvarezjjardon: just installed from the debian repos13:28
jjardonthe QEMU logs if someone interested: But anyway I can try to poke around here ;)13:30
jjardonpedroalvarez: use Arch! always up-to-date!13:30
pedroalvarezI'll continue usiung baserock ;)13:32
pedroalvarezbtw, baserock supports virtualization, so maybe you can install also gnome-boxes13:33
radiofreethat has to be the most disgusting qemu command line i've ever seen13:36
jjardonpedroalvarez: yeah, I saw it. it would be good to decouple pygobject from there btw13:36
radiofreejjardon: try
radiofreehda being your baserock image, hdb is optional i think13:37
radiofreeyou don't need net nic, tap either13:37
liw-orcI has merged the X consolidation patches13:37
jjardonradiofree: that commands/logs are generated by gnome-boxes, I do not have control on them13:37
pedroalvarezliw-orc: yay13:38
radiofreejjardon: just use qemu directly then!13:38
radiofreeif i branch from a release, shouldn't the cache exist for the wandboard image?13:40
liw-orcradiofree, yes13:40
KinnisonOnly if the wandboard image was part of the release and that the artifacts haven't been removed since the release13:40
jjardonradiofree: the point was to play with gnome-boxes, I know qemu directly works :P13:41
KinnisonAnd you're using the same morph as was used to make the release13:41
liw-orcradiofree, well, not necessarily the system image itself, but all the chukns and strata certainly13:41
radiofreewell i copied the wandboard devel image, added the wayland stuff, then morph build13:42
radiofreewants to know build llvm13:42
radiofreewhich obviously isn't going to happen anytime soon :\13:42
liw-orcradiofree, is llvm in the released wandboard devel image, or is it in the added wayland stuff?13:43
radiofreeliw-orc: i think it's added by the wayland stuff13:44
radiofreebut this wayland stuff exists in a genivi baseline image13:44
liw-orcwe didn't release a genivi baseline image in the last release13:44
radiofreeso 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
radiofreehmm what's llvm for anyway?13:45
pedroalvarezsomething that take ages to build13:45
radiofreepart of x-common13:45
radiofreewhat needs llvm to build?13:45
liw-orcI don't know, but I think it's something to do with 3D graphics optimisations13:46
jjardonradiofree: AFAIK mesa13:46
radiofreeaaah, right, for llvmpipe13:47
radiofreewhich, one arm, is so slow as to be unusable anyway...13:47
radiofreedon't need mesa, will just remove it13:48
pedroalvarezSo, what do the people think about creating baserock/$TAG branches in the repositories to use them in the morphologies?14:01
pedroalvarezthis is regerding my last mail in the "update glib and gobject..." thread14:01
richard_mawpedroalvarez: 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 tag14:07
jjardonpedroalvarez: why you think upstream is going to change/rebase... the tags?14:07
liw-orcrichard_maw, shameful, but it happens14:08
liw-orc(and it happens even in Baserock: our old release process led to that, for example)14:08
pedroalvarezjjardon: it can happen14:09
jjardonnever see a upstream change the tags, and if they do probably is for a very good reason14:09
Kinnisona good reason for them is still a failure in our reproducibility14:10
Kinnisonjjardon: and I've seen upstreams rework tags four or five times over the course of weeks14:10
Kinnisonjjardon: or worse, have a foo_1.0 tag which they *update* for any 1.0.x releases14:10
pedroalvarezand if we point to a sha1, and it dissapears, then morph can't build it!14:10
Kinnisonhence needing the SHA1 anchored in the unpetrify-ref14:11
jjardonok, understood, I only feel this make everything more complicated to deal with something that its the exception, not the norm14:12
ssam2just realised that my script needs to embed YAML in shell in YAML14:48
Kinnisonssam2: eww14:48
richard_mawssam2: just talk to pedroalvarez about how many levels of escaping he needed for his ansible stuff15:03
*** fay_ [] has quit [Remote host closed the connection]15:04
*** tiagogomes [] has quit [Ping timeout: 255 seconds]15:08
ssam2rebuilds from stage1-gcc-bins :(15:30
ssam2this shouldn't happen when building the baserock-14.29 tag, surely ??15:31
richard_mawwe changed the cache key algorithm recently15:31
ssam2oh, yes15:32
ssam2does anyone have any system artifacts they could share with me?15:32
ssam2well, and all the chunk artifacts15:32
* richard_maw will check his devel VM15:33
*** jonathanmaw [] has quit [Quit: Leaving]15:55
*** ssam2 [] has quit [Quit: Leaving]17:13
*** liw-orc` [] has joined #baserock23:21
*** benbrown1 [] has joined #baserock23:28

Generated by 2.14.0 by Marius Gedminas - find it at!