[07:17] <apachelogger> could someone please reject the pending konversation upload
[07:51] <doko> apachelogger, done
[07:51] <apachelogger> cheers
[08:13] <chrisccoulson> final freeze is this week isnt' it?
[08:14] <Laney> yes
[08:14] <seb128> chrisccoulson, https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule says thursday
[08:15] <chrisccoulson> seb128, thanks
[08:15] <chrisccoulson> i wonder what the chances are of me getting 2 firefox uploads in this week? i want to temporarily turn a crash in to a runtime abort to try and get more info out of it ;)
[08:15] <chrisccoulson> (and i have another crash fix and a packaging fix)
[08:20] <Riddell> chrisccoulson: and fix the kubuntu issue?
[08:20] <chrisccoulson> Riddell, yes, that would be one of them
[08:23] <seb128> chrisccoulson, well, I guess you tried other ways to get debug infos without luck?
[08:23] <chrisccoulson> seb128, all i have is crash reports that don't have enough info and with no contact details for the reporters
[08:23] <seb128> chrisccoulson, the builders queue seems quite empty, I guess you can try to convince Laney (or whatever other r-t member you find around, which is likely not a lot at this time of the day)
[08:25] <seb128> chrisccoulson, is that with the raring version? I should maybe run that rather than the ppa ... I guess you don't have steps to try reproduce the issue?
[08:25] <Laney> seems tight ...
[08:26] <chrisccoulson> seb128, it's actually with the current version in all releases
[08:26] <chrisccoulson> seb128, i'd rather you ran the ppa version though ;)
[09:22] <tseliot> hi, can any admin please reject nvidia-graphics-drivers-304-updates (304.88-0ubuntu2) and nvidia-graphics-drivers-310-updates (310.44-0ubuntu2) from raring-proposed?
[09:23] <Laney> ok
[09:25] <tseliot> thanks Laney!
[09:25] <Laney> what was the problem?
[09:28] <tseliot> Laney: there wasn't really a problem, I wanted to include more changes
[09:41] <cjwatson> Could somebody please review my debian-installer upload from Friday?  We need to get new kernels in.
[09:41] <Laney> seb128: is that unity-lens-friends upload alright?
[09:42] <stgraber> cjwatson: I'll do that now
[09:42] <stgraber> (then go back to pretending I'm not around ;))
[09:42] <Laney> libappindicator could do with being looked at too; I can't because it's my change
[09:43] <stgraber> Laney: gah, that one is a sync... we really need to teach LP how to diff those
[09:44] <cjwatson> stgraber: thanks
[09:44] <Laney> yeah ...
[09:44] <Laney> I couldn't figure out how to use LP API to grab them even
[09:44] <cjwatson> Damn, I meant to review doko's gcc-4.7 uploads before the weekend :-/
[09:45] <doko> heh, I did use the time do some ppa builds, until the ppa repo didn't accept any more uploads due to size
[09:46] <seb128> Laney, not sure about unity-lens-friends, better to check with Ken why social.scope.in.in has been dropped, I see no corresponding commit in the vcs
[09:47] <stgraber> Laney: so I think I'm confused about that changelog entry. I clearly see the change to have the library installed in /usr/lib instead of the multi-arch path, but I'm not seeing anything about getting the pcfile into /usr/share/pkgconfig
[09:47] <stgraber> Laney: nevermind, I'm blind
[09:47] <stgraber> (I somehow missed the 3rd file in the debdiff)
[09:47] <Laney> phew
[09:47] <stgraber> accepted
[09:48] <Laney> merci
[09:49] <stgraber> Bitte sehr
[09:51] <Laney> \o/
[09:52] <Laney> seb128: should the pot have been dropped too?
[09:52] <Laney> it seems to revert your upload
[09:52] <seb128> Laney, yes, dh-translations will generate it at build time
[09:53] <Laney> kenvandine: ^ I'll reject unity-lens-friends for safety until you check on the .scope.in.in dropping
[09:53] <cjwatson> (rss2irc is a build fix, since I think that's unclear from the changelog)
[10:07] <cjwatson> could somebody push through the latest set of haskell rebuilds?
[10:07] <cjwatson> also ideally the haskell syncs in NEW from the end of last week
[10:07] <Laney> looking (at the former)
[10:09] <cjwatson> just did a batch of armhf removals too; getting close ...
[10:09] <Laney> down to the wire
[10:10] <Laney> did soemone else accept rss2irc?
[10:10] <stgraber> cjwatson: speaking of removals, can you remove lttng-tools from raring, the binaries have been taken over by ltt-control (synced from Debian)
[10:10] <stgraber> Laney: I did
[10:10] <Laney> alright, great
[10:10] <Laney> otherwise it would have been a queue bug
[10:16] <cjwatson> stgraber: done - I reassigned the one open bug too
[10:39] <Laney> tseliot: are the nvidia-graphics-drivers-experimental-{304,310} packages going away?
[10:41] <Laney> ah, I see the bugs, yes
[11:06] <tseliot> Laney: yep
[11:14] <cjwatson> Sigh, more dep-wait
[11:14]  * cjwatson syncs haskell-readargs for haskell-basic-prelude
[12:06] <infinity> doko: Are you still checking rdeps for https://bugs.launchpad.net/ubuntu/+source/ecj/+bug/1165915 ?
[12:06] <ubot2> Launchpad bug 1165915 in ecj (Ubuntu Raring) "FFe: update ecj to a version supporting Java7" [Undecided,Incomplete]
[12:06] <doko> infinity, yes, done, now need to fix openjdk :-/ in progress
[12:07] <infinity> doko: Kay, so we're not good to go on the update then?  Can you update the bug to reflect that, and I'll reject the current sync so no one bothers with it until that's sorted?
[12:10] <cjwatson> (Note that you can't resurrect rejected syncs; it'd have to be re-requested.)
[12:11] <infinity> Yeah, not hard to do a new one.
[12:12] <doko> infinity, just reject
[12:12] <infinity> doko: ^-- Already done.
[12:14]  * infinity hugs sagari's gcc-4.7 build time, and wishes he could will a few more of those machines magically into the DC.
[12:30]  * cjwatson removes the haskell-dummy binaries, and all of washngo
[12:30] <cjwatson> actually I removed the haskell-dummy source too
[12:40] <jpds> Packages in -proposed go to -updates after 7 days of maturity when verification is done?
[12:40] <seb128> jpds, correct
[12:41] <jpds> seb128: Parfait, merci.
[12:41] <seb128> jpds, it's a manual process though, so tend to not happen between friday and monday
[12:48] <xnox> jpds: 7 days since publishing in -proposed && verification is done. So e.g. something can be verified on day 3 and published in -updates on day 7. No publishing on fridays, saturday, sundays; unless we can agree and assign people to be online to handle regressions.
[12:56] <xnox> bdmurray: ^^
[12:58] <kenvandine> Laney, that scope file shouldn't have been there to start with, so it's fine
[12:58] <kenvandine> Laney, and it wasn't installed in the previous version
[13:00] <cjwatson> blimey, removing haskell-dummy took about 400KB (of ~29MB) off the uncompressed size of universe/i386 Packages (60KB of 7MB off gzip)
[13:01] <infinity> cjwatson: Impressive...
[13:08] <kenvandine> Laney, i'm re-uploading
[13:09] <kenvandine> i just noticed seb128 had uploaded another change earlier on friday that wasn't included in my upload
[13:09] <Laney> right, k
[13:09] <Laney> just re-trigger the copy
[13:09] <Laney> or was it a manual upload? if so I can fish it out
[13:09] <seb128> kenvandine, yeah, that change was to discard
[13:09] <seb128> kenvandine, it's superseeded by dh-translations use
[13:09] <Laney> indeed
[13:09] <kenvandine> ah, so i didn't need to?
[13:09] <kenvandine> great
[13:09] <seb128> kenvandine, no, it was just a workaround upload to get the template imported
[13:10] <kenvandine> Laney, if you can recover it, that would be great :)
[13:10] <seb128> kenvandine, I would have included it in the merge request otherwise ;-)
[13:10] <kenvandine> ok :)
[13:13] <kenvandine> Laney, i can re-upload if that is easier
[13:16] <Laney> kenvandine: no, it's already done
[13:16] <kenvandine> Laney, thanks
[13:43] <debfx> virtualbox in precise-proposed contains an important bugfix that has been verified and two unverified less important fixes
[13:43] <debfx> do you guys have a suggestion on how to get that fix (compatibility with the lts backport kernel) into -updates?
[13:44]  * cjwatson removes ftphs binaries
[13:44] <debfx> re-uploading it with only that one fix?
[13:50] <cjwatson> debfx: 1031217 doesn't seem as though it should be hard for somebody with a 12.04 host system to verify.  I would be uncomfortable with dropping the patch for 1071344 - but for that I don't think we need to verify the fix, just regression-test that 64-bit guests still work, right?
[13:58] <debfx> cjwatson: I tried to reproduce 1031217 on precise but failed. It's easily reproducible on quantal so maybe you can trigger the bug with a custom networkmanager config on precise.
[13:59] <cjwatson> failed> as in the new package broke, or you just couldn't reproduce the original problem?
[13:59] <debfx> I couldn't reproduce the origin problem on precise
[14:01] <debfx> *original
[14:06] <ogra_> [14:06] <ogra_> sh: 1: /usr/sbin/ubuntu-touch-android.sh: not found
[14:06] <ogra_> hmpf
[14:06] <ogra_> argh !
[14:10] <ogra_> how embarrasing
[14:10] <cjwatson> looks easy to fix though?  or do you need a BuildLiveCD change ...
[14:10] <ogra_> nah
[14:10] <ogra_> already uploaded
[14:11] <ogra_> just waiting for the bot ...
[14:11] <ogra_> there we go ...
[14:11] <ogra_> still something that makes me blush ...
[14:12] <ogra_> but it seems that BuildLiveCD at least takes the correct path :) thats something
[14:20] <cjwatson> ^- another missing build-dep of haskell-project-template; I think this is the last of them ...
[15:07] <infinity> doko: What are the odd of getting http://sourceware.org/bugzilla/show_bug.cgi?id=14887 fixed before release (or, if you're too busy, mind if I roll/test/upload for that tomorrow?)
[15:07] <ubot2> sourceware.org bug 14887 in gas "Error: ARM register expected -- `str r1,[ r0 ]'" [Normal,Reopened]
[15:07] <infinity> doko: I'm not sure how many build faiures we have (or have fixed) as a result of that, but I know there's a couple.
[15:08] <doko> infinity, ok, will fix it today
[15:08] <doko> infinity, I assume you won't target a glibc update anymore?
[15:08] <infinity> doko: If you have an ARM machine to test on, gmp is a good test-case.
[15:09] <infinity> doko: I'm going to do one last conservative glibc upload tomorrow.
[15:09] <doko> infinity, no, bus errors for everything now
[15:09] <infinity> doko: Oh, that sucks. :/
[15:10] <doko> xnox, yeah for the arm assembler openssl issue ...
[15:10] <infinity> doko: LP bug for that binutils PR is https://bugs.launchpad.net/binutils/+bug/1166628
[15:10] <ubot2> Launchpad bug 1166628 in binutils (Ubuntu) "New compile error on ARM" [Undecided,New]
[15:13] <ogra_> hrm
[15:13]  * ogra_ wonders if he killed kapok.buildd
[15:13] <xnox> bdmurray: are you accepting openssl/precise as well at the same time? or do you want to publish quantal fully first?
[15:14] <ogra_> infinity, hulp ...
[15:14] <bdmurray> xnox: I'm getting to the precise one
[15:14] <infinity> ogra_: Define killed...
[15:14] <xnox> bdmurray: =)))) ok, thanks.
[15:14] <cjwatson> ogra_: still responds to HTTP
[15:14] <ogra_> cdimage@nusakan:~$ ssh -n -o StrictHostKeyChecking=no -o BatchMode=yes buildd@kapok.buildd /home/buildd/bin/BuildLiveCD -t android mako
[15:14] <ogra_> /home/buildd/bin/BuildLiveCD: fork: Cannot allocate memory
[15:14] <infinity> Hah.
[15:14] <ogra_> and the log is definitely not updated
[15:15] <infinity> Is ubuntu-touch-android.sh a DoS? :P
[15:15] <ogra_> i'm running this script from BuildLiveCD http://paste.ubuntu.com/5710578/ ... the shebang was wrong so i guess the "set -e" has no effect
[15:16] <cjwatson> Not sure how #! and set -e relate
[15:16] <ogra_> you mean it would stop BuildLiveCD ?
[15:16] <cjwatson> Ah, but IIRC there is some curious interaction between '.' and set -e
[15:17] <cjwatson> I forget the details
[15:17] <cjwatson> Do you mean that the version that was running was with #! /bin/sh?
[15:17] <ogra_> nope
[15:17] <ogra_> it was with !#/bin/bash
[15:17] <cjwatson> Ah
[15:17] <ogra_> flipped the chars :(
[15:17] <cjwatson> You might want to ask IS to figure out what state it's in
[15:17] <infinity> webops, rather.
[15:18] <cjwatson> Er, yeah, that
[15:18] <ogra_> theoretically i would expect set -e to stop it
[15:18] <ogra_> though it would probably help if BuildLiveCD had set -e set
[15:19] <ogra_> oh, it has
[15:19] <ogra_> just quite far down
[15:19] <cjwatson> Well, (a) set -e has no effect on things that precede it, (b) not totally sure what !#/bin/bash would do anyway, but if it does nothing then the worst case is probably that the script barrels on with /bin/sh
[15:19] <cjwatson> And in any case set -e in BuildLiveCD is irrelevant here
[15:20] <cjwatson> Since it checks the return code of that command explicitly
[15:20] <ogra_> "sh: 1: /usr/sbin/ubuntu-touch-android.sh: not found"
[15:20] <ogra_> thats the result of my run
[15:20] <cjwatson> Find out what's actually happening on the machine.  Guessing is too hard work.
[15:20] <ogra_> so i would have expected set -e to capture that as error and stop BuildLiveCD
[15:20] <cjwatson> set -e is totally irrelevant to anything here.
[15:21] <cjwatson> The error is inside 'if $LINUX32 sudo chroot ${DIR%/./*} sh -c "cd /${DIR#*/./} && $COMMAND" >> ${LOG} 2>&1; then', which is an explicit check
[15:21] <cjwatson> So that should have gone into the else case, i.e. exit 1
[15:21] <ogra_> oh
[15:21] <cjwatson> set -e only applies to commands whose exit status isn't checked
[15:21] <cjwatson> Like I say, find out what's really happening
[15:22] <ogra_> oh, indeed
[16:57] <cjwatson> grr, another haskell-yesod build-dep
[17:04] <cjwatson> Laney: too slow old man :)
[17:04] <Laney> oho
[17:05] <cjwatson> tantalisingly close now, I think it's just those two syncs above
[17:06] <cjwatson> I removed the haskell-platform binaries
[17:07] <infinity> ogra_: Erm, hold on.  You realise that you're doing things in a chroot that doesn't get deleted, right?
[17:07] <infinity> ogra_: So, you're adding a bunch of cruft that never gets removed.
[17:07] <Laney> To an extremely well tested Haskell suite in 13.04 *ahem*
[17:08] <cjwatson> Hey, it builds.
[17:08] <cjwatson> Mostly.
[17:08] <infinity> That's about as tested as it usually is.
[17:08] <Laney> spoken like a true functional programmer
[17:08] <ogra_> infinity, hrm, so should i debootstrap my own ?
[17:09] <ogra_> i thought that one comes from a tarball freshly unpacked on every build
[17:09] <infinity> ogra_: No, they definitely don't unpack fresh ones.
[17:10] <ogra_> ok
[17:10] <infinity> ogra_: The other curiosity is, if the build depends on i386 packages, why don't you build it on an i386 buildd?
[17:10] <ogra_> i'll debootstrap then
[17:10] <infinity> ogra_: Instead of focing multiarch on amd64?
[17:10] <infinity> s/focing/forcing/
[17:10] <ogra_> infinity, because the android tools expect an amd64 builder
[17:10] <infinity> ...
[17:10] <ogra_> yeah
[17:10] <ogra_> its all pretty awful
[17:10] <infinity> They expect an amd64 builder and i386 binaries?
[17:10] <ogra_> ask rsalveti :)
[17:11] <infinity> That sounds positively insane.
[17:11] <rsalveti> yup, it's indeed
[17:11] <ogra_> the tree also ships its own toolchain etc ...
[17:11] <ogra_> its all pretty insane
[17:11] <rsalveti> android way of doing it
[17:11] <doko> ?
[17:11] <doko> pff
[17:12] <ogra_> android :0
[17:12] <doko> "we only trust our own bugs"
[17:13] <ogra_> infinity, so reject that upload, chrooting all that stuff will take a bit of a rewrite
[17:13] <ogra_> sigh ...
[17:14]  * ogra_ notes that testing  all that stuff locally gained him exactly nothing ... 
[17:15] <ogra_> i know i'm not supposed to test in production ... but replicating the setup seems pretty impossible
[17:15] <infinity> Replicating a livefs builder is easy.
[17:16] <infinity> debootstrap a chroot in ~/build-raring-live/chroot-raring/ ; install livecd-rootfs in it, copy BuildLiveCD out to somewhere you can call it, edit BuildLiveCD to not mail logs all over the place, done.
[17:23] <ogra_> infinity, well, set up an android mirror somewhere in my LAN to pull the 15G tree from, have a local package mirror as well etc etc
[17:23] <ogra_> there is followup work :)
[17:28] <ogra_> hmm
[17:28] <ogra_>  chroot $builddir bash -c ". build/envsetup.sh && brunch $codename"
[17:28] <ogra_> would that work ?
[17:28] <ogra_> (to source the needed bits before running the brunch command)
[17:30] <ogra_> oh, crap ... sigh ...
[17:31] <ogra_> i guess i should just inject a script into the chroot ... that will work better
[17:31] <ogra_> since the android bits will likely choke on absolute paths
[17:40] <ogra_> infinity, mind taking a look at http://paste.ubuntu.com/5710991/ before i waste another version number ...
[17:47] <ogra_> hmm, line 14 could just drop the check i suppose ... since i know already i'm on amd64
[18:04] <infinity> ogra_: You might want proc and devpts mounted (and unmounted) in that chroot.
[18:05] <infinity> ogra_: And to start your builds by cleaning out builddir, in case of previous cruft.
[18:06] <infinity> ogra_: Otherwise, if that passes a local test, go nuts.  I'm not actually here today (and about to be a lot less here), so...
[18:06] <ogra_> ok
[18:07] <ogra_> ah, i just added proc and sys mounting ... forgot devpts :)
[18:07] <ogra_> thanks !
[18:16] <mdeslaur> can I upload a security fix for haproxy?
[18:16] <ScottK> mdeslaur: Yes
[18:16] <mdeslaur> ScottK: thanks
[20:05] <phillw> with the dropping of alternate from all but lubuntu and server, is it still flagging up an issue where sudo /cdrom/cdromupgrade still then attempts to download over the internet instead of using the CD image?
[20:05] <phillw> *is still worth flagging up*
[20:06] <cjwatson> If it exists it should work
[20:06] <cjwatson> There's the question of whether it's worth keeping that script on the images if it's only on a small number of images and thus not well-tested
[20:08] <cjwatson> But that doesn't mean it isn't a problem as it stands, based on that report
[20:09] <phillw> thanks cjwatson It's been a while since I've used an alternate image. I followed the instructions at http://linuxpoison.blogspot.co.uk/2011/06/how-to-upgrade-ubuntu-using-alternate.html and all went well until It decided to go and download stuff instead of using the ISO image that was mounted.
[20:10] <phillw> I'd guess it is more an issue for server, where they may want to do a mass upgrade. I've not tried the update ISO yet.
[20:10] <cjwatson> Realistically I can't imagine server users wanting to upgrade from a CD
[20:10] <cjwatson> cdromupgrade was always a desktop-user use case
[20:11] <cjwatson> Indeed I believe that cdromupgrade is not on the server image
[20:11] <cjwatson> Because it can't work off the squashfs-base system
[20:13] <phillw> cjwatson: that's fine. I'll try using the upgrade iso :) As ever, thank you for your time.
[20:14] <cjwatson> there's no separate upgrade ISO ...
[20:15] <phillw> cjwatson: There are lots of them at http://iso.qa.ubuntu.com/qatracker/milestones/243/builds :)
[20:16] <phillw> lubuntu has not yet tested our set, I was just curious as to if the alternate still worked :)
[20:16] <slangasek> no, there aren't; those are the tests for upgrading the OS, there is no "upgrade ISO" for any of these
[20:17] <phillw> slangasek: sorry, you are entirely correct! there is no ISO!
[20:17] <Laney> ghc.html looking nice
[20:17] <phillw> Hmm, okies. So cannot upgrade using iso. not to worry :)
[20:18] <stgraber> Laney: is that a good thing? It felt like the goal with ghc was to have it in some kind of constant transition ;)
[20:19] <slangasek> stgraber: "looking nice" is subjective, of course; he didn't say it was looking empty ;)
[20:19] <Laney> true, I'd better upload a new ghc :-)
[20:20] <Laney> Also looks likely that the autohinter will manage to transition it
[20:20] <stgraber> slangasek: oh indeed ;)
[20:20] <cjwatson> Laney: Yep, it should do it this run
[20:20] <cjwatson> Just waiting for the publisher
[20:20]  * Laney is impressed
[20:21] <cjwatson> If you don't want that you'd better block it quick ;-)
[20:21] <Laney> and slightly sad that we don't get to construct a monster hint
[20:21] <cjwatson> I think I can do without that
[20:21] <Laney> seems that the gitit workaround didn't do the trick though
[20:21] <Laney> ho hum
[20:22] <cjwatson> Laney: That's just because I'm an idiot - I'm uploading a fixed version to experimental as I type
[20:22] <cjwatson> Forgot that $? is spelled $$? in make
[20:22] <Laney> oh, nice
[20:41] <cjwatson> final: agda,agda-stdlib,cpphs,darcs,ghc,[...]
[20:41] <cjwatson> CLANG
[20:41] <cjwatson> SUCCESS (552/0)
[20:43] <doko> a beer for every migrated package \o/
[20:43] <Laney> glorious
[20:44] <cjwatson> Not sure Laney's and my liver combined can handle 552 beers
[20:44] <Laney> Might prevent us having to do this ever again if we try
[20:45]  * cjwatson watches ackee try to keep up with the copies
[20:49] <cjwatson> Even promote-to-release hasn't finished yet, and it's asynchronous!
[20:49] <doko> interesting times for debian unfreezing ...
[20:54]  * Laney starts receiving emails
[20:55] <cjwatson> And I think it's done
[20:56] <balloons> maybe it's better asked in here.. I'm helping get ubuntu touch added to the isotracker. So you should see a new family 'ubuntu touch' and products being listed.
[20:57] <balloons> this doesn't affect the raring manifest, but I did want to make sure we got or have a product owner lined up for these
[21:07] <cjwatson> Shockingly, this publisher run might take a while
[21:16] <skellat> ScottK: Mark appears to have spoken: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1169238
[21:16] <ubot2> Launchpad bug 1169238 in Unity "[UIFe] BFB icon swirl should run clockwise not anti-clockwise" [Undecided,Triaged]
[21:26] <phillw> skellat: why was that a surprise?
[21:27] <phillw> I actually agree with him (and that is a rare comment from me :P )
[21:50] <sarnold> hello; in the course of preparing a security update for curl for our supported distributions, I have also prepared a new package for raring, containing the back-ported security fix from upstream.
[21:50] <sarnold> is it okay to push this package to raring?
[21:53] <Laney> yes
[21:53] <sarnold> thanks Laney
[21:53] <Laney> np!
[22:00] <cjwatson> ... and update_excuses is readable again, yay
[22:00] <Laney> surprised I only got 21 copies apparently
[22:01]  * Laney attempts to bootstrap a codesearch instance
[22:07] <doko> $ wc -l update_output.txt
[22:07] <doko> 22 update_output.txt
[23:39] <doko> my bad ...