[03:08]  * ScottK shakes fist at slangasek.
[03:08] <ScottK> Multi-arching qt4-x11 broke python-qt4 builds too.
[03:08] <StevenK> ScottK: So you'd prefer qt4-x11 wasn't multi-arch? :-)
[03:09] <ScottK> I'd prefer I'd understood what was going to happen better before I approved the FFe.
[03:09] <ScottK> StevenK: Are you in the mood for some removals?
[03:10] <StevenK> I'm *always* in the mood for some removals
[03:10] <micahg> hehe
[03:11] <ScottK> Excellent.
[03:11] <StevenK> ScottK: I'm about to hit up lunch, so toss me a list and I'll look soon
[03:11] <ScottK> StevenK: OK.
[03:13] <ScottK> Bug #82914 (pgdesigner), then you can NBS gambas2-gb-qt-kde and gambas2-gb-qt-kde-html, then Bug #794513  gets rid of kdewebdev-kde3 and kdelibs.
[03:13] <ScottK> StevenK: ^^^
[03:13] <ScottK> Oops.
[03:13] <ScottK> Bug #829149
[03:13] <ScottK> That one.
[03:14] <StevenK> ScottK: Okay, I've made a note
[03:14] <ScottK> Great.  Thanks.
[03:18] <ScottK> StevenK: Never mind. slangasek beat you to it.
[03:18] <ScottK> (sorry for the double request, I didn't realize he was around)
[03:18] <micahg> StevenK: I've got a list in the ~ubuntu-archive queue if you're removal happy :)
[03:19] <micahg> *feeling removal happy :)
[03:20] <ScottK> As he says, that's his usual state.
[03:20] <ScottK> slangasek: I filed Bug #829165 for your reading enjoyment (and hopefully you fix it).
[03:20] <micahg> and it's Friday for him, the perfect time :)
[03:44] <slangasek> ScottK: heh; which would you like first, wxwidgets or python-qt4? :)
[03:44] <ScottK> slangasek: python-qt4.
[03:44] <slangasek> ok, queued
[03:45] <ScottK> That's a package I actually care about as opposed to a package I happen to receive bugmail for ...
[03:45]  * slangasek chuckles
[03:45] <ScottK> StevenK: There's also Bug #829175 if you still want a removal.
[03:46] <micahg> slangasek: you around for another 10 minutes?
[03:46] <slangasek> micahg: actually no... but StevenK is?
[03:46] <micahg> slangasek: ok, no problem
[03:47] <slangasek> ScottK: hmm, this is after sip4 is fixed or not?
[03:47] <ScottK> slangasek: Not.  I didn't get a chance to look at sip yet.
[03:47] <slangasek> ScottK: because python-qt4 is the package that led me to the sip4 regression... unrelated to multiarch ;)
[03:48] <ScottK> Hmmm.
[03:48] <ScottK> Except that particular build failure is due to a multiarch path.
[03:49] <ScottK> I broke qscintilla2 in Debian and it got to Testing to that got pushed on the stack ahead of sip4.
[03:49] <ScottK> to that/so that
[03:49] <slangasek> ScottK: yeah, I dug into it thinking it might be multiarch, but it's definitely sip4
[03:49] <ScottK> Crap.  OK.
[03:50] <slangasek> built fine with the previous upstream version
[03:50] <ScottK> Glad I didn't upload that sip4 to Debian yet then.
[03:50] <ScottK> Grumble.  Please assign that one to me then.
[04:03] <micahg> StevenK: would you happen to be back from lunch?
[04:04] <StevenK> micahg: Mmmm?
[04:04] <micahg> StevenK: can I get you to publish a security update for me from a PPA?
[04:04] <StevenK> micahg: Which PPA?
[04:04] <micahg> I got 3 out of 4 sources to work, but the last one has too many binaries
[04:05] <micahg> StevenK: ubuntu-mozilla-security (public)
[04:06] <StevenK> micahg: Firefox 6, I guess?
[04:06] <micahg> StevenK: I need firefox 3.6.20+build1+nobinonly-0ubuntu0.10.04.1 to lucid-security
[04:06] <micahg> StevenK: nah, slangasek too care of that for me on Tuesday
[04:06] <micahg> *took
[04:10] <StevenK> micahg: Done.
[04:10] <micahg> StevenK: just that one, right?
[04:10] <StevenK> micahg: Yes, just that one.
[04:10] <micahg> StevenK: thanks!
[04:18] <pitti> Good morning
[04:19] <StevenK> ScottK: If you're still around, pgdesigner, gambas2-gb-qt-kde{,-html} and kubrick purged as requested.
[04:20] <StevenK> ScottK: slangasek beat me to removing kdelibs, and I can't find ksudoko at all.
[04:26] <infinity> StevenK: Can't "find" it?
[04:26] <infinity>    ksudoku | 4:4.6.0-0ubuntu2 |         natty | armel
[04:26] <infinity>    ksudoku | 4:4.6.0-0ubuntu2 |       oneiric | armel
[04:26] <infinity>    ksudoku | 4:4.6.2-0ubuntu2 |         natty | amd64, i386, powerpc
[04:26] <infinity>    ksudoku | 4:4.7.0-0ubuntu2 |       oneiric | amd64, i386, powerpc
[04:26] <StevenK> Ah, ScottK can't spell
[04:26] <infinity> And you don't autocorrect well, apparently. ;)
[04:27] <StevenK> I don't play sudoku, so meh :-P
[04:27] <micahg> that typo actually makes for a rather comical command :)
[04:27] <infinity> And you've somehow missed millions of people referring to it for the last decade? :)
[04:28] <infinity> micahg: I assume it's a KDE command for invoking toolchain builds?
[04:28] <StevenK> infinity: Not missed; ignored.
[04:28] <micahg> infinity: something to that effect ;)
[04:42] <pitti> slangasek: it must have stung your heart to touch ia32-libs again
[04:43] <infinity> pitti: ia32-libs has taken a piece of every every soul that's touched it over the years.
[04:46] <pitti> slangasek: oh, BTW: flash working like a charm here now
[05:09] <slangasek> pitti: nah, I got to take an axe to ia32-libs, that was fun ;)
[05:09] <slangasek> my only regret is that I couldn't cut more out
[05:13] <RAOF> There seem to be some dependency issues remaining; I didn't get libnss3:i386 or libcurl3:i386 installed automatically.  Once they _were_ installed, though, hurray!
[05:15] <slangasek> hmm, how did you install?
[05:16] <slangasek> libnss3 and libcurl3 are definitely in the dep list, so that's pretty odd
[05:19] <kees> ia32-libs. the reverse horcrux.
[05:21] <pitti> hah
[05:21] <StevenK> kees: It just won't die?
[05:22] <RAOF> slangasek: I just update-managered.
[05:22] <RAOF> slangasek: I didn't do anything fancy to install.
[05:22] <slangasek> RAOF: but then, wouldn't you still have had flashplugin-installer:amd64 installed?  I haven't nuked that yet...
[05:23] <kees> StevenK: well, just going off what infinity said. if it steals a little of everyone's soul. maybe I should say 'super horcrux' instead.
[05:23] <StevenK> Haha
[05:23] <RAOF> slangasek: Yes, indeed I have got flashplugin-installer:amd64 installed.
[05:24] <RAOF> slangasek: And it wants libnss3, which no longer appears to be in ia32-libs?
[05:24] <slangasek> RAOF: right - switching to flashplugin-installer:i386 should have pulled in the libs for you (and allow ia32-libs to be removed)
[05:24] <slangasek> yes, it's not in ia32-libs anymore because flashplugin-installer:amd64 is on its way out
[05:24] <RAOF> Ah, ok.  It's just currently broken :)
[05:25] <RAOF> Transitionally broken.
[05:25] <slangasek> yep - I'll have it gone this week
[05:26] <StevenK> slangasek: So ia32-libs will exist in oneiric release, a shadow of its former self, or utterly purged?
[05:26] <micahg> slangasek: can packages depend on other arch versions of themselves?
[05:26] <slangasek> StevenK: will still exist.  if you want to expedite its irrelevance for p, please provide multiarch patches for libxml2 and unixodbc in Debian :)
[05:28] <slangasek> micahg: nope.  So maybe flashplugin-installer would want to become a transitional package?
[05:28] <slangasek> there are a couple ways it could work, I mean to play to see which gives the best behavior
[05:29] <slangasek> StevenK: also, libao
[05:29] <micahg> slangasek: well, if you want to play with it, you could use the flashplugin-nonfree transitional package to depend on the i386 installer and have the flashplugin-installer:amd64 depend on it
[05:30] <slangasek> micahg: by making flashplugin-nonfree an i386-only package? heh, twisted but it would work
[05:32] <micahg> slangasek: well, you still need the amd64 package to depend on nspluginwrapper, still not sure how the dependency chain would work
[05:32] <slangasek> that's assuming we don't just conclude nspluginwrapper should be pulled in on i386 too
[05:33] <micahg> ah, right, you suggested that before and it sounded like a good idea
[05:34] <slangasek> but yes, flashplugin-installer:amd64 Multi-Arch: same, depends: flashplugin-nonfree+nspluginwrapper; flashplugin-nonfree:i386 Multi-Arch: foreign Depends: flashplugin-installer; flashplugin-installer:i386 Multi-Arch: same would do the job
[05:34] <slangasek> and make people go cross-eyed ;)
[05:35] <micahg> slangasek: I thought you said you can't have the same package installed on 2 archs?
[05:35] <micahg> s/on/from
[05:35] <slangasek> you can if it's marked Multi-Arch: same
[05:35] <micahg> ah, perfect then, that's what I was thinking :)
[05:39] <slangasek> oh dear
[05:39] <slangasek> Suggests: xfs (>= 1:1.0.1-5)
[05:49] <micahg> slangasek: it's just a suggests, maybe drop it for now if there's no time...
[05:49] <slangasek> micahg: the "oh dear" was that it suggests it at all, given that nothing uses xfs anymore :)
[05:50] <micahg> ah
[05:52] <mneptok> uhhhh .... XFS is one of the very popular choices among DBAs for data partitions
[05:52] <slangasek> mneptok: apt-cache show xfs ;)
[05:52] <mneptok> slangasek: oh, *package* XFS
[05:53] <mneptok> slangasek: why are you not at LinuxCon? it's just up the road ...
[05:53] <slangasek> mneptok: too much travel this summer already
[05:53]  * mneptok went to dinner with Canonicalians on Monday. 'twas fun.
[05:54] <slangasek> all travel and no work makes ia32-libs a something-something
[05:54] <StevenK> "bloated piece of crap"
[05:55] <mneptok> "still a scary solution?"
[05:58] <slangasek> micahg: works as expected with dpkg; I'll check a bit later what happens with update-manager, before uploading
[05:58] <micahg> slangasek: very cool, thanks
[06:00] <slangasek> micahg: actually, just pushed to my multiarch ppa, so you're welcome to test too
[06:01] <micahg> slangasek: maybe after I get this USN out :)
[06:05] <doko_> pitti: according to the test rebuild, qdox requires jmock, which got demoted
[06:06] <pitti> doko_: ah, qdox wants to go to universe as well, doing
[06:06] <pitti> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[06:06] <pitti> I'll clean that up a bit
[06:06] <pitti> ant-contrib, antlr3, etc.
[06:06] <pitti> seems all obsolete
[06:07] <doko_> ok, thanks
[06:09] <pitti> oh, portmap wants to go to universe, too?
[06:10] <pitti> ok, most stuff in "source main->universe" done, except for the ones which should be checked again
[06:10] <doko_> pitti: hmm, there were some things there which I promoted ... so
[06:12] <doko_> at least protobuf-c and x264
[06:12] <pitti> ah, I can put them back then
[06:13] <pitti> but I guess at some point an AA cleanup will demote them again until they get an rdepends
[06:13] <doko_> icc-profiles-free
[06:13] <doko_> tkamppeter__, ^^^
[06:13] <pitti> I kept that one
[06:13] <pitti> also icc
[06:14] <doko_> and not sure if we should keep maven-ant-helper for now, there is a spec to go to maven3
[06:14] <doko_> jamespage, ^^^
[06:14] <pitti> we can promote it back when needed
[06:15] <pitti> it was in main before, so that doesn't need any process
[06:17] <pitti> once ubiquity drops its cheese b-dep, c-m should look a lot more useful again
[06:21] <doko_> micahg, isn't there a reason that ssmtp has a `fakesync' in the version?
[06:21] <micahg> doko_: I checked and apparently not...
[06:22] <micahg> it was originally due to .bz2 issues, I think those have been fixed, but if not, I"ll upload manually
[06:22] <tkamppeter__> pitti, icc-profiles needs perhaps a direct seed in ubuntu-desktop.
[06:23] <doko_> err, that one is in multiverse
[06:23] <jbicha> can gjs get pushed through the NEW queue?
[06:24] <micahg> doko_: in theory, gpac could be dropped instead of MIRd depending on what siretart wanted to do with it
[06:25] <doko_> micahg, well, let him sort it out
[06:26] <micahg> doko_: right, that's why I filed the bug and subscribed him :), I guess I should've been clearer in the descrption there
[06:27] <siretart> oh right, x264 drags gpac
[06:27] <siretart> well, we'll loose quite important functionality with that
[06:31] <siretart> I'll have to look at why gpac is in multiverse in the first place.
[06:31] <micahg> siretart: it's in universe I thought
[06:31] <siretart> ah, I misread the backlog
[06:32] <siretart> hm. we have a package for debian more or less ready, I wonder why we haven't uploaded it yet: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/gpac.git
[06:33] <micahg> siretart: what does it use xulrunner for?
[06:33] <siretart> tbh: no idea
[06:35] <micahg> siretart: ah, it seems to just need mozjs
[06:41] <doko_> ScottK, please add the ftbfs tag to new build failure reports
[06:51] <doko_> ScottK, will you do something with your teeworlds backport? still wants a newer bamf, and shows up on the buildds every hour or so
[06:52] <pitti> tkamppeter: icc-profiles sounds like something that should be a dependency of something
[06:53] <tkamppeter> pitti, then I suggest that colord or the color management part of g-c-c should depend on icc-profiles.
[06:53] <tkamppeter> pitti, can you have a look at bug 829205? It is really annoying for developers.\
[06:53] <pitti> tkamppeter: hm, icc-profiles is in multiverse, so actually we can't seed or depend on it
[06:54] <tkamppeter> pitti, s/icc-profiles/icc-profiles-free/
[06:54] <pitti> tkamppeter: I'm afraid that's a little outside of what I have time to do..
[06:55] <pitti> tkamppeter: ah, right; i-p-free could be a recommends: of colord?
[06:55] <pitti> or whichever package is actually using it
[06:55] <pitti> we only seed top-level applications
[06:55] <tkamppeter> pitti, yes that would be OK,.
[06:55] <tkamppeter> RAOF, hi
[06:55] <pitti> I'm off for an hour or so, have an appointment
[06:56] <tkamppeter> pitti, which package for bug 829205?
[06:56] <RAOF> tkamppeter: Hi.
[06:56] <tkamppeter> RAOF, can you add a Recommends: icc-profiles-free to colord?
[06:56] <pitti> tkamppeter: hm, dpkg probably
[06:56] <tkamppeter> pitti, thanks.
[06:56] <RAOF> tkamppeter, pitti: Way ahead of you.  Let me hunt down my bug for that :)
[06:56] <RAOF> tkamppeter: Certainly.
[06:57] <RAOF> tkamppeter: I'll finish looking into the run-as-system-user patch and such, too.
[06:58] <RAOF> tkamppeter: Oooh, actually, that's not the bug I'm thinking of; it's subtly different.\
[06:58] <RAOF> But the solution is to build i386 packages, too.
[06:58] <RAOF> bug #827950 is the one I was thinking of (which you'll hit if you *do* build i386 and amd64 packges)
[06:59] <tkamppeter> RAOF, so installation of an amd46 build environment (build-essential) should pull the i386 build environment and then every package should be actually built twice?
[07:00] <RAOF> tkamppeter: Well, no.  But you'll need an i386 build chroot; either pbuilder or sbuild.  Perhaps they should have their defaults changed to automatically build both i386 and amd64, though.
[07:01] <doko_> Subscribe somebody else ... ev ... Please enter at least three characters ... this is INSANE!
[07:02] <tkamppeter> RAOF, or does this mean that I have to develop and test in an i386 environment?
[07:02] <tkamppeter> slangasek, hi
[07:03] <RAOF> tkamppeter: It means that, if the packages you are touching are multiarched, you will need to build both amd64 and i386 packages.  If you have the i386 package installed.
[07:03] <micahg> doko_: that doesn't look like it's been filed yet
[07:03] <RAOF> tkamppeter: So, either don't have the i386 package installed, or build both amd64 and i386 packages.
[07:04] <doko_> micahg, what?
[07:04] <tkamppeter> RAOF, can I remove the i386 stack from my amd64 system? And if so, how to proceed?
[07:04] <RAOF> tkamppeter: apt-get remove $PACKAGE:i386
[07:04] <micahg> doko_: against launchpad
[07:05] <RAOF> tkamppeter: Unless you've got something critical (currently, the only possible candidate is flash) which depends on the i386 package, that'll work just fine.
[07:05] <tkamppeter> RAOF, and this for 100s of libs one-byone?
[07:06] <tkamppeter> RAOF, how do you do your package development and testing?
[07:07] <RAOF> tkamppeter: The only multiarch package I touch is mesa and its dependencies.  I just build both i386 and amd64 packages and install them side-by-side.
[07:07] <RAOF> tkamppeter: If you care about libcups2, either remove libcups2:i386 or build an i386 libcups2 binary.
[07:08] <RAOF> (Obviously, as well as your amd64 binary)
[07:08] <tkamppeter> RAOF, this means you have to do all test builds in a chroot, like pbuilder and always sttart the two builds in parallel and wait them to finish ...
[07:08] <RAOF> tkamppeter: That's correct, although I do test builds (that I might possibly want to _install_ ) in a chroot anyway.
[07:09] <RAOF> tkamppeter: Or, you can remove libcups2:i386; there's probably nothing interesting depending on it.
[07:09] <dholbach> good morning
[07:11] <tkamppeter> RAOF, correcting this by removing packages removes acroread and flash.
[07:13] <RAOF> tkamppeter: Then you'll need to build i386 packages as well as amd64 packages.
[07:13] <RAOF> tkamppeter: I agree that's a bit awkward.
[07:32] <jamespage> pitti, doko: I think maven-ant-helper could be demoted for the time being - but please can antlr3 remain in main - see bug 814819 and bug 828816
[07:48] <slangasek> tkamppeter: hey there - has RAOF answered your question already?
[07:49] <doko> jamespage, can you seed it, or else pitti will demote it again ;p
[07:49] <doko> can't approve FFE's
[07:50] <jamespage> doko: working on those bugs today
[08:07] <pitti> jamespage: do we really need to seed it? seems like the kind of package that really ought to be a build dep, not a top-level app
[08:07] <pitti> jamespage: we can re-promote it once something  pulls it in
[08:07] <jamespage> pitti: jython will pull it back in once its upgraded so no it does not need seeding
[08:08] <pitti> ah, good
[08:25] <ev> doko_: has my username uncovered a bug in LP?
[08:27] <ev> seb128: I did, tis what I meant by the other stuff I'd take care of in the morning.
[08:27] <pitti> it's too short :)
[08:27] <pitti> ev: good morning
[08:27] <ev> good morning, pitti!
[08:27] <seb128> ev: hey, ok
[08:27] <ev> on it now
[08:27] <seb128> thanks
[08:27] <seb128> ev: well done on landing the ubiquity gtk3 version btw!
[08:28] <ev> thanks, that was quite the battle
[08:28] <ev> there's still a massive bug in the css handler
[08:28] <ev> keeps segfaulting randomly
[08:28] <ev> hope to get to the bottom of that today or monday
[08:28] <pitti> ev: yeah, congrats! I'll try it with the new pygobject on today's live CD (assuming that it builds), and fix up remaining stuff if needed; but by code inspection it shoudn't cause trouble with the new version
[08:29] <pitti> that might actually help, pygobject 2.90 turns a lot of these previous segfaults into proper exceptions
[08:29] <ev> yay
[08:29] <ev> pitti: that's grand news
[08:29] <ev> do you know offhand if they fixed the exceptions being raised in a different context issue?
[08:30] <ev> I checked the bug yesterday and it wasn't closed, but perhaps it was fixed with some other change
[08:30] <pitti> I don't know about that, I'm afraid
[08:30] <ev> no worries, I'll have a look
[08:31] <pitti> ev: if you want to test with the new version, it's in https://launchpad.net/~ubuntu-desktop/+archive/ppa
[08:32] <pitti> ev: but beware, there are some caveats (bug 828751)
[08:33] <doko> ev: I had to promote the timezone package, MIR was missing :-/
[08:34] <pitti> ev: I made a task for myself in bug 829186 to check ubiquity with the new pygi, FYI
[08:34] <doko> ev: now I know why you don't get subscribed to any bug reports ;)
[08:42] <Laney> hallyn: which version of lxc do you want backported? We have to support the upgrade paths so the backport will need to go to the intervening releases too.
[08:44] <Laney> hallyn: So, what we need to approve the backport is you to state that it builds, installs and runs without further changes on those releases
[08:52] <doko> ev: is cheese still required in main?
[08:52] <ev> doko: nope!
[08:56] <doko> ev: so I can demote it from supported-desktop-extra?
[08:56] <ev> doko: please do
[08:58] <slangasek> \o/
[08:58] <slangasek> ev: nice work, glad that's finally landed :)
[08:58] <ev> me too
[08:58] <ev> and shouldn't you be sleeping?
[08:59] <slangasek> that's debatable
[08:59] <ev> :)
[09:01] <doko> unseeded
[09:05] <slangasek> ev: I had a session scheduled with my GSoC student actually; people in Ireland apparently keep nearly as funny hours as in London :)
[09:07] <ev> heh, nice
[09:10] <Daviey> doko: Ready to be super happy? https://launchpad.net/ubuntu/+source/psyco/1.6-2ubuntu1 <-- a Recommends of ajaxterm.
[09:10] <Daviey> going to bump it down to suggests, due to being locked into python2.6
[09:27] <cjwatson> ogra_: around?  if you could please push your livecd-rootfs changes to lp:livecd-rootfs, that'd be great - I want to work on livecd-rootfs a bit today
[09:34] <ogra_> cjwatson, hmm, i thought i had
[09:34]  * ogra_ checks
[09:35] <ogra_> hmm, the branch is up to date
[09:35]  * ogra_ wonders whats wrong here 
[09:38] <cjwatson> what does 'bzr info' say?
[09:38] <cjwatson> lp:livecd-rootfs here only has 2.26
[09:38] <cjwatson> the archive has 2.27
[09:39] <ogra_> yeah, got it ... one sec
[09:40] <ogra_> there you go, sorry the branch was on a different machine
[09:47] <cjwatson> ogra_: ah, right - thanks
[09:47] <ogra_> (checking terminal prompts helps sometimes :) )
[09:53] <doko> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[09:53] <doko> Daviey: there seem to be some nova related MIRs missing
[09:53] <pitti> much better
[09:53] <doko> Sweetshark, ^^^ MIR's for translate-toolkit dependencies missing
[09:54] <pitti> cjwatson: FYI, current CD buidl failure due to python-gmenu missing is being handled, just needs a s-c upload now
[09:55] <Daviey> doko: the -carrot induced ones i'm holding out on, as there is work to get rid of carrot.
[09:55] <doko> ScottK, ^^^ MIR for kdesvn missing?
[09:55] <cjwatson> pitti: yeah, had already checked software-center bzr for that :)
[09:55] <Daviey> doko: socat i raised an intial one, and asked zul to finish
[09:55] <pitti> cjwatson: ah, way ahead of me :)
[09:56] <Daviey> doko: and -psyco, see above.  I have someone sorting that out right now.
[09:59] <Daviey> doko: The recommended demotion of powernap, i am investigating if we actually still have a reason to keep it in main.
[09:59]  * Daviey notes that components-mismatch would be more useful if it linked to [MIR] bugs.
[10:00] <doko> Daviey, no dependency
[10:00] <Daviey> doko: uh?
[10:00] <doko> Daviey, it appears in demotions, because it's not referenced in main
[10:00] <doko> Daviey, I suppose cjwatson would accept a patch ;)
[10:00] <Daviey> doko: Yes, i'm trying to find out if we need to make it a dep or seed it seperately, or let it fall through.
[10:01] <Daviey> cjwatson: Where is the code which generates components-mismatch, it's not part of germinate iirc?
[10:02] <cjwatson> Daviey: it's in ~lp_archive/dak/ on cocoplum, don't remember whether it's public
[10:03] <cjwatson> I'm not sure how it would go about knowing where the MIR bugs were though ...
[10:03] <Daviey> cjwatson: bugs with prefix title [MIR] or ubuntu-mir subscribed ?
[10:05] <pitti> Daviey: I think all open bugs against the source package with ubuntu-mir subscribed is a very good approximation; there are seldomly more than one of those
[10:05] <pitti> and if so, listing both of them wouldn't hurt
[10:09] <Daviey> I'll take a sniff at doing that.
[10:10] <soren> It could even just link to https://bugs.launchpad.net/ubuntu/+source/<package name>/+bugs?field.subscriber=ubuntu-mir
[10:10] <Daviey> pitti: The problem is that some ~ubuntu-mir's work flow seems to involve un-subscribing if the MIR isn't ready, which would hide the inprogress report.
[10:10] <pitti> Daviey: oh, is it? back then we just set them to incomplete
[10:10] <Daviey> Laney: is that your workflow?
[10:11] <Laney> I'm not on the MIR team
[10:11] <soren> It's a long link, but you won't have to actually talk to launchpad to generate the list.
[10:11] <Daviey> hmm, sorry - i'm getting confused between ubuntu-mir and ubuntu-release
[10:11] <Laney> but unsubscribing sounds weird
[10:11] <Daviey> soren: That is easier to implement, but doesn't give a quick reference if the url links to an empty set.
[10:12] <soren> Daviey: Sure.
[10:12] <soren> Daviey: ...which is roughly as useful/useless as a missing reference (which is what you'd get if you tried to find this info ahead of time with launchpadlib or whatnot), isn't it?
[10:13] <Sweetshark> doko: I know, is on my list
[11:39] <apw> cjwatson, i have noticed that the new live-build environment is not inluding the overlayfs.ko onto the casper initramfs.  I've tested adding that .ko is enought to successfully enable its use.  I am wondering what the process is for fixing live-build given its odd nature
[11:41] <cjwatson> apw: I'd be surprised if it had anything to do with live-build
[11:41] <cjwatson> surely it's up to the casper package to include what it wants
[11:42] <cjwatson> lp:ubuntu/casper hooks/casper, add another manual_add_modules line somewhere there
[11:42] <cjwatson> it already has them for unionfs/aufs/blah
[11:43]  * apw checks, i thought there was a list in live-build too, but maybe i am mistaken which its using
[11:43] <cjwatson> shouldn't be
[11:43] <cjwatson> it's a few layers removed
[11:44] <apw> cjwatson, cool then i must be mistaken, and i've lost the tmp dir which had my work... grrr
[11:44] <cjwatson> well, OK, there's LB_UNION_FILESYSTEM in there, but all that does is pass a kernel parameter
[11:44] <cjwatson> and that isn't used in our builds
[11:51] <apw> cjwatson, ok cool, as simple as this it appears: lp:~apw/ubuntu/casper/oneiric/overlayfs-module
[12:04] <cjwatson> apw: LGTM, thanks - merged and uploaded
[12:05] <apw> cjwatson, thanks
[12:09] <OdyX> tkamppeter: thanks for the continuous fixing of the ppd-updating patch. :-) Now I don't think your fixes on foomatic-db-engine were really necessary (but will fix in the next updates).
[12:11] <njpatel> nspluginwrapper: no appropriate viewer found for /usr/lib/flashplugin-installer/libflashplayer.so
[12:11] <njpatel> dpkg: error processing flashplugin-installer (--configure):
[12:11] <njpatel>  subprocess installed post-installation script returned error exit status 1
[12:11] <njpatel> is there anyway around that for amd64?
[12:13] <ScottK> doko: AFAIK there's no intent to put kdesvn in Main.  I'll have to see what's up this time (this isn't the first time).
[12:14] <ScottK> doko: re teeworlds and bamf it's an LP bug.
[12:14] <ScottK> StevenK: Thanks.
[12:17] <debfx> ScottK: kdesvn appearing in component-mismatch is caused by the kdesdk ftbfs on powerpc
[12:17] <ScottK> Ah.
[12:17] <ScottK> debfx: Thanks.
[12:18] <apw> are we aware that PPA builds (at least) are dropping to CHROOTWAIT apparently due to a glibc detected memory corruption in sudo
[12:18] <ScottK> unfortunately I've no access to hardware to work on that one.
[12:18] <debfx> asac: could you please have a look at my patch for bug #750554?
[12:22] <cjwatson> apw: I asked #is about that just recently
[12:22] <cjwatson> apw: have you seen any not on shipova?
[12:41] <doko> seb128, is ubuntu-desktop writable for me?
[12:41] <seb128> doko, yes
[12:42] <seb128> it has subteams set to allow anyone who can upload to be able to commit as well
[13:28] <kelemengabor> pitti: hi, do you have a few minutes to copy over the Natty langpack updates from -proposed to -updates: https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA
[13:29] <pitti> kelemengabor: queueing; I'm sure I can get to it today, but probably only in two hours or so
[13:30] <kelemengabor> okay, thanks!
[13:30] <pitti> kelemengabor: thanks to you for organizing the testing!
[13:31] <tkamppeter> pitti, seb128, I have done a fix on Poppler, I bzr-branched bzr: ERROR: No push location known or specified.
[13:31] <tkamppeter> till@till:~/ubuntu/poppler/bzr/ubuntu$ less .bzr/branch
[13:31] <tkamppeter> branch/        branch-format  branch-lock/
[13:31] <tkamppeter> till@till:~/ubuntu/poppler/bzr/ubuntu$ less .bzr/branch/
[13:31] <tkamppeter> branch.conf    format         last-revision  lock/          tags
[13:31] <tkamppeter> till@till:~/ubuntu/poppler/bzr/ubuntu$ less .bzr/branch/branch.conf
[13:31] <tkamppeter> till@till:~/ubuntu/poppler/bzr/ubuntu$ bzr push --remember http://bazaar.launchpad.net/~ubuntu-desktop/poppler/ubuntu/ and want to push my changes. To which URL do I have to push?
[13:31] <StevenK> tkamppeter: You can't push to http URLs
[13:32] <seb128> tkamppeter, lp:~ubuntu-desktop/poppler/ubuntu
[13:32] <tkamppeter> StevenK, I getbzr push --remember http://bazaar.launchpad.net/~ubuntu-desktop/poppler/ubuntu/
[13:32] <tkamppeter> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~ubuntu-desktop/poppler/ubuntu/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[13:32] <StevenK> tkamppeter: Yes, because you can't push to http URLs
[13:32] <seb128> tkamppeter, use lp:~ubuntu-desktop/poppler/ubuntu
[13:33] <tkamppeter> seb128, thanks, but I get then:
[13:33] <tkamppeter> bzr: ERROR: Cannot lock LockDir(lp-89119376:///~ubuntu-desktop/poppler/ubuntu/.bzr/branchlock): Transport operation not possible: readonly transport
[13:33] <StevenK> You need to login
[13:33] <StevenK> Run bzr lp-login
[13:33] <pitti> seb128: oh, the package is missing a Vcs-Bzr: then
[13:34] <seb128> pitti, seems so indeed :-(
[13:34] <seb128> sorry about that
[13:35] <tkamppeter> bzr lp-login returns my user name and then doing bzr push lp:~ubuntu-desktop/poppler/ubuntu again gives
[13:35] <tkamppeter> bzr: ERROR: Cannot lock LockDir(lp-89229968:///~ubuntu-desktop/poppler/ubuntu/.bzr/branchlock): Transport operation not possible: readonly transport
[13:35] <pitti> I was about to say "debcheckout -a poppler", but that wouldn't work here then
[13:37] <StevenK> Argh! Where did View->Source go in Firefox 6?
[13:38] <nigelb> StevenK: Tools -> Web Developer -> Page Source. also, ctrl + U
[13:39] <StevenK> nigelb: Indeed, I just found that myself. Thanks!
[13:39] <StevenK> What a silly change.
[13:39] <nigelb> I just use firebug usually
[13:43] <tkamppeter> seb128, any further tips to bet the bzr push working?
[13:43] <seb128> tkamppeter, you maybe don't have access to that vcs
[13:43] <seb128> tkamppeter, do a merge request?
[13:46] <tkamppeter> seb128, is it perhaps core-dev-only?
[13:47] <seb128> tkamppeter, it is
[13:51] <tkamppeter_> seb128, my connection broke, here are the last messages again:
[13:51] <tkamppeter_> seb128, is it perhaps core-dev-only?
 tkamppeter, it is
[13:51] <tkamppeter_> seb128, I have only per-package upload (icl. Poppler). The new poppler package I have successfully uploaded to the upload server.
[13:52] <seb128> not sure how ppu works with vcs-es
[13:53] <pitti> seb128: you can push to UDD branches, but not to ~ubuntu-desktop
[13:54] <bigon> Rebuild upload doesn't require ffe I guess
[13:54] <bigon> ?
[13:54] <seb128> pitti, is there any way to "fix" that out of moving away from ~ubuntu-desktop?
[13:54] <Laney> bigon: for a transition? no
[13:55] <pitti> seb128: aside from using a MP or the UDD branch I don't see any
[13:55] <seb128> tkamppeter_, pitti: feel free to use udd for poppler then
[13:55] <seb128> it's small enough that it's ok
[13:59] <tkamppeter> pitti, seb128, will someone move poppler's BZR then?
[13:59] <NCommander> pitti: your a FFe machine. I went to go look at FFes this morning to find you've handled most of the queue :-P
[14:00] <pitti> NCommander: comes with being pinged about them relentlessly :)
[14:00] <pitti> NCommander: and also with cleaning mail in the morning
[14:01] <NCommander> I need a way ot make mail that already been handled to to Archived
[14:03] <tkamppeter> pitti, seb128, what needs to get into the Poppler branch is now the debdiff between 0.16.7-2ubuntu1 and 0.16.7-2ubuntu2.
[14:04] <tkamppeter> http://launchpadlibrarian.net/77598473/poppler_0.16.7-2ubuntu1_0.16.7-2ubuntu2.diff.gz
[14:04] <Gasseus> Is there any way to set the .profile for the guest?
[14:08] <tkamppeter> pitti, do you remember when we discussed the problem with foomatic-db-compressed-ppds instead of foomatic-db getting installed on the buildds and we arrived at the conclusion to add Build-Conflicts: foomatic-db-compressed-ppds to the printer driver packages? buildds built the packages then, but now that all broke together and it seems that a completely different solution is needed: bug 829471, bug 829446.
[14:08] <tkamppeter> OdyX, ping
[14:08] <OdyX> tkamppeter: pong
[14:09] <tkamppeter> doko, ping
[14:10] <tkamppeter> pitti, sorry, the problem with foomatic-db seems to be already solved.
[14:13] <seb128> doko, "xvfb-run: error: Xvfb failed to start"
[14:14] <seb128> doko, is that really a bug in random packages?
[14:14] <seb128> or is xvfb broken?
[14:21] <cjwatson> bdrung: are you OK with my syncpackage-lp branch now?
[14:22] <tkamppeter> OdyX, I have seen your pyppd package in Debian, great. Are you currently migrating all printer driver packages in Debian?
[14:23] <OdyX> tkamppeter: in the process of, yes.
[14:27] <hallyn> Laney: I'll reply in the bug
[14:28] <Laney> sure
[14:29] <hallyn> Laney: thanks
[14:31] <Laney> welcome
[14:42] <bdrung> cjwatson: i still have to look at it.
[14:43] <tkamppeter> OdyX, I saw your new foomatic-db and filed a sync request for pyppd, bug 829534.
[14:44] <tkamppeter> pitti, hi
[14:44] <pitti> hey tkamppeter
[14:45] <tkamppeter> pitti, can you have a look at bug 829534. OdyX has introduced a new debhelper for PPD compression. Is it OK for Oneiric? It only changes packaging, removing repeated code from  debian/rules in printer driver packages.
[14:47] <tkamppeter> doko, hi
[14:48] <pitti> tkamppeter: can you please subscribe u-release@? bit busy right now, will have a look later
[14:48] <doko> seb128, I can
[14:49] <doko> 't see this, how many o these are this?
[14:49] <tkamppeter> pitti, done.
[14:49] <doko> bryceh, could you have a look at xfvb?
[14:49] <seb128> doko, no sure but the pygtk one is due to that
[14:49] <doko> tkamppeter, now
[14:49] <seb128> doko, I doubt it's a bug in pygtk, it didn't change for ages
[14:50] <tkamppeter> doko, there were build failures of printer drivers, gutenprint, ptouch-driver, and m2300w.
[14:50] <doko> tkamppeter, fix them =)
[14:50] <tkamppeter> doko, they all built on buildds the first time when I uploaded them.
[14:50] <tkamppeter> doko, what has changed on the buildds?
[14:51] <doko> tkamppeter, software?
[14:51] <doko> tkamppeter, look at the build logs
[14:51] <tkamppeter> doko, and are gutenprint and ptouch-driver working again? You have marked them invalid without further comment.
[14:52] <doko> tkamppeter, no, script error
[14:52] <tkamppeter> doko, I had done Build-Conflicts against foomatic-db-compressed-ppds, and the buildds did it correctly, and now it has foomatic-db-compressed-ppds installed and blocks on it.
[14:55] <tkamppeter> doko, OdyX, pitti, so the general question: Both binary packages foomatic-db and foomatic-db-compressed-ppds provide foomatic-db. Now I ned foomatic-db and NOT foomatic-db-compressed-ppds as build dependency. Earlier it was suggested to me to add Build-Conflicts: foomatic-db-compressed-ppds and that worked in the beginning. Now it broke. What do I have to do?
[14:56] <pitti> tkamppeter: broke how?
[14:56] <doko> tkamppeter, can't tell without looking. I filed ~100 reports today
[14:56] <pitti> tkamppeter: you can use a versioned build dependency on foomatic-db if you want to ensure you get the real package
[14:56] <pitti> if build conflicts don't work
[14:56] <pitti> (haven't checked)
[14:58] <tkamppeter> pitti, doko, OdyX, bug 829471, bug 829446, bug 829496.
[14:59] <pitti> tkamppeter: so apparenlty something else pulls in the compressed variant
[14:59] <pitti> tkamppeter: try in a PPA with a versioned build dep?
[14:59] <tkamppeter> pitti, strange is that as I introduced the build conflicts 2 or 3 weks ago, it worked.
[14:59] <pitti> tkamppeter: yes, but your build dependencies may have changed, and grown a dependendcy to the compressed one?
[15:00] <tkamppeter> pitti, why could a versioned build dep work?
[15:00] <pitti> tkamppeter: Provides: are not versioned, so they don't satisfy a version requirement
[15:00] <tkamppeter> pitti, the available foomatic-db-compressed-ppds and foomatic-db are always of the same version.
[15:00] <tkamppeter> pitti, thanks.
[15:01] <pitti> tkamppeter: yes, but if you do "b-dep: foo (>= 1)", this will only be satisfied by "foo", not by package "bar" which "Provides: foo"
[15:01] <tkamppeter> pitti, and then the pulling of the versioned foomatic-db will uninstall foomatic-db-compressed-ppds?
[15:01] <pitti> tkamppeter: the deeper question is of course which package pulls in -compressed in the first place
[15:02] <pitti> tkamppeter: that depends on ^
[15:02] <pitti> if the thing that pulls it in has a dep "-compressed | foomatic", then it shuold work
[15:02] <pitti> if it has a dep "compressed" without alternative, then no
[15:02] <pitti> then it's uninstallable
[15:02] <tkamppeter> pitti, and if that package pulls "foomatic-db-compressed-ppds" explicitly, the build process will not be able to uninstall -compressed-ppds.
[15:02] <dholbach> jamespage, I'll have a look at the antlr3 update
[15:03] <pitti> tkamppeter: the builder never uninstalls a package
[15:03] <jamespage> dholbach: hey - you where reading my mind
[15:03] <ricotz> hrw, hello :), just wanted to mention the content of binutils-arm-linux-gnueabi_2.21.52.20110707-1ubuntu1cross1.71_amd64.deb seems a bit messed up
[15:03] <dholbach> jamespage, I got the email, which helped a bit with that ;-)
[15:04] <jamespage> dholbach: right - got an odd error from launchpad so assumed I'd failed to request a review from you :-)
[15:06] <tkamppeter> pitti, so if -compressed-ppds gets already installed by the builder before the build-deps of the source package are read, then the package is generally unbuildable.
[15:06] <tkamppeter> pitti, is there any way to do a general search on the buildds where this unwished dep originates?
[15:06] <hallyn> stgraber: hey, late last week, when shutdown in a container wasn't working for you, what was the missing package again?
[15:06] <pitti> tkamppeter: apt-cache rdepends
[15:06] <pitti> tkamppeter: Package: foomatic-db-engine
[15:06] <pitti> Recommends: foomatic-db-compressed-ppds | foomatic-db
[15:08] <tkamppeter> pitti, so I should remove this altogether and perhaps only put a Suggests: foomatic-db.
[15:09] <mr_pouit> seb128: the build failures with xfvb are caused by fakeroot 1.16 iirc
[15:09] <pitti> tkamppeter: depends; does it make sense for foomatic-db-engine to pull in the PPDs?
[15:09] <pitti> tkamppeter: as I said, you can still try with a versioned build dep
[15:09] <pitti> if apt resolves them all in one go, it should pick the alternative
[15:10] <stgraber> hallyn: it wasn't a missing package. It was the old lxcguest removing /var/run instead of removing its content (so removing the symlink from /var/run to /run)
[15:11] <tkamppeter> pitti, will do so, first, foiomatic-db-engine to remove the recommends, then the drivers to pull versioned foomatic-db.
[15:11] <pitti> tkamppeter: you shouldn't drop a valid recommends just to work around the ptouch-driver FTBFS
[15:12] <pitti> also, you only need one, not both
[15:12] <hallyn> stgraber: hm, i thought that there was a separate instance where a package was msising due to using minbase
[15:13] <hallyn> ok, thanks
[15:13] <Laney> I thought buildds didn't install recommends, only depends
[15:13] <tkamppeter> pitti, this recommends is not so important, especially the presence of -compressed-ppds  does not improve the functionality of foomatic-db-engine.
[15:13] <pitti> Laney: hmm, good point
[15:14] <Laney> get a chroot, aptitude --without-recommends build-dep foo, aptitude why bar
[15:14] <stgraber> hallyn: nope. the problem with using minbase was that we'd end up without ifconfig/file/... that are usually quite useful to have around
[15:15] <pitti> Laney: well, it's definitively a b-dep, the log is quite clear there
[15:16] <tkamppeter> pitti, for me it looks more that the buildds does something wrong. See
 https://launchpadlibrarian.net/77487052/buildlog_ubuntu-oneiric-i386.m2300w_0.51-0ubuntu13_FAILEDTOBUILD.txt.gz
 and search "compressed-ppds" in there.
