[00:26] <slangasek> barry: I see bug #911124 is assigned to you; did you sync sphinx from Debian (pulling python-support back into main ;)?
[00:26] <barry> slangasek: i'm on it already :)
[00:26] <slangasek> ok :-)
[04:36] <pitti> Good morning
[04:38] <pitti> tomreyn: no, it's in: update-manager | 1:0.152.25.6 | oneiric-proposed | source, all
[04:48] <pitti> barry, SpamapS: still here?
[04:50] <ajmitch> morning pitti
[05:36] <mbiebl> pitti: morning!
[05:36] <pitti> hey mbiebl
[05:36] <pitti> mbiebl: another early riser :)
[05:37] <mbiebl> you've been up since an hour ago :-)
[05:37] <mbiebl> pitti: just had a look a the pygobject bug
[05:37] <mbiebl> looks like the upload wasn't bug-fix only
[05:37] <mbiebl> http://git.gnome.org/browse/pygobject/commit/?id=ee62df4d2fc0cc63c2f29d3ad9b47b875dbd5f89
[05:37] <mbiebl> this requires glib 2.31
[05:38] <pitti> oh, how's that?
[05:38] <mbiebl> I'm wondering how it built...
[05:39] <pitti> GValue isn't exactly new?
[05:39] <mbiebl> pitti: the _schar functions were added after .30
[05:39] <pitti> /build/buildd-pygobject_3.1.0-1-i386-WbEc0E/pygobject-3.1.0/gi/pygi-property.c:124:13: warning: implicit declaration of function 'g_value_get_schar' [-Wimplicit-function-declaration]
[05:39] <mbiebl> right, that's the one
[05:39] <pitti> mbiebl: indeed; I'll revert that bit then, it doesn't work for chars yet anyway
[05:40] <pitti> mbiebl: thanks for spotting
[05:40] <mbiebl> np
[05:41] <mbiebl> looks like python on the kbsd buildds is borked
[05:41] <mbiebl> at least the test-suite runs into a timeout
[05:41] <mbiebl> the same for pygtk which I uploaded yesterday
[05:41] <pitti> I want to backport some more fixes from trunk anyway
[05:41] <pitti> yeah, saw :/
[05:42] <pitti> mbiebl: still curious how that linked..
[05:43] <mbiebl> I first thought you had built in on precise
[05:43] <mbiebl> when I realised that the other buildds had built it, too
[05:43] <mbiebl> hm, it's a loadable module
[05:44] <pitti> mbiebl: so, sorry for that blunder; will fix right away
[05:44] <mbiebl> nah, np
[05:50] <mbiebl> pitti:  #659184 is the corresponding bug report
[05:50] <pitti> ah, thanks; I just had a look, seems it's not in the PTS yet
[06:08] <pitti> mbiebl: uploaded
[06:12] <mbiebl> pitti: thanks
[07:56] <hyperair> jpds: ping.
[07:56] <hyperair> jpds: would you be interested in getting ubumirror into debian?
[08:18] <pitti> jibel: I believe the current alternate/server failure galore is due to a missing linux-meta upload for -15; I can't prove it, though, there are no useful logs
[08:18] <pitti> apw, smb`: ^ I can haz -meta for -15?
[08:19] <pitti> I'd upload it myself, but that would disrupt your git
[08:19] <jibel> pitti, good morning. right kernel version change.
[08:20] <jibel> pitti, colin uploaded d-i 20101020ubuntu107
[08:20] <pitti> yes, and the seeds are fine, too; just linux-meta missing
[08:21] <pitti> jibel: seems oneiric-universe is again due to bug 917153
[08:21]  * smb looks slightly sleepy
[08:21] <smb> wassa?
[08:22]  * pitti hands smb a cup of steaming coffee
[08:22] <smb> pitti, Thanks, got one in front of me... now I just need to drink it :)
[08:23] <jibel> pitti, re kernel version, i386 passed, isn't it just a matter of respining amd64 to pull latest packages ?
[08:23] <pitti> smb: do you think it's responsible to do a changelog-only package upload at this hour? :-)
[08:23] <pitti> jibel: no, it didn't? https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-oneiric-universe/lastFailedBuild/ARCH=i386,LTS=non-lts,PROFILE=universe,label=upgrade-test/
[08:23] <jibel> pitti, I meant alternate/server install failure
[08:23] <pitti> jibel: oh, sorry, wrong failure
[08:24] <smb> pitti, Certainly not. Not sure _when_ I did the last upload of a kernel package
[08:24] <pitti> jibel: hm, curious how it passed -- it shouldn't
[08:24] <smb> Eh I man I can try again :)
[08:24] <jibel> pitti, packages are not the same version on both arch
[08:24] <smb> If I finally am able to read correctly
[08:24] <pitti> jibel: I figure if we respin now, i386 will fail as well
[08:25] <pitti> jibel: I think I'll wait on smb's -meta upload, and respin when that published
[08:25] <jibel> pitti, k
[08:27] <pitti> jibel: ah, seems lucid->precise got a little further after the qtdbus fix; at least we now have two errors in one log, yay for slight parallelization :)
[08:27] <jibel> :)
[08:31] <pitti> jibel: are you interested in tracking the bugs (just filed 929381, for example), or don't you care?
[08:34] <smb> pitti, Now lets see how much worth that coffee was... Think I uploaded some meta
[08:34] <pitti> smb: AFAIK it's just bumping the version in changelog, no other changes
[08:35] <smb> pitti, It is. And there was something already in git with that
[08:35] <pitti> smb: but as it's in git, us mere mortals can't easily do that
[08:35] <smb> Probably just held back until the compile
[08:35] <diwic> dholbach, ping
[08:35] <pitti> smb: ah, uploaded in ogasawara's name :) thanks
[08:35] <dholbach> diwic, pong
[08:36] <smb> pitti, Yeah, did all the real work anyway :)
[08:36] <diwic> dholbach, two things: First, I vaguely remember me signing up for "writing a launchpad script that summarises ppa owners"
[08:37] <jibel> pitti, I am interested if they are found with automated tests.
[08:37] <pitti> jibel: yes, both are
[08:37] <pitti> (that's where I got them from)
[08:37] <diwic> dholbach, the idea was to contact ppa owners to see if they wanted to step up and maintain the official thing
[08:37] <pitti> jibel: they seem to be at least partially fallout from the kvm envirionment
[08:37] <pitti> jibel: bug 929381, bug 929382
[08:38] <pitti> cgroup-lite installs fine on my real workstation, tryign in kvm now
[08:38] <diwic> dholbach, but I'm overwhelmed with audio bugs, and it feels more efficient if I do the audio bugs and someone familiar with launchpad hacking would do that script
[08:38] <diwic> dholbach, and I can't even find the blueprint. Do you remember which one it was?
[08:40] <diwic> dholbach_, did you get all of that?
[08:40] <dholbach> diwic, pong
[08:40] <diwic> dholbach, repeating in PM
[08:40] <dholbach> no, I'm sorry
[08:40] <dholbach> ok great
[08:41] <pitti> jibel: hm, is /proc/cgroups nonempty in the environment of the upgrader?
[08:42] <pitti> jibel: oh, I figure it's running under a lucid kernel; I'll try reproducing that
[08:45] <jibel> pitti, looking
[08:45] <pitti> jibel: hold on for now, I'll debug this locally first
[08:45] <jibel> pitti, k
[08:49] <smb> pitti, Just from my random playing around with things. Usually when you looked at lxc you were told in the past that you need to mount cgroups somewhere. So I would not find it completely unexpected that some prople will have it in the fstab already.
[08:49] <pitti> smb: ah, so perhaps lxc failed because cgroup-lite failed
[08:50] <smb> pitti, Might be. I remember having seen something (if I could remember the symptoms) coming from automount when in precise cgroups gets mounted before and you still have it in fstabs
[08:51] <smb> Not sure that was detected in the installer...
[08:51] <smb> I mean the problem
[08:52] <smb> Think the upgrade went ok, but on reboot there was something wrong until I cleaned up fstab
[08:52] <pitti> right, I can reproduce on a lucid live system
[08:53] <alkisg> Hi, are there plans to switch thunderbird to the rapid release cycle too, so that we have thunderbird 10, 11 etc  in Lucid? Or that was only for firefox?
[08:54] <pitti> I think it's the plan
[08:56] <alkisg> Thank you :)
[08:56] <pitti> micahg or chrisccoulson will know better
[09:11] <pitti> jibel: hm, I cannot reproduce bug 929382 in a lucid live system
[09:12] <apw> smb, did you do the meta upload?  else will do it shortly
[09:13] <pitti> apw: yes, it's in
[09:13] <smb> apw, done
[09:13] <apw> cool
[09:13] <pitti> https://launchpad.net/ubuntu/+source/linux-meta/3.2.0.15.15
[09:15] <cjwatson> pitti: d-i failed to build on amd64 which didn't help.  I've just uploaded a fix.  I haven't looked at the logs but I doubt linux-meta had much to do with it.
[09:16] <pitti> cjwatson: ah, ok; but it should have independently failed due to the API mismatch, I guess?
[09:17] <cjwatson> that's exactly what the failure was
[09:17] <pitti> cjwatson: thanks
[09:17] <cjwatson> arguably the CD build should have failed but it would still have been a failure :)
[09:17] <cjwatson> not sure why that didn't happen, no time to look now
[09:19] <pitti> cjwatson: np
[09:24] <eitch> join #evince
[10:12] <jacekmigacz> how to remove seat once created by lightdm?
[10:27] <pitti> infinity: it seems https://launchpad.net/ubuntu/+source/libnih/1.0.3-4ubuntu7/+build/3197190 is stuck (didn't change in over an hour)
[10:27] <pitti> could that be killed, and we'll try it again?
[10:46] <pitti> cjwatson, jibel: d-i and linux-meta are published, rebuilding alternate/server
[11:16] <infinity> pitti: Stuck how?  Are you sure you're not just being impatient? :)
[11:17] <pitti> infinity: "stuck" in the sense of https://launchpad.net/ubuntu/+source/libnih/1.0.3-4ubuntu7/+build/3197190 not changing for two hours
[11:17] <infinity> pitti: It historically takes about 4.5 hours on a machine of that class.  I wouldn't complain until it passes that.
[11:17] <pitti> the build should take 1:15 in total
[11:17] <pitti> (the last build did, anyway)
[11:17] <pitti> infinity: but 2 hours to compile a single .c file?
[11:17] <infinity> pitti: The last build was probably on a faster machine...
[11:17] <pitti> infinity: well, if that's "normal", I can certainly just wait further
[11:18] <infinity> I'm willing to believe it's broken, but there are also some things that, yes, will take hours on a single file.
[11:18] <infinity> So, until it passes 5ish...
[11:18] <infinity> https://launchpad.net/ubuntu/+source/libnih/1.0.3-4ubuntu2/+build/2571092 <-- 4.5h
[11:19] <pitti> ack
[11:19] <pitti> infinity: thanks!
[11:19] <infinity> pitti: The good news is that Very Soon Now, all those old machines are going away.
[11:44] <mpt> mvo, hi, did you ever see <https://lists.ubuntu.com/archives/ubuntu-devel/2012-January/034714.html>?
[11:51] <nava> Hi all
[11:51] <nava>  I make a design for let users to choose want to have full screen with luncher or without it. where should i send it ?
[12:00] <pitti> stgraber: I would appreciate if you could take a look at bug 929382 and see whether my proposal would be acceptable
[12:00] <pitti> hallyn: ^ you, too, as the last uploader
[12:01] <pitti> if it is, I'd like to do an upload
[12:14] <mvo> mpt: hello! no I didn't, but I'm also not involved with apt-mirror
[12:15] <mpt> oh, ok
[12:27] <pitti> infinity: ah, done now \o/
[13:00] <lamont> sh: 1: /usr/bin/gdbus: not found
[13:00] <seb128> lamont, install glib?
[13:01] <lamont> seb128: I'm more curious as to why the natural order of things didn't install it for me...
[13:01] <lamont> current precise, mythbuntu box
[13:01] <seb128> lamont, what do you run to get that error?
[13:01] <lamont> apt-get update
[13:02] <lamont> Hit http://us.archive.ubuntu.com precise-updates/universe Translation-en
[13:02] <lamont> sh: 1: /usr/bin/gdbus: not found
[13:02] <lamont> Reading package lists... Done
[13:02] <lamont> to place it in context
[13:03] <lamont> which appears to be apt.conf.d/20packagekit just blindly doing its thing
[13:05] <lamont> I shall file the packagekit bug
[13:05] <seb128> yeah
[13:05] <seb128> what an idea to use that ;-)
[13:07] <lamont> yeah, hopefully it's a more valid bug that my last one. :(
[13:07] <lamont> E: Internal Error, No file name for libc6
[13:08] <lamont> uh... wut?
[13:08] <lamont> (apt is mad about libc6 deps, apt-get -f install fails as above)
[13:44] <melodie> hi
[14:00] <melodie> I am actually editing a page of the wiki containing infos for build requests for Openbox 3.5.0. I will now add imlib2 devel which is an optional lib.
[14:00] <melodie> could someone tell me what is the right name for this package at Ubuntu ?
[14:01] <melodie> http://openbox.org/wiki/Help:Installing
[14:02] <melodie> imlib2 devel when used as a build request allows getting icons in the openbox menus (since 3.5.0) such as here:
[14:02] <melodie> http://i.minus.com/ipNlKuTlCJr25.png
[14:02] <melodie> this is why I am adding it to this page now.
[14:03] <melodie> cking, ? AaronMT ? do you know about imlib2 devel package name please ?
[14:03] <AaronMT> Please dont ping random people.
[14:04] <melodie> you just arrived. sorry (oops)
[14:04] <melodie> :)
[14:04] <melodie> are you angry ?
[14:05] <pitti> melodie: libimlib2-dev
[14:05] <melodie> I thought it was important to let some members of the devel team I will edit this page
[14:05] <pitti> "apt-cache search imlib dev"
[14:05] <melodie> thanks pitti
[14:06] <pitti> -dev is the standard name for development packages in Debian/Ubuntu
[14:06] <melodie> pitti, this is not my distro. I did same at fedora devel chan. just giving info about this edit while looking for the right package name. thanks
[14:06] <pitti> mvo: do you know what's wrong with https://jenkins.qa.ubuntu.com/view/Precise/job/precise-softwarecenter-amd64/ and what it's supposed to test?
[14:06] <pitti> melodie: you can use the same for Debain
[14:06] <pitti> Debian
[14:07] <mvo> pitti: its the software-center testsuite
[14:07] <pitti> melodie: (and Mint, etc.)
[14:07] <melodie> I was just wondering about it : thanks !
[14:07] <pitti> mvo: ah, like running "make check" in a checked out tree?
[14:07] <pitti> mvo: is it supposed to fail, or is that due to running in the autotest environment?
[14:08] <mvo> pitti: its the environment I think
[14:08] <pitti> mvo: well, "supposed to fail" is certainly bogus, I  meant "fail locally as well"
[14:08] <melodie> done : http://openbox.org/wiki/Help:Installing#Dependencies_in_Ubuntu_and_Debian
[14:08] <jibel> pitti, it does a make check
[14:08] <melodie> have a nice day, bye now !
[14:09] <jibel> pitti, and probably failing because a test requires and external resources blocked by a fw
[14:09] <pitti> https://jenkins.qa.ubuntu.com/view/Precise/job/precise-softwarecenter-amd64/45/console is a bit of a messy read
[14:09] <pitti> Unable to find the server at recommender.ubuntu.com
[14:09] <pitti> yeah, seems like it
[14:10] <pitti> DatabaseOpeningError: Couldn\'t stat \'/var/lib/apt-xapian-index/inde
[14:10] <pitti> x
[14:10] <pitti> that seems solvable, though
[14:11] <mvo> pitti: yeah
[14:21] <seb128> hum
[14:21] <seb128> https://bugs.launchpad.net/bugs/929384
[14:21] <seb128> the libc update broken nvidia drivers
[14:22] <seb128> "Happens here too, when running the nvidia-current driver from precise.
[14:22] <seb128> It also makes gnome-shell crash on startup.
[14:22] <seb128> this is caused by the eglibc update (2.13-24ubuntu4 -> 2.15~pre6-0ubuntu10). I reverted it, it's fine now."
[14:26] <tseliot> seb128: I haven't updated the nvidia driver for a while now so eglibc is more likely to be the culprit
[14:26] <hallyn> pitti: that (bug 929382) sounds fine
[14:27] <hallyn> pitti: i think it's what i meant to do
[14:28] <seb128> tseliot, right, I just wonder if the nvidia drivers are doing something weird that lead to issues with the new libc
[14:28] <seb128> or if that's a bug with libc itself
[14:28] <seb128> cjwatson, slangasek, pitti, skaet: ^ nvidia drivers broken by the libc update today
[14:28] <seb128> that let quite some users without a working computer
[14:28] <seb128> not sure what to do about it but I think it should be raised
[14:28] <seb128> that's on precise
[14:29] <tseliot> seb128: maybe we should revert the upload and then I can discuss this issue with Nvidia
[14:30] <seb128> tseliot, not easy as fabian wrote
[14:30] <seb128> "(but reverting this libc6 is not easy as more packages are rebuild for it, leading to failing GLIBC_2.15 version checks everywhere)"
[14:30] <pitti> seb128: that was already with the 2.15~pre version, I take it?
[14:30] <pitti> because 2.15 final is still building
[14:31] <seb128> pitti, yes
[14:34] <rbasak> Is there a way to run sbuild but with an extra local repository added to resolve build dependencies from?
[14:41] <seb128> rickspencer3, is there any official way to raise precise brekages?
[14:43] <rickspencer3> seb128, I'm not sure what you mean
[14:43] <seb128> rickspencer3, the libc update from today break nvidia binary drivers and let precise user without a working machine
[14:44] <seb128> rickspencer3, I mentioned it on the channel but nobody seems to be around
[14:44] <seb128> rickspencer3, is there any official way to flag that we have an issue and should deal with it?
[14:44] <rickspencer3> seb128, can you raise it with the +1 maintenance team?
[14:44] <seb128> rickspencer3, should that be broadcasted in some way so users don't upgrade?
[14:44] <rickspencer3> oh
[14:44] <seb128> rickspencer3, where,who,how?
[14:45] <rickspencer3> is barry barry warsaw?
[14:45] <jelmer> rickspencer3: the one and only
[14:45] <rickspencer3> seb128, also, can you tell skaet, she can use the twitter/identica account to broadcast a "do not upgrade" message
[14:46] <seb128> rickspencer3, I did a 25 minutes ago, waiting for her to be around or reply
[14:48] <Laney> can you get it blocked on the mirrors?
[14:48] <seb128> Laney, I would like to know ;-)
[14:48] <Laney> heh
[14:49] <seb128> but seems none of the rt people are around atm
[14:49] <Laney> #-release informs me that skaet might be in mumble
[14:49] <Laney> go gatecrash :P
[14:49] <skaet> seb128, rickspencer3 - on a call on 10.04.4,  reading backscroll.   Will get on it.
[14:50] <seb128> skaet, thanks
[14:52] <cjwatson> I'm not sure what we can do about libc - as noted, reverting it would cause widespread chaos
[14:52] <cjwatson> do we know precisely why nvidia breaks?
[14:52] <cjwatson> (getting it blocked on the mirrors would be very bad too IMO)
[14:53] <seb128> cjwatson, no, just limited to what is in the bug
[14:53] <seb128> I don't have an nvidia card myself
[14:53] <seb128> but olli and some other people on IRC ran into the bug
[14:54] <cjwatson> there doesn't seem to be a useful stacktrace in the bug
[14:54] <seb128> no :-(
[14:54] <stgraber> yeah, we already rebuilt libnih on the new libc and then uploaded a new upstart, so reverting it would likely break most if not all existing systems.
[14:54] <seb128> I'm not sure we have debug symbols for nvidia binary drivers
[14:56] <cjwatson> I suspect it needs somebody with an affected system who's competent to debug it interactively, at least as far as diagnosing e.g. an affected libc symbol or something
[14:56] <seb128> tseliot, ^
[14:56] <seb128> tseliot, do you have any precise nvidia box, any chance you could look at it?
[14:56] <smoser> hey. i'm in need of some help. bug 929523.
[14:56] <cjwatson> if we're lucky we just need to rebuild something
[14:57] <ahasenack> I have an nvidia desktop box that wasn't updated yet, running precise 32bits
[14:57] <pitti> mvo: the point release process says "Ping mvo to update meta-release file on http://changelogs.ubuntu.com/"
[14:57] <tseliot> seb128: yes, I do and I'll have a look at it
[14:57] <pitti> mvo: this is "release - 6 days", which would be tomorrow
[15:02] <barry> pitti: hey, can we chat sometime today about +1?
[15:02] <tseliot> seb128: unfortunately my 1st machine with nvidia died (I don't know what hardware issue that is but I can't even access the BIOS). Fortunately I also have a laptop that I can use but it will probably take a while...
[15:02] <mvo> pitti: ok, I guess ideally this should be done on the day of the release instead, its just chaning the number from 10.04.x to x+1
[15:03] <smoser> sorry.. back with a bit more information on that bug now. (in the last comment).
[15:03] <smoser> i'm running into dh_shlibdeps complaining but it seems that bacula is doing what it intends to do.
[15:03] <pitti> mvo: ah, thanks
[15:03] <pitti> mvo: I'll update the wiki page
[15:03] <pgraner> cjwatson, I have an un updated nvidia box, if you want me to break it
[15:05] <mvo> pitti: thanks!
[15:08] <pitti> barry: In a meeting, and need to run out in ~ 20 mins, but yes, let's have a quick chat in a sec
[15:08] <barry> pitti: cool. i'm over in #ubuntu+1-maint
[15:13] <tjaalton> could an archive admin give gst-plugins-bad a push, it's in NEW due to libs&dev being split
[15:15] <pitti> tjaalton: done
[15:15] <tjaalton> pitti: thanks! now on to gstreamer-vaapi..
[15:36] <rbasak> Is there a way to run sbuild but with an extra local repository added to resolve build dependencies from?
[15:39] <cyphermox> rbasak: when I've had to do that I resorted to editing sources.list in the source schroot and doing the build, then reverting the change once done.
[15:40] <cyphermox> rbasak: I have no idea how it would be done otherwise -- anyway, sbuild doesn't seem to have a switch to do it.
[15:41] <rbasak> Thanks cyphermox - maybe I'll patch sbuild to add a switch one day, but I'll use your hack in the meantime
[15:41] <rbasak> cyphermox: did you use an http repo somewhere, or a local file one? And if a local file one, did you add that to the source chroot or something?
[15:41] <cyphermox> it might be useful, if say you want to enable universe for just one build, test builds against a particular PPA, etc.
[15:42] <rbasak> I'm trying to do a test rebuild of a dependent package - it fails in a PPA, but I can't figure out why.
[15:42] <cyphermox> rbasak: I was using reprepro to manage a local repository hosted in on my system with apache, in ~/public_html/
[15:42] <rbasak> (it succeeded for me doing it manually in a chroot)
[15:42] <janimo> rbasak, sbuild --pre-build-commands
[15:42] <janimo> I wonder if it cannot add a new apt sources file in /
[15:43] <rbasak> janimo, the part I don't understand is how to get my local repository into the chroot
[15:43] <janimo> rbasak, ah the files themselves from a local filesystem?
[15:43] <rbasak> yes
[15:44] <cyphermox> rbasak: with that --pre-build-commands I guess you could echo a file in /etc/apt/sources.list.d for your local repo
[15:44] <janimo> chroot-setup-commands too
[15:44] <rbasak> I have a pile of debs. Usually I "dpkg-scanpackages . /dev/null|gzip -9>Packages.gz" and then add "file:///path/to/dir /" in sources.list
[15:44] <janimo> not sure how to copy files in there though
[15:44] <cyphermox> rbasak: oh, that's why I was using a local apache
[15:44] <rbasak> yeah that's the bit where I'm stuck :)
[15:45]  * janimo used sbuild a week ago for the first time
[15:45] <cyphermox> otherwise if you use the security team's sbuild howto to bind mount /home you could leave the files there?
[15:45] <rbasak> Ah, a bind mount would be awesome
[15:46] <cyphermox> rbasak: https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment ; point number 5
[15:50] <rbasak> thanks cypermox - but what are ddebs?
[15:52] <cyphermox> debugging symbols packages
[15:53] <rbasak> I see - so irrelevant to me?
[15:58] <cyphermox> rbasak: probably
[16:03] <brendand> did the google talk plugin break in precise for anyone else?
[16:06] <slangasek> brendand: intermittently and possibly related to the eglibc upgrade today
[16:07] <brendand> slangasek, audio works for first few seconds and then stops
[16:07] <slangasek> yes, that's the issue I've seen
[16:07] <om26er> did anyone Pilot today?
[16:07] <slangasek> brendand: however, I wasn't able to reproduce it again after shuffling packages, so I haven't raised a bug
[16:07] <brendand> slangasek, what did you do?
[16:08] <slangasek> brendand: I downgraded eglibc, then upgraded it again, and then I couldn't reproduce the bug... so it may have actually been a bug somewhere in the audio stack
[16:09] <brendand> slangasek, what's the older version?
[16:09] <slangasek> brendand: 2.13-<foo>
[16:14] <brendand> slangasek, by eglibc you mean libc-bin, libc6, or all of them?
[16:15] <seb128> slangasek, brendand: maybe that's the bug which was in yesterday's alsa update and fixed today?
[16:15] <seb128> the configs were installed in the wrong dir
[16:15] <seb128> TheMuso fixed that today
[16:16] <brendand> seb128, nope i applied the workaround today. besides that didn't affect the googletalk plugin
[16:16] <seb128> dunno then
[16:21] <achiang> brendand: broken for me too
[16:27] <tseliot> seb128: according to ricotz the new Nvidia driver seems to work with the new eglibc. I'll test it here and upload it (if successful) today
[16:27] <tseliot> seb128: Sarvatt brought this to my attention
[16:29] <seb128> tseliot, ok, great, thanks
[16:31] <quadrispro> hi all
[16:32] <quadrispro> ehy tseliot ! how are you?
[16:32] <tseliot> quadrispro: hey, I'm still a little sick but fine otherwise, you?
[16:35] <quadrispro> tseliot, here the same, the flu has gone away right 2 days ago. I'm not used to this deep cold weather :/
[16:36] <tseliot> quadrispro: yes, I guess that's the problem..
[16:36] <slangasek> brendand: all of them, they have to be upgraded and downgraded in step
[16:46] <slangasek> brendand: note that at this point, due to rebuilds against the new version of glibc, you would also have to downgrade cups, bluez, pulseaudio, and libnih1 (used by upstart)
[16:59] <doko> slangasek, hmm, I don't have any nvidia hw :-/
[17:00] <geddy> barry, ping
[17:00] <slangasek> doko: I only assigned the eglibc task to you, if that's what you mean
[17:00] <doko> ahh, ok
[17:01] <geddy> barry ping
[17:38] <tseliot> seb128: unfortunately I'm unable to reproduce the problem on my laptop with the new eglibc...
[17:43] <Sarvatt> tseliot: every dupe i've opened so far is i386, that may explain why you can't reproduce on amd64
[17:45] <tseliot> Sarvatt: good point, I was starting to suspect i386...
[17:49] <seb128> bdmurray, why did you assign that gnome-screenshot upstream behaviour change to our team? it's not really a bug...
[17:49] <seb128> it's not a regression either, it's a on purpose behaviour change
[17:50] <bdmurray> seb128: I think its a huge usability issue
[17:50] <seb128> bdmurray, it's not really
[17:50] <bdmurray> How are people supposed to find their screenshots?
[17:51] <seb128> bdmurray, the new behaviour is how any phone or tablet out there will behave (yeah, they are different devices but still)
[17:51] <seb128> bdmurray, how do they find them on phones and tablets?
[17:51] <bdmurray> I don't think you take screenshots with a phone rather you take pictures and the photo software shows you the picture
[17:52] <seb128> bdmurray, well android tablets have a screenshot button on their 4 standard buttons which behaves like gnome-screenshot does, sound and visual effect and storing in the images directory
[17:54] <seb128> bdmurray, also the non interactive mode is only on screenshots, if you run gnome-screenshot from unity you will get an ui as before
[17:55] <bdmurray> seb128: part of assigning the bug to your team was to get an authoritative statement about the bug / workflow.  I'd imagine that bug will receive quite a few duplicates and people are interested in this information.
[17:56] <seb128> bdmurray, ok, I'm commenting on it, I just disagree with the regression tagging I think ;-)
[17:56] <seb128> though I'm not sure we will keep the new behaviour I think we should not hurry in reverting but rather see how the new workflow works for users
[17:56] <bdmurray> I can see how regression- tags can be subjective in design chagnes like this.
[17:57] <bdmurray> Its still not clear to me how I am supposed to find the screenshot.  Where do I navigate to?
[17:58] <bdmurray> View Photos in the dash?
[17:59] <seb128> bdmurray, they should show in the dash "recent files" on the dash home screen
[17:59] <seb128> bdmurray, if they don't atm we will fix that (need to check if that works)
[18:00] <seb128> bdmurray, the xdg Image folder is also in the bookmarks and easily accessible, if you know screenshots go there it's obvious to find them
[18:00] <seb128> (which is what phone and tablets do as well, you just need to know how to access your image dir)
[18:01] <seb128> bdmurray, in fact that works, they show there
[18:11] <kklimonda> hey, is it possible to change dch --increment behaviour? it always adds ubuntuX suffix which isn't really what I always want
[18:12] <micahg> kklimonda: what's the use case?
[18:12] <micahg> kklimonda: and welcome back :)
[18:13] <kklimonda> ah yes, I haven't been around in quite a while.. hey everyone :)
[18:13] <kklimonda> micahg: I maintain some packages that are not part of Ubuntu - they are either for debian or for a project based on Ubuntu.
[18:15] <kklimonda> ah, I can pass --distributor to override that
[18:15] <micahg> yeah
[18:15] <micahg> just found that in the source
[18:18] <slangasek> kklimonda: you can also pass -U, which is shorter
[18:18] <kklimonda> great, I can even use DEB_VENDOR to override that
[18:19] <doko> bryceh, can you confirm that an updated glibc will fix the nvidia issue?
[18:20] <kklimonda> slangasek: hmm, doesn't seem to work
[18:20] <kklimonda> ah
[18:20] <bryceh> doko, Sarvatt and tseliot say there is an nvidia driver update which will resolve it
[18:20] <kklimonda> sorry, I've misunderstood you
[18:20] <kklimonda> it works just fine :)
 bryceh: it seems that the latest nvidia (beta) driver solves the problem ^^
[18:21] <Sarvatt> bryceh: argh
[18:21] <tseliot> bryceh: I take back that. Apparently it doesn't
[18:21] <Sarvatt> bryceh: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/929384/comments/16
[18:34] <bryceh> doko, which glibc update?
[18:35] <doko> bryceh, there's only one, 2.15
[18:35] <cjwatson> has anyone managed to get valgrind output?
[18:36] <tseliot> cjwatson: do you suspect some major leak on i386?
[18:37] <slangasek> probably not a leak, but maybe some memory smashing that valgrind could pick up on
[18:37] <cjwatson> right
[18:37] <tseliot> interesting
[18:37] <cjwatson> Is https://bugs.archlinux.org/task/27737 possibly related?
[18:39] <slangasek> possibly, but I don't see any of those problems here on amd64
[18:39] <slangasek> oh, linked to nvidia
[18:39] <doko> I don't see the delays with firefox and chromium
[18:39] <slangasek> sorry, had a different eglibc issue on the brain :P
[18:39] <cjwatson> ah, here we go
[18:40] <cjwatson> https://bugzilla.redhat.com/show_bug.cgi?id=737223
[18:40] <cjwatson> http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=0c95ab64
[18:40] <cjwatson> doko: ^-
[18:41] <doko> cjwatson, the fix is in the package
[18:41] <cjwatson> oh, already?
[18:41] <ahasenack> valgrind output: http://pastebin.ubuntu.com/835568/
[18:43] <cjwatson> doko: I don't see it ...
[18:44] <cjwatson> looking in lp:ubuntu/eglibc
[18:44] <doko> hmm, only part of it:
[18:44] <doko> /usr/share/sounds/speech-dispatcher/test.wav
[18:45] <doko>               if (copy == NULL)
[18:45] <doko>                 _dl_fatal_printf ("out of memory\n");
[18:45] <doko>               l->l_libname->name = l->l_name = memcpy (copy, dsoname, len);
[18:45] <doko>             }
[18:45] <slangasek> I wonder, should this bug be reproducible without nvidia hardware just by installing the lib
[18:45] <cjwatson> incidentally, lp:ubuntu/eglibc is not up to date with precise
[18:45] <doko> ahh, I'll commit
[18:45] <cjwatson> slangasek: if this patch is what fixes it, that looks quite plausible
[18:46] <ahasenack> it's very similar to that rh bug
[18:46] <slangasek> yep, testing now
[18:46] <ahasenack> interesting LD_DEBUG options
[18:46] <cjwatson> ahasenack: please try running whatever you were running with 'LD_DEBUG=version'
[18:47] <ahasenack> it says the option "version" is unknown, I tried help and there are others
[18:47] <ahasenack> all quite verbose
[18:48] <cjwatson> ahasenack: er, right, =versions
[18:48] <ahasenack> standard shell redirection to a file doesn't work
[18:48] <cjwatson> 2>
[18:48] <cjwatson> i.e.  LD_DEBUG=versions glxinfo 2>x
[18:48] <ahasenack> oh, duh
[18:48] <Sarvatt> slangasek: some of the bug reporters mentioned it still happened when they switched the gpu to intel but still had nvidia installed, yep it should
[18:48] <ahasenack> nm
[18:50] <ahasenack> cjwatson: versions: http://pastebin.ubuntu.com/835583/
[18:50] <cjwatson> looks very much like the same bug to me.
[18:50] <ahasenack> and with LD_DEBUG=all
[18:50] <ahasenack> http://pastebin.ubuntu.com/835584/
[18:51] <cjwatson> cf. https://bugzilla.redhat.com/show_bug.cgi?id=737223#c12
[18:52] <ahasenack> got the symbol lookup error too
[18:52] <ahasenack> buried in those logs
[18:54] <cjwatson> slangasek: any luck?
[18:54] <slangasek> cjwatson: still working on it, just found that my i386 chroot didn't have eglibc upgraded yet
[18:54] <slangasek> yep, got it
[18:55] <slangasek> doko: it's reproducible in an i386 chroot with nvidia-current+mesa-utils installed, without needing nvidia hardware
[18:56] <bryceh> I'm updating my nvidia hw test box, but will be a few more minutes
[18:56] <slangasek> bryceh: reproducible in any i386 chroot
[18:56] <smoser> hey...
[18:56] <cjwatson> slangasek: did you say you saw audio problems as well?  I wonder if that's https://bugzilla.redhat.com/show_bug.cgi?id=769421
[18:56] <cjwatson> cf. http://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/glibc&id=ead7c0f93b194f6e3a100f249edd76c826debaef
[18:56] <smoser> i'm looking at bacula, and its not getting correct mysql libs because it is explictly checking (in configure) for certain paths that the lib might exist in
[18:57] <slangasek> cjwatson: yes; bug #929713
[18:57] <smoser> and that does not include /usr/lib/x86_64-linux-gnu
[18:57] <smoser> configure looks like this: http://paste.ubuntu.com/835598/
[18:57] <Daviey> smoser: doesn't it make sense to patch that in as an include path?
[18:57] <elmo> I have those audio problems too, FWIW
[18:57] <smoser> should i just patch it?
[18:57] <smoser> it seemed wrong to patch a 'configure'
[18:58] <cjwatson> is the configure script generated using autoconf?
[18:58] <Daviey> smoser: are there any .in files?
[18:58] <cjwatson> if so, you should patch the generating files
[18:58] <cjwatson> the modern form is .ac
[18:58] <Daviey> ah yeah, right
[18:59] <smoser> cjwatson. yes, but i dont think they're in the upstream tarball
[18:59] <cjwatson> although it might well be in .m4 somewhere
[18:59] <cjwatson> smoser: crazy upstream
[18:59] <cjwatson> if they don't ship the autoconf input, you don't have a lot of choice *shrug*
[18:59] <cjwatson> yes, it's wrong, but they were wrong first
[18:59] <cjwatson> playground logic
[18:59] <smoser> so cjwatson you were saying 'configure.ac' ?
[18:59] <cjwatson> yes
[19:00] <smoser> yeah. not there.
[19:00] <Daviey> smoser: I don't think you gain much by trying to do it 'right'
[19:00] <cjwatson> smoser: sure it is, in the autoconf/ subdirectory.
[19:00] <cjwatson> configure.in
[19:00] <Daviey> ah.. /me retreats.
[19:01] <cjwatson> autoconf/bacula-macros/db.m4 is probably what you want to change.
[19:02] <slangasek> cjwatson: the "NPTL issues" backtrace is not dissimilar to my quodlibet backtrace; checking the other apps where I'm seeing it
[19:04] <smoser> cjwatson, thank you.
[19:08] <elmo> how did that NPTL reversion not get into eglibc 2.15 upstream?  that bug is almost two months old
[19:20] <bryceh> elmo, nvidia might not be as high a priority for them?
[19:21] <elmo> bryceh: nvidia is the rtld.c change - the broken NPTL patch affects audio on machines with no nvidia
[19:21] <cjwatson> bryceh: the NPTL reversion is not about nvidia
[19:22] <cjwatson> I don't have an answer for why the Fedora patch fixing nvidia isn't upstream either, mind
[19:22]  * cjwatson -> pub, sod it
[19:23] <cjwatson> slangasek: I tentatively added a Fedora bug task for the audio bug
[19:23] <slangasek> cjwatson: seen, thanks
[19:27] <doko> the pthread_cond_wait issue is debian/patches/i386/local-pthread_cond_wait.diff, isn't it?
[19:27] <doko> cjwatson, ^^^
[19:31] <slangasek> doko: I'm seeing the NPTL issue on amd64
[19:32] <elmo> me too
[19:33] <doko> hmm, reverted in Debian:
[19:33] <doko>   * patches/amd64/cvs-pthread_cond_wait.diff: remove as it seems to cause
[19:33] <doko>     some issue with some kernels.  Closes: #651746.
[19:34] <slangasek> the remaining problem doesn't appear to be kernel-related
[19:34] <slangasek> and the proposed fix isn't to remove the assembly version altogether, but to patch it?
[19:44] <bryceh> doko, I've got 2 systems (one Nvidia, one Intel) reproducing the nvidia bug.  Both have libc 2.15 installed.
[19:47] <seb128> slangasek, do you know if somebody has been looking at upgrading valgrind's suppr files for multiarch? I've been adding local ones to clean my logs but I noticed some are in the default.suppr but the paths don't match because of multiarch dirs
[19:48] <slangasek> seb128: I haven't heard this mentioned before now, no
[19:48] <seb128> slangasek, hum, ok
[19:49] <seb128> slangasek, i.e /usr/lib/valgrind/default.supp has
[19:49] <seb128>    zlib-1.2.x trickyness (1b): See http://www.zlib.net/zlib_faq.html#faq36
[19:49] <seb128>    Memcheck:Cond
[19:49] <seb128>    obj:/*lib*/libz.so.1.2.*
[19:49] <slangasek> seb128: seems like it should be a simple bugfix though, right?
[19:49] <seb128> slangasek, yeah, it's just adding * to the lib paths in a file :p
[19:49] <seb128> slangasek, I was just wondering if somebody was working on it or if that was at least reported
[19:49] <seb128> slangasek, I will open a bug in the bts if there isn't one yet
[19:49] <slangasek> well, I'm not subscribed to the valgrind bugs :)
[19:49] <slangasek> ok
[19:50] <seb128> slangasek, let me check
[19:50] <seb128> slangasek, btw I sent you automake1.11 multiarch diff to the bts, it got merged but they credited me even if I mentioned the patch was yours
[19:50] <seb128> slangasek, sorry for stealing credit from you ;-) on the positive side it allowed us to sync automake1.11 again
[19:50] <slangasek> seb128: no worries, my name is in enough changelogs :-P
[19:51] <infinity> slangasek: Since we started trimming changelogs, I feel much less cool.
[19:51] <infinity> slangasek: That recursive grep in /usr/share/doc isn't what it used to be.
[19:51] <slangasek> :-)
[20:13] <doko> bryceh, slangasek, cjwatson, elmo: test packages (amd64) on http://people.canonical.com/~doko/tmp/eglibc-2.15/
[20:23] <doko> and i386
[20:33] <bryceh> doko, looks good.  installed those debs on the broken nvidia box, rebooted, and unity came right up
[20:34] <slangasek> interestingly, it seems to still be failing in my chroot
[20:34] <slangasek> ah, no
[20:34] <slangasek> it works, I just had to install libc-bin with it so the package actually got configured
[20:34] <bryceh> verified NVIDIA loaded, no X errors, dmesg is clean
[20:35] <doko> bryceh, amd64, or i386?
[20:35] <bryceh> doko, i386
[20:35] <slangasek> doko: glxinfo i386 nvidia chroot test succeeded here
[20:35] <slangasek> testing the audio regression now
[20:35] <bryceh> bryce@porlock:~$ uname -a
[20:35] <bryceh> Linux porlock.bryceharrington.org 3.2.0-15-generic-pae #24-Ubuntu SMP Tue Feb 7 23:30:35 UTC 2012 i686 i686 i386 GNU/Linux
[20:35] <bryceh> bryce@porlock:~$ apt-cache policy libc6
[20:35] <bryceh> libc6:
[20:35] <bryceh>   Installed: 2.15-0ubuntu2
[20:35] <bryceh>   Candidate: 2.15-0ubuntu2
[20:36] <doko> network sucks here, apt-get update taking now over 15min ...
[20:38] <bryceh> doko, what's in that 0ubuntu2 version?
[20:41] <doko> bryceh, the two patches identified by cjwatson
[20:49] <bryceh> doko, also verified it fixes the unity_support_test crash on the intel box
[20:50] <slangasek> doko: audio is testing out ok
[20:50] <slangasek> jdstrand: care to test the updated libc from http://people.canonical.com/~doko/tmp/eglibc-2.15/ with me in G+?
[20:51] <jdstrand> slangasek: sure. a browser restart should be enough I'm assuming, correct?
[20:52] <slangasek> jdstrand: no, the gtalk plugin starts its own server process, which is the one that hangs; so you want 'killall -9 GoogleTalkPlugin'
[20:52] <slangasek> jdstrand: possibly with a 'killall plugin-container' thrown in for flavor
[20:52] <jdstrand> heh, ok. downloading-- it'll probably be a few minutes
[20:52]  * slangasek nods
[20:57] <jdstrand> slangasek: ok, ready
[20:57] <jdstrand> joining
[20:58]  * jdstrand adjusts hair
[20:59] <tedg> hyperair, Do you have thoughts on this patch?  https://code.launchpad.net/~ballogy/libindicate/fix-mono-location/+merge/92313
[20:59] <tedg> hyperair, I always forget where things are supposed to go with Mono :-)
[20:59] <doko> jdstrand, do you see core dumps without adjusted hair? ;-P
[20:59] <jdstrand> worked great :)
[21:00] <jdstrand> doko: hehe-- maybe that was my problem before :)
[21:01] <hyperair> tedg: if you gacutil, don't bother installing it in assemblydir.
[21:01] <hyperair> tedg: afaik gacutil does that for you
[21:01] <hyperair> er i think
[21:02] <tedg> hyperair, How do I know if I gacutil? ;-)  It's used several times, I'm not sure which usages are important.
[21:03] <hyperair> tedg: gacutil -i installs into the GAC.
[21:03] <hyperair> tedg: if you do that, installing it into assemblydir like what it was before the patch was applied, and even after the patch is applied, is redundant.
[21:04] <hyperair> tedg: take a look at taglib-sharp's src/Makefile.am
[21:04] <tedg> hyperair, So the patch is from the arch guy, in theory it helps their packaging.  Would you say it's a no-op for Ubuntu then?
[21:05] <hyperair> tedg: we'll probably just ignore things found in /usr/lib/mono
[21:05] <hyperair> debian policy is to stick things into /usr/lib/cli in the .deb, and then gacutil -i it in postinst
[21:05] <hyperair> whereas upstreams should just gacutil -i straight.
[21:06] <hyperair> tedg: is ballogy around on irc somewhere?
[21:06] <hyperair> tedg: also i really need to sleep.
[21:06] <tedg> hyperair, Not sure, I've not talked with him/her on IRC
[21:07] <tedg> No IRC listed on LP either.
[21:07] <hyperair> tedg: well i'm pretty sure the Right Way™ for upstreams is what taglib-sharp is doing
[21:07] <hyperair> so please look at how it's done there and follow suite.
[21:07]  * hyperair → bed
[21:07] <hyperair> it's 5am and i need to wake up early tomorrow
[21:07] <tedg> hyperair, Okay, thanks!
[21:07] <tedg> 'night
[21:07]  * tedg doesn't want to be technical, but it already is early tomorrow :-)
[21:10] <slangasek> tedg: you don't *want* to be technical, you just find that it's an innate aspect of your makeup? :)
[21:16] <tedg> slangasek, I blame society
[21:24] <jono> hey folks
[21:24] <jono> is sound still broken in Precise for flash?
[21:24] <jono> still having issues with playing flash videos and using G+
[21:25] <slangasek> jono: eglibc 2.15-0ubuntu2 will fix it; building now
[21:25] <slangasek> (separate issue than the flash one yesterday)
[21:25] <jono> slangasek, awesome, thanks
[21:25] <jono> oh I see
[21:44] <dobey> slangasek: is that eglibc build the fix for the omg nvidia issuse?
[21:44] <elmo> dobey: yes
[21:44] <dobey> yay
[21:45] <dobey> was it an issue in __memcpy_ia32 btw? i'm hitting an odd crash in it right now, and just wondering if it's related
[21:50] <slangasek> dobey: no, it was in the linker
[21:50] <dobey> ah ok
[21:51] <dobey> then perhaps it's time for some bourbon, if i'm going to have to actually debug this crash in gnome-keyring, in introspection, in python :-/
[23:55] <hrw> [6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~OQhi
[23:55] <hrw> does someone know is reproductible hangs of chromium and firefox are due to eglibc 2.15 or other recent upgrade?
[23:56] <slangasek> hrw: haven't seen any reports of browser hangs due to eglibc 2.15; there are two critical bug fixes in eglibc 2.15-0ubuntu2
[23:56] <hrw> slangasek: here, I run chromium or firefox, enter address and it hangs - have to xkill
[23:57] <slangasek> hrw: arch?
[23:57] <hrw> amd64
[23:57] <slangasek> hmm
[23:57] <slangasek> I've been running firefox w/ eglibc 2.15 for a week, no issues
[23:59] <RAOF> hrw: Possibly flash being crazy?