[12:38] <plars> cjwatson, infinity: no desktop images since Saturday?
[12:38] <cjwatson> plars: being fixed
[12:38] <cjwatson> was due to bug 1184927
[12:39] <ubot2> Launchpad bug 1184927 in libnet-smtp-ssl-perl (Ubuntu) "[MIR] libnet-smtp-ssl-perl" [High,Fix released] https://launchpad.net/bugs/1184927
[12:39] <cjwatson> in fact I was just about to kick off a rebuild
[12:41] <plars> cjwatson: how did libmailtools with the new dep make it through proposed with the missing dep? I was thinking there were pieces already in place to prevent things like this.
[12:41] <cjwatson> plars: -proposed doesn't guard against component mismatches
[12:41] <cjwatson> since they only break image builds, not (typically) upgrades, I don't mind too much
[12:42] <plars> ok, good to know
[12:42] <plars> thanks
[12:45] <cjwatson> (also, in practice the bulk of component mismatches cause package build failures, because the -dev isn't available to the build - doesn't apply to interpreted languages though)
[13:15] <ogra_> argl ... grmbl ...
[13:16]  * doko looks up Brehms Tierleben
[13:19] <ogra_> heh
[13:20]  * ogra_ forgot to move the PPA stuff out of the way when rolling ubuntu touch initrds .... another 2h waiting for a 2 line change until i can trigger a new build 
[13:44] <ogra_> can someone let android-tools-adbd out of binary NEW please
[13:46] <seb128> ogra_, looking
[13:46] <ogra_> thx
[14:50] <plars> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1185053 seems to be affecting server cd images, yesterday's worked fine but todays does not
[14:50] <ubot2> Ubuntu bug 1185053 in plymouth (Ubuntu) "Saucy server images do not boot for 20130528" [Undecided,New]
[14:50] <plars> I suspect desktop images that just landed are going to have the same problem
[14:55] <cjwatson> plars: I'm looking at that right now; on the contrary I have no reason to believe desktop will be affected right now
[14:55] <cjwatson> And it sure isn't plymouth
[14:56] <plars> cjwatson: the builds seem to still get published to both pending and current, so we may want to switch the current for server at least back to yesterday's image
[14:56] <cjwatson> Let me investigate first
[14:56] <plars> cjwatson: ok, if there's anything I can do from my side let me know.
[14:56] <cjwatson> well, ok, yesterday's is there
[14:56] <cjwatson> symlink switched back
[14:57] <plars> cjwatson: indeed, the desktop install seems to be progressing
[15:41]  * ogra_ scratches head 
[15:41] <ogra_> The following packages have unmet dependencies:
[15:41] <ogra_>  ubuntu-touch : Depends: android-tools-adbd but it is not installable
[15:42] <ogra_> android-tools-adbd was approved 90min ago ... so it should eb available
[15:44] <seb128> ogra_, not sure if the publisher is slow or something, it took over 2 hours for the gnome-desktop binaries to go from "accepted" to "available" this morning
[15:45] <ogra_> well, it was already in -propsed, wasnt it ? so it should only need one run
[15:45] <seb128> well, accepted from NEW to proposed should have been one run only as well
[15:45] <ogra_> i'm used to 2h for a full loop ....  but for -propsed to archive it shouldnt take that long
[15:45] <seb128> dunno what's going on, it's just an observation that things are being weird today
[15:45] <ogra_> jenkins seems to be broken
[15:46] <ogra_> but that shouldnt affect us i would think
[15:46] <cjwatson> seb128: there was a downtime for a database upgrade
[15:46] <cjwatson> which I think went on a bit longer than usual due to a new op rotating in
[15:46] <seb128> cjwatson, ah ok, that would explain it, thanks
[15:47] <cjwatson> I was watching at the time and there was nothing else odd
[15:47] <cjwatson> oh, one publisher run ran long
[15:47] <ogra_> https://launchpad.net/ubuntu/saucy/+queue?queue_state=3&queue_text=android
[15:47] <ogra_> that looks a bit weird
[15:47] <ogra_> the new binary wants to go to main ?
[16:07] <xnox> Can the i386 build of https://launchpad.net/ubuntu/+source/yade/0.97.0-1ubuntu1 be forced on a host with loads of free RAM?
[16:07] <xnox> "virtual memory exhausted: Cannot allocate memory"
[16:11] <cjwatson> xnox: I don't know that there's any difference between the available i386 builders in terms of RAM.  infinity might
[16:12] <cjwatson> xnox: A compile run that runs our builders out of memory is pretty unreasonable, though.  Consider splitting the translation unit - we've done that to packages in the past
[16:12] <slangasek> ogra_: the source is in main because of android-tools-fsutils; so unless someone overrode it at NEW time, the new binary package goes to the same component as the source; it can be demoted via component-mismatches, but OTOH, if it's seeded in ubuntu-touch, it probably should be in main?
[16:12] <slangasek> (I realize your comment implies that ubuntu-touch is currently not pinned to main, but that seems like something to fix)
[16:12] <ogra_> slangasek, it surely shall be in main at some point
[16:13] <ogra_> but wasnt urgent in the first place since we are building with a ton of universe packages anyway atm
[16:13] <slangasek> sure
[16:13] <ogra_> and i dont see anyone filing a ton of MIRs until we actually use saucy and people upload saucy etc etc
[16:13] <xnox> cjwatson: hmm... I think there was a builder with 12GB of ram, but yade was trying to build -j3. I'll flip it back to -j1 and try again at some point later.
[16:13] <cjwatson> On i386 you won't get 12GB of RAM for a single process anyway
[16:14] <slangasek> ogra_: yes - that's the #1 priority right now.
[16:14] <ogra_> right
[16:14] <ogra_> working on it :)
[16:14] <xnox> cjwatson: good point, i wonder if it's hitting the RAM limit in a translation unit as you suggested. Is it the case of adding intermediate convenience libraries to reduce the ram usage?
[16:15] <ogra_> the container flip will be done by friday ...  but cdimage wont be able to spit out the android zip we need yet ...
[16:15] <ogra_> (will be aa bit fiddly to install in the beginning due to that)
[16:15] <xnox> obviously on amd64 with 32GB it compiles just fine here & on the builds.
[16:16] <cjwatson> xnox: I don't know the source but you usually don't need convenience libraries, since these are typically objects that eventually get linked together anyway, so just splitting up the source file is often enough
[16:16] <cjwatson> ogra_: android-tools is out of date on powerpc so proposed-migration isn't promoting it to release
[16:17] <ogra_> hmpf
[16:17] <ogra_> can we override that
[16:17] <ogra_> ?
[16:17] <cjwatson> but since the last version built it should be quick to narrow down
[16:17] <cjwatson> Yes but I greatly prefer never to override such things
[16:20] <cjwatson> hm, can't easily remove the package because it will render livecd-rootfs uninstallable
[16:20] <xnox> ogra_: looks like adbd is failing on powerpc, and as far as I can tell adbd shouldn't need to be build on powerpc.
[16:21] <ogra_> yeah
[16:21] <ogra_> looks like a variable length issue
[16:21] <ogra_> in some usb code
[16:21] <cjwatson> it's a non-constant initialiser
[16:21] <cjwatson> which is not valid C
[16:21]  * xnox wonders is someone is planning to commercialise androidPOWER =) ..... nintendo?!
[16:22] <cjwatson> Though I thought GNU C permitted non-constant initialisers
[16:22] <ogra_> heh
[16:22] <cjohnston> infinity: ping
[16:22] <cjwatson> Oh, only for automatic variables, which this isn't
[16:23] <cjwatson> I love how this code goes to great care to handle endianness in such a way that if the endian conversion is non-trivial then it will fail to compile
[16:23] <tumbleweed> talking of builders and RAM, pypy has been stuck timing out for hours now https://launchpad.net/ubuntu/+source/pypy/2.0.2+dfsg-1/+build/4608301. don't know if it needs a boot
[16:23] <cjwatson> Simplest fix is probably just to build adbd only on the architectures you care about, indeed
[16:23] <ogra_> yeah
[16:24] <ogra_> can you make britney let it in as a one time so i dont have to wait for another 2h while the fix builds ?
[16:24] <cjwatson> tumbleweed: I've asked webops
[16:24] <ogra_> *one timer
[16:24] <tumbleweed> cjwatson: ta. unfortunately it'll have to be retried, unless we delete the current armhf binary
[16:24] <tumbleweed> it should build, it does on my chromebook
[16:25] <cjwatson> ogra_: done, but only for this version
[16:25] <ogra_> thanks !
[16:25] <cjwatson> you'll have to fix it if you want any further changes
[16:25] <ogra_> yeah, thats fine
[16:26] <cjwatson> tumbleweed: do you want it to retry straight away?
[16:26] <ogra_> i just want to trigger a new image while the fix builds
[16:26] <tumbleweed> cjwatson: sure
[16:26] <cjwatson> ogra_: you'll have to wait a publisher run or two anyway
[16:26] <ogra_> yeah
[16:26] <ogra_> ugh, two ?
[16:26] <ogra_> ok
[16:26] <tumbleweed> cjwatson: thanks. /me -> dinner
[16:26] <cjwatson> depends on timing of proposed-migration vs. publisher
[16:27] <cjwatson> yeah, given current proposed-migration runtime I can't make it finish before the next publisher even if I run it by hand
[16:27] <ogra_> yeah, dont bother
[16:27] <cjwatson> so ETA an hour
[16:27] <ogra_> yup
[16:29] <lamont> cjwatson: tumbleweed: it's removing the build tree now -- back over to you guys
[16:30] <cjwatson> ta, though I don't know whether it will need processes killing too
[16:30] <cjwatson> we'll see
[16:31]  * cjwatson fixes the Kubuntu image build failure
[16:51] <infinity> xnox: As cjwatson points out, that probably has nothing to do with available RAM, and everything to do with 32-bit addressing.
[17:17] <zul> can someone de-binary-new python3-testtools please?
[17:43] <Laney> I'd appreciate someone NEWing gtksourceview3 when it arrives tonight so that I can do the transition quickly in the morning tomorrow
[17:44] <Laney> pre-req-ish of eds which I'll be doing later in the week
[17:44] <Laney> seb128: ^ if you happen to be around
[17:44] <seb128> Laney, gtksourceview3? didn't we just transition that?
[17:45] <Laney> erm, sorry, gtkspell3
[17:45] <seb128> Laney, ah ok, will do
[17:45] <Laney> too many transitions on the brain
[17:45] <seb128> ;-)
[17:45] <seb128> the gnome-desktop3 one should be complete btw
[17:45] <Laney> this one is only like 4 packages
[17:45] <Laney> ah good
[18:37]  * tumbleweed prays to the buildd gods and retries pypy
[18:37] <stgraber> ;)
[19:40] <infinity> tumbleweed: It may work slightly better when we get some new buildd hardware in place.
[19:40] <infinity> tumbleweed: Its biggest issue is RAM usage and swap-death, right?
[19:44] <tumbleweed> infinity: yeah
[19:44] <tumbleweed> builds in 7 hours on a chromebook with 2GB RAM
[19:45] <tumbleweed> (once I switched to the 3/1GB memory layout)
[19:45] <infinity> tumbleweed: Kay, so it might not go too badly on highbank with 4G.
[19:45] <tumbleweed> yeah
[19:45] <infinity> tumbleweed: Does it parallelize too?
[19:45] <tumbleweed> no
[19:45] <tumbleweed> only the gcc bit
[19:45] <infinity> Kay.  So, the 4 cores are useless to it, but highbank's a bit faster than Panda, per-core.
[19:46] <infinity> And all that yummy RAM and fast(er) disk.
[19:46] <tumbleweed> the majority of build time is rpython -> C translation - one big serial python process