| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| ScottK | stgraber: Yes. | 01:48 |
|---|---|---|
| stgraber | ScottK ok. Can you say so in the ubuntu-release@lists.u.c thread? | 01:49 |
| ScottK | stgraber: Riddell already did. | 01:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| infinity | ScottK: APAC woke up, rocs is building belatedly on armhf/quantal-proposed now. | 01:54 |
| ScottK | infinity: Thanks. | 01:55 |
| 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:31 |
| 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:35 |
| 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:36 |
| 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:38 | |
| * 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:39 |
| 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:40 |
| Riddell | jings and crivvens | 02:41 |
| infinity | Great, now I need to start filtering IRC. | 02:41 |
| infinity | Also, http://en.wiktionary.org/wiki/crivvens is brilliant: "See also: cripes and crikey". | 02:42 |
| === henrix_ is now known as henrix | ||
| === mmrazik is now known as mmrazik|lunch | ||
| cjwatson | Grr, getting live-build to install linux-generic-lts-quantal correctly is unexpectedly difficult | 11:05 |
| === mmrazik|lunch is now known as mmrazik | ||
| === doko__ is now known as doko | ||
| === yofel_ is now known as yofel | ||
| * 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:24 |
| xnox | ogra-cb: i'd like to know where the chinese images are... | 13:28 |
| ogra-cb | the bug points to them | 13:29 |
| ogra-cb | http://china-images.ubuntu.com/raring/daily-live/current/ | 13:29 |
| ogra-cb | its likely only a conicidence that they use the same timestamp format. but its irritating | 13:30 |
| cjwatson | The Chinese images use ubuntu-defaults-builder. | 13:31 |
| cjwatson | Which is based on live-build / livecd-rootfs, but another layer. | 13:31 |
| ogra-cb | xnox, i would also see a bug in utah here ... it should eb able to handle such stamps too | 13:42 |
| ogra-cb | (specifically because all arm images and images will have it) | 13:43 |
| ogra-cb | (well, all preinstallled ones at least) | 13:43 |
| xnox | ogra-cb: sure, but ideally we standartise on some kind of parsable format. | 13:46 |
| 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:48 |
| 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:49 |
| 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:58 |
| 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 | 13:59 |
| ogra-cb | and i'm not sure we would want that (breaks likely lots of download scripts out there) | 14:00 |
| 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:02 |
| ogra-cb | (and to all other scripts indeed, but these are on teh same machine anyway) | 14:03 |
| 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:07 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| ogra-cb | url != file is not ok, it is there because i introduced it lacking a better implementation | 14:15 |
| 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:16 |
| 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:17 |
| ogra-cb | that can only be done by a bit of redesign | 14:18 |
| 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:19 |
| 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. | 14:34 |
| === 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 | ||
| 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 :-/) | 15:54 |
| === mmrazik is now known as mmrazik|afk_for_ | ||
| ScottK | stgraber: Now that I created the Alpha 1 milestone in the tracker, is everything going to get added automatically? | 16:01 |
| 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:02 |
| ScottK | Excellent. | 16:03 |
| ScottK | IIRC, that's not far off. | 16:03 |
| cjwatson | Has anyone decided on whether a partial britney freeze is needed, and if so of what package(set)s? | 16:07 |
| 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:08 |
| === mmrazik is now known as mmrazik|afk | ||
| ScottK | stgraber: Can we have the current images in there manually? | 16:10 |
| ScottK | (for Kubuntu) | 16:10 |
| ScottK | I added them manually when I set up the milestone. | 16:11 |
| stgraber | ScottK: ok, added. | 16:11 |
| ScottK | Thanks. | 16:11 |
| 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:12 |
| 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:13 |
| ScottK | Cool. | 16:17 |
| === yofel_ is now known as yofel | ||
| === mmrazik|afk is now known as mmrazik | ||
| stgraber | highvoltage: edubuntu added to the alpha-1 manifest, first builds will show up a bit after 21:00 UTC | 17:15 |
| slangasek | cjwatson: livecd-rootfs accepted | 17:18 |
| xnox | stgraber: yeah, so ubiquity-gtk frontend will be exercised ;-) | 17:18 |
| cjwatson | slangasek: thanks | 17:28 |
| 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:35 |
| 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:36 |
| 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:38 |
| 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. | 17:39 |
| 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:01 |
| infinity | cjwatson: That should do. Thanks. | 18:02 |
| slangasek | sounds good | 18:03 |
| 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:17 |
| 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:19 |
| infinity | Heh. | 18:20 |
| 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:21 | |
| slangasek | infinity: mutilating machines that contain no spinning parts is way less fun | 18:35 |
| * 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:36 |
| ogra-cb | its pandaboards, you can just make them spin completely with pretty low effort | 18:40 |
| ScottK | This proposed thing is handy when a package update gets uploaded to the archive instead of a PPA by mistake ... | 19:38 |
| slangasek | heh | 19:39 |
| 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:24 |
| infinity | Sounds like ubiquity. | 20:26 |
| 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:27 |
| 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:28 |
| ScottK | Thanks. | 20:29 |
| slangasek | your bios? :) | 20:29 |
| === henrix is now known as henrix_ | ||
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| infinity | Not without more code than it has room to run. | 20:34 |
| infinity | Still, yeah, a mildly annoying buglet. | 20:34 |
| ScottK | I'll file it and then it will be what it will be. | 20:37 |
| ScottK | Turns out there is an existing bug. | 20:39 |
| infinity | Hrm. | 20:42 |
| infinity | Looks like "localboot -1" triggers int 18h, which should force your BIOS to try the next boot device. | 20:42 |
| infinity | Of course, that's likely wildly buggy from machine to machine as well. | 20:43 |
| 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:44 |
| 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:45 |
| 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:51 |
| ScottK | The syslinux thing was the 2nd most annoying bug I found. | 20:55 |
| infinity | That bug's been around forever, so hardly counts. What was the first most annoying bug? | 20:57 |
| 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. | 20:59 |
| ScottK | (for adding specific packages) | 21:00 |
| infinity | Ahh. | 21:00 |
| ScottK | qapt-batch | 21:00 |
| * infinity nods. | 21:00 | |
| 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:24 |
| slangasek | persia: to let you boot from the hard drive if you've accidentally left the CD in the drive | 21:25 |
| 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:26 |
| 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:27 |
| slangasek | persia: any machines that have a preinstall of Windows 8 won't see syslinux at all | 21:28 |
| 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:29 |
| 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:32 |
| * ScottK doesn't have a strong opinion about fixing/removing, but thinks one of them should happen. | 21:33 | |
| 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:38 |
| 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:39 |
| slangasek | I believe that's in the debian-cd branch | 21:41 |
| cjwatson | Either that or debian-installer. | 21:43 |
| 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:48 |
| 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:49 |
| * 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:50 |
| persia | (unless someone believes it to actually be a bug in syslinux code) | 21:51 |
| slangasek | it's a limitation of syslinux code | 21:52 |
| slangasek | well, or there's that -1 option, isn't there | 21:52 |
| 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:53 |
| slangasek | because 0x80 is the disk you just booted from | 21:55 |
| slangasek | so boot 0x80 is a loop | 21:55 |
| slangasek | I'm not sure you can properly solve this is a hybrid-friendly manner in bios | 21:56 |
| 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:57 |
| 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:58 |
| slangasek | anyway, the place to target would be the ubuntu-cdimage project | 21:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| * 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:08 |
| 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:09 |
| slangasek | that doesn't seem to be stopping anybody from talking it to death though :P | 22:11 |
| ScottK | slangasek: We could talk about systemd instead, if you'd prefer. | 22:14 |
| ScottK | ;-) | 22:14 |
| slangasek | doesn't bother me none | 22:14 |
| ScottK | It seems to be the recent driver for most extensive flogging of a dead horse I've seen lately. | 22:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!