[05:17] <siretart> mdeslaur: FYI: I've released libav 0.8.8 and libav 9.8 yesterday night
[05:24] <glitchd_> hello all
[07:09] <dholbach> good morning
[07:54] <mwhudson> turning a pile of .deb files into something i can point apt-get at means apt-ftparchive, right?
[07:56] <rbasak> mwhudson: right
[08:00] <dholbach> hey mvo, do you think you could take a look at lp:~evfool/update-manager/lp1079136?
[08:00] <dholbach> @pilot in
[08:08] <mwhudson> rbasak: i even made it work!
[08:08] <mwhudson> unfortunately the packages i built are for raring and i'm trying to install them on quantal...
[08:09] <rbasak> mwhudson: sbuild is your friend :)
[08:11] <dholbach> can somebody please reject https://code.launchpad.net/~malizor/ubuntu/saucy/ubuntu-wallpapers/fix-for-1177260/+merge/171911?
[08:12] <mvo> dholbach: sure!
[08:12] <dholbach> thanks mvo
[08:12] <dholbach> mvo, lp:~dylanmccall/update-manager/dialogs-refactor too please :)
[08:13] <seb128> dholbach, mvo: good morning my german friends, how are you?
[08:13] <dholbach> doing well - how about you?
[08:13] <seb128> I'm good thanks, summer finally arrived!
[08:13] <mvo> hey seb128! I'm good, how are you?
[08:13] <seb128> mvo, I'm good thanks ;-)
[08:13] <seb128> mvo, do you have months of holidays for summer break like student? ;-)
[08:15] <seb128> mvo, oh, the internet says it's not summer break in germany yet ... that just started in France
[08:16] <Laney> haha, for staff at universities that is when the real work happens
[08:17] <seb128> I see :p
[08:17] <seb128> dholbach, that gconf sync request is buggy, you can invalid it
[08:18] <dholbach> seb128, it could be changed to be a merge(?)
[08:18] <seb128> yes
[08:18] <dholbach> not sure if obounaim is up for that though
[08:18] <seb128> though I wouldn't trust somebody who overlooked most of the work to do this merge correctly...
[08:18] <seb128> I will review it if he does it
[08:18] <seb128> let's see ;-)
[08:19] <dholbach> done
[08:19] <mvo> seb128: yeah, no holidays for me :(
[08:19] <seb128> mvo, :-(
[08:32] <devinceble>  Does qtdeclarative5-hud1.0 library present on 13.04 or 13.10 only?
[09:19] <Noskcaj> what do i do for a needs packaging bug that already has a .deb file automatically made
[09:38] <smb> Are the problems with the time&date and privacy (at least) settings dialogues in S already known? Those seem to be unusable right now.
[09:38] <marga> ev, I'm having issues with whoopsie in precise, which is getting re-installed even though I had previously removed it, likely due to a new ubuntu-desktop release.  The issue is that both installing and removing the package crash my X session.  I've narrowed it down to the user adding/deleting, and I suspect this is due to the /var/crash handling.
[09:38] <marga> ev,  I checked the bugs, expecting this to be reported, but it's not, so I'm unsure if it's something specific to my setup, or so recent that nobody else has seen it/identified it yet.
[09:39] <marga> Just adding the user with the command line in the postinst script crashes my session...
[09:40] <ev> marga: that sounds like something is demonstrably broken in your setup. Calling adduser shouldn't bring down your X session.
[09:41] <ev> And if it does, the bug definitely isn't in whoopsie.
[09:41] <yofel> hi, is there someone that knows why gdk_x_error() is fatal?
[09:41] <yofel> Context: bug 1195007 is a nasty SRU regression in raring for KDE applications running under Unity/Gnome caused by the fix for bug 1180067
[09:41] <yofel> I'm kinda lost on what the proper way to resolve this would be.
[09:45] <marga> ev, you are right.  I just tried it and adding or removing any users kills my X.  So it's not whoopsie.  Sorry for the false ping.
[09:45] <ev> no worries
[10:14] <dholbach> @pilot out
[10:18]  * ogra_ hugs dholbach 
[10:18]  * dholbach hugs ogra_ back :)
[10:20]  * smb is grumpy finding Saucy's workspace moving keybindings gone random this morning
[10:20] <cjwatson> yay, glatzor is some kind of superstar.  (example patch for packagekit click backend; will need work but it's a lot easier to iterate on a patch)
[10:22] <dholbach> that's awesome :)
[10:22] <cjwatson> and reminds me that I need to ask for a new mime type
[11:39] <mdeslaur> siretart: great, thanks!
[12:44] <hallyn_> SpamapS: could you please accept https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=qemu-kvm ?
[13:03] <xnox> cjwatson: apachelogger reports that SRU bug 1180067 has caused a regression in raring, see last comment on that bug report.
[13:12] <Riddell> !regression-alert
[13:12] <cjwatson> xnox: OK, not sure I can do a whole lot just at the moment, needs somebody who knows more about it to assess it
[13:12] <Riddell> mitya about?
[13:13] <Riddell> xnox: do you know when he's normally on?
[13:13] <ScottK> Riddell: he's on vacation this week, IIRC.
[13:13] <Riddell> ah
[13:18] <Riddell> I think I'll just upload it with the patch reverted and let mitya fix it when he's back
[13:18] <Riddell> fix isn't super important but regression is
[13:26] <xnox> Riddell: it might be a one-liner fix: http://lists.freedesktop.org/archives/libreoffice/attachments/20120618/582fd1dd/attachment-0001.obj
[13:26] <xnox> this should cause gtk/gdk to ignore all X errors.
[13:28] <xnox> Riddell: but then again, we need to fix it in saucy as well.
[13:30] <ScottK> xnox: I think the SRU regression is more important for the moment.
[13:42] <xnox> Riddell: apachelogger: ScottK: Looking at other uses of gtk_init in qt4, shows that Xerror handler is stored before calling gtk_init, and reset back after. Thus the patch to fix the regression is something like this:
[13:42] <xnox> http://paste.ubuntu.com/5855413/
[13:43] <xnox> not tested yet, building.
[13:45] <apachelogger> xnox: makes sense
[13:52] <Riddell> ScottK: I uploaded qt without the patch to revert bug 1180067 , you could let it through now if you have a moment and we could delete it if xnox gets his patch to work
[13:53] <seb128> Riddell, ScottK, xnox: if any of you feels like doing some qt sponsoring, Mirv was looking for someone to sponsor the saucy qtdeclarative waiting in the sponsoring queue
[13:54] <Riddell> seb128: ok can look
[13:54] <seb128> Riddell, thanks
[13:54] <xnox> Riddell: ScottK: i think raring-updates revert should be published, and my fix should be tested/bake in saucy and can go through as a normal SRU for raring.
[13:54] <ScottK> Sounds reasonable.
[13:55] <ScottK> I just accepted the revert.
[13:56] <xnox> I'm using bug #1195007 as the regression report of bug #1180067
[13:57] <ScottK> OK.
[13:59] <xnox> ev: bdmurray: did / would have errors noticed above regression ^ sru released on 1st of july of qt4-x11, causing rdepends to crash a lot.
[14:01] <bdmurray> xnox: I'll have a look
[15:04] <SpamapS> hallyn_: done
[15:06] <hallyn_> SpamapS: lol!  i had actually *just* decided to re-upload with another fix in it.  But cool, will wait for this one to clear - thanks!
[15:09] <SpamapS> hallyn_: You LOSE. You get NOTHING. GOOD DAY SIR.
[15:11] <hallyn_> SpamapS: ?
[15:11] <SpamapS> hallyn_: not a wonka fan eh?
[15:12] <hallyn_> sorry, haven't seen it.
[15:12] <hallyn_> might have to one of these days.
[15:25] <infinity> rbasak: Hrm.  Someone's going to want to backport this golang 1.1 to older releases, aren't they? :/
[15:26] <infinity> rbasak: Which means I either need to backport my dpkg patch, or make golang *also* add the arch tags.  Bother.
[15:30] <SpamapS> hallyn_: oops, I forgot to actually hit "accept" on qemu-kvm .. so it is just now going through ;)
[15:33] <plars> cjwatson: you mentioned to me a while back that you had a patch to apt to give better debugging of the "something wicked happened" errors, that hasn't made it into saucy yet?
[15:37] <cjwatson> plars: It's in Debian unstable, I think pending a merge
[15:38] <cjwatson> Don't know what mvo's plans are there
[15:42] <ricotz> infinity, hi :)
[15:42] <ricotz> infinity, it is worth you simply retry https://launchpad.net/ubuntu/+source/llvm-toolchain-3.3/1:3.3-3 or would you expect it to fail again?
[15:43] <infinity> ricotz: It'll fail again.
[15:43] <Sarvatt> ^ builds fine on raring, gcc-4.8 fun?
[15:44] <ricotz> it builds on raring without gold though
[15:44] <infinity> So, stop using gold.  We don't use it for 3.2
[15:44] <Sarvatt> ah right, just noticed that
[15:45] <ricotz> infinity, debian introduced it for speed matters
[15:45] <infinity> ricotz: Sure, and we unintroduced it.  I just haven't gotten to 3.3 yet.
[15:46] <infinity> ricotz: Is there some urgency in making 3.3 happy?
[15:46] <ricotz> infinity, alright
[15:46] <ricotz> we want to use it in xedger's mesa
[15:46] <Sarvatt> just mesa git snapshots in a ppa but we can just shove an updated llvm-3.3 in that
[15:46] <infinity> Ugh.
[15:46] <infinity> Does mesa require 3.3? :/
[15:46] <Sarvatt> yep!
[15:47] <infinity> How lovely.
[15:47] <Sarvatt> hell, it'll probably require 3.4 by release in august and we'll have to disable features or add git crap to llvm again like what happened with 3.2..
[15:47] <ricotz> Sarvatt, llvm-3.4 is in saucy too ;)
[15:48] <infinity> Oh, hrm.  That PPC failure is curious, given that it worked on Debian.
[15:48] <infinity> Where did my atomics go in gcc-4.8 on PPC?
[15:48] <infinity> doko: ^
[15:48] <smartboyhw> When does patch pilots go on duty? (Just asking)
[15:48] <smartboyhw> s/does/do
[15:48] <infinity> smartboyhw: When they feel like it.
[15:49] <smartboyhw> infinity, :O
[15:49] <infinity> smartboyhw: We're scheduled by day, ish, but each pilot only puts in a 4h shift (again, ish), and not at a specific time.
[15:49] <doko> infinity, ?
[15:50] <infinity> doko: https://launchpadlibrarian.net/143949118/buildlog_ubuntu-saucy-powerpc.llvm-toolchain-3.3_1%3A3.3-3_FAILEDTOBUILD.txt.gz
[15:50] <infinity> doko: That doesn't happen in Debian.
[15:50] <infinity> doko: Did g++-4.8 do something vile to PPC atomics?
[15:52] <doko> not that I do know. the atomics lib shouldn't be needed on ppc
[15:55] <bdmurray> barry: did you see the regression autocomment in bug 1058884?  It seems unrelated to me.
[15:55] <barry> bdmurray: looking
[16:00] <barry> bdmurray: it could be related
[16:16] <ricotz> infinity, btw, llvm-3.3 is missing the symlinks added in llvm-toolchain-3.2 (1:3.2repack-7) too :\
[17:29] <xnox> infinity: building android with modern gcc & glibc results in: http://paste.ubuntu.com/5855986/
[17:32] <sarnold> xnox: in my x86_64-linux-gnu/sys/ucontext.h the REG_EBP is protected by #ifdef __USE_GNU
[17:36] <xnox> sarnold: yeah, defined, just before including ucontext.h.
[17:36] <sarnold> xnox: ah :/ good luck :)
[17:41] <xnox> sarnold: infinity: http://paste.ubuntu.com/5856022/
[17:41] <xnox> what's wrong? =)))
[19:43] <tvoss> slangasek, ping
[19:58] <mdz> cjwatson, kees, pitti, soren, stgraber: TB in 2 minutes?
[19:58] <cjwatson> yep
[19:58] <stgraber> yep
[19:58] <soren> mdz: Absolutely.
[19:58] <cjwatson> have small child in lap, will see what I can manage
[19:58] <cjwatson> but he seems to have just gone to sleep ...
[19:59] <mdz> looks like we'll manage a quorum
[20:00] <cjwatson> no sign of Rick to talk about the series alias thing though
[20:04] <xnox> sarnold: "Adding the #define before stdio.h does not help, as stdio.h includes features.h which undef __USE_GNU" stckoverflow win =) will apply the fix tomorrow, enough of this for today. So the answer is #include <stdio.h> \n #define __USE_GNU
[20:04] <cjwatson> huh?
[20:04] <cjwatson> no
[20:04] <cjwatson> #define _GNU_SOURCE
[20:05] <cjwatson> you're not meant to define __USE_GNU directly - define _GNU_SOURCE instead and you should be fine
[20:05] <cjwatson> and do so at the very top of the file, before any other preprocessor tokens
[20:05] <cjwatson> stackoverflow is wrong in this case :)
[20:05] <xnox> cjwatson: well that doesn't work.
[20:06] <cjwatson> I've used _GNU_SOURCE a lot, it certainly works in general.
[20:06] <xnox> never mind, it does with "-m32"
[20:06] <xnox> cjwatson: now I wonder, why android went for __USE_GNU instead of _GNU_SOURCE.
[20:11] <sarnold> xnox: oh! excellent :)
[20:12] <xnox> sarnold: but, moving the guards to the beginning of the file and #defining _GNU_SOURCE as per cjwatson works better.
[20:13] <xnox> Quote of the day: "Don't ever define __USE_GNU directly" From: Jakub Jelinek
[20:14] <sarnold> ooh
[20:14] <sarnold> that sounds like a good one to remember. :)
[20:14] <xnox> http://gcc.gnu.org/ml/fortran/2005-10/msg00365.html
[20:23] <manish> ev: ping. please check your mail
[20:26] <slangasek> tvoss: pong
[20:44] <slangasek> bdmurray: what's the best data source nowadays for information about whether users (as a whole) are using binary vs. free drivers?
[20:54] <bdmurray> slangasek: I'm not sure off the top of my head
[20:56] <slangasek> bdmurray: well, what are our options?  The information is in bug reports, right, but I guess that's heavy to query in aggregate... and there's also Ubuntu Friendly which would have something
[20:57] <olli> bdmurray, I assume (would have to do an install myself to verify) that we don't collect HW information during install?
[21:03] <bdmurray> olli: right we do not
[21:04] <olli> bdmurray, oki
[21:04] <olli> do you know whether we can create some insight when looking at the archive & mirrors? might be too cluttered as well I suppose
[21:05] <bdmurray> olli: what is the question you are trying to answer?
[21:05] <olli> bdmurray, :)
[21:05] <cjwatson> you could ask IS for relative stats of some selected package; I don't know how helpful they'll be since installed doesn't say much about whether it's in use
[21:06] <cjwatson> *packages
[21:06] <cjwatson> and indeed we often end up installing more hardware support than is used on a given machine
[21:07] <cjwatson> while it's a sort of odd application, this could be minable from errors.u.c, which would be easier to query in aggregate than bug reports
[21:07] <cjwatson> sounds like an interesting use case for ev's "let developers write hadoop jobs" thing
[21:08] <cjwatson> of course that's skewed, it only tells you what *broken machines* use
[21:08] <slangasek> in the case of the binary drivers, they definitely don't get installed unless selected for use
[21:08] <bdmurray> I'm not certain that errors has the right apport data for that either
[21:08] <cjwatson> right - but you can switch back to something else later and I don't think they get uninstalled
[21:08] <slangasek> they do
[21:08] <cjwatson> oh, all of them?  I thought that was just the gl driver
[21:09] <slangasek> well, we're only talking in the context of X drivers, sorry if that wasn't clear
[21:09] <cjwatson> but ok, if so then IS *might* be able to get something off mirrors
[21:09] <slangasek> X/gl/video
[21:10] <bdmurray> oh, I guess errors has NonfreeKernelModules which may help
[21:11]  * slangasek nods
[21:16] <olli> sorry, didn't see the last comment and http://irclogs.ubuntu.com/2013/07/08/%23ubuntu-devel.txt isn't up to date
[21:17] <olli> major brownout here
[21:17] <slangasek> olli: 14:10 < bdmurray> oh, I guess errors has NonfreeKernelModules which may help
[21:18] <olli> ah
[21:18] <olli> cool
[21:18] <bdmurray> well, looking further something is awry
[21:18] <bdmurray> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/apport/saucy/view/head:/apport/report.py#L312
[21:18] <bdmurray> I don't see it in precise either...
[21:18] <slangasek> bdmurray: the conspicuous absence of the bit that sets the field?
[21:19] <bdmurray> slangasek: right
[21:19] <olli> :)
[21:19] <slangasek> I'm sure I've seen that recently in bug reports, though
[21:19] <slangasek> bdmurray: data/general-hooks/generic.py
[21:19] <slangasek> add_info() ?
[21:20] <bdmurray> ah, great
[21:26] <Selling_FDhypno_> superaffordable erotic hypnosis anyone? :)