[00:28] <slangasek> ScottK: bit of NBS processing done; all these kernels makes the recommended commandline too long to cut'n'paste at one go, so I'll do another run a bit later, but that should help make it more readable
[04:42] <ScottK> slangasek: Thanks.
[04:52] <ScottK> Wahoo!  KDE 4.5 built on armel for the first time ....
[04:55]  * persia cheers upstream.
[06:45] <GrueMaster> Does anyone know why ubiquity-frontend-gtk-2.3.8 is not building for armel?  It is blocking image builds.
[06:47]  * persia looks, and suggests #ubuntu-devel as a better forum for that class of question in general
[06:47] <persia> Oh, it built.  Just waiting to be published (https://launchpad.net/ubuntu/+source/ubiquity/2.3.8/+build/1935852)
[06:47] <persia> Should be out in a bit.
[06:48] <GrueMaster> ok.  Not sure how the process works.  Since all of the packages come from the same source, I thought they would go at the same time.
[06:50] <persia> So, the source gets processed (NEW/Unaccepted/Accepted), and then gets added to the build queues.  The buildds pull from the build queues whenever they have time (some architectures are faster than others).  When a build finishes, it gets processed (NEW/Unaccepted/Accepted), and then gets published, after which it gets mirrored, after which you can grab it.
[06:52] <persia> Since the buildd queues are all different lengths, and the buildds different speeds, there are often differences between the publication time for different architectures.  This can lead to issues on amd64, armel, and powerpc when there are package relationships between arch:all and arch:any binary packages.  But the assumption is that most folks run i386, where it just works.
[06:52] <GrueMaster> Ok.  All run by cron jobs I would assume.
[06:53] <persia> No.
[06:54] <persia> publication is on cron.  If a package gets caught in NEW or Unaccepted, it's a manual action to get it out (either source or binary).  builds are queued as soon as the sources are processed (I believe this used to be cron, but got changed to avoid the 3-hour delay between upload and availability)
[06:54] <GrueMaster> Hmm.  Well, too much to consume before bed.  I'll manually pull it and install.  Want to see if I can make forward progress before bed.
[06:55] <persia> OK.  I'd expect it to be on ports in ~15 minutes.
[08:43] <ev> KDE ubiquity is busted on today's daily-live.  Seems to be a privileges thing; looking into it.
[08:51] <KE1HA> ev:  saw that on a couple other daily's as well. was told it could be the Artwork uploads doing it.
[08:52] <ev> KE1HA: older KDE ones?
[08:52] <KE1HA> not older ones no, from today.
[08:52] <KE1HA> today being 26th :-)
[08:52] <ev> heh, indeed
[08:52] <ev> which ones, specifically?
[08:53] <KE1HA> Xub and UB alts
[08:53] <KE1HA> amd64
[08:53] <ev> alts?  Alternates?
[08:53] <KE1HA> Yes
[08:54] <ev> ubiquity is not on the alternate CDs
[08:54] <KE1HA> I know.
[08:54] <KE1HA> was the same issue though.
[08:54] <ev> how so?
[08:55] <KE1HA> Hmm good question, I tryng to remember who told be this as said same thing happening on Ubiq iso too.
[08:55] <KE1HA> I stopped testing on the 3rd failed ISO
[08:57] <KE1HA> ev I can't remember who it was, ... that's gonna bug me, it was a developer though, I know that.
[08:58] <ev> what was the exact error you were seeing?
[08:58] <ev> and was this during, or post-install?
[09:00] <KE1HA> I had to try and switch mirrors, and the apt portion failed.
[09:00] <KE1HA> It was during install, never made it to the end.
[09:01] <ev> KE1HA: not sure who told you it was the same bug, but it definitely was not.
[09:02] <ev> the bug I'm describing prevents ubiquity from even starting.  It never makes it to apt-setup.
[09:02] <KE1HA> He didn't say it was Bug per say, but he said it was due to the updates with Artwork.
[09:04] <KE1HA> If yours ins't starting at all, probably unrelated I suppose.
[09:15] <ev> indeed
[10:05] <cjwatson> ScottK: on its way.  I was out yesterday.
[10:05] <cjwatson> oh, needs some work cocoplum-side to make it useful
[10:10] <cjwatson> persia: s/Unaccepted/Unapproved/g in your explanation above, FWIW
[10:11] <cjwatson> ctrl-c'ing the bot to avoid flooding the channel until such time as language packs are out of the queue
[10:12] <persia> cjwatson, Right.  Thanks for the correction.
[11:53] <cjwatson> can people please STOP NBSing old kernels before d-i has been updated to use the new ones?!
[11:54] <cjwatson> I'm getting kind of fed up of spending time debugging problems that turn out to be due to this.
[11:55] <cjwatson> (bug 624915)
[11:55] <ubot4> Launchpad bug 624915 in linux (Ubuntu Maverick) (and 3 other projects) "maverick kvm guests not seeing virtio disks (affects: 1) (heat: 6)" [High,Invalid] https://launchpad.net/bugs/624915
[11:55] <persia> Is there a way to update the NBS script to detect that d-i still needs the kernels?
[11:55] <cjwatson> pretty hard
[11:56] <cjwatson> maybe the people who like to blindly apply its output could do that
[11:56] <persia> heh.  Right.  Doesn't sound worth it to look into the hard bits.
[11:56] <cjwatson> I'm sure it's possible since there's a udeb manifest in the archive
[11:57] <cjwatson> under dists/maverick/main/installer-*/
[12:20] <ogra> can someone let jasper through please (it fixes a hard hang of the omap4 images)
[13:03] <cjwatson> Has somebody been removing old CD build logs from antimony?
[13:04] <cjwatson> Please don't ever do that in future.  Whoever you are, you've made it impossible for me to investigate the exact set of circumstances leading up to bug 597734.
[13:04] <ubot4> Launchpad bug 597734 in debian-installer (Ubuntu) "kernel version mismatch between debian-installer and CD-ROM (affects: 1) (heat: 54)" [Undecided,New] https://launchpad.net/bugs/597734
[13:48] <ScottK> cjwatson: Thanks for the bot.
[16:00] <ScottK> ogra: All the armel build failures for KDE are (finally) fixed.  Once there is room in the queue, it would be good to try and spin an armel image (understanding it's not the priority)
[16:00] <ogra> ScottK, i thought that already happened
[16:00] <ScottK> ogra: Maybe it did.  I didn't look.
[16:01]  * ogra saw someone paste a url somewhere 
[16:01] <ogra> http://cdimage.ubuntu.com/kubuntu-mobile/ports/daily-preinstalled/current/
[16:01] <ogra> (will still be broken until someone approves my jasper-initramfs upload)
[16:07]  * ScottK pushes the big red button.
[16:07] <ScottK> ogra: Accepted.
[16:07] <ogra> sweet, thanks
[16:09] <GrueMaster> omap only?  No omap4?
[16:10] <GrueMaster> or is it still building?
[16:11] <ogra> GrueMaster, if omap userspace works for kde and we know that omap4 kernel/bootloader work in ubuntu we currently save buildd time, i'll enable omap4 builds after beta for kubuntu
[16:11] <ogra> nobody out there can test omap4 atm
[16:11] <GrueMaster> ok
[16:11] <GrueMaster> well, me (assuming we get our images working again).
[16:12] <ScottK> ogra: We don't have an armel image for Kubuntu desktop yet.
[16:13] <ScottK> http://cdimage.ubuntu.com/kubuntu/ports/daily-live/current/
[16:13] <ogra> i think NCommander enabled something in the crontab that just wasnt built yet
[16:16]  * lamont has been shuffling buildds amd64->i386 and back to flush the langpack queue faster
[16:23] <ScottK> ogra: Cool.  I thought he was just working on the kubuntu-mobile stuff, but we'll see.
[17:48] <jdstrand> hey, so avahi is sitting in binary new since it is a merge from Debian. it does not reference a bug-- has someone from ubuntu-release ack'd it?
[17:49] <jdstrand> err, a merge and has a new binary
[17:50] <seb128> it was uploaded  before the freeze not sure it needs a ack from binaries waiting there?
[17:50] <seb128> ie it got blocked in binnew as any packaged having new binaries
[17:51] <jdstrand> well, the version is 0.6.27-2ubuntu1 and we currently have 0.6.25-1ubuntu6
[17:51] <jdstrand> so we seem to be in a gray area, and I thought I'd ask
[17:52] <ScottK> Given how long it's sat, having it sit until after beta may not be a bad idea.  Technically it doens't need a freeze exception though.
[17:52] <jdstrand> ScottK: because of the timing of the upload?
[17:53] <jdstrand> ScottK: ie, it technically doesn't need one because of the timing of the upload?
[17:57] <seb128> jdstrand, well we can't refuse the binaries for maverick
[17:57] <seb128> if we don't want the new version we will need to downgrade the source
[17:58] <jdstrand> seb128: I wasn't suggest refuse the binaries. I was curious about the beta freeze
[17:58] <jdstrand> seb128: and perhaps waiting to accept until after, like ScottK said
[17:58] <seb128> seems there is a soname change so we might as well wait
[17:59] <seb128> not my call
[17:59] <seb128> on one side we might want to test the new version in beta
[17:59] <jdstrand> right, mine either, hence the question here :)
[18:01] <ScottK> jdstrand: Yes.  Because of the timing of the upload.
[18:02]  * jdstrand nods
[18:22] <jdstrand> ScottK: can you look at https://wiki.ubuntu.com/ArchiveAdministration#Archive%20Administration%20and%20Freezes and tell me if it is accurate. I looked at https://wiki.ubuntu.com/FreezeExceptionProcess and it wasn't clear
[18:22] <jdstrand> ScottK: specifically for the universe/multiverse bits
[18:27] <ScottK> jdstrand: I'm about to head out for a while.  I'll try and have a look later.
[18:27] <jdstrand> ScottK: thanks
[19:20] <ev> I'd greatly appreciate it if someone could review and accept the freeze exception for the ubiquity upload I just did.  Bug 625472
[19:20] <ev> Without it, KDE users wont be able to install from the desktop CD.
[19:20] <ubot4> Launchpad bug 625472 in ubiquity (Ubuntu) "Beta freeze exception for 2.3.9 (affects: 1) (heat: 8)" [Undecided,Fix committed] https://launchpad.net/bugs/625472
[20:12] <ScottK> ev: Looks good.
[20:13] <ScottK> Downside risk is nil in any case.
[20:14] <ScottK> Just going to double check with sistpoty since he commented in the bug.
[20:16] <sistpoty> ScottK: actually, I always forget about the exact uid handling, so I wrote a test program... however that actually fails at the setegid(1000)... still not too sure why. so seteuid(0) and setegid(0) seems to do the right thing
[20:16] <ScottK> sistpoty: Are you OK if I accept it then?
[20:16] <sistpoty> ScottK: sure, just go ahead
[20:16] <ScottK> sistpoty: Thanks.  Would you please mark the bug approved.
[20:16] <sistpoty> (and sorry, for not getting my test program right in the first place)
[20:18] <ScottK> I think it delayed things by a full four minutes, so the consequences are pretty severe....  ;-)
[20:18] <sistpoty> heh :)
[20:22] <ScottK> ev: It's in.
[20:41]  * ScottK isn't reviewing ^^^
[20:43]  * sistpoty tries to be invisible
[20:48] <ScottK> jdstrand: I agree it doesn't look quite right (incomplete update when motu-release and ubuntu-release were combined).
[20:57] <ScottK> sistpoty: Would you please read through https://wiki.ubuntu.com/FreezeExceptionProcess and see what you think of the Universe/Multiverse specific things we need to keep?
[20:57] <slangasek> wrt avahi which came up for discussion earlier, the only revdeps of libavahi-core6 in main are from the same source package
[20:57] <sistpoty> ScottK: sure, will do
[20:57] <ScottK> Thanks.
[20:57] <slangasek> so I think it'd be fine to take this now rather than waiting to post-beta
[20:57] <ScottK> slangasek: If you think so, then I'd say go ahead.
[21:01] <GrueMaster> ScottK: The maverick-preinstalled-desktop-armel+omap.img is missing the vfat partition.  This is a bad image.
[21:01] <ScottK> OK.  How do we fix that?
[21:01]  * ScottK looks around for ogra.
[21:01] <GrueMaster> I'm going to try to hack it together with our netbook image to see if it works.  Beyond that, it's an ogra thing.
[21:02] <ScottK> Thanks.
[21:03] <GrueMaster> I should be able to dd the netbook image on, then overwrite the rootfs with the kubuntu one.
[21:07] <sistpoty> ok, got a few points that I'll try to reword. However I'm unsure about: "FeatureFreeze for bugfix-only updates"
[21:08] <sistpoty> the section seems to imply that bugfix only updates are only suitable for universe/multiverse, but I think practice differs... make that section general for all packages?
[21:13] <ScottK> sistpoty: The difference is that in Universe/Multiverse we had a historical practice of requiring a bug to be filed to document it.
[21:13] <ScottK> I think we can drop that now.
[21:18] <sistpoty> *nod*
[21:22] <ScottK> I think there ought to be some discussion about seeded versus uneseeded packages in freezes, but I don't think we need any Universe/Multiverse specfic stuff anymore.
[21:23] <sistpoty> *nod*
[21:24] <ScottK> slangasek: I'm about to head out for a while.  The new ubiquity built and should be in the archive in ~20 minutes.  Would you please kick off Kubuntu live i386/amd64 rebuilds once it is so we can get the installer changes smoke tested?
[21:25] <slangasek> ScottK: ack
[21:25] <ScottK> Thanks.
[21:38] <sistpoty> hmpf, just updated the FFe page in the wiki, and don't find the knob to revert it back to the old version (so that the changes can be discussed on the mailing list, and my bad grammar and spelling can be sorted out)
[21:59] <skaet>  sistpoty, can you bounce me the link to FFe page,  haven't encountered that one yet.
[21:59] <sistpoty> skaet: https://wiki.ubuntu.com/FreezeExceptionProcess
[22:00] <sistpoty> (sorry, should have added that to the mail)
[22:00] <skaet> sistpoty,  thanks!
[22:52] <slangasek> ScottK: kubuntu images rolled
[22:52] <ScottK> slangasek: Cool.  Thanks.  Just got back.
[23:02] <GrueMaster> ScottK: Copying the kubuntu-preinstalled-desktop image over the top of the UNR armel image appears to be working so far.  System is very slow, but I am now in oem-config, which is a good sign.
[23:03] <ScottK> GrueMaster: Cool.  So we just need to get the vfat problem solved and we should be good, right?
[23:04] <GrueMaster> Err, no.  oem-config just crashed.  sigh.  I'll file a bug and get back to you.
[23:05] <GrueMaster> But the vfat issue will need to be fixed for sure.
[23:10] <ScottK> GrueMaster: Thanks.
[23:10]  * ScottK hopes for ogra to appear with a fix.
[23:11] <GrueMaster> he's afk for the day.
[23:11] <ScottK> Surely if we repeat his nick enough he'll reappear.
[23:13] <GrueMaster> It's 12am his time.  Doubtful.
[23:13] <ScottK> Right, then there's also the risk he might not be sober enough to give good advice even if he did appear.
[23:14] <GrueMaster> heh.
[23:24] <ScottK> slangasek: Would you please demote kubuntu-mobile to Universe.  It shouldn't be in Main and (as one might expect) isn't installable just with Main.
[23:26] <GrueMaster> ScottK: http://paste.ubuntu.com/484686/ is the failure, but there is a new version specific to qt/kde.  Will pull that and try again before filing bug.
[23:26] <cjwatson> ScottK: it seems to be seeded for main though
[23:28] <ScottK> cjwatson: A while ago I mailed you about trying to figure out how to build two metapackages out of the same source one for Main and on with Universe.  We never got a chance to discuss it.  No doubt we missed something in trying to set it up.
[23:29] <cjwatson> hmm
[23:30] <cjwatson> don't suppose that mobile could live in a different seed collection, rather than kubuntu.maverick?
[23:30] <cjwatson> that's what drives it
[23:31] <cjwatson> could somebody review debian-installer in the queue?  it's needed to get armel to build
[23:31] <ScottK> Also didn't figure out how to have a metapackage names kubuntu-mobile that wasn't built off of kubuntu-meta
[23:32] <cjwatson> 'Task-Metapackage: kubuntu-mobile' at the top of the relevant seed
[23:33] <ScottK> Right.  Some things are too obvious.
[23:33] <ScottK> OK.  I'll work on that.
[23:39] <ScottK> cjwatson: I'll take care of accepting D-I.
[23:39] <cjwatson> thanks
[23:40] <ScottK> Done.  That's probably the one time ever D-I will have a trivial enough diff for me to be confident reviewing it.
[23:41] <ScottK> GrueMaster: That smells like somethe the latest updates should fix.
[23:56] <ScottK> cjwatson: No doubt you know, but it FTBFS on armel.
[23:56] <persia> Wouldn't moving kubuntu-mobile to a new seed require landing a patch to cron.germinate in LP?
[23:56] <persia> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head:/cronscripts/publishing/cron.germinate