slangasek | micahg: they'd be subject to feature freeze | 00:05 |
---|---|---|
micahg | slangasek: understood, but are they wanted :) | 00:09 |
* slangasek defers to the release manager ;) | 00:19 | |
micahg | skaet: ^^ | 00:20 |
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:21 |
=== rsalveti` is now known as rsalveti | ||
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:40 |
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:41 |
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:44 |
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:46 |
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:47 |
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:48 |
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) | 00:49 | |
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:06 |
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) | 01:22 |
ScottK | micahg: Fixing bugs in the packaging system is one thing. Redesign of the packaging system is different. | 02:43 |
ajmitch | ScottK: so switching from cdbs & pycentral to dh7 & dh_python2 probably needs an FFe? | 02:45 |
ScottK | Yes, but that'd be an easy one to approve in most cases. | 02:46 |
* ajmitch got a couple of those in just before FF | 02:47 | |
ajmitch | at least 1 remaining to do, but I'll look at getting a FFe for a new upstream release as well | 02:48 |
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:05 |
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:06 |
micahg | ScottK: and if the case is that it needs an FFe, the followup question is, are the changes still desired? | 03:07 |
ajmitch | still plenty in universe to migrate, iirc | 03:08 |
micahg | at least 1091 total still, idk how many in universe | 03:08 |
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:14 |
micahg | ScottK: k | 03:15 |
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. | 03: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 | 07:18 |
=== doko__ is now known as doko | ||
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:26 |
pitti | tseliot: you mean multiverse? | 08:27 |
tseliot | pitti: launchpad says universe | 08:28 |
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:29 |
tseliot | pitti: ok, shall we move them to main in the future? | 08:30 |
tseliot | pitti: restricted | 08:30 |
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:31 |
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:33 |
tseliot | pitti: I'll fix nvidia-common. It's next on my TODO list | 08:34 |
pitti | tseliot: fglrx-amdcccle-updates looks like it would file-conflict with fglrx-amdcccle | 08:35 |
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:36 |
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:37 |
tseliot | pitti: same thing for fglrx which conflicts, replaces and provides fglrx-driver | 08:38 |
pitti | tseliot: right, looks fine; sorry for false alarm | 08:39 |
tseliot | better be safe than sorry ;) | 08:39 |
pitti | tseliot: all done | 08:39 |
micahg | jbicha: I'd suggest to file bugs for each group of related removals and subscribe ubuntu-sponsors | 08:40 |
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:41 |
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:42 |
tseliot | pitti: oh, I see. Thanks again | 08:43 |
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:04 |
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:05 |
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:06 |
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:07 |
didrocks | doko: one sec, greeping my logs | 09:08 |
didrocks | grepping* | 09:08 |
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:09 |
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:11 |
didrocks | seems seed maybe was late to be edited or deps and so they were demoted? | 09:12 |
doko | seb128, didrocks: who can I blame^B^B^B^Bask about the new usb seeds? | 09:25 |
seb128 | skaet I think but not sure, maybe cjwatson or pitti know better | 09:26 |
pitti | the initial set was done by allison; but anyway, we shold just throw out the universe stuff for now | 09:53 |
Daviey | ugh | 09:59 |
ogra_ | dont say that ! | 09:59 |
Daviey | :o | 09:59 |
doko | pitti: so it's ok to drop anjuta, audacity, wesnoth-1.8, fozen-bubble? | 10:02 |
Daviey | - python-carrot should hopefully fall off Main Inclusion, next week - being transitioned. So doesn't need touching atm. | 10:19 |
Daviey | - python-ipy will go away when the nova snapshot currently in unapproved queue passes (dropped as a dep) | 10:39 |
Daviey | - swift, glance and nova are top level depends; others need satisfying first. | 10:58 |
Daviey | skaet: I will not be able to attend the release meeting today, and the rest of the team are travelling. | 11:08 |
* Daviey will be travelling shortly. | 11:09 | |
ogra_ | hmm, where do we have the universe FF definition, do i need an FFe for a new package in universe ? | 11:22 |
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:23 |
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:24 |
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:25 |
ogra_ | *night's | 11:26 |
ogra_ | mvo and dbarth know about it from conversations though, they should be prepared ;) | 11:26 |
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:27 |
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:28 | |
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:30 |
mvo | ogra_: which bug is that? | 11:39 |
ogra_ | mvo, black screen if gksu shows the dialog if metacity composite is enabled | 11:40 |
ogra_ | running unity-2d and firing off gksu should show it | 11:41 |
mvo | ogra_: ok, gksu is going away anyway | 11:53 |
ogra_ | this cycle ? | 11:53 |
jbicha | mvo: will pkexec gedit work? or will we have to type in a long string? | 12:01 |
mvo | not sure, #security was handling this, I'm not fully up-to-date | 12:02 |
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:12 |
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:24 |
* cjwatson uploads ubuntustudio-meta, since it's ages behind its seeds | 12:31 | |
cjwatson | and is the sole cause of a number of NBS entries | 12:32 |
pitti | doko: seems harmless enough; no formal test suite, but the code is simpl enough, so no objection | 12:52 |
doko | pitti, can you subscribe (or the team)? | 12:53 |
pitti | doko: to bugs? yes | 12:53 |
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:55 |
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:56 |
pitti | I sub'ed myself for now | 12:57 |
Laney | cheers for the backport run | 13:01 |
* mterry writes MIR for cython | 13:03 | |
mterry | oh, maybe not | 13:03 |
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:08 |
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:09 |
cjwatson | well, I don't *think* it's a germinate issue anyway, it isn't normally. I suppose I ought to check | 13:10 |
mterry | cjwatson, cython doesn't seem to be in platform or ubuntu seeds | 13:11 |
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:12 |
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:13 |
doko | wondering why update-inetd shows up in c-m. | 13:15 |
* mterry does MIR for dvdauthor | 13:16 | |
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:18 |
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:19 |
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:20 |
cjwatson | doko: it's not showing up itself, only as the cause for libfile-temp-perl | 13:21 |
cjwatson | though I'm not sure why it's picking libfile-temp-perl rather than perl-modules which Provides it | 13:23 |
cjwatson | probably because update-inetd shows up while processing a relatively fundamental seed and perl-modules hasn't been encountered yet | 13:24 |
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:25 |
cjwatson | doko: worked around | 13:27 |
doko | cjwatson, thanks! | 13:42 |
mterry | seb128, what's the story with cheese? is it supposed to be in main? | 14:03 |
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:04 |
mterry | That will fix a lot of these component mismatches | 14:06 |
seb128 | mterry, indeed, all the clutter, mx, gst ones | 14:09 |
seb128 | with quite some codecs and libs due to the gst one | 14:09 |
doko | I hope all js mismatches are done now ... | 14:45 |
=== micahg_ is now known as micahg | ||
doko | it's now cheese which smells strongest in c-m | 14:55 |
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:04 |
doko | yes, he's working on it | 15:07 |
=== Ursinha is now known as Ursinha-bbl |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!