[00:32] <robru> anybody from the release team around? i'm confused by the status of python2.7 in update_excuses. 2.7.6-2ubuntu1 fixes a big regression for us, we need that ASAP
[00:36] <rsalveti> doko: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libffi failed autopkgtest
[00:36] <rsalveti> which seems to be holding python2.7
[00:38] <rsalveti> there was a sync from git-annex today, which is holding everyone
[00:39] <robru> rsalveti, is it something you can fix? who do we ping about this?
[00:40] <rsalveti> let me first try to understand why it's failing
[00:40] <robru> rsalveti, ok, brb. ping me if you need help testing anything.
[00:41] <rsalveti> seems the tests are all fine, but the ret code is not 0
[00:44] <xnox> rsalveti: let me look at annex failure.
[00:44] <xnox> rsalveti: i've fixed it before....
[00:45] <rsalveti> xnox: ok, cool
[00:47] <xnox> rsalveti: i see http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-git-annex/10/ARCH=amd64,label=adt/artifact/results/dsc0t-basics-stderr/*view*/ that no tests run, since new version was uploaded.
[00:48] <rsalveti> right https://jenkins.qa.ubuntu.com/job/trusty-adt-git-annex/ARCH=amd64,label=adt/10/console
[00:49] <rsalveti> indeed, was opening the last successful one
[00:50] <xnox> Laney: stgraber: can you mark up git-annex as bad tests? I've opened block-proposed bug #1256143 to make sure that git-annex doesn't migrate, but such that dependencies are unblock to migrate?
[00:50] <ubot2> Launchpad bug 1256143 in git-annex (Ubuntu) "adt tests borked in -proposed" [High,Triaged] https://launchpad.net/bugs/1256143
[00:52] <xnox> rsalveti: are you touch-release?
[00:52] <xnox> rsalveti: touch-release can also mark up git-annex as badtests
[00:52] <rsalveti> xnox: nops
[00:52] <rsalveti> cyphermox: ?
[00:53] <rsalveti> maybe even robru
[00:54] <xnox> rsalveti: hm, possibly britney will request git-annex trusty-release pocket adt tests and everything will work. this is what happened, last time i requested a block-proposed bug.
[00:56] <xnox> rsalveti: actually git-annex is not the only problem. libffi is out of date on powerpc
[00:56] <xnox> rsalveti: and python2.7 is invalidated by dependency on libffi.
[00:57] <rsalveti> yeah, ftbfs for ppc
[00:57] <robru> rsalveti, xnox: i dunno anything about that...
[00:58] <xnox> rsalveti: robru is not in https://launchpad.net/~ubuntu-touch-release/+members
[00:58] <xnox> rsalveti: anyway, libffi/powerpc should be fixed.
[00:58] <robru> cyphermox, you around? we need you ^^
[00:59] <rsalveti> there's no git-annext test anymore
[00:59] <xnox> robru: even if git-annex is forcedbad tests, libffi must be fixed, cause otherwise there will be huge archive skew.
[00:59] <rsalveti> seems they removed the test option with latest version
[01:00] <robru> xnox, any idea how to fix libffi? i've no idea
[01:00] <xnox> robru: rsalveti: well ffi has missing symbols. not sure why/how.
[01:57] <xnox> infinity: git-annex test-suite is pending more haskell "echo test suite currently disabled until haskell-tasty is out of NEW"
[01:58] <xnox> infinity: can you please mark git-annex as badtest? git-annex itself is blocked from migrating by my block-proposed bug, such that we will get new git-annex, only once it has autopackagetest again, but such that it doesn't block the world.
[01:58] <xnox> (well speficially python2.7 and libffi)
[01:59] <infinity> xnox: Can do.
[01:59] <xnox> infinity: thanks.
[02:00] <infinity> # git-annex is blocked with a migration bug, don't block its rdeps too:
[02:00] <infinity> force-badtest git-annex/5.20131127.1
[02:00] <infinity> ^-- That look sane?
[02:00] <xnox> coreect.
[02:00] <xnox> correct that is.
[02:01] <infinity> Test-building libffi out of paranaoia, but will upload shortly.
[02:06] <infinity> Alright, I'm not sure who between my ISP and Canonical is screwing with me, but this is unaccetable:
[02:06] <infinity> Fetched 23.0 MB in 4min 1s (95.4 kB/s)
[02:08]  * stgraber read that as MB/s for a second and wondered what infinity was complaining about again
[02:09] <infinity> stgraber: Yeah, no.  This is genuinely busted.
[02:11] <stgraber> infinity: I'm getting somewhere between 15MB/s and 20MB/s from archive.u.c from this side of the country
[02:12] <stgraber> entirely over Level3 from Montreal to the DC in London
[02:12] <infinity> stgraber: Yeah.  I'm getting decent saturation on my link to random speedtest.net servers, but all of archive/ports and us.archive/us.ports are a mess for me.
[02:12] <infinity> (Yes, even the US ones)
[02:13] <infinity> Not sure who to blame.  I'll care deeply if it persists after I move, and start whining.
[02:13] <robru> infinity, you on Shaw? Shaw I think has a vendetta against Ubuntu, they will often drop canonical's netblock right off the network (100% packet loss for days), and most of the rest of the time it's very slwo
[02:14] <stgraber> infinity: interestingly enough I'm only getting 1.5MB/s from us.archive.u.c over IPv4 but I get 50MB/s from the same servers over IPv6...
[02:15] <stgraber> ah, IPv4 from here to Boston goes through Level3 (same path as to London) but then jumps to Cogent in New York which gives me a final route longer than that to London and the speed that's typical for a Cogent provided link...
[02:16] <stgraber> infinity: weren't you using a server in the US for the *.ubuntu.com trafic before?
[02:19] <infinity> robru: I am indeed.
[02:20] <robru> infinity, it's a conspiracy. Microsoft pays Shaw to give us shit service.
[02:20] <infinity> stgraber: I was tunneling through San Jose for a long time, yeah.
[02:20] <infinity> stgraber: (Through the machine I'm IRCing from)
[02:20] <infinity> I may have to go back to doing that.
[02:20] <infinity> But things had been okay for so long.
[02:20] <infinity> *sigh*
[02:22]  * infinity tries to decipher gv.shawcable.net and gives up.
[02:22] <infinity> Greater Victoria?
[02:23] <infinity> Grungy Vatican?
[02:24] <stgraber> Vancouver (if so, you're not heading the right direction ;))?
[02:24] <infinity> stgraber: Vancouver is vc.
[02:24] <infinity> stgraber: But robru lives in Victoria, apparently, so my first guess might be close.
[02:25] <robru> infinity, greater vancouver?
[02:25] <robru> infinity, I used to live in Winnipeg and had problems with Shaw there, too
[02:25] <infinity> robru: If you mean the island and not the city, maybe.  (As I said, Vancouver itself is ".vc." in shaw routing speak)
[02:26] <infinity> Maybe granville.  The few, the proud, the drunk.
[02:26] <robru> infinity, gisland vancouver ;-)
[02:32] <infinity> Hrm.  Something very bad has happened to birch.
[02:32]  * infinity stabs it with a fork.
[02:34] <infinity> xnox: libffi fix uploaded.  Good thing I tested, I missed one spot the first time. :P
[02:35] <infinity> doko_: Feel free to sync my libffi changes to Debian at any point.  Fixes the FTBFS on both powerpc and ppc64.
[03:45] <infinity> final: gambas3,glib2.0,libffi,pypy,python2.7,ruby1.9.1,ruby2.0,witty/arm64
[03:46] <infinity> robru: ^
[06:26] <robru> infinity, sweet, thanks a ton
[10:52] <cjwatson> Could somebody review grub2/precise, please?  It's pretty urgent - there's an OEM deadline of 6 Dec for it to be in updates
[11:19] <xnox> cjwatson: uploaded ubiquity into precise-proposed, only changes are automatic dependency refresh, to pick up all the SRUs.
[11:19] <xnox> (netcfg + partman-*)
[11:20] <cjwatson> xnox: partman-* is broken right now, the discard thing
[11:21] <cjwatson> So I'd been holding off until I got round to fixing that
[11:21] <xnox> ah =(
[11:22] <xnox> then reject that upload.
[11:23]  * cjwatson goes to work on that in Debian
[11:23] <xnox> cjwatson: may then instead cherrypick just partman-auto 101ubuntu2.1 for bug #1065281 ? or shall it just wait for discard fixups?
[11:24] <ubot2> Launchpad bug 1065281 in OEM Priority Project quantal "Installer crashed when trying to partition 4k/4k sector hard disks" [High,In progress] https://launchpad.net/bugs/1065281
[11:24] <xnox> wrong bug number.
[11:24] <xnox> i meant cherry-pick for bug #1197766
[11:24] <ubot2> Launchpad bug 1197766 in OEM Priority Project "Different partition layout after recovery with keep home partition" [Critical,Confirmed] https://launchpad.net/bugs/1197766
[11:25] <cjwatson> Just wait, shouldn't take too long
[11:31] <apw> cjwatson, idly looking at the grub change for recovery mode, i note that in the menu entry itself the 'recovery mode' string isn't internationalised (and never has been) i wonder if it makes sense to use GRUB_RECOVERY_TITLE="$(getext...)"
[11:31] <cjwatson> It was internationalised before, and I did use gettext in the code that uses GRUB_RECOVERY_TITLE
[11:32] <apw> oh now i see that is only for hurd, ignore me :)
[11:32] <cjwatson> +             title="$(gettext_printf "%s, with Linux %s (%s)" "${os}" "${version}" "$(gettext "${GRUB_RECOVERY_TITLE}")")" ;;
[11:32] <cjwatson> etc.
[11:32] <cjwatson> Yeah, that wasn't i18ned before in precise (it was in later releases) and I didn't bother to change that in the backport
[11:32] <apw> yeah i am just being dumb and ignoring the filename
[11:33] <apw> sensibly so, doh
[11:33] <cjwatson> xnox: in progress now, I'll just wait for the d-i i18n cron jobs to pick it up
[12:01] <apw> cjwatson, for what it is worth that grub2 diff looks to do what is claimed
[12:02] <cjwatson> Thanks.  Hopefully somebody in ~ubuntu-sru will have a look shortly ...
[12:03] <cjwatson> I dunno, fancy joining that team? :-)
[12:03] <doko> giving one finger, and taking the whole hand ... ;p
[12:03] <cjwatson> I prefer to call it "seeing an opportunity"
[12:04] <apw> :)
[12:28] <sil2100> seb128: thanks for the unity-voice review yesterday! We seemingly fixed all the issues if anything, so, once you have a quant of time... just a glance ;) Thank you and sorry for bothering!
[12:28] <seb128> sil2100, ok, sure, let me have another look
[12:35] <cjwatson> stgraber: queuebot seems ill
[12:35] <cjwatson> I'm sure it should have noticed my partman-basicfilesystems/precise upload from 25 minutes ago by now
[12:35] <apw> perhaps it is eating turkey
[12:41] <doko> cjwatson, pitti, jibel: looking at why gcc-4.8 doesn't migrate ... this looks like a broken 3dpict autopkg test
[12:43] <doko> same for python3.3, broken misaka autopkg test
[13:45] <jibel> doko, I forced results of misaka and 3depict to pass, they failed because their testsuite is broken.
[13:47] <xnox> jibel: i think i'll upload 3depict disabling it's tests. As it doesn't actually test as-installed binaries what's so ever. and if a package FTBFS we will notice it on updates / soname-transitions / archive rebuilds.
[13:49] <jibel> xnox, sounds good, and the maintainer said he wouldn't have time to fix it in the coming weeks.
[13:50] <xnox> jibel: adt compile tests make sense only for libfoo-dev packages, where actual as installed -dev package is test compiled.
[13:50] <xnox> jibel: jenkins does notice when adt tests removed?
[13:53] <jibel> xnox, no it must be removed manually
[13:53] <xnox> jibel: i guess it makes sence, removed adt tests may mean a regression.
[14:04] <jibel> xnox, indeed, there are more cases where adt tests have been removed by mistake than dropped on purpose.
[14:41] <cjwatson> ... ah, another KDE SC upload, that's why my builds aren't happening :-)
[14:49] <timchen119> hi, anyone in sru team can help me on this bug ? https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1244065 I'd like this backport to precise.
[14:49] <ubot2> Launchpad bug 1244065 in OEM Priority Project "Add more options to the power settings menu" [Critical,Confirmed]
[15:23] <shadeslayer_> cjwatson: hehe
[15:23] <shadeslayer_> it's the time of KDE SC releases \o/
[15:44]  * ogra_ glares at trusty-changes ... hmmm, 169 mails in 1.5h 
[15:44] <ogra_> ok, it's KDE day ...
[15:48] <xnox> wow we have multi-cpu fields =) that's nice
[15:49] <cjwatson> Yep, thanks to wgrant :-)
[15:49] <cjwatson> The queue lengths are wildly wrong now because they don't really know about that, but he said he was going to fix that next week
[15:53] <seb128> timchen119, I've sponsored that g-c-c SRU, with the template on launchpad/translations there, it should be doable as a SRU along the next langpack update
[15:54] <timchen119> seb128, awesome, thanks!
[17:12] <cjwatson> I would suggest not NEWing fakeroot
[17:12] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730792
[17:12] <ubot2> Debian bug 730792 in libfakeroot "libfakeroot: tries to overwrite libfakeroot-sysv.so, which is also in package fakeroot 1.20-1" [Serious,Fixed]
[17:13] <cjwatson> The next auto-sync should bring in -3 and fix it
[17:15] <cjwatson> in fact how about I just reject the binaries
[17:16] <infinity> libfakeroot?  multiarchified fakeroot?
[17:16] <cjwatson> Yeah
[17:16] <infinity> Fancy.
[17:17] <infinity> I wonder what that will end up breaking.
[17:28] <robru> infinity, cjwatson: hey, can you have a look at glib2.0 in update_excuses? there's a failure listed there, but when i click through to the jenkins log, it actually looks like the failure exists with the version already in main, not the version in -proposed. we need to get the version in -proposed released because it fixes a big regression on the phone.
[17:29] <sil2100> seb128: hello! I was browsing through and noticed that some of the glib2.0 autopkg tests seem to be failing - do you know anything about it ?
[17:29] <robru> sil2100, lol ;-)
[17:29] <sil2100> robru: ;D
[17:29] <ogra_> robru, see #ubuntu-desktop, Laney is on it
[17:29] <Laney> haha
[17:30] <sil2100> Laney: thanks!
[17:30] <sil2100> :)
[17:30] <robru> Laney, also thanks ;-)
[17:30] <Laney> Yeah, it doesn't really scale to ping release team guys btw
[17:30] <Laney> can you retry tests?
[17:30] <Laney> I think we should try it again in the hope that it gets the right version ...
[17:31] <robru> Laney, I confirmed on my device that the version in -proposed fixes the regression that got into main
[17:31] <Laney> I believe that part
[17:31] <Laney> the autopkgtests are testing the whole thing though
[17:32] <robru> Laney, i don't understand the failure though. looking here: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/ARCH=amd64,label=adt/ the only red one is 'trusty/main', all the 'trusty-proposed' ones are green
[17:32] <Laney> it tested an old version of the tests against the new library for some reason
[17:33] <infinity> robru: Hrm?  I see a red trusty-proposed/main
[17:33] <infinity> (But yes, the version mismatch thing is a weird oops)
[17:34] <robru> infinity, I see red trusty-proposed here: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/ but that's a different link
[17:34] <infinity> Also the link that's linked from excuses, so probably the one that matters here. :)
[17:35] <robru> infinity, yeah, but i clicked through to the red amd64 failure and that's where it says the failure is only in main
[17:36] <Laney> robru: do you have permission to retry them one more time?
[17:36] <robru> https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/ARCH=i386,label=adt/ even here the latest trusty-proposed is green
[17:37] <robru> Laney, nope, I only do q-jenkins, that's d-jenkins
[17:40] <cjwatson> BTW please stop saying "main" in opposition to "-proposed" - they're different categories and that's extra-confusing
[17:40] <Laney> Ok, I pinged cj ohnston to retry it once more - if the same happens again then someone can force-badtest it since it has now passed on both architectures
[17:40] <cjwatson> you probably mean "release"
[17:41] <robru> cjwatson, yes, that one
[17:41] <cjwatson> or "trusty" or "the release pocket" or something
[17:41] <cjwatson> "main" is in opposition to "restricted", "universe", "multiverse"
[17:41] <infinity> cjwatson: The confusion is likely because jenkins shows the component, so you see "trusty-proposed/main" and "trusty/main".
[17:41] <cjwatson> this has been a public service announcement on behalf of the commission for confusing terminological schemes
[17:43] <ogra_> lol
[17:43] <Laney> tune your radios to http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/23/ARCH=amd64,label=adt/console
[17:45] <Laney> Seems to have the right tests now
[17:51] <Laney> looks like it passed that time
[17:52] <Laney> if britney doesn't notice that for whatever reason then someone can force-badtest it
[17:52] <Laney> got to go now, see you
[17:53] <robru> Laney, thanks