[12:13] <cjwatson> mebrown: no, only in bzr
[12:13] <cjwatson> they'll be in 1.6.1
[12:14] <mebrown> which day can I expect them to be in daily gutsy? (I'm working on other details right now and have hacked in all the patches from evan and everthing is working fine)
[12:15] <mebrown> So it is not a huge rush to get them in.
[12:15] <cjwatson> by Thursday
[12:15] <mebrown> ok. Thanks. All my stuff is working great with the latest patch set.
[12:15] <cjwatson> good to know
[12:16] <cjwatson> Evan and I were talking about splitting up the "automation failed" and "installation failed" cases
[12:16] <cjwatson> since they're logically distinct
[12:16] <mebrown> I'll mark fix confirmed as soon as I see them in a daily build.
[12:16] <cjwatson> so you might need to adjust your preseeding a little if that happens; Evan can let you know at any rate
[12:16] <mebrown> for my case, I dont think it really matters. Just let me know.
[12:16] <cjwatson> right, it doesn't matter in your case (the two hooks would want to be the same)
[12:16] <cjwatson> but we need to think generally too :-)
[12:16] <mebrown> right.
[12:17] <mebrown> completely understand and can deal with any changes given a warning.
[12:17] <mebrown> So, just keep me in mind and let me know if it changes.
[12:17] <mebrown> Personally, I would probably separate them.
[12:28] <superm1> evand, have you tested your code from evand@ubuntu.com-20070928190548-mdrjta41znoro86g and evand@ubuntu.com-20070928192642-q1l4bx157irqvvzt ?
[12:29] <superm1> i just encountered an error with GrubInstaller failing with code 1 with a locally built package doing a normal install
[12:29] <superm1> where it was trying to issue the command 'grub-install false'
[12:30] <cjwatson> +                self.preseed('grub-installer/bootdev', 'false')
[12:30] <cjwatson> hmm, quite, that's wrong, that's not a boolean
[12:31] <cjwatson> evand: (all yours though, I'm going to bed ...)
[12:31] <superm1> night cjwatson
[12:32] <superm1> i'm imagining that should just be self.preseed('grub-installer/bootdev', bootdev) at that point
[12:52] <CIA-18> ubiquity: superm1 * r2300 ubiquity/ubiquity/components/install.py: when not in automatic, preseed the bootdev obtained from debconf, not 'false'
[12:53] <superm1> (i just verified that worked correctly in my vm)
[01:01] <evand> oh wow, whoops
[01:01] <evand> thanks for noticing that and the subsequent fix, superm1
[01:01] <superm1> no prob
[11:32] <CIA-18> ubiquity: cjwatson * r2301 ubiquity/ (debian/changelog gui/glade/ubiquity.glade):
[11:32] <CIA-18> ubiquity: * Make the OK button the default widget in the create and edit partition
[11:32] <CIA-18> ubiquity:  dialogs.
[11:33] <CIA-18> ubiquity: cjwatson * r2302 ubiquity/debian/changelog: reorg
[03:42] <CIA-18> ubiquity: superm1 * r2166 mythbuntu-ubiquity/ (192 files in 19 dirs): merge with trunk
[03:43] <CIA-18> ubiquity: superm1 * r2167 mythbuntu-ubiquity/scripts/install.py:
[03:43] <CIA-18> ubiquity: locally disable (unnecessary) calls to cache.open(None) after discussion
[03:43] <CIA-18> ubiquity: in #ubuntu-devel with mvo
[03:44] <cjwatson> superm1: could you please test that by deliberately breaking a package or something?
[03:44] <superm1> cjwatson, i was just going to see if i could.
[03:44] <superm1> (that's not on trunk if you didn't realize)
[03:44] <superm1> any recommendations on how to deliberately break something?
[03:47] <cjwatson> might be easier to do on removal
[03:47] <cjwatson> stick 'exit 1' near the top of /var/lib/dpkg/info/ubiquity.prerm?
[03:47] <superm1> k
[03:47] <cjwatson> I forget how I did it last time
[03:47] <cjwatson> but if you get it right you should get a dialog box with the names of broken packages
[03:59] <superm1> cjwatson, yeah it does work correctly http://imagebin.org/10797
[03:59] <superm1> the installer throws that and then continues on
[03:59] <cjwatson> superm1: no, it's not ...
[04:00] <cjwatson> superm1: it's not listing the broken packages
[04:00] <cjwatson> it should say:
[04:00] <superm1> there is a second dialog
[04:00] <superm1> let me imagebin it
[04:00] <cjwatson> The following packages are in a broken state:
[04:00] <cjwatson> ubiquity
[04:00] <cjwatson> instead, it has a blank line
[04:01] <superm1> http://imagebin.org/10798
[04:01] <cjwatson> sure, but the first dialog is bust
[04:02] <cjwatson> and that dialog is generated directly after the code you removed ...
[04:02] <superm1> so with this way of doing it, would just modifying that other dialog make sense?
[04:02] <cjwatson> no
[04:02] <cjwatson> the change you made is demonstrably incorrect
[04:02] <cjwatson> because self.broken_packages(cache) isn't working
[04:03] <cjwatson> might be worth taking that to mvo
[04:03] <cjwatson> broken_packages iterates over the cache and does cache._depcache.IsInstBroken() on each
[04:05] <cjwatson> the second dialog is a lot less neat if multiple packages break; I'd rather have the summary
[04:06] <superm1> well the order of those two are reversed, i uploaded them backwards
[04:06] <superm1> and i thought that first one was generated because an InstallError would have been thrown
[04:07] <cjwatson> no, look at the code right after the line you removed
[04:07] <cjwatson> the bit that asks the broken_install or broken_remove debconf question
[04:08] <superm1> oh  i see
[10:24] <jimcooncat> I'm setting up an automated netboot install server, and I'd like to run badblocks before partitioning. Looks like this is only on the wishlist for d-i.
[10:24] <jimcooncat> Perhaps I could netboot a livecd to run badblocks?
[10:24] <jimcooncat> How do you netboot a live cd?
[10:30] <jimcooncat> sorry, gotta go
[11:17] <evand> isn't that what SMART is for?
[11:51] <cr3> anyone happen to know if there's python code to to parse those dpkg .templates files?
[12:06] <cjwatson> cr3: they're not dpkg, they're debconf
[12:06] <cjwatson> please don't invent code outside debconf to parse them
[12:07] <cjwatson> you can use debconf-copydb to extract them in a form you can parse
[12:07] <cjwatson> ubiquity/i18n.py in ubiquity does this
[12:08] <cjwatson> (and is better than parsing *.templates or even /var/cache/debconf/templates.dat directly because we might quite reasonably switch to a new database format - using debconf-copydb insulates you from that)