=== robbiew is now known as robbiew-afk [10:14] cjwatson: is keyboard-configuration coming to lucid sometime soon? [10:14] replacing console-setup [10:25] uhm, so it's c-s that build k-c. needs a merge I guess [10:25] buildS [10:28] it's a prereq for the udevified xserver, though easily changed back if needed [11:38] tjaalton: at some point yes, but the merge is complicated so I can't give you a time [11:41] cjwatson: hmm ok, before alpha1 though? [11:42] I'm not sure, don't bank on it, I'd rather have a working installer ... [11:42] I'll let you know if I do manage to get it merged; definitely for lucid [11:43] heh, ok [11:43] I'll work around it then [12:18] base-installer: cjwatson * r386 ubuntu/ (85 files in 7 dirs): merge from Debian 1.103 [12:20] base-installer: cjwatson * r387 ubuntu/ (12 files in 5 dirs): [12:20] base-installer: Remove all traces of lpia, which is being decommissioned (see [12:20] base-installer: https://blueprints.launchpad.net/ubuntu/+spec/mobile-lucid-lpia-future). [12:22] cjwatson: ubiquity still seems to be locking up at 95% the hd is flashing once per second and it's been like this for 5 minutes I'm assuming it should of moved on by now. [12:29] debian-installer: cjwatson * r1211 ubuntu/ (46 files in 4 dirs): Belatedly update Canonical copyright dates for 2009 (LP: #448647). [12:36] base-installer: cjwatson * r388 ubuntu/debian/changelog: releasing version 1.103ubuntu1 [12:36] davmor2: did the live filesystem actually get rebuilt today? [12:37] hmm, apparently so [12:37] please don't ever say "95%". what is the progress info message? [12:37] percentages are more or less no use I'm afraid [12:39] cjwatson: only said that while I was running ubuntu-bug to get it on your radar. bug 491847 [12:39] Launchpad bug 491847 in ubiquity "Ubiquity locks up at 95%" [Undecided,New] https://launchpad.net/bugs/491847 [12:39] ok [12:40] even in bug titles, the info message is more use than the percentage [12:40] e.g. 'locks up at "Configuring hardware..."' or whatever [12:40] the exact numbers aren't stable [12:41] cjwatson: moded accordingly [12:41] looks like it's downloading [12:41] could be wrong, hard to tell with accuracy [12:42] hmm, though I'd have expected a clearer message from apt in that case [12:42] guess I'll find out when my rsync completes [12:43] god, there are so many totally random reports on debian-installer [12:44] cjwatson: is there one on the configure grub-pc? [12:44] just fixed that [12:44] bug 491801 [12:44] Launchpad bug 491801 in base-installer "config dialog apears duing alt instal when it shouldn't" [High,Fix released] https://launchpad.net/bugs/491801 [12:46] cjwatson: is there a way round it currently is it just a case of hitting enter? [12:46] yes [12:47] cool [12:47] may break later though - the basic problem is that it's installing grub too early [12:47] ah [12:47] meh who wants to test iso's anyway [12:49] cjwatson: ubiquity install still stuck on installing lang packs [12:52] davmor2: ok, kill it if you want and I'll see if I can reproduce it === rgreening_ is now known as rgreening === robbiew-afk is now known as robbiew [15:47] davmor2: I think it's almost certainly just downloading *lots*, and a lack of progress information. progress info's better in ubiquity bzr [15:48] I should get that uploaded and we can see the difference tomorrow [15:49] cjwatson: just so you know it's still going still at installing lang packs it don't take this long to download a dvd [15:49] hmm [15:49] did you use --debug? [15:49] if you did, 'tail /var/log/installer/debug' will show what it's doing, after a fashion [15:50] meh no I can run again and try that if it will help [16:10] davmor2: FWIW my test install completed successfully [16:12] meh [16:12] burns another copy just incase [16:15] wouldn't expect that to be the problem [16:15] it probably just got stuck downloading for some random network reason, and the lack of progress made it hard to see [16:16] could be but it won't hurt either though [16:34] ubiquity: cjwatson * r3610 ubiquity/ (debian/changelog ubiquity/components/partman.py): Fix inconsistent return types in partman.Page.snoop. [16:36] ubiquity: cjwatson * r3611 ubiquity/ubiquity/segmented_bar.py: fix argument mismatch resulting from pychecker cleanup in r3592.1.10 [16:38] yikes, sorry about that [16:42] easy to miss [16:42] thought I'd do a pychecker run before upload :) [16:43] would pychecker be a good idea to run in the clean rule maybe to ensure it's ran every time before upload? [16:44] superm1: that is the eventual intent, but it doesn't run cleanly yet and the remaining problems are hard [16:44] ah [16:44] I want to get to the point where we can simply rely on its exit code [16:44] unfortunately pychecker isn't brilliant code itself in a few places ... [16:45] in the meantime at least having some way to run it conveniently has shaken out a lot of problems [16:46] I don't know how to deal with the fact that it only really works well in some ways if you have all the enormously heavy build-deps installed [16:46] well build-deps don't have any other negative implications other than a few extra minutes in build time though do they? [16:47] I don't want them on my laptop. :) [16:47] ah :) [16:47] ubiquity: cjwatson * r3612 ubiquity/ (d-i/manifest debian/changelog): [16:47] ubiquity: Automatic update of included source packages: base-installer [16:47] ubiquity: 1.103ubuntu1. [16:52] ev: hmm. did you test these super() changes? I remember those being delicate in the past [16:53] I'm a bit scared of changing those just because pychecker says so :) [16:53] oh, heh, apparently I changed *away* from that back in feisty. Fair enough [16:54] I didn't test them (was on a plane and figured KVM + battery = pain), but I do recall doing a reasonable amount of digging through bzr blame. [16:54] I just misremembered the direction of the change [16:55] there seems to be no way to get round some pychecker errors - the change to debug_enabled just caused a different error :( [16:56] and Guido's apparently said that pychecker should get over itself in requiring 'for _ in' rather than 'for in' :-) [16:57] heh [16:58] ev: I think it might be better to use unused_ prefixes on arguments rather than weakening interfaces to just *args. What do you think? [16:58] or maybe we should just bin the "unused function argument" warnings - sometimes they seem to be more trouble than they're worth [16:58] unused_ prefixes are interface changes too due to the way Python handles keyword arguments, IIRC [16:59] yeah, I'd agree with binning it then. [17:00] I'd love to have something like __attribute__((__unused__)) in C [17:00] maybe a function decorator or something ... [17:02] ubiquity: cjwatson * r3613 ubiquity/debian/changelog: releasing version 2.1.3 [18:38] hi all, do you think is possible to create ubuntu-micro as a smaller package set than ubuntu minimal? [18:42] it wouldn't be Ubuntu - we're not prepared to support anything smaller than ubuntu-minimal. You can create your own metapackage and just not install ubuntu-minimal, if you like [18:45] cjwatson, i was thinking in something like this for liquid. [18:47] cjwatson, but it is better to use the current minimal system and for lucid +1 work to get it smaller [18:47] cjwatson, would it be possible to get ubuntu-minimal smaller for lucid+1? [18:49] we'll listen to particular recommendations ... [18:50] I've been thinking of moving console-setup out to standard for lucid, which would be a pretty massive whack on its own [18:50] I meant to do that for karmic, actually [18:50] cjwatson, cool! [18:51] well, not as massive as people think, but it would stop people complaining about X being in minimal without checking just how tiny a piece of X it is :) [18:52] ehehehe [18:52] cjwatson, i will make a proof of concept [18:52] cjwatson, i'm thinking in a very minimal system for an embedded device [18:53] bear in mind that many of the things in minimal are actually deliberate. We're prepared to accept that embedded devices will have to do their own thing. [18:53] you could e.g. take Priority: required as a starting point instead; you don't necessarily have to have a metapackage ... [18:54] cool! [18:54] debootstrap has a --variant=minbase option [18:54] in the debconf template files I see lots of comments like "# :sl1:", what does it mean? [18:55] corp186: http://d-i.alioth.debian.org/doc/i18n/ch01s04.html#sublevels [18:55] cjwatson: thanks [18:55] cjwatson, but can ubuntu-minimal depend on an e.g. ubuntu-micro? [18:56] for arcane reasons ubuntu-* metapackages don't depend on each other. [18:57] I don't want to create another metapackage at that kind of position in the official Ubuntu archive. As I say it's fine (and not hard) for derivatives to do that kind of thing [18:58] I think embedded derivatives will likely want to customise around that area anyway, and they could use the required seed as a base [18:58] * cjwatson -> dinner [18:58] cjwatson, cool! I've never imagined that [18:59] cjwatson, thanks for the clarification and bon appetit :-) [20:33] I'm trying to set up a development environment for d-i hacking [20:33] I've got a local repo mirror set up [20:33] I've also got a new package I want to test [20:34] how do I put the package into the repo and have the Packages.gz file updated? [22:20] in a preseed file, if I specify additional repositories as local0/repository, will the latest packages from those repositories be installed automatically? === robbiew is now known as robbiew-afk