[01:48] <ScottK> stgraber: Yes.
[01:49] <stgraber>  ScottK ok. Can you say so in the ubuntu-release@lists.u.c thread?
[01:49] <ScottK> stgraber: Riddell already did.
[01:50] <stgraber> ScottK: ah? https://lists.ubuntu.com/archives/ubuntu-release/2012-November/ and https://lists.ubuntu.com/archives/ubuntu-release/2012-December/ don't seem to agree
[01:51] <stgraber> and there's nothing in the moderation queue
[01:51] <cjohnston> stgraber: do you know where the code is for http://reqorts.qa.ubuntu.com/reports/boot-speed/ by chance?
[01:52] <ScottK> OK.  Done.
[01:52] <stgraber> cjohnston: nope
[01:52] <stgraber> ScottK: thanks
[01:52] <ScottK> Seems I mis-remembered.
[01:52] <ScottK> No problem.
[01:52] <cjohnston> thanks stgraber
[01:54] <infinity> ScottK: APAC woke up, rocs is building belatedly on armhf/quantal-proposed now.
[01:55] <ScottK> infinity: Thanks.
[02:31] <infinity> ScottK: When you get a moment, can you review and let the above hugetlbfs into lucid-backports?
[02:31] <ScottK> Is it tested?
[02:31] <infinity> Yeahp.  stokachu had it tested.
[02:31] <infinity> (So says the bug log)
[02:35] <infinity> Do backports uploads auto-close bugs, or do I need to do it manually?
[02:35]  * infinity goes to look.
[02:35] <ScottK> No.  They don't, but I already did it.
[02:35] <infinity> Ahh, thanks.
[02:36] <ScottK> It wasn't actually even filed against backports.  Fixed that too.
[02:36] <infinity> Oh, yeah.  The backport bug tracking is a bit odd to me.  The lack of per-pocket bugs targeting makes it sketchy, I guess.
[02:38] <ScottK> Each release is a separate project in LP.
[02:38] <Riddell> hmm I'm sure I e-mailed ubuntu-release
[02:38]  * ScottK thought so too, but didn't see it.
[02:39]  * ScottK did a backup mail and covered it though.
[02:39] <Riddell> my sent-mail says I sent it to stgraber directly, silly me
[02:39] <Riddell> doesn't explain why he hasn't seen it but
[02:40] <infinity> I dunno about him, but I spam filter all mail with Scottish accents.
[02:40] <stgraber> Riddell: well, I've had e-mail problems on Friday and likely lost an hour or so of e-mails. I re-checked all my mailing-lists manually for anything I'd missed, but there's not much I could do for private e-mails
[02:41] <Riddell> jings and crivvens
[02:41] <infinity> Great, now I need to start filtering IRC.
[02:42] <infinity> Also, http://en.wiktionary.org/wiki/crivvens is brilliant: "See also: cripes and crikey".
[11:05] <cjwatson> Grr, getting live-build to install linux-generic-lts-quantal correctly is unexpectedly difficult
[13:24]  * ogra-cb wonders if the chinese images are built using a different build system ... bug 1085918 shows the same timestamp i use for nexus7 images but thats set only based on the subarch 
[13:24] <ubot2> Launchpad bug 1085918 in ubiquity (Ubuntu) "Chinese raring desktop images have different format of media-info to that of standard desktop images" [Undecided,New] https://launchpad.net/bugs/1085918
[13:28] <xnox> ogra-cb: i'd like to know where the chinese images are...
[13:29] <ogra-cb> the bug points to them
[13:29] <ogra-cb> http://china-images.ubuntu.com/raring/daily-live/current/
[13:30] <ogra-cb> its likely only a conicidence that they use the same timestamp format. but its irritating
[13:31] <cjwatson> The Chinese images use ubuntu-defaults-builder.
[13:31] <cjwatson> Which is based on live-build / livecd-rootfs, but another layer.
[13:42] <ogra-cb> xnox, i would also see a bug in utah here ... it should eb able to handle such stamps too
[13:43] <ogra-cb> (specifically because all arm images and images will have it)
[13:43] <ogra-cb> (well, all preinstallled ones at least)
[13:46] <xnox> ogra-cb: sure, but ideally we standartise on some kind of parsable format.
[13:48] <ogra-cb> yes, for preinstalled where the stamp is created on the live builder we cant know if it is yyyymmdd.n or just yyyymmdd
[13:48] <ogra-cb> so there must be another format that still makes it possible ot have more than a build per day
[13:49] <ogra-cb> if the stamp is added during post processing you code can check whats in the www dir alreday, cant do that from a live builder easily
[13:49] <ogra-cb> *your
[13:58] <xnox> ogra-cb: or the stamp can be yyyymmdd.HHMM
[13:58] <ogra-cb> oh, sure
[13:58] <xnox> and that has ~ same machine parsability.
[13:59] <ogra-cb> but that will require code changes all over the place if you want consistency
[13:59] <ogra-cb> i.e. to make the download dirs use that
[14:00] <ogra-cb> and i'm not sure we would want that (breaks likely lots of download scripts out there)
[14:02] <ogra-cb> i think we should rather determine the version string at the very beginning of the build and export it to the live builder
[14:03] <ogra-cb> (and to all other scripts indeed, but these are on teh same machine anyway)
[14:07] <psivaa> xnox: i am seeing bug 1085961 when i do side by side installations
[14:07] <ubot2> Launchpad bug 1085961 in ubiquity (Ubuntu) "Unable to install two raring desktops side-by-side" [Undecided,New] https://launchpad.net/bugs/1085961
[14:10] <xnox> ogra-cb: I am not talking about urls, I am only talking about the format/regexp of the image/iso diskid.
[14:10] <xnox> ogra-cb: which we can use in ubiquity & utah etc.
[14:11] <ogra-cb> xnox, usually that corresponds to the url
[14:11] <xnox> ogra-cb: no. all urls use current/ symlink.
[14:11] <xnox> ogra-cb: and that's the canonical url, the rest may or may not exist as we rotate them a lot & images may not be build today.
[14:12] <ogra-cb> i.e. an iso from  cdimage.u.c/daily/20121201.1 will have exactly that timestamp insiuude too
[14:12] <ogra-cb> and i think thats wanted
[14:12] <ogra-cb> current is just a link to the latest of these timestamped dirs
[14:13] <xnox> ogra-cb: apart from that url -> file mapping is not always true (e.g. as we see in preinstalled & chinese images), while current->latest symlink is correct across all of them.
[14:14] <ogra-cb> preinstalled just got that added two weeks ago ... and simply because i couldnt come up with anything better
[14:14] <xnox> ogra-cb: that gives me confidence that url != file is ok, but file having a different format within image is / can be a problem.
[14:14] <ogra-cb> chinese looks more like a bug
[14:14] <xnox> ack.
[14:15] <ogra-cb> url != file is not ok, it is there because i introduced it lacking a better implementation
[14:16] <ogra-cb> the proper implementation would be as i said above, figure out the stamp at the very beginning and hand them to the respective scripts ... currently the stamp is only used in post processing
[14:16] <ogra-cb> which we dont do for preinstalled
[14:16] <xnox> ogra-cb: ack.
[14:17] <xnox> ogra-cb: and ubuntu-defaults builder should be fixed to generate more similarish timestamps.
[14:17] <ogra-cb> i simply didnt want to hack up the whole code of cdimage ... introducing yyymmdd-hhmm was just the way of least resistance for an unsupported image
[14:17] <ogra-cb> i dont mind replacing the dash with a dot for now ... but effectively it wont fix the bug
[14:18] <ogra-cb> that can only be done by a bit of redesign
[14:19] <ogra-cb> i might even drop the whole thing again if we decide to switch to xz for nexus7 which means we would re-pack the tarball on nusakan anyway
[14:34] <ScottK> It would be nice if someone in SRU (I uploaded it, so I can't) would review ^^^ so we don't end up hold all of KDE 4.9.3 up for it.
[15:54] <cjwatson> infinity,slangasek: ^- livecd-rootfs 2.65.4 - YA in the secure boot saga
[15:54] <cjwatson> This time I've actually tested the image build (which is currently failing in precise :-/)
[16:01] <ScottK> stgraber: Now that I created the Alpha 1 milestone in the tracker, is everything going to get added automatically?
[16:02] <ScottK> It'd be nice to only have the Kubuntu stuff in there so people don't get confused.
[16:02] <stgraber> ScottK: yeah, I still need to setup some scripts to avoid that ^
[16:02] <stgraber> was planning on doing that this afternoon :)
[16:03] <ScottK> Excellent.
[16:03] <ScottK> IIRC, that's not far off.
[16:07] <cjwatson> Has anyone decided on whether a partial britney freeze is needed, and if so of what package(set)s?
[16:08] <stgraber> ScottK: alright, I removed everything from the alpha-1 milestone. I'll add the Kubuntu desktop products to the manifest so that they'll auto-publish when we start building at 21:00 UTC today
[16:08] <stgraber> cjwatson: I didn't get any request so far, so I'm hoping not
[16:10] <ScottK> stgraber: Can we have the current images in there manually?
[16:10] <ScottK> (for Kubuntu)
[16:11] <ScottK> I added them manually when I set up the milestone.
[16:11] <stgraber> ScottK: ok, added.
[16:11] <ScottK> Thanks.
[16:12] <stgraber> ScottK: you added them with an invalid version number (.0), so that's why I removed them earlier
[16:12] <ScottK> Yes.  I messed that bit up.  I wasn't sure what to put in.  Thanks for fixing.
[16:13] <stgraber> btw, we may end up having an Edubuntu alpha-1 after all. Seems like highvoltage will have enough time to take care of it all by himself.
[16:13] <stgraber> we'll have the final decision by 21:00 UTC
[16:17] <ScottK> Cool.
[17:15] <stgraber> highvoltage: edubuntu added to the alpha-1 manifest, first builds will show up a bit after 21:00 UTC
[17:18] <slangasek> cjwatson: livecd-rootfs accepted
[17:18] <xnox> stgraber: yeah, so ubiquity-gtk frontend will be exercised ;-)
[17:28] <cjwatson> slangasek: thanks
[17:35] <infinity> cjwatson: Oh, FWIW, verified over the weekend that the britney hack for d-i/udeb block/pass works fine.  So, that takes some pressure off d-i upload timing.
[17:35] <slangasek> block/pass/pick/fumble/touchdown
[17:35] <infinity> I don't understand, that's not hockey.
[17:36] <cjwatson> Good good, thanks.  (Not that I was feeling the pressure anyway, I must say; the worst case was NBS.  The difficult sync is between d-i and seeds ...)
[17:38] <infinity> cjwatson: Yeah, seeds are a bit sketchy still.  I've been trying to time my seed updates to when d-i hits disk on ftpmaster, which isn't an ideal thing for normal mortals to try to do. :P
[17:39] <infinity> cjwatson: Maybe that could do with some rethinking.  I was going to use the word "automation", but I don't really want automated commits to seed branches.
[18:01] <cjwatson> infinity: Quite.
[18:01] <cjwatson> infinity,slangasek: I've fixed britney to require at least one up-to-date binary on at least one architecture before promotion, regardless of any exceptions for slow architectures.
[18:02] <infinity> cjwatson: That should do.  Thanks.
[18:03] <slangasek> sounds good
[18:17] <ScottK> heka had a chroot problem failure, but it must have been gremlins/cosmic rays because the retry hit heka again and worked fine.
[18:19] <infinity> When we finally get decent ARM buildds, I intend to send a Panda from the DC to every member of ~launchpad-buildd-admins and ~ubuntu-release to mutilate as they please.
[18:19] <micahg> infinity: can I get on the list for one please :)
[18:20] <infinity> Heh.
[18:21] <infinity> micahg: I see your firefox finally built. :P
[18:21] <micahg> infinity: yeah, last time it muttered about a \37....
[18:21]  * micahg didn't ask it to fnid Amelia Earhart, just to build firefox...
[18:35] <slangasek> infinity: mutilating machines that contain no spinning parts is way less fun
[18:36]  * ScottK looks around for some spare dynamite.
[18:36] <ScottK> Depends on how you do it.
[18:36] <sbeattie> slangasek: the point is to make the parts that are not spinning spin.
[18:36] <sbeattie> or at least, that's what I go for.
[18:36] <sbeattie> YMMV and all that.
[18:40] <ogra-cb> its pandaboards, you can just make them spin completely with pretty low effort
[19:38] <ScottK> This proposed thing is handy when a package update gets uploaded to the archive instead of a PPA by mistake ...
[19:39] <slangasek> heh
[20:24] <ScottK> Which package owns the first startup screen in the installer (the one that Ubuntu doesn't show by default, where you, for example, set up an OEM install)?
[20:26] <infinity> Sounds like ubiquity.
[20:27] <infinity> Do you have a string from said screen?
[20:27] <ScottK> "Boot from first hard disk"
[20:27] <ScottK> That one is particularly relevant because it's trying to boot from my USB stick again.
[20:27] <infinity> Oh, pre-boot?
[20:27] <ScottK> Yes.
[20:28] <ScottK> The one that you have to hold shift down in Ubuntu to see.
[20:28] <infinity> That would be syslinuxish, though the actual menus don't come from syslinux.
[20:28] <ScottK> So in the case of picking the wrong thing to boot from, what package do I blame?
[20:28] <infinity> I'm trying to sort that out...
[20:29] <ScottK> Thanks.
[20:29] <slangasek> your bios? :)
[20:29] <infinity> debian-cd writes the menus.
[20:29] <infinity> label hd
[20:29] <infinity>   menu label ^Boot from first hard disk
[20:29] <infinity>   localboot 0x80
[20:29] <slangasek> "Boot from first hard disk" is done via BIOS calls; if the "first hard disk" it's booting isn't the one you want, that's a BIOS issue
[20:29] <infinity> And yeah, that's just booting 0x80, so if your BIOS is remapping your stick, that's correct.
[20:30] <infinity> And it's arguably correct for your BIOS to remap your stick when you select it as the boot device.
[20:30] <ScottK> Hmmm.
[20:30] <infinity> (Though this behavious varies wildly between machines)
[20:30] <slangasek> solution: upgrade your firmware to UEFI
[20:30] <infinity> behaviour, too.
[20:30] <slangasek> then you can't run syslinux at all, problem solved
[20:30] <infinity> Hahaha.
[20:30] <infinity> "solved".
[20:30] <ScottK> So does this option actually do any good?
[20:31] <infinity> ScottK: It made a lot more sense on CDs, which were never remapped.
[20:31] <ScottK> Right.
[20:31] <infinity> ScottK: And it makes sense for people who burn our images to DVDs (same argument).
[20:31] <slangasek> right, if the issue is that you're booted *from* the USB stick, it should probably detect that and translate it to 0x81 instead
[20:31] <infinity> That's probably still more common than USB sticks, except for serial reinstallers.
[20:32] <ScottK> slangasek: That sounds sensible.
[20:32] <infinity> slangasek: That's a fair chunk of extra magic to ask of syslinux.
[20:32] <slangasek> IIRC the same el-torito boot image is used for both CD and hybrid USB booting, so this magic would have to be in syslinux
[20:33] <slangasek> infinity: it doesn't hurt to ask
[20:33] <ScottK> Also it doesn't have to detect it's a USB, it would have to detect that the device it's about to try to boot from is the same one it's already booted from.
[20:33] <infinity> But yeah, one could do an "if current device = 0x80, shift all menu lookups by 1" or something.  I guess.
[20:33] <infinity> I'm not sure if it can even reliably know this.
[20:33] <ScottK> From the discussion, it seems like that would do it.
[20:34] <infinity> Not without more code than it has room to run.
[20:34] <infinity> Still, yeah, a mildly annoying buglet.
[20:37] <ScottK> I'll file it and then it will be what it will be.
[20:39] <ScottK> Turns out there is an existing bug.
[20:42] <infinity> Hrm.
[20:42] <infinity> Looks like "localboot -1" triggers int 18h, which should force your BIOS to try the next boot device.
[20:43] <infinity> Of course, that's likely wildly buggy from machine to machine as well.
[20:44] <infinity>                 cmp ax,-1
[20:44] <infinity>                 je .int18
[20:44] <infinity> .int18:
[20:44] <infinity>                 int 18h                         ; Hope this does the right thing...
[20:44] <infinity>                 jmp kaboom                      ; If we returned, oh boy...
[20:45] <infinity> Such faith in his own code there...
[20:45] <ScottK> Heh.
[20:45] <ScottK> Bug #1066387 in case you want some place to document findings.
[20:45] <ubot2> Launchpad bug 1066387 in syslinux (Ubuntu) "D-I install menu, select "Boot from first hard disk" and it goes back to Language selection" [Medium,Triaged] https://launchpad.net/bugs/1066387
[20:51] <ScottK> BTW, the continuous quality push seems to be showing.  I got through all the Kubuntu test cases for i386 with  no failures.
[20:51] <infinity> \o/
[20:55] <ScottK> The syslinux thing was the 2nd most annoying bug I found.
[20:57] <infinity> That bug's been around forever, so hardly counts.  What was the first most annoying bug?
[20:59] <ScottK> http://launchpad.net/bugs/1086047
[20:59] <ubot2> Launchpad bug 1086047 in qapt (Ubuntu) "Firefox installer fails in raring" [High,Fix released]
[20:59] <ScottK> The Kubuntu package install mechanism was broken.
[21:00] <ScottK> (for adding specific packages)
[21:00] <infinity> Ahh.
[21:00] <ScottK> qapt-batch
[21:00]  * infinity nods.
[21:24] <persia> re: bug 1066387 : what problem is the "boot from first HD" option attempting to solve
[21:24] <ubot2> Launchpad bug 1066387 in syslinux (Ubuntu) "D-I install menu, select "Boot from first hard disk" and it goes back to Language selection" [Medium,Triaged] https://launchpad.net/bugs/1066387
[21:25] <slangasek> persia: to let you boot from the hard drive if you've accidentally left the CD in the drive
[21:26] <slangasek> without having to reboot and/or fiddle
[21:26] <persia> Given that it won't work with any machines that have a preinstall of Windows 8 or OS X > 10.6, how much longer should this remain relevant?
[21:27] <persia> (plus we did tell the user to remove the CD in order to perform the reboot, although some hardware lets one ignore this)
[21:28] <slangasek> persia: any machines that have a preinstall of Windows 8 won't see syslinux at all
[21:29] <slangasek> I don't know that this bug is anything we're going to invest time in fixing
[21:29] <slangasek> but I think it's true that it's a bug
[21:32] <persia> Makes sense: rather than trim syslinux to just not show this for the dwindling use case, leave it as a known issue, and let it expire as BIOS becomes irrelevant.
[21:33]  * ScottK doesn't have a strong opinion about fixing/removing, but thinks one of them should happen.
[21:38] <cjwatson> Ultimately the boot menu needs to move to GRUB for all architectures, but it's a non-trivial chunk of work to migrate the menu interface over.
[21:38] <cjwatson> Something I've tried to push up the hill before.  It may get higher-priority as UEFI becomes more common.
[21:39] <cjwatson> If we do it for UEFI then we can ditch syslinux across the board and rejoice.
[21:39] <cjwatson> Longish-term plan though.
[21:39] <persia> What produces txt.cfg?  I don't see it in the syslinux source.
[21:41] <slangasek> I believe that's in the debian-cd branch
[21:43] <cjwatson> Either that or debian-installer.
[21:48] <stgraber> ScottK: so I'm assuming you don't want your 21:00 UTC respin?
[21:48] <ScottK> stgraber: We do.  I want the newer qapt in.
[21:49] <ScottK> The qapt-batch bug didn't cause the test case to fail, but it's still a significant bug.
[21:49] <stgraber> ScottK: ok, so should I kick a respin now?
[21:50]  * ScottK is lost in TZ math.
[21:50] <stgraber> it's 21:48 UTC :)
[21:50] <stgraber> or :50 even
[21:50] <ScottK> Right.
[21:50] <ScottK> So if the 2100 respin is out of date for qapt, yes.  Please.
[21:50] <persia> It is in debian-cd, although in the branch, and not the package.  From infinity's suggestions, I get the impression that the bug should be retargeted, but I'm not sure of the semantics of that, as it's not in the debian-cd ubuntu package, nor in the debian-cd trunk branch on LP.  Can we do specific branch-targeting of bugs?
[21:51] <persia> (unless someone believes it to actually be a bug in syslinux code)
[21:52] <slangasek> it's a limitation of syslinux code
[21:52] <slangasek> well, or there's that -1 option, isn't there
[21:53] <slangasek> so I'm actually not sure how that works when you've got a mapped eltorito image
[21:53] <persia> What's the limitation in syslinux?  If it's being told to boot 0x80, and it does, why is this wrong?
[21:55] <slangasek> because 0x80 is the disk you just booted from
[21:55] <slangasek> so boot 0x80 is a loop
[21:56] <slangasek> I'm not sure you can properly solve this is a hybrid-friendly manner in bios
[21:57] <persia> Sure.  I agree it's a bug.  I'm just not convinced it's a syslinux bug, but rather a debian-cd bug.
[21:57] <persia> I'm not sure why syslinux shouldn't boot from BIOS-mapped first hard drive when instructed to "localboot 0x80"
[21:58] <slangasek> persia: er, show me how you can tell syslinux to dtrt
[21:58] <slangasek> it's a debian-cd bug iff there's already a way to express this to syslinux
[21:59] <slangasek> anyway, the place to target would be the ubuntu-cdimage project
[22:00] <persia> Ah, OK.  Not having hardware that does such BIOS mapping, I'll leave that alone then (as I can't test the -1 option).
[22:00] <infinity> I think the word "bug" is a bit harsh in this case.  Misfeature, perhaps. :P
[22:01] <infinity> The (potential) problem with switching to -1 is that some BIOSes, upon remap, may remove your HDD entirely from the boot list, so 18h would trigger floppy, then fail.
[22:01] <infinity> But that's theoretical, since I have no idea what any one person's weird BIOS will do. :/
[22:02] <ScottK> But that's at least no worse off.
[22:02] <infinity> Barring that potential strange behaviour, though, 18h is probably what one actually expects to happen, since it's just the generic "this boot device sucks, fall through to the next" call.
[22:03] <infinity> 18h being what, for instance, PXE firmware will do when it fails to get a BOOTP server, etc.
[22:03] <cjwatson> persia: bugs on our debian-cd branch go on the ubuntu-cdimage project
[22:04] <cjwatson> oh, slangasek said that
[22:04] <persia> But you also saying it changes my mind to actually do the retarget, as opposed to wait longer for someone to test the -1 thing with appropriate hardware before retargeting.  It can always come back, if it turns out to really be a syslinux thing.
[22:04] <infinity> cjwatson: We could switch to -1, call it "Attempt to boot from next device..." and call it good. :P
[22:05] <cjwatson> We could.  I'm not much interested, TBH :-)
[22:05] <cjwatson> I suspect that'll attract a different set of bugs.
[22:05] <infinity> Yeah, I don't really care deeply either way.  The obvious solution to "it doesn't work" is "remove the USB stick, doofus".
[22:06] <infinity> cjwatson: In the known-working case (CDs), -1/18h should work just as well.
[22:06] <cjwatson> Assuming sane BIOS ...
[22:06] <infinity> cjwatson: In the USB case, it'll likely just break in a different set of weird BIOS cases.
[22:08]  * infinity doesn't care terribly if it just stays kinda broken anyway, given that "I left the disk in the drive, oops" is a time-honored "I own a PC, and did a stilly thing" deal.
[22:08] <persia> Added an ubuntu-cdimage task: someone should set it to wontfix or switch to -1, and set it to fixreleased (and be willing to argue with folk about which is the right thing for follow-on reports).
[22:09] <infinity> Note that this isn't remotely a "new" bug.  Well, as new as the ability to boot USB thumb drives.
[22:09] <infinity> I don't see that dealing with it suddenly became urgent. :P
[22:11] <slangasek> that doesn't seem to be stopping anybody from talking it to death though :P
[22:14] <ScottK> slangasek: We could talk about systemd instead, if you'd prefer.
[22:14] <ScottK> ;-)
[22:14] <slangasek> doesn't bother me none
[22:15] <ScottK> It seems to be the recent driver for most extensive flogging of a dead horse I've seen lately.