[00:19] ev: Speaking of jockey, how crackful would it be to run jockey-text -a when the live session starts up? If I do that by hand I get working wifi in the live session on my broadcom based netbook. [05:56] ScottK, without a user agreeing to do it, probably not the best thing to do on the live session [08:53] ubiquity: superm1 * r4307 ubiquity/ (debian/changelog ubiquity/frontend/noninteractive.py): Restore the functionality of the noninteractive frontend. [09:12] ev: I don't know if you *can* dpkg-divert away a trigger [09:12] ev: I'm not entirely averse to introducing a way to suppress it via an environment variable [09:13] can dpkg-divert> ah, I hadn't considered that possibility :) [09:13] cjwatson: in the trigger itself? [09:13] sounds reasonable to me if all else fails [09:49] hi all ppl [09:50] anybody not afk? [09:51] i have a problem, probably you could help, i need the installer to leave alone one of the MBRs in my system [09:51] but it persists on messing up with it [09:51] erupter: is this Maverick? [09:53] dunno, kubuntu 10.04 [09:53] if you have time, i would explain more clearly [09:54] erupter: oh, there's an advanced button on the summary page, before you click the final install button [09:54] in the dialog that appears is a checkbox to either install or not install the bootloader [09:54] if you uncheck it, the bootloader wont be installed [09:55] ok but if i don't do that then how can i access the linux install? [09:55] my problems aroused because i have a software raid array (intel ich9) and a spare disc [09:56] i set up the bios to use the spare as boot disc (this usually works for windows installations) [09:56] but after installing the distro i ended up with the bootloader on my raid array [09:56] and neighter oses booting [09:57] in that dialog you can also pick which disk or partition you want to install the bootloader to [09:58] ok i'll try then thaks [09:58] hope this helps me :p [09:58] sure thing [09:58] have a nice day [10:13] you too [10:18] ev: yeah [10:20] looks like it hangs on loading... [10:20] it has installed and has started as it should but now it has hang with the kubuntu loading screen... [10:21] ubiquity: evand * r4308 trunk/ (4 files in 3 dirs): Add back the hostname entry (LP: #628087). [10:23] I still have to do the dmidecode dance, just wanted to get things back to a sane state first. [10:23] oh and fix the KDE hostname bug. [10:24] ok looks like it's now starting... [10:28] ev, So, which value from dmidecode are you using? [10:29] persia: I'm not sure. Is there a field that is more often set than not? Family? [10:31] Values for Family for a couple machines that support dmidecode here are "To Be Filled By O.E.M." and "Other" [10:32] We could filter those out, or are you making the point that there are lots of bogus values? [10:32] I think Chassis/Type is closest, but I have one machine with the value "Lunch Box" there, so I'm not sure it's well standardised. Also seems an even mix of "Desktop" and "Desktop Case" [10:33] the idea is to use something somewhat unique [10:33] I take it as a given there are lots of bogus values for every dmidecode entry. That said, having irregular hardware, I'd like to help you find one that is more sensible, and make sure we can support it (e.g. contains spaces) [10:33] so if I install Ubuntu on several devices, I don't end up with the same hostname [10:33] unique but still attractive* [10:33] Right. I think Chassis/Type is probably cleanest, as long as we can support spaces (swich to more hypens, maybe?) [10:34] indeed, spaces would be subbed with hyphens [10:34] I have "Notebook" for Chassis Type though. [10:34] I'd recommend limiting to ~15 characters, to avoid matching "To Be Filled By O.E.M." [10:34] fairly generic [10:34] 15 characters> good idea [10:34] Yeah, but "ev-notebook" vs. "ev-desktop" vs. "ev-lunch-box" allows some differentiation. [10:35] sure, but is there no field that would give us something like ev-thinkpad-x61 [10:35] Is version often not set? [10:35] Chassis/Version? [10:35] not set here [10:35] system version is [10:36] (mind you I haven't read through the spec, I'm just going off how dmidecode the binary prints this) [10:37] System/version is "001", "To Be Filled by O.E.M", "1.0" on the dmidecode capable machines on my desk. [10:37] * persia also [10:37] System/Family looks better here "CFY7-1", "To Be Filled By O.E.M", "Macmini" [10:38] ah, system family works [10:38] as that's thinkpad x61 as well [10:38] I'll do a quick survey of Millbank [10:38] Good plan. [10:38] to make sure at least the major have it set [10:38] Next bit: what about machines that don't have dmidecode? [10:39] we fall back to username-{desktop,laptop} [10:39] where desktop/laptop is determined by laptop-detect [10:39] How do we make that determination? [10:39] Ah, OK. [10:40] Hrm. Seems that relies on either having a battery interface *OR* having dmidecode. [10:41] Anyone know if there's a reliable way to get the used blocks on any supported linux filesystem without actually mounting it? Something in the superblock perhaps? [10:41] persia: battery interface? The path is try dmidecode, if that fails or doesn't exist, try running laptop-detect (which we've always run to determine the hostname). [10:42] Right. laptop-detect checks for batteries, and runs dmidecode. [10:43] ah, so then your argument is to not try laptop-detect at all and simply go straight to ubuntu-desktop? [10:43] No. I've no argument at all. [10:43] :) [10:43] I have an unsolved issue of what to do with devices with unused battery interfaces (e.g. the ARM boards folks are using) [10:43] Not supporting them cleanly is *not* a regression, but now that I understand the path, there's a chance of possibly supporting them in the future. [10:44] gotcha [10:44] Might also affect small home-built whatevers. Or some NAS boxes that have built-in batteries as internal semi-UPS, etc. [10:45] FWIW on my Dell Latitude D830, System/Family is blank, System/Manufacturer is "Dell Inc.", System/Product Name is "Latitude D830", Chassis/Type is "Portable" [10:46] I imagine you'll want fallbacks or something [10:47] System/Product Name looks good here: "CF-Y7AW1AXS", "Macmini3,1", "To Be Filled By O.E.M." (the last would be too long, and fall back to "desktop") [10:47] good call [10:47] Base Board/Product Name also has full support here "MacF22C86C8", "CFY7-1", "MCP7A-ION" [10:48] "0HN341" [10:48] That's not very informative. [10:48] and on my server, "i440BX-W83977 (BH6 V1.1)" [10:48] Do servers get the same logic applied? [10:49] Either of you have any thoughts on the filesystem question, or is that a lost cause? [10:49] which also has blank System/Product Name and System/Manufacturer, no System/Family at all, and Chassis/Type "Desktop", so that's probably a bit of a loss [10:49] ev: Why the "without mounting it" requirement? [10:49] well, it was originally a desktop :-) [10:49] I'm not too concerned about servers ;) [10:49] Ah :) [10:49] * persia thinks most server folk set hostname via DNS in advance anyway [10:49] you want to avoid mounting filesystems so that you don't replay journals [10:49] if possible [10:49] soren: don't we have issues with replaying journals on hibernated systems? [10:49] ah, beat me to it [10:50] libparted might be able to tell you? [10:50] for what it's worth, this is for the resize widget in the partitioner, saying "Files, X GB used" instead of "Unknown operating system" [10:50] Just use blockdev to set it to read-only? [10:50] ev: I thought partman already had an interface for that [10:50] I thought the d-i team tried that and it failed spectacularly [10:50] blockdev --setro, that is [10:51] d-i should use blockdev, there were just some tedious things to deal with [10:51] ev: Exactly. [10:51] but anyway, I don't think you need to go down that route [10:51] this is what the resize range stuff in partman is for [10:51] and I thought that ubiquity already interpreted that [10:51] ah, I thought it just shelled out to resize2fs for that [10:52] or are you saying, use the lower bound as the size used [10:52] err upper bound [10:52] that's what I'm saying, yes [10:52] errr partition size - upper bound [10:52] coffee, need cofee [10:52] awesome [10:52] thanks everyone [10:52] the value you get as the minimum resizable size of the filesystem is as near as damnit the size used [10:53] I mean, it does shell out to tune2fs in the case of ext[234], but that's the information you want anyway [10:53] and best to avoid ext2-specific code in ubiquity IMO [10:53] indeed [10:53] brilliant [11:09] ev, please dont forget that dmidecode only works on systems with a BIOS [11:09] ogra: indeed, that's why we have the fallback [11:10] and thanks so much for adding the hostname feature back :) [11:13] sure thing. I still want to ultimately get rid of it, but clearly we're not ready yet [11:14] yeah [11:14] sabdfl wants this as part of the solution: https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/634187 [11:14] Launchpad bug 634187 in ubiquity (Ubuntu) "Detect hostname collisions using avahi (affects: 1) (heat: 6)" [High,Triaged] [11:14] ogra, If you have any bright ideas on how to make laptop-detect more robust to do more than just check for batteries or Chassis/Type=="Notebook"|"Portable" or to try to differentiate phone/handheld/netbook/laptop/desktop or just differentiate dev boards, it may be interesting. [11:15] we could have a BOF at UDS ;) [11:15] i dont have bright ideas beyond either a database or parsing additional info from i.e. /proc/cpuinfo (on arm for example) [11:16] ev, Do you think you'd have time at UDS to participate in such a thing, or would you not care, as long as we can produce useful strings? [11:17] I'm most concerned about having useful strings, but if you think it would be helpful for me to be there, put me as required and I'll make the time.l [11:18] Up to you :) If we have such a spec, I'll definitely at least subscribe you (and let you select whether you are required) [11:20] okay [11:22] well, on arm the useful strings live in the hardware line of /proc/cpuinfo usually (thats also where all other tools look) [11:23] i guess its up to the arm team to develop and supply such a püatch once the function is there :) [11:24] The same kind of thing ought work for powerpc as well, although there may be better sources of information. [11:24] yes, ppc has nvram to read from iirc [11:25] on arm cpuinfo is the only common thing among all boards [11:26] At least on my powerpc machines, cat /proc/cpuinfo is likely to have more human-readable information on the device that the output of nvsetenv. [11:26] Anyway, let's save this discussion until *after* release :) [11:46] ubiquity: evand * r4309 trunk/ (debian/changelog ubiquity/plugins/ubi-partman.py): [11:46] ubiquity: * Use a block device icon for cases where we cannot detect the [11:46] ubiquity: operating system on a partition. [11:46] ubiquity: * Set the amount of used space on a partition that we presume contains [11:46] ubiquity: no operating system (LP: #626299). [12:11] superm1: You're probably right (re restricted drivers in live session). Something to consider for the next UDS for design. [13:51] :q [13:51] whoops [14:16] ubiquity: evand * r4310 trunk/ (debian/changelog gui/gtk/stepUserInfo.ui): [14:16] ubiquity: Make requiring a password to log in the default again, matching the [14:16] ubiquity: behavior in the previous version of Ubuntu. [14:19] ubiquity: evand * r4311 trunk/debian/ (changelog ubiquity.templates): Use the correct string for the resize partition option. [15:33] ubiquity: evand * r4312 trunk/ (3 files in 3 dirs): [15:33] ubiquity: Set the size of the disk on the automatic partitioning page [15:33] ubiquity: (LP: #626299). [16:01] ev, re dpkg-diverting the trigger, its a live filesystem - you can probably just rm it can't you? [16:01] well, I wanted to undo the change afterwards [16:01] it's not like you are making that change in /target though [16:01] but if you want to undo it, just mv it to trigger.old to run jockey, and move it back? [16:02] sure, though I'm going to try Colin's suggestion of adding a flag to man-db [16:02] just as soon as I finish with building a big table of common locations for the product name in DMI [16:02] superm1: I don't suppose you know where they occur on all of your systems? [16:03] /sys/class/dmi/id/product_name [16:03] is it always system product name? [16:03] it should always be that directory, first half is line of business (eg vostro, inspiron, etc) and second half is model number [16:04] I'm assuming you mean file [16:04] but noted [16:04] thanks! [16:05] yeah i mean that file [16:05] re persia's recommendation to only cover up to 15 characters long names, i'm not sure that would continue to work. if you go an look at something like Latitude E6410XFR, that would be too long [16:06] so probably better to just filter out those bad ones like To Be Filled by O.E.M [16:06] indeed, will do [16:17] ScottK, well as you saw that for the newer generation of broadcom cards they've been open sourced, hopefully it becomes less of something that needs to be worried about over time [16:17] superm1: True. [16:17] OTOH, all the hard work is done now, it's a shame not to take advantage of it. [16:33] I had a chat with the kernel team about this. The new driver doesn't work with 42XX and non-SSB adapters as I understand it, equally it will be a post-release thing, so we couldn't take advantage of it in the installer anyway. [17:01] debian-installer: cjwatson * r1358 ubuntu/ (build/config/armel/dove.cfg debian/changelog): Move dove to 2.6.32-410 kernels. [17:35] ubiquity: evand * r4313 trunk/ (3 files in 3 dirs): [17:35] ubiquity: Use dmidecode to get a more unique suffix for the hostname [17:35] ubiquity: (LP: #628087). [17:53] debian-installer: cjwatson * r1359 ubuntu/debian/changelog: releasing version 20100211ubuntu25 [17:54] ubiquity: evand * r4314 trunk/ (debian/changelog ubiquity/plugins/ubi-usersetup.py): [17:54] ubiquity: Also generate a sample hostname when generating a sample username [17:54] ubiquity: (LP: #634279). [18:00] cjwatson: given bug #635040, what are your thoughts on not raising that exception anymore? [18:00] Launchpad bug 635040 in ubiquity (Ubuntu) "ubiquity crashed during install - no bootloader (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/635040 [18:00] the "oh bother, no bootloader" one, that is. [18:05] I guess we could demote it to a log message, yes. But why's it happening here? armel/dove is supposed to be handled by the flash_kernel component. [18:06] we're hitting an else that suggests that archdetect is producing the wrong output? [18:08] indeed, followed up in the bug [18:45] ubiquity: evand * r4315 trunk/ (3 files in 3 dirs): [18:45] ubiquity: Only set the next button to 'Install Now' when not on the first [18:45] ubiquity: partitioning page. [23:18] ev, Thought on data source validation: checkbox runs dmidecode: it may be that there's thousands of values stored in the checkbox DB in LP (helps find bad values to filter, strong candidates, etc.)