[01:07] <micahg> hi skaet, still around?
[01:07] <skaet> hi micahg, yup,  what's up?
[01:08] <micahg> skaet: 1st, I have to apologize, I forgot to tell mr_pouit that gmusicbrowser needed an FFe for the sound menu integration, should I file a bug and get a retroactive FFe?
[01:09] <micahg> I think he assumed I already got it, but it got lost in the shuffle
[01:09] <skaet> micahg, yes please.
[01:09] <micahg> skaet: ok, thanks, second, what to do with cairo-dock, bug 723994
[01:09] <ubot4`> Launchpad bug 723994 in cairo-dock (Ubuntu Natty) (and 1 other project) "FFe: Please update Cairo-Dock to 2.3.0~0rc1 version (affects: 2) (heat: 16)" [Wishlist,New] https://launchpad.net/bugs/723994
[01:10] <skaet> you were waiting for some things to land,  where are they?
[01:10]  * skaet hasn't looked at the bug yet, and probably should :/
[01:10] <skaet> s/yet/today
[01:10] <micahg> skaet: so, now he tells me the Debian package isn't good and we should just use his version, so I'm a little confused, maybe he was hoping Debian would take his changes
[01:11] <micahg> I was hoping we would just be able to sync, but that's not possible apparently
[01:12] <skaet> micahg,  my preference is to leave it on the bench then for a while, and sort it out after beta1 comes out.
[01:12] <micahg> skaet: we can still upload then?  Does UiF factor in?
[01:13] <skaet> It does.
[01:13] <skaet> But right now,  we're at UIF as well.
[01:13] <skaet> UIF/BetaFreeze was 2300 UTC
[01:14] <micahg> ugh, ok
[01:14]  * skaet should send out a note.   Was chasing too many loose ends earlier.   Will do now
[01:16] <micahg> skaet: bug 742185
[01:16] <ubot4`> Launchpad bug 742185 in gmusicbrowser (Ubuntu) "FFe: Please Sync gmusicbrowser (universe) 1.1.7-1 from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/742185
[01:17] <micahg> changed title to look less actionable :)
[01:18]  * micahg will have to go hunt for whale food now...
[01:27] <micahg> skaet: anyways, thanks
[01:38] <skaet> micahg,  gone in and added comments, and subscribed ubuntu archive admin.
[01:38] <micahg> skaet: no need, it's already in
[01:38] <skaet> heh
[01:38] <skaet> okie
[01:38] <micahg> that's why I changed the title and apologized :)
[01:39] <skaet> :)
[01:39]  * skaet needs to get that note out now...
=== slangasek changed the topic of #ubuntu-release to: Beta Freeze in effect! | Natty Narwhal Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release managers with beer | we accept payment in cash, check or whale food | melior malum quod cognoscis
[02:22] <lamont> slangasek: it's because y'all keep stuffing huge builds through arm, and breaking sleeves and stuff
[02:22] <slangasek> breaking wut
[02:23] <slangasek> and hey, the biggest thing I stuffed through the arm queue today was php5
[02:23] <slangasek> so don't look at me ;)
[02:23] <lamont> well, all y'all
[02:23] <lamont> by which I mean DOKO
[02:24] <lamont> though to be fair, that's mostly because he got a bunch of huge phat packages dropped on his head a few years back
[02:24] <lamont> doko_: gcj-4.5 is also playing shooting-gallery with the armel targets.
[02:25]  * lamont plays whack-a-mole with the outdated gcj-4.5 (-ubuntu1) on hubbard
[02:26] <micahg> lamont: I'm about to upload chromium in a couple hours :)
[02:30] <slangasek> yeah, and I think the double gcj-4.5 upload is due to a multiarch buglet, so you can blame that one on me anyway
[02:31] <micahg> lamont: actually if you're short armel builders, I can save chromium for the weekend
[02:36] <micahg> hmm, is this new, all uploads need manual approval until release or until beta freeze is over?
[02:37] <lamont> slangasek: heh
[02:38] <lamont> anyway, the obviously mad armels are all stuffed back into the race
[02:38] <lamont> the not-obviously mad ones will eventually be obviously mad
[02:38] <lamont> but I need to go do some admin work on my daughter's laptop before she bursts into pouting
[02:49] <nhandler> j/48
[09:29] <chrisccoulson> skaet, could i get an NSS upload in to natty (it fixes the same issue as bug 741528, and is a pretty safe change)?
[09:29] <ubot4`> Launchpad bug 741528 in firefox-3.5 (Ubuntu Karmic) (and 15 other projects) "Compromised Comodo SSL certificates puts users at risk (affects: 1) (heat: 258)" [Medium,Fix released] https://launchpad.net/bugs/741528
[09:37] <cjwatson> right, we're going to be wanting queuebot then
[11:20] <cjwatson> ScottK: mx51> linux-linaro-mx51 is going to need to be promoted to main to make this work.  Can you deal with any exception bugs or whatever that you feel are needed for that?
[11:21] <ScottK> Sure.
[11:21] <ScottK> chrisccoulson: I'd suggest go ahead and upload and someone will review it in the queue.
[11:21] <cjwatson> ScottK: can I keep on calling it imx51 in d-i, or is mx51 better?
[11:21] <cjwatson> I don't know the meanings of the terms
[11:22] <chrisccoulson> ScottK, thanks
[11:22] <ScottK> cjwatson: I'm not sure.  I'd say let's try to take the shortest path to success, but I'm not sure.
[11:23] <cjwatson> it's not significantly harder either way; I'm more interested in what's right
[11:23] <cjwatson> grepping for imx51 and changing it to mx51 is easy enough
[11:23] <cjwatson> if that's the right thing to do
[11:24] <cjwatson> but if they're just different names for the same thing, I'll stick with imx51
[11:24] <ScottK> I'll ask and see if I can find out.
[11:24] <cjwatson> thanks
[11:28] <ogra_> cjwatson, i think linaro implemented something in flash kernel thats called mx51
[11:30] <ogra_> hrm
[11:30] <ogra_> we have pleany of imx arches now in the code
[11:32] <ogra_> and the efika HW doesnt have a subarch check at all
[11:32] <ogra_> (so from flash-kernel perspective the name doesnt matter)
[11:34] <cjwatson> flash-kernel doesn't care about the d-i image name anyway, only about what archdetect says
[11:34] <ogra_> (given that the kernel will likely only run on efika i would suggest calling it efikamx or some such though)
[11:34] <cjwatson> (and certainly archdetect names should be static)
[11:34] <cjwatson> hm, if that were the right name shouldn't it also be the kernel package name though?
[11:35] <cjwatson> I don't really like *inventing* names for d-i images
[11:35] <cjwatson> I'd rather either stick with current (inertia) or else match the kernel package name
[11:35] <ogra_> well, flash-kernel nowadays checks for "imx5"|"mx51" and for "Freescale MX51 Babbage Board", "Freescale MX53 LOCO Board" and for "Genesi Efika MX (Smartbook)" | "Genesi Efika MX (Smarttop)"
[11:35] <ogra_> i dont think archdetect has the latter two at all
[11:38] <cjwatson> so is mx51 a more general term than imx51?
[11:38] <ogra_> i think they are different subarches
[11:38] <cjwatson> http://www.genesi-usa.com/products/efika says "Freescale i.MX515"
[11:39] <cjwatson> so I guess imx51 is still accurate?
[11:39] <cjwatson> so confusing
[11:39] <ogra_> well, i havent been involved with mx51 at all, thats a pure linaro thing, what i know is that their kernel partially works on the nettop and should also work on the babbage
[11:40]  * ogra_ checks how their kernel is called
[11:40] <ogra_> -mx51
[11:40] <ogra_> so call the subarch that then :)
[11:40] <cjwatson> ok
[11:41] <cjwatson> is there any reason to leave the imx51 subarch in place in d-i?
[11:41] <ogra_> no
[11:41] <cjwatson> or can I rename it to mx51?
[11:41] <cjwatson> ok
[11:41] <ogra_> only historical ones probably, but i doubt we'll ever to a ludic image rebuild
[11:42] <ogra_> and if so, likely not with this d-i :)
[11:42] <ogra_> (god, my typing sucks)
[11:43] <cjwatson> ScottK: also, is there a bug for this feature in general?  if so, can it have a d-i task?
[12:42] <ScottK> cjwatson: I'll be sure to add it once I write it.
[12:52] <ScottK> cjwatson: It's 742430
[12:53] <cjwatson> ta
[12:59] <zul> skaet: can i get a FFE for new cobbler and openstack snapshot they are both in universe
[13:05] <ScottK> zul: Please just file the bugs and we'll look at them.
[13:15] <ScottK> cjwatson: I was going to subscribe ubuntu-mir to the bug and ask about promotion after someone approved the FFe.  I've discussed this with skaet and she OK'ed it, so I can either wait for her or some other release team member can mark it approved.
[13:27] <ScottK> cjwatson: So now I look around and that's not all.  I was under the impression that we had images for Kubuntu Mobile on n900 already.  We don't.  This already has an FFe (724534), but it's kernel, linux-n900 (which is based on Linaro's) is also in Universe.  Sigh.
[13:27] <ScottK> This image is also on the manifest.
[13:28] <ScottK> Do pre-installed images need D-I changes?
[13:29] <ScottK> Riddell: ^^^
[13:31] <Riddell> I didn't know we were planning on having images for n900, would be awesome though
[13:32] <ScottK> It's been on the manifest for the entire cycle.
[13:34] <cjwatson> I don't think preinstalled images need d-i, but perhaps ogra could confirm
[13:34] <ogra_> only oem-config
[13:35] <ogra_> but you need a relatively complex debian-cd setup
[13:36] <ScottK> My head hurts.
[13:36] <ScottK> ogra_: Does headless need D-I?
[13:37] <ogra_> no, as i said above, only uses oem-config
[13:37] <ScottK> I thought that was pre-installed.
[13:37] <ScottK> But great if it's both.
[13:38] <ScottK> cjwatson: If we do the Kubuntu image as a preinstalled image then I don't think we need mx51 support in D-I then.  Which also means we don't need to promote the kernels, right?
[13:39] <ogra_> you need the kernels for preinstalled too indeed
[13:39] <cjwatson> well, not on account of d-i at any rate; I don't know what preinstalled images require/prefer in that department
[13:39] <ogra_> preinstalled is pretty much identical to live images with its requirements
[13:40] <ScottK> ogra_: But does the kernel need to be in Main?
[13:40] <ogra_> hmm, i dont think so
[13:40] <ogra_> cjwatson, we have a universe mirror antimony can access, right ?
[13:40] <ScottK> It does for D-I, so avoiding that for the propsed linaro based images would be a really good thing.
[13:41] <ogra_> debian-cd pulls bootloader and kernel from the archive during build so both need to be accessible from the cdimage server (antimony)
[13:42] <ogra_> if thats the case it should work without promotion
[13:42] <cjwatson> antimony can use universe for images that are configured that way, yes
[13:42] <cjwatson> it's separated a bit to avoid universe leaking into main-only images by accident
[13:44] <ogra_> well, the debian-cd post-boot-armel+mx51 script needs to be created (preferably by someone having the HW), it needs to be able to pull the bootloader from the archive and pulls the kernel and initrd from the livefs builder livefs
[13:44] <ogra_> -livefs
[13:45] <ogra_> i see that kubuntu-mobile already has universe enabled in livecd-rootfs
[13:45] <ScottK> It does.
[13:45] <ogra_> so it should be able to find the kernel there
[13:46] <ScottK> So it's mainly the debian-cd work that needs doing?
[13:46] <ogra_> kubuntu hasnt though
[13:46] <ScottK> Ah.  Right.
[13:46] <ogra_> that will likely need more changes
[13:47] <ScottK> How about Ubuntu Headless?  Is that Main only?
[13:47] <ogra_> you need to add a switch for COMP i guess
[13:47] <ogra_> yes, headless is main only
[13:47] <ogra_>         headless)
[13:47] <ogra_>             LIST="$LIST minimal^ standard^"
[13:47] <ogra_>             LIVELIST="$LIVE_BOOT_SCRIPTS"
[13:47] <ogra_>             ;;
[13:47] <ogra_> thats all headless sets as defaults
[13:48] <ScottK> Because if we could just do the mx51 headless image, then I wouldn't worry about the Kubuntu one for this cycle.
[13:48] <ScottK> n900 should be doable already since Kubuntu Mobile already has Universe enabled.
[13:48] <ogra_> headless is completely focused on serial though
[13:49] <ScottK> Right, but if one edits boot.scr before booting it to remove the oem-config preseed, then it should work, right?
[13:50] <ogra_> theoretically yes, untested though
[13:50] <ScottK> For mx51 I'd be willing to try it.
[13:50] <ScottK> (I've got hardware)
[13:50] <ogra_> we currently set console= to serial and preseed debian-installer/framebuffer=false
[13:51] <ogra_> theoretically removing both should get you framebuffer oem-config in debconf mode
[13:51] <ScottK> So if we could get the image built, I could try it and see.
[13:52] <ScottK> If it works, then we can go from there.  I think "If you don't want to work via serial, do X, Y, Z" is not an unreasonable release note.
=== apachelogger is now known as releaselogger
[13:55] <ogra_> do you have a bootloader in the archive ?
[13:56] <ogra_> and a working boot.scr
[14:08] <jibel_> skaet, bug 703230
[14:08] <ubot4`> Launchpad bug 703230 in pango1.0 (Debian) (and 2 other projects) ""rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory" when updating to 1.28.3-4 (affects: 3) (dups: 3) (heat: 79)" [Unknown,Fix released] https://launchpad.net/bugs/703230
[14:11] <ogra_> ScottK, i see u-boot-linaro-efikamx as well as u-boot-linaro-mx51evk ... with which in turn strikes me that livecd-rootfs wont be able to handle a kernel with linaro in the name OOTB, that will need a change too
[14:12] <ScottK> OK.  Sorry.  Got distracted by $WORK.  I'll look at this later.
=== smspillaz|zzz is now known as smspillaz
[16:04] <doko_> skaet, cjwatson: please approve openjdk-6 and openjdk-6b18 (multiarch library path)
=== bjf is now known as bjf[afk]
[16:52] <micahg> are unseeded package uploads still welcome?
[16:55] <cjwatson> micahg: generally yes, though they'll still go through the queue for review and avoidance-of-buildd-load
[16:56] <micahg> ok, also, will the archive be open again after beta or remain moderated, I wasn't sure based on the beta freeze e-mail
[16:58] <cjwatson> https://wiki.ubuntu.com/BetaFreeze clarifies I think
[16:59] <cjwatson> we'll be open for 10 days after beta-1, then hard-freeze for beta-2
[17:00] <micahg> right, that's what I remember from the last 2 cycles, just wanted to make sure something didn't change since we switched to a beta 2
[17:00] <micahg> eh, relatively close at least :)
[17:01] <micahg> cjwatson: you commented last release about sync with Debian uploads, when should those stop, hard freeze?
[17:02] <cjwatson> I did?
[17:02] <micahg> cjwatson: yeah, I uploaded enigmail that just basically merged a Debian changelog
[17:03] <micahg> err, wasn't sync, was a merge
[17:04] <micahg> cjwatson: was this upload: https://launchpad.net/ubuntu/+source/enigmail/2:1.1.2-1ubuntu1
[17:05] <micahg> I'm just wondering where the point is to only sync/merge where we gain something instead of just being in sync or ready for sync
[17:11] <cjwatson> micahg: that sort of tidy-up should only really run up to Debian import freeze IMO
[17:11] <cjwatson> later than that there must be better things to do o:)
[17:12] <cjwatson> substantive syncs are fine whenever a corresponding direct upload with the same change would be, IMO
[17:13] <micahg> cjwatson: ok, will keep in mind for the future, thanks
[17:20] <bdrung> may i upload the ftbfs fix for lintian or should i wait until the beta freeze is lifted?
=== bjf[afk] is now known as bjf
[17:29] <ScottK> bdrung: Go ahead and upload.
[17:29] <ScottK> Worst case it sits in queue.
[17:30] <bdrung> k, done
[17:32] <ScottK> bdrung: The tests you dropped: Did Debian drop them too?
[17:33] <bdrung> ScottK: no, but they are worthless with our two changes
[17:42] <ScottK> bdrung: I don't get the no-upstream-changelog change.  IIRC we are shipping at least partial changelog in all packages.
[17:43] <bdrung> ScottK: some of the test cases produced the no-upstream-changelog warning, but the testcase didn't expected it.
[17:44] <ScottK> Sounds like something that shouldn't be.
[17:45] <zul> robbiew
[17:45] <robbiew> zul: what's up
[17:46] <bdrung> ScottK: look at the test cases. they do not carry an upstream changelog.
[17:46] <ScottK> OK.
[17:46]  * bdrung has to leave now.
[17:46] <ScottK> Did you file a bug with Debian on this?
[17:46] <bdrung> ScottK: not yet, but i will forward it.
[17:46] <ScottK> OK.
[17:46] <zul> robbiew: sorry misfire
[17:47] <robbiew> zul: lol
[17:47] <ScottK> bdrung: Accepted.
[17:50] <cjwatson> parted and dmraid should either go together or not at all
[18:00] <slangasek> robbiew: why the proposal to drop netboot support for !x86? (https://wiki.ubuntu.com/NattyNarwhal/ReleaseImageContacts)
[18:02] <robbiew> slangasek: x86?
[18:02] <robbiew> uh
[18:02] <slangasek> no, !x86
[18:02] <slangasek> :)
[18:02] <slangasek> the netboot images are free as long as we're doing an existing d-i build for the arch
[18:02] <cjwatson> agreed, netboot support should be kept even if there are no testers IMO - it's actively painful to remove them
[18:02] <robbiew> slangasek: I can't test them...and that was a requirement
[18:02] <skaet> slangasek,  no ones signed up to test them,   d-i's will keep building
[18:03] <cjwatson> skaet: I can't make them stop publishing without doing violence to d-i
[18:03] <skaet> cjwatson,  don't want you to
[18:03] <robbiew> "Drop from that wiki page"
[18:03] <robbiew> ;)
[18:03] <cjwatson> where are you proposing to drop them from, then?
[18:03] <cjwatson> I don't understand
[18:04] <skaet> Not publishing them as part of the 11.04 artifacts.
[18:04] <skaet> This is all back to the UDS discussions on not publishing images we don't test.
[18:04] <cjwatson> to where?  you mean http://cdimage.ubuntu.com/netboot/11.04/ or something?
[18:05] <skaet> yes,
[18:05] <cjwatson> (those are just links, sure, they're easy to drop)
[18:05] <skaet> I don't want the dailies to stop.
[18:05] <cjwatson> ok
[18:05] <skaet> :)
[18:06] <doko_> slangasek: while you are at it, please accept openjdk-6 too (and python2.6, python3.1, python3.2)
[18:06] <slangasek> doko_: ack, looking
[18:06] <doko_> only openjdk-6 is on the dvd, but not on the cd's
[18:09] <doko_> will try to get binutils fixed over the weekend
[18:33]  * lamont does another round of armel buildd restoration
[19:17] <ogasawara> cjwatson: I've uploaded linux-2.6.38-7.39, could I get it approved in the queue please?
[19:23] <cjwatson> ogasawara: done
[19:23] <ogasawara> cjwatson: thanks
=== releaselogger is now known as apachelogger
[21:38] <kirkland> FYI ... ^ bikeshed upload I had okay'd with ScottK earlier this week;  I missed a one-liner in the Makefile to get the change to take effect
[21:38] <ScottK> I'll review it.
[21:39] <ScottK> kirkland: Accepted.
[21:39] <kirkland> ScottK: thanks
[21:39] <ScottK> You're welcome.
=== bjf is now known as bjf[afk]
[22:50] <slangasek> pango1.0 in unapproved is a multiarch upgrade-handling fix we'll want for beta
[23:08] <cjwatson> slangasek: accepted; I think we want the same the other way round too?
[23:09] <slangasek> from the plymouth side it just needs to be made more robust wrt these files being missing; plymouth itself shouldn't depend on pango, only plymouth-label does
[23:09] <slangasek> so a bit of tuning is still needed there
[23:10] <cjwatson> well, OK; I just noticed that new plymouth and old pango1.0 broke, and had been meaning to say something about it
[23:11] <slangasek> yeah, we should fix it that way 'round too - I just think a better fix is in order than Breaks
[23:11] <cjwatson> we shouldn't simply ignore those files being missing since that would result in no text being displayed (AIUI)
[23:11] <cjwatson> I suppose we could fall back to the text theme or something
[23:12] <slangasek> not that text gets displayed currently /anyway/ of course
[23:12] <cjwatson> I think Breaks might result in a more consistent user experience though
[23:12] <cjwatson> it gets displayed correctly for me - I can't reproduce that bug, so far
[23:12] <cjwatson> at least IIRC
[23:12] <slangasek> ah - I can reproduce the bug, and will see what I can figure out
[23:13] <cjwatson> that'd be lovely, thanks - plymouth bugs I can't reproduce are no fun at all
[23:13] <cjwatson> I should probably check again mind you
[23:14] <cjwatson> works on nouveau, modulo the need to alt-f1/f7 before it shows anything (which I should investigate, but that's separate)
[23:15] <slangasek> that's with plymouth in the initramfs?
[23:15] <slangasek> it may be that the hook is missing something else for the initramfs case
=== bjf[afk] is now known as bjf
[23:33] <cjwatson> hm, now, I didn't think to try that - no, plymouth is not in the initramfs
[23:35] <cjwatson> I have some time nowish, I'll wedge together an initramfs test case
[23:38] <cjwatson> good call, I think that's it
[23:39] <cjwatson> I don't see the blanked-out areas here like were in the image in the bug, but I don't see text either, having touched /forcefsck
[23:39] <cjwatson> so that should be amenable to strace debugging
[23:44] <slangasek> cool
[23:56] <cjwatson> the effective diff in the grub2 upload (it's a merge, so maybe not trivial to work out which changelog entries matter) is:
[23:57] <cjwatson> - Fix crash when extending menu entry line beyond 79 characters
[23:57] <cjwatson> - Switch back to framebuffer page zero before loading the kernel (basically fixes black-screen that occurred on average 50% of the time when switching VTs on fglrx, and possibly broke other things too)
[23:57] <cjwatson> - Stop grub-setup being really slow if the first partition isn't near the start of the disk
[23:58] <cjwatson> plymouth> looks like missing libGL symlink, am poking
[23:58] <slangasek> \o/