[00:07] <btm> works good.
[00:22] <CIA-3> ubiquity: cjwatson * r3090 ubiquity/ (3 files in 2 dirs):
[00:22] <CIA-3> ubiquity: Add ubiquity/keep-installed question which can be preseeded with a
[00:22] <CIA-3> ubiquity: space-separated list of packages to keep installed even if they aren't
[00:22] <CIA-3> ubiquity: in the desktop manifest and aren't in the list of language packs to keep
[00:22] <CIA-3> ubiquity: (LP: #290400).
[00:25] <btm> cjwatson: So I don't know what's setting root's password to ! in /target/etc/shadow, but it's making user-setup's root_password always return saying that the password is already set. so root-password-crypted doesn't get used.
[00:26] <btm> cjwatson: afaict, user-setup's root_password() would have always considered '!' as being set, even before LP:307443
[00:30] <cjwatson> btm: yes, I'm not sure about that, but I can't look at it now as I'm about to go to bed. Could you please file a bug?
[00:31] <btm> cjwatson: Yeah.
[00:40] <CIA-3> wubi: ago * r90 trunk/ (7 files in 4 dirs):
[00:40] <CIA-3> wubi: * Fixed typo (LP: #340400)
[00:40] <CIA-3> wubi: * Fixed CD eject issue due to wrong path (LP: #339907)
[00:40] <CIA-3> wubi: * Made btdownloader progress strings consistent with the ones used in the standard downloader
[01:01] <xivulon> cjwatson, since steve accepted the new wubi, shall I close 300769, or shall I live it open because of 8.04/8.10 implications?
[03:07] <shtylman> cjwatson: committed fixes for the two bugs, requested merge
[09:03] <davmor2> cjwatson: did you get the races issue resolved in the end?
[09:08] <tjaalton> well, it seems to have helped my case
[09:08] <tjaalton> although the lvm install still fails since it claims that the vg name is already in use
[09:09] <tjaalton> but the partitioning goes through
[09:10] <cjwatson> could people try the current server CD rather than the hacked-up one I posted?
[09:13] <cjwatson> oh, hang on, I wonder if one built
[09:15] <tjaalton> I used the latest netboot image
[09:16] <btm> cjwatson: the passwd/root-password-crypted problems I mentioned yesterday are caused by the LP:296841 changes to passwd, see LP:340841
[09:16] <cjwatson> netboot should be current
[09:17] <tjaalton> yep
[09:17] <cjwatson> LVM VG name stuff sounds like an entirely different bug
[09:17] <cjwatson> so that's a relief of sorts
[09:18] <tjaalton> probably the same as when trying to install regular on top of lvm, since it can't remove the vg's
[09:18] <cjwatson> so we appear to have current CDs that contain all our fix attempts
[09:19] <cjwatson> davmor2: ^- please do give them a try if you can, with any luck ...
[09:19] <cjwatson> this is my nightmare bug
[09:19] <tjaalton> introduced by the udev inotify change?-)
[09:20] <cjwatson> yes
[09:21] <cjwatson> shtylman: I'm struggling to see what the 'import sys' at the end of Timezone.py does
[09:21] <davmor2> cjwatson: netboot seems to be okay
[09:22] <cjwatson> shtylman: you seem to have reverted my fix for bug 337181 - any particular reason?
[09:22] <ubottu> Launchpad bug 337181 in ubiquity "ubiquity crashed with AttributeError in on_advanced_button_clicked()" [Medium,Fix released] https://launchpad.net/bugs/337181
[09:27]  * cjwatson does the merge review in LP instead
[09:28] <cjwatson> btm: I can't see how bug 296841 could have affected this; it should only have affected systems installed by vm-builder that literally had '!' as a valid password
[09:28] <ubottu> Launchpad bug 296841 in vm-builder "root account has ! as default password" [Critical,Fix released] https://launchpad.net/bugs/296841
[09:28] <cjwatson> oh, heh, you mentioned why
[09:29] <btm> cjwatson: because it checks dpkg --compare-version using 'lt'... yeah.
[09:29] <cjwatson> but even so, shouldn't the unix_chkpwd check also happen?
[09:30] <cjwatson> <cjwatson@sarantium ~>$ sudo head -n1 /etc/shadow
[09:30] <cjwatson> root:!:13767:0:99999:7:::
[09:30] <cjwatson> <cjwatson@sarantium ~>$ printf '!\0' | sudo unix_chkpwd root nullok; echo $?
[09:30] <cjwatson> 7
[09:30] <btm> cjwatson: I didn't look at that program, I'm unfamiliar with it, but I did change lt to lt-nl, purge base-passwd + passwd, rm /etc/passwd /etc/shadow, then reinstall those packages and the shadow file didn't come out with :!:
[09:32] <cjwatson> mm, I'm not quite sure that's a sound test TBH
[09:32] <cjwatson> but the lt-nl change is correct anyway
[09:34] <btm> cjwatson: s/root:!:/root::/ and unix_chkpwd returns 0
[09:34] <cjwatson> btm: I'm going to reopen the d-i task (and put it on user-setup) as my system doesn't have a root password set and yet the root_password function returns 0 for me
[09:35] <cjwatson> ok, so in that case we should also look into the unix_chkpwd bit of that code
[09:35] <btm> cjwatson: root_password() will return 0 if password is ! because it only checks for *
[09:35] <cjwatson> yes, I'm quite aware of that :-)
[09:35] <btm> cjwatson: the root password in shadow used to be empty before user-setup before 296841, which inadvertantly sets it to !
[09:36] <btm> cjwatson: word.
[09:36] <cjwatson> my system was not affected by the change in bug 296841
[09:36] <ubottu> Launchpad bug 296841 in vm-builder "root account has ! as default password" [Critical,Fix released] https://launchpad.net/bugs/296841
[09:36] <btm> I mean, user-setup probably should check for !
[09:36] <cjwatson> at least I would not have expected it to be thus; and ! is a perfectly reasonable way to say "no password" anyway
[09:37] <cjwatson> yes, that's what I meant by reopening that bug task
[09:37] <btm> agreed.
[09:39] <cjwatson> so now I have to work out why unix_chkpwd is behaving that way
[09:41] <btm> there's talk in 296841 that references s/nullok/nonull/. if shadow => 'root::' and you run 'printf '!\0' | unix_chkpwd root nonull' it yields 7. (I just tested that)
[09:44] <davmor2> cjwatson: new one on me kerneloops-ui
[09:44] <cjwatson> btm: ok; but then, reading that bug makes me wonder why base-passwd sets up root:: rather than root:*: to begin with
[09:44] <cjwatson> perhaps this is a subtle base-passwd bug
[09:45] <cjwatson> davmor2: hmm?
[09:45] <davmor2> cjwatson: only after install on 64bit netboot
[09:46] <btm> cjwatson: passwd.master in base-passwd has 'root::' so when passwd runs pwconv in postinst it doesn't get 'root:*:' in shadow but rather 'root::' in shadow.
[10:01] <davmor2> cjwatson: just doing an lvm netboot now seems fine again
[10:15] <btm> cjwatson: attached another patch to bug 340841, for user-setup. root-password-crypted works for me now.
[10:15] <ubottu> Launchpad bug 340841 in user-setup "passwd/root-password-crypted not being honored" [Medium,Triaged] https://launchpad.net/bugs/340841
[10:17] <cjwatson> btm: right, but I'm the base-passwd maintainer and I'm wondering if base-passwd ought to be changed here too
[10:17] <btm> cjwatson: haha. fix it all!
[10:17] <cjwatson> davmor2: ok, kerneloops at least is somebody else's problem. I am so relieved that the partitioning race has gone away for you!
[10:17] <davmor2> seems to of :)
[10:18] <cjwatson> btm: it's all one operating system, there's no point working around bits of it in other bits if we don't have to :)
[10:18] <cjwatson> btm: I'll apply at least the patches so far after alpha-6 is out, thanks
[10:53] <davmor2> cjwatson:  going for an encrypted lvm over over lvm and something doesn't seem to be right anymore :(  I got a blue screen with a grey bar at the bottom and disc activity
[10:53] <davmor2> no disc activity even
[10:57] <cjwatson> logs?
[10:59] <davmor2> working on it
[11:04] <davmor2> cjwatson: http://www.davmor2.co.uk/new/partman http://www.davmor2.co.uk/new/syslog
[11:10] <davmor2> cjwatson: I'm just wondering the uk.archive is up to date isn't it.  I just got the races issue again doing a whole drive over an lvm
[11:14] <cjwatson> "the races issue"> please don't assume there's just one
[11:15] <cjwatson> will need you to go through the full logs rigmarole including killing udevd and restarting it with extra debugging ...
[11:15] <cjwatson> this encrypted LVM thing looks different although I'll have to analyse it. The logs are not as informative as they might be
[11:18] <davmor2> cjwatson: the races one do you want the syslogs as they are or will you just want the udev-debug log?
[11:20] <cjwatson> udev debug + syslog + partman
[11:20] <davmor2> cjwatson: do you want the syslog and partman before I reboot or just the ones that go with the udev?
[11:21] <cjwatson> let's extract the logs before you reboot just in case it doesn't come up next time ...
[11:21] <cjwatson> but I don't want them on IRC, I want them attached to a bug
[11:21] <cjwatson> (a new one)
[11:21] <davmor2> cjwatson: no probs
[11:21] <cjwatson> I can't keep track of all the stuff going on on IRC at the moment
[11:29] <davmor2> cjwatson: bug 341046 should I sub keybuk to it too?
[11:29] <ubottu> Launchpad bug 341046 in debian-installer "Jaunty: Netboot install possible race condition" [Undecided,New] https://launchpad.net/bugs/341046
[11:29] <cjwatson> won't hurt
[11:30] <cjwatson> davmor2: would it be fair to say that the incidence rate seems to have dropped, at least?
[11:30] <davmor2> cjwatson: only affecting lvm now rather than any install
[11:30] <cjwatson> Mar 11 11:08:02 partman-lvm:   WARNING: Wiping physical volume label from /dev/sda1 of volume group "hb1"
[11:30] <cjwatson> Mar 11 11:08:02 partman-lvm:   Can't open /dev/sda1 exclusively - not removing. Mounted filesystem?
[11:30] <davmor2> and only overwritting lvm at that
[11:31] <cjwatson> oh and complaints before that about open logical volumes
[11:31] <cjwatson> ok, so this may be a relatively well-understood problem and we just need some more synchronisation points
[11:31] <cjwatson> which would be a relief of sorts
[11:32] <davmor2> cjwatson: so not races at all then Yay :)
[11:32] <cjwatson> well, it is still a race
[11:32] <cjwatson> just a different one
[11:33] <davmor2> cjwatson: do you still need the udev-debug or can I just reboot and try to install again?
[11:33] <cjwatson> I think it may be difficult to construct now without setting the whole thing up again
[11:33] <cjwatson> so let's leave it for the time being
[11:34] <davmor2> np's
[11:35] <davmor2> cjwatson: Now do you want a bug writing up for the first issue too? If so under what?  And is there anything else you want me to do with that system?
[11:36] <cjwatson> that one shows:
[11:36] <cjwatson> Mar 11 10:51:19 partman-lvm:   2 logical volume(s) in volume group "esey1" now active
[11:36] <cjwatson> Mar 11 10:51:36 partman-lvm:   Can't remove open logical volume "root"
[11:36] <cjwatson> so I think I am vaguely inclined to say that it may be the same problem
[11:36] <cjwatson> MAY :-)
[11:37] <cjwatson> let's not have a bug for that for now; it's a pretty edge case anyway so I'm comfortable with just seeing if it recurs after we fix the other one
[11:37] <davmor2> cjwatson: do you want me to add the syslog and partman from that issue to the bug too or just leave it for now?
[11:38] <cjwatson> just leave it, I think
[11:38] <cjwatson> but thanks
[11:39] <davmor2> np's
[11:39]  * cjwatson attempts to decipher the common thread "Can't remove open logical volume"
[11:39] <cjwatson> open by what, I ask
[11:39] <davmor2> udev
[11:40] <cjwatson> well, it's a possibility ...
[11:41] <cjwatson> maybe an update-dev --settle before the lvremove will be sufficient
[11:42] <davmor2> this will be an after alpha 6 thing though right :)
[11:43] <cjwatson> not sure yet
[11:43] <cjwatson> might respin server only
[11:43] <davmor2> I don't mind that I don't test it ;)
[11:44] <cjwatson> heh
[11:44] <cjwatson> for server LVM is the default now so it's a bit more important
[11:45] <davmor2> true :)
[11:54] <davmor2> cjwatson: I've had the dd 0 the mbr in order to carry on.  But at least that has worked this time :)
[11:59] <cjwatson> I have a candidate patch but would like to reproduce the problem myself first
[11:59] <cjwatson> not that that has worked very well so far ...
[12:31] <davmor2> cjwatson: did you get the oem issue resolved?
[12:37] <cjwatson> davmor2: the one from the alpha-5 release notes?
[12:38] <davmor2> Yes
[12:40] <cjwatson> yes, should be; that was just a case of "we fixed it in bzr but forgot to upload"
[12:42] <davmor2> cjwatson: cool test that after wubi and m-a then :)
[12:45] <davmor2> evand: Yay autorun works :)
[12:45] <evand> ja
[14:09] <davmor2> evand: can you try something with wubi for me please.  Start an install let it auto detect the username from windows but then change it to something else and carry on with the install.  Then take a look at fusa's user name
[14:10] <evand> davmor2: Wubi isn't working yet on Windows 7, so unfortunately I cannot.
[14:10] <evand> davmor2: what's happening?
[14:12] <davmor2> evand: on mine fusa has the original username even though the login is the one I choose.
[14:13] <evand> hrm, if you can verify it, please file a bug and attach your wubi log
[14:13] <davmor2> evand: I'm about to do a vista wubi so if it is the same I will :)
[14:22] <evand> thanks
[14:27] <davmor2> evand: maps nicer now :)
[14:27] <evand> thanks
[14:28] <davmor2> it doesn't make you eyes bleed anymore :)
[14:28] <cjwatson> shtylman_: we're getting KDE frontend crash reports on the bFrame.remove_widget() calls in set_autopartition_choices. Shouldn't that be before_frame.layout().removeWidget(before_bar) etc. to match the addWidget calls?
[14:34] <shtylman_> cjwatson: will look at that (also...the revert of your fix is not intentional...maybe a bad merge...?
[14:35] <shtylman_> cjwatson: just removing from layout isn't enough...it still stays the child of its parent
[14:36] <shtylman_> it also has to be removed from the widget...can I get a use scenario for when that happens?
[14:36] <cjwatson> ah, ok. bFrame is just a QWidget though, and it doesn't have a removeWidget method
[14:37] <shtylman_> cjwatson: what seems weird to me is that its on remove_widget() ... thats not a standard qt method...nor do I recal putting that in
[14:38] <cjwatson> I did bzr annotate, it's your code :)
[14:38] <cjwatson> I meant removeWidget rather than remove_widget
[14:38] <cjwatson> I'm trying to untangle a situation where this could happen now
[14:39] <cjwatson> why does the GTK frontend use '(%s)' % k.strip('=dev=') but the KDE frontend uses "%s" % d.strip('=dev=')?
[14:39] <cjwatson> (ignore the k/d difference)
[14:40] <shtylman_> cjwatson: removeWidget is indeed not a valid method...so now I am curious why that hasn't failed for me in the past...or why I wrote it...
[14:40] <cjwatson> shtylman_: maybe just try it when there's a reasonably large partition with a reasonably large amount of free space on it, and the disk is entirely tiled with partitions, so that the resize choice appears
[14:41] <cjwatson> removeWidget is a valid enough method, but only on a layout, not on a widget
[14:41] <cjwatson> hence my question earlier
[14:41] <shtylman_> cjwatson: ok, I will....and the '(%s)' had a reason...I just need to recall it...I think it had to do with the device not always being in ()...
[14:42] <cjwatson> this code all postdates the last time I dealt with partitioning in ubiquity, so I'm horribly confused
[14:43] <cjwatson> evand would have a better idea
[14:43] <shtylman_> heh
[14:43] <davmor2> evand: Wubi is dying on vista it doesn't have permission to write the log
[14:43] <cjwatson> I'm not sure why GTK and KDE would be different here though
[14:43] <evand> davmor2: please file a bug :)
[14:44] <evand> hrm
[14:46] <shtylman_> cjwatson: I will look at the remove widget thing right now..and the sys line will be removed from timezone...it was for testing. Also, I do not get a crash for that bug you mentioned #337181
[14:47] <cjwatson> you might only get it if you use the advanced dialog
[14:48] <davmor2> will do as soon as I get back :)
[14:48] <cjwatson> but isn't the code clearly wrong? the method used is not documented for QComboBox
[14:48] <shtylman_> cjwatson: yea...I did testing and fixes with that yesterday and it never came up...do you have to click ok maybe?
[14:48] <shtylman_> cjwatson: yea..it is...that what confuses me...
[14:48] <cjwatson> you may well have to, yes
[14:48] <shtylman_> cjwatson: and I know I have made it right in the past :/
[14:48] <cjwatson> sometimes I wish python were more rigidly-typed
[14:50] <shtylman_> oh...I know that feeling...I at least wish there was a 'faux compile check' I could do
[14:50] <shtylman_> for at least methods or something...
[14:54] <shtylman_> cjwatson: fixed the 337181 bug problem...(gonna check out the remove thing now)
[15:13] <shtylman_> cjwatson: (unrelated to ubiquity) do you get depricated python warnings when running bzr?
[15:14] <shtylman_> and also...I committed all my changes
[15:14] <shtylman_> once I push, do I need to ask for a remerge?
[15:14] <cjwatson> I think you need to poke the merge request somehow, yes, though I forget how
[15:14] <cjwatson> I don't get python warnings, but I haven't upgraded in a little while so that probably doesn't mean much
[15:15] <CIA-3> partman-lvm: cjwatson * r1212 ubuntu/ (debian/changelog lib/lvm-base.sh):
[15:15] <CIA-3> partman-lvm: swapoff and umount may write to the device and thereby trigger udev
[15:15] <CIA-3> partman-lvm: change events, so wait for udev to settle before calling lvremove
[15:15] <CIA-3> partman-lvm: (LP: #341046).
[15:17] <CIA-3> partman-lvm: cjwatson * r1213 ubuntu/debian/changelog: releasing version 65ubuntu2
[15:18] <cjwatson> davmor2: ^- I *think* that will fix your problem and I even found a reason why it breaks ...
[15:19] <davmor2> cjwatson: Yay :)
[15:19] <davmor2> are you re-spining or not?
[15:19] <cjwatson> server only, I think
[15:20] <davmor2> cool :)
[15:20] <davmor2> evand: Mis-read the error so I'll upload the log as well
[15:26] <davmor2> evand: bug 341181
[15:26] <ubottu> Launchpad bug 341181 in wubi "Jaunty: Python wubi doesn't have permission to write in vista" [Undecided,New] https://launchpad.net/bugs/341181
[15:29] <evand> davmor2: ah, looks like it's a duplicate of one I filed the other day: bug 340400
[15:29] <ubottu> Launchpad bug 340400 in wubi "Wubi crashes on installation in Windows 7" [Low,Confirmed] https://launchpad.net/bugs/340400
[15:30] <davmor2> evand: :( so no vista or win7 then :(
[15:30] <evand> davmor2: not for the moment
[15:31] <davmor2> evand: do you want to dupe it or leave it as individual bugs as it is for different windows versions?
[15:32] <evand> I've already duped it and adjusted the parent bug accordingly
[15:36] <davmor2> cool :)
[15:42] <shtylman_> evand: miller projection?
[15:42] <shtylman_> I looked around and I think its mercator
[15:42] <shtylman_> did you actually find where it said miller?
[15:42] <shtylman_> or are they the same?
[15:51] <evand> miller, they're different
[15:52] <shtylman_> isn't it the same timezone map as before...just different colors?
[15:52] <evand> http://en.wikipedia.org/wiki/Miller_cylindrical_projection
[15:52] <evand> updated artwork, but yes, the same base map
[15:54] <shtylman_> ?? http://en.wikipedia.org/wiki/File:Timezones2008.png ??
[15:54] <davmor2> evand, cjwatson: Partitioner screen text layout is way off here :( http://www.davmor2.co.uk/part.png
[15:57] <evand> shtylman_: yes.  It's generated from the PDF version, as found on the CIA's website.
[15:57] <shtylman_> evand: that is a mercator projection... according to the caption...
[15:57] <shtylman_> :)
[15:59] <evand> shtylman_: Where do you see that?  I'm looking at the bottom left that says it's a Miller cylindrical projection
[15:59] <shtylman_> evand: haha...well thats great... the descption on the wiki page says mercator...and the map says miller
[15:59] <shtylman_> haha
[16:00] <evand> miller is a modified mercator projection :)
[16:00] <evand> davmor2: interesting, that should be in a scrolledwindow.
[16:00]  * evand digs
[16:06] <cjwatson> shouldn't the "Windows Vista/Longhorn (loader)" bit wrap? seems better than horizontal scrolling
[16:07] <superm1> shouldn't the longhorn bit really be dropped at this point in the first place since it's a launched product?
[16:10] <cjwatson> probably. partially orthogonal to the question though
[16:19] <evand> sure
[16:27] <kirkland> superm1: i thought i had fixed kvm's dkms-ification, but bug #341159 just got reported
[16:27] <ubottu> Launchpad bug 341159 in kvm "package kvm-source 1:84+dfsg-0ubuntu7 failed to install/upgrade: " [High,Triaged] https://launchpad.net/bugs/341159
[16:27] <kirkland> superm1: could you take a look and see if you can tell what we're doing wrong?
[16:31] <superm1> kirkland, huh? intrepid->hardy upgrade?
[16:33] <kirkland> superm1: i assumed that was a mistake by mvo
[16:33] <superm1> kirkland, so perhaps the kernel headers weren't installed for the current running kernel
[16:33] <kirkland> superm1: i'm sure he means intrepid -> jaunty
[16:34] <superm1> take a look at that make.log in /var/lib/dkms/kvm/84/build if possible
[16:34] <superm1> remember during a dist upgrade it's trying to use the headers for the current running kernel to build not the new kernel that got installed with the dist upgrade
[16:34] <kirkland> okay
[16:36] <superm1> kirkland, otherwise i think your postinst looks correct.
[16:36] <kirkland> superm1: okay
[16:36] <kirkland> superm1: it also might be an i386 problem
[16:36] <kirkland> superm1: i've only tested this on amd64
[16:36] <kirkland> superm1: i'm installing i386 in a vm now
[16:36] <superm1> kirkland, ah
[16:36] <superm1> kirkland, so maybe what you'll want to do is check that the headers are installed at the time of the postinst, and if they're not, dont run the build, just let the autobuilder service handle it upon boot
[16:37] <kirkland> superm1: hmm, really?
[16:37] <superm1> kirkland, well depending on what the root cause is here;  if it's because the headers from intrepid's kernel aren't there, you dont have many other options
[16:38] <kirkland> superm1: yeah
[16:38] <superm1> ask the poster to add that log though for assistance in debugging further if possible though
[16:39] <cjwatson> vista/longhorn> fix committed upstream
[16:39] <cjwatson> (os-prober, to just call it vista)
[16:41] <davmor2> evand: is the map different on oem user setup deliberately ?
[16:42] <evand> davmor2: no, it's fixed in oem-config bzr though
[17:18] <shtylman_> cjwatson: put in another review
[17:18] <shtylman_> evand: better city placement code if you are interested (using the miller projection and playing with the numbers a bit) ... ( I really hate cities being out of place :) )
[19:08] <cr3> I just noticed an Ignore/Cancel prompt during partitioning, is there a way to preseed that?
[19:13] <davmor2> cr3: that is because of a races issue were you over writing lvm?
[19:13] <cr3> davmor2: it is possible that the machine was running an lvm test before
[19:14] <davmor2> cr3: should be fixed on some cds but not ubuntu.
[19:14] <cr3> davmor2: but I have a few preseeds to automate lvm overwriting: d-i partman-lvm/device_remove_lvm boolean true; d-i parman-md/device_remove_md boolean true; d-i partman-lvm/confirm boolean true
[19:14] <cr3> davmor2: ok, if this is a problem pending to be fixed, all good
[19:15] <davmor2> cr3: with the races issue gone so will the ignore/cancel
[19:15] <cr3> sweet
[19:15] <davmor2> cr3: should work on server if you have a preseed for that and the lastest iso's
[19:16] <cr3> davmor2: I'll probably get around to testing that tomorrow for alpha 6
[19:18] <davmor2> cr3: well that should be fixed so it should just work :)
[19:22] <kirkland> cjwatson: do you know off hand what the login password length limit is in adduser/passwd?
[19:22] <kirkland> cjwatson: i'm getting:
[19:22] <kirkland> Enter new UNIX password:
[19:22] <kirkland> Retype new UNIX password:
[19:22] <kirkland> passwd: Permission denied
[19:22] <kirkland> passwd: password unchanged
[19:22] <kirkland> in adduser when using a long (~128 chars) login passphrase
[19:22] <kirkland> this is in trying to reproduce a bug reported against ecryptfs-utils
[20:57] <davmor2> cjwatson: just to let you know 20% lvm worked a charm.  I used rescue mode test to dd the partition to carry on :)
=== shtylman_ is now known as shtylman
[22:28] <cjwatson> kirkland: not offhand, sorry
[22:28] <cjwatson> davmor2: yay
[22:29] <kirkland> cjwatson: no worries, i was about to look at the code and got pull of into a different shitstorm
[22:53] <xivulon> davmor2, evna hi
[22:53] <xivulon> evand
[22:53] <davmor2> xivulon: heelo
[22:53] <davmor2> hello even
[22:55] <xivulon> hi, how are things going with the testing?
[22:56] <davmor2> wubi went okish
[22:57] <xivulon> I have seen the permission issue in Vista, will have a look on how to escalate privileges
[22:57] <xivulon> did you test rev 90?
[22:57] <xivulon> should have close a couple of previous issues
[22:58] <xivulon> closed
[22:59] <xivulon> is there anything else I should be aware of?
[23:09] <davmor2> xivulon: yes cd still doesn't eject and evand fixed the autorun issue which I know technically isn't to do with wubi but it meant you got no umenu
[23:11] <xivulon> The laptop with windows is dead (power connector needs to be replaced), so I have to create a new testing rig before I can play with that
[23:12] <xivulon> for the rest did it work? a quick workaround for the vista permissions is to use run-as and execute  wubi as admin
[23:16] <davmor2> xivulon: I'll try that on kubuntu tomorrow and see :)
[23:17] <xivulon> davmor2 thanks a lot