[00:18] <slangasek> infinity: how far out is d-i looking?
[00:20] <infinity> slangasek: Kernels are still several hours out, then promotion to -release, then d-i.
[00:20] <infinity> slangasek: So, it's a "when I wander past my computer tonight" thing.
[00:21] <slangasek> infinity: ok
[00:22] <skaet> if it gets to be morning time for europe,  check if app-install-data-ubuntu is close to being published before kicking off the builds
[00:22] <infinity> Perhaps I'll go find some dinner between now and then.
[00:22]  * skaet thinking dinner might be a good idea for herself too...
[00:22] <infinity> skaet: Are we expecting a new app-install-data-ubuntu sometime?
[00:25] <skaet> infinity,  mvo kicked off the scripts for it earlier
[00:25] <skaet> it should show up on the link in the pad,  when done.
[00:26] <infinity> skaet: Well, when someone uploads it, yes. :P
[00:26] <skaet> if its close to morning,  may be worth checking with mvo how close it actually is to publishing, and hold up for it.
[00:26] <skaet> infinity,  was under the impression his script will do that,  but I could have misunderstood.
[00:27] <infinity> skaet: If his script automates signing and uploading it, a few of us will likely tell him to stop that. :P
[00:27] <infinity> skaet: But I'm pretty sure it just generates a source package that he still manually gives a once-over and uploads.
[00:27] <stgraber> just what I was about to say ;)
[00:28] <skaet> infinity,   ok.
[00:28] <skaet> if he's online,  ask how close,  if not, go ahead and get some images started building
[00:29] <skaet> or rather you, slangasek, myself, or who ever's still up when the d-i bits publish
[00:30] <infinity> slangasek or Laney, according to the wiki.  I'm perfectly happy to pretend not to care about images this month. ;)
[00:30] <infinity> (But I'll make sure the kernel and d-i are ready for those who are doing releasy things)
[00:31] <phillw> i promise to book mark it... do you have the pad link for ubuntu-release ?
[00:32] <skaet> infinity,  thanks.
[00:32] <phillw> is okay.. found it :)
[01:02]  * skaet just cleaned up some stale data on https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive 
[01:17] <infinity> skaet: Tidied a bit more.
[02:15] <skaet> hmm,   I was stimied a bit on armel since it is still an official arch for natty and oneiric, and would show up in the archive that way.    We may want to restructure this part a bit more for clarity about which archs are official for which releases, but what's there will do for now.    thanks.
[02:29] <infinity> skaet: "show up in the archive that way", in what sense?
[02:29] <infinity> skaet: The archive makes no distinction.
[02:30] <infinity> skaet: And there's a list of which arches as they come in and out of officialness on that page, more or less.
[02:30] <infinity> skaet: (Frankly, the only people who care if natty and oneiric were official on armel are paid customers, and they already know :P)
[02:30] <micahg> skaet: FYI, https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures
[02:31] <skaet> infinity,   lets just redirect that section to point to the link micahg points to.   That's much clearer.
[02:32] <infinity> Except that the first line of that wiki section is also a lie. :)
[02:33] <micahg> that's true :(
[02:34] <infinity> It also says nothing about what's *currently* supported, which is probably more interesting.
[02:34] <infinity> (please give me edgy security fixed for powerpc, thx)
[02:35] <micahg> infinity: see footnote 1 :)
[02:36] <infinity> Oh.  That's tiny.
[02:36] <infinity> BOLD AND RED!
[02:38] <micahg> I'll suggest it :)
[02:38] <skaet> infinity,  by shows up in the archive,  I just meant it builds to armel not armhf for specific releases.  In past manifests we didn't separate between armel vs. armhf,  just used arm, so it may be confusing.  see:https://wiki.ubuntu.com/OneiricOcelot/ReleaseManifest
[02:40] <micahg> skaet: yes, in precise: https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest
[02:40] <micahg> ah, right no armel ther
[02:40] <micahg> oh, yes there is :)
[02:40] <skaet> micahg, actually there is armel in precise's
[02:40] <infinity> skaet: Turns out that's a wiki and can be edited. ;)
[02:41] <infinity> skaet: Anywhere where it matters from an archive perspective, armel is armel.
[02:41] <skaet> infinity,  all the ones we're talking about are wiki's...   just a matter of finding them all,  and doing the edits to make them consistent.  ;)
[02:41] <infinity> (And always was)
[02:42] <skaet> and yes,  archive is the one place we can't change.  ;)
[02:42] <infinity> And also the one place that's right?
[02:42] <infinity> :P
[02:44] <skaet> hmm...   definition of right seems to change with time.    when there was only arm variant,  calling it armel then may have been confusing.  :P
[02:45] <ScottK> It depends on how much of the history you have.
[02:45] <ScottK> There was a Debian arm port before armel.
[02:45] <ScottK> (never in Ubuntu)
[02:46] <ScottK> But given that history, calling armel arm was always wrong, IMO.
[02:48] <skaet> Looks like the only two Release Manifests with it as arm rather than armel are Natty and Oneiric.
[02:49]  * skaet figures may as well clean them up then.
[02:49] <skaet> so there's consistency there.
[02:56] <skaet> Natty & Oneiric Manifests are now consistent with the rest.    armel used in all.
[02:57] <infinity> skaet: Yeah, it was never right to call it just "arm".
[02:58] <skaet> infinity,  none of the folks doing line sign offs flagged it.  :P
[02:59] <infinity> To be fair, they were mostly management.
[03:11] <micahg> skaet: sorry, I seemed to have spaced on some needed Ubuntu Studio uploads, mind if I do them now?  (all smallish packages and mostly arch all)
[03:12] <skaet> micahg,  we're still waiting for d-i so go ahead.     Hopefully they'll all be sorted by the time ubuntu studio starts to build.
[03:13] <micahg> skaet: is that still 18:00 UTC?
[03:13] <micahg> or will this be a manually triggered build?
[03:13] <skaet> micahg, no,  we're off cron now,  manual triggered
[03:13]  * micahg will try to get it sorted in the next hour as sleep is calling
[03:14] <skaet> please log them on pad.ubuntu.com/ubuntu-release as opportunity targets if they don't go in, in next hour.
[03:19] <micahg> ok
[03:52] <micahg> ok, studio default settings upload, spinning up the -meta upload now
[04:00] <micahg> ok, new Ubuntu Studio meta uploaded, I think that's it unless there are bugs found
[04:06] <skaet> thanks micahg
[04:08] <micahg> skaet: also, xubuntu is horribly oversized, don't know if I'll have an answer tonight though
[04:09] <infinity> micahg: Drop the kernel, that'll solve it.
[04:09] <micahg> heh
[04:10] <micahg> ah, awesome, Qt got pulled in somehow
[04:11] <infinity> ubuntuone?
[04:11] <micahg> idk, looking
[04:11] <infinity> Hrm, no, that only seems to be in Ubuntu.
[04:12] <micahg> thunar-archive-plugin recommends ark
[04:12] <infinity> That's a remarkably silly recommends.
[04:12] <infinity> If you want to fix it, go nuts.  Still two more publisher cycles until d-i's ready.
[04:12] <infinity> Or, rather, two more until I can upload it, 3 more until it's ready.
[04:13] <micahg> it's an alternate recommends, that's easily clobbered...continuing to look
[04:13] <skaet> infinity, looks like the kernel's finished building,     d-i upload?
[04:13] <infinity> skaet: See above.
[04:13] <micahg> ah, that's not it
[04:15] <micahg> infinity: fglrx depends libqtcore4
[04:15] <infinity> Hasn't it always done so?
[04:16] <micahg> hrm, yes...
[04:16] <skaet> slangasek,  still around?
[04:16] <micahg> and that's not on the image
[04:16] <infinity> I didn't realise Xubuntu shipped non-free drivers.
[04:16] <infinity> Yeah, exactly. :P
[04:20] <skaet> Laney,  if slangasek doesn't chime in before you get online,  looks like you'll get to build the first set.
[04:20]  * skaet --> zzz
[04:21] <micahg> ubuntu-sso-client-qt looks to be the real culprit, blacklisting
[04:22] <infinity> micahg: How's it coming it?
[04:22] <micahg> see above :)
[04:22] <infinity> micahg: I don't see an above explaining where ubuntu-sso-client-qt is coming from. :)
[04:23] <micahg> infinity: ubuntu-sso-client recommends ubuntu-sso-client-gui (qt is the only choice now)
[04:23] <infinity> Ahh, erk.
[04:23] <infinity> You should petition to resurrect the GTK one.
[04:26] <micahg> hrm, I like Qt personally...
[04:27] <micahg> how often are the germinate-output crons generated?
[04:28] <micahg> s/generated/run/
[04:32] <infinity> micahg: Not often, but nothing important uses that output.
[04:32] <infinity> micahg: Or did you just want to see it, so you could be lazy and not run it locally? :)
[04:32] <micahg> infinity: I just wanted to verify my work :)
[04:32] <infinity> 2 */4 * * *             update-germinate
[04:32] <infinity> I can force the issue.
[04:32] <micahg> ok, so I can check in the morning
[04:32] <micahg> nah, I should go to bed
[04:32] <infinity> Yeah, speaking of.
[04:33] <infinity> Publisher's going to run over by a couple of minutes. >:(
[04:33] <infinity> I should just do my d-i upload on a sleep(1) delay and go do something else.
[04:53]  * slangasek appears
[04:54] <infinity> slangasek: Did you bring cookies?
[04:56] <ScottK> micahg: They're dumping the Uone installer, so I think shipping the client-gui will be the only supported way.
[04:56] <slangasek> infinity: no, but I'm chiming in, so <tinkle,tinkle>
[04:56] <micahg> ScottK: well, IIRC, Xubuntu doesn't ship the U1 client anyways
[04:57]  * slangasek blinks at two new linux flavors appearing in component-mismatches
[04:57] <ScottK> OK.  Then I'm confused about what this issue was, but that's fine.  I don't need to understand it.
[04:57] <ScottK> slangasek: We're not in final freeze, so they're early.
[04:58] <infinity> slangasek: Hrm?  You mean the -5 stuff that's NBS?
[04:58] <slangasek> ScottK: one of them's for the n900, so I'd argue it's 3 years late ;P
[04:58] <ScottK> Well sure.
[04:58] <infinity> Oh, the two heading to main.  Wow.
[04:59] <ScottK> Maybe I'll have something to do with my n900 besides let it collect dust.
[04:59] <slangasek> infinity: linux-n900, linux-qcm-msm; strangely being pulled in via open-iscsi-udeb, vlan-udeb - either a buggy dep declaration, or a c-m bug
[04:59] <infinity> slangasek: That's probably just an oops from having no kernels seeded to main for a second.
[04:59] <micahg> ScottK: Xubuntu ships software-center which needs oneconf which needs ubuntu-sso-client which recommends ubuntu-sso-client-gui of which there is only Qt now
[05:00] <ScottK> I see, but it doesn't need a gui?
[05:00] <infinity> slangasek: (In that I bumped the seeds for the mainline kernel to the new version before it was published)
[05:00] <micahg> ScottK: no, it has the GTK gui in it apparently
[05:01] <ScottK> I see.
[05:02] <slangasek> infinity: ah
[05:03] <infinity> NCommander: What was wrong with backporting the quantal highbank d-i support, instead ot rewriting it? :/
[05:33] <infinity> Alright, d-i uploaded for both quantal and precise, that's EOD for me.
[05:35]  * slangasek waves
[05:36] <infinity> slangasek: If you feel like reviewing the precise-proposed d-i, that would be lovely.
[05:36] <slangasek> ok
[05:36] <infinity> slangasek: Or, you could wait until the quantal one builds successfully and appears to publish things to sane paths, since the precise one is the same code. :P
[05:37] <slangasek> mmm, amd64+i386 d-i builds just failed with a "disk full" error generating the netboot images
[05:38] <infinity> Oh, FFS.
[05:38] <infinity> New firmware again? :/
[05:39] <slangasek> no idea
[05:39] <infinity> Yeahp, new firmware.
[05:40] <infinity> Although, not a lot.
[05:40] <infinity> Kernels might have grown too.
[05:41] <slangasek> the fix for which is... to bump the fs size?
[05:41] <infinity> I need to change the Makefile to give me the *^!% size of vmlinux and initrd after it trips over it.
[05:41] <slangasek> are you fixing this up, or do you want me to?
[05:42] <infinity> I can fix it.  Want to wait for the world to fail, first.
[05:42] <slangasek> ok
[05:43] <slangasek> Laney: fyi, looks like you get to kick off the builds from the pad then; I don't think I'll be around still when d-i catches up
[05:46] <infinity> Actually, I might leave the d-i image size bump to someone else.  I need to try to not be awake at night tonight.
[05:49] <slangasek> ok
[05:49] <infinity> And it wasn't firmware growing, same version of firmware was used in the previous d-i builds.
[05:49] <infinity> So, I guess the kernel grew just a bit.
[05:49] <infinity> Or a lot.
[05:51] <infinity> Or maybe everything's just been slowly growing by enough to finally hit the limit again.  Don't see any obvious explosions.
[05:52] <infinity> Meh.
[05:52] <infinity> Maybe I'll just fix it.
[05:53]  * infinity wonders idly why the powerpc image appears to be growing in base10 units, and the x86 ones in base2...
[05:56] <infinity> slangasek: Testing a fix here.
[05:57] <slangasek> ok
[05:59] <jibel> with the new format of server images, sources.list only contains cdrom entries. filing a bug
[06:10] <infinity> slangasek: The good news is that the highbank stuff from the last build spit out the way I expected it to.
[06:10] <infinity> slangasek: So, as soon as these amd64 and i386 local builds complete, I'll commit, upload, and go away. :)
[06:21] <slangasek> infinity: sounds like a plan then :)
[06:23] <infinity> (uploaded and building)
[07:37] <Laney> howdy
[07:50] <Laney> we building all flavours for a3?
[08:11] <jibel> bug 1028301 with server 20120723.2
[08:11] <ubot2> Launchpad bug 1028301 in debian-installer "Quantal Ubuntu Server - sources.list only contains cdrom entries after a preseeded installation" [Undecided,New] https://launchpad.net/bugs/1028301
[08:21] <pitti> hello
[08:21] <pitti> I fixed bug 1026066, I think that ought to go into alpha-3
[08:21] <ubot2> Launchpad bug 1026066 in aptdaemon "software-properties-gtk crashed with ImportError in /usr/lib/python3/dist-packages/aptdaemon/client.py: No module named gobject" [Critical,Fix released] https://launchpad.net/bugs/1026066
[08:21] <pitti> it breaks update-manager, software-properties, and presumably lots of other stuff
[08:28] <Laney> agreed
[08:40] <jibel> added to the pad. does it affect kubuntu ?
[09:18] <Riddell> hmm I don't know
[09:21] <Riddell> but since we have no candidate images yet then may as well wait for that
[09:24] <cjwatson> Why is bug 1026964 listed as a rebuild trigger?  It's a suspend/resume bug, importance medium, not tagged rls-q-anything.  I don't see why we'd care particularly about it for image builds?
[09:24] <ubot2> Launchpad bug 1026964 in linux "Lenovo T410s laptop suspends fine, won't resume any more" [Medium,Triaged] https://launchpad.net/bugs/1026964
[09:25] <jibel> could be a confusion with bug 1027828 which was fixed in kernel 3.5.0-6.6
[09:25] <ubot2> Launchpad bug 1027828 in linux "[Quantal] black screen on resume on 3.5.0-5.5 (regression from 3.5.0-4.4)" [High,Fix released] https://launchpad.net/bugs/1027828
[09:27] <cjwatson> Seems more plausible.  I've changed the pad.
[09:27] <jibel> I added a comment to the report
[09:37] <ogra_> Laney, is there any reason you dropped all the arm precise preinstalled lines from default-arches ? you have to explicitly call a preinstalled build anyway so nothing would attempt to build them unless you say so
[09:38] <ogra_> (having the entry helps to keep track what arches were built when, even though nothing uses this entry)
[09:39] <Laney> ogra_: I was advised to do so by slangasek.
[09:39] <ogra_> hmm, k
[09:40]  * ogra_ doesnt get why though, its just historical data and doesnt do any harm
[09:43]  * cjwatson fixes ubuntu-server/precise
[09:47] <ogra_> cjwatson, is server completely switched to squashfs now ?
[09:48] <cjwatson> ogra_: ubuntu-server/daily is
[09:48] <ogra_> ok
[09:48] <cjwatson> ogra_: just for the base system though
[09:48] <ogra_> so we are depending on the live builder with it ... thats what i wanted to know
[09:48] <cjwatson> no plans to go beyond that in quantal
[09:49] <ogra_> (bottlenecks etc :) )
[09:49] <cjwatson> it's best looked at as a cached debootstrap (although it actually has the server seed in there too)
[10:04] <cjwatson> Any objection to me rebuilding world after the next publisher run completes (which will be in ~1hr since we're in the fastdowntime window)?  I believe all the rebuild triggers are at worst pending publication.
[10:25] <jibel> +1 to rebuild the world
[10:26] <ogra_> as long as you keep the weather do what you want with the world :)
[10:46] <Daviey> cjwatson: rebuild would be good
[11:15] <cjwatson> rebuilding
[11:21] <cjwatson> Hah, the health checks are really pretty confused by squashfs-base.
[11:21] <cjwatson> I may have to turn the installability check off for server unless I can think of something clever.
[11:23] <cjwatson> Which I suppose isn't totally out of the question; maybe I can bodge something using the manifest ...
[12:12] <ogra_> hmm, apt-setup failures on omap4 server
[12:23] <ogra_> cjwatson, is there any way to convince live-installer to not call update-initramfs ?
[12:23] <cjwatson> ogra_: are we talking performance or what?
[12:23] <ogra_> it calls it before flash-kernel-installer is done (which runs apt-install u-boot-tools)
[12:23] <ogra_> so it fails missing the mkimage command
[12:24] <cjwatson> it's in the console-setup hook, I think, but let me check
[12:24] <ogra_> i cant find a debconf key for supressing update-initramfs in live-installer :/
[12:24] <cjwatson> it'll need (a) me to think about it (b) code changes
[12:24] <cjwatson> hang on a bit :)
[12:24] <ogra_> need a log ?
[12:25] <ogra_> its slightly confusing that the actual failure shown is in apt-setup ... which fails since in-target didnt return properly
[12:25] <cjwatson> wouldn't hurt but I was just doing a test install here, so if it's >0 effort don't worry about it
[12:26] <ogra_> http://paste.ubuntu.com/1108095/
[12:27] <ogra_> logger thinks its from live-installer
[12:27] <cjwatson> right, yeah, the c-s hook
[12:27] <ogra_> Jul 24 12:09:08 base-installer: warning: /usr/lib/post-base-installer.d/25live-installer-console-setup returned error code 1
[12:27] <ogra_> yep
[12:28] <cjwatson> surprised you didn't have the same problem with trad base-installer though
[12:29] <cjwatson> you know, you could fix this in f-
[12:29] <cjwatson> k
[12:29] <cjwatson> if you wanted
[12:29] <ogra_> how, i cant hard depend on u-boot-tools
[12:29] <cjwatson> just have it do the apt-install earlier, say in a base-installer hook
[12:29] <ogra_> sicne f-k deals with lots of other bootloaders too
[12:29] <cjwatson> would involve splitting it up a bit
[12:30] <cjwatson> it'd need some care with where you move flash-kernel out of the way
[12:30] <ogra_> how about calling flash-kernel-installer as part of live-installer ?
[12:31] <cjwatson> how about not :-P
[12:31] <cjwatson> (I would very much rather live-installer not have to know about f-k)
[12:31] <ogra_> why not? we need the bootloader setup anyway
[12:31] <cjwatson> layering
[12:31] <ogra_> so we could as well do it early
[12:31] <ogra_> hmm, k
[12:32] <cjwatson> the hooks are available so it's not necessary, anyway
[12:33] <cjwatson> I mean, if you want flash-kernel-installer to run as a live-installer hook, be my guest, but you're still going to need to leave flash-kernel-installer.postinst in place and figure out a way for it to notice that it's already been called
[12:33] <ogra_> well, calling it twice wouldnt do any harm
[12:33] <cjwatson> I just don't think we should change live-installer for it
[12:33] <ogra_> apart from wasting time
[12:34] <cjwatson> there's /usr/lib/live-installer.d/ though
[12:34]  * ogra_ was pondering about post-base-installer.d/20live-installer-flash-kernel
[12:35] <cjwatson> live-installer.d is better, I think - this flow is specific to live-installer so better to use a hook that's also specific to live-installere
[12:35] <cjwatson> *live-installer
[12:35] <ogra_> ok
[12:35] <cjwatson> let me just check where direct apt-install is enabled
[12:36] <ogra_> hmm, but live-installer.d has no ordering
[12:36] <cjwatson> never mind that, bigger problem
[12:36] <ogra_> how do i make sure f-k is done before update-initramfs
[12:36] <ogra_> oh ok
[12:36] <cjwatson> never mind that
[12:36] <cjwatson> apt-install only queues until install_extra is run
[12:36] <cjwatson> which isn't until after post-base-installer.d hooks are run
[12:36] <cjwatson> so this approach is a non-starter whatever way you slice it
[12:37] <ogra_> :(
[12:37] <ogra_> yeah
[12:38]  * ogra_ wonders if there is a way to just solve it thgrough seeding ... but i guess that would mean all arm images end up with u-boot-tools again
[12:38] <ogra_> *through
[12:38] <cjwatson> I think I have a better idea
[12:40] <cjwatson> just fleshing out the details
[12:40] <ogra_> k
[12:40] <cjwatson> add a post-base-installer.d hook with an early number (say 01) that dpkg-diverts update-initramfs and installs a symlink to /bin/true in its place
[12:41] <cjwatson> (put that in the flash-kernel-installer udeb)
[12:41] <cjwatson> then undo the diversion in flash-kernel-installer.postinst, just before you call update-initramfs
[12:41] <cjwatson> actually probably before the apt-install calls so that the nslu2-utils case mentioned there still works (although I realise that doesn't matter for Ubuntu)
[12:42] <cjwatson> that means we don't have to play whack-a-mole with anything that might indirectly call update-initramfs
[12:42] <ogra_> ok, doesnt that also need a dep to live-installer in flash-kernel-installer ?
[12:42] <cjwatson> I don't see why - it would work just as well with the other style of base system installation
[12:42] <ogra_> ah, well, if it isnt there the file will be a no-op
[12:42] <ogra_> yeah, thinko :)
[12:43] <cjwatson> it would probably speed things up a bit
[12:43] <cjwatson> which I assume you don't mind
[12:43] <ogra_> its very fasdt already :) but yeah, i dont :)
[12:43] <ogra_> *fats
[12:43] <ogra_> bah
[12:43] <cjwatson> so I think that's all doable entirely within flash-kernel - are you OK with fleshing out the details of that?
[12:44] <ogra_> yes, just looking for the place the file has to go
[12:44] <cjwatson> be a bit careful about interaction with ubiquity, I guess
[12:44] <cjwatson> since that calls flash-kernel-installer and probably won't have done the diversion, unless you take steps for it to do so
[12:44] <ogra_> ubiquity ?
[12:44] <ogra_> yes, also normal d-i alternates wouldnt use it
[12:45] <cjwatson> they would if you used a post-base-installer hook
[12:45] <cjwatson> so you'd have to either arrange to do the same diversion in ubiquity, or else have flash-kernel-installer.postinst not mind if the diversion isn't there
[12:45] <ogra_> f-k-i will have to check if the diversion exists first in any case
[12:45] <cjwatson> the latter's probably a good idea in any case
[12:45] <cjwatson> yeah
[12:45] <cjwatson> just check for the existence of the diverted file, probably easiest
[12:45] <ogra_> if it doesnt it wont try to revert it ...
[12:45] <ogra_> right
[12:55] <ogra_> grr, one day we should make update-noifier check for the arch of a device so it doesnt always offer me to upgrade from my armhf images on my x86 desktop
[12:56]  * ogra_ just noticed the 50 or so popup messages behind his terminal window
[13:12] <stgraber> ogra_: what's wrong with that, if you have qemu-user-static installed, you can totally upgrade from your armhf images ;)
[13:12] <ogra_> stgraber, right, and that works very well, i once did that in the middle of a customer call
[13:13] <ogra_> at the end of the call, when i rebooted my machine i noticed what had happened since it didnt boot anymore :)
[13:13] <stgraber> hehe :)
[13:14] <stgraber> yeah, in my experience you at least need a few important amd64 packages for it to work (upstart, libnih, mountall, iputils, isc-dhcp)
[13:14] <stgraber> as qemu-user-static doesn't like ptrace or netlink
[13:15] <stgraber> (and on a physical machine, you'd probably need binfmt in the initrd with the rest of the initrd being amd64)
[13:15] <ogra_> cjwatson, http://paste.ubuntu.com/1108165/ does that look ok ?
[13:17] <ogra_> oh, the ${ROOT} is definitely wrong
[13:17] <cjwatson> ogra_: some over-indentation, I'd spell out "flash-kernel-diverted" in full, 'set -e' in the post-base-installer hook, and please make the source file for the hook be "post-base-installer.d/01live-installer-flash-kernel-diversion" rather than under live-installer/
[13:17] <ogra_> ok
[13:17] <cjwatson> and actually drop "live-installer-" from that - this isn't live-installer specific
[13:18] <cjwatson> do you need --local on the undivert too?  I forget
[13:18] <cjwatson> might be best to match there
[13:18] <ogra_> i just stole the code from livecd.sh :)
[13:18] <ogra_> there it worked like this
[13:19] <cjwatson> mm, maybe dpkg-divert was lax, I think maybe best not to rely on it always being so though
[13:19] <cjwatson> the docs say "When adding, default is --local and --divert original.distrib. When removing, --package or --local and --divert must match if specified."
[13:19] <cjwatson> which implies to me that if you add with --local then you must remove with --local too
[13:20] <ogra_> k
[13:21] <skaet> good morning
[13:23] <ogra_> cjwatson, http://paste.ubuntu.com/1108178/
[13:24]  * ogra_ thinks that will fly 
[13:25]  * ogra_ dputs
[13:35] <Laney> hmm
[13:35] <Laney> I have a work item to fix unseeded universe final freeze, but I forgot what we said
[13:36] <Laney> can anyone remember?
[13:37] <ogra_> skaet, i always lose the pad url (used to be in the channel topic) ... could you add a rebuild note for armhf omap4 once flash-kernel 3.0~rc.4ubuntu11 has built
[13:37] <ogra_> ?
[13:37] <Laney> was it that we asked people to use proposed after that point?
[13:37] <ogra_> skaet, omap4 server that is
[13:38] <skaet> Laney, cjwaton - In looking at the pad and tracker,  trying to figure out if the latest published set of images has the app-install-data-update or only some of them (am guessing its a some of them since a-i-d-u only published 2 hours ago)
[13:38] <skaet> ogra_,  doing
[13:38] <Laney> some, the rest are still churning through
[13:38] <ogra_> skaet, "<cjwatson> Any objection to me rebuilding world after the next publisher run completes (which will be in ~1hr since we're in the fastdowntime window)?  I believe all the rebuild triggers are at worst pending publication."
[13:38] <skaet> Laney do we know which of the built ones don't have it.
[13:38] <ogra_> skaet, that was 3h ago, based on it i would a ssume a complete rebuild of everything
[13:39] <skaet> ogra_,  since it published 2 hours ago,   I think it was overlooked in the full trigger
[13:39] <skaet> s/it/a-i-d-u/
[13:39] <skaet> so,  some have it, some don't.
[13:43] <skaet> ogra_, http://pad.ubuntu.com/ubuntu-release  :)   have added your flash-kernel already,  and I'll put the link in the topic next.
[13:43] <Laney> looks like the desktop images do have it
[13:44] <skaet> thanks Laney.
[13:44] <ogra_> skaet, thx !
[13:45] <Laney> where are the logs on the server?
[13:45] <ogra_> which server ?
[13:45] <ogra_> nusakan ?
[13:45] <Laney> ye
[13:45] <ogra_>  /srv/cdimage.ubuntu.com/logs/
[13:45] <Laney> ah yeah found
[13:46] <ogra_> though if you need a live-build log that lives on the respective live builder machines
[13:46] <ogra_> w3m celbalrai.buildd/~buildd/LiveCD ... on nusakan would give you http access to the armhf build logs
[13:46] <Laney> oh, they are mirrored separately?
[13:47] <ogra_> yep
[13:47] <ogra_> they are created on different machines
[13:47] <Laney> thought nusakan might fetch them back
[13:47] <ogra_> iirc they are mirroed to the same place but with a delay
[13:48] <Laney> was just going to grep for the version of app-install-data-ubuntu they got
[13:48] <ogra_> http://people.canonical.com/~ubuntu-archive/ then gets them last
[13:48] <ogra_> just look at the manifest and list files in the image dirs on cdimage
[13:48] <skaet> ogra_,  re: dropping arm images from precise daily builds - because they're not denoted as LTS, so keeping them automatically building with the precise dailies as we ramp up to 12.04.1 wasn't needed.
[13:48] <ogra_> (manifest for live, list for alternate)
[13:48] <ogra_> skaet, nothing buiolds preinstalled automated :)
[13:48] <skaet> Laney,  other way is to just grep the manifests of the built images for the right version.
[13:49] <Laney> yeh
[13:49] <ogra_> (at least for precise)
[13:52] <skaet> ogra_ we're turning on the automated builds for all of the LTS participants from now until 12.04.1 FF,  which was motivation for making sure it reflected manifest.
[13:57] <ogra_> skaet, right, but nothing executes daily-preinstalled in crontab for precise
[13:57] <ogra_> so default-arches isnt relevant
[13:58] <ogra_> anyway, its gone now, just dont blame me if in two years nobody can anser which images we built in 12.04 :)
[13:59] <Laney> that's why we have vcs history
[13:59] <skaet> ogra_,   fair enough.
[13:59] <ogra_> Laney, heh
[13:59] <Laney> you could tag it when we do a release
[14:00] <ogra_> Laney, well, up to now we never touched default-arches for past releases, thats new with 12.04
[14:01] <ogra_> (to make sure everything works the same as it did on release day)
[14:01] <ogra_> (in case you want to do a rebuild, which never ever happened for arm)
[14:02] <skaet> Laney,  tagging when doing a release is a good idea, esp now that there's new hardware being added after the release.
[14:02] <Laney> I suppose using it would be difficult though, because you'd have to have either the old changes or the current
[14:03] <ogra_> that might gert tricky to coordinate since the cdimage code isnt bound to ubuntu releases
[14:03] <ogra_> *snap* :)
[14:04] <skaet> date of change should have the info, but tagging would make it a bit easier.    yes,  being able to recreate exactly what worked on release day  is a goal we need to accomplish as well.
[14:04] <ogra_> the current setup does that very well
[14:05] <ogra_> all scripts that touch any release specific bits are also in release specifc subdirs in debian-cd
[14:05] <skaet> ogra_ has we ever had to try it out in ernest?   ie.  was there ever a case a full recreate was executed?
[14:06] <ogra_> no, but there were rebiulds for certain oem images before they switched to OBS
[14:07] <ogra_> and mibile images too ... many of tehse wer built out of sync with the release schedule for older releases
[14:07] <ogra_> *mobile
[14:07] <ogra_> sigh, my typing starts to annoy me today
[14:08] <ogra_> so for picked images that always worked ... as well as for point releases of earlier LTSes
[14:08] <jibel_> wubi is missing from the tracker is it building ?
[14:09] <skaet> ogra_,  heh,  its the trackpad on this machine that keeps on flipping my cursor where I don't want it to be.   Thanks for the explanation.   Was curious.
[14:09] <ogra_> colin can surely give more details if needed, he designed the system with the rebuiolds in mind from the beginning
[14:10] <Laney> jibel_: yeah, crunching through
[14:10] <jibel_> ack
[14:10] <skaet> jibel,   builders are still going,  and WUBI's last (see pad for order builds were kicked off in)
[14:12] <Laney> https://wiki.ubuntu.com/FinalFreeze check what I wrote at the end there.
[14:12] <Laney> separate UUFF goes away and becomes this.
[14:14] <skaet> Laney,  looks good to me.   Post to ubuntu-release maillist,  with a pointer to the update, and if no issues raised by end of week,   consider it done.
[14:25] <micahg> chrisccoulson: you realize that we're in alpha3 freeze, right?
[14:25] <seb128> micahg, no need to crosspost that accross channels
[14:26] <seb128> kenvandine, chrisccoulson: please upload to quantal-proposed during a3 time ;-)
[14:26] <micahg> seb128: cross post?  sorry, I must have missed something :)
[14:26] <chrisccoulson> heh, oops ;)
[14:26] <seb128> micahg, doh, my IRC client played me tricks, I though that was #ubuntu-desktop
[14:26] <seb128> micahg, sorry about that
[14:26] <kenvandine> seb128, whoops...
[14:33] <ScottK> Laney: What does the archive is frozen mean in the context of your wiki update?
[14:34] <Laney> that was preexisting, but it means frozen in the launchpad sense
[14:36] <ScottK> So what's the term for when we're in the "only accept things that cause babies to catch fire no matter what part of the archive it's in." state?
[14:37] <ScottK> I think terminology is a significant part of why people get confused about this stuff.
[14:37] <Laney> "Deadline"? :-)
[14:38] <Laney> you could add a sentence abou tthat
[14:38] <tumbleweed> well, the nice thing about proposed, is if you're uploading there, there isn't such a state
[14:38] <Laney> it only says "consider"
[14:38] <tumbleweed> if the uploads don't get to -release, they'll go to -updates
[14:38] <tumbleweed> (assuming they're SRU worthy, but at that point, they should all be, right?)
[14:39] <Laney> not really
[14:39] <Laney> add something about how on release day all uploads must go to proposed, and if they are not SRU worthy and are too big then they may be rejected
[14:43] <tumbleweed> requiring all uploads in the last 1.5 days to be SRU worthy seems reasonable to me
[14:43] <Laney> that's what we had before
[14:44] <tumbleweed> am I taking us around in circles? damn
[14:45] <Laney> we're trying to get as many fixes as possible in
[14:45] <Laney> so we should just say that the closer we get to release, the less chance your upload has of getting in
[14:46] <tumbleweed> that's fairly clear, you should say it something like that
[14:47] <micahg> infinity: seb128: we missed the recommends on libwebkitgtk-3.0-0 :(
[14:48]  * micahg was wondering why c-m was still exploded with gstreamer goodness
[14:48] <Laney> ScottK: tumbleweed: try that
[14:48] <micahg> or badness in this case :)
[14:50] <ScottK> Laney: Rather than say final freeze is final for unseeded universe, I think it would be clearer to say that even though the archive as a whole is frozen, final freeze doesn't start for unseeded universe until X.
[14:50] <Laney> I'm trying to say that we don't have a final freeze here
[14:51] <Laney> just keep uploading your stuff and use proposed so that it can become an SRU if you miss the release and your bugs are good enough
[14:52] <skaet> ogra_ what's the bug number for the flash-kernel fix?
[14:52] <ogra_> skaet, no bug, we immediately worked out the fix when it showed up
[14:52] <skaet> ogra_,  ack.    thanks
[14:52] <ogra_> it is fgallout of the squashfs change
[14:52] <ogra_> *fallout
[14:53] <tumbleweed> Laney: it works for me. i was going to say that it could be clearer that fixes are still welcomed. But if one reads to the end of the paragraaph, I think it is
[14:53] <Laney> feel free to reword if you can improve it :-)
[14:57] <skaet> Laney,  what time did you kick off the first build of everything?   (or did cjwatson do it?)
[14:57] <Laney> he did a second round
[14:57] <Laney> about 0800UTC
[14:57] <skaet> thanks
[14:58] <micahg> skaet: so,  libwebkitgtk-3.0-0 is recommending universe codecs ATM which might balloon any images with universe enabled, but since this is only an alpha release and size isn't really a blocker, and webkit take 1.15 days on armel, I think maybe it should just be release noted?
[14:58] <Laney> upload it to proposed?
[14:59] <micahg> yeah, was thinking to do that
[14:59] <micahg> meh, was hoping not to be TIL for webkit, but whatever
[14:59] <Laney> so we get it if we can, otherwise: release note
[14:59] <micahg> do we need a tracking bug?
[14:59] <ScottK> Laney: There is a difference though.  For a final freeze upload, you don't need test cases, etc.  Once it is an SRU, different rules apply, so it's not as simple as keep uploading.
[14:59] <skaet> micahg,  yes.  tracking bug and  Release Note is appropriate.
[15:00] <skaet> micahg,  go ahead and add the note to https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha3,  we can delete if it ends up going in easily enough.
[15:00] <Laney> "Hey, these images contain loads of cool stuff!"
[15:01] <micahg> heh, right :)
[15:01] <Laney> ScottK: Indeed, people may have to come back and do more work. Although I think zero-day SRUs are a bit more lax?
[15:01] <stgraber> skaet: in case you aren't reading #ubuntu-testing, dhcpd currently fails to start on quantal, at least with LTSP, but very likely in any scenario. So far it looks like it's a potential apparmor/kernel regression. I'm trying to get someone from #security to look at it.
[15:02] <tumbleweed> Laney: it's more than coming back to do more work
[15:02] <tumbleweed> you need a tracking bug in the upload
[15:02] <tumbleweed> and yes, zero-day SRUs could probably use better documentation
[15:03] <Laney> true
[15:05] <micahg> a 3 hour test build for a
[15:05] <micahg> * a 3 hour test build for a control file change is fun, right?
[15:05] <Laney> does it parallelise?
[15:06] <micahg> no, I think that's broken ATM
[15:06] <Laney> oh, woe
[15:06] <Laney> was going to give it to The Cloud
[15:07] <micahg> I think I have a WI somewhere for that
[15:07] <skaet> Laney,   did you manage to figure out which of the images are going to need to be respun to pick up the right version of a-i-d-u?
[15:07] <Laney> all will be fine
[15:07] <Laney> colin's rebuilds were after it got published
[15:07] <skaet> Laney,  :)  happiness indeed
[15:17] <skaet> Laney,  can you take a look at http://pad.ubuntu.com/ubuntu-release,  and confirm I've got the history section accurate now,  as well as the status of the current images building/needing to rebuild?
[15:18] <skaet> (history section is after the current set of images)
[15:18] <ogra_> the new flash-kernel is done btw armhf server daily can be rebuild
[15:19] <micahg> skaet: wiki update for webkit issue, pad updated, test build in progress, est ~2hrs until it's done
[15:20] <Laney> skaet: yeah, lgtm
[15:20] <Laney> what's the page that lists the bugs we're tracking?
[15:25] <skaet> Laney,    http://iso.qa.ubuntu.com/qatracker/reports/defects  under Quantal Alpha 3 shows summary of what's been found so far,  once a bug is logged.
[15:25] <Laney> I meant the rls-q-incoming and nominated ones
[15:25] <skaet> ahh...
[15:26] <skaet> http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-incoming-bug-tasks.html
[15:27] <Laney> aha
[15:27] <Laney> ta
[15:27] <skaet> but folks aren't all adding the tag yet,  so iso tracker is good to cross check against.
[15:27]  * skaet added a couple this morning already
[15:28] <Laney> sure
[15:28] <Laney> ogra_: so teach me, what's the right invocation to do your respin?
[15:28] <ogra_> well, depends, do you onyl want to rebuilds armhf+omap4 ?
[15:28] <slangasek> ogra_, Laney: yes, the fact that *all* the precise preinstalled lines were being removed escaped me; it would've been more straightforward to just make sure they weren't in the crontab
[15:28] <ogra_> *sigh* my typing
[15:29] <ogra_> slangasek, thats what i meant :)
[15:29] <Laney> ah well
[15:29] <Laney> ogra_: let's say yes for now
[15:29] <Laney> I assume there's an env var you set
[15:30] <ogra_> Laney, omap4 only: ARCHES="armhf+omap4" buildlive ubuntu-server daily && ARCHES="armhf+omap4" for-project ubuntu-server cron.daily
[15:30] <Laney> aaaaaaaaaha
[15:30] <ogra_> essentially just grab whats in crontab for a specific flavour and use ARCHES=
[15:31] <ogra_> (mind you, thats usually two commands in succession so you need to set it twice)
[15:32]  * skaet nods
[15:35] <Laney> ok, doing
[15:38]  * apw has noted that linux-lowlatency is lagging the main kernel.  i would like to update it.  i am unsure if you care to have it in A3, so i was proposing to upload it to quantal-proposed and you can either promote it before or after the freeze lifts.  is that reasonable?
[15:40] <Riddell> ooh kubuntu images
[15:41] <skaet> apw,  seems reasonable.
[15:41] <skaet> apw,  please note it on the pad as opportunity target,  with the links so we can track.
[15:43] <jibel> skaet, alternate fails to install on Mac, there is a loop on detection of USB devices. Connect/Disconnect ... forever
[15:43] <jibel> skaet, I'll confirm with another hardware
[15:43] <jibel> mac mini that is
[15:43] <skaet> jibel,  thanks for flagging.   post bug number when you're got it.
[15:46] <infinity> micahg: I thought seb uploaded for that?  Or did he miss a bit?
[15:46] <micahg> infinity: missed a bit
[15:46] <infinity> micahg: Poop.
[15:46] <micahg> infinity: I've got a test build going and will upload to -proposed when it's done
[15:46] <infinity> micahg: Hah, I was just about to suggest I bounce something to proposed, but it's all you.
[15:47] <micahg> gives my machine something to do while I'm testing webkit in precise
[15:58] <ogra_> no need to put any arm netboot images on the tracker, they are all broken
[15:59] <ogra_> (they will need a complete overhaul for the new flash-kernel and i didnt get to them yet (next on my TODO))
[16:03] <skaet> ogra_ ack.   have put a note on the pad,  and marked them for rebuild on the iso tracker.   add details/bug numbers to the pad as you get them.
[16:04] <stgraber> hmm, something's wrong with the bot...
[16:04] <stgraber> the disabled entries are good, but the updated ones shouldn't have shown
[16:04]  * ogra_ hugs his ac100 images ... 
[16:04] <ogra_> the only arm images that work ootb this time :)
[16:05] <infinity> ogra_: A "complete overhaul"?
[16:05] <infinity> ogra_: Did f-k not provide a sane interface on upgrade here?
[16:06] <ogra_> infinity, well, f-k and upgrades are another bug i have to catch (thanks to you :P )
[16:06] <ogra_> infinity, its the fact that there are no partitions on the MMC in netinst ... so f-k doesnt knwo what to do
[16:07] <stgraber> skaet: looks like apparmor not logging is some kernel weirdness on my machine, the actual failure can be fixed in isc-dhcp. I'll upload a fix to -proposed in a few minutes
[16:07] <infinity> ogra_: I didn't literally mean upgrades, I just meant that f-k and f-k-i should still be presenting a similar interface, so changing d-i shouldn't be required, right, just fixing f-k?
[16:07] <infinity> ogra_: My netboot images all have partitions...
[16:08] <ogra_> infinity, in the img file ?
[16:08] <ogra_> would be intresting how you got these since d-i doesnt have any dep on any partitionintg tool :)
[16:09] <infinity> Oh, maybe the d-i images don't.  My PXE images do.
[16:09] <infinity> That's not "a complete overhaul", though, it's a question of a simple tweak.
[16:09] <ogra_> well, i have to wrap a partiton table and a partition around them
[16:09] <ogra_> and an mbr
[16:10] <infinity> Yeah, cargo-cult debian-cd, that's what I did for PXE. ;)
[16:10] <infinity> Better yet, now that I understand this problem, bug me about it in ~1 week, and I'll JFDI.
[16:10] <ogra_> and given that we have never found a way to make omap systems recognize parted created partitions for booting (CHS binding) it will be an intresting effort
[16:11] <ogra_> since i assume colin wont allow me to make d-i build-dep on fdisk or sfdisk :)
[16:12] <ogra_> alternatively we could hack up parted to actually force creation of the mbr and first partition during install but thats even harder to achieve
[16:12] <ogra_> (beyond parted in d-i really really scaring me)
[16:14] <infinity> ogra_: Erm, it doesn't need to build-dep on them, they're essential.
[16:14] <ogra_> oh !
[16:14] <infinity> And I'm sure some images already use either one or both.
[16:14] <ogra_> that should make it a bit easier
[16:14] <ogra_> since i can just copy the logic from debian-cd then
[16:14] <jibel_> bug 1028526 breaks ltsp, not sure of the importance for server
[16:15] <ubot2> Launchpad bug 1028526 in isc-dhcp "dhcpd failed to start with apparmor denied: capname="dac_override"" [Undecided,New] https://launchpad.net/bugs/1028526
[16:15] <jibel_> skaet, stgraber ^
[16:15] <micahg> Riddell: is there supposed to be a Kubuntu DVD listed on the pad?
[16:15] <Riddell> micahg: no it's gone
[16:16] <apw> skaet, ok the builds are in progress and its on the tracker thingy [12]
[16:16] <micahg> Riddell: ah, ok, it's still showing up in seeded-in-ubuntu (and the seeds still exist), but no worries
[16:18] <stgraber> skaet, jibel_: jdstrand is preparing an upload now, we'll need to respin any image containing isc-dhcp-server
[16:19] <balloons> fyi, hggdh noticed the download links are wrong for ubuntu server armhf+ompa4: http://iso.qa.ubuntu.com/qatracker/milestones/226/builds/19353/downloads
[16:19] <balloons> I'm going to change to correct now
[16:20] <balloons> precise should keep the -preinstalled, but quantal should move to the daily
[16:20] <balloons> agreed?
[16:20] <stgraber> sounds right
[16:21] <ogra_> balloons, preinstalled is completely dead in quantal, yeah
[16:21] <ogra_> apart from ac100
[16:21] <ogra_> all arm images you care about are now identical to their x86 pendant
[16:22] <balloons> yes -- we need to review all the download links for them to make sure they are pointing properly to the right images
[16:22] <balloons> I'll do that
[16:22] <ogra_> balloons, also note that there wont be rebuilds of preinstalled precise ...
[16:22] <balloons> just wanted to make everyone aware before I dove in :-)
[16:22] <ogra_> so not sure you need to keep them on the tracker at all
[16:22] <balloons> ogra_, just historical purposes.. we want the old links to be correct
[16:22] <ogra_> k
[16:24] <stgraber> balloons: you might actually want to use "SERIES" as a placeholder in the links and not make the links series-specific, so we don't need to update them all for quantal+1
[16:24] <balloons> stgraber, I'm noticing all the md5sums appear to be broken as well
[16:25] <balloons> yikes yikes
[16:25] <balloons> ok, just on those images.. ;-)
[16:25] <ogra_> indeed they are
[16:26] <ogra_> they will likely match with the broken dl paths though :)
[16:30] <ogra_> lol, funny that ubiquity just informs me that the UX team is hiring ...
[16:30] <balloons> stgraber, on the SERIES thing.. it seems like we don't have them linked on cdimage to allow that
[16:31] <balloons> stgraber, notice there is no quantal (http://cdimage.ubuntu.com/ubuntu-server/)
[16:31] <jdstrand> skaet: should this (isc-dhcp) use quantal-proposed or quantal?
[16:32] <stgraber> balloons: only point releases show up as /SERIES/SERIES-<media type>-<version>.iso, so for all products at this point we should have two entries
[16:32] <skaet> jdstrand,  quantal directly.
[16:32] <skaet> we'll be doing a respin for it.
[16:32] <stgraber> balloons: PRECISE with /ubuntu-server/SERIES/VERSION/SERIES-<media type>-<arch>.iso
[16:32] <stgraber> balloons: and a generic entry with /ubuntu-server/VERSION/SERIES-<media type>-<arch>.iso
[16:33] <balloons> stgraber, yes, but that will fail for quantal
[16:33] <stgraber> balloons: no
[16:33] <balloons> ubuntu-server/quantal is a 404
[16:33] <stgraber> balloons: read again ;) you only use /SERIES/ for POINT-RELEASES
[16:34] <balloons> stgraber, lol :-) I'm multitasking here.. Let's plan to review the links as post-alpha3 follow-up
[16:34] <balloons> I'll add it to the agenda
[16:34] <balloons> I see some download links are missing rsync's, etc
[16:34] <balloons> we should clean all of them up and do best practice (aka, use series), etc
[16:35] <balloons> and stgraber yes, I agree on making them as static as possible :-)
[16:35] <stgraber> For Ubuntu server amd64, you'd have two entries:
[16:35] <stgraber> series == precise: http://cdimage.ubuntu.com/ubuntu-server/SERIES/daily/VERSION/SERIES-server-amd64+mac.iso
[16:35] <stgraber> series == NULL: http://cdimage.ubuntu.com/ubuntu-server/daily/VERSION/SERIES-server-amd64+mac.iso
[16:36] <stgraber> with these two entries, we should be good until 14.04.1 where we'll have to add an entry with /SERIES/ for that series
[16:36] <jdstrand> skaet: ack
[16:36] <jdstrand> it'll be soon, I'm building locally and will test/upload
[16:37] <Laney> doesn't 9 affect pretty much everything?
[16:39] <stgraber> Laney: if you want isc-dhcp (all binaries) to be on the same version everywhere, yes. If you're just interested in the fix, no.
[16:40] <stgraber> isc-dhcp-client and isc-dhcp-common are indeed on pretty much all images, though the fix will just change the init script of isc-dhcp-server, that's only seeded on server, alternate and edubuntu IIRC
[16:54] <Laney> climbing time. back in ~3h
[16:54]  * ogra_ wonders whgat the heck pulls redboot-tools into the omap images 
[16:57]  * skaet --> lunch,  biab
[16:58] <stgraber> same here, biab
[17:15] <micahg> skaet: is there a reason xubuntu was left out of the rebuild commands for desktop and alternater images?
[17:28] <ogra_> infinity, were you planning to do some mx5 tests ? else we should probably drop them from the tracker if no testers are around
[17:32] <infinity> ogra_: I hadn't planned to do any.  I'd rather drop the image and build a netboot, to be honest. :P
[17:32] <ogra_> lets do that then
[17:32] <ogra_> i would have tested if i had the HW
[17:32] <ogra_> but i dont and there is no community
[17:33] <ogra_> (and i think we should rather keep the currently rare builder cycles for omap3 than for mx5)
[17:34]  * ogra_ goes out to mow the lawn
[17:36] <infinity> Grr.  Who feels good about a new d-i upload? :P
[17:36] <micahg> infinity: aren't we already rebuilding the world for isc-dhcp?
[17:37] <infinity> micahg: Ahh, I haven't been keeping up with the channel.
[17:37] <micahg> infinity: maybe not, not sure what the call on that was
[17:37] <micahg> and I don't see it on the pad except for Ubuntu Studio
[17:37] <micahg> oops
[17:37] <infinity> Well, the current d-i named the highbank initrd incorrectly.  Other than that, it's a no-change for other arches.
[17:37] <micahg> nevermind, it's on there
[17:38] <micahg> infinity: so, no plans to rebuild the world ATM :)
[17:38] <infinity> Well, it doesn't throw things out of sync.  Maybe I'll just upload anyway, and if there's a rebuild later, it'll get picked up.
[17:40]  * infinity does that.
[17:42] <micahg> infinity: local webkit build still not done yet :(
[17:42] <infinity> micahg: If it's just changing debian/control, is a test build really necessary?
[17:45] <micahg> infinity: well, there's a new gobject-introspection, it really depends on if anything related in the archive has changed since the last upload I guess
[18:04]  * skaet back
[18:11] <skaet> micahg,  its an oversite,   just checked and  isc-dhcp-server is in the .list for the alternate.  Have added to the pad for rebuilds
[18:13]  * micahg wants to cry, his 3 hour webkit test build failed due to lack of space :(
[18:22] <skaet> micahg,  you're right, xubuntu wasn't in the rebuild scripts.   I've added it now.
[18:22] <micahg> thanks
[18:23] <skaet> Laney,  slangasek ^  does it make sense to do the builds for xubuntu desktop now?   for xubuntu alternates,  I think we should wait until the isc-dhcp-server fix lands, since its close.
[18:26] <stgraber> skaet: according to rmadison isc-dhcp-server is built and published on everything but armel
[18:28] <micahg> ok, let's go for a set then
[18:28] <skaet> thanks stgraber.
[18:29] <skaet> stgraber,   we've still got edubuntu dvd,  ubuntu studio, and wubi building to get through on the desktop,  but  we should be able to get the alternate and server build (except arm ones).
[18:30] <infinity> skaet: We don't build armel images, no need for the "except arm" there.
[18:31] <skaet> infinity,  d'uh.  good point.
[18:33] <skaet> infinity,  is there anything else about to land for the arm images?
[18:34] <infinity> Nothing ARM-specific.
[18:34] <infinity> Can't speak to the work others have been doing today.
[18:37] <skaet> Laney, slangasek - I've started a rebuild of the alternates for ubuntu, xubuntu and lubuntu to pick up the isc-dhcp-server fix.
[18:43] <skaet> ogra_,  is there an ETA on when you'll be finished the reworking for the new flash kernel?
[18:49] <jibel_> is hope to see wubi today definitely lost ?
[18:49] <skaet> jibel_ no,  its just backed up behind edubuntu and ubuntu studio dvds
[18:50] <skaet> edubuntu dvd is building now.
[18:50]  * skaet thinks we should probably rearrange the order on the pad....
[18:50] <jibel_> ok, good night then o/
[18:51]  * highvoltage peeks in
[18:52] <stgraber> skaet, Laney: did you use ARCHES= for edubuntu? we're not releasing omap4 for alpha3, so if you want to save a couple of hours, just override ARCHES to "amd64 i386"
[18:53] <skaet> stgraber,  Laney kicked it off,  but I suspect not.
[19:12] <skaet> micahg, ^ Xubuntu alternates available to try now.
[19:35] <skaet> Laney, slangasek have updated the pad to make it explicit that any further rebuilds of Edubuntu are only for i386 and amd64.
[20:53] <skaet> ok,  we've gotten the last of the build lives out,  next up,  Xubuntu Desktop,  then a rebuild of Ubuntu Sever
[20:53] <skaet> Server even.
[21:04] <shadeslayer> uhm, why does Ubuntu Server have a mac image
[21:04] <shadeslayer> seems a bit pointless imo
[21:05] <skaet> Daviey, ^
[21:05] <shadeslayer> ( fwiw I don't see the point of mac images atm because afaik they don't do anything special and cannot be booted from USB drives )
[21:06] <stgraber> amd64+mac is supposed to contain the required tricks to allow booting from Mac EFI, the standard amd64 image doesn't boot
[21:06] <shadeslayer> stgraber: it does :)
[21:06] <stgraber> on a clean mac without refit or any other efi tricks?
[21:06] <shadeslayer> yes
[21:06] <shadeslayer> I've done it before
[21:07] <shadeslayer> you burn a CD/DVD , hold down the 'C' key
[21:07] <shadeslayer> and it boots the CD
[21:07] <shadeslayer> after installing, you hold down the option key to choose which OS to boot
[21:08] <shadeslayer> here's the fun part, Fedora managed to get proper EFI boot working
[21:08] <stgraber> we'd need cjwatson for the details, but in theory, the state of things on most Macs is that i386 will boot fine (holding c, then install), amd64 might boot but won't install, amd64+mac will boot and install
[21:09] <stgraber> yeah, Fedora has a couple more tricks in their boot sector that Ubuntu doesn't have yet
[21:09] <stgraber> that's why we still have a separate image
[21:09] <shadeslayer> well ... if it's just the booting part, I am 99% confident that it just works with the standard desktop image
[21:10] <shadeslayer> I'll test alpha 3 once I buy a DVD tomorrow
[21:10] <micahg> hrm, shouldn't a blacklist entry prevent the inclusion of a binary and its dependency tree?
[21:11] <shadeslayer> stgraber: I'd absolutely love to see Fedora's modifications included in ubuntu so that I don't have to burn DVD's
[21:11] <micahg> http://bazaar.launchpad.net/~xubuntu-dev/ubuntu-seeds/xubuntu.quantal/revision/909 did I miss something?
[21:11] <shadeslayer> I'd do it myself, except I have no idea how all of that works :P
[21:11]  * shadeslayer can volunteer for testing however
[21:12] <micahg> ah, I included the wrong binary :(
[21:14] <ogra_> skaet, for netboot you mean ? i was hoping to be done by end of the week
[21:15] <stgraber> shadeslayer: yeah, it's been on Colin's todo list for a few months, it's not trivial as we're not using the same tools at all and IIRC there was concern that Matthew's tricks would regress some currently working setups
[21:15] <skaet> ogra_, ok,   wasn't sure if it was something needed for A3 or not,  from the comments.   I'll assume not then.
[21:16] <shadeslayer> stgraber: ahh ...
[21:16] <ogra_> skaet, well, its definitely to much change to get into debian-installer right now
[21:16] <shadeslayer> all of it seems very magical to me tbh
[21:16] <skaet> ogra_,  can you add a release note to the TechnicalOverview/Alpha3 about it?
[21:17] <Daviey> shadeslayer: Was that an offer to help?
[21:17] <ogra_> i actually wanted to have it ready by monday but instead had to fix the server builds first ....
[21:17] <ogra_> skaet, no problem, will add something
[21:17] <skaet> thanks ogra_
[21:17] <shadeslayer> Daviey: sure, except I don't know shit about EFI and how stuff works in GRUB
[21:17] <shadeslayer> oh plus
[21:18] <shadeslayer> one more thing that needs to be done is that the i915 module should be compiled into the standard kernel, that way you can switch off discrete graphics
[21:18]  * skaet has kicked off the server rebuilds
[21:19] <micahg> hrm, is updating the blacklist file not enough?  I still seem to have ubuntu-sso-client-qt even though I added it to the blacklist file
[21:19] <shadeslayer> Daviey: I barely have EFI booting at the moment
[21:19] <shadeslayer> pure EFI boot I mean, not that BIOS emulation crap
[21:39] <slangasek> shadeslayer: it may have worked for one particular mac case that you tested; it does not, in general, work reliably on EFI Macs
[21:39] <shadeslayer> slangasek: right, I'm just interested in why exactly we have Mac ISO's
[21:39] <slangasek> *that* is why
[21:39] <slangasek> because the non-mac image does not, in general, work reliably on EFI Macs
[21:40] <shadeslayer> well ... I have a EFI mac
[21:40] <shadeslayer> Late July 2011, MBP (8,2)
[21:41] <shadeslayer> slangasek: and didn't work as in didn't even boot?
[21:41] <shadeslayer> or  did not work as in "Fans did not come up causing machine to get insanely hot"
[21:42] <ScottK> No boot.
[21:42] <slangasek> shadeslayer: doesn't boot.  you really need to talk to cjwatson if you want specifics; but the answer is still the same, we can't get rid of amd64+mac images until our image build scripts do the same handling for EFI boot that Fedora has now implemented
[21:43] <ScottK> FSVO sane.
[21:43] <ScottK> Oh, you said same.
[21:44] <shadeslayer> slangasek: I'm not saying get rid of them, I'm curious as to what special magic goes into the Mac builds
[21:44] <shadeslayer> and that it doesn't make sense to have mac builds for Servers
[21:44] <slangasek> the special magic in the mac builds is that they don't include EFI support
[21:45] <shadeslayer> they *don't* include EFI support? 0.o
[21:45] <slangasek> so they *only* boot in bios compat mode, which Works
[21:45] <slangasek> as for the server builds, that's certainly up to Daviey (and the Ubuntu Server folks generally) to decide
[21:46] <shadeslayer> uhh .. ok
[21:47] <shadeslayer> slangasek: any particular model where the standard image didn't work?
[21:47] <slangasek> I wouldn't know the details
[21:47] <shadeslayer> right, will wait for cj then
[21:48] <Laney> stgraber: but you are having omap4 in general?
[21:49] <stgraber> Laney: we have omap4 for dailies as preview images for our a10 images that we hope will start appearing a bit later this cycle
[21:49] <stgraber> Laney: so we don't release omap4 as we don't want people to expect us to release an omap4 image for 12.10 as our target is a10
[21:50] <Laney> ok
[21:50] <Laney> so it should be in default-arches but overridden for manual milestone builds
[21:50] <stgraber> right
[21:51]  * Laney wonders why we have all of the for p in <one thing> there
[21:52] <Laney> jibel_: skaet: wubi is starting now
[21:53] <slangasek> Laney: cut'n'paste is easier? :)
[21:53] <skaet> Laney,   WUBI published already with latest
[21:54] <Laney> oh, well this is from the stuff i queued up this morning
[21:55] <skaet> Laney,  anything else in your queue that's not on the pad?
[21:56] <Laney> wubi is last in the order, so I doubt it
[21:57] <skaet> Laney,  coolio.   WUBI emerged from the full rebuild that cjwatson started around an hour ago.
[21:57] <Laney> wonder how his were faster
[21:58] <Laney> pasted all of the timings i could find in there
[21:58] <skaet> Thanks Laney
[21:58] <Laney> especially the arm buildd was fighting contention though
[21:59] <skaet> cjwatson started his off at 1100 UTC as one big set,   when did you start yours off?
[22:00] <Laney> 0800UTC
[22:00] <Laney> I just used the rune on the pad
[22:00] <skaet> yeah,  I thought yours had all finished when he started his,  so must have been some weird contention going on.
[22:01] <Laney> oh well
[22:08] <stgraber> infinity: lp:~stgraber/ubuntu-archive/tools/detect-broken-bugs
[22:08] <stgraber> infinity: lp:~stgraber/ubuntu-archive-tools/detect-broken-bugs even
[22:44] <Laney> there
[22:45] <Laney> skaet: are we intentionally not building alternates for kubuntu?
[22:47] <skaet> Laney,   Riddell had indicated he wasn't interested in them for the Alphas, since they may be going away.
[22:48] <hggdh> ogra_: there still?
[22:48] <skaet> if Riddell or ScottK, want them built,  we certainly can.
[22:48] <Laney> right. The manifest says they're still coming, so wanted to check.
[22:48]  * Laney EODs. see ya
[22:49] <skaet> Laney,  right thing to do.  :)   I'll go update the manifest to be a bit clearer on it.
[22:50] <Laney> lowlatency kernels in NEW btw
[22:50] <infinity> Laney: Is not.
[22:50] <Laney> erm.
[22:51] <Laney> well wouldya look at that
[22:55] <Riddell> Laney, skaet: yeah I think we do want alternates for kubuntu still
[23:01] <micahg> hrm, no answer about the seeds :(
[23:03] <stgraber> micahg: I don't remember exactly how the seed blacklist works, but in most of the cases, that's not the right thing to use as it won't be respected when manually installing xubuntu-desktop or doing a netboot install
[23:04] <micahg> stgraber: yes, but I don't mind these things in those cases :), just on the images
[23:04] <micahg> and they're not in -desktop
[23:10] <hggdh> armhf-omap4 server image -- no working keyboard, bug 1028664
[23:10] <ubot2> Launchpad bug 1028664 in debian-installer "keyboard does not work on quantal-server-armhf+omap4.img" [Undecided,New] https://launchpad.net/bugs/1028664