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