[03:54] <mwhudson> who can i chase to get a fix for this bug SRUed? https://bugs.launchpad.net/ubuntu/+source/offlineimap/+bug/877883
[03:54] <mwhudson> it's a bit exciting
[03:56] <RAOF> Mmm.  I'm all about deleting people's main!
[03:56] <RAOF> s/main/mail/gc
[03:56] <mwhudson> heh
[03:57] <ajmitch> it's all about inbox zero these days
[03:58] <RAOF> Bah.  There's a lot of *entirely unrelated* change there :/
[03:59] <RAOF> Stupid embedding of libs.
[04:00] <mwhudson> i guess it might be possible to dig out the relevant fix to imaplib2
[04:04] <RAOF> Yeah.  It's probably not a huge change.
[04:06] <mwhudson> can't find it though :/
[04:06] <mwhudson> going by timestamps it must be one around here
[04:07] <mwhudson> http://imaplib2.git.sourceforge.net/git/gitweb.cgi?p=imaplib2/imaplib2;a=commit;h=187658d4f11ecbadcab8244dba732aff5caba48b
[04:07] <mwhudson> but there are no tags in the repo (unless i fail at git)
[04:07] <mwhudson> so i don't know which commit corresponds to 2.24
[04:21] <pitti> Good morning
[04:22] <pitti> micahg: you'll need a condition for this in debian/rules anyway, so I'd advise to only switch it on for precise an dup
[04:22] <pitti> "and up"
[04:23] <micahg> pitti: ok, will do
[04:23] <pitti> SpamapS: release to maverick-updates you mean?
[04:23] <pitti> sure
[05:09] <SpamapS> pitti: yes I do mean maverick-updates. :)
[05:27] <slangasek> SpamapS: bug #811823> blast, I was too slow; based on Steve Atwell's last comment, I was going to push a fix for the other race condition he pointed out...
[05:27] <slangasek> guess I'll do it as a follow-on SRU
[05:30] <SpamapS> slangasek: heh, sorry, its been waiting so, so long.
[05:33] <slangasek> SpamapS: I see though that you've only pushed for natty, but have marked it 'verification-done' for all?
[05:36] <SpamapS> slangasek: if done and needed are there, that means "pay attention SRU team, some things are not done"
[05:37] <didrocks> good morning
[05:38] <SpamapS> slangasek: and I'm holding off on lucid to see if we get maverick verified. Its such a shame when upgrades cause regressions. :-/
[05:38] <SpamapS> my guess is that we won't though
[05:38] <SpamapS> the list of unverified SRU's for maverick is quite long
[06:02] <slangasek> SpamapS: hmm.  when it's been verified already for both lucid and natty, I would argue that it should also be pushed to maverick on that basis.
[06:03] <slangasek> or if not, it should at least be pushed to lucid, as there aren't likely to be many users upgrading from lucid to maverick now - but there are still plenty of people using lucid
[06:09] <SpamapS> slangasek: agreed, and done. ;) this will henceforth be known as the Langasek Release Sandwich Policy
[06:13] <slangasek> mmm
[06:13] <slangasek> just the right amount of mustard
[06:13] <SpamapS> And paprika
[06:21] <broder> SpamapS: haha, so that's the trick to getting rid of it? i'm still working through the tiny souvenir bags i picked up in Budapest :)
[06:53] <dholbach> good morning
[07:16] <vin__> qualcuno sa come configurare thunderbird con exchange?
[08:04] <sroecker> hi, are you guys using unity2d? i am trying to debug why i only have 1 workspace
[08:04]  * ogra_ has 4 with a default install 
[08:04] <sroecker> yes, when i use unity i got 4. unity2d only shows me 1
[08:05] <ogra_> even with ctral-alt and the left/right cursor key ?
[08:05] <sroecker> yes
[08:05] <geser> I had to change the number of workspaces to get more than 1 (unity-2d), I don't remember if I had in natty more then 1 or not (I upgraded from natty to oneiric)
[08:06] <ogra_> if you can run unity 3d there the 2d version might use compiz instead of metacity
[08:06] <ogra_> i clearly run metacity here on my non GL capable device
[08:06] <ogra_> and get proper 4 workspaces
[08:06] <sroecker> looks like metacity
[08:07] <sroecker> ah, thats why trying to configure compiz with ccsm doesn't change anything
[08:08] <chihchun> it seems code.launchpad.net does not sync changes for precise yet?
[08:08] <chihchun> there are some new packages in precise, but the code is not sync in lp:/ubuntu/package
[08:10] <sroecker> ogra_: thx, metacity num_workspaces was set to 1. although i am sure i had 4 before the upgrade to oneiric
[08:11] <ogra_> yeah, thats weird, i still have four here
[08:11] <ogra_> (not that i would ever need more than one)
[08:13] <chihchun> the latest version of gtg is https://launchpad.net/ubuntu/precise/+source/gtg/0.2.4-6, but the code is still 0.2.4.5 https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/gtg/precise
[08:18] <elleuca> seb128, do you know why gnome-terminal 3.0.x is available in oneiric, instead 3.2.x?
[08:19] <seb128> elleuca, no
[08:20] <seb128> elleuca, it's likely because the first vte 0.29 tarball was 08-28
[08:20] <seb128> i.e way after feature freeze etc
[08:21] <elleuca> seb128, oh yes, I forgot about vte dependence
[08:23] <chrisccoulson> sroecker, have you used gnome-shell at all?
[08:23] <sroecker> chrisccoulson: yes, i tried it once
[08:23] <chrisccoulson> i find that the number of workspaces is reset to 1 after i use gnome-shell
[08:23] <chrisccoulson> every time
[08:23] <sroecker> ah
[08:23] <seb128> chrisccoulson, it's a design decision
[08:23] <seb128> you always start at 1 and add them dynamically
[08:24] <chrisccoulson> seb128, ah. it's a bit of a pain that it interferes with the unity-2d session :(
[08:24] <chrisccoulson> i alternate between them a fair bit
[08:24] <ogra_> bah, oneiric makes debian crash !
[08:24] <ogra_> http://people.canonical.com/~ogra/debian-crashing.png
[08:25] <seb128> chrisccoulson, get a script settings the few keys it reset on unity-2d start ;-)
[08:26] <chrisccoulson> seb128, won't that slow my login down? ;)
[08:26] <chrisccoulson> (which is pretty fast in 2d)
[08:26] <chrisccoulson> perhaps i should just stick to using one desktop shell
[08:26] <sroecker> ogra_: whats that irc client? looks nice
[08:26] <ogra_> sroecker, xchat
[08:27] <sroecker> ogra_: vanilla or gnome?
[08:27] <ogra_> vanilla
[08:28] <ogra_> with indeed the defaults adjusted a bit (userlist and channel list on the right, some color defaults changed etc, nothing big though)
[08:52] <Judge> Hi there. We need support for advanced GD features in PHP like imagerotate() for example. In LP: #74647 there was a question about why this isn't supported in Ubuntu and it was answered with "won't fix".
[08:53] <Judge> Therefor, we set up a PPA, changing the GD support to the bundled one, which supports these functions.
[08:53] <Judge> Now, we updated PHP to the latest Repo-Version by accident on lucid and hardy and suddenly: This is working with the default packages !
[08:54] <Judge> Can someone tell me when and why this has been changed and if this will be a permanent change this time?
[09:02] <ajmitch> Judge: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321237 has the information about it - there were changes in php5 upstream in 5.3.x which added a compatibility layer
[09:04] <Judge> ubottu / ajmitch : Great! That makes it clear for Lucid / PHP5.3 - What's the matter with Hardy / PHP5.2 ?
[09:04] <Judge> LOL
[09:07] <ajmitch> Judge: afaik, it's just a general issue around avoiding bundled libs
[09:08] <Judge> ajmitch: That's right.
[09:08] <Judge> But somehow, it seems to work now.
[09:09]  * ajmitch doesn't know how, unless you're still getting your self-compiled php5 loaded
[09:10] <Judge> However: Thank you for your help :)
[09:40] <cjwatson> Daviey: can you deal with the xmlrpc-c merge?
[09:40] <cjwatson> (I forget whether I asked already)
[09:43] <Daviey> cjwatson: you have not, and yes i will
[09:43] <Daviey> (unless i missed it)
[09:44] <cjwatson> great, thanks
[09:49] <Daviey> Riddell: Hey, happen to remember why http://launchpadlibrarian.net/62034463/xmlrpc-c_1.16.32-0ubuntu2_1.16.32-0ubuntu3.diff.gz happend?
[09:51] <Riddell> Daviey: hmm, no, although it feels like I should
[09:51] <Daviey> Riddell: no worries, thanks
[09:54] <Riddell> Daviey: must be related to cmake
[11:32] <doko> lucas: any hint about bug 874306
[11:33] <lucas> doko: yes, see ubuntu-devel@ on friday
[11:33] <lucas> doko: ppa introduced alternatives in an incompatible way
[11:34] <Laney> get the tools to report that a broken upgrade was from an unofficial package and advise purging it?
[11:35] <doko> mvo: ^^^ can the upgrade tools figure this out? that would be indeed a big help
[11:35] <doko> I agree that purging is the right solution
[11:37] <fabiand> is csanchez around or does someone know where to find him? :)
[11:38] <mvo> doko, lucas: sure, the upgrader can special case this and go it, i need the exact version of the incompatible pkg
[11:39] <doko> hmm, I was more thinking about having a general solution. but I assume, you don't want to have a list of "official" package versions
[11:40] <lucas> alternatively, ubuntu could carry a patch that adds a Conflicts or a Breaks with all the packages ever published on those PPAs
[11:40] <lucas> (conflicts or breaks on the ruby1.{8,9.1} packages)
[11:41] <doko> only if they get the alternatives removal right
[11:41] <Laney> there is some way to tell if a package is official because apport does it
[11:57] <hyperair> apt-cache policy?
[11:57] <hyperair> check against a whitelisted bunch of mirrors?
[12:11] <Laney> Origin:
[12:30] <hallyn> didrocks, hey, just wondering, i noticed you had a newer version of gnome-keyring in oneiric-proposed, but not precise.  Is there a reason for that?
[12:30] <hallyn> I'm looking at it because, with libvirt 0.9.6 (no idea why yet), it keeps spitting out annoying warnings about WARNING: unable to connect to socket
[12:31] <didrocks> hallyn: we are in sync basically, so once the version in -proposed is validated and move to -updates, it's generally copied to precise
[12:31] <Laney> i thought stuff is usually copied when it goes into proposed
[12:32] <hallyn> heh, i thought it could only go into proposed after it's in precise :)  But, was just wondering, thanks.
[12:32] <hallyn> does my 'WARNING:' problem ring any bells for you?
[12:33] <hallyn> google searching brings up a few other people having that problem with other software.
[12:33] <didrocks> hallyn: as long as we are in sync, it's not a big deal
[12:33] <Laney> it they are equal then the proposed package can be copied to the next release
[12:33] <didrocks> hallyn: I guess yo uhave perm issues
[12:33] <hallyn> it only happens when you're not logged in on console
[12:33] <didrocks> you*
[12:33] <hallyn> so /tmp/whatever/pkcs11 doesn't exist
[12:34] <hallyn> annoyingly, it also happens when I sudo, since root isn't then logged into X
[12:35] <didrocks> hallyn: not sure about gnome-keyring and sudo, normally is export variables like GNOME_KEYRING_CONTROL=/tmp/keyring-* which is accessible only to your user
[12:35] <doko> slangasek, your cron merge pulls in universe stuff. see bug 878155
[12:37] <hallyn> right.  it's just, gnome-keyring shouldn't be spitting out warnings on console about it.  ok it was late last night, i'll see if i can find the offensive line, thx
[12:38] <seb128> Laney, one issue is that it needs to be built on all archs to be copied
[12:38] <seb128> Laney, so it can't be copied when accepted
[12:38] <seb128> Laney, but yeah, it would be nice to have things copied over before the one week validation delay
[12:38] <Laney> yeah, i thought that's what was done
[12:39] <seb128> depends of the archive admins I think
[12:40] <seb128> there was some discussion previous cycle about that but some were in disagreement with pocket copied from proposed iirc
[12:40] <seb128> I don't remember the details though
[12:41] <frafu> pitti: Concerning Onboard 0.96.0 and LP: #872374 . The Onboard developer already committed some small fixes. I now wonder what is better for the oneiric proposed procedure: should we wait for the procedure to get onboard 0.96.0 into oneiric to be terminated, or is it better to release 0.96.1 as soon as possible and add the corresponding debian package to the bug thread?
[12:42] <pitti> frafu: if the current SRU makes it better, but not perfect yet, it can progress to -updates first; if there is any regression, we should push another -proposed version
[12:46] <frafu> pitti: thanks for the reply; so, if I get it right: it is better to wait and see whether there is any regression before releasing 0.96.1; correct?
[12:46] <pitti> frafu: the upstream release shouldn't need to block on the ubuntu SRU
[12:47] <doko> hallyn, please see bug 878162
[12:49] <hallyn> doko, qemu-kvm-spice (which should be in universe) does, but qemu-kvm shouldnt...
[12:49] <doko> hallyn, it's the build depends
[12:49] <hallyn> sigh, i was assured that was ok :)
[12:50] <hallyn> does that mean i must have a separate source pkg?
[12:50] <doko> no, it's not
[12:50] <doko> yes
[12:50] <hallyn> ok, thanks.
[12:51] <hallyn> i was goin gto merge 0.15 today anyway, so i'll do that and pull the -spice package out
[12:51] <frafu> pitti: Ok. I will talk with the other Onboard developer about it and we can decide about the upstream release independently from the SRU, unless there is a regression. Thanks.
[13:00] <cjwatson> Daviey: doesn't block this upload, but I wonder if perhaps libxmlrpc-core-c3-0-udeb should be renamed to libxmlrpc-core-c3-udeb in line with the deb variant
[13:02] <Daviey> cjwatson: Yeah, probably right.. I'll raise a bug.. will handle that and it's rdepend soonly.
[13:03] <Daviey> it's only a wishlist, right?  They isn't any impact?
[13:03] <cjwatson> wishlist, yeah
[13:03] <akgraner> Day 3 of Open Week just started - https://wiki.ubuntu.com/UbuntuOpenWeek
[13:03] <Daviey> cjwatson: did you fire the amd64 rebuild?
[13:03] <cjwatson> yeah
[13:04] <cjwatson> I gave back everything I could find that had failed due to transient perl breakage
[13:04] <Daviey> thanks muchly, i did fire it earlier.. and just went to check it, and saw it was built \o/
[13:04] <pitti> cjwatson: ah, so it was you; thanks (wanted to give back bluez and saw that it was built already)
[13:04] <pitti> I also pushed the powerpc build score, but firefox/linux are blocking it
[13:05] <pitti> cjwatson: want me to temporarily set the powerpc ones on manual until perl is built/published?
[13:05] <cjwatson> yeah, firefox looked stalled last I checked
[13:05] <doko> Daviey, looked serverish, bug 878170
[13:05] <cjwatson> pitti: no, it was only a problem because amd64 built before perl, AFAIK
[13:05] <cjwatson> pitti: err ... because amd64 built before i386
[13:05] <Daviey> doko: yeah, i raised a bug and assigned it to the person that did the sync :)
[13:05] <pitti> ah, ok
[13:06] <Daviey> doko: marking as a dupe of bug 875818.
[13:07] <cjwatson> i386 has built now so I don't think it should repeat for other architectures; I haven't noticed a similar pattern of failurebombing from armel
[13:08] <doko> Daviey, thanks, subscribed ubuntu-mir to let this show up in our list
[13:08] <Daviey> doko: do we have a richer c-m tracking list?
[13:09] <Daviey> I've got http://people.ubuntu.com/~davewalker/component-mismatches-mir-track.html , but i'd rather someone was in the main page
[13:10] <hallyn> zul: didrocks: I needed http://people.canonical.com/~serge/gnome-keyring-warning.debdiff pushed on gnome-keyring for libvirt to shut up.  zul, do you know why gnome-keyring is being used by libvirt 0.9.6 at all?
[13:10] <hallyn> (I'm hoping that will allow the qa-regression-tests to succeed :)
[13:10] <zul> hallyn: no idea
[13:10] <didrocks> hallyn: well, not sure that commenting warning is a nice way to make things work :)
[13:11] <hallyn> didrocks: but that warning is not helpful.  it gives no indication who is trying to open what socket or why, and strace doesn't help either.  I suppose you could find it under gdb...
[13:12] <hallyn> in a program it'd be fine i suppose, but this is a library.
[13:12] <didrocks> hallyn: yeah, deubbing under gdb, maybe it worthes rather discussing with gnome-keyring people?
[13:12] <tjaalton> forgot about bug 838091 until now, is the proposed fix doable?
[13:12] <didrocks> would be better to know why and how you get this warning in your condition
[13:13] <hallyn> didrocks: yeah definately we need to bring it up.  I was just showing waht I needed :)
[13:13] <hallyn> didrocks, the reason I get it is clear;
[13:13] <hallyn> gnome-keyring lib wants to talk to gnome-keyring, but i'm not logged into gnome, so it can't
[13:13] <Daviey> hallyn: do you know why spice is being pulled into main?
[13:14] <cjwatson> Daviey: I think bug 878180 is a NEW blocker though
[13:14] <hallyn> Daviey, bc you told me I could put a binary package depending on universe packages in with a source pkg in main :)
[13:14] <didrocks> hallyn: the right fix will then be to ensure you have libvirt only using gnome-keyring if you are under a GNOME session
[13:14] <hallyn> Daviey, I will merge qemu 0.15 today and drop qemu-kvm-spice into its own source pkg
[13:14] <Daviey> hallyn: did i?
[13:15] <hallyn> zul, I trust you'll look into dropping gnome-keyring from libvirt libs?
[13:15] <cjwatson> hallyn: you can if that binary package is itself destined for universe
[13:15] <hallyn> I can't see why it's using it
[13:15] <hallyn> cjwatson, the binary package is
[13:16] <tjaalton> basically, if you have old ntfs mounts in /etc/fstab, the bootup process will complain about "serious problems"
[13:16] <cjwatson> hallyn: evidently not ...
[13:16] <hallyn> but the universe libraries are in build-depends for the src package
[13:16] <cjwatson> hallyn: ah, well, that will indeed cause those libraries to be pulled into main
[13:16] <hallyn> right
[13:16] <cjwatson> main must be transitively closed under Build-Depends+Depends+Recommends
[13:17] <cjwatson> and all source packages that deliver binary packages in main must be in main, but not vice versa
[13:25] <soren> Any ideas why reportbug can't seem to contact Debian's BTS?
[13:26] <Laney> is it a package with a lot of bugs?
[13:26] <soren> wnpp :)
[13:27] <Laney> sometimes times out
[13:27] <Laney> reportbug -b if you don't need the query
[13:28] <soren> Ah, neat.
[13:28] <soren> Thanks.
[13:32] <Pici> Hrm.  http://changelogs.ubuntu.com/meta-release seems to be pointin to files that don't exist for the Oneiric release, getting a bunch of reports in #ubuntu about this.  Whose attention do I need to bring this to?
[13:33] <soren> mvo: ^ ?
[13:33] <soren> I think.
[13:35] <Daviey> ev: ^^ Was that something you were working on last week?
[13:35] <ev> nope
[13:38] <seb128> tseliot1, hey
[13:38] <tseliot1> hi seb128
[13:38] <seb128> tseliot1, is bug #855943 or your list? should it be assigned to you or to somebody else?
[13:39] <seb128> tseliot1, just asking because we get quite some user who get a non starting box due to it :-(
[13:39] <tseliot1> seb128: let me have a look
[13:39] <seb128> tseliot1, I've triaged several unity and lightdm bugs which were in fact duplicates of that one now
[13:39] <seb128> tseliot1, thanks
[13:40] <seb128> brendand ran into it yesterday
[13:40] <seb128> brendand, did you use jockey btw or just the command line?
[13:41] <brendand> seb128 - jockey
[13:41] <seb128> tseliot1, ^ so it's not command line specific, people screw their system by using jockey...
[13:41] <seb128> brendand, thanks
[13:42] <tseliot1> seb128: I saw the bug report but I kind of lost track of the issue as I was busy with other work. I'll make sure to spend some time on the bug to fix it ASAP
[13:42] <seb128> tseliot1, thanks a lot!
[13:42] <tseliot1> seb128: thanks for bringing this to my attention again
[13:42] <seb128> yw ;-)
[13:51] <mvo> Pici: should be fixed now, sorry for that
[13:52] <mvo> pitti: is there a chance that we can get u-m 0.152.25.1 that used to be in proposed into -updates? its a rather important fix for a crash with unusual fstab layouts (that turn out to be not that unusual)
[13:53] <pitti> mvo: sorry, is that update-manager? -updates has 1:0.150.3
[13:53] <pitti> 0.152.25.1 looks like a very odd version number
[13:54] <Pici> mvo: thanks
[13:54] <pitti> mvo: ah, ignore me, that was natty
[13:54] <mvo> pitti: i mean oneiric, there is 1:0.152.25.4 in proposed, but 0.152.25.1 would be really good to have in -updates by now :/
[13:55] <pitti> mvo: there's nothing to copy, tohugh, as .1 is not published anywhere :(
[13:56] <pitti> mvo: perhaps we can fast-pace 1:0.152.25.4 instead? that would be a good idea either way, for people who upgrade these days
[13:57] <mvo> pitti: yeah, I asked jibel if he has some spare cycles and I will also give it a go
[13:57] <pitti> jibel, mvo: does either of you have a natty VM for testing an oneiric upgrade? could we test an upgrade with the current -proposed u-m, and if that works, release it?
[13:58] <mvo> pitti: I will do it now, and +1 for fast tracking :)
[13:58] <mvo> thanks!
[14:00] <akgraner> Up next for Ubuntu Open Week in #ubuntu-classroom and #ubuntu-classroom-chat at 1400 UTC is How to contribute translating Ubuntu -- David Planella (dpm)
[14:06] <hallyn> zul, yay, fix is going into gnome-keyring upstream :)  meanwhile, i'm down to two failures in libvirt regression tests
[14:06] <zul> hallyn: sweet what are the failures?
[14:06] <hallyn> zul, dunno yet, just saw the summary.  trying to finish off qemu+ipxe first
[14:07] <zul> k
[14:08] <hallyn> zul, any interest in looking over my qemu 0.15 merge to make sure I didn't mess something up?
[14:08] <hallyn> (it tests fine and isn't much different from the one i ran for a month in september :)
[14:08] <zul> hallyn: i dont have any experience with qemu-kvm packaging so im probably not a good candidate
[14:08] <hallyn> nm, i'll just push
[14:08] <hallyn> to fix that archive problem i created at least
[14:09] <hallyn> what a day
[14:10] <hallyn> zul, failures are from test_CVE_2010_2237_2238 and test_virt_install_location
[14:10] <zul> k then it should probably be updated :)
[14:10] <hallyn> latter looks like a testcase bug:  it says it can't find <kernel>/home/serge/.virtinst/boot/virtinst-linux
[14:13] <hallyn> zul, biab
[14:36] <lfaraone> For UDS, Is it still possible to mark oneselv as attending specific talks / meetings?
[14:37] <maco> lfaraone: participation essential checkbox in blueprint
[14:47] <LoRez> I need ftp://ftp.comtrol.com/dev_mstr/rts/drivers/linux/devicemaster-linux-4.22.tar.gz packaged up for lucid.  It's a kernel module and utilities.  anybody know of a contractor willing to take it on?
[15:07] <mvo> pitti: fwiw, update-manager release upgrade with the -proposed version for natty->oneiric worked fine for me, jibels is still running afaik
[15:16] <seb128> slangasek, hey, could you look at bug #856988?
[15:17] <seb128> I've no real clue about it, but comments seem to indicate that the .gstreamer-0.10 cache could be confused by some of the multiarch changes
[15:17] <pitti> mvo: yay, thanks
[15:17] <seb128> it got some comments and user subscribed, it might be worth keeping an eye on it
[15:23] <pitti> mvo: jibel confirmed as well; releasing
[15:23] <pitti> mvo: oh, bugger
[15:23] <pitti> ATTENTION! update-manager requires a special procedure for releasing to -updates:
[15:23] <pitti>     https://wiki.ubuntu.com/ArchiveAdministration#Special_case:_update-manager_updates
[15:23] <pitti> mvo: ok, I'm afraid I don't have time for this today, as I'd need to wait for the publisher to finish, and I need to run out in 40 mins
[15:24] <pitti> mvo: so I can do it tomorrow morning, or you bug someone else with cocoplum access (infinity/cjwatson/slangasek) for help
[15:24] <mvo> pitti: well, I can tweak the metarelease file in the meantime to point to the proposed version
[15:25] <pitti> mvo: so, the actual package is in -updates now
[15:25] <jibel> pitti, the postgresql upgrade is still running, results in ~45min or so.
[15:25] <pitti> jibel: many thanks for the quick testing of everything, you rock!
[15:25] <pitti> mvo: but I suppose the wiki procedure is needed to really use the new version?
[15:25]  * mvo hugs jibel
[15:26] <cjwatson> pitti: I can do it
[15:26] <mvo> pitti: well, I can workaround by pointing to the explicit version in -proposed in the meta-release file, but once its in -updates that is much cleaner
[15:26] <pitti> cjwatson: thanks
[15:27] <mvo> thanks cjwatson!
[15:50] <cjwatson> pitti,mvo: done
[15:51] <slangasek> seb128: gstreamer hasn't been multiarched, so I have no idea why the cache would be confused.  Note that he says it works with /usr/lib32/gstreamer-0.10, which has nothing to do with multiarch
[15:52] <mvo> thanks cjwatson!
[15:53] <seb128> slangasek, ok, dunno then, I just wanted to point it
[15:53] <mvo> cjwatson: http://archive.ubuntu.com/ubuntu/dists/oneiric-updates/main/dist-upgrader-all/ is currently empty, will this take a bit until it hits the public server?
[15:53] <slangasek> seb128: doesn't look like anything I can help with, sorry.  I'll pull the multiarch tag off
[15:54] <slangasek> seb128: would probably be good to get a copy of one of these corrupted ~/.gstreamer-0.10 directories...
[15:54] <cjwatson> mvo: yes, it'll be visible after the next publisher run
[15:54] <seb128> slangasek, right, I will ask for details, I figured I would ping in case that's something which speaks to you ;-)
[15:54] <seb128> doesn't hurt to ask
[15:54] <cjwatson> so ~40 minutes I guess
[15:54] <slangasek> seb128: :)
[15:54] <seb128> slangasek, thanks
[15:54] <mvo> thanks
[15:55] <smb> cjwatson, could you work magic to allow kernel package uploaders to upload linux-lts-backport-oneiric. There must be something for the older lts-backport ones... Just cannot run the query_acl correctly it seems
[15:58] <cjwatson> smb: hmm, I can't see any sign that it was done for maverick or natty either
[15:58] <cjwatson> smb: I've added linux-lts-backport-{maverick,natty,oneiric} to the kernel packageset in lucid
[15:58] <cjwatson> smb: I think that should be enough
[15:58] <smb> cjwatson, OK, so it is not just my bad query skills... How the heck did we get those uploaded then...? Probably Tim did it all
[15:59] <smb> cjwatson, Great, yes that should be it
[15:59] <cjwatson> must have been done by a member of ubuntu-core-dev, yes
[16:02] <micahg> cjwatson: shouldn't MOTU be able to upload a new package as well?
[16:03] <cjwatson> micahg: I guess
[16:03] <cjwatson> micahg: I don't think that's relevant here though
[16:03] <micahg> cjwatson: adds another 70 or so people that can be poked :)
[16:03] <cjwatson> smb: oh, and done for linux-meta-lts-backport-{maverick,natty,oneiric} now too
[16:03] <micahg> unless it's already uploaded
[16:04] <smb> cjwatson, Ah, yes. Is that effective immediately or does it need some propagation time?
[16:04] <micahg> which it seems like it is../me goes whistling off in another direction
[16:04] <herton> cjwatson: this is the upload error: Changes file must be signed with a valid GPG signature: Verification failed 3 times: ['General error', 'General error', 'General error'] : Permission denied.
[16:04] <cjwatson> smb: immediately
[16:05] <cjwatson> herton: that might actually be a known red herring
[16:05] <soren> herton: I got that a lot a couple of days ago, too. The uploads went through just fine, though.
[16:05] <cjwatson> herton: you sure it didn't work anyway, despite the error?
[16:05] <cjwatson> herton: I see linux-lts-backport-oneiric in https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages, uploaded 49 minutes ago
[16:06] <herton> yeah, it is building, so it's ok I guess
[16:06] <smb> Oh darn, forgot we only upload there. So the upload rights do not matter at all
[16:07] <herton> cool, thanks, didn't come to my mind checking there
[16:19] <stgraber> @pilot in
[16:25] <penguin42> stgraber: Hi
[16:27] <stgraber> penguin42: hey
[16:28] <penguin42> stgraber: I was helping someone on -bugs yesterday, they've got a 1 line patch on bug 877791
[16:28] <penguin42> stgraber: It probably needs a qt person to know if it's the right solution; but it's a fix for crashes of a bunch of different apps which seems like a good thing
[16:29] <stgraber> didrocks: ^
[16:29] <stgraber> would indeed be nice to have that tested and commited to the appmenu trunk branch. Then we can get that in Precise and as SRU to Oneiric
[16:30] <didrocks> stgraber: penguin42: appmenu-qt is handled by agateau who is upstream, he's probably the best to review it
[16:30] <didrocks> not sure he's still around though
[16:31] <sroecker> penguin42: stgraber: that was me who filed that bug :)
[16:32] <penguin42> sroecker: Ah hi; I noticed there was a patch pilot around and remembered it from yesterday
[16:36] <maco> didrocks: agateau is still around. he works at canonical :)
[16:36] <agateau> stgraber: penguin42: will look into this tomorrow
[16:36] <maco> oh hi
[16:36] <agateau> maco: hi :)
[16:36]  * agateau has to go
[16:37] <didrocks> maco: depends, see :-)
[16:37] <stgraber> agateau: perfect. I assigned you the bug so you don't forget ;)
[16:37] <maco> didrocks: i thought you meant "around" in the "still maintaining" sense :P
[16:37] <didrocks> maco: ah not in that sense, indeed! :-)
[16:52] <yofel> mvo: can you take a look at https://code.launchpad.net/~yofel/software-properties/lp-819793/+merge/79424 ? Just so I know if that's correct. (it works for me)
[17:32] <jdstrand> !regression-alert bug 877905
[17:33] <jdstrand> !regression-alert
[17:33] <jdstrand> bug #877905
[17:33] <jdstrand> I am starting an incident report
[17:33] <jdstrand> this is a result of http://www.ubuntu.com/usn/usn-1232-1/
[17:34] <skaet> jdstrand,  ack.
[17:35] <jdstrand> mdeslaur is in the processing of confirming/triage/etc
[17:39] <jdstrand> https://wiki.ubuntu.com/IncidentReports/2011-10-19-xorg-server-security-update-breaks-glx
[17:48] <mvo> yofel: hello, thanks! this looks correct, but I will have to give it a fresh look in the morning to double check
[18:32] <jdstrand> fyi, problem found and fix being uploaded
[18:48] <LoRez> is there a better place to ask around for packaging contractors?
[18:51] <Laibsch> where can I see how long the SRU queue is for "ready to upload"-debdiff patches?
[18:52] <Laibsch> I've been waiting for over a month now.  It feels like being back in the "bad old days".  Reactions had been much swifter in the past which was nice.
[18:52] <Laibsch> stgraber?
[18:53] <micahg> Laibsch: doesn't exist anymore, SRU reviews are in queue
[18:53] <stgraber> http://reports.qa.ubuntu.com/reports/sponsoring/index.html will give you an idea of how far your item is in the queue
[18:54] <micahg> ah, sponsoring queue...
[18:55] <Laibsch> micahg: what doesn't exist anymore?  I was indeed asking about the queue, wasn't I?  I'm puzzled.
[18:55] <Laibsch> micahg: OK, seems we misunderstood each other.
[18:55] <micahg> Laibsch: I thought you meant SRU approved debdiffs to upload, not debdiffs to upload as SRUs
[18:56] <micahg> Laibsch: BTW, as long as I have you here, I had the unfortunately luck to be the last person to touch isdnutils, could we chat towards the end of next month about cleaning up the Ubuntu package
[18:57] <Laibsch> hehe
[18:57] <Laibsch> a terrible piece of work, I know
[18:58] <Laibsch> I'm HOPING to be able to get that in shape for syncing in time for precise
[18:58] <Laibsch> but there's a lot of obstables
[18:59] <Laibsch> micahg: and to be honest I'm still miffed about some of my patches I think that were even related to isdnutils that rotted for months and years without anybody bothering to even look (long time ago, granted)
[18:59] <micahg> Laibsch: Ubuntu has a higher version, so syncing will be hard (unless Debian takes the newer version), I can't discuss right now though, only 3.5 hours until eow for me
[18:59] <micahg> Laibsch: I'm happy to help you from the Ubuntu side next month
[18:59] <Laibsch> but that left me with the feeling that while I try to help Ubuntu by helping Debian (which I don't really use) that serious efforts are routinely wasted in Ubuntu :-(
[19:01] <Laibsch> micahg: obviously, I'm looking to get Debian up to that higher version.  I'm even trying to get upstream to make at least another bug-fix release.  But some stuff in Debian is now newer than in Ubuntu.  And that's the stuff that I actually care about.  So, a simple "push back the Ubuntu package" will not work.
[19:01] <tumbleweed> Laibsch: patches in launchpad are routinely ignored, yes. But if you can supply a debdiff and put it on the sponsor queue, it will be reviewed
[19:01] <micahg> Laibsch: right, that's part of what confused me about the whole thing...
[19:02] <Laibsch> tumbleweed: unfortunately, I'm speaking out of experience a few years past.  I followed all the steps. Trust me.  It used to be BAD (around the time lucid was released, IIRC)
[19:02] <Laibsch> micahg: let's chat about the details when you have time.
[19:03] <tumbleweed> Laibsch: the patch pilot process seems to have fixed things for the sponsorsorship queue, although it can still get a little long, it stays under control
[19:03] <micahg> Laibsch: ok, will come find you later
[19:03] <Laibsch> micahg: in a nutshell, what I'm trying to do is take small steps with what we have, make the build system sane and then hope for a smoother update.
[19:03] <Laibsch> instead of take newest upstream first and hope to backport the patches, for example.
[19:04] <Laibsch> tumbleweed: yes, the patch pilot is what fixed this.  Before it was terrible and that's the time I was referring to.  That's why I was a bit anxious to see things slipping back.
[19:05] <tumbleweed> Laibsch: yeah, those bad days predate me :) Please shout if things regress
[19:05] <Laibsch> tumbleweed, stgraber: It seems that my patch went back in the queue because I rebased it to the latest changes (which had ignored my debdiff :-( )
[19:05] <Laibsch> bug 379382
[19:06] <Laibsch> stgraber: thank you for the link. exactly what I was looking for
[19:15] <jdstrand> !regression-alert
[19:16] <jdstrand> please consider bug #877905 resolved. updated packages are confirmed to fix the problem. we are currently waiting for other architectures to finish building
[19:20] <ScottK> Thanks for jumping right on it.
[19:21] <jdstrand> sure thing
[19:21]  * jdstrand hugs mdeslaur 
[19:21] <mvo> hallyn: if you don't mind I will upload a new vm-builder for precise that can build precise images
[19:27] <stgraber> Laibsch: uploaded
[19:27] <Laibsch> stgraber: great. Many thanks.
[19:28] <stgraber> Laibsch: btw, what are the plans for maverick and natty?
[19:28] <Laibsch> how do I read that link, though. There's still patches several months old.
[19:28] <Laibsch> I suppose those are waiting for fixes to the patches themselves?
[19:28] <Laibsch> stgraber: maverick and natty did not apply cleanly.  Personally, I'm mostly concerned about lucid/LTS-releases.
[19:29] <stgraber> yeah, some are there because they aren't worth an SRU at this time (typo fixes and similar), some are waiting feedback, ...
[19:29] <Laibsch> that's why I left it at that.  I did not feel confident to rebase the patches from upstream. I merely packaged them.
[19:30] <hallyn> mvo, great, thanks
[19:31] <Laibsch> stgraber: so, you have to follow that list/URL to have a feel of where things are at?  I'm a bit unsure of how to read it.
[19:33] <stgraber> Laibsch: yeah, ideally that list should really only contain things that are either ready for review or ready for upload. Unfortunately it's not entirely the case at the moment. We also have the problem of some of them appearing twice (once has a bug and once as a merge proposal)
[20:29] <stgraber> @pilot out
[20:31] <slangasek> bah, we really need smarter tools for merging .po files as part of package updates
[20:35] <salty-horse> hey. where can I find the source for the installer's (ubiquity?) partition manager? I think I found a bug
[20:38] <smoser> ls -l /proc/SOMEPID/fd/
[20:38] <smoser> shows ' 0 -> pipe:[12113]'
[20:38] <smoser> what is 12113 ?
[20:46] <Laibsch> salty-horse: "pull-lp-source $packagename"
[20:46]  * Laibsch invites salty-horse over to #ubuntu-bugs
[20:47] <salty-horse> Laibsch, I know that :). I'm asking which package name :)
[20:48] <Laibsch> OK.  Next try ;-)  "dpkg -S $pathtobinaryname"
[20:48] <salty-horse> that's hard since it's part of the installation
[20:48] <Laibsch> $pathtobinaryname = $(which $binaryname) ;-)
[20:48] <salty-horse> I looked at ubiquity, but I'm not sure where exactly is the partition editor. it seems to have third party debian code
[20:53] <DoctorPepper> hi guys !!!
[20:53] <Daviey> jbicha: Hey!
[20:53] <DoctorPepper> agateau:  are you here ?
[20:53] <Daviey> jbicha: did you see bug 875818?
[21:32] <lightnin> I see that some 32 bit packages can now be installed on amd64 Oneiric.
[21:32] <lightnin> How does one create a i386 package that is compatible with amd64 architecture? (And doesn't make users Force the install?)
[21:33] <broder> lightnin: the term you're looking for is "multiarch". https://wiki.ubuntu.com/MultiarchSpec is the spec
[21:34] <cjwatson> lightnin: also http://wiki.debian.org/Multiarch/Implementation
[21:35] <lightnin> cjwatson: Thanks! That second one I hadn't found...
[21:35] <Laibsch> lightnin: There's also #multiarch channel on oftc servers
[21:36] <Laibsch> stgraber: is the upload already building or will that have to be handled by somebody else?
[21:36] <lightnin> Multiarch is enabled by default in Oneiric, correct?
[21:36] <Laibsch> IOW, will this be "verification-needed" in a few hours?
[21:36] <cjwatson> lightnin: on amd64 systems, yes
[23:03] <stgraber> Laibsch: it's been uploaded to the -proposed queue, the SRU team will review and let it through to -proposed if that looks good
[23:35] <bdmurray> lucas: is there a reason ubuntu bug descriptions don't appear in the ubuntu_bugs table in udd?