[08:26] hi [12:16] Hello everyone. Yesterday in the preseeding talk by evand a tool called debconf-get-selections was mentioned for saving the selected answers from an install. Unfortunately I can't find this on my alternate install environment. I can see debconf-set-selections and debconf-get but no debconf-get-selections.. any ideas? [12:18] * Omahn wonders if the use of the server CD is the issue here [12:21] it won't be there until after reboot [12:21] you do have to be careful with its output - it should only be used in conjunction with the installation guide [12:21] oh, remember to install debconf-utils [12:22] Aha. evand suggested that it needed to be done in the installation environment. [12:23] debconf-get-selections --installer [12:23] (for alternate/server installations) [12:29] cjwatson: Perfect. Thanks. [14:59] Almost working :-) [14:59] I've getting the confirmation dialog about removing existing logical volume data, even though I have: [14:59] d-i partman-auto/purge_lvm_from_device boolean true [14:59] in my preseed. [14:59] # And the same goes for the confirmation to write the lvm partitions. [14:59] d-i partman-lvm/confirm boolean true [14:59] A bug or am I doing it wrong?... [15:01] exactly which messages are you seeing? We need the text in order to search [15:01] evand, bean123 has updated the grub4dos svn code [15:01] I can now do the new builds which support find + relative path [15:02] Just doing another build now, I'll copy the text when it gets there. [15:02] evand, can you please run the tests in https://bugs.launchpad.net/wubi/+bug/217348/comments/9 [15:02] and if successful patch grub-installer as indicated? [15:03] xivulon: will do [15:03] great! [15:04] also seems that the vista bug is fixed with the 7z trick (davmor2) [15:04] note that to build the CD build you use a different command: make wubi-selfextract [15:04] which will also run make and create 2 different binaries [15:05] Ready for this screen text?.. [15:05] [!!] Partition disks [15:05] The selected device already contains logical volumes and/or volume [15:05] groups from a previous LVM installation, which must be removed from [15:05] the disk before creating any partitions. [15:06] Note that this will also permanently erase any data currently on the [15:06] logical volumes. [15:06] Remove existing logical volume data? [15:06] (done) :-) [15:06] xivulon: I thought you said the 7z trick did not work for you? [15:06] d-i partman-lvm/device_remove_lvm boolean true [15:07] aha.. I'll stick that in and try again.. [15:07] evand that was using UPX [15:07] ah, my mistake [15:07] UPX cretes a package that when unpacked is not bit-identical to the original :( [15:07] and since nsis uses internal CRC check those fails [15:07] 7z is a bit larger but does not suffer from the same issue [15:08] The other attempt in the middle was to postpone the eject call to the very end, but it did not work and I have reverted the changes [15:10] cjwatson: Perfect. I'm guessing that should go into appendix B of the installation guide?.. [15:10] Omahn: yep, I just edited my local copy to include that [15:10] cjwatson: By local copy, do you mean locally checked out copy? :-) [15:11] whatever terminology you prefer [15:11] Good stuff. Just wanted to make sure it goes back in to the docs. [15:11] I don't really understand the distinction you're drawing [15:12] Well, if you have a local copy of the installation guide on your machine, editing it is of no use to other users unless it goes back upstream to the distro. [15:12] yes, I mean my checkout of the guide's source; I'm the person who normally uploads it [15:12] Fantastic. :-) [15:12] BTW - how did you find the answer? Or did you know it already? (for future reference) [15:13] I searched the templates files in a couple of candidate packages [15:14] i.e. roughly analogous to reading the source [15:14] I see. Thanks. [15:15] we don't really have any way to automatically generate documentation from debconf templates yet, unfortunately, even though the format would theoretically support it [15:15] Ok. I'm guessing documenting every possible option would be overkill anyway? [15:16] overkill and probably harmful [15:17] some options are not meant to be used outside the installer, preseeding them can have unexpected results. [15:18] er, questions [15:18] Does a 'server' tasksel exist? I've just used standard for now but that installs openoffice which doesn't seem ideal for our servers. [15:19] standard doesn't itself install openoffice.org; the things you're missing are: [15:19] d-i pkgsel/language-pack-patterns string [15:20] d-i pkgsel/install-language-support boolean false [15:20] (from /cdrom/preseed/ubuntu-server.seed on server CDs) [15:21] I've just realised I used the alternative installer CD.. that would explain it.. [15:22] you'd need to preseed those items either way (at least theoretically) [15:22] I've added them and just reinstalling with the server CD. [15:46] anna: cjwatson * r410 ubuntu/debian/changelog: releasing version 1.31ubuntu1 [16:16] xivulon: didn't work for me. Did it work for you? It doesn't seem like it would as I don't believe you can do 'root find...' [16:25] evand hm I tested directly with an edited menu.lst and missed that... [16:25] good point [16:26] we have 3 options then: [16:26] 1) go for the wubi specific case: root ()/ubuntu/disks [16:27] 2) ask bean 123 to change the root syntax root()/ubuntu/disks --find=/path/to/look/for [16:27] 3) change update-grub / grub-installer to support an extra line: find --set-root [16:29] any preference? [16:32] definitely not 3, imo. [16:32] I suppose 1 is our best bet. [16:34] 1 is the first patch provided then, I have been suggesting it around and nobody complained so far [16:34] well actually, I take that back. I guess 3 wouldn't be terrible, but I'm not swayed. [16:35] ok [16:36] 1 is not invasive but it ties the implementation to wubi [16:37] the question is there anyone else likely to use grub-installer/bootdev_directory? [16:37] I doubt it. cjwatson does going with 1 seem unreasonable to you? [16:40] 3 sounds like the right long-term answer, but for 8.04.1 we should pick the thing that's most contained and least likely to affect anything else, IMO [16:41] agreed, so 1 for now and we'll work on 3 in 8.10. [16:42] sounds good to me [16:42] https://bugs.launchpad.net/wubi/+bug/217348/comments/5 [16:47] I would still need to upgrade grub4dos since that includes fixes for gate A20 #224311 [16:52] ok [16:59] evand we posted together :) [17:00] "Forget the above post" now looks bad on my comment to #217348... [17:00] heh, whoops [17:00] editing comments in LP is #1 on my wishlist [17:39] cjwatson: for changes to packages that are going to go into proposed (grub-installer), should I create a hardy branch or is it safe to commit to trunk? [17:40] hardy branch would be good [17:40] hmm I have already committed a few changes to wubi/hardy branch would that be ok? [17:41] ack'ed [17:43] xivulon: I'd prefer to have a branch of Wubi for just the things that are going to go into 8.04.1 [17:46] evand then I will rename hardy -> hardy.old (obsoleted) and re-upload hardy as of 501 (since do not know other way to revert things in launchpad) [17:46] then I will add hardy.pointrelease or something with the extra changes [17:46] is that ok? [17:48] you can just 'bzr revert -r501' and then commit that, thereby committing a change which takes you back to r501 [17:48] (possibly branching first so that you have the state handy for later) [17:48] ah thanks will that later on tonight then [17:55] am I right in assuming that the proper bzr workflow is make a change in trunk then merge in the hardy branch, so we carry any necessary changes to the next release and preserve the changelog entries? [17:56] merge the changes into* [18:00] if so I could also rename hardy->trunk + branch trunk -r 501 and upload as "8.04" + create a third branch called 8.04.1 [18:11] there's no need for three branches [18:11] we just need a branch for keeping changes that will go into 8.04.1 and trunk [18:12] so trunk I keep trunk ("hardy" in my case) at r501 and add a new branch with r505+ [18:13] correct? [18:13] indeed [18:13] will do [18:13] thanks [18:14] np (should have thought about branching earlier on) [19:07] ubiquity: evand * r2677 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py): * Handle the migration-assistant UI being fed non-UTF data gracefully. [19:53] cjwatson: can you confirm the above? Is the right workflow to make changes in trunk and then merge into the hardy branches for most changes? [20:22] evand: that's usually sensible, yes [20:22] although the other way round is not a critical failure or anything [20:23] cjwatson: ok, thanks for clearing that up [20:31] ubiquity: evand * r2678 ubiquity/ (3 files in 2 dirs): * Make capitalization of migration-assistant consistent (LP: #225555). [20:46] Hrm, "Migration Assistant: " generated in scripts/summary and thus untranslated or "None" untranslated? (in reference to bug 225558) [20:48] I suppose I also have the option of sticking a text question in debconf for either option and gaining translations. [20:54] evand, do you mean that none of the summary text is localized? [20:54] mpt: no, it is. [20:55] the summary text is translated, but the stuff m-a substitutes in is not [20:55] It didn't occur to me at the time, but "Migration Assistant" doesn't appear anywhere else in the interface, does it? [20:55] hrm, no, I don't believe it does [20:55] it's the hidden engine [20:56] should it just say something like, "Documents and settings to import: "? [20:56] sure [20:56] followed by either "None", or the list of what it is importing [20:57] ok, will do [21:00] I wondered why that text isn't left out for non-m-a installs [21:01] well, it wouldn't get translated if I subst'ed it in, but I think what I'm going to do is make ubiquity/none or something similar to hold translations for None [22:33] Question for the team about the Ubuntu installer [22:36] the installation hangs at the "detecting hardware" seciton [22:42] usually, that's because trying to load a module hung, and is typically a kernel bug of some kind [22:42] it may be interesting to know whether the system is otherwise responsive [22:43] this time it's hanging at the "resizing partitions" section [22:43] if you are using the desktop CD, try wiggling the mouse [22:43] if you are using the alternate or server CD, press Alt-F2 and then Alt-F1 and see if the screen changes [22:43] the system is as responsive as a bootable CD can be [22:43] the gui really slows things down [22:43] how much memory do you have? [22:44] 2 GB [22:44] I built this machine last year and I've run Ubuntu on it before [22:45] ok, plenty [22:45] pop up a terminal and look at the end of /var/log/syslog [22:45] stand by [22:46] strange, the install moved forward when I launched terminal [22:48] I don't have any error messages in the syslog [22:49] curious that starting a terminal nudged it [22:49] note that resize is known to take some time without feedback [22:49] well I'm at the next step and this is where it's been hanging up [22:50] it hangs at "detecting file systems" [22:50] anything in /var/log/installer/debug or /var/log/kern.log? [22:51] hey it moved this time, but the difference was that I was running terminal [22:52] I did get a Python "Future warning" but things are moving along [22:52] I left this same config last night but it just hung up [22:52] I wasn't running terminal [22:53] future warning> probably from the apt module, that one's harmless [22:53] that's what I figured [22:54] random freezes that unwedge when you move something smell of lost interrupts to me [22:54] (again, kernel ...) [22:54] the kern.log has a warning about the ufstype and a bad magic number [22:54] maybe it hung up on mounting the new file partitions? [22:58] one issue with the graphical installer: if you choose to just run the installer you can't pop up a terminal to see what's wrong [22:58] shouldn't think so, it's (unfortunately) normal behaviour for a vast number of such warnings to be emitted during os-prober runs [22:59] true, though you can press Ctrl-Alt-F1 and look there [22:59] really? I didn't know that was available [22:59] what does that function do? [23:03] does it pull up a console or does it display a running log? [23:09] ctrl-alt-f1> switch to Linux virtual terminal [23:09] i.e. switch away from the graphical environment [23:09] you can switch back with alt-f7 [23:11] I'll have to try that next time [23:11] I've done that when I ran Debian and had the video driver dump on me [23:11] but that was several years ago [23:22] anyways, thank for your help [23:37] evand, can you see if you are happy with the wubi branches? [23:38] then I will add the grub4dos code [23:38] there is a new branch called hardy.proposed for rev 501+ [23:42] salve a tutti! [23:42] c'è qualche buon'anima a cui posso chiedere un help su ubuntu? [23:43] I'm afraid I don't speak Italian; #ubuntu-it might be of more help [23:44] ops...sorry, right, i'm go to ubuntu.it...tank you very much [23:44] bye [23:44] :-) [23:48] elixam, Io parlo italiano [23:51] what is good practice when a bug is actually fixed in another project (see 217348) shall I mark wubi in such case as invalid? [23:51] or as fix committed?