[01:55] what shall be the default fallback colour if visual a11y is enabled and hence we are not showing the wallpaper? [02:00] xnox: Black or white would be fine. [02:00] xnox: Any attempts at being fancy could run into color blindness issues with background and foreground appearing to bleed into each other. [02:00] xnox: (Pick the opposite of what the installer window is) [02:02] google indicates there are special a11y colour wheels to ensure high-contrast with different types of disorders e.g. some highly contrasting colours for a healthy eye may not appear as much contrasting with some disorders. [02:02] * xnox will use gsettings default fallback colour and later ubuntu-defaults could be changed. [11:40] I'm trying to install Ubuntu 12.10 64Bit with HD encryption. [11:41] There is a strange behaviour when it comes to the password. [11:41] The window shows if the password is good or weak etc. [11:42] However if I have a strong password (according to the interface) and add some characters it shows that the password is too short. [11:43] Example: 11Qwertz$ is shown as strong [11:43] bug 1068391 [11:43] Launchpad bug 1068391 in ubiquity (Ubuntu) "Password strength bug" [Undecided,Confirmed] https://launchpad.net/bugs/1068391 [11:43] thanks cjwatson [11:46] What a peculiar bug ... [11:47] Hmm, the pages of that notebook are in the wrong order, I think [11:47] oh. [11:48] So it goes weak -> fair -> good -> strong -> too_short instead of too_short -> weak -> fair -> good -> strong [11:48] xnox: shall I just fix the ordering? pretty sure that's all there is to it [11:49] cjwatson: go ahead. [11:49] I wonder if glade screwed me over though, as it sometimes does by auto-reordering stuff... [11:50] I was just going to edit the XML :) [11:51] =) [11:51] does anyone have good example code for respawning child processes ? like with using signal() and catching SIGCHILD ? [11:51] The password_match position numbers look odd too [11:51] * ogra_ would like to try to add respawning to the compiz invocation in ubiquity-dm [11:51] 1/2/3 rather than 0/1/2 [11:53] Can ubiquity (well oem-config) in gtk frontend be pre-seeded with WiFi network configuration? And if not, what's the best way to achieve it, with ideally fetching preseed file for automatic-oem-config over the network. [11:56] Probably not right now; it's probably not worth turning the wireless page into a full-blown debconf confmodule, but it could at least populate and check a select template [11:57] if you refer to nx7 images, you can add a preseed file to / of either initrd or the img [11:58] not sure if there are keys for wlan preseeding we use though [11:59] (note though that the debconf call to apply the preseed file happens from ac100-tarball-installer, will not work once that has removed itself) [12:02] ogra_: ok. I think I can then add more hacks to ac100-tarball-installer, as I was thinking to only pass a SSID & password on the kernel command line and make something drop a shell hook into the hooks dir which does a `nmcli device wifi connect myhotspot mypass` [12:03] feel free :) [12:03] and just have a static (sample) preseed file shipped in oem-config package to allow automatically zip through oem-config. [12:04] but that is still limitting as qa would most likely want utah-client / openssh-server and hooks to trigger that. [12:04] they should sefine that in late_command [12:05] *define [12:05] in an apt call [12:05] right but how would they get it on the image, as I daubt that initramfs in nexus7 will be able to bring the network up. Kernel cmd line arg with a URL to late command? [12:06] they have a local mirror [12:06] as log as wifi gets brought up during the automated oem-config run, they shoudl be fine [12:09] qbi: Fixed for raring; sorry about that. In 12.10, "Strong" should apparently be read as "Good" and "Short" should be read as "Strong". :-/ [12:09] ogra_: hmm... i was hoping that one can just update kernel boot args and not unpacking & changing initrd. [12:09] (QA?) [12:10] xnox, i think thats the smallest issue, plars has scripts for injecting files into initrds [12:11] ok. [12:11] cjwatson: yeah, for QA lab. [12:11] the last piece of the puzzle would be rebooting form ubuntu into android fastboot mode. [12:11] xnox: No, I was referring to the fact that we didn't catch bug 1068391 before release [12:11] Launchpad bug 1068391 in ubiquity (Ubuntu Raring) "Password strength bug" [High,Fix committed] https://launchpad.net/bugs/1068391 [12:12] i think he also researched the "reboot bootloader" bit (at least he has a WI for it somewhere) [12:12] But in fact QA did spot it just about before release - bug 1067799 [12:12] Launchpad bug 1067799 in ubiquity (Ubuntu) "same password is reported as fair (disk encryption key) and weak (user password)" [Medium,New] https://launchpad.net/bugs/1067799 [12:12] Not in time to fix it though [12:52] cjwatson: Thanks. ;) [12:56] cjwatson: yeah, I seem to recall that at the end. Would be nice if there were a good way to automate all the corner-case testing for this. Is the piece that checks this and reports the strength embedded inside ubiquity (or di?) or is it a separate piece that they call and we could test more directly with a list of cases? [12:57] The former [12:57] It's in the ubiquity.validation Python module - but as it happens the bug here wasn't in the validation module, it was in the UI code making use of it [12:58] if we could run autopilot in the live cd.... [13:05] crazy talk [14:19] ph. nexus7 initrd is xz compressed, yet ours is with gzip. [14:19] (on the desktop that is) [14:20] mine is 26MB and I'd prefer it to be smaller as I have separate /boot partition and full disk encryption [14:20] xnox, rsyncability breaks with xz [14:20] (and zsyncability) [14:21] for personal use you can easily swithc it in the initramfs.conf [14:21] on the images sure, but our installer always does update-initramfs and the installed system can / should use xz. [14:22] Using xz probably increases boot times. Is disk space that important on non-phablet devices? [14:27] well, the time you waste in unpacking might be gained by faster loading it from disk [14:27] *re-gained [14:27] i doubt it would be significantly slower [14:29] No, it's probably not a big deal one direction or the other. [14:30] Defaulting to xz doesn't sound like an awful idea. [14:30] btw ... xz ... [14:30] is pxz in main already ? [14:30] No. [14:30] * ogra_ hanst started testbuilds with it yet [14:30] k [14:31] *hasn't [14:31] I'm not sure how comfy I am with "supporting" it unless upstream can convince the xz-utils people to carry it in their codebase. [14:31] (Or, more realistically, roll it into xz(1) as a command-line option) [14:31] well, it would have to be a live-build dep to use it [14:32] for nx7 images [14:32] wvwn though i didnt test with it yet, i looked at the nedded live-build changes [14:32] geez ... my typing [14:33] *even [14:33] pxz is not stable for me - not enough testing it can fail to pack/unpack. [14:33] 26 MB vs 19MB [14:33] not sure if it was worth it. [14:33] for your initrd ? [14:33] thats insane ! [14:34] * xnox has plymouth, mdadm, cryptsetup, lvm and what not in it. [14:34] (that's for my usual machine) [14:36] still insane to have a two digit megabyte value for that [14:36] we urgently need to lose fat here [14:37] its just an initrd [14:40] * ogra_ remebers times where 26MB was big for a rootfs [14:40] but then i'm an old fart ... [14:43] You sure are. [16:51] is it safe to call `apt-get autoremove` at the end of oem-config? there is garbage left around which is $arch specific. Or shall I be generating the removal command at build time? [16:51] i guess we should lighten up the dependencies. Or like seed them instead. As e.g. there is no point in having os-prober and uboot on nexus7 images. [16:52] infinity: ^ ? [16:54] xnox: I had meant to do that years ago. Should be entirely safe. [16:54] xnox: In oem-config-remove. [16:54] ok. [16:54] * xnox like. [16:54] And oem-config-remove-gtk [16:54] * infinity nods. [16:54] (which uses aptdaemon iirc) [16:55] yeah, i hope aptdaemon knows auto-remove action. [16:55] If it doesn't, you could cheat and just fork apt-get.