[01:30] <Noskcaj> Since requestsync keeps breaking, can someone sync gthumb?
[01:30] <Noskcaj> I fixed the existing delta in the latest upload, and it's only exp because of debian's gtk3.10
[06:15] <pitti> jtaylor: I enabled doko's PPA which sets the default to 3.4 (https://launchpad.net/~ubuntu-toolchain-r/+archive/python3)
[06:16] <pitti> dobey: FTR, apport is reporting to LP again in trusty; I'll look at the MarkForUpload bug today
[06:16] <pitti> Good morning
[06:20] <pitti> cjwatson: is it still true that "Packages in
[06:20] <pitti>       the base system may not use bzip2"
[06:20] <pitti> ?
[06:20] <pitti> cjwatson: (from libpng's merge changelog)
[06:27] <cjwatson> pitti: I'd prefer to keep that; the problem is that it limits the use of debootstrap to bootstrap Ubuntu on non-Debian/Ubuntu systems
[06:28] <pitti> cjwatson: ok, thanks; so we'll keep that (the other delta is gone now, that's why I asked)
[06:28] <pitti> cjwatson: and, early for you!
[06:28] <cjwatson> pitti: also, it breaks debootstrap in d-i (which could be fixed by reconfiguring busybox, but we'd still run into the above)
[06:28] <cjwatson> pitti: about to get a train to the core sprint in London
[06:29] <cjwatson> so injecting coffee ..
[06:29] <pitti> cjwatson: ah right
[07:11] <pitti> wgrant: do you know why https://launchpad.net/debian/+source/bzr-upload still hasn't picked up 1.1.0-4? It got uploaded to sid two days ago
[07:32] <mitya57> xpdf/experimental from 2 days ago also isn't picked up for some reason
[07:45] <pitti> same for cups; it looks like autoimport is generally not working?
[08:06] <mitya57> pitti: Does bug 1273075 break some packages? (If yes, then I probably should apply it in Debian as well)
[08:08] <pitti> mitya57: autopilot AFAIK (that's why I backported the fix, on veeber's request)
[08:09] <pitti> mitya57: it's just a backport from upstream, so it'll get into Debian sooner or later anyway; but of course feel free to backport it as well
[08:09] <mitya57> Then it's not urgently needed in Debian :)
[08:09] <pitti> mitya57: yes, that's what I thought
[08:24] <dholbach> good morning
[08:27] <dholbach> Laney, happy birthday!
[09:02]  * Laney hugs dholbach 
[09:03] <wgrant> pitti, mitya57-mobile: I think our internal Debian mirror is out of date. Will investigate once IS appears.
[09:03]  * dholbach hugs Laney back
[09:05] <pitti> wgrant: ah, thanks
[09:18] <slangasek> RAOF: looking at libgusb merge, I see you've added DEB_BUILD_MAINT_OPTIONS = hardening=+all; is there a particular reason to have this delta here?  +all only adds PIE and -Wl,-z,now, neither of which is relevant for a library AFAIK
[09:22] <Laney> hmm
[09:25] <Laney> Is there a path back to fixed image builds? Robert's intention wasn't to bring unity-control-center onto them yet - AFAIK, everything has alternates & the idea is/was to switch the seeds at some point.
[09:27] <Laney> But it looks like having unity-control-center as the primary dep/recommends of things is causing it to be chosen
[09:54] <cjwatson> Laney: explicitly seeding the old one for now might fix things
[09:54] <Laney> cjwatson: it is
[09:55] <Laney> I don't see it in the germinate output though so it looks as if the package relationships are being resolved first
[09:56] <cjwatson> how about gnome-control-center-datetime?
[09:56] <Laney> nope
[09:56] <cjwatson> explicitly seeding that (and uploading ubuntu-meta) might help
[09:56] <cjwatson> since unity-control-center-datetime is being pulled in by indicator-datetime per germinate
[09:57] <Laney> yep, I see that
[09:57] <Laney> worth a try
[10:03] <Laney> this is a ppc64elfest
[11:11] <arges> doko: hi. Do you mind if I take on the sudo merge?
[11:11] <doko> arges, not at all
[11:12] <arges> doko: : ) cool
[12:01] <Laney> cjwatson: looks like that worked
[12:03] <cjwatson> Laney: great
[12:10] <Laney> the mysterious inner workings of OMG I just found a hidden creme egg
[12:54] <mitya57> wgrant: import seems working now, thanks!
[13:14] <wgrant> mitya57: Ah yes, sorry, fixed it to use a different mirror
[13:14] <wgrant> pitti: ^^
[13:21] <Mirv> could I get a core-dev to look at this packaging change before uploading http://pastebin.ubuntu.com/6826135/ . background at https://code.launchpad.net/~timo-jyrinki/qml-friends/fix_qt52_ftbfs_adding_dependencies/+merge/203012
[13:22] <Mirv> I could reproduce the failing build's error message on device, but I didn't find other explanation than that the dependency resolving is complex. that is, friends-facebook already depends on account-plugin-facebook, but only when adding those dependencies explicitly PPA builder got happy.
[13:23] <Mirv> similarly I needed to apt-get install account-plugin-facebook first on the device before friends-facebook was happy to install.
[13:25] <Mirv> what I'd need is an ack (or not) to proceed with uploading that change via cu2d.
[13:40] <highvoltage> 5
[13:51] <pitti> wgrant: splendid, thakn you!
[13:51] <pitti> wgrant: syncpackage now crashes differently, but at least it got further
[13:51] <pitti> ubuntutools.archive.DownloadError: Signature on bzr-upload_1.1.0-4.dsc could not be verified
[13:52] <pitti> wgrant: I'll try again in a bit, supposedly it needs some time to catch up?
[14:37] <smoser> hm.. anyone have an idea here?
[14:38] <smoser> i've got a python program (cloud-init) that runs early in boot.  I'm trying to wait a reaasonable amount of time for a http resource to appear (120 seconds).
[14:38] <smoser> it does that by setting the timeout (default 50 seconds), and then if it times out, adding that to a counter and checking that that counter is < 120 seconds and then trying again if so
[14:39] <smoser> the issue I think is that ntp is kicking in and setting the clock after first reading of the conter
[14:39] <smoser> of the clock
[14:39] <smoser> (i read the clock with time.time())
[14:40] <smoser> so in summary the issue is that reading the clock with 'time.time()', waiting some time, then reading the clock again with 'time.time()'. ends up with time going backwards.
[14:41] <smoser> i could use /proc/uptime for my time reading. but is there any way in python that would be safe to the clock being set backwards ?
[14:44] <arges> infinity: can you take a look at http://people.canonical.com/~arges/sudo/sudo_debian.debdiff
[14:46] <cjwatson> smoser: use python >= 3.3 and you can use time.clock_gettime(time.CLOCK_MONOTONIC) or something along those lines
[14:47] <smoser> yeah. i got that same answer in #python cjwatson.
[14:47] <smoser> thanks.
[14:47] <cjwatson> (there might be better ways, that's just the first that comes to mind)
[14:49] <infinity> arges: Did you test that that LDFLAGS bit was actually still necessary before merging it into a different makefile target?
[14:49] <arges> infinity: no I'll test if that is still necessary
[14:51] <infinity> arges: Oh, nevermind, I now see what it's doing.  Yeah, it's necessary.
[14:51] <infinity> arges: But if there are any new targets, they'd all need it added.  I hope you checked for that.
[14:52] <arges> infinity: yea so the libcommon target was renamed to libsudo_util (found in the changelog)
[14:52] <infinity> arges: Kay.
[14:52] <arges> infinity: that's the only target 'change' and I made sure the LDFLAGS addition was there
[14:53] <infinity> arges: As a nit pick, I'd clean up the mess that MoM made of the Debian changelog at the tail end there.  Not that you did that, it's probably been like that for years.
[14:53] <infinity> arges: I'll review the rest of the merge in a bit.  I need some not-so-fresh air.
[14:54] <arges> infinity: ok.
[14:59] <arges> ok changlog cruft fixed
[15:00] <Laney> Mirv: how can that problem be reproduced?
[15:01] <shadeslayer> dpm: ping
[15:05] <Logan__> infinity: please look at netcdf :)
[15:07] <wgrant> pitti: Hm, shouldn't be any delay. Can you recheck now?
[15:07] <pitti> wgrant: I synced it successfully some 15 mins ago now
[15:08] <seb128> wgrant, hey
[15:08] <wgrant> seb128: Hi
[15:08] <wgrant> pitti: Great
[15:08] <seb128> wgrant, is there any chance you could have a look to https://bugs.launchpad.net/launchpad/+bug/1260754 ? by then you said it should fix itself once the initial import queue was dealt with, but that didn't seem to happen
[15:09] <wgrant> seb128: Do you have an example that hasn't imported in the last couple of weeks?
[15:10] <seb128> wgrant, gtk+3.0 got an upload since, https://launchpad.net/ubuntu/+source/gtk+3.0/3.10.6-0ubuntu3
[15:10] <seb128> but that's more tahn "couple of weeks"
[15:10] <seb128> I can do another upload if you think that's worth trying
[15:11] <wgrant> seb128: Hum, will have a look soonish
[15:11] <wgrant> Thanks
[15:12] <shadeslayer> dpm: would be nice to get https://code.launchpad.net/~dpm/intltool/add-qtdesigner-support/+merge/145112 merged soon
[15:12] <seb128> wgrant, thank you
[15:27] <cjwatson> tseliot: http://people.canonical.com/~ubuntu-archive/pending-sru.html is still looking kinda nasty for nvidia ...?
[15:35] <tseliot> cjwatson: bug #1268027 is not really a regression and we should stop the bot from claiming that verification failed. Speaking of bug #1076414, that should not affect my packages in proposed any more because nvidia-settings will be the only package of its kind. As for bug #1222670, my packages in proposed fix it
[15:36] <cjwatson> bdmurray: ^- can you help tseliot with pacifying the bot?
[15:41] <tseliot> cjwatson: I also uploaded a new jockey for bug #1259237 but if you approve bug #1272311, you'll get that for free
[15:44] <cjwatson> tseliot: it's *really* tight for 12.04.4.  is it absolutely critical for that?
[15:44] <cjwatson> the only way I can get new uploads in in time at this point is to waive the waiting period.
[15:45] <tseliot> cjwatson: it's for hardware enablement and I think we need the code to be in 12.04.4 for our images
[16:11] <cjwatson> tseliot: I think we at least need to get the existing bbswitch in first before superseding it?
[16:11] <cjwatson> oh, it doesn't include bbswitch, hmm
[16:12] <tseliot> :)
[16:20] <slangasek> ogasawara, bdmurray, infinity: update-manager released to quantal; upgrades will now go straight from 12.10 to 13.10
[16:21] <ogasawara> slangasek: ack, thanks
[16:21] <arges> infinity: here's an update: http://people.canonical.com/~arges/sudo/debian_sudo.debdiff
[16:23] <vlad_starkov> Copy-pasted from #ubuntu-kernel:
[16:23] <vlad_starkov> I probably found a bug in some module. Can't boot Ubuntu Server on my machine. It raises CPU soft lockup errors all the time. The system even can't boot.
[16:23] <vlad_starkov> I tried to boot from grml USB flash, and it does almost all the same. But when I tried to boot grml with 'noudev' boot option, the grml has booted just fine and htop shows me all my 8 CPU cores with 0-2% load.
[16:23] <vlad_starkov> What does 'noudev' boot option in my case?
[16:25] <slangasek> vlad_starkov: it's not a standard kernel boot option, the definition of it would be specific to grml
[16:26] <vlad_starkov> slangasek: hmm
[16:27] <cjwatson> bdmurray: bug 1259237
[16:27] <tseliot> cjwatson: oh, and I think
[16:27] <slangasek> vlad_starkov: the most obvious guess, however, is that it doesn't launch udev and let udev load drivers
[16:27] <tseliot> cjwatson: bug #1262238 is required too
[16:27] <cjwatson> tseliot: https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1259237/comments/11 has instructions for you on what to do ... did you try following thenm?
[16:28] <cjwatson> *them
[16:28] <tseliot> right, let me do that
[16:28] <vlad_starkov> slangasek: It seems like reasonable explanation of what is 'noudev'.
[16:28] <zul> mterry:  ping i subscribed the server team oslo.rootwrap to the bugs can we get it MIRed now
[16:28] <vlad_starkov> slangasek: is there anything like 'noudev' for Ubuntu Server?
[16:29] <mterry> zul, OK, thanks!
[16:29] <mterry> zul, will do a pass after lunch
[16:29] <zul> mterry:  cool thanks
[16:32] <vlad_starkov> slangasek: "grml noudev                disable startup of udev (disables module loading)"
[16:34] <dpm> shadeslayer, yeah, I had no success pinging danilo at the time, but perhaps dobey can have a look at it? (https://code.launchpad.net/~dpm/intltool/add-qtdesigner-support/+merge/145112)
[16:34] <slangasek> vlad_starkov: no, there's nothing like that for Ubuntu; it's not a case we would support, so it would only be useful for debugging
[16:36] <vlad_starkov> slangasek: What would be the right strategy to find the buggy module and disable it?
[16:36] <slangasek> not sure, honestly
[16:36] <slangasek> #ubuntu-kernel may have ideas
[16:39] <vlad_starkov> slangasek: there are no answers for the moment on #ubuntu-kernel
[16:50] <pitti> stgraber: autopkgtest email notification is currently broken (ev is on it AFAIK), so relaying: lxc fails its autopkgtest, thus held in -proposed
[16:50] <ev> retoaded: ^ I thought this was fixed?
[16:51] <retoaded> ev, that is part of the smtp-lab.canonical.com time out issue
[16:51] <stgraber> pitti: yeah, I know, it's the lab's fault, I pushed a force-badtest to the hints branch
[16:51] <jibel> pitti, stgraber forced it because test fails due to networking issues and he ran them successfully in an adt environment outside if the lab
[16:52] <stgraber> pitti: juju blew up for unknown reason, jibel is looking into that, lxc failed because of broken network in the lab and some of the debootstrap calls failing
[16:52] <stgraber> both succeeded when run on my own jenkins+buildd so I'm just blaming the lab and forcing stuff through until that's resolved
[16:52] <ev> retoaded: I thought James just checked it was working?
[16:53] <jibel> stgraber, and of course when I try the copy succeeds http://d-jenkins.ubuntu-ci:8080/job/trusty-adt-juju-core/ARCH=i386,label=adt/39/console
[16:53] <stgraber> jibel: hehe, of course :)
[16:53] <retoaded> ev, James checked that the server was up and working but not the connectivity from the lab to it.
[16:54] <jibel> same arch, same host, same base VM
[16:54] <ev> retoaded: can you pursue this and keep pitti in the loop?
[16:54] <retoaded> ev, ack
[16:58] <doko> barry, https://launchpad.net/ubuntu/+archive/test-rebuild-20140127/+builds?build_text=&build_state=failed
[17:22] <doko> barry, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140127-trusty.html
[18:01] <jtaylor> barry: numpy followup, should fix pandas build: https://code.launchpad.net/~jtaylor/ubuntu/trusty/python-numpy/new-upstream-20140124/+merge/203159
[18:37] <YokoZar> Is "new" queue processing anyone in particular's responsibility?
[18:49] <rbasak> YokoZar: The ubuntu-archive team. See: https://launchpad.net/~ubuntu-archive
[19:49] <jtaylor> does ppc64 work with qemu?
[20:07] <vlad_starkov> BUG detected http://paste.ubuntu.com/6828163/
[20:59] <Logan_> I feel like I missed the DMB meeting. That's sad.
[20:59]  * Logan_ checks logs.
[21:01] <Logan_> Looks like Noskcaj was confused. He put himself on the agenda. :P
[21:01] <Logan_> infinity: Did you take a look at netcdf yet?
[22:34] <RAOF> slangasek: Should be fine to drop, that was probably just "shouldn't break anything" leftovers from convincing me that the no-fortify-functions was indeed a false-positive.
[22:36] <juliank> Logan_: Logan__: I still find the autoreconf bug reporting in Debian a bit unfortunate. We now have a usertag   "User: debian-devel@lists.debian.org" "Usertags: autoreconf". It would be nice if you could set them on the bugs you report.
[22:37] <juliank> Possibly manual using the bts tool after you received confirmation from the bts
[22:37] <Logan_> juliank: Yeah, I plan on doing that in batch retroactively to all of my autoreconf bugs. I just haven't had the time so far to get them all in a list.
[22:37] <Logan_> I'll do that ASAP, though.
[22:37] <Logan_> Right now I'm forwarding some more that I did the other day.
[22:38] <juliank> Logan_: OK, thanks, I just wanted to let you know in case doko did not tell you
[22:38] <Logan_> Yeah, he let me know. I've been delinquent in actually doing it. :P
[22:45] <juliank> Logan_: If you do not have a list already, bts status $(bts select submitter:logan@ubuntu.com) fields:bug_num,subject | grep -B1 '^subject.*dh-autoreconf' | awk '/^bug_num/ {print $2}'  gives you one
[22:45] <Logan_> Brilliant. That'll make my life a lot easier.
[22:49] <juliank> Right, you can then just build your usertagging email (or bts command, but email building is easier) by looping over the numbers.
[22:50] <Logan_> Smart. I'll do that tonight.
[22:50] <Logan_> Is there a limit for one email?
[22:51] <juliank> I don't know.
[22:51] <juliank> None you should hit, I think
[22:51] <Logan_> I guess we'll find out. :)
[22:51] <Logan_> Heh, you'll be surprised at how many I've filed.
[22:51] <Logan_> Or maybe you won't, since you apparently get pinged every time. :P
[22:52] <juliank> Yes, if I am on IRC I get pinged. And I know you filed about 180 bugs
[22:52] <juliank> at least the dh-autoreconf ones.
[22:52] <Logan_> Oh wow.
[22:52] <juliank> The other ones are not interesting.
[22:52] <Logan_> I'll try to spice them up then.
[22:54] <juliank> If you want to go crazy, this should generate the entire email: echo "user debian-devel@lists.debian.org"; for bug in $(bts status $(bts select submitter:logan@ubuntu.com) fields:bug_num,subject | grep -B1 '^subject.*dh-autoreconf' | awk '/^bug_num/ {print $2}'); do echo "usertag $bug autoreconf"; done; echo "thanks"
[22:54] <Logan_> I'm not exactly a bash expert, so I was probably going to ask you for a command to generate the email anyway. :P
[22:55] <juliank> You just need to send the output of this command to control@b.d.o
[22:55] <Logan_> I'll do that tonight so I'm sure to pull in the bugs I file today.
[22:56] <Logan_> juliank: Is there any way to make it so that it excludes the ones that already have that tag? :P
[22:57] <juliank> You could select the ones with a tag and then calculate the differences of those sets, but I'd not do that in bash anymore, but rather in Python, as it gets to ugly otherwise.
[22:58] <juliank> But retagging does not hurt, so no real need to worry.
[22:58] <juliank> People do not even get a notification for usertags IIRC
[22:58] <Logan_> Okay, sweet.
[23:01] <juliank> None of your bugs were tagged yet anyway.
[23:01] <juliank> http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=logan@ubuntu.com;users=debian-devel@lists.debian.org;tag=autoreconf is empty
[23:01] <Logan_> True.
[23:01] <Logan_> I'll fix that. :P
[23:03] <juliank> This website should give you a list of all untagged bugs mentioning dh-autoreconf in the subject: http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Adh-autoreconf;submitter=logan%40ubuntu.com;exclude=tags%3Aautoreconf;users=debian-devel@lists.debian.org
[23:03] <juliank> In case the script happens to miss something, you can see it there.
[23:04] <Logan_> Thanks so much for your help!
[23:04] <Logan_> Actually, I'll run it now.
[23:04] <juliank> No problem, it's midnight here anyway, so there's not much else to do.
[23:05] <juliank> Well, OK, sleeping would be an option. But this here is more interesting
[23:07] <Logan_> juliank: So the user command doesn't need the bugs after it as well?
[23:07] <juliank> The user command sets the user, and then each usertag command tags a single bug.
[23:08] <juliank> for the last set user
[23:08] <Logan_> Okay.
[23:08] <Logan_> Sent.
[23:08] <Logan_> Prepare for BTS downtime, lol.
[23:12] <juliank> Seems to have worked.
[23:13] <juliank> Apart from vanessa-socket (736891)
[23:13] <Logan_> Awesome.
[23:13] <Logan_> Yeah, I just filed that one.
[23:31] <slangasek> RAOF: okey-dokey; have dropped it