[00:39] <infinity> wgrant: Do we know what causes the above, BTW?  It is just some touchy hard-to-hunt-and-fix race, or scary corruption somewhere, or...?
[00:40] <infinity> (I've always been inclined to not care deeply, sinc the workaround is easy and not a big deal unless it was a 24h GCC build, but... Sometimes it's a 24h GCC build)
[00:40] <wgrant> infinity: That wasn't the actual error
[00:40] <wgrant> The error was "Server said:"
[00:40] <wgrant> It's some librarian network glitch, I believe.
[00:40] <infinity> Server said: nothing?  Whee.
[00:41] <wgrant> Right
[00:41] <wgrant>   File "/srv/launchpad.net/codelines/soyuz-production-rev-16916/lib/lp/services/librarian/client.py", line 104, in _checkError
[00:41] <wgrant>     raise UploadFailed('Server said: ' + response)
[00:41] <wgrant> UploadFailed: Server said:
[00:41] <wgrant> It should probably retry in that case, but it's a bit complicated.
[00:42] <infinity> wgrant: Like I said, not a big deal, just a curiosity.
[00:42] <infinity> (We still see the odd hash mismatch too, which is disconcerting, since we no longer have bitflip-prone hardware..)
[00:42] <wgrant> Do we?
[00:42] <wgrant> I haven't seen any of those recently :/
[00:42] <infinity> Yeah, I see a failed hash upload once a month or so, maybe.
[00:43] <infinity> Arch random.
[00:43] <infinity> We're not abusing the same python-doesn't-do-http-post-properly misfeature of the chroot uploads, are we? :)
[00:43] <wgrant> Fortunately not.
[00:43] <infinity> Nah, can't be that, or it would die a lot more often.
[00:43] <wgrant> Python sucking at MIME is unrelated to XML-RPC.
[00:44] <infinity> And more reproducibly on builds of a certain size.
[00:45] <infinity> wgrant: I forget, did we actually hack around that for the chroot case?
[00:46] <wgrant> infinity: You don't want to know.
[00:46] <infinity> I'm pretty sure I once knew.
[00:46] <infinity> And forgot.
[00:46] <wgrant> Keep it that way.
[00:46] <infinity> Hahaha.
[00:46] <infinity> Kay.
[00:46] <infinity> Was it uglier than my "why not have the client null-terminate, and the server strip?" suggestion?"
[00:46] <infinity> s/"$//
[00:47] <wgrant> You asked for it: https://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/soyuz/model/distroarchseries.py#L172
[00:47] <infinity> HAHAHAHAHAHA.
[00:47] <infinity> So, yes, it's worse that my suggestion, from a performance POV.
[00:47] <infinity> But, transparent.  So yay.
[00:48] <wgrant> Right, the main point is that it's transparent to the client.
[00:48] <wgrant> It works around the broken data from the client, while allowing a proper client fix later.
[00:48] <wgrant> Without breaking protocol.
[00:48] <infinity> I don't think you get to make fun of cprov's code for a week.
[00:48] <infinity> Also, it would be infinitely better without the comment.
[00:48] <infinity> "doesn't match?  add random shit and try again."
[00:49] <wgrant> Heh
[05:36] <darkxst> anyone able to bump mozjs24 through the new queue? so I can get the other bits (gjs/gnome-shell etc) uploaded over the weekend
[14:36] <jamespage> please could a member of the SRU team review the openvswitch-lts-saucy source package I uploaded a while back to fix bug 1262225
[14:36] <ubot2`> Launchpad bug 1262225 in openvswitch (Ubuntu Precise) "openvswitch 1.4.6 is not compatible with the 3.11 saucy HWE kernel" [High,Triaged] https://launchpad.net/bugs/1262225
[14:37] <jamespage> its the same approach we took with the lts-raring kernel
[15:31] <bdmurray> What are the release task wiki pages?  For new releases and making a release EoL.
[15:31] <bdmurray> ah, I think I found it
[15:33] <rsalveti> stgraber: we now have an i386 tarball published from cdimage, what needs to happen to get that tarball published via the system-image server?
[15:33] <rsalveti> ogra_: ^
[15:33] <ogra_> rsalveti, we only have the tarball
[15:33] <rsalveti> ogra_: isn't that enough?
[15:33] <rsalveti> or do we need a device tarball as well?
[15:33] <ogra_> rsalveti, i assume you want the android package too
[15:33] <rsalveti>  /tarball/images/
[15:34] <rsalveti> right, for now just a tarball is fine
[15:34] <rsalveti> as that's what is used by the ubuntu-emulator script
[15:34] <ogra_> currently x86 skips in in live-build
[15:34] <ogra_> rsalveti, it doesnt use any android bits ?
[15:34]  * ogra_ assumed you want boot/system at least
[15:35] <ogra_> rsalveti, i also havent enabled it by default yet ... will do so after didrocks' image has build
[15:36] <rsalveti> ogra_: hm, true, the current one is extracting the kernel from the boot image
[15:36] <rsalveti> but the previous one wasn't
[15:37] <rsalveti> but having the system image for the rootfs tarball would already help me a lot
[15:37] <ogra_> rsalveti, if you only use the tarball and no android system.img for the container i think that would need changes on the system-image,u.c side
[15:37] <rsalveti> ogra_: well, the tarball is always generic, right?
[15:37] <ogra_> (though if you only need the tarball i would just pull it directly=
[15:37] <rsalveti> the android image I produce it myself
[15:38] <rsalveti> ogra_: it's just that the logic we have pulls it from system-image
[15:38] <ogra_> rsalveti, on cdimage it is generic ... system-image stuffs the system.img in place
[15:38] <rsalveti> and we also use the system-image format when booting the emulator
[15:38] <rsalveti> ogra_: thought that this was happening during flash
[15:38] <rsalveti> ogra_: the rootfs tarball in system-image is still generic
[15:38] <ogra_> rsalveti, well, it dumps links and dirs in place
[15:38] <rsalveti> that's why we have the device tarball and the rootfs tarball there as well
[15:38] <rsalveti> ogra_: but that's generic enough
[15:39] <ogra_> right
[15:39] <ogra_> rsalveti, http://paste.ubuntu.com/6931793/ (from rootstock)
[15:40] <ogra_> rsalveti, thats the bit that system-image does in generatos.py
[15:40] <ogra_> *generators
[15:40] <ogra_> (which rootstock does during install)
[15:40] <rsalveti> ogra_: right, and that's what I'm using locally :-)
[15:41] <rsalveti> ogra_: that's why I said they are generic enough for the emulator, because I'm already using it :-)
[15:41] <ogra_> well, i was wondering if we shouldnt just have the emulator wrapper script do that
[15:41] <ogra_> it is trivial enough
[15:41] <rsalveti> ogra_: why if we can just download the system-image rootfs?
[15:42] <rsalveti> and that rootfs will be there anyway
[15:42] <rsalveti> with proper id and such
[15:42] <stgraber> I'd expect i386 emulator to be similar to the armhf emulator and we sure have a device tarball for that one
[15:42] <rsalveti> stgraber: yeah, that will happen soon
[15:42] <rsalveti> stgraber: it's just that we got the rootfs tarball already
[15:42] <stgraber> system-image can be configured not to ship with a device tarball but only in a separate channel
[15:42] <stgraber> and I don't think we want to create a separate channel just for the i386 emulator :)
[15:42] <rsalveti> stgraber: but can't we just publish the rootfs tarball?
[15:43] <rsalveti> or do you need a device image there as well?
[15:43] <rsalveti> yeah, we don't want a separated channel, no
[15:44] <stgraber> system-image won't publish an image if it's lacking any of the configured tarball for the channel, so no, for our existing channels, it's not possible to publish an image without a device tarball
[15:44] <ogra_> you could surely do that if you clone stgraber
[15:44] <ogra_> so he has time to chaneg the code :)
[15:45] <rsalveti> right, will just push harder to get the device image in place
[15:45] <rsalveti> :-)
[15:46] <ogra_> rsalveti, i guess that needs some magic in the adnroid package then ... and we need to enable the android part in live-build
[15:47] <ogra_> (since system-image pulls from cdimage and expects the device files there)
[15:47] <rsalveti> ogra_: yeah
[15:47] <rsalveti> but I got a bunch of things to do first anyway
[15:47] <rsalveti> like qt packaging, mir and so on
[16:50] <darkxst> anyone able to bump mozjs24 through the new queue? so I can get the other bits (gjs/gnome-shell etc) uploaded over the weekend
[19:10] <lamont> anyone know anything about gccgo-4.9 being mode 0?
[19:10] <seb128> lamont, see #is scrollback some 9 hours ago if you have it
[19:10] <lamont> ta
[19:11] <seb128> lamont, doko uploaded a version that nuked libgcc1 content and made apt, chroots and other things unhappy
[19:11] <seb128> lamont, the binaries got chmoded to avoid users getting it
[19:12] <lamont> right
[19:12]  * lamont had just concluded that