[10:45] <CIA-6> ubiquity: evand * r3676 ubiquity/ubiquity/frontend/gtk_ui.py: Missed one spot that had a bgo 56070 workaround.
[10:53] <cjwatson> ev: I guess not that many people are believers in the Unicode ellipsis in English text; it always seemed to be asking for trouble to me :-)
[10:55] <ev> I think it looks a bit nicer (http://tecnocode.co.uk/2009/10/01/unicode-in-gnome/), but not enough for me to go and invalidate a whole bunch of translations.
[11:13] <cjwatson> the other constraint might be that gettext restricts msgids to ASCII-only
[11:13] <cjwatson> or strongly recommends, anyway
[11:14] <cjwatson> this is apparently because if gettext doesn't find a translation it returns the msgid unchanged without doing any recoding
[11:14] <cjwatson> but the upshot is that if you try to put non-ASCII text in msgids, you get whines on stderr all the time, so most people avoid it
[14:55] <CIA-6> grub-installer: cjwatson * r833 no-device-map/ (debian/changelog grub-installer): Use an appropriate OS device name rather than (hd0) if possible.
[15:16] <ev> perhaps its best solved in en_* then.
[16:03] <ikt> heya anyone alive >.>
[16:11] <ev> cjwatson, michaelforrest: (bug 414912, bug 336751) thoughts? http://people.canonical.com/~evand/tmp/transitions.html
[16:11] <ev> I'm afraid it's even more jarring than the existing version.
[16:12] <cjwatson> ev: I was hoping we could use a status bar or something
[16:12] <cjwatson> I agree this is pretty jarring
[16:13] <cjwatson> I like what you've done with the manual partitioner though!
[16:13] <ev> thanks
[16:13] <ev> I think I need to smooth that out a bit
[16:13] <michaelforrest> ev let's talk about this in a bit
[16:13] <michaelforrest> (I am about to go to a meeting )
[16:14] <ev> michaelforrest: sure thing
[16:14] <cjwatson> does it disable the UI when the spinner is up in the manual partitioner?
[16:14] <ev> yes
[16:14] <cjwatson> in bug 336751, mpt said "A status bar would be quite inappropriate in an assistant-style window such as the installer", but gives no reasoning for this declaration
[16:14] <ev> cjwatson: indeed, that's what I was going off of
[16:15] <ev> it's a shame he's not around, but perhaps michaelforrest (when he gets back) understands what mpt's reasoning would be
[16:15] <cjwatson> I'm concerned at that sort of declaration since it seems that the result is things looking much worse :)
[16:15] <ev> agreed
[16:16] <cjwatson> maybe not a status bar, but could we do something like the spinner you did for the manual partitioner, but in some other bit of blank space?
[16:16] <cjwatson> I don't know what's consistently available ...
[16:16] <cjwatson> ikt: replied to your mail
[16:16] <ev> the space between step X of X and back forward next
[16:16] <ev> err quit back forward
[16:16] <ev> that's about it :)
[16:17] <ev> for what it's worth, this is all in ~ev/ubiquity/progress_indicator
[16:18] <ev> PyGTK 2.17.0-0ubuntu2 just hit the archive with GtkSpinner
[16:21] <CIA-6> ubiquity: cjwatson * r3677 ubiquity/ (10 files in 4 dirs):
[16:21] <CIA-6> ubiquity: Add a context manager (raised_privileges) and a function decorator
[16:21] <CIA-6> ubiquity: (raise_privileges) that are equivalent to a
[16:21] <CIA-6> ubiquity: regain_privileges/drop_privileges pair, but that wrap up the required
[16:21] <CIA-6> ubiquity: try/finally logic to make it less likely that we'll end up at the wrong
[16:21] <CIA-6> ubiquity: privilege level by mistake.
[16:24] <ikt> cjwatson: cheers :)
[16:36] <CIA-6> ubiquity: cjwatson * r3678 ubiquity/ (debian/changelog ubiquity/auto_update.py):
[16:36] <CIA-6> ubiquity: When attempting to upgrade the installer, only stop debconf-communicator
[16:36] <CIA-6> ubiquity: once we've determined that we actually have something to upgrade.
[16:59] <CIA-35> grub-installer: cjwatson * r834 no-device-map/ (debian/changelog grub-installer):
[16:59] <CIA-35> grub-installer: When installing from non-CD media, we only need to reset the default
[16:59] <CIA-35> grub-installer: boot device if we would otherwise end up installing GRUB to the
[16:59] <CIA-35> grub-installer: installation media.
[17:26] <CIA-35> ubiquity: cjwatson * r3679 ubiquity/debian/ (changelog control): Require Python 2.6, for the 'with' statement.
[18:42] <CIA-35> grub-installer: cjwatson * r835 no-device-map/debian/changelog: grammar
[18:43] <CIA-35> ubiquity: cjwatson * r3680 ubiquity/ (6 files in 4 dirs):
[18:43] <CIA-35> ubiquity: Move default GRUB target calculation to ubiquity.misc, which is a better
[18:43] <CIA-35> ubiquity: location for common code than ubiquity.components.summary. Try to avoid
[18:43] <CIA-35> ubiquity: using (hd0) as the target (prefer the first device from grub-mkdevicemap
[18:43] <CIA-35> ubiquity: output if possible), and, when installing from a non-CD medium, only
[18:43] <CIA-35> ubiquity: reset the default boot device if we would otherwise end up installing
[18:43] <CIA-35> ubiquity: GRUB to the installation medium.
[18:59] <CIA-35> ubiquity: cjwatson * r3681 ubiquity/debian/changelog: LP: #508725 appears to be fixed by debconf-communicator work
[19:14] <CIA-35> localechooser: cjwatson * r154 ubuntu/debian/changelog: releasing version 2.12ubuntu3
[19:21] <Lyaa> hya - anyone working on patman-iscsi ?
[19:22] <Lyaa> partman-iscsi, that is
[19:25] <CIA-35> ubiquity: cjwatson * r3682 ubiquity/debian/changelog: r3678 fixes LP: #495175
[19:26] <cjwatson> Lyaa: yes, but more currently I'm working on having dinner.  Please say what the problem is and hang around, and I'll get back to you
[19:33] <Lyaa> cjwatson: i've managed to launch the Lucid's installer via PXE and installed in iscsi-root (<- it has *really* improved even since Karmic! ;-))
[19:34] <Lyaa> cjwatson: but the generated /etc/iscsi.initramfs is wrong.. it has $*USERNAME* ans $*PASSWORD* set to "<NULL>" which leads to no avail while initramfs-hook starts logging in that target
[19:35] <Lyaa> it should be left out completly or at leadt set to =""
[19:35] <Lyaa> least..
[19:39] <Lyaa> (then the only thing that's left for me is to find out how to re-order the network module probing in initramfs to get the right eth0-device pointing into the target's direction..grr..)
[21:20] <cjwatson> Lyaa: hmm.  could I see the installer logs?  /var/log/installer/syslog and /var/log/installer/partman, particularly
[21:21] <cjwatson> Lyaa: doing something about network probing is on my list, but it won't be by way of module probe order, it'll be by remembering the right network device to use
[21:21] <cjwatson> Lyaa: I'd like a copy of iscsi.initramfs as well
[21:25] <dmarkey_> hmm.. is there a reason ubuntu still doesnt support being installed as a domU
[21:26] <Lyaa> cjwatson: hmm.. about module reordering: i've added now a file "udevrules" below /etc/initramfs-tools/hooks/ that copies over the 70-net-persistent file to initramfs image
[21:27] <Lyaa> cjwatson: that does the trick ;-)
[21:27] <Lyaa> cjwatson: so now my nics get (re)numbered according to udev-rules in the running system
[21:29] <Lyaa> cjwatson: about the log files: any  special sub part of them to nopaste? or complete logs?
[21:32] <Lyaa> cjwatson: additionaly i do not have any syslog output - i had to kill some processes (i.e sysklogd) due to low ram on that machine (i.e 64MB.. )
[21:32] <Lyaa> cjwatson: however, i have the partman log
[21:40] <Lyaa> . o 0 ( hmm .. and i've killed the lines from iscsi.initramfs rather than commenting them.. )
[21:41] <Lyaa> i guess i'm a louzy bug reporter..
[21:41] <Lyaa> :)
[21:47] <cjwatson> Lyaa: you killed sysklogd in the installer?
[21:47] <cjwatson> Lyaa: the net-persistent stuff should already be copied, if it isn't that's a bug
[21:48] <Lyaa> cjwatson: ha! .. found the original : http://paste.ubuntu.com/359236/
[21:48] <cjwatson> hmm.  indeed it isn't.  we should fix that.
[21:48] <cjwatson> Lyaa: complete logs> always
[21:51] <Lyaa> btw: kernel cmdline "... blacklist=particular_module..." is not honored either by init-premount/blacklist
[21:51] <cjwatson> hang on, I can't deal with all this at once :)
[21:51] <Lyaa> take your time :-)
[21:52] <cjwatson> Lyaa: can you answer "you killed sysklogd in the installer?"
[21:54] <Lyaa> cjwatson: right after d-i started with the dialog-menu, i switched to console 2, activetaed the busybox shell, did a "ps" and killed all tasks (i.e syslogd and klogd) to get more ram
[21:54] <Lyaa> as i said, it's a diskless machine with only 64MB ram ..
[21:55] <Lyaa> and tht seems to be too low for current d-i
[21:55] <cjwatson> drat
[21:56] <Lyaa> additionally i've unloaded some modules that were autoloaded by the installer (like: filesystems that are not used further on (i.e xfs, jfs, ..)
[22:01] <Lyaa> cjwatson: but with the generated variables in iscsi.initramfs you see from the script local-top/iscsi line 68: "${ISCSI_USERNAME:+-u "$ISCSI_USERNAME"}" that this _will_ fail obviously ;-)
[22:01] <cjwatson> yeah, I'm looking into that part of it now
 there is certainly wrong, it's just a matter of detecting that gracefully
