[00:05] <slangasek> micahg: they'd be subject to feature freeze
[00:09] <micahg> slangasek: understood, but are they wanted :)
[00:19]  * slangasek defers to the release manager ;)
[00:20] <micahg> skaet: ^^
[00:21] <slangasek> fwiw I would in general be willing to spend some time reviewing FFes for multiarching of any libraries that are part of ia32-libs currently
[00:40] <skaet> micahg,  slangasek;  which libs are we talking about?   I can't see in my scroll back.  Had an offline glitch for an hour or so.  :P
[00:41] <slangasek> I think micahg's referring to the hypothetical case at the moment
[00:41] <micahg> [17:26] <micahg> in general through the end of the cycle, do we still want multiarch changes from Debian?
[00:41] <slangasek> but there are about 15 packages that are interesting wrt ia32-libs right now (due to wine)
[00:44] <skaet> ah,  ok.   Yeah,  it definitely will require FFEs now ;)   however if slangasek is volunteering...   should be ok to pick some up for next week or so.   After that,  we'll need to see where we are with unity/ubiquity/etc. and solid the images are.
[00:46] <micahg> skaet: yeah, I'll file FFes, but I've been noticing  a couple a day in Debian and was wondering if it's wanted
[00:47] <skaet> micahg,  thanks.
[00:47] <slangasek> I wouldn't bother with any that aren't in ia32-libs
[00:47] <skaet> slangasek,  https://api.launchpad.net/1.0/ubuntu/natty/ has no release date for natty...   any idea where it should have been set from?
[00:47] <slangasek> if they haven't yet risen to the level of someone wanting them in ia32-libs, they're not worth an FFe
[00:47] <micahg> slangasek: oh, it wouldn't be better to get them in now for extended testing for the LTS?
[00:48] <slangasek> skaet: no clue; bdmurray raised that question earlier, I've never even heard of release dates for series being part of the LP API
[00:48] <slangasek> micahg: I would expect 6 months in Debian unstable to be adequate testing on that score, if it's really a change we're just picking up from Debian
[00:49] <micahg> slangasek: ok, will keep in mind
[00:49]  * micahg will also keep an eye out for dh_python2 changes, but those should just be packaging changes (that I wouldn't think would be subject to FFe as it affects build time)
[01:06] <ScottK> micahg: Build system changes are generally subject to FFe.
[01:06] <ScottK> (I've already fixed one dh_python2 transition that resulted in an empty package in the archive)
[01:22] <micahg> ScottK: oh, hmm, I've always thought packaging changes that shouldn't impact binaries don't need an FFe (yes, everyone can mess up)
[02:43] <ScottK> micahg: Fixing bugs in the packaging system is one thing.  Redesign of the packaging system is different.
[02:45] <ajmitch> ScottK: so switching from cdbs & pycentral to dh7 & dh_python2 probably needs an FFe?
[02:46] <ScottK> Yes, but that'd be an easy one to approve in most cases.
[02:47]  * ajmitch got a couple of those in just before FF
[02:48] <ajmitch> at least 1 remaining to do, but I'll look at getting a FFe for a new upstream release as well
[03:05] <micahg> ScottK: if that's policy for dh_python2, maybe you can send an e-mail to that regard?  I'm sure I wouldn't be the only one to have thought differently
[03:05] <ScottK> I'll discuss with the release team first to make sure I'm not the outlier.
[03:06] <micahg> ScottK: k, thanks, I"ll hold off until that happens, I still have to switch stragglers in the xubuntu seed to dh_python2, but won't start on that until next week
[03:07] <micahg> ScottK: and if the case is that it needs an FFe, the followup question is, are the changes still desired?
[03:08] <ajmitch> still plenty in universe to migrate, iirc
[03:08] <micahg> at least 1091 total still, idk how many in universe
[03:14] <ScottK> micahg: I would say that in general, it's desired, but let's see what I find out from my mail to ubuntu-release.
[03:15] <micahg> ScottK: k
[03:18] <ScottK> Personally, I'd be glad to approve any with an attached build log, the output of debc attached, and a link to a Debian bug.
[07:18] <pitti> cjwatson: thanks, I source-NEWed it last night, will do binNEW now
[07:18] <pitti> cjwatson: I'll just add it to the dependencies of ubuntu-defaults-builder, I think; these are small packages
[08:26] <tseliot> pitti: can you approve the binaries in new for the following sources, please? nvidia-graphics-drivers-updates nvidia-graphics-drivers-96-updates nvidia-graphics-drivers-173-updates nvidia-settings-updates fglrx-installer-updates
[08:26] <tseliot> pitti: also, they're in universe now instead of restricted
[08:27] <pitti> tseliot: you mean multiverse?
[08:28] <tseliot> pitti: launchpad says universe
[08:29] <jbicha> if you're doing archive admin work today, I have a whole collection of packages that are obsolete
[08:29] <jbicha> and should be removed: http://paste.ubuntu.com/664050/
[08:29] <pitti> tseliot: that sounds wrong, I'll move it to multiverse
[08:30] <tseliot> pitti: ok, shall we move them to main in the future?
[08:30] <tseliot> pitti: restricted
[08:31] <pitti> tseliot: eek, no -- these are still not free software, right?
[08:31] <pitti> tseliot: restricted sounds fine to me, I'll put them there
[08:31] <pitti> moved the source packages
[08:33] <tseliot> pitti: yes, they're proprietary and I really meant restricted instead of main
[08:33] <pitti> tseliot: will nvidia-common actually get along with these? the alternatives handling etc?
[08:34] <tseliot> pitti: I'll fix nvidia-common. It's next on my TODO list
[08:35] <pitti> tseliot: fglrx-amdcccle-updates looks like it would file-conflict with fglrx-amdcccle
[08:36] <pitti>  Conflicts: fglrx-control, fglrx-control-qt2
[08:36] <pitti>  Replaces: fglrx-amdcccle, fglrx-control
[08:36] <pitti> shouldn't that have a conflicts: fglrx-amdcccle, too?
[08:36] <tseliot> pitti: yes, unfortunately it's not possible to install them at the same time
[08:36] <seb128> jbicha, you might want to open bugs about those or if you don't want to do that maybe drop an email on the devel list
[08:36] <tseliot> pitti: let me check
[08:36] <seb128> jbicha, better chance that somebody pick those from an email than from IRC
[08:37] <pitti> tseliot: same with the fglrx-updates binary; it Replaces: fglrx, but doesn't Conflicts: to it, so you will install both at the same time and overwrite all of fglrx' files
[08:37] <pitti> that makes it hard to switch back to fglrx
[08:37] <tseliot> pitti: they both conflict and provide fglrx-control though
[08:37] <tseliot> and replace
[08:37] <pitti> tseliot: ah
[08:38] <tseliot> pitti: same thing for fglrx which conflicts, replaces and provides fglrx-driver
[08:39] <pitti> tseliot: right, looks fine; sorry for false alarm
[08:39] <tseliot> better be safe than sorry ;)
[08:39] <pitti> tseliot: all done
[08:40] <micahg> jbicha: I'd suggest to file bugs for each group of related removals and subscribe ubuntu-sponsors
[08:41] <tseliot> pitti: thanks. I guess launchpad hasn't updated the source pages yet
[08:41] <pitti> oh? it should, that's fairly immediate
[08:41] <jbicha> micahg: ubuntu-sponsors not ubuntu-archive?
[08:41] <micahg> jbicha: removals like anything else need to be ACKd
[08:41] <jbicha> ok
[08:42] <pitti> tseliot: https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-updates/+publishinghistory
[08:42] <pitti> looks alright
[08:42] <tseliot> pitti: I still see universe except for nvidia-settings-updates which is in multiverse
[08:42] <tseliot> pitti: oh, so it's the overview that's not updated
[08:42] <pitti> tseliot: yes, that only updates after publishing
[08:42] <pitti> +changelog and +publishinghistory are immediate
[08:43] <tseliot> pitti: oh, I see. Thanks again
[09:04] <doko> didrocks, there are a lot of bugs, which you claim having promoted, but which are not :-(  e.g. 795073. please be more careful
[09:05] <didrocks> doko: see comment #5
[09:05] <didrocks> doko: I promoted it
[09:05] <didrocks> I didn't copy the output manually
[09:05] <didrocks> or is there something wrong here?
[09:06] <didrocks> I get the same thing with you yesterday btw
[09:06] <didrocks> something you promoted that wasn't as well
[09:06] <doko> didrocks, no, look at the current archive. python-greenlet is still in universe. I just promoted it
[09:06] <didrocks> doko: well, I didn't copy the output manually
[09:07] <doko> well, then something else is wrong
[09:07] <doko> cjwatson: ^^^
[09:07] <didrocks> doko: I have the same with one of your promotion yesterday
[09:07] <didrocks> please check before blaming
[09:07]  * didrocks looks for it
[09:07] <doko> didrocks, which one?
[09:08] <didrocks> doko: one sec, greeping my logs
[09:08] <didrocks> grepping*
[09:09] <didrocks> doko: libgrip
[09:09] <didrocks> doko: https://bugs.launchpad.net/ubuntu/+source/libgrip/+bug/740206
[09:09] <ubot4> Launchpad bug 740206 in libgrip (Ubuntu) "[MIR] libgrip (affects: 1) (heat: 3)" [Undecided,Fix released]
[09:09] <didrocks> doko: see, I've redone the promotion yesterday evening
[09:11] <doko> didrocks, see, I've redone the python-greenlet promotion now
[09:11] <doko> so there seems to be something wrong
[09:11] <didrocks> indeed
[09:12] <didrocks> seems seed maybe was late to be edited or deps and so they were demoted?
[09:25] <doko> seb128, didrocks: who can I blame^B^B^B^Bask about the new usb seeds?
[09:26] <seb128> skaet I think but not sure, maybe cjwatson or pitti know better
[09:53] <pitti> the initial set was done by allison; but anyway, we shold just throw out the universe stuff for now
[09:59] <Daviey> ugh
[09:59] <ogra_> dont say that !
[09:59] <Daviey> :o
[10:02] <doko> pitti: so it's ok to drop anjuta, audacity, wesnoth-1.8, fozen-bubble?
[10:19] <Daviey> - python-carrot should hopefully fall off Main Inclusion, next week - being transitioned. So doesn't need touching atm.
[10:39] <Daviey> - python-ipy will go away when the nova snapshot currently in unapproved queue passes (dropped as a dep)
[10:58] <Daviey> - swift, glance and nova are top level depends; others need satisfying first.
[11:08] <Daviey> skaet: I will not be able to attend the release meeting today, and the rest of the team are travelling.
[11:09]  * Daviey will be travelling shortly.
[11:22] <ogra_> hmm, where do we have the universe FF definition, do i need an FFe for a new package in universe ?
[11:23] <Laney> yes
[11:23] <ogra_> thx
[11:23] <Laney> there's no separate process for universe/main
[11:23] <ogra_> there used to be
[11:24] <ogra_> and i feel that it varies every release (not sure why i feel like that) ...
[11:24] <skaet> Daviey, thanks,  wendar will be hosting today.   I'll be traveling too.
[11:24] <ogra_> .. so i think i better ask :)
[11:24] <Laney> the motu and main release teams were merged some time ago
[11:24] <Laney> no problem with asking :-)
[11:24] <ogra_> skaet, ! what are you doing up already
[11:25] <skaet> ogra_, heading to airport,  on way to Vancouver for LinuxCon next week.
[11:25] <skaet> :)
[11:25] <ogra_> skaet, to answer last night question, i dont think there is a bug about the composite vs. gksu issue yet, i'll make sure to have filed it today
[11:26] <ogra_> *night's
[11:26] <ogra_> mvo and dbarth know about it from conversations though, they should be prepared ;)
[11:27] <ogra_> Laney, do you also know who is FFe approver for universe this time round ?
[11:27] <Laney> ogra_: anyone, it's the same queue
[11:27] <Laney> some of us might be more universe focused than others though
[11:27] <ogra_> ah, k
[11:28] <ogra_> thats a good change vs having single people assigned as we did in the past
[11:28]  * ogra_ hugs Laney, thx !
[11:28] <Laney> I don't know if the delegates system is still operational, but that wouldn't replace this anyway :-)
[11:28]  * Laney hugs ogra_ 
[11:30] <doko> cjwatson, ev: ubiquity depends on libcheese1, which depends on gst-plugins-bad. what should we do about this?
[11:30] <ev> doko: it's going to be cleared up in the next upload
[11:30] <doko> cool, thanks
[11:30] <ev> which is waiting on me sorting the move of camerabin from gst-plugins-bad to gst-plugins-good
[11:39] <mvo> ogra_: which bug is that?
[11:40] <ogra_> mvo, black screen if gksu shows the dialog if metacity composite is enabled
[11:41] <ogra_> running unity-2d and firing off gksu should show it
[11:53] <mvo> ogra_: ok, gksu is going away anyway
[11:53] <ogra_> this cycle ?
[12:01] <jbicha> mvo: will pkexec gedit work? or will we have to type in a long string?
[12:02] <mvo> not sure, #security was handling this, I'm not fully up-to-date
[12:12] <ogra_> mvo, well, if we dont it shouldnt be hard to just comment the gamma adjusting code, no ?
[12:12] <ogra_> so the window shows on a plain screen instead of black background
[12:24] <doko> pitti, would you be happy with json-c in main for the desktop team? see bug #824303
[12:24] <ubot4> Launchpad bug 824303 in json-c (Ubuntu) "[MIR] json-c (affects: 1) (heat: 10)" [Undecided,Confirmed] https://launchpad.net/bugs/824303
[12:31]  * cjwatson uploads ubuntustudio-meta, since it's ages behind its seeds
[12:32] <cjwatson> and is the sole cause of a number of NBS entries
[12:52] <pitti> doko: seems harmless enough; no formal test suite, but the code is simpl enough, so no objection
[12:53] <doko> pitti, can you subscribe (or the team)?
[12:53] <pitti> doko: to bugs? yes
[12:55] <pitti> doko: done, sub'ed desktop-team
[12:55] <seb128> pitti, what team? ubuntu-desktop?
[12:55] <pitti> canonical-desktop-team for now
[12:55] <pitti> it's got zero bugs, and if anyone ever finds one, it's probably serious
[12:56] <seb128> pitti, hum, please don't
[12:56] <seb128> hum
[12:56] <pitti> seb128: I can also sub myself only
[12:56] <seb128> pitti, let's switch to #ubuntu-desktop to discuss it
[12:57] <pitti> I sub'ed myself for now
[13:01] <Laney> cheers for the backport run
[13:03]  * mterry writes MIR for cython
[13:03] <mterry> oh, maybe not
[13:08] <mterry> doko, why does cython show up in component-mismatches?  it's part of a "cython | python-pyrex" build-depend, and python-pyrex is in main
[13:08] <doko> germinate issue
[13:08] <mterry> Is that just a nuance the mismatch script doesn't handle, or is that something we should change in the packagin?
[13:09] <mterry> germinate is how we generate this report?
[13:09] <cjwatson> not a germinate issue
[13:09] <cjwatson> may be a seed issue
[13:09] <cjwatson> yes, we germinate all the seeds and then compare against main
[13:10] <cjwatson> well, I don't *think* it's a germinate issue anyway, it isn't normally.  I suppose I ought to check
[13:11] <mterry> cjwatson, cython doesn't seem to be in platform or ubuntu seeds
[13:12] <cjwatson> sure
[13:12] <cjwatson> didn't say it was :)
[13:12] <mterry> cjwatson, thought that was what you meant by seed issue
[13:12] <cjwatson> what I mean is that normally the data should be blamed not the processing tool
[13:13] <cjwatson> in much the same way that one doesn't automatically say that a bug in the output of a C program is a gcc bug
[13:13] <mterry> I thought most programmers blamed gcc for their bugs  ;)
[13:15] <doko> wondering why update-inetd shows up in c-m.
[13:16]  * mterry does MIR for dvdauthor
[13:18] <cjwatson> from what I can tell, germinate simply ends up trying to resolve build-deps from bzr before it runs across anything that would cause it to put python-pyrex in main
[13:18] <cjwatson> it's important to remember that it does not care what is *currently* in main when making this judgement; it's selecting everything from scratch
[13:19] <cjwatson> the simplest workaround is probably to put python-pyrex in the supported-development-common seed along with bzr (with a suitable comment)
[13:19] <mterry> cjwatson, apparently, part of our delta for bzr is already dropping other build-depends that aren't in main
[13:19] <mterry> cjwatson, it might make sense just to drop cython too
[13:20] <cjwatson> if you do that then it will know that python-pyrex is supported before trying to resolve build-dependencies, so it won't need to make a decision about the disjunctive build-dep
[13:20] <cjwatson> *shrug* either is reasonable, personally I'd probably seed it but whichever
[13:21] <cjwatson> doko: it's not showing up itself, only as the cause for libfile-temp-perl
[13:23] <cjwatson> though I'm not sure why it's picking libfile-temp-perl rather than perl-modules which Provides it
[13:24] <cjwatson> probably because update-inetd shows up while processing a relatively fundamental seed and perl-modules hasn't been encountered yet
[13:25] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/723731 would be useful for this, but in the meantime I'll commit a workaround
[13:25] <ubot4> Launchpad bug 723731 in germinate (Ubuntu) "control alternative dependency expansion without actually seeding package (affects: 1) (heat: 1)" [Wishlist,Triaged]
[13:27] <cjwatson> doko: worked around
[13:42] <doko> cjwatson, thanks!
[14:03] <mterry> seb128, what's the story with cheese?  is it supposed to be in main?
[14:04] <seb128> mterry, no, ev is working on getting the new ubiquity which drop that depends in
[14:04] <seb128> mterry, should be done today if that works as he wants
[14:06] <mterry> That will fix a lot of these component mismatches
[14:09] <seb128> mterry, indeed, all the clutter, mx, gst ones
[14:09] <seb128> with quite some codecs and libs due to the gst one
[14:45] <doko> I hope all js mismatches are done now ...
[14:55] <doko> it's now cheese which smells strongest in c-m
[15:04] <slangasek> did I see that cheese was pulled in via ubiquity?  And ev said he was going to be dropping that anyway
[15:04] <slangasek> so maybe this goes away with a ubiquity upload
[15:07] <doko> yes, he's working on it