=== Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [01:48] stgraber: Yes. [01:49] ScottK ok. Can you say so in the ubuntu-release@lists.u.c thread? [01:49] stgraber: Riddell already did. [01:50] 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] and there's nothing in the moderation queue [01:51] stgraber: do you know where the code is for http://reqorts.qa.ubuntu.com/reports/boot-speed/ by chance? [01:52] OK. Done. [01:52] cjohnston: nope [01:52] ScottK: thanks [01:52] Seems I mis-remembered. [01:52] No problem. [01:52] thanks stgraber [01:54] ScottK: APAC woke up, rocs is building belatedly on armhf/quantal-proposed now. [01:55] infinity: Thanks. [02:31] ScottK: When you get a moment, can you review and let the above hugetlbfs into lucid-backports? [02:31] Is it tested? [02:31] Yeahp. stokachu had it tested. [02:31] (So says the bug log) [02:35] Do backports uploads auto-close bugs, or do I need to do it manually? [02:35] * infinity goes to look. [02:35] No. They don't, but I already did it. [02:35] Ahh, thanks. [02:36] It wasn't actually even filed against backports. Fixed that too. [02:36] 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] Each release is a separate project in LP. [02:38] 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] my sent-mail says I sent it to stgraber directly, silly me [02:39] doesn't explain why he hasn't seen it but [02:40] I dunno about him, but I spam filter all mail with Scottish accents. [02:40] 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] jings and crivvens [02:41] Great, now I need to start filtering IRC. [02:42] Also, http://en.wiktionary.org/wiki/crivvens is brilliant: "See also: cripes and crikey". === henrix_ is now known as henrix === mmrazik is now known as mmrazik|lunch [11:05] Grr, getting live-build to install linux-generic-lts-quantal correctly is unexpectedly difficult === mmrazik|lunch is now known as mmrazik === doko__ is now known as doko === yofel_ is now known as yofel [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] 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] ogra-cb: i'd like to know where the chinese images are... [13:29] the bug points to them [13:29] http://china-images.ubuntu.com/raring/daily-live/current/ [13:30] its likely only a conicidence that they use the same timestamp format. but its irritating [13:31] The Chinese images use ubuntu-defaults-builder. [13:31] Which is based on live-build / livecd-rootfs, but another layer. [13:42] xnox, i would also see a bug in utah here ... it should eb able to handle such stamps too [13:43] (specifically because all arm images and images will have it) [13:43] (well, all preinstallled ones at least) [13:46] ogra-cb: sure, but ideally we standartise on some kind of parsable format. [13:48] 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] so there must be another format that still makes it possible ot have more than a build per day [13:49] 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] *your [13:58] ogra-cb: or the stamp can be yyyymmdd.HHMM [13:58] oh, sure [13:58] and that has ~ same machine parsability. [13:59] but that will require code changes all over the place if you want consistency [13:59] i.e. to make the download dirs use that [14:00] and i'm not sure we would want that (breaks likely lots of download scripts out there) [14:02] 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] (and to all other scripts indeed, but these are on teh same machine anyway) [14:07] xnox: i am seeing bug 1085961 when i do side by side installations [14:07] Launchpad bug 1085961 in ubiquity (Ubuntu) "Unable to install two raring desktops side-by-side" [Undecided,New] https://launchpad.net/bugs/1085961 [14:10] ogra-cb: I am not talking about urls, I am only talking about the format/regexp of the image/iso diskid. [14:10] ogra-cb: which we can use in ubiquity & utah etc. [14:11] xnox, usually that corresponds to the url [14:11] ogra-cb: no. all urls use current/ symlink. [14:11] 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] i.e. an iso from cdimage.u.c/daily/20121201.1 will have exactly that timestamp insiuude too [14:12] and i think thats wanted [14:12] current is just a link to the latest of these timestamped dirs [14:13] 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] preinstalled just got that added two weeks ago ... and simply because i couldnt come up with anything better [14:14] 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] chinese looks more like a bug [14:14] ack. [14:15] url != file is not ok, it is there because i introduced it lacking a better implementation [14:16] 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] which we dont do for preinstalled [14:16] ogra-cb: ack. [14:17] ogra-cb: and ubuntu-defaults builder should be fixed to generate more similarish timestamps. [14:17] 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] i dont mind replacing the dash with a dot for now ... but effectively it wont fix the bug [14:18] that can only be done by a bit of redesign [14:19] 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] 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. === mmrazik is now known as mmrazik|otp === Ursinha is now known as Ursinha-afk === mmrazik|otp is now known as mmrazik === mmrazik is now known as mmrazik|otp === mmrazik|otp is now known as mmrazik [15:54] infinity,slangasek: ^- livecd-rootfs 2.65.4 - YA in the secure boot saga [15:54] This time I've actually tested the image build (which is currently failing in precise :-/) === mmrazik is now known as mmrazik|afk_for_ [16:01] stgraber: Now that I created the Alpha 1 milestone in the tracker, is everything going to get added automatically? [16:02] It'd be nice to only have the Kubuntu stuff in there so people don't get confused. [16:02] ScottK: yeah, I still need to setup some scripts to avoid that ^ [16:02] was planning on doing that this afternoon :) [16:03] Excellent. [16:03] IIRC, that's not far off. [16:07] Has anyone decided on whether a partial britney freeze is needed, and if so of what package(set)s? [16:08] 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] cjwatson: I didn't get any request so far, so I'm hoping not === mmrazik is now known as mmrazik|afk [16:10] stgraber: Can we have the current images in there manually? [16:10] (for Kubuntu) [16:11] I added them manually when I set up the milestone. [16:11] ScottK: ok, added. [16:11] Thanks. [16:12] ScottK: you added them with an invalid version number (.0), so that's why I removed them earlier [16:12] Yes. I messed that bit up. I wasn't sure what to put in. Thanks for fixing. [16:13] 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] we'll have the final decision by 21:00 UTC [16:17] Cool. === yofel_ is now known as yofel === mmrazik|afk is now known as mmrazik [17:15] highvoltage: edubuntu added to the alpha-1 manifest, first builds will show up a bit after 21:00 UTC [17:18] cjwatson: livecd-rootfs accepted [17:18] stgraber: yeah, so ubiquity-gtk frontend will be exercised ;-) [17:28] slangasek: thanks [17:35] 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] block/pass/pick/fumble/touchdown [17:35] I don't understand, that's not hockey. [17:36] 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] 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] 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] infinity: Quite. [18:01] 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] cjwatson: That should do. Thanks. [18:03] sounds good [18:17] 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] 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] infinity: can I get on the list for one please :) [18:20] Heh. [18:21] micahg: I see your firefox finally built. :P [18:21] 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] infinity: mutilating machines that contain no spinning parts is way less fun [18:36] * ScottK looks around for some spare dynamite. [18:36] Depends on how you do it. [18:36] slangasek: the point is to make the parts that are not spinning spin. [18:36] or at least, that's what I go for. [18:36] YMMV and all that. [18:40] its pandaboards, you can just make them spin completely with pretty low effort [19:38] This proposed thing is handy when a package update gets uploaded to the archive instead of a PPA by mistake ... [19:39] heh [20:24] 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] Sounds like ubiquity. [20:27] Do you have a string from said screen? [20:27] "Boot from first hard disk" [20:27] That one is particularly relevant because it's trying to boot from my USB stick again. [20:27] Oh, pre-boot? [20:27] Yes. [20:28] The one that you have to hold shift down in Ubuntu to see. [20:28] That would be syslinuxish, though the actual menus don't come from syslinux. [20:28] So in the case of picking the wrong thing to boot from, what package do I blame? [20:28] I'm trying to sort that out... [20:29] Thanks. [20:29] your bios? :) === henrix is now known as henrix_ [20:29] debian-cd writes the menus. [20:29] label hd [20:29] menu label ^Boot from first hard disk [20:29] localboot 0x80 [20:29] "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] And yeah, that's just booting 0x80, so if your BIOS is remapping your stick, that's correct. [20:30] And it's arguably correct for your BIOS to remap your stick when you select it as the boot device. [20:30] Hmmm. [20:30] (Though this behavious varies wildly between machines) [20:30] solution: upgrade your firmware to UEFI [20:30] behaviour, too. [20:30] then you can't run syslinux at all, problem solved [20:30] Hahaha. [20:30] "solved". [20:30] So does this option actually do any good? [20:31] ScottK: It made a lot more sense on CDs, which were never remapped. [20:31] Right. [20:31] ScottK: And it makes sense for people who burn our images to DVDs (same argument). [20:31] 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] That's probably still more common than USB sticks, except for serial reinstallers. [20:32] slangasek: That sounds sensible. [20:32] slangasek: That's a fair chunk of extra magic to ask of syslinux. [20:32] 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] infinity: it doesn't hurt to ask [20:33] 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] But yeah, one could do an "if current device = 0x80, shift all menu lookups by 1" or something. I guess. [20:33] I'm not sure if it can even reliably know this. [20:33] From the discussion, it seems like that would do it. [20:34] Not without more code than it has room to run. [20:34] Still, yeah, a mildly annoying buglet. [20:37] I'll file it and then it will be what it will be. [20:39] Turns out there is an existing bug. [20:42] Hrm. [20:42] Looks like "localboot -1" triggers int 18h, which should force your BIOS to try the next boot device. [20:43] Of course, that's likely wildly buggy from machine to machine as well. [20:44] cmp ax,-1 [20:44] je .int18 [20:44] .int18: [20:44] int 18h ; Hope this does the right thing... [20:44] jmp kaboom ; If we returned, oh boy... [20:45] Such faith in his own code there... [20:45] Heh. [20:45] Bug #1066387 in case you want some place to document findings. [20:45] 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] BTW, the continuous quality push seems to be showing. I got through all the Kubuntu test cases for i386 with no failures. [20:51] \o/ [20:55] The syslinux thing was the 2nd most annoying bug I found. [20:57] That bug's been around forever, so hardly counts. What was the first most annoying bug? [20:59] http://launchpad.net/bugs/1086047 [20:59] Launchpad bug 1086047 in qapt (Ubuntu) "Firefox installer fails in raring" [High,Fix released] [20:59] The Kubuntu package install mechanism was broken. [21:00] (for adding specific packages) [21:00] Ahh. [21:00] qapt-batch [21:00] * infinity nods. [21:24] re: bug 1066387 : what problem is the "boot from first HD" option attempting to solve [21:24] 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] persia: to let you boot from the hard drive if you've accidentally left the CD in the drive [21:26] without having to reboot and/or fiddle [21:26] 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] (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] persia: any machines that have a preinstall of Windows 8 won't see syslinux at all [21:29] I don't know that this bug is anything we're going to invest time in fixing [21:29] but I think it's true that it's a bug [21:32] 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] 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] Something I've tried to push up the hill before. It may get higher-priority as UEFI becomes more common. [21:39] If we do it for UEFI then we can ditch syslinux across the board and rejoice. [21:39] Longish-term plan though. [21:39] What produces txt.cfg? I don't see it in the syslinux source. [21:41] I believe that's in the debian-cd branch [21:43] Either that or debian-installer. [21:48] ScottK: so I'm assuming you don't want your 21:00 UTC respin? [21:48] stgraber: We do. I want the newer qapt in. [21:49] The qapt-batch bug didn't cause the test case to fail, but it's still a significant bug. [21:49] ScottK: ok, so should I kick a respin now? [21:50] * ScottK is lost in TZ math. [21:50] it's 21:48 UTC :) [21:50] or :50 even [21:50] Right. [21:50] So if the 2100 respin is out of date for qapt, yes. Please. [21:50] 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] (unless someone believes it to actually be a bug in syslinux code) [21:52] it's a limitation of syslinux code [21:52] well, or there's that -1 option, isn't there [21:53] so I'm actually not sure how that works when you've got a mapped eltorito image [21:53] What's the limitation in syslinux? If it's being told to boot 0x80, and it does, why is this wrong? [21:55] because 0x80 is the disk you just booted from [21:55] so boot 0x80 is a loop [21:56] I'm not sure you can properly solve this is a hybrid-friendly manner in bios [21:57] 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] I'm not sure why syslinux shouldn't boot from BIOS-mapped first hard drive when instructed to "localboot 0x80" [21:58] persia: er, show me how you can tell syslinux to dtrt [21:58] it's a debian-cd bug iff there's already a way to express this to syslinux [21:59] anyway, the place to target would be the ubuntu-cdimage project [22:00] 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] I think the word "bug" is a bit harsh in this case. Misfeature, perhaps. :P [22:01] 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] But that's theoretical, since I have no idea what any one person's weird BIOS will do. :/ [22:02] But that's at least no worse off. [22:02] 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] 18h being what, for instance, PXE firmware will do when it fails to get a BOOTP server, etc. [22:03] persia: bugs on our debian-cd branch go on the ubuntu-cdimage project [22:04] oh, slangasek said that [22:04] 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] cjwatson: We could switch to -1, call it "Attempt to boot from next device..." and call it good. :P [22:05] We could. I'm not much interested, TBH :-) [22:05] I suspect that'll attract a different set of bugs. [22:05] 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] cjwatson: In the known-working case (CDs), -1/18h should work just as well. [22:06] Assuming sane BIOS ... [22:06] 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] 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] Note that this isn't remotely a "new" bug. Well, as new as the ability to boot USB thumb drives. [22:09] I don't see that dealing with it suddenly became urgent. :P [22:11] that doesn't seem to be stopping anybody from talking it to death though :P [22:14] slangasek: We could talk about systemd instead, if you'd prefer. [22:14] ;-) [22:14] doesn't bother me none [22:15] It seems to be the recent driver for most extensive flogging of a dead horse I've seen lately.