[22:02] <cjwatson> hoping to avoid a simple string comparison
[22:02] <Lyaa> is that a string/scalar representation of a null-value?
[22:03] <cjwatson> looks like I may not have a lot of choice
[22:03] <cjwatson> apparently so
[22:04] <cjwatson> I don't see a way to distinguish between a username that's genuinely "<NULL>" and a NULL value.  OTOH "<NULL>" probably isn't allowed by the iSCSI spec anyway so ...
[22:05] <Lyaa> hmm .. don't try to parse it in the init(ramfs) script but while generating that value ?
[22:05] <cjwatson> that's what I'm doing.
[22:05] <Lyaa> no offense :-)
[22:05] <cjwatson> but the <NULL> text itself is generated inside the kernel.
[22:05] <cjwatson> so I can't actually intervene there.
[22:07] <Lyaa> so actually emit some warning during install: "what?!? no password on the target? that's insecure!" - fix your security and set a password" :-)))
[22:08] <cjwatson> no
[22:08] <CIA-35> partman-iscsi: cjwatson * r44 ubuntu/ (debian/changelog init.d/iscsi):
[22:08] <CIA-35> partman-iscsi: Cope with "<NULL>" text in username, password, username_in, and
[22:08] <CIA-35> partman-iscsi: password_in files.
[22:08] <cjwatson> ^- that
[22:09] <CIA-35> partman-iscsi: cjwatson * r45 ubuntu/debian/changelog: releasing version 11
[22:10] <Lyaa> is that also an issue for backports to 9.10..?
[22:11] <cjwatson> no, because 9.10 didn't have iSCSI authentication support
[22:11] <Lyaa> oic
[22:11] <cjwatson> not that I can effectively change the 9.10 installer anyway
[22:11] <cjwatson> it is what it was
[22:14] <Lyaa> so now i still have to dive into initramfs to get early swap on that target - still experiencing OOM there..
[22:14] <cjwatson> Lyaa: is http://paste.ubuntu.com/359249/ reasonably close to what you used in your initramfs hook?
[22:14] <Lyaa> . o 0 ( 64MB is not state of the art .. sigh )
[22:17] <Lyaa> cjwatson: I've copied the original udev from /usr/share/... to /etc/initramfs-tools/hooks/udevrules and adapted like this: http://paste.ubuntu.com/359251/
[22:17] <cjwatson> I'm hoping that this fixes bug 473036
[22:19] <Lyaa> ..but it's been just a quick hack
[22:19] <cjwatson> near enough equivalent then.
[22:19] <cjwatson> (except for my inability to spell /etc/udev/rules.d, apparently)
[22:20] <cjwatson> you're copying to /lib/udev/rules.d/ instead, but udevd should look in both places.
[22:20] <Lyaa> actually, i've tried to blacklist the other nic-module using /proc/cmdline parsing by blacklist - that failed
[22:21] <cjwatson> that's outside my area of expertise
[22:21] <cjwatson> best to file it as an initramfs-tools bug, I think
[22:21] <Lyaa> but that will obviosly fail if you have two nics using the same driver
[22:22] <cjwatson> I think I might talk with our udev maintainer about this, rather than going ahead and fixing it right away
[22:22] <cjwatson> the NFS and NBD paths have essentially the same problem
[22:23] <cjwatson> and I don't see why 70-persistent-net.rules shouldn't just be universally copied in, really
[22:24] <Lyaa> yeah - that's mainly because i did now know it initramfs' "udev" is the real udev or some kind of busybox {u,m}dev that only looks in /lib/udev/rules.d/ - it's not FHS, but alas it's the initrd.. who really cares ;-)
[22:24] <cjwatson> it's the real udev but with a cut-down configuration
[22:24] <cjwatson> the reduced tools are sometimes more trouble than they're worth
[22:26] <Lyaa> actually, the devices _should be_ the same order as during install, as they are enumerated by pci-bus-id.. but again i renumbered them during install phase.. ;-)
[22:27] <cjwatson> this category of problem is what the persistent rules files are for
[22:28] <Lyaa> Alt-F2, Shell, modprobe -r nic0, modprobe -r nic1; nano /etc/udev/rules.d/70-net-persistent.net.rules and swapped eth0 with eth1, saved, udevadm control --reload; modprobe in order -> swapped names
[22:28] <cjwatson> eww.  why was that worth it?
[22:28] <cjwatson> IOW why does the naming matter?
[22:29] <Lyaa> the machine has two nics - one is on-board.. and that's the (only) one with PXE..
[22:29] <cjwatson> as long as they're the same from installer through initramfs to running system, it shouldn't matter?
[22:30] <Lyaa> and it boots from it - altering the name during boot and run mostly leads to even more fuzz..
[22:30] <cjwatson> I'm confused, and want to understand this
[22:31] <cjwatson> why does it matter whether eth0 is the PXE one?  PXE-booting should be before Linux assigns names, and independent of it
[22:31] <Lyaa> the machine detects the on-board first and does not initialize the PCI-card
[22:33] <cjwatson> sure, but udev will assign it a name that's consistent with what was available in the installer (once this initramfs hook fix is applied, wherever it goes), and with what the installed system expects
[22:33] <Lyaa> so it does PXE via the on-board, get it's IP and chainloads a gPXE image which does iSCSI .. and you have a INT13 disk whioch loads the boot loader .. that Kernel does ipconfig and initiator again
[22:33] <cjwatson> it's entirely possible for the first device that's detected to be assigned eth1
[22:34] <Lyaa> and you know by yourself, it does only probe for iSCI on device "eth0" ;-)
[22:35] <cjwatson> but that is not true?
[22:35] <cjwatson> or at any rate it is certainly not supposed to be true!
[22:36] <cjwatson> it's supposed to try bringing up all interfaces
[22:36] <Lyaa> and the other nic points in another network which does not reach the iscsi target
[22:36] <Lyaa> hmm?
[22:37] <cjwatson> ok, so the problem is not that it only probes eth0, it's that it tries bringing up all interfaces and only tries probing the first in asciibetical order
[22:37] <cjwatson> thank you, that clarifies things
[22:37] <Lyaa> it does - but the Kernel bringing the PCI card up as eth0 and tries to get a hold for the Target on that nic
[22:38] <cjwatson> the kernel does what it's told by userspace, in this regard
[22:38] <cjwatson> the kernel does not do iSCSI login by itself
[22:38] <cjwatson> as far as I can see, eth0 is not hardcoded anywhere relevant
[22:38] <cjwatson> if it is, we should fix that, but I don't believe it is
[22:39] <Lyaa> right - you may work around this by specifying "ip=all" on Kernel cmdline
[22:39] <cjwatson> whoa, wait a sec
[22:40] <cjwatson> OH, I see now
[22:40] <cjwatson> ./conf/initramfs.conf:65:DEVICE=eth0
[22:40] <cjwatson> silly thing
[22:40] <cjwatson> OK, I take it back that it isn't hardcoded
[22:40] <Lyaa> then ipconfig probes DHCP on all nics - but then booting takes like ages on timeouts when one nic has no link
[22:41] <cjwatson> so we need partman-iscsi to remember the network device used
[22:41] <cjwatson> regrettably, I'm not sure I can find this in /sys ...
[22:42] <Lyaa> hmm .. some "ip route show | grep $TARGET_SUBNET | grep_for_dev"-magic..?
[22:43] <cjwatson> Lyaa: in the installer, which device did you select at the network configuration stage?  did you select the interface that's to be used for iSCSI?
[22:43] <cjwatson> the installer normally only brings up one network device, IIRC
[22:45] <cjwatson> at the moment, I'm thinking of remembering the network device selected in netcfg in ISCSI_NETDEVICE in iscsi.initramfs
[22:46] <Lyaa> i've selected eth0 in d-i .. but that had been after I altered the device names in udev
[22:46] <Lyaa> but that should work out
[22:47] <cody-somerville> grrr... I seem to be causing Ubiquity to crash somehow. :/
[22:47] <cjwatson> Lyaa: eth0 (pre-renaming) was the right device to use for iscsi, then?
[22:49] <Lyaa> nah - Kernel, d-i, some userspace, whatever would called that nic "eth1".. so i swapped the name right before entering the "Network configuration" item
[22:49] <Lyaa> then it had been displayed as "eth0"
[22:49] <cody-somerville> cjwatson, Does Ubiquity in karmic support creating users with a blank password? UserSetupApply is failing with code 1 and thats the only thing I can think of thats different from another build I have that works fine.
[22:49] <cjwatson> OK.  So all we need to do is lose that renaming and remember that we should use eth1 at initramfs time.
[22:50] <Lyaa> cjwatson: think so
[22:50] <cjwatson> cody-somerville: only if user-setup/allow-password-empty is set to tru
[22:50] <cjwatson> true
[22:51] <cody-somerville> cjwatson, I have that. And d-i passwd/user-password{,-again} password
[22:52]  * cody-somerville takes a peak at ubiquity's source.
[22:54] <cody-somerville> It looks like I might want to use the ubiquity in karmic-updates before moving forward.
[22:57] <cjwatson> I'm not convinced ...
[22:57] <cjwatson> I suggest using ubiquity --debug in the first instance
[22:58] <cjwatson> getting a full debconf trace is usually the quickest way to attack these problems
[22:58] <cjwatson> then show the full log
[22:58] <cjwatson> (/var/log/installer/debug - use a non-valuable password!)
[23:00] <cody-somerville> /var/log/installer/debug says its failing on UserSetupApply and running it manually I see "No password supplied" repeated three times followed by "chpassword: (user ubuntu) pam_chauthtok() failed, error:\n Authentication token manipulation error.
[23:00] <cody-somerville> I'll try running ubiquity with --debug
[23:02] <cjwatson> you don't have any other odd backports of things like shadow or pam, do you?
[23:02] <cody-somerville> Nope. Just pointing at karmic.
[23:02] <cjwatson> I'm at a loss just now, then
[23:03] <cjwatson> I don't see any interesting changes in user-setup
[23:03] <cody-somerville> To be honest, I think I ran into this issue before but never bothered to look into it and just put in a dummy password instead.
[23:06] <cjwatson> Lyaa: will you be available for retesting of lucid daily builds at some later point, once we've fixed this?  if you could e-mail me at cjwatson@ubuntu.com, I can get in touch with you
[23:30] <CIA-35> user-setup: superm1 * r77 user-setup/ (debian/changelog user-setup-apply):
[23:30] <CIA-35> user-setup: Fix automatic login on situations where custom.conf didn't exist
[23:30] <CIA-35> user-setup: already on the target.
[23:31] <CIA-35> user-setup: superm1 * r78 user-setup/debian/changelog: releasing version 1.28ubuntu3