[01:04] <cjwatson> could somebody review mountall?  I ran the "mountpoint is a symlink to another mountpoint" handling past Keybuk and got a "looks sane"; the other changes are a few lines each and easily eyeballable
[01:04] <cjwatson> I uploaded sysvinit and mountall intending them to be reviewed as a pair, but unfortunately only sysvinit has been accepted
[01:35] <cjwatson> slangasek: linux-linaro and linux-meta-linaro are a lot of what's left in component-mismatches.  Should they be seeded or demoted?
[01:57] <cjwatson> I've looked through the python-gnome2-desktop NBS listing (which also effectively covers python-gnomeprint).  They're all false positives due to ored dependencies, with the exception of labyrinth (filed bug 648469) and memaker (fix uploaded).
[01:57] <ubot4> Launchpad bug 648469 in labyrinth (Ubuntu Maverick) (and 1 other project) "depends on NBS python-gnome2-desktop (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/648469
[02:18] <cjwatson> oh my.  http://people.canonical.com/~ubuntu-archive/NBS/libopensync0-dev is not going to be fun.
[02:18] <cjwatson> is anyone at all driving that transition?
[02:19] <cjwatson> looks like libopensync0-dev -> libopensync-dev, opensync-1.0.pc -> libopensync.pc (which will entail a load of reautotooling) and probably some more ...
[08:52] <ogra> oh, cdimage has new CSS
[08:53] <ogra> a bit out of bounds with the content though
[09:21] <slangasek> cjwatson: linux{,-meta}-linaro> demoted; I thought doko was already taking care of this?
[09:35] <wgrant> cjwatson: bigjools wants your blessing for the queue admin permission granularity extensions. Could you record your approval on bug #648611?
[09:35] <ubot4> Launchpad bug 648611 in soyuz "Queue admin permissions need pocket and status granularity (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/648611
[09:38] <mvo> I sponsored mesa based on the FFe discussed in #631413 - it has quite a bit of churn :/
[09:39] <mvo> it seems that if we decided to go with that branch we should go all the way instead of shiping a snapshot, but I can not say that I feel really great about it (from a releae-management POV)
[09:41] <mvo> fwiw I tested it on my intel arrandale and it was fine there
[09:58] <cjwatson> ogra: yes, I've reported the poor layout and Matt Nuzum is supposed to be doing something about it
[09:58] <ogra> nice
[09:58] <cjwatson> slangasek: thanks
[09:59] <cjwatson> wgrant: done
[09:59] <ogra> btw, i jusr discovered that i missed to seed u-boot-linaro-omap3-beagle ... just a warning that i just replaced u-boot-omap3 with it since you guys are cleaning up component mistmatches
[10:00] <ogra> (it will likely show up there soon)
[10:00] <wgrant> cjwatson: Thanks.
[10:00] <ogra> (removal bug is filed too as bug 648616)
[10:00] <ubot4> Launchpad bug 648616 in u-boot-omap3 (Ubuntu Maverick) (and 1 other project) "please remove u-boot-omap3 from the archive, it got replaced by u-boot-linaro (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/648616
[10:57] <cjwatson> did whoever reviewed debconf ensure that it behaves appropriately when unconfigured?
[11:57] <cjwatson> slangasek: the linux-linaro demotion doesn't seem to be taking; I'm going to try promoting it to main and then demoting it again in the hope that that will take
[11:57] <cjwatson> the database is right but it hasn't been published
[11:59] <cjwatson> doko_: this libopensync-plugin-gnokii rebuild isn't enough; notice how it's also listed in http://people.canonical.com/~ubuntu-archive/NBS/libopensync0-dev.  Rejecting it
[12:01] <cjwatson> doko_: same goes, I suspect, for all your opensync uploads :-(
[12:01] <cjwatson> doko_: surely they need to be converted to the current development package
[12:02] <cjwatson> 02:19 <cjwatson> looks like libopensync0-dev -> libopensync-dev, opensync-1.0.pc -> libopensync.pc (which will entail a load of reautotooling) and probably some more ...
[12:02] <doko_> cjwatson: yes =)
[12:02] <doko_> had the old package still installed :/
[12:04] <cjwatson> ok, rejecting them all then, sorry - probably best not spend buildd time in duplicate at the moment
[12:04] <wgrant> cjwatson: Does linux-linaro have any arch-indep packages?
[12:04] <wgrant> If so, you've just destroyed them.
[12:05] <wgrant> Ah, it appears not. Good.
[12:05] <cjwatson> why would I have?
[12:06] <wgrant> Reverting an unpublished override eats arch-indep binaries.
[12:06] <cjwatson> wgrant: lovely ...
[12:06] <wgrant> cjwatson: Yes.
[12:06] <wgrant> cjwatson: Why do you think the demotion hadn't worked? You overrode it a couple of minutes into last hour's publisher.
[12:06] <wgrant> So it should be publishing right around now.
[12:07] <cjwatson> wgrant: and I'd overridden it an hour or two before that, and slangasek an hour or two before that.
[12:08] <wgrant> Soyuz only knows about one 59 minutes ago.
[12:08] <wgrant> And it just published now.
[12:08] <cjwatson> 09:21 <slangasek> cjwatson: linux{,-meta}-linaro> demoted; I thought doko was already taking care of this?
[12:08] <wgrant> So change-override didn't do anything. Do you have output from a run before an hour ago?
[12:08] <cjwatson> insufficient screen scrollback, sorry
[12:09] <wgrant> Hmmm.
[12:10] <cjwatson> well, sorry if I reverted the override unnecessarily; I can put it back later today
[12:10] <wgrant> It seems to have happily returned to main now.
[12:10] <wgrant> So a further universe override should work fine.
[12:10] <cjwatson> should I wait 'til this publisher run finishes?
[12:10] <wgrant> But I am intrigued as to why change-override didn't do anything the first two times.
[12:11] <wgrant> Doesn't matter, no.
[12:11] <cjwatson> hang on, if it just published now, then that override was the one that put it back to main
[12:11] <cjwatson> the output of change-override when I tried to override to universe said that it was already in universe
[12:11] <wgrant> cjwatson: The universe and main overrides just published together.
[12:11] <cjwatson> oh
[12:12] <wgrant> In a few minutes the main one will supersede the universe one.
[12:12] <cjwatson> I've overridden it back to universe, then
[12:12] <cjwatson> which hopefully will actually work
[12:12] <wgrant> It has worked, yep.
[12:12] <cjwatson> I mean publish :-)
[12:29] <doko> cjwatson: any idea why springlobby doesn't have build records for armel and powerpc?
[12:30] <cjwatson> %spring: i386 amd64                                                   # x86 specific, needs java5 and hardware accellerated OpenGL
[12:30] <cjwatson> %springlobby: i386 amd64                                              # Depends on spring
[12:30] <cjwatson> (Packages-arch-specific)
[12:31] <cjwatson> that's straight from Debian
[12:40] <doko> cjwatson: hmm, I did look at bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/packages-arch-specific/ubuntu
[12:52] <stgraber> Riddell: ping
[12:55] <Riddell> hi stgraber
[13:02] <stgraber> Riddell: did you get my mail regarding langpack issues affecting Edubuntu and Kubuntu ?
[13:02] <Riddell> don't think so
[13:02] <Riddell> ah, there it is, /me reads
[13:03] <stgraber> it's kind of an issue as it makes Edubuntu and Kubuntu DVD to fail to build completely :(
[13:03] <Riddell> stgraber: pitti and cjwatson were discussing that earlier in #u-d
[13:04] <Riddell> 11:43 < cjwatson> or we could exclude those language packs from the build
[13:04] <stgraber> oh, ok, didn't see it (just woke up) :)
[13:04] <Riddell> seemed to be the conclusion
[13:04] <Riddell> I don't know how to exclude them from the seeds though
[13:05] <stgraber> no idea, in our case we use a regexp to match everything, so we might need some cjwatson magic (would the blacklist work for that ?) to solve the issue
[13:06] <stgraber> I clearly don't mind shipping RC with a few missing kde langpacks as long as I at least have a build to release ;)
[13:06] <cjwatson> I can deal with it
[13:07] <cjwatson> regexps can support that kind of thing if you're sufficiently devious
[13:07] <stgraber> cjwatson: I'd appreciate it, thanks.
[13:13] <doko> ScottK: bug #648773
[13:13] <ubot4> Launchpad bug 648773 in ufc (Ubuntu) (and 1 other project) "FFe: sync ufc and dolfin from unstable (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/648773
[13:41] <cjwatson> doko: debconf fails to build, and I'm concerned about changing helpers at this point since debconf.py has very specific requirements (it absolutely has to work even when unconfigured).  Would it be possible to have an upload that reverts the use of dh_python2/3 and just fixes the python3 module path?
[13:44] <doko> cjwatson: ok, will look at it. might require a python-central merge from unstable. will know later
[14:01] <zul> can someone accept the new mysql-cluster upload it contains the proper fix for mysqlclient collision bug
[14:06] <cjwatson> zul: err ... same version as what's already in the archive?
[14:06]  * cjwatson thinks LP could stand to have rejected that one
[14:06] <zul> cjwatson: umm
[14:07] <zul> cjwatson: crap...never mind
[14:08] <seb128> hello there
[14:08] <seb128> I think you will not like that but glib update coming
[14:09] <seb128> it's breaking quite some abi and api and even dropping some
[14:09] <seb128> do you want a bug with the debdiff, NEWS, rational etc?
[14:09] <seb128> basically those are api added during the unstable cycle they decided were wrong and dropped before GNOME 2.32
[14:10] <seb128> they are updating the GNOME 2.32 according to the changes
[14:10] <cjwatson> I think we should search the archive for uses of such API
[14:10] <seb128> it's very likely that nothing else is using those api
[14:10] <cjwatson> we don't have time to react in any less organised way
[14:10] <seb128> do we have an easy way to do that?
[14:10] <cjwatson> probably not, find a DC machine with an archive and unpack it
[14:10] <seb128> kees, ^
[14:10] <seb128> I think you did grepping for api some time ago for dx
[14:11] <seb128> do you have an easy setup for that?
[14:22] <seb128> ok
[14:22] <seb128> bug #648877
[14:22] <ubot4> Launchpad bug 648877 in glib2.0 (Ubuntu) "2.25.16 glib update (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/648877
[14:23] <seb128> has a summary of the changes and a debdiff for review
[14:24] <cjwatson> ubiquity 2.4.3 fixes livefs build failures with 2.4.2; would appreciate review
[15:19] <doko_> cjwatson: could you have a look at http://paste.ubuntu.com/501506/ for gcc-4.4 (and maybe for gcc-4.5 too)
[15:21] <cjwatson> looks ok to me
[15:22] <doko_> ok, finishing my test build and veryfing that plplot builds again
[15:36] <seb128> is there anybody in charge of the release or who can be pinged for reviews?
[15:36] <seb128> until when do we have for changes?
[15:55]  * Riddell doing reviews
[16:00] <raphink> hi guys
[16:01] <raphink> the most recent berkeley DB is 4.8 in maverick/main
[16:01] <raphink> would it be a good idea to have db5.0 in universe?
[16:01] <raphink> I have the package ready
[16:02] <raphink> (and tested in production)
[16:17] <raphink> anyone here?
[16:32] <cjwatson> raphink: I think new packages in universe are probably not a good idea at this point; there's too little time to fix them if they turn out to have problems
[16:32] <raphink> ok
[16:32] <raphink> thanks
[17:49] <kees> seb128: hello!
[17:49] <kees> seb128: yeah, I can do another search; I have a local copy of the archive. what's the api?
[17:50] <seb128> kees, hey
[17:50] <seb128> g_application
[17:50] <seb128> g_application*
[17:53] <kees> seb128: ok, checking
[17:53] <seb128> thanks
[17:57] <slangasek> cjwatson: sorry, when I said "demoted" I meant "should be demoted", not "I've demoted them" - so yours was the first override, I think :)
[17:58] <cjwatson> slangasek: ah - gotcha
[18:04] <Riddell> in https://wiki.kubuntu.org/ReleaseCandidateProcess where it says Modify debian-cd/CONF.sh to set OFFICIAL="Release Candidate"  where is that file?
[18:04] <Riddell> /srv/cdimage.ubuntu.com/debian-cd/CONF.sh looks likely
[18:04] <cjwatson> bzr+ssh://antimony/srv/cdimage.ubuntu.com/bzr/debian-cd/
[18:05] <cjwatson> edit it there please, then 'bzr pull' in /srv/cdimage.ubuntu.com/debian-cd
[18:57] <cjwatson> I've mucked around with scary regexes in the Kubuntu and Edubuntu DVD seeds to exclude the broken language packs for now
[18:58] <cjwatson> should be reverted after the new base language packs arrive post-RC
[19:11] <stgraber> cjwatson: thanks
[19:44] <seb128> kees, still grepping?
[19:44] <kees> seb128: yup.
[19:44] <seb128> ok
[19:44] <kees> seb128: so far, glib2.0 glibmm2.4 totem
[19:44] <kees> (I'm past "t" in main, universe will probably take until tomorrow)
[19:46] <seb128> kees, can you put the list on bug #648877
[19:46] <ubot4> Launchpad bug 648877 in glib2.0 (Ubuntu) "2.25.16 glib update (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/648877
[19:46] <seb128> once it's past the main set
[19:46] <kees> seb128: sure thing
[19:47] <seb128> thanks!
[19:49] <kees> seb128: oh, finished main. I've updated the bug
[19:50] <seb128> kees, thanks
[19:54] <kees> np
[20:01] <seb128> cjwatson, skaet, slangasek: could you review the glib update?
[20:01] <seb128> cjwatson, skaet, slangasek: could you review the glib update?
[20:01] <seb128> ups
[20:01] <seb128> bug #648877
[20:01] <ubot4> Launchpad bug 648877 in glib2.0 (Ubuntu) "2.25.16 glib update (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/648877
[20:06] <ScottK> cjwatson or slangasek: Could I have a respin of Kubuntu desktop live on i386?  We'd like to test the latest ubiquity on an actual ISO (just to be sure as soon as possible it's working).
[20:06] <skaet> seb128,  looking...
[20:06] <seb128> skaet, thanks
[20:13] <ScottK> slangasek and cjwatson: unping.
[20:37] <Riddell> seb128: did you work out a way to check that the ABI changes to glib don't affect anything?
[20:38] <seb128> Riddell, kees is grepping the archive for those abi, there is only totem and glibmm using it in main
[20:38] <seb128> and those are going to be updated today as part of GNOME 2.32
[20:38] <ScottK> How about Universe?
[20:39] <seb128> grep still running
[20:39] <ScottK> OK
[20:39] <Riddell> seb128: thanks, I'll accept
[20:39] <seb128> but I would be surprised if something out of GNOME was using it
[20:39] <seb128> those api have been adding in the maverick cycle
[20:39] <kees> ScottK: I'll have universe in about 10 hours, I think
[20:39] <seb128> and they have broken the abi every second week
[20:39] <ScottK> You'll update those too, right?
[20:39] <seb128> I think nothing out of GNOME started using them
[20:39] <seb128> yes
[20:39] <ScottK> Cool.
[20:40] <seb128> ScottK, thanks
[20:47] <Riddell> I feel unqualified to review linux-mvl-dove, anyone able to tell me what I'm looking for?
[21:24] <Rubidium_> hi, is a Debian freeze-exception enough to get one for Ubuntu's Maverick release as well? It'd would be just syncing some packages unmodified from Debian testing. I'm personally not using Ubuntu and the last time I installed Ubuntu to make debdiffs they were never used although that was for an after-release CVE vulnerability.
[21:25] <Rubidium_> http://lists.debian.org/debian-release/2010/09/msg01824.html is the "ack" of Debian's release team and one of the bugs that are fixed is listed in http://qa.ubuntuwire.com/bugs/rcbugs/
[21:27] <cjwatson> depends - we're later in our release process than Debian is, but it can be possible.  please file sync requests for each one separately (https://wiki.ubuntu.com/SyncRequestProcess) and we'll look at them
[21:36] <Daviey> Hi release team!  Just as a "heads up", i'm hoping to get one more upload of eucalyptus in tonight... ETA ~2 hours. :/
[21:36] <Daviey> The package will be ready before then... but trying to test it.. and as it's an upgrade bug.. takes a while to reproduce
[21:43] <robbiew> Daviey: heh...trying to influence the freeze again, aye? ;)
[21:43] <Daviey> robbiew, Yeah, can we have the freeze tomorrow instead - then i can go to bed? :D
[23:02] <superm1> can someone from @ubuntu-release take a look over the ubiquity upload I just did (2.4.4), ideally to make the RC candidate disks?
[23:03] <superm1> oh there's a bot that does that and lets people know, cool
[23:16] <ScottK> superm1: Accepted.
[23:24] <superm1> thx