[11:16] evand (or someone else), can you please apply the following patch to umenu? http://paste.ubuntu-nl.org/55953/ [11:17] to test it: make prerequisites && make && make debug [11:17] cannot ssh from here [11:18] https://code.launchpad.net/~ubuntu-installer/umenu/devel [11:25] bug #191803 [11:26] Launchpad bug 191803 in umenu "Dynamic branding in revision 4 is broken (patch attached)" [Medium,Fix committed] https://launchpad.net/bugs/191803 [11:27] What is the status of the ISO by the way? === ebel_ is now known as ebel === ebel is now known as zombiebel === ebel_ is now known as ebel === cjwatson_ is now known as cjwatson === cjwatson_ is now known as cjwatson [13:58] xivulon: The build system is not producing new ISOs: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/hardy/ubuntu/20080214/livecd-20080214-amd64.out [14:10] xivulon: patch applied, committed, and pushed [14:11] it complains about an invalid CD, but I imagine that's accurate as this machine doesn't have a CD drive :) [14:13] evand, use "make debug" [14:13] that is ~ make test, but it passes a fake cdinfo for testing purposes [14:13] ahh [14:14] should I be seeing a kubuntu dialog in debug mode? [14:14] yes see Makefile [14:14] will do [14:14] you can override the cdinfo using DEBUG_CDINFO [14:15] in makefile that is set to kubuntu (since default is ubuntu and otherwise I would not see changes on errors anyway) [14:15] make degub DEBUG_CDINFO='Xubuntu 8.04 "Hardy Heron" - Alpha i386 (20080131.2)' [14:15] make debug^ [14:17] ah neat! [14:18] I haven't tested on a real CD though [14:18] also the icons are all wrong, since couldn't find anything and used ubuntu icon throughout [14:18] I asked the artwork team to provide them [14:19] http://canonical.com/logos [14:20] no .ico [14:20] indeed, Ken probably has something [14:20] Had zero time yesterday to try to figure out how to do that [14:21] Icons should go into wubi too [14:23] I may send a wubi patch to: 1 help you compile wubi yourself, 2 recode an horrible workaround in metadl [14:34] ok === cjwatson_ is now known as cjwatson [14:46] xgettext inserts the absolute path of the file before msgid. Is it possible to make it a relative path? [17:56] casper: cjwatson * r467 casper/ (4 files in 4 dirs): merge aufs-integration branch [18:00] casper: cjwatson * r468 casper/debian/changelog: releasing version 1.118 [18:25] ubiquity: evand * r2461 ubiquity/ubiquity/misc.py: Whoops. Apparently cowboyed a faulty error handler in previously. === cr3_ is now known as cr3 === cr3_ is now known as cr3 [21:15] I just received an error message from pkgsel when installing daily-current: hwtest-certify-cli: Depends: hwtest-certify but it is not going to be installed; E: Broken packages [21:15] then, I get: (process:23769): ls: /usr/lib/pre-pkgsel.d/*: No such file or directory [21:16] I don't seem to have much more information and I have specified DEBCONF_DEBUG=5 [21:16] how can I find out what might be the problem? [21:16] pre-pkgsel is just noise, ignore it [21:17] hwtest-certify-cli isn't in the archive so I'm not quite sure how I could go about helping [21:17] the real error may be further up in the log; if the desktop is uninstallable, pkgsel might well fall over later [21:17] cjwatson: I'm wondering how I can go about attempting to understand what might be wrong. actually, I can probably try in-target apt-get install hwtest-certify [21:18] use 'chroot /target' for interactive debugging [21:18] if you're at a shell you don't have debconf hooked up and in-target isn't of much help [21:18] I would read backwards through syslog until I found something else interestingly error-shaped [21:19] cjwatson: the only errors, ie lines with "E:", in syslog concern index files which failed to download and: Couldn't find package acpi-support-base [21:20] perhaps you could post syslog somewhere? [21:22] cjwatson: when I tried to apt-get the failing package, there was a clear error stating that there are missing dependencies which are not found in the repositories. this is great and I know how to fix that. [21:22] cjwatson: however, would it make sense for the syslog to have provided this information? [21:23] cjwatson: if you think this makes sense, I could report a bug, but I'm not sure if it's the responsibility of the installer to be that verbose in syslog [21:26] this is a bad time for me, but if you report a bug with syslog attached I can look later [21:26] it should be verbose and I'm surprised it isn't [21:26] cjwatson: sure thing, thanks [21:28] ubiquity: evand * r2462 ubiquity/ (4 files in 3 dirs): [21:28] ubiquity: * Check the md5 hash of the source and target files on copy to ensure they [21:28] ubiquity: match, giving the user the option to abort, retry, or skip the file. [21:29] evand: neat; did you get a chance to try out performance impact of that? [21:29] I toyed around with the idea of threading that, but I think it would overly complicate the install routine and probably not gain us much given that we lose the cache of the file in the process (that is, it cannot happen as part of the regular copy routine) [21:29] I'm no fan of threading anyway :) [21:33] I can't find my previous tests of with and without md5 atm, but my tests of md5 vs CRC32 (which was designed for this sort of thing) and SHA-1 show a negligible difference in speed. [21:33] which I find somewhat perplexing. [21:33] oo, I still need to allow the user to preseed this away [21:34] probably dominated by I/O [21:35] try md5ing 700MB of data twice on an unloaded system with lots of memory and you should get an upper bound for the amount of CPU time involved from the second run [21:35] ok [21:36] but this is just a thought experiment - I have a fairly strong suspicion that modern CPUs can do any of those hashes more quickly than they can read stuff off disk [21:37] ah, indeed [22:01] ubiquity: evand * r2463 ubiquity/ (4 files in 3 dirs): [22:01] ubiquity: * The md5 check can be disabled by preseeding [22:01] ubiquity: ubiquity/install/md5_check to false.