[12:31]  * xnox took the plunge and bought a SecureBoot capable motherboard with two fakeraid controllers.
[12:32] <xnox> should be nice for d-i work / image testing. As well as case/ram/cpu to match.
[12:32] <cjwatson> My new server is SB-capable but like hell I'm SBifying it
[12:32] <cjwatson> (And isn't one I can take down for experimentation)
[12:33] <xnox> well i have 4 disks so I do plan on taking it up & down for testing / developing on it. virt-manager works nicely over kvm+ssh so i can continue working on my laptop when this new desktop is down.
[12:34] <xnox> so not sure if that machine will have desktop installed or not. i am expecting livecd to fly on it.
[12:38] <cjwatson> I have a new (well, QA-surplus) laptop which I'll be trying to reproduce the GRUB efinet problems on shortly, once I've finished backing up its existing contents
[12:38] <cjwatson> This would go a lot faster if the gigabit switch I ordered the other day had arrived yet
[13:04] <xnox> my ram has shipped already (ordered what 40min. ago?!) the rest will probably arrive over the next two weeks *sigh*
[13:06] <cjwatson> I must say it's rather nice to have a machine that can afford to have 93% of its RAM spent on buffers and cache
[13:07] <xnox> true.
[14:24] <xnox> I'm failing to see "toggle_top_level", "toggle_progress_section", "toggle_navigation_control" used at all. Dead code?!
[14:24] <xnox> or is it API for custom plugins?
[14:29] <xnox> i'm going to assume it's an external api to external plugins for now.
[14:29] <xnox> ev: you seem to have merged one of these toggle_* functions. What are they for? =)
[14:30] <ev> xnox: we've (I've) done a really poor job of documenting and correctly exposing the API
[14:31] <ev> actually being consistent in defining private members
[14:31] <ev> not reaching into classes private members, etc
[14:31] <ev> xnox: it might be used by dell-recovery, according to google
[14:32] <xnox> hmm.... ok. well committer @Dell.com was a give away as well ;-)
[14:34] <ev> xnox: best ask superm1 :)
[14:34] <xnox> ok.
[14:35] <xnox> superm1: ping =))) message me when you are around and free to chat about ubiquity ;-)
[14:38] <cjwatson> xnox: You could look at lp:dell-recovery directly
[14:40] <xnox> awesome.
[14:40] <xnox> superm1: unping.
[14:43] <xnox> looks a lot like ubiquity-tweak tool I was thinking off to do. Which can e.g. change default filesystem to xfs/btrfs and the likes.
[14:43] <xnox> aka gui presseed builder.
[14:45] <ogra_> just abuse the kickstarted UI ?
[14:45] <ogra_> *kickstarter
[14:46] <xnox> yeah.
[15:57] <stgraber> xnox: remember the number of that console-setup ubiquity bug you wanted me to look at?
[15:57]  * stgraber starts digging
[15:58] <xnox> stgraber: http://pad.lv/c/ubiquity and look at a few merge proposals there is like 4 for it.
[15:59] <stgraber> ah, bug 944614
[15:59] <ubot2`> Launchpad bug 944614 in ubiquity (Ubuntu) "ubiquity crashed with AttributeError in keyboard_variant_timeout(): 'NoneType' object has no attribute 'apply_keyboard'" [High,Triaged] https://launchpad.net/bugs/944614
[16:00] <stgraber> right, the fix is wrong, I'll poke at it a bit and get a correct one
[16:00] <xnox> yes, please =)
[16:00] <xnox> i have logs of last time we were discussing it....
[16:01] <xnox> do you need them? or you remember the context?
[16:02] <stgraber> I'm sure I just came to the same conclusion I did back then by looking at the proposed fix
[16:02] <stgraber> the proper way to fix it is to cancel the gobject timeout when moving away from the page
[16:02] <stgraber> so that the timeout doesn't hit when the page no longer exists
[16:02] <stgraber> (that or have the timeout function check whether the page is currently displayed, both should work fine)
[16:03] <stgraber> the proposed fix will obviously work, but will also possibly catch other unrelated issues which we'd want to see should they happen
[20:12] <stgraber> xnox: http://paste.ubuntu.com/5577302/
[20:13] <stgraber> I think that's the correct way to fix this
[20:14] <stgraber> xnox: tested here and pushed to trunk
[20:15] <superm1> xnox: if you want to refactor any of those toggle_* to something different, feel free, just lemme know so i can adjust dell-recovery for those changes too
[20:17] <stgraber> xnox: I guess I may as well push it to precise too, will copy the commit to that branch too.
[21:24] <xnox> superm1: well, we want to show progress section at all times now.
[21:25] <xnox> let me find a screenshot.
[21:26] <xnox> superm1: https://picasaweb.google.com/lh/sredir?uname=105922848292507689403&target=PHOTO&id=5850457453851904290&noredirect=1
[21:26] <xnox> so it's orange dots for all steps -> slideshow with progress bar -> finish.
[21:26] <xnox> superm1: I'm just going to keep toggle_* functions to work, but you may consider switching / keeping to show it. Or whatever =)
[21:40] <stgraber> xnox: ah, I didn't notice he also sent it to precise-proposed, thanks for getting rid of that one too :)
[21:41] <xnox> stgraber: yah, there was a gazzilion of them =)
[21:41] <xnox> stgraber: all nice and clean now. Also ping the u1 to clean up their merged proposals. (most of it is in main-u1 now)
[23:26] <infinity> xnox: kernels and d-i have been migrating together for months.
[23:27] <infinity> Trying easy from autohinter: linux/3.8.0-9.18 linux-meta/3.8.0.9.23 linux-signed/3.8.0-9.18
[23:27] <infinity> leading: linux,linux-meta,linux-signed
[23:27] <infinity> start: 193+0: i-96:a-39:a-25:p-33
[23:27] <infinity> orig: 193+0: i-96:a-39:a-25:p-33
[23:27] <infinity> easy: 196+0: i-97:a-40:a-26:p-33
[23:27] <infinity>     * i386: debian-installer-images
[23:27] <infinity>     * amd64: debian-installer-images
[23:27] <infinity>     * armhf: debian-installer-images
[23:27] <infinity> FAILED
[23:27] <infinity> xnox: ^--- For example.
[23:51] <cjwatson> infinity: Also seed sync bugs, which we should figure out something more automatic for at some point
[23:51] <cjwatson> But yeah, the override thing is the worst of it.  Maybe next week
[23:52] <infinity> cjwatson: Yeah.  I can overcome both misfeatures if I'm around when the migration happens (as I will be when it does in the next hour or so), but it would be lovely if I didn't have to.
[23:52] <infinity> cjwatson: Seed sync bugs probably just need the seeds rethought a bit WRT how that works.
[23:53] <infinity> cjwatson: Given that britney and nbs-report both have a concept of "debian-installer-images dependencies", baking that into germinate somehow might possibly be doable in a not-too-hideous fashion.
[23:54] <infinity> cjwatson: Which would then let us take ABI out of the seeds entirely.
[23:55] <infinity> cjwatson: I suppose the easiest way to stop all those hacks would be to actually generate a real package that depends on all of those deps.  Some "debian-installer-udebs-meta" or something that just records the udebs used in the build.
[23:56] <infinity> cjwatson: If that were in the archive, we could seed it, it would Just Work for NBS and migration, and we wouldn't need other hacks.
[23:57] <infinity> cjwatson: Would that be a hideous solution to you?  Other than a single crufty metapackage no one will ever install, it actually seems vaguely elegant, compared to the current state of affairs.
[23:59] <cjwatson> Maybe.  I'd like to think about it a bit to see if I can find something slicker ...
[23:59] <infinity> Sure.  Though that's really easy to implement.  Don't know why I didn't think of it the last time I hacked a solution for this.
[23:59] <cjwatson> To make your solution work, the metapackage would actually have to be a udeb
[23:59] <infinity> Since the build produces the manifests, etc, the last thing you do it just make a debian-installed-udebs-all.udeb that depends on all of them, done.