[01:55] <xnox> what shall be the default fallback colour if visual a11y is enabled and hence we are not showing the wallpaper?
[02:00] <infinity> xnox: Black or white would be fine.
[02:00] <infinity> xnox: Any attempts at being fancy could run into color blindness issues with background and foreground appearing to bleed into each other.
[02:00] <infinity> xnox: (Pick the opposite of what the installer window is)
[02:02] <xnox> 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] <qbi> I'm trying to install Ubuntu 12.10 64Bit with HD encryption.
[11:41] <qbi> There is a strange behaviour when it comes to the password.
[11:41] <qbi> The window shows if the password is good or weak etc.
[11:42] <qbi> 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] <qbi> Example: 11Qwertz$   is shown as strong
[11:43] <cjwatson> bug 1068391
[11:43] <ubot2> Launchpad bug 1068391 in ubiquity (Ubuntu) "Password strength bug" [Undecided,Confirmed] https://launchpad.net/bugs/1068391
[11:43] <qbi> thanks cjwatson
[11:46] <cjwatson> What a peculiar bug ...
[11:47] <cjwatson> Hmm, the pages of that notebook are in the wrong order, I think
[11:47] <xnox> oh.
[11:48] <cjwatson> So it goes weak -> fair -> good -> strong -> too_short instead of too_short -> weak -> fair -> good -> strong
[11:48] <cjwatson> xnox: shall I just fix the ordering?  pretty sure that's all there is to it
[11:49] <xnox> cjwatson: go ahead.
[11:49] <xnox> I wonder if glade screwed me over though, as it sometimes does by auto-reordering stuff...
[11:50] <cjwatson> I was just going to edit the XML :)
[11:51] <xnox> =)
[11:51] <ogra_> does anyone have  good example code for respawning child processes ? like with using signal() and catching SIGCHILD ?
[11:51] <cjwatson> 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] <cjwatson> 1/2/3 rather than 0/1/2
[11:53] <xnox> 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] <cjwatson> 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] <ogra_> if you refer to nx7 images, you can add a preseed file to / of either initrd or the img
[11:58] <ogra_> not sure if there are keys for wlan preseeding we use though
[11:59] <ogra_> (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] <xnox> 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] <ogra_> feel free :)
[12:03] <xnox> and just have a static (sample) preseed file shipped in oem-config package to allow automatically zip through oem-config.
[12:04] <xnox> but that is still limitting as qa would most likely want utah-client / openssh-server and hooks to trigger that.
[12:04] <ogra_> they should sefine that in late_command
[12:05] <ogra_> *define
[12:05] <ogra_> in an apt call
[12:05] <xnox> 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] <ogra_> they have a local mirror
[12:06] <ogra_> as log as wifi gets brought up during the automated oem-config run, they shoudl be fine
[12:09] <cjwatson> 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] <xnox> ogra_: hmm... i was hoping that one can just update kernel boot args and not unpacking & changing initrd.
[12:09] <cjwatson> (QA?)
[12:10] <ogra_> xnox, i think thats the smallest issue, plars has scripts for injecting files into initrds
[12:11] <xnox> ok.
[12:11] <xnox> cjwatson: yeah, for QA lab.
[12:11] <xnox> the last piece of the puzzle would be rebooting form ubuntu into android fastboot mode.
[12:11] <cjwatson> xnox: No, I was referring to the fact that we didn't catch bug 1068391 before release
[12:11] <ubot2> Launchpad bug 1068391 in ubiquity (Ubuntu Raring) "Password strength bug" [High,Fix committed] https://launchpad.net/bugs/1068391
[12:12] <ogra_> i think he also researched the "reboot bootloader" bit (at least he has a WI for it somewhere)
[12:12] <cjwatson> But in fact QA did spot it just about before release - bug 1067799
[12:12] <ubot2> 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] <cjwatson> Not in time to fix it though
[12:52] <qbi> cjwatson: Thanks. ;)
[12:56] <plars> 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] <cjwatson> The former
[12:57] <cjwatson> 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] <xnox> if we could run autopilot in the live cd....
[13:05] <ogra_> crazy talk
[14:19] <xnox> ph. nexus7 initrd is xz compressed, yet ours is with gzip.
[14:19] <xnox> (on the desktop that is)
[14:20] <xnox> mine is 26MB and I'd prefer it to be smaller as I have separate /boot partition and full disk encryption
[14:20] <ogra_> xnox, rsyncability breaks with xz
[14:20] <ogra_> (and zsyncability)
[14:21] <ogra_> for personal use you can easily swithc it in the initramfs.conf
[14:21] <xnox> on the images sure, but our installer always does update-initramfs and the installed system can / should use xz.
[14:22] <infinity> Using xz probably increases boot times.  Is disk space that important on non-phablet devices?
[14:27] <ogra_> well, the time you waste in unpacking might be gained by faster loading it from disk
[14:27] <ogra_> *re-gained
[14:27] <ogra_> i doubt it would be significantly slower
[14:29] <infinity> No, it's probably not a big deal one direction or the other.
[14:30] <infinity> Defaulting to xz doesn't sound like an awful idea.
[14:30] <ogra_> btw ... xz ...
[14:30] <ogra_> is pxz in main already ?
[14:30] <infinity> No.
[14:30]  * ogra_ hanst started testbuilds with it yet
[14:30] <ogra_> k
[14:31] <ogra_> *hasn't
[14:31] <infinity> 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] <infinity> (Or, more realistically, roll it into xz(1) as a command-line option)
[14:31] <ogra_> well, it would have to be a live-build dep to use it
[14:32] <ogra_> for nx7 images
[14:32] <ogra_> wvwn though i didnt test with it yet, i looked at the nedded live-build changes
[14:32] <ogra_> geez ... my typing
[14:33] <ogra_> *even
[14:33] <xnox> pxz is not stable for me - not enough testing it can fail to pack/unpack.
[14:33] <xnox> 26 MB vs 19MB
[14:33] <xnox> not sure if it was worth it.
[14:33] <ogra_> for your initrd ?
[14:33] <ogra_> thats insane !
[14:34]  * xnox has plymouth, mdadm, cryptsetup, lvm and what not in it.
[14:34] <xnox> (that's for my usual machine)
[14:36] <ogra_> still insane to have a two digit megabyte value for that
[14:36] <ogra_> we urgently need to lose fat here
[14:37] <ogra_> its just an initrd
[14:40]  * ogra_ remebers times where 26MB was big for a rootfs
[14:40] <ogra_> but then i'm an old fart ...
[14:43] <infinity> You sure are.
[16:51] <xnox> 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] <xnox> 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] <xnox> infinity: ^ ?
[16:54] <infinity> xnox: I had meant to do that years ago.  Should be entirely safe.
[16:54] <infinity> xnox: In oem-config-remove.
[16:54] <xnox> ok.
[16:54]  * xnox like.
[16:54] <cjwatson> And oem-config-remove-gtk
[16:54]  * infinity nods.
[16:54] <cjwatson> (which uses aptdaemon iirc)
[16:55] <xnox> yeah, i hope aptdaemon knows auto-remove action.
[16:55] <infinity> If it doesn't, you could cheat and just fork apt-get.