[00:00] <RAOF_> Hm.  That was apparently a bad time to update.  It seems that everything I start from gnome-terminal sits in D state in rtnl_lock
[00:00] <slangasek> retinal lock?
[00:00] <RAOF_> I don't know what crazy kernel internal bit that is :)
[00:01] <RAOF_> Ah, no.  Maybe it's anything which hits some part of the networking stack…
[00:04] <RAOF_> Yeah, that's it.
[00:08] <RAOF_> It's not been a good couple of days for oneiric :(
[00:09] <slangasek> so this is after a post-upgrade reboot?
[00:10] <RAOF_> slangasek: Yes.
[00:11] <slangasek> well, doh
[00:11] <RAOF_> (And that was xchat-gnome dying for no obvious reason) :)
[00:13] <RAOF_> Hm.  And the previous kernel doesn't seem to help at all.
[00:31] <RAOF> But preventing network-manager from loading works.
[01:03] <cyphermox> RAOF: reading backlog, so NM issue or is it conclusively kernel? (or could it be libnl?)
[01:03] <RAOF> cyphermox: Not conclusively kernel; switching to an older kernel doesn't change the issue.
[01:04] <RAOF> cyphermox: Definitely related to NM in some way; disabling it (by killing /etc/init/network-manager.conf - running "stop network-manager" *also* hangs) and bringing up eth1 manually with dhclient works.
[01:05] <RAOF> Might be related to libnl, or wireless.
[01:05] <cyphermox> huh, stop NM hangs?
[01:05] <cyphermox> that's probably not libnl or wireless :)
[01:06] <cyphermox> just in case, have you tried downgrading n-m to 0.8.9997+git.20110721t045648.36db194-0ubuntu1?
[01:06] <RAOF> I've not yet tried that.  I'll do so once my other stuff hits an appropriate checkpoint.
[01:07] <cyphermox> ok... let's still check something though; but let's do this in #ubuntu-desktop
[04:05] <pitti> Good morning
[04:05] <pitti> tkamppeter: pong
[06:25] <tkamppeter> pitti, hi
[06:27] <tkamppeter> Can you upload CUPS to Debian and Ubuntu now? The first shot of PPD update centralization did not work (needed a small fix) and I have also found a bug which made some of the available PPDs not appea, rendering several hundreds of supported printers appearing unsupported.
[06:27] <tkamppeter> pitti ^^
[06:32] <jbicha> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2011-August/thread.html is a few days out of date
[06:43] <pitti> tkamppeter: ah, sure
[06:54] <pitti> tkamppeter: done
[07:00] <dholbach> good morning
[07:01] <tkamppeter> pitti, thanks.
[07:23] <Sweetshark> hggdh: ping?
[07:32] <nigelb> Sweetshark: I'm fairly sure he'd be asleep now
[07:39] <pitti> Daviey: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt has a whole lot of eucalyptus and dependencies that want to go to universe
[07:40] <pitti> Daviey: is that deliberate? switching to openstack now?
[07:40] <pitti> (or whatever the name was)
[07:43] <Sweetshark> doko: got the message about translate-toolkit?
[07:44] <doko> Sweetshark, no nothing seen yet
[07:45] <Daviey> pitti: yes, jamespage opened a bug to try and speed it up aswell
[07:46] <Daviey> bug 816408
[07:46] <pitti> Daviey: oh, the demotion can happen any time, that's not a problem
[07:46] <pitti> or time critical
[07:46] <pitti> I just wondered whether it was deliberate
[07:46] <Daviey> pitti: it is deliberate
[07:48] <Sweetshark> doko: the "remove Matthias Klose who is no longer involved in this package" wasnt me, it was upstream debian doing that
[07:49] <doko> bah
[07:51] <Sweetshark> nigelb, brian-murray, jorge, leannogasawara, pvilllavi: anyone awake who can prevent me from expiring in ubuntu-bugcontrol?
[07:51] <nigelb> Sweetshark: do you expire today?
[07:52] <Sweetshark> nigelb: no, it will be a few more days.
[07:52] <nigelb> if not, I'm sure, one of those pings will hit somone who'll do it tomorrow morning
[07:52]  * Sweetshark checks ...
[07:52] <nigelb> :)
[07:52] <Daviey> Sweetshark: can you not renew yourself?  I thought it allowed self renewewl?
[07:54] <nigelb> wait, you summoned pedro_  ;)
[07:55] <nigelb> Daviey: No bugcontrol is not self renewal
[07:55] <pedro_> hey nigelb ;-)
[07:55] <Sweetshark> Daviey: ugh, where would I find that in launchpad? I am asking for the guys named above at those are the ones proposed to me in the nagmail.
[07:55] <nigelb> pedro_: Sweetshark wants his bc membership renewed :)
[07:56] <pedro_> Sweetshark, just $5000 dollars ;-)
[07:56] <iulian> Wow.
[07:56] <nigelb> lol
[07:56]  * nigelb goes to blog about corruption in the community :P
[07:56] <iulian> $1000 ought to do it though.
[07:56] <iulian> pedro_: You just can't ask for that much.
[07:56] <pedro_> Sweetshark, what's the lp id?
[07:56] <Sweetshark> pedro_: wait a few more month, when the fed has printed enough, I might comply ;D
[07:56] <pedro_> iulian, oh well, with the financial crisis and all that... we have to raise the price :-P
[07:57] <Sweetshark> pedro_: bjoern-michaelsen
[07:57] <nigelb> iulian: I think the trick is to start high and then negotiate to something like 0$ :P
[07:57] <iulian> Heh.
[07:57] <nigelb> pedro_: all of QA at the sprint?
[07:58] <pedro_> Sweetshark, renewed ;-)
[07:58] <Sweetshark> pedro_: thanks
[07:58] <pedro_> nigelb, nope, just the defect analysts
[07:58] <nigelb> pedro_: nice :)
[08:07]  * ogra_ hugs pitti seeing the last u-meta upload .... does gnome-user-guide stay off the images permanently now ?
[08:07] <pitti> ogra_: well, at least until the docs team switches back to having everything tehre :)
[08:07] <ogra_> hrm
[08:07] <pitti> but as we just switched back and forth, I guess it'll stay that way now, and it seems to make more sense
[08:07] <ogra_> sad, i was hoping ...
[08:08] <pitti> ogra_: I guess it's one of the packages which take a week to unpack?
[08:08] <ogra_> it is the one package that makes SD card based rootfses scream
[08:08] <ogra_> takes about 20min to unpack here
[08:08] <ogra_> right :)
[08:08]  * ogra_ types to slow today 
[08:22] <bdmurray> Is there an archive admin channel anymore?
[08:23] <infinity> Was there ever?
[08:24] <bdmurray> I seem to recall there being one otherwise I wouldn't have asked. ;-)
[08:24] <infinity> I don't recall ever having been in one, but I may have missed the memo. ;)
[08:24] <bdmurray> Anyway I'm curious about how to get a package removed from the archive.
[08:24] <infinity> File a bug, subscribe us.
[08:24] <infinity> I'm willing to bet there might even be a cute helper tool for the bug filing, but not sure.
[08:25] <bdmurray> I'd imagine just saying I think this package should be removed isn't quite enough though.  What type of content should I include?
[08:26] <infinity> Whatever justification you have, really.
[08:26] <infinity> "It was removed from Debian, and we have no interest in maintaining it in Ubuntu" is a good one.
[08:26] <infinity> If it's Ubuntu-specific "we don't maintain it, and neither does MOTU" works.
[08:27] <infinity> It it's still in Debian, but complete crack, then a longer justification would be needed, along with a reminder to blacklist it from syncs.
[08:28] <bdmurray> Fails to start, has 1 star in software center and hasn't been updated since lucid and has lots of crash reports?
[08:28] <infinity> All of that sounds like bug reports to me.  We could, y'know, fix it.
[08:29] <infinity> One star doesn't mean much to me.
[08:29] <infinity> We have tons of software no one would ever install from Software Centre.
[08:30] <infinity> And "lots of crash reports" sounds like it's used.
[08:30] <jbicha> but is it maintained?
[08:30] <bdmurray> Right we could fix it but the bugs have been around forever bug 132636 and bug 703556
[08:30] <bdmurray> So we haven't gotten around to fixing it yet
[08:32] <hrw> hi
[08:33] <hrw> SyntaxError: ("'continue' not properly in loop", ('/usr/share/apport/package-hooks/source_ubiquity.py', 30, None, 'continue\n'))
[08:33] <infinity> hrw: Already fixed.
[08:33] <hrw> thx
[08:33] <infinity> hrw: Upgrade with an up-to-date mirror. :)
[08:34] <hrw> infinity: ok
[08:34] <infinity> bdmurray: I'm just playing devil's advocate here, to be fair.  I suspect that the glaring bugs could be fixed pretty quickly if someone took the time.  And our maintainerless system does tend to let things fall through the cracks, which is a bit irksome.
[08:35] <infinity> bdmurray: Also, given that I don't see those particular error in the Debian BTS, either the problem is Ubuntu-specific (quite likely), or more Ubuntu users use it than Debian ones.  Either way, it hasn't been updated in Debian because it's not RC buggy there.
[08:35] <infinity> (Though I'm not sure it's hugely well-maintained in Debian either, from the looks of it)
[08:35] <infinity> Meh.
[08:36] <seb128> doko, did you mean to score your archive rebuilds over normal ppa builds?
[08:36] <infinity> bdmurray: (It could just be that it needs to be rebuilt or something if it links against stuff that's been changing under its feet)
[08:36] <doko> seb128, yes, in batches of 200
[08:37] <seb128> :-(
[08:37] <doko> until main is built
[08:37] <seb128> doko, ok, pitti helped, but dx has been blocked since yesterday to get their compiz ffe update building to be able to test it
[08:37] <seb128> that sucks
[08:37] <seb128> that's blocking people to get real work done
[08:38] <pitti> but at the same time the rebuild test isn't very useful if it's not getting through quickly
[08:38] <doko> fixing build failures is real work. soyuz sucks
[08:38] <pitti> and frankly, I consider the rebuild test more urgent than daily maverick chromium/firefox builds
[08:38] <pitti> we can still manually score up the urgent ones
[08:38] <seb128> pitti, why not? what difference does it make if it tests tomorrow's version of a source rather than yesterday's?
[08:38] <doko> and there are 10 non-working machines, which are not given back currently
[08:39] <pitti> seb128: because these builds are already queued, so you wouldn't test tomorrow's source
[08:39] <infinity> bdmurray: Actually, looking more closely, the balazar issues on Ubuntu look to be in soya, not balazar.
[08:39] <pitti> seb128: you'd get build failure reports which were already fixed in a newer version
[08:40] <seb128> pitti, ok, fair enough, I guess I will just nag you today for dx when they have builds they need, I want that compiz ffe sorted
[08:40] <seb128> just a bit annoyed that they wasted half a day waiting for builds
[08:40] <pitti> seb128: sure
[08:40] <seb128> pitti, danke ;-)
[08:44] <doko> seb128, pick up your favourite build failures at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110816-oneiric.html ;p
[08:45] <pitti> xvfb-run: error: Xvfb failed to start
[08:45] <pitti> awesome
[08:46] <pitti> that might hit a few test suites
[08:46] <seb128> doko, do you want a list of the ones we (desktop) can look at?
[08:46] <wgrant> seb128: There are package sets on that page now.
[08:46] <wgrant> Which may be relevant.
[08:46] <infinity> Don't we break xvfb-run every second release?
[08:46] <doko> seb128, I assume that would be the ubuntu-desktop package set?
[08:46] <seb128> wgrant, where?
[08:46] <wgrant> seb128: Should be links at the top to lists down the bottom.
[08:46] <seb128> oh, tooltip under the checkmark
[08:46] <wgrant> Also that, yeah, but there are per-packageset lists down the bottom.
[08:47] <wgrant> And FTBFS bugs are shown too, if present.
[08:47] <seb128> doko, wgrant: ok, thanks
[08:47] <seb128> we will look at the desktop ones
[08:47] <doko> ScottK: same for the kubuntu ones
[08:47] <doko> Daviey, and the server ones ...
[08:48] <seb128> doko, pitti: seems mono is not installable on amd64, that will be leading to quite some builds issues as well
[08:48] <seb128> it's because it failed to build on i386 and there is an arch all,any mismatch for the binaries
[08:48] <pitti> yeah, see http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html
[08:48] <doko> it doesn't seem to be all mono afaics
[08:48] <seb128> not all, but a few are
[08:49] <doko> as directhex, he did ask for the sync
[08:49] <seb128> there is a least 5 of the desktop ones due to it
[08:49] <seb128> Laney was looking at it I think
[08:50] <wgrant> Laney and directhex mentioned it yesterday.
[08:50] <wgrant> I think.
[08:50] <Daviey> doko: I've already got it open :)
[08:51] <directhex> it's maddening. it only fails on ubuntu's i386 builders. it's not reproducible on debian's builders or locally
[08:51] <pitti> directhex: the buildds run on the lucid kernel, might that be related?
[08:52] <pitti> directhex: was a rebuild already tried? i. e. not just gamma rays?
[08:52] <directhex> pitti, yes. and it fails on two different buildds
[08:53] <pitti> infinity: do the PPA builds "see" a different kernel due to the virtualization?
[08:53] <pitti> i. e. in such cases, is it worth trying a build in a PPA to see whether it's any different?
[08:53] <directhex> it builds in an oneiric ppa. i can fling it at a lucid ppa?
[08:54] <wgrant> PPA kernels don't differ by series.
[08:54] <pitti> directhex: that's what I meant
[08:54] <pitti> directhex: an oneiric build in an oneiric PPA might actually use an oneiric kernel in the VM
[08:54] <wgrant> It doesn't.
[08:54] <pitti> directhex: while on the ubuntu builders it uses the lucid kernel
[08:55] <pitti> wgrant: ah, these don't use kvm then?
[08:55] <pitti> or xen?
[08:55] <wgrant> I think all the VMs are Lucid kernels, but it's complicated due to Xen.
[08:55] <wgrant> pitti: There is a Lucid VM, with a $series chroot.
[08:55] <pitti> ah, right, with Xen client-side kernels are optional
[08:55] <pitti> wgrant: I see
[08:55] <pitti> thanks
[08:55] <pitti> wgrant: so that pretty  much rules out a kernel issue then
[08:55] <pitti> we had that problem with glib (failed on a too old kernel)
[08:55] <wgrant> The PPA VMs may well be running a somewhat custom kernel, but who knows...
[08:56] <wgrant> We've had issues with mono on Xen before.
[08:56] <wgrant> But not, AFAICR, a situation where it worked on Xen but not on bare metal :)
[08:56] <directhex> rothera and vernadsky have similar hardware?
[08:56] <wgrant> They're both bases.
[08:56] <wgrant> So within a year or so, probably.
[08:57] <wgrant> Both should be i386 kernels.
[08:57] <directhex> and the other three builders? which of them is significantly different?
[08:57] <seb128> pitti, the glib issue was happening on ppa builds as well
[08:57] <wgrant> directhex: roseapple and zirconium are very different.
[08:57]  * pitti always chuckles when he sees DMI info in bug reports with "MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M."
[08:57] <wgrant> directhex: roseapple may be an amd64 kernel.
[08:58] <wgrant> directhex: zirconium was originally an lpia builder, so I don't know what it is.
[08:58] <AnAnt> Hello, why doesn't Ubuntu sync the  openbios-*  packages from Debian ?
[08:58] <Daviey> doko: I see last time you raised ftbfs bugs based on the rebuild, are you doing that again?
[08:58] <doko> Daviey, later this week
[08:58] <directhex> can we briefly disable vernadsky etc, and jab the rebuild button, so it goes on roseapple or zirconium?
[08:59] <wgrant> Sure, I can do that. Which build?
[08:59] <directhex> https://launchpad.net/ubuntu/+source/mono/2.10.4-2/+build/2687881
[08:59] <doko> directhex, set to manual, please upload
[09:00] <directhex> doko, i need to upload a 2build1?
[09:00] <wgrant> No, it's queued now.
[09:00] <Daviey> doko: Are you doing them manually, or scripted?
[09:00] <pitti> no, we just need to retry
[09:00] <wgrant> Should start in 5s or so.
[09:00] <wgrant>  Currently building on roseapple
[09:00] <directhex> okay, cool. let's see how this goes
[09:00] <doko> scripted, but need to check the script first ...
[09:01] <wgrant> (I manualled zirconium too, because I trust roseapple more)
[09:01] <directhex> all my local test builds have been on an amd64 kernel. i think Laney was working on an i386 VM
[09:01] <wgrant> Everything back to auto.
[09:01] <directhex> i eagerly await the result :/
[09:01] <pitti> directhex: don't watch the build log, lest it takes forever :)
[09:02] <directhex> it was 40 minutes on vernadsky. i expect less time on faster tin
[09:04] <AnAnt> https://launchpad.net/ubuntu/oneiric/+source/openbios-ppc  <- why aren't there binaries generated for openbios-* packages ?
[09:05] <pitti> AnAnt: failed to build
[09:05] <directhex> AnAnt, sounds like the old "can't build arch:all packages on non-i386" issue
[09:05] <pitti> https://launchpadlibrarian.net/70891377/buildlog_ubuntu-oneiric-i386.openbios-ppc_1.0%2Bsvn1018-1_FAILEDTOBUILD.txt.gz
[09:05] <pitti> "This package must be built on a PowerPC machine"
[09:05] <AnAnt> aha
[09:06] <Laney> the VM build succeeded
[09:06] <AnAnt> pitti, directhex: thanks
[09:06] <directhex> Laney, which kernel?
[09:06] <Laney> O
[09:06] <Laney> 3.0.0-7
[09:06] <directhex> install an l kernel?
[09:06] <Laney> -generic-pae
[09:06] <Laney> yeah, said that yesterday
[09:07] <infinity> pitti: Nearly all (or maybe all by now) of the PPA machines are amd64, while the i386 distro buildds are actually i386, that's probably the difference.
[09:09] <pitti> ah, good to know
[09:09] <wgrant> infinity: Even roseapple?
[09:09] <wgrant> infinity: I thought it was amd64.
[09:10] <wgrant> (it appeared while you were gone)
[09:10] <infinity> wgrant: Oh, roseapple's new.  And almost certainly amd64 hardware.  No idea what kernel it's running, though.
[09:10] <infinity> wgrant: rothera and vernadsky are both i386 for sure, though.
[09:10] <wgrant> Yup.
[09:11] <wgrant> IIRC palmer is a little nicer than them, but still i386.
[09:11] <infinity> That said, "building on amd64 to make it work" is the wrong answer.  If we still ship and support i386, we should figure out why things don't work there.
[09:12] <directhex> infinity, agreed - but how long do you want to hang around & wait, with a messed up archive?
[09:12] <directhex> sigh, the only i386 tin in the house has a maverick kernel
[09:13] <infinity> directhex: I'm not averse to workarounds, but I'm wary of workarounds that then lead to people forgetting about and not fixing bugs.
[09:13] <directhex> et voila, it just got past the failure point
[09:14] <jamespage> morning - please could someone with appropriate perms poke the package importer for the jenkins source package - it borked with a TooManyConcurrentRequests error.
[09:17] <cjwatson> jamespage: if nobody appropriate responds here, file a bug on bugs.launchpad.net/udd
[09:17] <jamespage> cjwatson: OK - thanks for the advice
[09:19] <Daviey> jamespage: In other news, did you see that slangasek was looking at porting the cdbs maven support into dh?
[09:19] <jamespage> Daviey: nope - missed that one
[09:20] <jamespage> I know its on the list for the debian-java team
[09:20] <jamespage> but I don't think anyone is working on it ATM
[09:25] <dholbach> @pilot in
[09:26] <doko> jamespage, could you have a look at component mismatches, and confirm the demotion of all the java packages?
[09:26] <pitti> doko: already discussed with Daviey, and demoted
[09:26] <jamespage> doko: ack - I'll take a look now
[09:26] <pitti> doko: it's due to the demotion of eucalyptus
[09:26] <doko> ahh, ok
[09:26] <pitti> bug 816408
[09:26] <pitti> jamespage: ^
[09:27] <jamespage> pitti: stopping looking now...
[09:29] <dholbach> jamespage, is https://bugs.launchpad.net/ubuntu/+source/antlr3/+bug/814819 something the release team should have a look into? is it a bugfix release only?
[09:31] <jamespage> dholbach: its not bugfix only - 3.0 -> 3.2 made quite a few changes
[09:31] <jamespage> dholbach: just thinking about the best way to deal with this package
[09:32] <dholbach> jamespage, is there anything that needs to be transitioned after the update?
[09:35] <jamespage> dholbach: it only has a few reverse-build-depends
[09:35] <jamespage> so it would be minimal
[09:36] <directhex> Finished a moment ago (took 35 minutes, 16.5 seconds)
[09:36] <directhex> infinity, wgrant ^
[09:36] <directhex> also pitti i guess
[09:36] <pitti> yay
[09:36] <dholbach> jamespage, maybe it'd be good to list those reverse-build-deps and what needs to be done to them and add something like a NEWS file diff to the bug, so the release team can have a second look - I'm happy to deal with it from a sponsoring POV
[09:37] <jamespage> dholbach: OK - I'll stick it on my list
[09:38]  * dholbach hugs jamespage
[09:38] <dholbach> I'll subscribe to it
[09:39] <ev> what's the correct way to supersede a package? Is it the Provides, Conflicts, Replaces trifecta or is simply declaring Replaces sufficient?
[09:39] <pitti> ev: for permanently obsoleting it, Conflicts:/Replaces:
[09:39] <directhex> pitti, that should get the archive running again. we're scrambling to reproduce the issue locally, still
[09:40] <pitti> ev: "Provides:" if it's a binary compatible drop-in replacement, or just a newer choice
[09:40] <dholbach> thanks jamespage
[09:40] <pitti> ev: just replaces: wouldn't cause package removal, just file overwriting
[09:40] <directhex> provides: doesn't help for versioned depends though
[09:40] <jamespage> dholbach: np
[09:40] <directhex> iirc
[09:44] <tjaalton> poolie: hey, which thinkpad model do you have?
[09:47] <tjaalton> poolie: asking since I noticed that on 745112 you reported of a similar issue which is now reported as a regression on the kernel from natty-proposed, bug 814325
[09:48] <ev> pitti: you're a star; thanks
[09:54] <tjaalton> poolie: ah, X201 I guess? could you still read through that other bug and post your findings there, and if possible, test oneiric to see if you can reproduce the regression
[09:56] <pitti> ugh, what's up with LP? It keeps logging me out, and fails to change bug states, add comments, etc.
[09:57] <tjaalton> poolie: we've had a hard time getting it confirmed on any other hw, so it would be great to find another machine and then figure out what's common with those setups. thanks!
[10:02] <soren> pitti: I'm seeing the same thing. Just raised it in #launchpad
[10:11] <soren> pitti: Should be fixed now.
[10:11] <soren> pitti: Poke henninge in #launchpad if that's not the case.
[10:11] <pitti> thanks!
[10:11] <soren> I'm just the messenger :)
[10:30] <dholbach> cjwatson, hey Colin - how are you doing? how do you feel about merging debhelper 8.9.4 (https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/812120)? AFAICS it consists entirely of bug fixes
[10:31] <cjwatson> I think it needs an FFE for safety's sake
[10:32] <cjwatson> debhelper merges should not be just waved through at this point IMO
[10:32] <dholbach> ok, no worries, I'll add some info and subscribe the release team and make sure that it's OK from a sponsoring POV
[10:32] <cjwatson> the changes in 8.9.4 look subtle, especially the buildflags change, and personally I would rather defer it unless there is a clear reason
[10:33] <cjwatson> Ahmed should be giving explicit justifications for merging debhelper at this point
[10:33] <cjwatson> i.e. "it will fix these build problems over here"
[10:33] <dholbach> ok, I'm happy to point this out
[10:33] <cjwatson> thanks
[10:34]  * cjwatson goes back to the NBS slog
[10:34] <dholbach> unfortunately the consecutive merges have been overlooked for about a month, but still he should add some justification
[10:34] <dholbach> although it seems he forgot so subscribe sponsors
[10:34] <dholbach> thanks cjwatson
[10:34] <cjwatson> argh, python-elementary, stop failing to build
[10:35] <cjwatson> oh, chroot problem
[10:38] <lamont> smacking buildds around a bit
[10:50] <hrw> doko: alive?
[10:52] <doko> hrw: ohh, do I get the arm biarch patch?
[10:53] <hrw> doko: sorry, next week - I work remotely nto my main machine now ;(
[10:53] <hrw> doko: I had an issue with cross binutils build but it was just missing deps on my side. sorry
[10:56] <debfx> dholbach: could you have a look at bug #827489, it's a fix for a regression introduced in the last udev upload
[10:57] <doko> seb128, directhex: which packages in the test rebuild archive should be given back now that mono did build?
[10:57] <directhex> doko, is there a list?
[10:58] <dholbach> debfx, sure
[10:58] <doko> directhex, sure, see the topic
[10:59] <Laney> gnome-sharp2 gtk-sharp2 libappindicator launchpad-integration linindicate libreoffice libubuntuone nunit
[10:59] <Laney> banshee
[11:00] <Laney> anything in main which reverse-build-depends on mono-devel
[11:01] <doko> Laney, libreoffice ftbfs on i386 too
[11:01] <doko> Sweetshark, ^^^
[11:02] <Laney>  mono-devel : Depends: libmono-cil-dev (= 2.10.3-1) but it is not going to be installed
[11:02] <Laney> sounds like skew
[11:06] <doko> thanks! given back
[11:06] <Sweetshark> doko, Laney: yes, mono-deps in LO are a mess.
[11:06] <Laney> i'd like to see a build log
[11:06] <Laney> but it's probably best to disable those bindings
[11:06] <Sweetshark> Laney: already done
[11:07] <Laney> not uploaded though?
[11:08] <Sweetshark> Laney: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-oneirictest-20110718/+sourcepub/1859989/+listing-archive-extra
[11:08] <doko> Sweetshark, why not test it in the distro?
[11:08] <Laney> cool
[11:09] <Sweetshark> Laney: nope, not uploaded. Needs a FFe (because I wasted so much time with mono :/), and I still need to get the LO-l10n to build ...
[11:09]  * Sweetshark crosses fingers (145/152 modules done)
[11:11] <directhex> last time i tried to test-build OOo to debug mono problems, it was just filled with fail in other places, so i gave up. couldn't rebuild it locally at all.
[11:11] <Sweetshark> the mono stuff seems to be mixing mono1 headers and mono2 tooling, which is a path to doom anyway likely.
[11:12] <Sweetshark> directhex: the official binary downloads on libreoffice.org do not have mono either, but debian does (and we did), so I tried to keep it alive.
[11:12] <Laney> i suspect upstream no longer cares for that
[11:12] <doko> lamont, if it's smacking time, please smack the builds on dubnium and hassium too so that I can downscore these
[11:13] <directhex> Sweetshark, the bindings were part of go-oo, but not ooo upstream
[11:13] <dholbach> cjwatson, I'll have a look at your meta-gnome2 update - seems we like had a mid-air collision, when I uploaded a merge from debian earlier
[11:13] <lool> slangasek: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/828014 seems to hit some people switching to multiarch; on my system, /usr/share/doc/libfontconfig1/AUTHORS is a (looping) symlink to ../libfontconfig1/AUTHORS, but that's not what the .deb ship and I couldn't find any maintainer snippet creating these symlinks at install time, so I'm a bit puzzled; if I compare the .debs for i386 they both ship a real file, and the contentsmatch
[11:14] <Sweetshark> directhex: most of go-oo patches have been migrated to the main LO repos though -- but mono wasnt.
[11:14] <directhex> Sweetshark, i think that's politics
[11:15] <Sweetshark> directhex: it is ;)
[11:15] <doko> Daviey, pitti: eucalyptus-commons-ext is still in main
[11:15] <directhex> plus ca change
[11:16] <cjwatson> dholbach: I think that merge dealt with a small part of it but that there's still more to go
[11:16]  * Sweetshark is "member of the engineering steering commitee" for LO
[11:16] <Sweetshark> directhex: I see enough politics
[11:16] <dholbach> cjwatson, yep - will have a look
[11:16] <cjwatson> dholbach: I saw the existing merge but decided that I was going to want somebody who knew GNOME to look at it anyway :-)
[11:16] <pitti> doko, Daviey: demoting
[11:16] <lool> slangasek: hmm this might be due to a temporary loss of the Debian diff
[11:17] <directhex> Sweetshark, i find it particularly amusing when LO/OOo eat microsoft's lunch, and mono doesn't. which is the bigger "danger" to MS's bottom line? therefore which has a bigger target painted on its back?
[11:17] <Daviey> doko / pitti: thanks!
[11:24] <Sweetshark> directhex: well, but for the same reason other 800lb gorillas (*cough* IBM *cough*) still care about LO/OOo and might go nuclear in a patent shootout too. mono was always a novell only show -- nobody cared for it, as everyone else used java (either from sun, or their own impl.).
[11:25] <directhex> true
[11:46] <poolie> hi tjaalton, i've since upgraded my laptop to oneiric
[11:48] <tjaalton> poolie: ah, ok. do you get the same regression though?
[11:49] <OdyX> tkamppeter: Thanks for the fixes to my patch; it was needed indeed.
[11:49] <Daviey> doko: The fixes you suggested for MIR of bug #
[11:49] <OdyX> .oO(I spent 2 hours yesterday trying to fix those issues and ended seeing that you had committed that already. :-/ )
[11:49] <poolie> tjaalton: actually i have been seeing that, i think even on oneiric
[11:49] <Daviey> doko: bug 825110 have just been uploaded, would you mind ack'ing the MIR if you are happy please?
[11:49] <poolie> on 3.0.0-7 or -8
[11:50] <poolie> i thought i filed another bug (which would be a dupe of this)
[11:50] <poolie> ... but thinking back i actually i did not
[11:54] <doko> Daviey, ok, will do
[11:55] <tjaalton> poolie: ok, could you post your findings on the newer bug I mentioned, it would be valuable to find another machine with this issue..
[11:55] <tjaalton> err, we found that, but would be nice for others to know about it too :)
[12:02] <poolie> tjaalton: xchat crashed, that was exciting
[12:02] <poolie> anyhow, i can reproduce some similar stuff
[12:03] <tjaalton> poolie: ok, that might still be relevant to the bug
[12:03] <Daviey> doko: thanks!
[12:03] <tjaalton> 14:55 < tjaalton> poolie: ok, could you post your findings on the newer bug I mentioned, it would be valuable to find another machine with this issue..
[12:03] <tjaalton> 14:55 < tjaalton> err, we found that, but would be nice for others to know about it too :)
[12:03] <poolie> bug 814325?
[12:04] <poolie> i'll boot it up and see if that's actually true
[12:05] <tjaalton> poolie: yep
[12:06] <tjaalton> there's a simple script to help in reproducing the issue
[12:07] <mdeslaur> cyphermox: are you planning an evo upload soon? if not, I'll take care of bug 828693 later today
[12:09] <poolie> ok
[12:09] <poolie> 615MB of updates first
[12:09] <poolie> (!)
[12:09] <tjaalton> hehe
[12:15] <doko> Daviey, package new'ed, will promote it in the next cycle
[12:17] <hggdh> Sweetshark: pong
[12:19] <Sweetshark> hggdh: thanks, already solved it was about my expiring bugcontrol membership.
[12:19] <hggdh> Sweetshark: ah, OK.
[12:20] <doko> directhex, Laney: nunit failed again
[12:21] <Laney> i think that one awaits a sync
[12:21] <Laney> doko: got a link to the build log, please?
[12:21] <Laney> it's not on the index yet
[12:22] <doko> Laney, https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+builds?build_text=&build_state=failed
[12:23] <doko> seb128, pitti: fyi started the next batch of test rebuilds
[12:24] <seb128> doko, ok
[12:27] <Daviey> doko: thans
[12:27] <Daviey> thanks*
[12:41] <dholbach> can somebody please mark https://code.launchpad.net/~gal-fourier/ubuntu/natty/opencv/bug-756154/+merge/68171 as obsolete? it seems like all the related bugs are fixed in a newer version already
[12:42] <StevenK> dholbach: You should be able to ?
[12:42] <dholbach> StevenK, it's "natty" - so it looks like I can't
[12:42] <StevenK> Hm, even I can't.
[12:43] <dholbach> I guess only james_w or cjwatson can close https://code.launchpad.net/~gal-fourier/ubuntu/natty/opencv/bug-756154/+merge/68171
[12:45] <james_w> dholbach, rejected
[12:45] <dholbach> thanks james_w!
[12:54] <smb> pitti, Just playing around with latest Oneiric and got a crash that pointed me to bug 827176. Funny thing is that I did not have language-selector installed (only language-selector-common and language-selector-gnome). Even with having run install ubuntu-desktop^ before...
[12:54] <pitti> dholbach: hm, you didn't push the udev upload into the branch, can you please do?
[12:55] <dholbach> :-( will do
[12:55] <pitti> thanks!
[13:04] <tkamppeter> OdyX, did you run into the ppds.dat mess, too?
[13:04] <OdyX> tkamppeter: no.
[13:04]  * smb wonders which package a bug about "the new iconify and de-fullsize buttons are the worst visual design I ever have barely seen" would be reported
[13:04] <OdyX> tkamppeter: I'm currently migrating foomatic-db to the cups triggers and to dh_pyppd. It's fun.
[13:05] <tkamppeter> OdyX, I see a lot of printer driver package uploads, are they all to make use of the centralized PPD update and the new Debian Helper for pyppd?
[13:05] <dobey> smb: whatever theme they're in i guess
[13:05] <OdyX> tkamppeter: yes, + new upstream release for foo2zjs
[13:06] <smb> Would be the default then.. whatever that is called in Oneiric...
[13:06] <tkamppeter> OdyX, the ppds.dat problem I only discovered with HPLIP when I migrated it to the centralized update (so it now only needs the pyppd change).
[13:11] <OdyX> tkamppeter: so far, foomatic-db-engine, foo2zjs, c2esp and epson-inkjet-printer-driver have been migrated (the latter to multiarch too)
[13:18] <pgraner> pitti, just hit https://bugs.launchpad.net/ubuntu/+source/apport/+bug/828010 which is marked fixed released and I'm fully updated
[13:18] <pgraner> pitti, not sure how you wanted in the report
[13:23] <dholbach> @pilot out
[13:26] <shadeslayer> hey, anyone around to correct a small problem on http://developer.ubuntu.com/packaging/html/packaging-from-scratch.html ?
[13:26] <nigelb> dpm: ^
[13:27] <Laney> there should probably be a footer showing how to file bugs
[13:27] <Laney> shadeslayer: please file a bug https://bugs.launchpad.net/ubuntu-packaging-guide
[13:27] <nigelb> oooh, that's our packaging guide!
[13:27] <Laney> there's another one?
[13:28] <nigelb> no, I think it just found its permanent home.
[13:28] <dpm> thanks nigelb for the heads up. dholbach takes care of that bit of developer.ubuntu.com ^
[13:28] <nigelb> instead of people.ubuntu.com/~dholbach
[13:28] <Laney> uh
[13:28] <dpm> yeah, that's correct
[13:28] <Laney> that page doesn't mention workflow for getting it into the distro really
[13:28] <dholbach> I put it on my TODO list to create a redirect
[13:29] <nigelb> shadeslayer: branch, fix, and propose a merge! https://code.launchpad.net/~ubuntu-packaging-guide-team/ubuntu-packaging-guide/trunk
[13:29] <Laney> or going through Debian, which dholbach wrote a wiki page about recently
[13:29] <nigelb> Laney: How long is this mono compliation going to take? (2-core machine)
[13:29] <Laney> hour or so
[13:29] <Laney> less if it fails :-)
[13:29] <nigelb> heh
[13:30] <dpm> Laney, there's a link at the bottom of the page that takes you to how to upload packages "See uploading for more information."
[13:30] <Laney> dpm: there is a bit of a specific workflow for new packages
[13:32] <dpm> Laney, ah, ok. I'm not involved in the guide, I was just pointing that bit out. dholbach should be able to tell you where to best discuss the structure and any missing content from the guide
[13:33]  * shadeslayer shall fix on his own
[13:36] <pitti> pgraner: what's the version in dpkg -l apport-gtk ?
[13:42] <hrw> cyphermox: can you take a look at http://paste.ubuntu.com/669242/ diff? It has all changes which were needed to build network-manager-applet without indicator support. also had to disable -Werror
[13:42] <hrw> cyphermox: changes are not usable for default ubuntu package anyway
[14:01] <ScottK> slangasek: Does http://paste.debian.net/126597/ look like it might be related to the multi-arched qt4-x11?
[14:01] <hallyn> If a package's x.install currently says "usr/lib/python2.6/dist-packages/", is changing that to "usr/lib/python*/dist-package/" ok?
[14:01] <ScottK> hallyn: Generally, yes.
[14:01] <dobey> morning ScottK
[14:01] <ScottK> Hello dobey.
[14:02] <hallyn> ScottK: thx
[14:02] <ScottK> I find I'm a bit unclear what the U-one package you've got a pending FFe for is supposed to accomplish.
[14:02] <dobey> hallyn: i also do *-packages, to deal with differences in python versions where site-packages might be used instead of dist-packages (if you care to support many versions from one debian/ dir)
[14:02] <dobey> ScottK: it installs ubuntu one.
[14:03] <ScottK> site-packages is only python < 2.5
[14:03] <ScottK> dobey: So why is it needed?
[14:04] <dobey> the reasons chipaca mentioned in his comment on the bug; it is a result of the discussion from https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-updates-for-network-clients at UDS
[14:04] <ScottK> pitti: ^^^ This is exactly what I think the TB needs to approve.  It's not aligned with the current policy.
[14:04] <ScottK> dobey: Thanks.
[14:05] <pitti> but I thought that installer would specifically not enable a PPA, but just install the Ubuntu packages instead?
[14:05] <pitti> ScottK: agreed
[14:05] <pitti> but I'm confused since the bug report says it would not do taht
[14:06] <dobey> what current policy?
[14:06] <hallyn> not sure i'm quite following, but i'll do *-packages just in case, thanks :)
[14:06] <pitti> just providing an aptdaemon shim to install u1 packages from ubuntu doesn't need TB approval, that's similar to our codec installer or what u1 already does right now (install desktopcouch when you want extra services, etc.)
[14:06] <pitti> dobey: SRU
[14:06] <ScottK> pitti: Agreed.
[14:06] <pitti> so there seem to be two different claims in that bug: (1) provide a spec implementation, which entails PPAs, etc. (2) merely provide an installer
[14:06] <pitti> dobey: ^ so which is it then?
[14:07] <ScottK> I don't think that's what this is about though (although you might get that as a side benefit).
[14:07] <ogra_> hmm, is anyone else seeing nm-applet leak memory ? i just killed it with 42MB reserved mem
[14:07] <dobey> pitti: it is now currently only an installer
[14:08] <ScottK> Of what?
[14:08] <dobey> ubuntu one
[14:08] <ScottK> From?
[14:08] <dobey> whatever archives the user has installed at the time of running the installer
[14:09] <dobey> s/installed/enabled/
[14:09] <ScottK> And the functionality to enable additional repositories?
[14:09] <dobey> isn't there
[14:09] <dobey> user has to apt-add-repository now
[14:09] <pitti> that seems fine to me
[14:10] <dobey> well the code is there, but it doesn't get run now. we simply update the cache and do the installe
[14:10] <ScottK> Not even a command line option?
[14:11] <pitti> (FWIW, I'd even accept a pure CLI -- add-apt-repository is about as easy to use as any CLI from that new package, after all, and even has apturl support)
[14:11] <dobey> ScottK: not currently there isn't no. there is a bug to add that though
[14:11] <dobey> ScottK: but may or may not do that for Oneiric
[14:11] <ScottK> pitti: Would you accept a scribus package with CLI option to add the scribus PPA?
[14:12] <ScottK> We have, in the past, not allowed packages to add PPAs (I think for good reason).
[14:12] <ScottK> I don't think we should change that.
[14:12] <pitti> ScottK: ah, we didn't? ok
[14:12] <ScottK> pitti: envy-ng was the first one I remember coming up.
[14:13] <dobey> fwiw, there is no specific documentation in the Ubuntu Policy Manual about PPAs, afaict
[14:15] <ScottK> It me it seems relatively obvious that if the user wants to reconfigure their system to allow third-party software it should be done via the package management system.
[14:15] <ScottK> Allowing applications to bootstrap themselves outside the Ubuntu archive just doesn't seem a good idea.
[14:17] <ogra_> software-center has a channel specification, we use it with the ti omap4 ppa for the
[14:17] <pitti> eek - new LP now auto-sets bugs to "confirmed" on any response?
[14:17] <pitti> bug 828751
[14:17] <ogra_> HW specific addon packages
[14:17] <dobey> well it doesn't matter. we're past that. ubuntuone-installer doesn't add a PPA
[14:17] <seb128> pitti, it should do it when somebody clients "it affects me as well"
[14:17]  * pitti sets it back to New
[14:17] <pitti> seb128: ah
[14:18] <dobey> pitti: if it was New, and it gets a dup or someone clicks "affects me too" it does i think
[14:18] <seb128> pitti, which seems to be the case there
[14:18] <seb128> pitti, it does make sense since "confirmed" should be "somebody else confirm it's a valid bug"
[14:19] <pitti> ok, so that just fails on exception requests then
[14:20] <seb128> pitti, what does "confirmed" means for those?
[14:20] <seb128> pitti, the process should perhaps be changed to use triaged or in progress?
[14:20] <pitti> "approved"
[14:20] <pitti> just like for sync requests, etc.
[14:20] <seb128> we should change to use "Triaged" I guess
[14:21] <pitti> yeah, perhaps; but so far "confirmed" seemed to grasp "approved" best
[14:21] <dobey> pitti: not to interfere with your annoyance with LP, but back to me :)
[14:21] <pitti> ScottK: do you have more questions to dobey about this?
[14:22] <ScottK> pitti: No.  As long as it is just an installer and doesn't have the CLI (or other) option for adding PPAs, I think it's a release team decision.  I'm fine with whatever you decide.
[14:22] <hrw> did someone got situation when linux see mouse (/dev/input/eventX created, evtest with it works) but x11 does not use this mouse?
[14:25] <mdeslaur> cyphermox: hello?
[14:26] <pitti> dobey: bug 817133 updated
[14:26] <nigelb> Laney: sucess
[14:26] <nigelb> Laney: err, success.
[14:26] <cyphermox> hrw: I don't get what you mean, you don't need todo that much work for it; just disable the patch that adds indicator support
[14:26] <cyphermox> mdeslaur: yo
[14:26] <mdeslaur> cyphermox: did you see my question earlier?
[14:26] <nigelb> Laney: Rather, I think it was a success, I don't see failure anyway, and I see lots of deb references
[14:26] <nigelb> tumbleweed: ^
[14:27] <cyphermox> hrw: but then I don't see what you mean about not usable for the default package. nm-applet is meant to have indicator support, it just needs to be fixed for the cases where indicators fallback
[14:27] <dobey> pitti: great, thanks. can you upload? :)
[14:27] <cyphermox> mdeslaur: yes, finishing up on evo 3.1.5, which I was going to upload within minutes
[14:28] <pitti> dobey: looking
[14:28] <mdeslaur> cyphermox: ah, cool...that's what I wanted to know. thanks.
[14:29] <hrw> cyphermox: sure, I could just disable indicator patch and do build. but I wanted to check will it build with this patch applied but functionality disabled
[14:30] <hrw> cyphermox: it did not so I hacked sources a bit to get them built. waste of time anyway
[14:30] <cyphermox> hrw: right, but disabling the patch will let it build just fine without indicator, so I'm not sure what you're trying to achieve
[14:32] <hrw> cyphermox: if/when indicator.patch will get merged upstream then build will fail for those without indicator. merge my changes into indicator.patch and both worlds will be happy with indicator.patch merged
[14:33] <cyphermox> not really
[14:33] <cyphermox> not using --enable-indicator should do the same (not sure of the syntax, but it's build-time configurable
[14:33] <pitti> dobey: uploaded
[14:34] <dobey> pitti: thanks again!
[14:34] <hrw> cyphermox: I did build without --enable-indicator and it failed when indicator.patch was applied
[14:34] <pitti> dobey: you're welcome
[14:34] <cyphermox> ok, then that's different, but the patch looks a little weird. that said, I haven't tried to apply it and build
[14:35] <hrw> cyphermox: I suxx when it comes to gtk apps code so thats why patch is hacky
[14:35] <cyphermox> heh, it comes with time, don't worry
[14:36] <slangasek> lool: right, sounds like transient package breakage; do you think this was widespread enough that we should upload libfontconfig1 with a preinst to fix the symlink?
[14:36] <cyphermox> I'm just pretty sure that wouldn't work for both "worlds"
[14:36] <hrw> cyphermox: I am avoiding gtk code for ~7 years now
[14:36] <slangasek> ScottK: yes, I think http://paste.debian.net/126597/ gets fixed with a no-change rebuild of akonadi
[14:36] <ScottK> slangasek: Thanks.  I'll have a go at that.
[14:37] <ScottK> slangasek: Also I just accepted qt4-x11 with qdbus.  Thanks for getting that fixed up.
[14:37] <hrw> cyphermox: anyway - nm-applet built without indicator support works great here. finally have icon and menu
[14:37] <Ursinha> jelmer_: hello! could you help me out with a couple of bugs? I'm doing some bug cleanup and bug 707563 might be a duplicate of bug 596064
[14:37] <slangasek> ScottK: sure
[14:37] <ScottK> slangasek: Any idea if anything else needs rebuilding (or how I can tell)?
[14:37] <slangasek> ScottK: no idea
[14:38] <jelmer_> Ursinha: Hey! Sure, I'll have a look.
[14:38] <cyphermox> hrw: cool. in any case, I'll fix the fallback so it works properly, but for now it appears to be broken. My guess is that some signalling between nm-applet and libappindicator/dbusmenu isn't quite working for that case
[14:38] <Ursinha> jelmer_: thanks. :) If that happens to be true, so I'm afraid we have a lot of recent samba bugs that are dupes of the older bug as well
[14:39] <hrw> cyphermox: ok - I can work as guinea pig for tests if needed
[14:39] <cyphermox> hrw: ok. I'll try to get something out today
[14:39] <hrw> cyphermox: hrw@canonical.com as I will end work in ~30 minues
[14:39] <Laney> nigelb: oh, that's sad. cheers anyway
[14:40] <cyphermox> sure sure
[14:45] <doko> ev, camerabin now built from neither bad nor good?
[14:45] <lool> slangasek: I wondered the same, there were only 3 people affected in the bug including me and 2 bug reports including mine, but I decided that it was easy enough to add a snippet and remove this post oneiric
[14:45] <slangasek> lool: well, go for it :)
[14:45] <lool> slangasek: Just uploaded a minute ago
[14:45] <slangasek> yay
[14:45] <ev> doko: it's built from good
[14:46] <ev> UGH
[14:51] <lool> slangasek: the only other ill effect I'm seeing so far is LP #828807, which seems to be an aptitude bug (albeit it might affect apt too?)
[14:51] <ev> doko: actually, my range was a bit premature, camerabin is in -good
[14:55] <hrw> pitti: can you check https://bugs.archlinux.org/task/25356 for udev? my BT mouse got ignored by X11 due to that
[15:00] <slangasek> lool: ah, I'm unfamiliar with this aptitude feature
[15:01] <hrw> pitti: bug 828814 at launchpad
[15:01] <pitti> hrw: could that be a dupe of bug 827489?
[15:01] <pitti> hrw: that got fixed in 173-0ubuntu2
[15:02] <lool> slangasek: basically helps picking up new binary packages as they appear; only packages which were never seen are listed; pressing "forget" empties the list
[15:02] <lool> acts a bit like a subscription to binary NEW  :-)
[15:03] <hrw> pitti: again you people are faster then me ;)
[15:03] <hrw> pitti: will check upgraded package
[15:03] <pitti> hrw: thanks
[15:11] <jelmer_> Ursinha, so, it seems like there are two related issues
[15:12] <jelmer_> Ursinha: the fact that testparm is being called before the various directories in /var/ are created, and the problems with the net-device line
[15:18] <tumbleweed> lool: aha!, you found the fontconfig symlink thing I ran into and got to the bottom of it, \o/
[15:20] <slangasek> lool: yep... guess someone needs to poke aptitude for this, I don't think apt has any equivalent
[15:31] <nigelb> Laney: wait, sad
[15:31] <nigelb> ?
[15:31] <Laney> we are trying to reproduce a failure
[15:31] <nigelb> haha
[15:31] <nigelb> oh
[15:32] <nigelb> man, that was depressing. I had a successful build and I get "thats sad!"
[15:32] <Laney> :P
[15:35] <directhex> sorry, can't reproduce on any of our hardware. someone mail me vernadsky since that consistently fails
[15:35] <hallyn> kees: hey, do you know of a way to make sbuild build in an existing session?
[15:36] <kees> hallyn: I haven't tried, but I generally just use "debuild -uc -us" in those situations
[15:36] <kees> hallyn: it's close, but not perfect
[15:38] <hallyn> i wanted to verify that package versions listed in dependencies will be ok
[15:38] <hallyn> debuild will do that though?  i'll do that, thx
[15:38] <pgraner> pitti, ii  apport-gtk     1.21.3-0ubuntu
[15:38] <kees> hallyn: oh, debuild won't do build-deps
[15:39] <kees> hallyn: it'll verify them, but not fetch them
[15:39] <pitti> pgraner: ah, of course it got cut off at the very point when it gets interesting
[15:39] <pitti> pgraner: can you please try "dpkg -l apport-gtk | cat"?
[15:39] <hallyn> kees: ok, verify is all i wanted.
[15:39] <hallyn> kees: thanks
[15:40] <pgraner> pitti, ii  apport-gtk                             1.21.3-0ubuntu4
[15:40] <dhana013> Hi trying building with vim package using cdbs
[15:40] <dhana013> I am trying with building with vim using cdbs.. I included these rules
[15:41] <dhana013> root ~/test/vim-7.3.035+hg~8fdc12103333 # cat debian/rules
[15:41] <dhana013> #!/usr/bin/make -f
[15:41] <dhana013> include /usr/share/cdbs/1/rules/debhelper.mk
[15:41] <dhana013> include /usr/share/cdbs/1/class/autotools.mk
[15:41] <dhana013> include /usr/share/cdbs/1/class/gnome.mk
[15:41] <dhana013> include /usr/share/cdbs/1/class/perlmodule.mk
[15:41] <dhana013> I got error like this please guide me
[15:41] <dhana013> dh_installinfo: cp README.txt.info Contents.info runtime/icons.info
[15:41] <dhana013> runtime/macros/README.txt.info runtime/macros/hanoi/poster.info
[15:41] <dhana013> runtime/macros/hanoi/click.me.info runtime/macros/urm/README.txt.info
[15:41] <dhana013> runtime/macros/maze.info runtime/macros/urm.info
[15:41] <dhana013> runtime/macros/life/click.me.info runtime/macros/hanoi.info
[15:41] <dhana013> runtime/macros/maze/poster.info runtime/macros/maze/README.txt.info
[15:41] <dhana013> runtime/macros/maze/maze_5.78.info runtime/tutor/README.txt.info
[15:41] <dhana013> runtime/tutor/tutor.info runtime/tools.info runtime/doc/help.txt.info
[15:41] <dhana013> runtime/doc/vim.man.info runtime/doc.info runtime/tutor.info
[15:41] <dhana013> runtime/icons/README.txt.info runtime/icons/Vim_32Colors.info
[15:41] <dhana013> runtime/icons/Vim_4ColorsLace.info runtime/icons/Vim_8ColorsLace.info
[15:41] <dhana013> runtime/icons/Vim_8Colors.info runtime/macros.info vimdir.info
[15:41] <dhana013> README_amibin.txt.info README_amisrc.txt.info README_ami.txt.info
[15:41] <dhana013> src.info runtime.info Vim.info Xxd.info debian/vim/usr/share/info
[15:41] <dhana013> returned exit code 1
[15:41] <dhana013> make: *** [binary-install/vim] Error 2
[15:41] <dhana013> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
[15:41] <dhana013> debuild: fatal error at line 1340:
[15:41] <dhana013> dpkg-buildpackage -rfakeroot -D -us -uc failed
[15:41] <dhana013> please guide me
[15:42] <hallyn> kees: I swear I used to be able to use '--chroot-setup-commands "dpkg -i xyz.deb"', but now it says i don't have privilege when i try that
[15:46] <ScottK> slangasek: You put kscope on the sync blacklist due to being kde3.  It's now a Qt4 application (but with the same package name).  Would you pelase remove it from the sync blacklist so we get it back next cycle?
[15:46] <slangasek> sure
[15:49] <slangasek> ScottK: done
[15:49] <ScottK> slangasek: Thanks.
[15:59] <kees> hallyn: yes, that used to work; the patch regressed. I was actually going to fix that today.
[15:59] <Ursinha> jelmer_: and is that detectable by the files attached to the bugs? or the comments?
[16:00] <hallyn> kees: awesome!
[16:05] <jelmer_> Ursinha, bug 596064 is the testparm issue, bug 750786 is the other issue
[16:07] <jelmer_> Ursinha, The tracebacks seem to suggest bug 596064 is a dupe of 707563; the user that was encountering the other issue filed bug 750786
[16:35] <kees> hallyn: okay, sbuild fix uploaded. thanks for the reminder. :)
[16:38] <hallyn> kees: awesome, thanks :)
[16:40] <SpamapS> oooo Chrome grew print preview
[16:41] <cjwatson> cyphermox,jelmer: any chance of an evolution-mapi update?  it fails to build and it's built against old EDS libraries ...
[16:41] <cyphermox> cjwatson: already on it :)
[16:41] <cjwatson> excellent, ta
[16:42] <cyphermox> jelmer had 3.1.4 ready; but we're uploading 3.1.5, so we'll get that in shortly
[16:42] <cjwatson> lots of evolution stuff on http://people.canonical.com/~ubuntu-archive/nbs.html
[16:42] <cjwatson> I know you only just changed soname
[16:49] <cyphermox> yeah, and already been working to clean that up
[16:49] <cyphermox> I'll get back to it once 3.1.5 is in
[16:51] <cjwatson> ev: I've NBS-removed gstreamer0.10-camerabin since it looks like you just moved that into the gstreamer0.10-plugins-good package directly; hope that's OK
[16:51] <ev> cjwatson: thanks!
[16:51] <cjwatson> (... ubiquity upload soon then? :-) )
[16:53] <ev> yes, I'll do that now
[16:53] <doko> \o/
[16:54] <infinity> Didn't that just move out of a plugins bundle package a few weeks ago? :)
[16:54] <ev> ...yes...
[16:54] <cjwatson> infinity: but -bad
[16:54] <infinity> Yeah.
[16:54] <cjwatson> no good for MIRage
[16:54] <ev> silly, really
[16:54] <infinity> Just curious about the middle step. :)
[16:55] <cjwatson> it was a mistake I think
[16:55] <infinity> I hope it enjoyed its brief freedom.
[16:55] <ev> well I did it
[16:55] <cjwatson> *shrug* rectified now
[16:55] <infinity> It's like moving out of your parents' place, only to move in with your girlfriends' parents a month later.
[16:55] <infinity> Poor thing.
[16:55] <ev> but I mean, I think it's silly that I have to move a portion of a source tree from one place to another because we have this restriction in place
[16:55] <slangasek> heh
[16:55] <ev> rather than just saying "these files go into main"
[16:56] <slangasek> it's the lesser evil
[16:56] <slangasek> because we don't do MIR review for binary packages, which would be a much greater burden
[16:57] <ScottK> doko: Can you retry packages from the rebuild?  I'd like to see if a bunch of KDE stuff builds now thanks to rebuilding akonadi.
[16:57] <slangasek> ev: I think you need a bumped versioned Breaks/Replaces on gstreamer0.10-plugins-bad from gstreamer0.10-plugins-good
[16:58] <doko> ScottK, sure, just make sure that it's already in the archive
[16:58] <slangasek> ev: since camerabin was in -bad until 0.10.22-2ubuntu2, and the current Breaks/Replaces doesn't cover the version that was in natty
[16:59] <slangasek> ev: er, no, it does cover that version... so it's only an issue for people who are running oneiric but upgrade infrequently
[17:00] <ScottK> doko: Will do.  Turns out it's not there yet.
[17:01] <seb128> ev, bug #828845 is yours
[17:02] <slangasek> heh, yes
[17:05] <kees> hggdh: hi! the ajaxterm patch looks good. do you need that uploaded, or do you have a sponsor for it already?
[17:07] <hggdh> kees: no sponsor; Daviey would look at it, but he is busy as hell
[17:07] <hggdh> kees: so, if I can impose on you...
[17:08] <hggdh> kees: a question there -- we will now have a delta, is this an issue?
[17:08] <kees> hggdh: it's not an issue, but it'd be nice to send the patch to Debian in the form of a bug report (see the "submittodebian" tool for more details)
[17:09] <hggdh> kees: roger, will do
[17:10] <ev> new ubiquity is up. I'll take care of the rest tomorrow
[17:12] <seb128> ev, saw the bug I pointed before?
[17:16] <SpamapS> hmm interesting situation
[17:17] <SpamapS> http://people.canonical.com/~ubuntu-archive/nbs.html confirms it.. libdbi0-dev .. which was built by libdbi, but is not just a virtual package provided by libdbi-dev .. seems to be blocking the use of libdbi-dev for compiling..
[17:18] <SpamapS> s/but is not/but is now/
[17:18] <SpamapS> slangasek: I guess I need to complete that AA training so I can handle these things myself. :)
[17:22] <slangasek> SpamapS: heh; libdbi0-dev nuked
[17:24] <kees> hggdh: I made a few changes (Last-Update was july instead of august, filled in my name as reviewer, and clarified the description)
[17:24] <kees> hggdh: if you're about to forward it to debian, I can wait to upload so that we can add the debian bug # to the ubuntu upload...
[17:25] <hggdh> kees: thank you; I expected the reviewer to be filled...
[17:25] <hggdh> kees yes, I am. Should I send the whole diff, or edit out the changes to control?
[17:25] <kees> hggdh: I would leave out the maintainer changes when forwarding
[17:25] <hggdh> kees: will do now
[17:26] <kees> hggdh: okay, cool. I'll upload it when you get the bug # back from the debian tracker. :)
[17:27] <cjwatson> SpamapS: yes, the NBS list does occasionally have incorrect cases in its dependency checking
[17:28] <mdeslaur> micahg: looks like it has the translations in it now, since it got demoted to universe
[17:28] <micahg> ah, didn't know it finally got demoted, ok, no issue then ,thanks
[17:28] <mdeslaur> micahg: is this a problem?
[17:29] <micahg> mdeslaur: no, it'll sort itself after the next translations update then
[17:29] <mdeslaur> micahg: why did you notice that? did you have an issue with something?
[17:29] <micahg> mdeslaur: a 4MB increase in install size for a wrapper fix seemed bad :)
[17:30] <mdeslaur> micahg: how did you notice that? :)
[17:30] <mdeslaur> micahg: you've got me curious now :)
[17:30] <micahg> mdeslaur: aptitude FTW!
[17:30] <seb128> doko, infinity, cjwatson: could somebody score up https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2719587
[17:30] <seb128> ?
[17:31] <seb128> it's the unity weekly update, I would like to get a ppa build for testing before uploading to the archive
[17:31] <cjwatson> seb128: done
[17:31] <seb128> cjwatson, thanks ;-)
[17:32] <mdeslaur> micahg: hehehe
[17:32] <doko> cjwatson > 10000
[17:32] <doko> (done)
[17:32] <cjwatson> 5000 said "1 minute"
[17:32] <cjwatson> but OK
[17:33] <seb128> hum
[17:33] <seb128> failed again :-(
[17:33] <seb128> https://launchpadlibrarian.net/77530994/buildlog_ubuntu-oneiric-i386.unity_4.8.2-0ubuntu1~build1_CHROOTWAIT.txt.gz
[17:34] <seb128> "sudo: no valid sudoers sources found, quitting
[17:34] <seb128> *** glibc detected *** sudo: double free or corruption (!prev): 0x0000000000629ff0 ***
[17:34] <seb128> [17:34] <seb128> /lib/libc.so.6[0x7f2598a970ea]"
[17:34] <seb128> I got 3 broken i386 builds in a row due to that
[17:34] <seb128> did we broke oneiric?
[17:34] <seb128> or is that a buildds issue?
[17:36] <doko> seb128, save the log and try again?
[17:36] <seb128> doko, the one you scored was a retyr
[17:36] <seb128> retry
[17:36] <seb128> it failed the same way 15 minutes ago
[17:36] <seb128> gobject-introspection from pitti in the same ppa failed the same way on i386
[17:37] <seb128> I retried it but it's not going to try before some hours
[17:37] <seb128> i.e that's 3 i386 builds that failed this way in a row
[17:38] <seb128> doko, https://launchpad.net/builders/shipova/+history
[17:39] <seb128> doko, could be the builder which is broken
[17:40] <seb128> it's doing that on all builds it tries
[17:41] <seb128> doko, I've retried the build if you could rescore it again
[17:41] <seb128> https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2719587
[17:42] <doko> seb128, done
[17:42] <seb128> doko, thanks
[17:43] <seb128> doko, I guess it's going to fail again, it picked the broken builder
[17:43] <seb128> which I guess it's because all others are busy
[17:44] <doko> seb128, shipova? I could disable this one
[17:44] <seb128> doko, yes, see https://launchpad.net/builders/shipova/+history
[17:44] <seb128> doko, that would be nice
[17:45] <seb128> doko, ok, https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2719587 to rescore once shipova is down
[17:45] <seb128> thanks a lot, I appreciate the help on that ;-)
[17:46] <hggdh> kees: debian bug 638332
[17:48] <doko> seb128, done
[17:54] <Daviey> kees: Are you taking hggdh's branch?
[17:54] <kees> Daviey: yup, almost hav eit uploaded now
[17:54] <Daviey> kees: That is great, thanks!
[17:54] <kees> np! :)
[17:54] <hggdh> kees: BTW, thank you very much, I really appreciate the help
[17:55] <kees> hggdh: sure thing!
[17:56] <seb128> doko, can you rescore https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2719587 as well?
[17:56] <ScottK> doko: Can you retry kdepimlibs in the rebuild test?  It should work and then if that does, I'll have some others to try ...
[18:04] <doko> seb128, ScottK: done
[18:04] <seb128> doko, thanks
[18:05] <tkamppeter> pitti, hi
[18:11] <tkamppeter> Any multiarch lib package expert around? I get always an error like this if an i386 version of a multiarch lib gets installed:
[18:11] <tkamppeter> Unpacking libcups2:i386 (from .../libcups2_1.5.0-3_i386.deb) ...
[18:11] <tkamppeter> dpkg: error processing /var/cache/apt/archives/libcups2_1.5.0-3_i386.deb (--unpack):
[18:11] <tkamppeter>  './usr/share/doc/libcups2/changelog.Debian.gz' is different from the same file on the system
[18:11] <tkamppeter> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
[18:11] <tkamppeter> And this is not a problem of CUPS, I had it with another package before.
[18:12] <infinity> I wonder if this is a product of our changelog mangling...  Though every binary should still have the same changelog.
[18:12] <infinity> In theory.
[18:13] <infinity> slangasek: ^-- You have better theories?
[18:15] <micahg> tkamppeter: if you built that locally and installed w/out pkgbinarymangler running, you would probably get that result
[18:16] <infinity> Oh, there's that, yes.
[18:16] <infinity> tkamppeter: Local builds?
[18:16] <micahg> ugh, that was unclear, if the local build didn't run pkgbinarymangler that would cause this
[18:16] <infinity> micahg: It was clear to me. ;)
[18:16] <slangasek> tkamppeter, infinity: two typical causes: 1) it's a library that you've done a local build of (perhaps because it was your upload and you tested it locally first), so your already-installed package doesn't match the one built in the archive due to things like changelog mangling and doc symlinking; 2) in some cases (such as the fontconfig issue mentioned in scrollback), a conversion between symlink and file may have gone wrong on your sys
[18:16] <slangasek> ... past, resulting in a mismatch
[18:16] <infinity> micahg: (But that was obvious from my questioning changelog mangling initially)
[18:17] <micahg> infinity: indeed
[18:18] <ScottK> doko: Thanks.
[18:20] <slangasek> oh man - a user's biggest complaint about multiarch is the spurious warning messages from the gtk postinst. https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/646954/comments/18
[18:20] <tkamppeter> slangasek, infinity, micahg, thanks, at least for the CUPS package this is the case. The current release of the CUPS package is done by me and on exactly this machine.
[18:21] <slangasek> tkamppeter: so to fix this, I would do 'sudo apt-get install --reinstall libcups2' to get the version from the archive installed
[18:21] <slangasek> (the same for any other affected packages)
[18:21] <slangasek> if it still fails for you on any package, that would merit a bug report
[18:23] <tkamppeter> slangasek, OK, done so.
[18:43] <SpamapS> slangasek: thanks!
[18:46] <doko> no evan ... libcheese1 still depends on gst-bad
[18:46] <doko> ev: ^^^
[19:01] <slangasek> doko: that's odd, why does the library depend on any of those?
[19:04] <slangasek> doko: cheese fix uploaded
[19:18] <pitti> ev: I thought ubiquity would drop the cheese b-dep, and just use gst directly?
[19:19] <pitti> ubiquity is in depwait now, as cheese is in universe
[19:19] <slangasek> from context, sounds like doko is reviewing an MIR for this already?
[19:19] <slangasek> and it's per se correct for libcheese1 to drop the dep on -bad now
[19:20] <pitti> that's right
[19:20] <pitti> but the current cheese is quite heavy
[19:20] <slangasek> well, but not libcheese1, which is only 60k
[19:20] <pitti> it pulls in clutter (which we don't want on the CDs, and not in general because it has rather poor hw support), and also stuff like mx
[19:20] <slangasek> although when speaking of cheese, 60k does sound like a lot
[19:20] <slangasek> oh, indeed
[19:21] <pitti> lol
[19:21] <pitti> right, I meant heavy in terms of MIR dependencies, not CD space this time
[19:21] <slangasek> right, that doesn't sound like a good thing
[19:31] <seb128> slangasek, pitti: ev said the other day he would use gst directly and not cheese
[19:32] <slangasek> ok
[19:32] <slangasek> seems that's not what's been uploaded so far; I guess we need ev to comment
[19:32] <pitti> slangasek: earlier, the cheese b-dep was just unused; perhaps he just forgot to drop it
[20:18] <ScottK> doko: Would you please try kdepim/kdepim-runtime for the rebuild?
[20:33] <kees> slangasek: I'm looking at the pam merge to get the syslog debug bug fix, but wanted to run some of the changes by you just to double-check: http://paste.ubuntu.com/669532/  (doesn't include the new ubuntu changelog entry for the merge yet)
[20:49] <hallyn> doko: hi, for bug 823711, did you have a debdiff or something?  (the lp tree isn't showing me where the fix was localized.  Want to make sure i preserve it in a debian merge)
[20:51] <hallyn> doko: ah, I see, there's a patch under debian/patches/.  thanks.
[20:54] <slangasek> kees: hmm, what are the version bumps for?
[20:56] <kees> slangasek: that was one of my questions. that's what in Debian's postinst/control. I figured moving it later wouldn't hurt
[20:56] <kees> slangasek: (in the interest of reducing the ubuntu to debian delta)
[20:58] <doko> ScottK, done
[20:58] <doko> hallyn, wait for the next gcc-4.6 upload, and it won't be needed anymore
[20:59] <doko> after a rebuild of libnl3
[21:01] <slangasek> kees: ah, I guess those are the versions that first introduced multiarch in each of Debian/Ubuntu.  The control changes should be ok, apt can sort it out for natty->oneiric upgrades and for lucid->p it makes no difference
[21:01] <slangasek> kees: I would shy away from bumping the versions in preinst/postinst just yet, because I still need to bugfix how we're doing the debconf prompts
[21:01] <kees> slangasek: that was my thinking, but I wanted to be sure there wasn't anything fishy going on :)
[21:01] <slangasek> (per UDS discussions)
[21:01] <kees> slangasek: ah, okay, I can switch those back.
[21:33] <hallyn> doko: when will that (gcc-4.6 upload) be?
[21:35] <doko> don't know yet, sorry
[21:38] <hallyn> doko: ok, thanks
[21:50] <doko> slangasek, ev: now gnome-video-effects is a b-d of cheese, and still keeps gst-bad in main, afaics
[21:50] <doko> anyway, afk now
[21:56] <ScottK> slangasek: https://bugs.launchpad.net/bugs/828999 looks like more multu-arch fallout.
[22:05] <slangasek> ScottK: hmm, in natty even it seems :/
[22:05] <ScottK> Yep.
[22:21] <slangasek> cjwatson: when you do have openssl0.9.8 available, I'd like to know so I can update ia32-libs to include it
[22:22]  * micahg thought openssl0.9.8 was going the way of the dodo in oneiric
 slangasek: partly because, even if we do manage to fix everything in the archive, libssl seems like the sort of thing people are not unlikely to have local binaries built against
[22:23] <micahg> ah
[22:23] <slangasek> FSVO "local binaries" that includes "acrobat reader", apparently :-)
[22:23]  * micahg hugs slangasek for updating ia32-libs
[22:25] <micahg> and behold, the source tarball fits on a CD again :P
[22:25] <slangasek> just barely ;)
[22:25] <micahg> you shaved almost 300MB off
[22:28] <micahg> and the binary itself was reduced by ~50%
[22:28] <slangasek> yeah, it was in need of some gardening
[23:41] <cjwatson> ogra_: please push your livecd-rootfs changes to lp:livecd-rootfs