[15:16] <Laney> just saying that generally if I want to know "why did this package get installed?" I call upon aptitude why
[15:16] <hallyn> stgraber: my newest lucid container, under oneiric, isn't shutting down.  drat.
[15:17] <Laney> tkamppeter: that means that you've said -compressed- must not be installed, but another package says that it must
[15:17] <Laney> two conflicting requirements
[15:18] <stgraber> hallyn: can you try creating a symlink from /run to /var/run?
[15:18] <tkamppeter> pitti, first mention is "Build-Conflicts: foomatic-db-compressed-ppds" meaning that it did not get installed before and now the system knows it is not desired.
[15:18] <stgraber> hallyn: I'm wondering if lxc only monitors /run now
[15:18] <pitti> tkamppeter: yes, but as you see in the build log it gets installed during installing build dependencies
[15:19] <pitti> so perhaps the buildds have started installing recommends recently/
[15:19] <pitti> ?
[15:19] <pitti> infinity, lamont ^
[15:19] <tkamppeter> pitti, second mention: foomatic-db-compressed-ppds: already deinstalled, system confirms that -compressed-ppds is correctly not present.
[15:20] <tkamppeter> pitti, can it be that the buildds is installing recommended packages nowadays?
[15:20] <pitti> tkamppeter: that's why I asked infinity/lamont about this
[15:20] <Laney> you can see that recommended packages are not installed
[15:21] <Laney> look for Recommended packages: and see that none of those get pulled in
[15:21] <hallyn> stgraber: no that doesn'tn do it :(
[15:21] <hallyn> (and /proc/10573/root/run/utmp and /proc/10573/root/var/run/utmp are the same file now)
[15:21] <pitti> apt-cache rdepends foomatic-db-compressed-ppds only has some meta packages, and cups/foomatic-db-engine which only recommend it
[15:22] <pitti> Laney: that "recommended packages" list isn't quite complete, though, apparently?
[15:22] <Laney> I didn't get -compressed installed in my chroot, fwiw
[15:22] <infinity> pitti: As Laney says, Recommends aren't being installed, but I missed what the actual problem is here?
[15:22] <hrw> ricotz: report a bug please
[15:22] <pitti> infinity: trying to figure out https://launchpadlibrarian.net/77487052/buildlog_ubuntu-oneiric-i386.m2300w_0.51-0ubuntu13_FAILEDTOBUILD.txt.gz
[15:22] <Laney> I assume it's something to do with how the buildds resolve depends
[15:23] <pitti> infinity: in particular, why foomatic-db-compressed-ppds gets pulled in
[15:23] <pitti> (it's a build conflict)
[15:23] <stgraber> hallyn: ok, so you're probably hitting something completely different then...
[15:24] <hallyn> yeah, lxc-monitor doesn't report anything until i do 'lxc-stop' by hand
[15:24] <infinity> pitti: Build-conflicts aren't magical.
[15:24] <Laney> it must be being pulled in by the provides
[15:24] <pitti> infinity: they shouldn't be
[15:24] <pitti> infinity: but I checked apt-cache rdepends and can't find a package which pulls in foomatic-db-compressed-ppds as a depends
[15:25] <infinity> It provides foomatic-db, which is a build-dep.
[15:25] <pitti> infinity: my initial recommendation was to version the foomatic-db build dep
[15:26] <pitti> to force taking the real package
[15:26] <infinity> WHY does it provide fommatic-db?
[15:26] <Laney> is the provides correct then, if it's not a genuine replacement?
[15:26] <infinity> foo*
[15:26] <tkamppeter> infinity, but foomatic-db can also be fulfilled by foomatic-db why does the buildds not go this way?
[15:26] <pitti> tkamppeter: just try it with a versioned b-dep
[15:26] <infinity> tkamppeter: Because it's perfectly valid to do so? :P
[15:27] <pitti> well, arguably it's quite unexpected
[15:27] <infinity> I need to toy with the idea of adding build-conflicts to the apt-get invocation as negatives.
[15:27] <infinity> as in: apt-get install build-dep buil-dep build-dep build-conflict-
[15:27] <pitti> if there's a real package, it should use that, especially when the virtual alternative is a conflict, but still, there's an easy workaround, so I don't think we should waste more time on that
[15:28] <infinity> pitti: "If there's a real package, it should use that" is a non-starter.  Real and vitual are afforded the same level of citizenry.
[15:29] <Laney> is there a custom resolver or do they use one provided by sbuild?
[15:29] <infinity> pitti: It's why we usually don't have real and virtual overlapping in namespace, so we can then do things like "Depends: real | virtual" to get the desired behaviour.
[15:29] <pitti> well, just said that this is my gut feeling :)
[15:29] <infinity> Laney: sbuild's resolver to find the build-deps, apt's resolver to install.
[15:30] <infinity> Uhm.
[15:30] <infinity> pitti: Also, duh.
[15:30] <Laney> I think rleigh did some tests recently with the aptitude resolver
[15:30] <infinity> pitti: foomatic-db is in universe, this package is in main.
[15:30] <infinity> pitti: (So, people might be oeverthinking this a lot)
[15:30] <pitti> ah :)
[15:30] <infinity> pitti: The ONLY foomatic-db in main is the one that's also a build-conflict.
[15:31] <pitti> tkamppeter: ^
[15:33] <pitti> kelemengabor: released
[15:33] <infinity> Laney: Upstream sbuild has, like, 34 different resolver options.  On the other hand, we know the warts in Ubuntu's, and I like reproducibility.
[15:33] <kelemengabor> pitti: thanks!
[15:33] <infinity> Laney: (We also do things viciously different from Debian buildds intentionally in some ways...)
[15:35] <infinity> Laney: It's also worth noting that 99% of the time people complain about sbuild's resolver (or other such things), it's usually pilot error (as above).
[15:35] <infinity> Laney: Which somewhat inflates the percieved number of problems. :P
[15:39] <Laney> I don't have a problem with it - the only time I use aptitude is when building for exp when apt won't find a solution. It seemed like that was one of the times when aptitude would have found a solution over apt, but happily it was likely a user problem
[15:54] <mr_pouit> pitti: when you have some time later, could you look at bug #817792 please? (sorry if you're already aware of it) advpng is changing to mode 664 recompressed pngs
[15:55] <pitti> mr_pouit: ah, probably fallout from the recent umask change
[15:55] <pitti> mr_pouit: I'm wasn't aware, thanks for pointing out
[15:58] <hallyn> stgraber: well the problem for me is that ssh only stops on runlevel S, but the container never goes to runlevel S, it goes from 2 to 0
[15:58] <hallyn> when i change ssh's stop on to 'runlevel [0S]' the continer exits fine
[15:59] <infinity> hallyn: Why would you expect it to go to S?
[16:00] <cjwatson> I deliberately made ssh *not* stop on 0 (or 6) in line with https://wiki.ubuntu.com/Teardown
[16:01] <hallyn> infinity: *I* don't.  ssh.conf shipped with openssh-server does
[16:01] <stgraber> cjwatson, hallyn: did that change post-release?
[16:01] <hallyn> cjwatson: yet another thing for lxcguest to tweak then
[16:02] <infinity> Where are you seeing a stop on S?
[16:02] <hallyn> cjwatson: I think the full problem is that it gets killed by sendsigs,
[16:02] <hallyn> cjwatson: and then upstart restarts it
[16:02] <infinity> I have stop on runlevel [!2345]
[16:02] <hallyn> infinity: look at lucid's ssh.conf
[16:02] <infinity> Oh, we're going back in time. :P
[16:02] <hallyn> !2345 wouuld work for us
[16:03] <infinity> Err, lucid's is as above too.
[16:03] <hallyn> not on mine!
[16:03] <hallyn> what on earth...?
[16:04] <hallyn> oh, maybe bc the containers are debootstrapped without lucid-updates
[16:04] <hallyn> checking
[16:04] <cjwatson> stgraber: oh, wait, it indeed changed in maverick
[16:04] <cjwatson> yeah, bug 603363
[16:04] <hallyn> (and lp:ubuntu/lucid-updates/openssh does not exist :( )
[16:15] <tkamppeter> pitti, can you move foomatic-db into Main then. I t should always have been in Main as it is a build dependency.
[16:15] <pitti> tkamppeter: done
[16:16] <pitti> tkamppeter: that should solve the issue, so you can close the FTBFS bugs
[16:16] <tkamppeter> pitti, is there something which automatically demotes binary packages to Universe if it does not find an evidence that it contributes to what is on the CDs?
[16:17] <pitti> tkamppeter: s/CDs/main/
[16:17] <pitti> tkamppeter: not automatically, but http://people.canonical.com/~ubuntu-archive/component-mismatches.txt will complain, so archive admins demote unneeded stuff
[16:17] <tkamppeter> pitti, thanks for syncing pyppd.
[16:18] <tkamppeter> pitti, should I switch to the versioned build-depends to secure foomatic-db in main?
[16:18] <pitti> tkamppeter: let's see whether it complains; if it does, we need to do that
[16:19] <tkamppeter> pitti, one package with versioned dependency is already on the way: m2300w.
[16:56] <ScottK> slangasek: I fixed sip4 (uploaded), but then it turns out python-qt4 does have a mulit-arch related issue.  Please let me know when you can discuss so I can figure out the best way to fix it.
[17:05] <tkamppeter> pitti, how long does it take for foomatic-db to arrive in Main?
[17:10] <infinity> tkamppeter: A publisher cycle.
[17:10] <infinity> tkamppeter: From the POV of the buildds, I assume it'll be fine in about 20 minutes, longer for mirrors.
[17:40] <tkamppeter> infinity, thanks. m2300w started to build now.
[17:47] <slangasek> ScottK: hi, happy to discuss python-qt4 now
[17:47] <ScottK> slangasek: Hello.
[17:48] <ScottK> Now that I fixed sip4 I have one file in python-qt4 (and the dbg) that gets multiarched:
[17:48] <ScottK> usr/lib/i386-linux-gnu/qt4/plugins/designer/libpythonplugin.so
[17:49] <slangasek> ok, yes, I saw that in my testing too
[17:49] <slangasek> is that a problem?  It should transparently DTRT on the Qt side
[17:49] <ScottK> python-qt4.install has usr/lib/qt4/*
[17:49] <ScottK> So it finds nothing.
[17:49] <ScottK> Bang.  FTBFS.
[17:50] <ScottK> If I, for the sake of testing, change it to usr/lib/i386-linux-gnu/qt4/* then all is well.
[17:51] <ScottK> Suggestions?
[17:51] <slangasek> ScottK: I would (and did locally) edit the .install to usr/lib/*/qt4/*
[17:51] <ScottK> slangasek: Fair enough.
[17:51] <ScottK> Thanks.
[17:52] <slangasek> sure!
[18:17] <doko> ScottK, please keep the bug tasks in the ftbfs, create a new task, don't reassign please
[18:17] <ScottK> doko: It was re-assigned once.  I was putting it back.
[18:19] <ScottK> If there's special rules for these bugs they should be written down somewhere.
[18:21] <doko> ScottK, send a patch to the svammel project
[18:22] <ScottK> doko: I've no idea what you are talking about?
[18:33] <slangasek> ScottK: lp:svammel is the mass-ftbfs-bug-filing tool; the trouble is that if the bug gets reassigned off of the package that fails to build, the next svammel run (depending on options passed) may wind up filing the bug again
[18:33] <ScottK> Ah.  Well that would explain why another one got filed against python-qt4.
[18:33] <slangasek> (though there's meant to be a capability of caching the list of already-filed-bugs locally to avoid dupes)
[18:36] <xerosis> hi, I'm trying to bzr push a bug fix but it will let me push to .../natty/... but not .../oneric/... what am I doing wrong?
[18:40] <slangasek> xerosis: do you want to give the full URIs of where you're trying to push to?  Otherwise we'd kinda be guessing blind :)
[18:41] <xerosis> slangasek, sorry, I'm following https://wiki.ubuntu.com/Bugs/HowToFix and I'm trying to do the second to last command
[18:42] <slangasek> xerosis: yes, please tell us the exact command line you're typing
[18:42] <slangasek> oh, nevermind, I see the issue
[18:42] <slangasek> you've misspelled "oneiric" :-)
[18:42] <xerosis> slangasek, oh dear
[18:43] <xerosis> slangasek, thank-you that was it, I'll be hiding in the corner now...
[18:43] <slangasek> no worries
[18:44] <slangasek> it's not an easy word to spell... considering it's not even in half the dictionaries I have to hand: )
[19:56] <slangasek> YokoZar1: hey, what was the reasoning for pulling all of the gstreamer0.10-plugins-* packages, with dependencies, into ia32-libs last cycle?  Surely it's a diminishingly small set of plugins that are actually useful in the wine case, no?
[20:32] <dupondje> Somebody knows if there is someone working on a new mutter version ?
[20:56] <GTRsdk> I don't know if this is the right channel, but is there a package that provides xulrunner-dev?
[21:02] <tkamppeter> OdyX, ping
[21:06] <infinity> ScottK: Can I blame these failures on recent QT mangling? https://launchpad.net/ubuntu/+source/semantik/0.7.3-0ubuntu3
[21:09] <slangasek> infinity: it's probably fallout from qt4 going multiarch, so I'll share the blame together with upstream's bad build system
[21:33] <infinity> slangasek: Any interest in looking into it, or shall I poke it later?
[21:33] <slangasek> infinity: no specific interest; there are a number of kubuntu packages in main I should probably look at first
[21:34] <infinity> Fair enough.  It'll stall the ocaml re-transition for a bit, but that won't hurt my feelings if I don't fix it before the weekend. :)
[21:35] <infinity> slangasek: I haven't looked, but I'm assuming you figure it's probably just a bad path lookup?
[21:35] <infinity> slangasek: Shouldn't be rocket science for me to sort.
[21:35] <infinity> s/bad/hardcoded/
[21:36] <slangasek> infinity: yes, the only bugs we have that should be rocket science for us to sort are ones in altus metrum-provided packages
[21:43] <sgnb> infinity: I think it doesn't affect anything else ocaml-ish...
[21:44] <sgnb> and besides, this package doesn't seen to provide any *.cmx* file, so it didn't need recompilation
[21:44] <infinity> sgnb: Ahh, well, it was on the transition page.   I'll admit to not being sure how that's generated. :P
[21:45] <sgnb> the transition page lists everything (build-)depending on ocaml... it is not specially relevant to this transition
[21:46] <infinity> sgnb: Either way, finding the build failure doesn't hurt my feelings. ;)
[21:46] <infinity> sgnb: (But happy to fix it later, if you're sure it doesn't matter for the transition)
[21:46] <sgnb> the actual condition is "installing some *.cmx* file"
[21:47] <infinity> sgnb: Do you happen to have a list that meets your criteria for stages 3 through 6? ;)
[21:48] <infinity> Or 8...
[21:48] <infinity> sgnb: I was just going through the transition page and bouncing everything that appears to contain native-compiled code.  Which seems reasonable enough.
[21:49] <infinity> (Though obviously less precise than your definition)
[21:50] <cjwatson> siretart: do you have any recommendation for what to do with mplayer in oneiric?  At the moment it fails to build because libavformat isn't detected at configure time due to an API change (av_alloc_format_context).  The version in Debian experimental seems to have totally different stuff around there in configure.  My choices seem to be (a) just fix up the configure test with the new API, and anything else using the same ...
[21:50] <cjwatson> ... functions, or (b) pull in the new snapshot from experimental, requiring an FFe and all the rest of it.  Neither of those options seems hugely appealing to me
[21:51] <infinity> cjwatson: Changing the configure test sort of assumes that function isn't actually used in the code...
[21:51] <sgnb> infinity: is there some file listing of .deb files of Ubuntu available somewhere?
[21:51] <infinity> cjwatson: Oh, I see the "and anything else using the same".  Yes.  That sounds unfun.
[21:51] <cjwatson> there actually isn't anything else using it
[21:51] <infinity> sgnb: Contents files on the mirrors.
[21:52] <cjwatson> the actual code in libmpdemux uses libavformat_alloc_context, which is the new API
[21:52] <infinity> cjwatson: So, if you short the configure test and build, everything's groovy?  That seems to be the path of least resistance.
[21:52] <slangasek> I'm always in favor of stabbing configure checks that test for things that aren't used by the software
[21:52] <slangasek> like the wrong libssl check I patched for the other day
[21:53] <cjwatson> infinity: I'm about to find out
[21:53] <slangasek> every time I see the package phonon, I think of Bokonon
[21:54] <infinity> sgnb: I need to run out for a late lunch appointment.  But I'll be back in an hour or less if you have more transition insight for me. :)
[22:01] <cjwatson> ok, there are a couple of other API fixes needed, but don't look too major
[22:01] <cjwatson> hmm
[22:01] <cjwatson> upstream diff:
[22:01] <cjwatson> -       for (fmt = first_oformat; fmt; fmt = fmt->next)
[22:01] <cjwatson> +       for (fmt = av_oformat_next(NULL); fmt; fmt = av_oformat_next(fmt))
[22:01] <cjwatson> compare with:
[22:01] <cjwatson> -    for (fmt = first_iformat; fmt; fmt = fmt->next)
[22:01] <cjwatson> +    for (fmt = av_iformat_next(NULL); fmt; av_iformat_next(fmt))
[22:02] <slangasek> heh
[22:04] <nigelb> is it python?
[22:04] <cjwatson> err?
[22:05] <nigelb> only place where whitespace probably matters :)
[22:05] <cjwatson> no, it's the missing 'fmt = '
[22:05] <nigelb> ah
[22:05] <nigelb> gah, should learn to read before asking stupid questions :)
[22:07] <Laney> looks good
[22:08] <slangasek> all except that infinite loop part
[22:09] <YokoZar1> slangasek: mostly it's the embedded movies in game intros and stuff -- things that in the bad old days would cause a crash even though the app worked
[22:09] <slangasek> YokoZar1: yes, but what are the gstreamer plugins that are *actually* needed?
[22:10] <YokoZar1> I don't fully know, I'll try to get a shorter list.  Are you considering splitting the packages further?
[22:10] <slangasek> you pulled in roughly 250 plugins, with a similarly high number of library dependencies; I don't think all of these represent things actually used by Windows software in practice, and I'd like to cull some of the lesser-used plugins
[22:11] <slangasek> either by removing them from ia32-libs entirely, or leaving the plugins in the package but ditching their specialized library dependencies
[22:12] <YokoZar1> Yes, I did this because I wasn't entirely sure what was being useful and what was not (with a suspicion that the more esoteric plugins were precisely the sort of thing that would occur in weird windows programs)
[22:13] <slangasek> well, I'd really like it if we had some hard data here on what plugins are actually needed; I would estimate we could reduce the size of ia32-libs (source+binary) another 30-40% from where it is right now if we had that
[22:14] <slangasek> but if it's non-trivial to get that info, well, I'd rather you focused on converting the gstreamer deps to multiarch for P :)
[22:14] <mdeslaur> so...glade in oneiric doesn't open gtk2 glade files anymore?
[22:15] <YokoZar1> slangasek: I'll send an email to the guy who did the actual gstreamer implementation in Wine to see what he thinks.  I do suspect there's some 80/20 stuff going on here for sure though.
[22:17] <slangasek> YokoZar1: cool, thanks :)
[22:41] <YokoZar1> slangasek: the response is that -good and -base would probably be enough, which seems like the logical place to start anyway
[22:42] <slangasek> YokoZar1: oh, if we could drop the others that would be most excellent - how strong of a "probably" is that?