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