xnox | what shall be the default fallback colour if visual a11y is enabled and hence we are not showing the wallpaper? | 01:55 |
---|---|---|
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:00 |
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. | 02:02 | |
qbi | I'm trying to install Ubuntu 12.10 64Bit with HD encryption. | 11:40 |
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:41 |
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:42 |
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:43 |
cjwatson | What a peculiar bug ... | 11:46 |
cjwatson | Hmm, the pages of that notebook are in the wrong order, I think | 11:47 |
xnox | oh. | 11:47 |
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:48 |
xnox | cjwatson: go ahead. | 11:49 |
xnox | I wonder if glade screwed me over though, as it sometimes does by auto-reordering stuff... | 11:49 |
cjwatson | I was just going to edit the XML :) | 11:50 |
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:51 |
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:53 |
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:56 |
ogra_ | if you refer to nx7 images, you can add a preseed file to / of either initrd or the img | 11:57 |
ogra_ | not sure if there are keys for wlan preseeding we use though | 11:58 |
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) | 11:59 |
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:02 |
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:03 |
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:04 |
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:05 |
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:06 |
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:09 |
ogra_ | xnox, i think thats the smallest issue, plars has scripts for injecting files into initrds | 12:10 |
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:11 |
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:12 |
qbi | cjwatson: Thanks. ;) | 12:52 |
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:56 |
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:57 |
xnox | if we could run autopilot in the live cd.... | 12:58 |
ogra_ | crazy talk | 13:05 |
xnox | ph. nexus7 initrd is xz compressed, yet ours is with gzip. | 14:19 |
xnox | (on the desktop that is) | 14:19 |
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:20 |
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:21 |
infinity | Using xz probably increases boot times. Is disk space that important on non-phablet devices? | 14:22 |
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:27 |
infinity | No, it's probably not a big deal one direction or the other. | 14:29 |
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:30 |
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:31 |
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:32 |
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:33 |
* xnox has plymouth, mdadm, cryptsetup, lvm and what not in it. | 14:34 | |
xnox | (that's for my usual machine) | 14:34 |
ogra_ | still insane to have a two digit megabyte value for that | 14:36 |
ogra_ | we urgently need to lose fat here | 14:36 |
ogra_ | its just an initrd | 14:37 |
* ogra_ remebers times where 26MB was big for a rootfs | 14:40 | |
ogra_ | but then i'm an old fart ... | 14:40 |
infinity | You sure are. | 14:43 |
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:51 |
xnox | infinity: ^ ? | 16:52 |
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:54 |
xnox | yeah, i hope aptdaemon knows auto-remove action. | 16:55 |
infinity | If it doesn't, you could cheat and just fork apt-get. | 16:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!