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