[13:11] <stgraber> cjwatson: did you have a chance to look at that diff I pasted yesterday? or do you prefer a MP for it?
[13:11] <cjwatson> Oh, right, one sec
[13:12] <cjwatson> Yeah, I think that's fine
[13:13] <stgraber> ok, I'll commit it then, hopefully that'll be the end of the weird langpacks related bugs :)
[13:14] <cjwatson> I've said that before ;-)
[13:14]  * xnox *giggles*
[13:15] <stgraber> :)
[14:16] <Gioyik> Hello
[14:16] <Gioyik> I have a question
[14:17] <Gioyik> i like to port the ubuntu installer to ArchLinux, how can i do it? Any guide?
[14:19] <xnox> Gioyik: there are two: ubiquity (graphical) and debian-installer (text based). The graphical one, is more-or-less a frontend to the text based one.
[14:19] <xnox> so it heavily relies on debian-installer, partman and apt
[14:20] <xnox> and debian-installer in turn heavily relies on udebs and debconf based configuration.
[14:20] <xnox> which is all very debian specific...
[14:22] <xnox> Gioyik: or you could take the UI, but then write your own backend logic for arch-way of installing. But you'll end up with something "inspired-by" or "rewritten-from-scratch".
[14:22] <xnox> Gioyik: just the design is outlined here http://goo.gl/Kokw5
[14:24] <Gioyik> i like to port ubiquity, a graphical installer, is posible to do it in a easy way?
[14:26] <cjwatson> There is not likely to be any easy way, no.  It has a large number of Debian/Ubuntu-specific assumptions.
[14:26] <cjwatson> There has never been any effort to make it more portable than that.
[14:26] <xnox> Gioyik: no, because it simply constructs automatic-preseeding to the debian-installer. Ubiquity is pretty, but doesn't actually do any bits of the installation.
[14:26] <cjwatson> Or at least nothing that resulted in code being merged into the mainline.
[14:27] <cjwatson> xnox: Well, that's not true.  But the bits it does are done Debian-specifically.
[14:27] <xnox> cjwatson: ok, true.
[14:27] <stgraber> jibel: can you still reproduce bug 960077?
[14:27] <ubot2> Launchpad bug 960077 in casper "live session with persistence - keyboard layout selected during first boot is used" [Medium,Incomplete] https://launchpad.net/bugs/960077
[14:28] <stgraber> jibel: I'm looking at it as a potential duplicate of bug 946406 but I'm having no luck reproducing the issue
[14:28] <ubot2> Launchpad bug 946406 in casper "suspect race condition Keyboard layout, oem-config not set on persistent USB image" [High,Incomplete] https://launchpad.net/bugs/946406
[14:28] <cjwatson> Gioyik: I'm not saying it's impossible, but it will be a long project and you'll have to do most of the legwork yourself.
[14:29] <cjwatson> Since there's no precedent there's no guide.
[14:29] <Gioyik> Mmmmm Ok Thanks foy your answers!
[14:51] <jibel> stgraber, I'll try and tell you.
[14:53] <stgraber> jibel: thanks
[16:01] <jibel> stgraber, I can't reproduce 960077. the right layout is active every time. I'll close it.
[16:02] <stgraber> jibel: ok. I checked all the code again and can't find anything wrong with it, though it's a known problematic part of casper...
[16:03] <stgraber> my guess is that in some cases, the keyboard layout ends up in the user's gsettings and so even if /etc/default/keyboard is correct, the layout still end up being wrong... but until I can reproduce it, I can't be sure and the various report of this are really blurry on what the user actually did...
[16:04] <jibel> stgraber, well compared to the bug report, there is only 1 layout listed in the keyboard settings and the applet is not displayed, while there were 4 before. So something changed here.
[16:04] <stgraber> yeah... having just one keyboard listed is the expected behaviour when you boot directly into the live session
[16:04] <stgraber> the only case where you should have more than one is if you go through ubiquity-dm
[16:05] <stgraber> but those bits are mostly owned by the desktop team, so things tend to change quite often... :)
[16:05] <stgraber> anyway, I did find quite a bunch of problems with persistence (though couldn't find bugs for those) which I fixed and a new casper is now in the upload queue waiting for review
[16:06] <stgraber> I'll kick a rebuild once that's approved and then prepare the next batch of fixes (trying to cleaup casper a bit so I don't have to do that on release week ;))
[16:07] <cjwatson> ... again
[16:08]  * xnox =)
[16:20] <stgraber> oh, that's a fun one... why is keyboard-configuration calling update-initramfs? :)
[16:20] <stgraber> that's making the "try ubuntu" button take something like a minute on my i7 test laptop
[16:21] <cjwatson> Because the initramfs contains keyboard configuration
[16:23] <cjwatson> Might make sense to divert update-initramfs around that, maybe
[16:23] <stgraber> oh right and as I'm using a persistent media, it can actually do something with an update initramfs...
[16:23] <stgraber> we already divert update-initamfs to casper-update-initramfs
[16:23] <cjwatson> Mm, nested diversions probably won't wowrk
[16:23] <cjwatson> *work
[16:24] <jibel> I was blaming my netbook where it takes much more than 1 minute
[16:24] <stgraber> I'll have to dig what was the exact reason for casper-update-initramfs and if we can't simply have that script exit 0 and be done with it
[16:25] <stgraber> I'm not really sure I actually want the live image to update the initrd even if the boot media is writable
[16:25] <cjwatson> upgrades of persistent live CDs
[16:25] <cjwatson> please don't revert that, it was a bug with Mark's attention on it
[16:25] <cjwatson> care needed
[16:26] <cjwatson> there were people running live images with persistence and wanting to be able to upgrade them across kernel ABI bumps and the like
[16:26] <cjwatson> whether this is a good idea or not, we have no real way to stop them doing this, so it's better to make it not explode
[16:26] <stgraber> wow, we have really weird users ;)
[16:26] <cjwatson> yeah, some of them pay our salaries ;-)
[16:27] <cjwatson> if we can't easily fix performance issues without breaking that, we'd better leave the performance issues in place until we figure it out properly
[16:27] <stgraber> ok, so I guess I'll change that script to exit 0 if the target isn't writable, that should take care of the cdrom use csae
[16:27] <stgraber> for the persistent media, well, it's apparently a "feature" that it's terribly slow, so I'll just leave it as is ;)
[16:28] <cjwatson> just be careful, I have a vague memory that [ -w ] didn't DTRT
[16:29] <infinity> Isn't -w just a permissions check?
[16:30] <infinity> You likely want something like wrapping a touch in a break/rollback or some such.
[16:30] <stgraber> I'll probably copy/paste the hack I have in dhclient-script. : >> "$file" and check the return code
[16:30] <infinity> Yeah, that. :P
[16:32] <cjwatson> -w is access(3) I think
[16:33] <cjwatson> And doesn't work if the fs refuses after that
[16:35]  * cjwatson peers at bug 1057485.  I can't make that tooltip say anything other than AM or PM in Greek
[16:35] <ubot2> Launchpad bug 1057485 in ubiquity "ubiquity-kde codepage problem in Timezone map (Timezone.py)" [High,Triaged] https://launchpad.net/bugs/1057485
[16:35] <cjwatson> In either 12.04 or 12.10
[16:36]  * cjwatson tries to reproduce this indirectly instead ...
[16:50] <stgraber> ok, I think http://paste.ubuntu.com/1256333/ will do the trick
[16:55] <cjwatson> Seems reasonable
[18:26] <stgraber> jibel: bingo! reproduced the bug!
[18:27] <stgraber> jibel: or at least found a way to get the same symptoms.
[18:29] <stgraber> 1) let it boot to ubiquity-dm, choose French and Essayer Ubuntu. 2) Reboot the system 3) Stop the boot in gfxboot, choose German and Ubuntu ohne Installation ausprobieren => you get an azerty layout instead of qwertz
[18:30] <ogra_> such a commmon usecase even !
[18:30] <stgraber> now to figure out how to fix that...
[18:30] <ogra_> :)
[18:31] <stgraber> ogra_: depends where. I have a lot of friends nagging me about it, but they are from the swiss loco and we have four languages and 2 keyboard layouts in the same country, so it happens...
[18:31] <ogra_> heh, yeah, but you are a weird country :)
[18:32] <ogra_> once seb and didrocks succeeded we'll all have to speak french anyway :)
[18:32] <stgraber> but yeah, getting ch-fr instead of ch-de isn't nearly as problematic as my example with fr and de ;) (ch-fr and ch-de are both qwertz layouts with only some accents swapped)
[18:33] <stgraber> as long as we don't need to switch to azerty too, it's fine ;)
[18:33] <ogra_> ++
[18:33]  * ogra_ wants a kbd with ß on it 
[18:34] <stgraber> I'm extremely glad I never had to learn that one, it's already enough of a mess in my head when moving between qwertz and qwerty :)
[18:34] <ogra_> not that i ever use that char ... but it makes me feel warm and cosy :)
[18:34] <stgraber> ogra_: my US int keyboard has it (not printed though, but alt-gr + s gives you ß)
[18:35] <ogra_> cool
[18:37] <stgraber> US int with alt-gr dead keys (altgr-intl) is really quite good. I get most common accented letters pressing just two keys (without dead keys) and for the rest you can compose them with the dead keys. And everything else is standard US qwerty so everything just works ;)
[18:39] <ogra_> my prob with the germany layout (not sure its like that on others) is that deadkeys steals my tilde
[18:40] <ogra_> and indeed i always forget to hit space when i need a tilde ...
[18:42] <infinity> I'm a pretty big fan of compose keys.
[18:42] <infinity> Compose+s+s isn't all that hard.
[18:42] <stgraber> US int is just shift + ` to get you ~, it's not a dead key. To get the matching dead key you need to do altgr+shift+`+key-to-put-the-~-on
[18:42] <ogra_> well, my finger memory is usually stronger than my fanboyship
[18:43] <ogra_> thats also my prob with unitys broken alt tab behavior
[18:43] <stgraber> so if you want ñ, you can use altgr+shift+`+n but then again, you could just use altgr+n which would give you the same thing :)
[18:43] <infinity> That sentence gave me a headache.
[18:44] <infinity> I think it might be time to finally sleep for a bit.
[18:55] <jibel> stgraber, that's what I did but the other way around, german first then french, aber ohne Glück
[18:58] <stgraber> jibel: odd. Anyway, I know how to fix it, it just won't be really pretty as I'll need to wipe a gsettings key from casper...
[19:18] <stgraber> yay for ugly hacks in casper... http://paste.ubuntu.com/1256656/
[19:19] <stgraber> I initially wanted to do it the same way as the accessibility stuff by writing a script on the target, though that wouldn't work in all cases as I really want that key flushed before ubiquity-dm starts...
[19:55] <stgraber> that's going to be one hell of a casper changelog...
[19:56] <stgraber> every time I fix a bug I'm finding a couple others, though hopefully we'll be good for a while after that with people complaining of weirdness on persistent systems
[20:07] <stgraber> ogra_: I took bug 984276 from you as I was messing with that code anyway.
[20:07] <ubot2> Launchpad bug 984276 in casper "installing casper on a non live system causes update-initramfs to fail" [High,Confirmed] https://launchpad.net/bugs/984276
[20:18] <ogra_> stgraber, thanks so much ...
[20:18] <ogra_> i'm pushing that bug since ages
[20:19] <stgraber> ogra_: my guess is that removing the few lines in the postinst will do the trick
[20:19] <stgraber> ogra_: it was trying to make the symlink and call update-initramfs from the postinst for some unknown (and AFAICS undocumented) reasons
[20:20] <stgraber> nowadays it's a casper hook making the symlink at boot time (+ a dpkg divert), so the one from postinst shouldn't be needed at all (I still need to test to be 100% sure)
[20:20] <cjwatson> Well in general anything that ships code in /usr/share/initramfs-tools/ calls update-initramfs.
[20:20] <ogra_> well, it is helpful if you locally want to roll a live initrd if the postinst runs it
[20:20] <stgraber> cjwatson: yeah, that part is fine, it's the part about making /usr/sbin/update-initramfs a symlink from the postinst that wasn't
[20:20] <cjwatson> Oh, err, check bzr history for that, I added that
[20:21] <cjwatson> Check what bug I was fixing and make sure you aren't reintroducing it :-)
[20:24] <stgraber> cjwatson: yeah, the change was http://paste.ubuntu.com/1256798/ and that's linked with bug 591207. Though I fail to see the reason for the postinst part of the change.
[20:24] <ubot2> Launchpad bug 591207 in casper "Casper's USB update-initramfs shim should look for initrd.img in /boot" [High,Fix released] https://launchpad.net/bugs/591207
[20:25] <stgraber> I'll recheck in a bit, maybe it's something obvious I'm just not seeing
[20:30] <cjwatson> It was probably needed to handle live media with the previous broken update-initramfs.
[20:30] <cjwatson> It may no longer be necessary.
[20:31] <cjwatson> Since nobody should still be running a system booted from code before that fix.
[20:31] <cjwatson> At least not and expect to upgrade it to quantal in one step.
[20:36] <stgraber> oh yeah, that makes sense. Will add a mention of that in the changelog.
[20:51] <stgraber> cjwatson: I see you are the one who moved bug 296129 from ubiquity to casper though I'm not really sure how we'd fix that in casper without causing huge log files for those using persistence. What do you think of getting ubiquity to chmod -x /usr/sbin/logrotate at the beginning of the install and restoring it post-install?
[20:51] <ubot2> Launchpad bug 296129 in casper "live Installer may rotate syslog during install and copy only a portion to /target/var/log/installer/syslog" [Medium,Triaged] https://launchpad.net/bugs/296129
[20:52] <stgraber> the cron.daily script checks for the executable bit on /usr/sbin/logrotate and exits 0 if it's not set, so we wouldn't be getting an error from the cron job and unless we're horribly unlucky, the logs shouldn't have been rotated by the time apport is triggered (cron.daily would have to trigger in the few seconds after install for that to happen)
[21:42] <cjwatson> stgraber: That sounds like a good option, yes
[21:42] <cjwatson> I probably wasn't thinking about persistence at the time