| 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:39 |
|---|---|---|
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| infinity | And more reproducibly on builds of a certain size. | 00:44 |
| infinity | wgrant: I forget, did we actually hack around that for the chroot case? | 00:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| wgrant | Heh | 00:49 |
| === maclin__ is now known as maclin | ||
| 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 | 05:36 |
| === doko_ is now known as doko | ||
| === peterm-u_ is now known as Peter-offsite | ||
| === ara is now known as Guest55777 | ||
| 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:36 |
| jamespage | its the same approach we took with the lts-raring kernel | 14:37 |
| === tyhicks` is now known as tyhicks | ||
| 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:31 |
| 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:33 |
| 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:34 | |
| ogra_ | rsalveti, i also havent enabled it by default yet ... will do so after didrocks' image has build | 15:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| ogra_ | right | 15:39 |
| ogra_ | rsalveti, http://paste.ubuntu.com/6931793/ (from rootstock) | 15:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| rsalveti | or do you need a device image there as well? | 15:43 |
| rsalveti | yeah, we don't want a separated channel, no | 15:43 |
| 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:44 |
| rsalveti | right, will just push harder to get the device image in place | 15:45 |
| rsalveti | :-) | 15:45 |
| 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:46 |
| 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 | 15:47 |
| 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 | 16:50 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| 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:10 |
| 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:11 |
| lamont | right | 19:12 |
| * lamont had just concluded that | 19:12 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!