[01:51] How do I get past the installer being stuck at 15%? [01:55] Anybody there? [03:07] ubiquity: evand * r2438 ubiquity/ (6 files in 5 dirs): [03:07] ubiquity: * Validate the boot device string that the user provides on the [03:07] ubiquity: advanced page. [03:07] ubiquity: * Change the boot device Entry to a ComboBox that displays suitable targets. [06:30] ugh, pyqt is quite evil. [06:33] trying to implement the equivalent of that above commit for qt? [06:36] yeah, and weird language gotchas like having to str() qstrings [06:36] I just want a model with two columns, is that so much to ask for? [06:37] apparently :) [06:37] haha [06:38] you see why i opted for the mythbuntu frontend to derive off the gtk one then? I played with the qt designer for a little bit and decided it would be way to rough to work from [06:38] I used to know Qt quite well :/ [06:39] but yes, my brain can handle GTK much better [07:56] base-installer: soren * r322 base-installer/ (debian/changelog kernel/i386.sh): Add support for AMD CPU family 16 on i386. [09:08] speaking of GTK, if anyone knows how to implement a multi-column list in GTK where the columns flow newspaper-style rather than meaning different things, that'd be great [09:08] that is, it's only multi-column in that when it runs out of vertical space in one column it goes on to the next [09:29] cjwatson: I don't think there's a widget for that in GTK, but I guess you could use a regular TreeView and call gtk_tree_view_get_visible_* to determine how many rows are showing and then do it manually. === cjwatson_ is now known as cjwatson [10:40] soren: mm, that's the best I've come up with - it'll be nasty on resize though [10:44] I think I'll ask gtk-list if anyone has any sample code [11:38] how to be a member in ubuntu-installer@lists.ubuntu.com [11:38] ? [11:53] sridhar: https://lists.ubuntu.com/mailman/listinfo/ubuntu-installer [12:06] cjwatson: thanks [12:09] superm1: I'm looking at your preservehome branch at the moment, and comparing it with the adduser source [12:09] superm1: it seems to me that if you pass --gid to adduser it expects the group to exist already (although this isn't particularly documented) [12:09] superm1: did you test this and confirm it to work? [12:10] superm1: I think that you probably need to call addgroup explicitly if GIDOPT is set [12:23] does d-i run any scripts _before_ inittab is read? [12:23] outside the initrd [12:23] d-i runs entirely from its initrd so that question has no meaning ... [12:24] heh [12:24] rootskel/src/init [12:24] that does some stuff and then execs busybox init which reads inittab [12:24] :q [12:24] (oops) [12:25] basically just mounts /proc and creates some devices [12:25] oh, and mounts /dev to put said devices in, of course [12:27] I'm (again) thinking how it would be possible to disable the "convenience shells" run from inittab. maybe it would be too fugly to read a kernel parameter in rootskel/src/init and echo those tty-lines in a normal situation? [12:27] you could read a kernel parameter and have it sed -i /etc/inittab [12:27] to eliminate them [12:27] remind me why you're disabling them? [12:28] unattended installations on a public place [12:28] ok, hope you've locked the bootloader [12:28] sure [12:28] that's easy :) [12:28] netboot supports passwords now [12:28] I think honouring a 'noshell' parameter or similar would be fine [12:29] but the place to do it is in src/init? [12:29] yeah [12:29] ok cool, I'll make a debdiff [12:30] feel free to just commit and upload [12:30] heh, ok :) [12:30] bzr branch in the usual place [12:31] I'm so excited that Matt made all those fancy patches for syslog and sshkey-authentication for network-console :) [12:31] d-i will simply rock [12:31] oh, it already does btw [12:31] but even more === cjwatson_ is now known as cjwatson [12:43] 12:31 I'm so excited that Matt made all those fancy patches for syslog and sshkey-authentication for network-console :) [12:43] was the last thing I saw [12:43] tjaalton: yeah, it's pretty cool [12:43] 14:31 < tjaalton> d-i will simply rock [12:43] 14:31 < tjaalton> oh, it already does btw [12:43] 14:31 < tjaalton> but even more [12:43] :) [12:45] haha [13:10] cjwatson, I'd like to add hooks similar to lupin/casper into d-i, what would be a good place? initrd, rootskel or udeb? [13:10] the reason is to support distros that do not ship a live CD and to make it possible to have netinstall capabilities in the future [13:11] that depends. hooks for what? [13:11] 1 hook to set a local ISO skiping the stage where an ISO is looked for (mount it as /cdrom?) [13:12] 1 hook to do initrd preseeding using a file on local device [13:12] possibly keeping the same boot arguments [13:12] as in casper [13:17] haven't we done this before? this should use hd-media [13:17] I do not want to add this to the CD initrd [13:18] before I was using the initrd since I needed to do overrides of the ISO [13:18] of the d-i installer^ [13:18] d-i has multiple initrd variants [13:18] but I do not think it is necessary [13:18] anymore [13:19] I'd go for either rootskel/src/lib/debian-installer.d or a udeb to be called before initrd preseeding [13:19] rootskel is completely and utterly inappropriate [13:20] can you remind me when initrd preseeding kicks in (web interface is a pain to look code for) [13:20] that seems to leave udeb route [13:20] using a local ISO is already implemented by iso-scan [13:20] initrd preseeding using a file on a local device is a contradiction in terms [13:20] the purpose of initrd preseeding is to be entirely local to the initrd [13:21] I think I used to do to seed locale/layoutcode... but can do that via boot parameters anyway [13:21] indeed so [13:22] file-preseed runs after iso-scan and can already be used in hd-media mode to preseed from a file on a local device [13:22] it would be good then to specify the path/name of the ISO [13:22] would be good then to specify the path/name of the ISO/preseed [13:22] which takes precedence over standard paths [13:23] it would be reasonable for iso-scan to support preseeding of iso-scan/filename (which it already uses as an output) [13:24] it is already possible to set paramaters to look for a specific local path for preseeding correct? [13:24] yes [13:24] so that /path/to/preseed.cfg is looked for in all devices [13:25] err, no [13:25] only on things that are already mounted [13:25] and that depends on... [13:25] I am very cautious of things that run around mounting everything in d-i [13:26] they have been known to cause data loss [13:26] (e.g. hibernated partitions) [13:26] only a temporary mount is required, enough to copy over preseed (and possibly other files) then umounting [13:27] it's difficult to specify the linux device from windows [13:27] I know, but that doesn't really help matters [13:27] mounting a hibernated partition that uses a journalled filesystem is enough to corrupt it [13:28] also a ro mount? [13:28] yes [13:28] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=417407 suggests a scheme for avoiding this [13:28] Debian bug 417407 in os-prober "os-prober: protect partitions with "blockdev --setro"" [Important,Open] [13:28] doesn't the iso-scan mount partitions anyway [13:28] but one does have to be pretty careful [13:28] IIRC [13:28] that would be not much different [13:28] hmm, yeah, I suppose iso-scan does have that problem; yet another reason it is not in the cdrom initrd :) [13:29] the boot arguments currently used by casper would not be accepted into upstream d-i [13:30] I did warn you about this ages ago ;) [13:30] on my side the situation is that I have C:\path\to\ISO and C:\path\to\preseed.cfg and need to convey this info over to the installer [13:30] all d-i boot arguments used by udebs must correspond to debconf questions and must be properly namespaced [13:30] so if you want this in d-i there's going to have to be a transition [13:30] if you have any good idea on that I'd be more than happy to implement it [13:31] things implemented by iso-scan must generally be iso-scan/foo, etc. [13:31] casper of course has to use the initrd, while that is not required for d-i (as mentioned above), not sure if that helps matters [13:33] I can do iso-scan mods, that means though that I have to use hdmedia initrd as opposed to the one found in the alternate ISO, correct? [13:33] or do a netinstall skiiping isoscan (would still need preseed-scan though) [13:35] on a different topic, I do not know how I missed it for so long, but there is an nsis package in the archives [13:35] this greatly simplifies the build process [13:36] only thing is that I'd need v2.34 (now 2.33) since new code uses nsdialog interface which is much saner than previous implementations [13:39] at present, iso-scan fundamentally conflicts with the normal cdrom boot process [13:39] it might be possible to fix that in some way, but I haven't thought about it much and cannot guarantee that it's straightforward [13:40] can we have either one or the other accoring to boot arg maybe? [13:40] no [13:40] well, not right now [13:41] that would obviously be roughly the way to fix it but it needs some thought from a d-i developer to get it right [13:42] hdmedia initrd + iso would still work though (assuming I can push the changes to hdmedia) [13:42] iirc hdmedia also works for netinstallations [13:43] I'd be happy with that too [13:44] network installations should generally use the netboot initrd [13:45] hd-media doesn't include net-retriever [13:45] haven't looked at it in a while but thought that much functionality of netboot is also in hdmedia [13:45] net-retriever is kind of important :) [13:45] you can't get udebs from the network without it [13:46] then I didn't remember correctly... [13:47] any reason to have different initrds as opposed of having boot switches? wouldn't think that the size would change dramatically [13:49] they conflict [13:49] and actually the size is quite important and yes it does make a difference [13:49] different boot methods require different sets of kernel modules [13:50] the netboot initrd doesn't need block device drivers, for instance; it can retrieve those later [13:50] similarly the cdrom and hd-media initrds can save quite a bit of space by leaving out network drivers [13:55] I am fine with it, it only makes it slightly inconvenient for people that want to use wubi in offline mode [13:55] since on top of the ISO/CD they also need to get an appropriate initrd (but only in some cases) [13:56] I'm not saying it's perfect, just that there isn't a quick fix and that it needs some design work, that's all [13:56] to conclude then I'd gess the best route might be to add an iso-scan/path parameter that will affect hdmedia [13:57] iso-scan/filename (since the debconf question already exists) [13:57] yes, that seems like a fairly obvious first step [13:57] as for the preseed fetching I am a bit more cautious, I'd also need something similar to the above [13:58] does current local-device-preseed-fetching only affects hdmedia? [13:58] in case I can simply patch that [13:58] well, there isn't really such a thing right now [13:59] file-preseed knows how to fetch a preseed file from a specified path [13:59] (about to be on the phone for two hours, sigh) [14:00] can we change (in a backward compatible way) the path syntax so that I can specify ANYDEVICE/path/to/preseed.cfg? [14:01] I think it would be better to add a second question which says to do a device search, rather than to try to crowbar it into the syntax [14:08] see also ^ re nsis 2.34, I'll need to nag someone to have that in the archives... [14:27] cjwatson the above is certainly ok for hdmedia, but not for netinstall (if block device drivers are not there I am not sure how I can preseed it) [14:28] That is only an issue for dedicated partition installation, you mentioned that if I use a local ISO with hdmedia, repartitioning is an issue, does that still hold true? [14:57] yep [15:04] I assume that using "iso-scan/filename" also in casper is not acceptable since there is no iso-scan package. But would be nice to standardize on that [15:05] cjwatson, I didn't actually get to test it to confirm it works. I'll see if I can give that a go. [15:05] same with debian-installer/custom-installation (now in casper) [15:06] wich includes preseed [15:14] rootskel uploaded, hope I got it right the first time [15:23] iso-scan/filename in casper would be OK; casper already abuses namespaces somewhat for compatibility [15:26] ok I'll change that, I like it better than find_iso anyway [15:27] what about debian-installer/custom-installation within d-i? maybe scan-custom-installation/foldername? [15:27] I am on the phone but will get back to you later [15:27] sure [16:41] preliminary iso-scan "patch" to support preseeded filename http://paste.ubuntu-nl.org/54997/ [16:51] please follow local style in terms of indentation [16:52] (indent is one tab except for case patterns which are half-indent, i.e. four spaces, to keep the depth reasonable) [16:53] I think it would be better to just whack $DEVS and go through the normal code path, to avoid duplicating that code [16:53] Bug #189630 summarize above discussion [16:53] Launchpad bug 189630 in lupin "d-i/hdmedia should have hooks similar to the ones in lupin/casper" [Undecided,New] https://launchpad.net/bugs/189630 [16:53] and I really think this ought to be controlled by a separate preseeded variable which is off by default [16:54] you mean iso-scan/filename? [16:54] I don't mean $DEVS, sorry, I mean the output of the directory-scanning code in the inner loop [16:54] no [16:54] well, er [16:55] I just factored out try_dir since the same block would occur 3 times [16:55] oh, um, ok, maybe I misunderstood [16:55] could you send an actual patch once you can [16:55] can do that tonight [16:55] even a debdiff at that :P [16:56] I think rather than try_preseeded_filename you should just insert this into the loop that goes 'for iso in $dir/*.iso $dir/*.ISO; do' [16:56] and have it check iso-scan/filename first and only if it's not set then do that scan [16:57] then it doesn't really need any refactoring AFAICS [16:57] then it should go in "for dev in devs", since I only need to check once per dev [16:57] actually, probably should be around 'for dir in . *; do' [16:57] right [16:58] sorry, hard to read code while chairing a meeting ;) [16:58] np [17:03] xivulon: [17:03] 11:00:25 < TheMuso> evand: I think atm, a series of radio buttons, as thats all that can be done from gfxboot, and I don't think there is a need for more than one profile needed at the same time. [17:03] 11:00:43 < evand> TheMuso: fantastic, thanks [17:03] 11:00:48 < cjwatson> I actually implemented checkbox support in gfxboot-theme-ubuntu recently [17:03] 11:00:53 < cjwatson> in a hideously crude way but never mind [17:03] 11:01:01 < cjwatson> ("x " FTW) [17:04] 11:01:11 < evand> haha [17:04] 11:01:12 < TheMuso> cjwatson: I still don't think it makes sense in this context. [17:09] I'm having an odd, odd problem trying to build d-i.. [17:09] The symptom: [17:09] During get-packages, I get: [17:09] cyberorc: Helt sikkert. Har jævnt travlt, men det er ca. som forventet.The following packages have unmet dependencies: console-tools-udeb: Depends: libconsole (= 1:0.2.3dbs-65ubuntu6) but it is not installable [17:09] E: Broken packages [17:09] Whoops. [17:09] Only this bit: The following packages have unmet dependencies: console-tools-udeb: Depends: libconsole (= 1:0.2.3dbs-65ubuntu6) but it is not installable [17:09] * soren curses his mouse wheel [17:11] evand thanks, I am not convinced that 1 profile is enough but if the TheMuso says so, it's fine with me [17:13] I can't imagine what would make libconsole uninstallable. [17:21] grub-installer: evand * r724 grub-installer.ubuntu/ (debian/changelog grub-installer): [17:21] grub-installer: * Generate a device.map when bootdev_directory is set (loop [17:21] grub-installer: installations) (LP: #188460). Thanks Agostino Russo. [17:22] cjwatson: Hm... the sources.list.udeb doesn't list a regular main, only the d-i one.. How is it supposed to get its hands on libconsole? Is it supposed to be a build-dependency of d-i? [17:23] grub-installer: evand * r725 ubuntu/debian/changelog: releasing version 1.27ubuntu3 [17:23] cjwatson: Or is the main archive's absence from sources.list.udeb a bug? [17:34] err, you might just need to have it installed on the build system [17:34] the main archive should definitely not be in sources.list.udeb [17:35] actually, why is console-tools-udeb depending on libconsole rather than libconsole-udeb? that's a bug [17:35] I thought I fixed that ages ago [17:35] I bet dpkg broke that on me [17:36] udeb: libconsole 0 libconsole-udeb (= 1:0.2.3dbs-65ubuntu6) [17:36] shlibs *look* right ... [17:44] It built correctly on the buildd's as well. How odd. [17:45] Ah, new console-tools from the day before yesterday. [17:47] urr. any chance you could figure out why console-tools-udeb is getting the wrong dependency, despite the shlibs? [17:49] the change in console-tools isn't relevant AFAIK; it's a build system thing [17:49] WEll, I guess I'm going to have to. [17:49] cjwatson: Sure, I was just wondering why it worked a week ago. [17:49] cjwatson: and that explains it. [17:50] it hadn't been built since gutsy, so I expect it needs tweaked to cope with dpkg-shlibdeps changes [17:50] it was doing some kind of nasty stuff [17:51] Will you be around for the next couple of hours or later this evening? [17:51] My crystal ball tells me I'll find the issue, but won't be able to tell if it's dpkg or console-tools that's doing the wrong thing. [17:51] s/dpkg/dpkg and friends/ [17:59] cjwatson: Hrm... There's a shlibs.local, that says "libconsole 0 libconsole (= ${Source-Version}) [17:59] Erk.. That looks mangled here. [17:59] cjwatson: Hrm... There's a shlibs.local, that says "libconsole 0 libconsole (= ${Source-Version})". [18:00] cjwatson: dpkg-shlibdeps doesn't mention anything about udeb. I have literally no historical context, so I'm not sure where to point my finger. [18:06] cjwatson: Adding the udeb: lines to shlibs.local fixes it.. [18:07] * soren goes to dinner. bbl. [18:08] soren: later as in much later [18:08] not the next couple of hours [18:09] urr [18:09] I *think* that shlibs.local should just go away [18:09] would be worth seeing what happens if you just rm the thing [20:54] cjwatson_: Yeah, everything looks lovely without shlibs.local AFAICS. [20:54] cjwatson_: Thanks for your input. [20:59] great, thanks === cjwatson_ is now known as cjwatson [20:59] I like people figuring out d-i build failures for me ;) [21:02] :) [21:02] I'm curious why it suddenly broke, though. [21:02] That shlibs.local has been the for a looong time, apparantly. [21:43] cjwatson: d-i's build/config/common still says "SUITE =? gutsy". I doubt that's intentional but somehow I feel I should probably ask to be sure :) [21:45] yeah, doesn't actually matter because debian/rules overrides it, but should be fixed; go ahead [21:45] suddenly broke> dpkg-shlibdeps was practically rewritten ... [21:48] Ah, yes. [22:16] cjwatson: Ok, a bit of assistance... I'm working on the iscsi thing again. I've made changes to disk-detect and added a new udeb... How do I most easily test these things? the mini.iso d-i can build for me doesn't have the udeb's so that's not as easy as I had hoped.. [22:16] My apologies if this is already explained somewhere.. [22:20] localudebs? [22:20] evand: Yeah, but they don't land on the mini.iso, do they? [22:20] I thought they did, but it's been a while. [22:20] or am I being a muppet? [22:21] It's quite conceivable that I am. [22:21] heh [22:22] Nope. [22:22] argh, not sure then [22:24] aha! [22:24] EXTRAUDEBS ftw, it seems. [22:28] for adding a new udeb, localudebs or EXTRAUDEBS is about right [22:28] you might need to prod build/pkg-lists/whatever [22:29] for simpler changes it's often sane to just edit things on the fly in the running installer [22:29] that doesn't work if you add debconf templates though [22:31] I do. [22:32] But the mini iso should do fine? [22:32] Or do I need to dive into debian-cd, too? [22:36] mini.iso should do fine provided it's the cdrom one [22:36] (mini.iso is a delivery format rather than something that defines what udebs go on the image) [22:37] if cdrom doesn't work, monolithic is the standard big hammer [22:37] you'll need to edit build/config/i386.cfg or similar to uncomment monolithic, and then run 'make' in build/ to get the right target name [22:37] probably rebuild_monolithic [22:38] Ah... adding them to EXTRAS and cleaning and rebuilding got them into the initrd. That was what I was looking for, I guess. [22:38] monolithic builds all available udebs into the image [22:38] Ah, ok. [22:38] except that it doesn't need a retriever [22:38] because it already has it all in the initrd [22:38] obviously fairly giant [22:39] I can imagine :) [22:41] cjwatson: I remember you said I could define /proc/cmdline aliases... Where was that again? [22:41] preseed_aliases [22:41] in the preseed source [22:41] I think it's /lib/preseed/preseed_aliases in the initrd [22:42] right, early(ish) night time, I think [22:43] Alright. I think I have plenty to work with now. Thanks for your help. [22:43] no problem [23:04] cjwatson: Have you gone yet? [23:26] cjwatson re iso-scan: http://paste.ubuntu-nl.org/55035/ [23:26] haven't tested it though [23:55] howdy [23:55] howdy [23:56] when I use debuild I get "secret key not available" [23:56] the key is in my keyring, do I need to register it homehow?