[00:37] <lamont> mass giveback done per request from doko, just fyi < skaet / slangasek
[00:37] <ScottK> Oh my.
[00:37] <skaet> lamont, thanks for the head's up.
=== jjohansen is now known as jj-afk
[01:06] <lamont> not that much, actually.
[01:06] <lamont> now that I've really done the giveback. :-(
[01:08] <lamont> arm was the winner at 112 jobs
=== bjf is now known as bjf[afk]
=== bjf is now known as bjf[afk]
[10:25] <ogra> lamont, acorn reboot ping :)
[10:25] <ogra> lamont, it's hanging once again
[11:23] <lamont> ogra: bbg3 boards aren't remotely rebootable. :-(
[11:23] <lamont> well, powerstabable
[11:39] <ogra> lamont, yeah, i know, seems Nafallo already cared when i pinged anyway
[11:48] <ScottK> I'd appreciate it if another release team member would double check this, but doesn't the pm-utils upload need a b-d on dpkg-dev added to use dpkg-vendor?
[11:56] <ogra> lamont, cjwatson, would http://paste.ubuntu.com/499635/ seem suitable for you to fix bug 600478 ?
[11:56] <ubot4> Launchpad bug 600478 in livecd-rootfs (Ubuntu Maverick) (and 2 other projects) "livecd.sh should remove foreign subarch headers during livefs build (affects: 1) (heat: 47)" [Medium,Confirmed] https://launchpad.net/bugs/600478
[11:59] <lamont> ogra: does that want to override, instead of appending?
[12:00] <lamont> ogra: otherwise, I'm head deep in some other stuff atm... testing would be love, etc...
[12:00] <ogra> lamont, right, on amrel images we currently end up with all linux-headers packages for all subarches
[12:00] <ogra> and we only want the one for the actual subarch we build
[12:02] <lamont> ah, yeah.  that's a somewhat stab-in-the-face approach, but may well be right.
[12:02] <lamont> I haven't really reviewed it
[12:03] <ogra> i'll run a testbuild ... takes only 90min
[12:03] <ogra> (once my babbage boots)
[12:13] <cjwatson> ScottK: perhaps a versioned b-d, but it may not matter since lucid had dpkg-vendor in its dpkg-dev
[12:14] <ScottK> cjwatson: Right, but AFAICT, it doesn't b-d on dpkg-dev at all, so I don't see how the change could work?
[12:15] <cjwatson> ScottK: is it using it at build time, rather than run time?
[12:15] <cjwatson> ScottK: dpkg-dev is build-essential ...
[12:15] <ScottK> Ah.  OK.
[12:15] <ScottK> That was the bit I was missing.
[12:15] <cjwatson> has to be given things like dpkg-source :-)
[12:15] <ScottK> cjwatson: Thanks.
[12:16] <cjwatson> if you catch things using dpkg-vendor at run-time, that's almost definitely a bug
[12:16] <cjwatson> anyone care to eyeball bug 634554 for me?  I think the upstream update is appropriate for maverick
[12:16] <ubot4> Launchpad bug 634554 in fuse (Fedora) (and 4 other projects) "fuse mounts hang on xattr retrieval with auditd (affects: 4) (heat: 28)" [Unknown,Unknown] https://launchpad.net/bugs/634554
[12:19]  * cjwatson lobs it at the queue
[12:19] <ScottK> I'm not qualified to review the code diff, but from the changelog it sounds reasonable.
[12:20]  * cjwatson nods.  Thanks.
[12:20] <cjwatson> ntfs-3g still works ;-)
[12:59] <cjwatson> the rest of the queue is either my uploads or stuff I'm too closely involved with to review
[13:05] <cjwatson> also, the sysvinit and mountall uploads are coupled; not strongly enough to justify a dependency relationship, but if sysvinit goes in without mountall then there'll be a bit of error noise at boot
[13:42] <doko> cjwatson: why does gs-common show up as a candidate for demotion? it's used as a b-d, but it's a virtual package?
[13:47] <ScottK> cjwatson: When you have a couple of minutes, I have an idea for a platform related LP change I'd like to run by you.
[13:48] <cjwatson> doko: presumably germinate always picks something else
[13:48] <cjwatson> ScottK: sure
[13:49] <ogra> ok, my livecd-rootfs headers fix works fine ...
[13:49]  * ogra commits and uploads
[13:49] <ScottK> cjwatson: It occurred to me that it would possibly be useful for non-archive admin members of the release team (such as sistpoty and iulian) to have access to the unapproved queue for the development release (like I do by virtue of being an archive admin).
[13:50] <ScottK> cjwatson: I chatted with wgrant about it and it's apparently feasible to do this.  We might also want similar for -proposed for ubuntu-sru members that aren't archive-admins.
[13:55] <doko> cjwatson, ev: libutouch-grail1-udeb utouch-grail-tools xserver-xorg-video-fbdev-udeb demotions ok? installer stuff
[13:56] <cjwatson> ScottK: agreed, I think ubuntu-release should have queue admin access
[13:56] <cjwatson> doko: yes, for now (though I want to look at those for later)
[13:57] <ScottK> cjwatson: Thanks.  How about ubuntu-sru for -proposed?
[13:57] <cjwatson> ScottK: fine by me, it makes sense
[13:57] <ScottK> OK.  Great.  I'll talk to wgrant to see if we can make it happen.
[13:57] <cjwatson> that would be wonderful, thanks
[14:08] <ScottK> cjwatson: I have a question about your language-selector upload.  The comment right before the line that's changed is "# rename is atomic".  AFAICT that's true of os.rename and also true of shutil.move if it's src and dst are on the same file system, but not if they aren't.  I'm not sure if we care, but I thought it was worth a mention to doublecheck.
[14:16] <ScottK> doko: About your axis upload - I don't find that we have a package named libservlet2.5-java-gcj (just 2.4).
[14:20] <doko> well, then we should build it, or drop libjava-axis-gcj
[14:20] <doko> so better build it for 2.5 at this stage
[14:21] <cjwatson> ScottK: good question.  let me see if it matters
[14:21] <cjwatson> hm, yes, it does, we're doing it on /etc/default/locale
[14:21] <ScottK> Thanks.
[14:21] <cjwatson> so I think instead we want something like:
[14:21] <cjwatson> try:
[14:22] <cjwatson>     os.rename(out.name, fname)
[14:22] <cjwatson> except OSError:
[14:22] <cjwatson>     shutil.move(out.name, some_name_on_same_fs)
[14:22] <cjwatson>     os.rename(some_name_on_same_fs, fname)
[14:22] <ScottK> Want me to reject it then?
[14:22] <cjwatson> actually maybe that's nonsense, perhaps we should just create the tempfile on the same fs to start with
[14:22] <cjwatson> yes please
[14:23] <ScottK> DOne.
[14:23] <ScottK> doko: I'll defer to you on how best to fix it, but your current upload would make the package uninstallable.  How about if I reject it and you upload again once it's sorted?
[14:24] <cjwatson> I think perhaps http://paste.ubuntu.com/499706/
[14:24] <doko> ScottK: no, please let it stay, I'll upload a new libservlet2.5
[14:24] <ScottK> doko: OK.
=== ara__ is now known as ara
[14:29] <ScottK> cjwatson: I think so, but I'm only looking at the changes, I don't understand the surrounding code.
[14:30] <cjwatson> I've confirmed correct behaviour with strace
[14:31] <cjwatson> the purpose of the function is to search-and-replace an existing file and write a replacement version of it
[14:31] <cjwatson> it's basically just glorified sed -i
[14:34] <doko> ScottK: re-uploaded axis, just dropping the dependency
[14:35] <ScottK> cjwatson: OK.  I'll accept it when it hits the queue.
[14:35] <ScottK> doko: OK.  I'll reject the first one and then look at that one.
[14:35] <cjwatson> ScottK: reuploaded.  thanks again for catching that
[14:36] <ScottK> cjwatson: You're welcome.  The real thanks go to whoever wrote the comment.
[14:36]  * ScottK would have never thought twice about it otherwise.
[14:37] <cjwatson> 178.2.12 michael.vogt@ubuntu.com 20100519
[14:37] <ScottK> Right, well I don't think I've ever seen anything he did that wasn't done well.
[15:02] <mvo> cjwatson: thanks a lot for this language-selector fix, funny co-incidence, I got bitten by the bug today and you already fixed :)
[15:02] <doko> cjwatson, slangasek: do the linaro packages need some seeding?
[15:13] <cjwatson> mvo: heh, well it was mostly due to seeing the merge proposal
[15:13] <cjwatson> doko: beats me
[15:27]  * persia would prefer not to see linaro packages seeded, and have the long-delayed discussion about how to represent multiple support entities at UDS
[15:38] <cjwatson> lamont: can you confirm whether bug 642344 is on your to-do list?
[15:38] <ubot4> Launchpad bug 642344 in libspring-2.5-java (Ubuntu Maverick) (and 1 other project) "libspring-2.5-java needs an initial manual build (affects: 1) (heat: 3380)" [High,Confirmed] https://launchpad.net/bugs/642344
[15:44] <doko> cjwatson: one more installer related demotion: libmtdev1-udeb mtdev-tools
[15:44] <cjwatson> that's ok too
[15:47] <smoser> i guess i should have brought this up before upload. there is a cloud-utils upload with fixes bug 621473 and bug 646823. they're both trivial fixes, with the dependency being more serious.  diff is at http://paste.ubuntu.com/499759/ diff is
[15:48] <ubot4> Launchpad bug 621473 in cloud-utils (Ubuntu) "uec-run-instances - passing multiple launchpad ids results in all of them failing (affects: 1) (heat: 116)" [Undecided,New] https://launchpad.net/bugs/621473
[15:48] <ubot4> Launchpad bug 646823 in cloud-utils (Ubuntu) "uec-run-instances requires paramiko but isn't a depends (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/646823
[15:50] <ttx> smoser: targeting them to maverick
[16:05] <ScottK> smoser: Accepted.
[16:05] <smoser> thank you
[16:06] <ScottK> You're welcome.
[16:09] <lamont> cjwatson: interestingly, it's on Ng's todo list
[16:10] <lamont> cjwatson: rt41455
[16:11] <lamont> cjwatson: we're testing some documentation while we're at it
[16:11] <doko> didn't you do this already with fpc? ;p
=== jj-afk is now known as jjohansen
[17:22] <slangasek> doko: if you mean in components-mismatches, there's no reason for these u-boot packages to be in the Ubuntu seeds right now AFAICS
[17:22] <doko> ok
[17:23] <slangasek> just don't demote u-boot-linaro-omap4-panda, which the ARM team is using :)
[17:24] <doko> slangasek: and u-boot-linaro-ca9x4-ct-vxp u-boot-linaro-mx51evk u-boot-linaro-omap3-beagle ?
[17:24] <slangasek> those are used in linaro images, not in official Ubuntu ones; they can all be demoted
[17:25] <ScottK> slangasek: What would you think about recasting the Linaro release freeze is a period to do ISO builds and testing from the Maverick archive and then make it any flavor or derivative that wants to take advantage of it can use it and uploads should be coordinated with them?
[17:26] <ScottK> Although I'm not on the SRU team, so I didn't reply to the list, I think to the extent we can make this a generic Ubuntu thing and not special treatment for one derivative, it's a good idea.
[17:27] <ScottK> I doubt it actually affects what we'll do, but I think it's a better message.
[17:27] <cjwatson> that does make a certain amount of sense
[17:28] <cjwatson> a derivative stabilisation period
[17:28] <slangasek> ScottK: it becomes an n-way coordination problem for the SRU team to figure out what should or shouldn't be let through, so if n ends up being large we would need some better tools; but sure, I think it makes sense to treat it that way
[17:29] <ScottK> I'm pretty sure n=1 for this cycle, so we can get smarter if it gets bigger.
[17:29] <slangasek> right :)
=== bjf[afk] is now known as bjf
[17:33] <ogra> cjwatson, any idea why the dove and omap4 kernels want to go to universe ? looking at supported-kernel-common in the seeds it seems dove for example was never there but it never wanted to move to universe before either
[17:33] <cjwatson> no
[17:33]  * ogra wonders if he should just add both to supported-kernel-common
[17:33] <cjwatson> look at germinate output and figure it out from there
[17:39] <ogra> oh, i guess i see the prob
[17:39] <ogra>  * ${Kernel-Stem}-dove [armel]
[17:39] <ogra>  * ${Kernel-Stem}-omap [armel]
[17:39] <ogra>  * ${Kernel-Stem}-omap4 [armel]
[17:40] <ogra> Kernel-Stem is only linux or linux-image ... but omap4 and dove have linux-ti and linux-mvl
[17:40] <ogra> (in the boot seed)
[17:40] <cjwatson> should be ${Kernel-Stem}-mvl-dove etc. then
[17:41] <ogra> right
[17:41] <ogra> no
[17:41] <ogra> actually :)
[17:41] <ogra> the that wont work with linux-image
[17:43] <skaet> ScottK, slangasek - any thoughts on where the derivative stabilization period should be documented?   wondering if this is a good topic for UDS, after we go through a cycle?
[17:43] <ScottK> Unfortunately we won't have gone through a cycle until after UDS.
[17:44] <skaet> well,  we'll be part way through at least ;)
[17:44] <slangasek> ogra: eh - why are the binary metapackages not named consistently with the kernel packages!
[17:44] <cjwatson> ogra: in fact, the original was just fine
[17:44] <cjwatson> linux-dove | 2.6.32.409.1 |      maverick | armel
[17:44] <ogra> slangasek, i didnt name them ...
[17:44] <cjwatson> linux-image-dove | 2.6.32.409.1 |      maverick | armel
[17:44] <cjwatson> linux-image-2.6.32-410-dove | 2.6.32-410.26 |      maverick | armel
[17:44] <ScottK> I think we ought to have a release team BOF session at UDS, but I don't think think particular issue needs a full session.
[17:44] <cjwatson> only the source package is -mvl-dove, and the source package name is entirely irrelevant to germinate
[17:44] <slangasek> ogra: I guess you'll have to list ${Kernel-Stem}-ti-omap4 and ${Kernel-Stem}-omap4 both to get the desired result
[17:45] <cjwatson> slangasek: no, he's just got it wrong :)
[17:45] <skaet> ScottK, including JamieBennett too I think.
[17:45] <cjwatson> ${Kernel-Stem}-ti-omap4 will have no effect as far as I can see
[17:45] <cjwatson> the metapackages are linux-omap4 and linux-ti-omap4
[17:45] <ScottK> skaet: Certainly, although my focus was around the Ubuntu release team, I think having other there is great too.
[17:46] <slangasek> skaet: I agree with ScottK; we should discuss things more generally
[17:46]  * ogra is confused, doko pinged me about tehse packages being on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[17:46] <slangasek> cjwatson: ah, ok
[17:46] <cjwatson> ogra: somebody needs to update the dove metapackage to the current version, that's all
[17:46] <skaet> slangasek, ScottK,  cool.
[17:46] <cjwatson> haven't checked what's happening with omap but I imagine it's similar
[17:46] <ogra> cjwatson, oh, ok
[17:46] <ogra> well, omap should be up to date
[17:47] <ogra> (omap4 that is)
[17:47] <cjwatson> anyway, please check germinate output etc. rather than guessing.
[17:48] <chrisccoulson> thanks to whoever approved lightning :)
[17:49] <slangasek> ogra, cjwatson: platform/installer lists the old ABI version for omap4.
[17:50] <ogra> but the proper one for dove
[17:50] <ogra> oh my
[17:50]  * ogra fixes 
[17:52] <ogra> not only the old abi version btw
[19:17] <ScottK> doko: We should have a new drizzle update on Monday that will actually build.  I'd rather not accept this one and then wait for the new one on Monday if you're OK with that?
[19:18] <doko> ScottK: I don't care, just cleaning up NBS
[19:19] <ScottK> OK. I'll reject this one and we'll let next week's upload clean it up.
[19:19] <ScottK> Thanks.
=== bjf is now known as bjf[afk]
[19:34] <sistpoty> ScottK: can you send a follow-up mail to u-d-a wrt sugar?
[19:35] <ScottK> sistpoty: Do you thin it needs it?  I cc'ed lfaraone and I don't think anyone else really needs to care.
[19:36] <sistpoty> ScottK: I guess it doesn't have mach practical impact, but I think it would be good for the sake of transparency
[19:37] <ScottK> I can see that, but I think it's a very minor point for a u-d-a mail.
[19:37] <sistpoty> ok, agreed (and it can be read on ubuntu-release list anyways)
[19:38] <ScottK> Great.
[20:07] <ogasawara> skaet: just fyi bug 647071
[20:07] <ubot4> Launchpad bug 647071 in linux (Ubuntu Maverick) (and 1 other project) "0-day Maverick Kernel Upload (affects: 1) (heat: 10)" [High,Triaged] https://launchpad.net/bugs/647071
[20:08] <skaet> ogasawara, thanks for the heads's up
[20:18] <doko> ScottK: 647079 again, ok to sync idzebra?
[20:19] <ScottK> doko: Yes.
[20:24] <skaet> ogasawara, looks good.  Only one weird thing from my perspective,  I see you set the milestone to maverick-updates, but its not showing up when I display it.
[20:27] <skaet> ogasawara, not being picked up in the maverick-updates milstone search...   hmph.   will see what I can do.
[20:30] <skaet> ogasawara, heh.   yup that worked.   search is picking it up.   all good.  action done ;)
[21:13] <doko> ScottK: ^^^ needed to build with qalculate version in maverick
[21:13] <ScottK> doko: OK.
[21:14] <ScottK> doko: Accepted.