[01:22]  * infinity self-accepts his libd-i 1-liner.
=== henrix_ is now known as henrix
[07:00] <tseliot> hi, can an admin please reject fglrx-installer-updates from precise-proposed?
[07:47] <dbarth> Riddell: hey Jonathan, mardy file https://launchpad.net/bugs/1378660 to clarify the purpose of the signon changes from yesterday
[07:47] <ubot2> Launchpad bug 1378660 in signon (Ubuntu) "Notification appears when applications need to be (re-)authorized" [Undecided,In progress]
[07:48] <dbarth> or anyone in the release team willing to approve the signon package upload in the unapproved queue
[07:48] <dbarth> thanks
[08:03] <Riddell> dbarth: accepted, thanks for the extra info
[08:03] <Riddell> dbarth: this is surprising given the qt build-deps :) "Section: gnome"
[08:05] <tseliot> Riddell: can you reject fglrx-installer-updates from precise-proposed, please?
[08:06]  * Riddell looks
[08:09] <Riddell> tseliot: rejected!
[08:10] <tseliot> Riddell: thanks a lot :)
[08:19] <dbarth> Riddell: thank you
=== doko_ is now known as doko
[10:10] <cjwatson> infinity: nice catch on libd-i.  did you send that to Debian too?
[10:10] <cjwatson> suspect they'd want it
[13:20] <jamespage> Laney, could you take a peek at https://bugs.launchpad.net/ubuntu/+source/ceilometer/+bug/1377218
[13:20] <ubot2> Launchpad bug 1377218 in ceilometer (Ubuntu) "[FFe] ceilometer 2014.2.rc1" [High,New]
[13:20] <jamespage> and that would be for rc2 now; upstream just popped a new one with some fixes
[13:38] <Riddell> any ubuntu-sru people around able to give a second opinion on bug 1378789 ?
[13:38] <ubot2> bug 1378789 in kubuntu-settings (Ubuntu Trusty) "[SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty" [Undecided,New] https://launchpad.net/bugs/1378789
[13:38] <Riddell> we want to sru the change in schduler back to linux defaults to keep baloo indexer working
[13:42]  * Riddell eyes up stgraber as a desktop minded sru member ↑
[14:34] <ogra_> stgraber, something is wrong with system-image mirroring to the external server ...
[14:35] <ogra_> stgraber, i see a krillin 91 image in www/full/ubuntu-touch/ubuntu-rtm/14.09-proposed/krillin/ ... since quite a while ... but http://system-image.ubuntu.com/ubuntu-touch/ubuntu-rtm/14.09-proposed/krillin/ doesnt seem to get it
[14:37] <ogra_> stgraber, i even ran sync-mirrors manually on nusakan (assuming thats what s-i does as well) but with no result
[14:42] <infinity> rtg: The latest linux-firmware doesn't appear to contain the fix for LP: #1378491
[14:42] <ubot2> Launchpad bug 1378491 in linux (Ubuntu Utopic) "Utopic netboot initrd missing bnx2x firmware" [Undecided,Fix committed] https://launchpad.net/bugs/1378491
[14:43] <infinity> rtg: What gives? :)
[14:43] <rtg> infinity, it was a kernel fix, which I have not uploaded yet.
[14:43] <rtg> bnx2x is boot essential, so it gets packaged with the kernel.
[14:44] <infinity> rtg: Oh, err.  Really?  But nic-firmware.udeb comes from linux-firmware.  Is this particular one in kernel-image.udeb?
[14:44] <infinity> rtg: Check, okay.
[14:44] <infinity> slangasek: ^-- kernel fix, not l-f fix, will get done in the usual d-i respin for the new kernel.
[14:44] <rtg> infinity, I'll likely wrap it up and upload later tonight, or tomorrow. I did update the LP bug
[14:45] <infinity> rtg: Yeah, I missed that it was assigned to linux, cause someone implied it was l-f, not naming any names. :)
[14:47] <infinity> rtg: I guess maybe we need some machinery to check linux-image.deb and kernel-image.udeb for firmware inconsistencies and bail?  If the argument for firmware in linux-image is that it's "boot essential", I can't see how that would be any less valid for the installer package.
[14:48] <rtg> infinity, put that on your list of things to talk to me about next week. I have some questions about how we're doing that kind of firmware, but I'm in a class right now and kind of distracted.
[14:49] <infinity> rtg: *nod*
[14:50] <infinity> rtg: Oh, I guess my consistency check wouldn't help here, as that firmware wasn't in either package. :P
[14:50] <infinity> And perhaps you're already doing the right thing and installing the same firmware to both packages.
[14:50] <rtg> infinity, nope, it was only in linux-firmware
[14:51] <infinity> At least, I hope you are, cause this commit doesn't seem to have anything udeb-specific.
[14:51] <rtg> infinity, yup, its in both now, but I'd like to fix that.
[14:52] <infinity> rtg: Sorry, I meant "both" as in linux-image and kernel-image, not talking about linux-firmware at all.
[14:52] <infinity> rtg: As in, I assume/hope that all firmware in linux-image.deb is also in the kernel-image.udeb
[14:53] <rtg> yes (IIRC). I'll check for sure later, but I think our packaging is consistent
[14:53] <infinity> rtg: Oh, hrm.  No, looking at the packaging, this probably should be in nic-modules.udeb, which is defined at tree/debian.master/d-i/firmware/nic-modules
[14:54] <infinity> rtg: So that goes back to the consistency check arguments, I guess.  We should ensure that the intersection of kernel-image, nic-modules, and scsi-modules contains the same firmware as linux-image+linux-image-extra.
[14:55] <infinity> rtg: Anyhow, this bug (which was agaisnt d-i) won't be fixed by your commit, as I read this.  I think.
[14:55] <rtg> infinity, my patch is consistent with previous bnx2x firmware packaging. I'm pretty sure it'll fix the netboot issue.
[14:56] <infinity> rtg: Previous bnx firmware is listed in the file I pointed out.
[15:01] <slangasek> infinity: ah oops yes, I knew that and misspoke
[15:05] <infinity> cjwatson: Haven't committed that to Debian yet, as I wanted to actually do an end-to-end test and see what else is broken. :P
[15:06] <infinity> cjwatson: Which is somewhat hampered by the utopic kernel bumping off my test machine fairly reliably.
[15:11] <sil2100> slangasek: hey, do you know why the release of indicator-network for utopic that we just triggered through the train got put into the unapproved queue?
[15:11] <sil2100> slangasek: common sense told me indicator-network is not touch-specific, but I see it in my FFe I filled in
[15:11] <sil2100> slangasek: which means it has to be touch-specific
[15:12] <slangasek> sil2100: everything goes in the unapproved queue, some things are just supposed to be let back out again semi-automatically
[15:13] <slangasek> sil2100: indicator-network is only in ubuntu-desktop-next and ubuntu-touch, so it's ok to unblock; but if things are getting stuck in the unapproved queue when they shouldn't, I think that's a question for #ubuntu-release
[15:13] <slangasek> oh, we're on that channel
[15:13] <slangasek> I think it's a question for infinity or stgraber ;)
[15:13] <sil2100> Yeah ;)
[15:13] <sil2100> infinity: ^ can you help here?
[15:14] <slangasek> sil2100: ^^ accepted in the meantime
[15:14] <sil2100> Thanks!
[15:14] <slangasek> but the underlying "why'd it stick" should be looked at
[15:15] <infinity> The python script that does auto-accepts is a bit dumb, IIRC, and only looks at the moral equivalent of "seeded-in-ubuntu" without actually checking which seeds/packagesets something is in.
[15:15] <infinity> We should probably make it smarter, but also entirely reasonable to just give us a poke with "hey, this is only in touch, can you let it through?"
[15:16] <infinity> sil2100: ^
[15:16] <Laney> It has a whitelist
[15:16] <infinity> Oh, so it does.
[15:16] <infinity> Hrm.
[15:16] <infinity> Clearly, that's not working right. :P
[15:17] <infinity> slangasek: Did you just accept everything in that state? :/
[15:18]  * infinity was hoping for something in the queue he could manually run against.
[15:18] <Laney> It'll be because it's in the ubuntu-desktop packageset
[15:18] <sil2100> infinity: ok, thanks :)
[15:18] <infinity> Laney: Ahh, that would perhaps do it.
[15:18] <sil2100> infinity: not sure who approved those, but those were anyway safe to land as they only had touch-specific things in them
[15:19] <infinity> sil2100: Some of those were auto-accepts (ie: working as designed) :)
[15:19] <sil2100> Yay, well - I already knew that the auto-accept worked as I saw unity8 smoothly migrating just a moment ago, but yeah ;)
[15:23] <slangasek> Laney: then it sounds like keying on packageset for the queue autoaccept is the wrong thing to do?
[15:23] <Laney> I asked about that a few days ago
[15:24] <infinity> slangasek: We've generally considered it the right thing to do because "in a packageset" maps nicely to "might want extra eyes on it".  Images aren't the only thing that matter.
[15:25] <infinity> slangasek: But this specific case is a bit more special.  If only a couple of indicators are in this boat, we can just whitelist the packages for now.
[15:25] <Laney> Not sure why indicator-network is in ubuntu-desktop, mind you
[15:25] <Laney> Lemme re-run the script and see if it changes
[15:26] <slangasek> infinity: "might want extra eyes on it" is not the same thing as "should be frozen".  Isn't everything in main in one packageset or another?
[15:28] <infinity> slangasek: I'm not disagreeing, just stating that stgraber's original design was meant to be more conservative than permissive, I believe.
[15:29] <infinity> Better to review a few extra packages than to have people break things that we really don't want broken.
[15:29] <infinity> But I'm sure this could use some fine-tuning.
[15:43] <Laney> oh
[15:44] <Laney> There's an ancient (2010-07-08) exception putting indicator-network in ubuntu-desktop
[15:44]  * Laney zzzap
[15:47] <jibel> there is no desktop image since yesterday. CD build fails with cp: cannot stat `boot1/isolinux/lang': No such file or directory
[15:47] <jibel> make: *** [/srv/cdimage.ubuntu.com/scratch/ubuntu/utopic/daily-live/tmp/utopic-i386/bootable-stamp] Error 1
[15:47] <jibel> could anyone look at it?
[15:49] <elfy> jibel: I'm assuming that all the other images would have the same error
[15:49] <infinity> syslinux broken?  What a shock.
[15:50] <infinity> ... except it hasn't been uploaded since June.
[15:50] <infinity> jibel: Will look into it in a bit.
[15:59] <jibel> infinity, it could be the fix for bug 1334189 ?
[15:59] <ubot2> bug 1334189 in Ubuntu CD Images "pre-boot menu offers no OEM mode on Utopic live images" [Critical,Fix released] https://launchpad.net/bugs/1334189
[16:01] <infinity> jibel: Could well be.  Haven't had a chance to look yet.  Usual morning headless chickening routine.
[16:01] <jibel> infinity, or more likely r1899
[16:09] <cjwatson> infinity,jibel: yeah, my code, I'll fix
[16:09] <cjwatson> bah etc.
[16:10] <cjwatson> ah inverted logic
[16:10] <infinity> cjwatson: Ta.
[16:10] <jibel> cjwatson, thanks
[16:11] <cjwatson> fixed || → &&, sorry about that
[16:28] <stgraber> ogra_: sorry, I'm on vacation until Friday. system-image doesn't use sync-mirrors but every run of import-images calls the ssh sync, so try running bin/import-images manually (as cdimage) and if that doesn't print an error message then it's something wrong on IS' end
[16:28] <ogra_> stgraber, yeah, all solved ... nusakans / was full
[16:29] <stgraber> ogra_: oh, right, that doesn't help and I suspect system-image was making it worse by trying to create a bunch of stuff in /tmp
[16:29] <ogra_> heh, yeah, seemingly
[16:29] <stgraber> I should make that configurable so we can use /srv/system-image.ubuntu.com/tmp or something like that instead of /
[16:29] <ogra_> but now all is fine
[16:29] <ogra_> i guess that can wait til after your vac. ;)
[16:30] <stgraber> yeah
[16:49] <ogra_> hmm
[16:49] <ogra_> the last two images expose the same issue but nusakan does have plenty of diskspace
=== bjf[afk] is now known as bjf