[00:09] <CIA-23> console-setup: cjwatson * r47 ubuntu/debian/ (changelog config.proto): * Set default for Dutch to us(intl), not just us (LP: #129982).
[00:13] <CIA-23> console-setup: cjwatson * r48 ubuntu/debian/changelog: releasing version 1.21ubuntu2
[00:21] <CIA-23> debian-installer: cjwatson * r872 ubuntu/debian/changelog: releasing version 20070308ubuntu27
=== cjwatson_ is now known as cjwatson
[08:42] <ganesh> how to upldate  the grub when the filesystem copied from live cd
[09:24] <superm1> evand, Kano threw this together earlier tonight: http://kanotix.com/files/thorhammer/updates/casper/casper-aufs.patch  .  You may consider adding it to casper, there should be an upcoming patch to the kernel for aufs support (which is where its headed)
[09:34]  * mpt wishes there was some way of telling the installer "Show only those keyboard layouts for which Shift+3 gives me a # symbol not a £ symbol dammit" :-)
[09:35] <superm1> hehe
[09:47] <cjwatson> casper patch looks sane at first glance
[09:48] <superm1> at very worst it shouldn't break anything, but it won't be testable until aufs gets in lum
[10:01] <mpt> cjwatson, evand wrote that "Colin is taking care of" presenting the list of languages in isolinux before showing the main menu. Is that right?
[10:02] <mpt> And if so, is that tracked in a bug report? (I don't see one)
[10:03] <CIA-23> ubiquity: cjwatson * r2421 ubiquity/ (debian/changelog scripts/install.py): * Run fontconfig-voodoo with --force.
[10:11] <CIA-23> oem-config: cjwatson * r407 oem-config/ (3 files in 3 dirs):
[10:11] <CIA-23> oem-config: * Call 'fontconfig-voodoo --auto --force --quiet' on startup and when the
[10:11] <CIA-23> oem-config:  language is changed. May help with LP #185269.
[10:11] <ubotu> Launchpad bug 185269 in oem-config "Incorrect Chinese Characters in Firstboot" [High,Confirmed] https://launchpad.net/bugs/185269
[10:12] <cjwatson> mpt: yes; it's tracked in the HardyBootloaderReview spec
[10:13] <cjwatson> haven't actually started on it yet though
[10:13] <CIA-23> ubiquity: cjwatson * r2422 ubiquity/ (debian/changelog ubiquity/components/language.py):
[10:13] <CIA-23> ubiquity: * Call 'fontconfig-voodoo --auto --force --quiet' when the language is
[10:13] <CIA-23> ubiquity:  changed. May help with LP #185269.
[10:13] <ubotu> Launchpad bug 185269 in oem-config "Incorrect Chinese Characters in Firstboot" [High,Confirmed] https://launchpad.net/bugs/185269
[10:16] <cjwatson> mpt: why?
[10:21] <mpt> cjwatson, I'm following up on Thorsten Wilms' review, linking to the relevant bugs/blueprints
[11:50] <xivulon> I have also experienced bug #186711 when testing wubi yesterday
[11:50] <ubotu> Launchpad bug 186711 in partman-target "The installer needs to remove operating system files from the install target, but was unable to do so. The install cannot continue" [Undecided,New] https://launchpad.net/bugs/186711
[11:51] <xivulon> it worked well in VM but for some reason did not work on real hardware
[11:52] <xivulon> was late and did not have time to debug properly, will resume tonight
[12:05] <mpt> I experienced that bug this morning :-)
[12:07]  * xivulon glad it's not me breaking stuff
[12:09] <xivulon> that means that the wubi frontend might be okish for initial testing (once update-grub/umountfs patches hit the new builds)
[12:20] <cjwatson> I'm going to milestone that for alpha-4, since it seems to be biting a lot of people
[12:21] <CIA-23> ubiquity: cjwatson * r2423 ubiquity/debian/changelog: usability -> accessibility
[12:45] <xivulon> talking of accessibility, mpt, any progress there?
[12:59] <mpt> xivulon, not in the next three weeks sorry. I'll be busy with music-in-Ubuntu + photos-in-Ubuntu + Launchpad this week, and on holiday the two weeks after that.
[13:07] <xivulon> sure, note that I just discovered that the Ease of Access thingy is Vista only... So detecting windows accessibility settings might not be trivial
[13:10] <xivulon> cjwatson, evand, did you do any testing with layoutcode preseeding by any chance, I forgot to test that myself?
[13:16] <xivulon> also there is a minor glitch in ubiquity automatic, whereby at startup a large window is displayed for 1 sec or so, which then vanishes and the progress dialog gets displayed
[14:01] <evand> I would advise against trying to automagically detect the Windows a11y settings.  I spoke with TheMuso about this and he said that most a11y tools do not record their presence or purpose in a common location.  I think asking the user to select from a list of options is perfectly reasonable.
[14:08] <evand> I'm also aware of that brief display of the main window.  I thought I had fixed it a while back, but I'll take care of it.
[14:08]  * evand goes to unbreak the world.
[14:18] <saispo> it maybe a silly question, but for build an amd64 cd i just do "ARCH=amd64 DIST=gutsy project cron.daily" ?
[14:22] <xivulon> evand I should have fixed the preseed recipes, you can have a go with the new build
[14:22] <xivulon> if it's good enough it might go into alpha4
[14:23] <xivulon> cdboot is still supported as a flag, (wubi --cdboot)
[14:23] <xivulon> forgot to add confirmation dialog in that case
[14:24] <cjwatson> saispo: 'ARCHES=amd64 DIST=gutsy for-project ubuntu cron.daily' I'd've thought
[14:24] <saispo> ok, thanks :)
[14:38] <xivulon> evand, mpt, re accessibility, there isn't much interaction in the windows frontend itself other than insterting the password and pressing install
[14:38] <xivulon> particularly considering than any windows accessibility tool would probably be active at the time
[14:39] <xivulon> if the user has to activate accessibility within wubi, he might just as well do it after ubuntu installation
[14:40] <xivulon> while by autodetecting existing settings/apps, we might avoid this last step, hence it might be worth giving it a go
[14:44] <evand> The scenario I have in my head is that a blind user starts Wubi, their existing Windows screen reader reads the a11y options to them, they select "Blindness" and press install.  Wubi adds access=v3 to the kernel command line, capser picks that up, does the necessary magic and orca is launched along with ubiquity and added to their session post-install.
[14:45] <evand> let me know if that got cut off.  Speaking of which, anyone know offhand if there's a way to tell irssi to split long messages?
[14:45] <xivulon> got it al
[14:45] <evand> All of the infrastructure is there, wubi just needs a drop down box with the a11y options and the backend code to take the selected option and stick it on the kernel command line
[14:46] <xivulon> last is the easy part, as for the list is mostly a matter of making it accessible in itself
[14:47] <evand> that was my point, we can expect that the user has already taken care of this by installing a screen reader in windows
[14:47] <xivulon> I'd prefer to detect the screen reader itself, if not I might have a button "accessiblity" that diplays a new form with checkboxes
[14:47] <evand> as I said above, I don't think it's possible to detect the screen reader
[14:49] <xivulon> Then I will add "accessibility" where you normally have the back button
[14:49] <xivulon> 1 page with V1, v2, v3, m1, m2 checkboxes (and proper localized labels)
[14:50] <evand> whatever UI you decide on is fine with me.  If you want to stay consistent with Windows, I believe the log in screen has an accessibility button (at least in Vista it does) that you could use as an example.
[14:51] <evand> I don't think the codes have any significance to users, you probably just want the localized labels.
[14:51] <xivulon> absolutely
[14:51] <evand> ah, indeed
[14:52] <xivulon> mpt, if you agree on the above I will add a comment on bug #185954
[14:52] <ubotu> Launchpad bug 185954 in wubi "Detect accessibility settings" [Medium,Confirmed] https://launchpad.net/bugs/185954
[14:53] <mpt> xivulon, I think this is out of my league actually
[14:54] <mpt> I have access to a Vista VM, but it's not activated a.t.m.
[14:58] <xivulon> evand the accessibility options are mutually exclusive or not? particularly within the same category.
[14:59] <evand> yes they are
[14:59] <xivulon> what happens if I boot with v1 v3 m1 m2?
[14:59] <evand> it just takes whatever is first
[15:00] <xivulon> v1 in the above case
[15:00] <xivulon> not v1 m1
[15:00] <evand> actually, I may be wrong here
[15:02] <xivulon> it should be highest option in each group: v3 m2
[15:02] <evand> it looks like they can be used together, but talk to TheMuso on #ubuntu-devel, he'll know for sure what the intended outcome is.
[15:03] <evand> casper definitely accepts any combination of them.
[15:03] <cjwatson> OTOH gfxboot-theme-ubuntu will only let you pick one
[15:04] <evand> oh, right. hrm.
[15:04] <cjwatson> so unclear what the intent is; I agree, talk to Luke
[15:05] <evand> xivulon: you may have some difficulty in reaching him at the moment as he's in Australia.  Sorry, I should've said that earlier.
[15:05] <xivulon> ah
[15:05] <evand> his email address is listed on his LP page though: https://launchpad.net/~themuso
[15:06] <xivulon> changed 185954 description
[15:07] <xivulon> I think that the options should be in separate radio groups, 1 per category.
[15:07] <xivulon> And that it should be possible to boot with more than one profile at once, particularly for separate categories
[15:07] <xivulon> If that is not the case, it should be fixed
[15:44] <xivulon> evand, do you think it is reasonable to have wubi full in alpha 4?
[15:51] <evand> quite hard to say at the moment, I don't know when the seeds are going to reopen, or if the latest grub really fixes things (I'm going to be looking at that today).  I'll keep you posted though.
[15:53] <xivulon> as mentioned I think that the frontend is ok
[15:53] <xivulon> pending changes should be independent of the frontend at this point
[15:54] <evand> indeed, I tried your new version and it fixed the issues for me.
[15:54] <cjwatson> seeds are open
[15:54] <cjwatson> archive is soft-frozen
[15:54]  * xivulon likes the sound of that
[15:54] <cjwatson> (but important reasonable things can still go in)
[15:55] <xivulon> like wubi :=)
[15:56] <evand> ah, fantastic
[15:56] <xivulon> not sure what winfoss status is anymore, but the call for cdboot is now "wubi --cdboot"
[15:56] <evand> did heno ever get back to you?
[15:56] <xivulon> nope
[15:57] <evand> odd
[15:58] <evand> ah, thanks for fixing the system-config-printer breakage, cjwatson.
[15:58] <cjwatson> yeah, was playing with virt-manager and ran right into it
[16:00] <xivulon> evand the last patch in 151579 is in correct?
[16:02] <evand> xivulon: not yet, I'd like to rearrange it so it's no more verbose than it was prior to the patch, I just haven't had a chance yet.
[16:03] <xivulon> evand, that is a hard requirement since without that you have an fs freeze at each reboot
[16:04] <xivulon> cjwatson you may also want to review the prosed patch
[16:04] <xivulon> it's an hybrid of what we discussed in the past
[16:04] <cjwatson> I'm happy for evand to review it
[16:05] <xivulon> If it can help the patch skips all the mountpoints in the top section of /proc/mounts (like before)
[16:05] <xivulon> On top of it, for the mountpoints in the bottom half, that have a device which is also in top half, it removes the -f flag when umounting
[16:06] <xivulon> since umount -f mountpoint ~ umount device (at least for bindmounts)
[16:07] <xivulon> that is an issue for wubi since /boot is bindmounted and the device is the same as /host
[16:07] <evand> speaking of bind mounts, I noticed that update-initramfs doesn't seem to play nice with a bind mounted /boot.  It's on my list of things to look at.
[16:08] <xivulon> ah I think I know that
[16:09] <xivulon> if you replace the initrd it works, if you update it, it does not
[16:09] <xivulon> update-initramfs -k $(uname -r) should work for instance
[16:09] <xivulon> do not know why the update fails though
[16:09] <evand> it thinks /boot is mounted ro from the warning that I got
[16:10] <xivulon> nope
[16:10] <xivulon> that's the error message but it must be bogus
[16:10] <xivulon> since boot is rw (try to write to it) and since if you replace the initrd it works ok
[16:11] <xivulon> -c flag
[16:12] <xivulon> try: update-initramfs -c -k $(uname -r)
[16:12] <xivulon> is there a bug for it already?
[16:14] <xivulon> I noticed some time ago' and forgot to file a report
[16:16] <evand> I haven't filed a bug report, no.
[16:16] <xivulon> I can do that
[16:17] <cjwatson> I wonder if the ro_boot_check function is broken then
[16:17] <cjwatson>         boot_opts=$(awk '/boot/{if (match($4, /ro/) && $2 == "/boot")
[16:17] <cjwatson>                 print "ro"}' /proc/mounts)
[16:17] <cjwatson>         if [ -n "${boot_opts}" ]; then
[16:17] <cjwatson> that's the logic
[16:17] <cjwatson> /ro/ doesn't happen to match something else in the mount options, does it?
[16:17]  * cjwatson hates dodgy checks like that ...
[16:18] <cjwatson> could match errors=remount-ro for instances
[16:18] <cjwatson> s/s$//
[16:20] <xivulon> don't recall what is in there normally, it might well be the case. the only thing I noticed is that update-initramfs -c works, while update-initramfs -u does not
[16:21] <cjwatson> right, I'm just trying to analyse :)
[16:21] <xivulon> I mean I do not have a loopinstallation at hand to have a look at
[16:21] <cjwatson> if that fires, you get a message "WARNING: /boot is ro mounted."
[16:22] <xivulon> seems very plausible, I'd say that if the same check is not there for -c then I'd put my money on it.
[16:22] <cjwatson> that's correct
[16:23] <cjwatson> it's only called in the update path
[16:23] <xivulon> then 1 bug less
[16:23] <cjwatson> not until it's fixed ;-)
[16:24] <xivulon> That said, the check should be in -c also though
[16:26] <cjwatson> maybe; I do wonder why it causes update-initramfs to exit 0 rather than 1, so in its current form adding it to -c might cause errors to go unnoticed
[16:32] <xivulon> I do not see why -u should fail silently anyway, if that is required the calling app should trap the error
[16:41] <evand> ah, so my logic in clear_partitions completely fails to account for the fact that you cannot remove a directory that's a mountpoint.
[16:51] <bdmurray> When did ubiquity start warning about reserved usernames?  Those types of bugs should be "Fix Released" right?
[16:51] <cjwatson> ah
[16:51] <cjwatson> bdmurray: somewhere between dapper and edgy
[16:52] <cjwatson> ubiquity 1.1.28
[16:53] <bdmurray> Reading the bug report closer - does debian-installer also warn?
[16:55] <evand> yes, it's done by user-setup, the underlying d-i component.
[16:57] <cjwatson> there was a separate bug on user-setup
[17:02] <CIA-23> apt-setup: cjwatson * r118 apt-setup/ (3 files in 2 dirs):
[17:02] <CIA-23> apt-setup: * Add apt-setup/proposed question (never asked); if preseeded to true,
[17:02] <CIA-23> apt-setup:  -proposed entries will be added to sources.list (LP: #181776).
[17:03] <CIA-23> net-retriever: cjwatson * r340 ubuntu/ (debian/changelog net-retriever): * Fetch installer components from -proposed if apt-setup/proposed is true.
[17:06] <CIA-23> base-installer: cjwatson * r321 ubuntu/ (debian/changelog library.sh):
[17:06] <CIA-23> base-installer: * If apt-setup/proposed is true, set up the default sources.list to look
[17:06] <CIA-23> base-installer:  in -proposed as well (LP: #181776).
[17:06] <CIA-23> net-retriever: cjwatson * r341 ubuntu/debian/changelog: last commit closes LP: #181776
[17:59] <cjwatson> bdmurray: the bug report says "XUbuntu 6.10-lts" so who knows what he actually meant :-) I suspect 6.06 LTS
[18:00] <xivulon> evand see http://paste.ubuntu-nl.org/53974/
[18:00] <xivulon> should have same verbosity as before
[18:00] <xivulon> did not test that though
[18:00] <bdmurray> Yeah it is hard to say.
[18:05] <bdmurray> cjwatson: One thing I wanted to talk about last week was the console-setup project in Launchpad.  It says it doesn't use bugs but I thought it should point to the debian bug tracker.
[18:05] <cjwatson> is that possible?
[18:06] <cjwatson> oh, hey, that's new
[18:06] <cjwatson> that feature didn't exist when I/others registered all the bits of d-i :)
[18:06] <cjwatson> I've changed console-setup, will go round and change others too
[18:07] <cjwatson> doesn't really produce a fantastic link mind you
[18:08] <cjwatson> hey, neat, I can just change the bug tracker for d-i and it changes all the bits at once
[18:25] <bdmurray> cjwatson: I've also submitted bug 181860 - what is the deadline to get that fixed?  Since it is something I could help with.
[18:25] <ubotu> Launchpad bug 181860 in console-setup "spelling or grammar issue" [Undecided,New] https://launchpad.net/bugs/181860
[18:29] <cjwatson> bdmurray: need to push that one upstream
[18:30] <cjwatson> (otherwise cue translation update nightmare)
[18:30] <cjwatson> I'll do it this week
[18:32] <bdmurray> Could I get the upstream code via bzr and create a branch or is just easier for you to do?
[18:34] <cjwatson> significantly easier for me to just do it
[18:34] <cjwatson> you can certainly get the current code from https://code.launchpad.net/~vcs-imports/console-setup/trunk
[18:34] <cjwatson> and a patch would probably speed things up
[18:35] <cjwatson> but I'll basically have to re-commit it to upstream svn anyway
[18:35] <cjwatson> the text in question was written by a Bulgarian and it does sort of show :)
[18:35] <cjwatson> very good coder, somewhat dodgy English
[18:38] <bdmurray> Okay.  I'm curious about how others can go about fixing strings like this as it seems like a potentially easy thing for new contributors to do.
[18:38] <cjwatson> best process is a bug report to upstream
[18:39] <cjwatson> the problem is that syncing up translations is a lot of manual work
[18:39] <cjwatson> upstream already has a process for doing all of this with loads of automation, and it's best to take advantage of it where possible
[18:39]  * cjwatson -> out for a bit
[18:40] <bdmurray> Is the translations bit complicated because it is in debian?
[19:36] <cjwatson> err, sort of, that's not really the reason
[19:36] <cjwatson> changing translated strings involves changing the gettext .po files for all languages supported by the package, which creates a massive diff that is a lot of manual labour to merge later
[19:36] <cjwatson> (our tools are pretty poor at doing it automatically)
[19:37] <cjwatson> and it also puts the burden on us to gather translations
[19:37] <cjwatson> if somebody else is already doing that, and if it's really just a bug rather than an Ubuntu-specific extension, then it just doesn't make sense to do the change locally in Ubuntu
[19:38] <cjwatson> especially as translations are difficult to forward upstream - you typically can't just commit them, you have to get approval from the translation teams or you get lots of angry e-mail
[19:38] <cjwatson> (been there, done that)
=== ceeka1 is now known as seeka1
=== seeka1 is now known as ceeekay