[09:49] <CIA-9> pkgsel: cjwatson * r143 ubuntu/debian/ (changelog postinst):
[09:49] <CIA-9> pkgsel: Add support for setting pkgsel/language-packs to "ALL", to install
[09:49] <CIA-9> pkgsel: everything available on the installation media (LP: #371470).
[09:50] <CIA-9> ubiquity: cjwatson * r3263 ubiquity/ (debian/changelog scripts/install.py):
[09:50] <CIA-9> ubiquity: Add support for setting pkgsel/language-packs to "ALL", to install
[09:50] <CIA-9> ubiquity: everything available on the installation media.
[09:50] <CIA-9> ubiquity: cjwatson * r3264 ubiquity/debian/ (changelog ubiquity.install-any): Install block-attr from debian-installer-utils 1.68.
[09:51] <CIA-9> ubiquity: cjwatson * r3265 ubiquity/debian/changelog: bug closure for pkgsel/language-packs change
[09:52] <baba_> hi, thanks cj for email reply
[09:53] <baba_> im working on it...
[12:02] <twb> A RHEL weenie was telling me recently how it's a great thing that the RHEL installer will ask you ALL the questions up front, and then do all the work
[12:02] <twb> This means you can answer questions then go to lunch, instead of having five minutes of waiting here and there
[12:02] <twb> Are there any plans to do something along those lines in d-i?
[12:05] <soren> Is it possible (using preseeding) to avoid installing recommends by default in the installed system?
[12:06] <cjwatson> twb: Not as such. We try to ask questions as early as possible when we can, but asking *everything* up-front would be a total rearchitecture.
[12:06] <twb> cjwatson: that's what I figured.
[12:06] <cjwatson> soren: Only by writing out apt configuration from one of the general scripting hooks.
[12:06] <twb> Ooh, good idea.
[12:07] <twb> I was gonna just say "run aptitude -R in the post-command"
[12:07] <soren> cjwatson: That's what I figured. Would you be opposed to adding a hook to do it from apt-setup (or whereever you feel it belongs)?
[12:07] <cjwatson> soren: apt-setup would be OK, I think
[12:07] <soren> twb: I mean by default.
[12:07] <cjwatson> though I'd prefer to run that through Debian
[12:08] <twb> Right now u-server has a 20 minute gap at one point, installing the base packages.  Then there's a few more questions before it installs stuff from the net.  That's a kinda sucky delay.
[12:08] <soren> cjwatson: Does Debian install recommends by default these days?
[12:08] <cjwatson> soren: yes
[12:08] <soren> Oh. I didn't realise.
[12:08] <cjwatson> twb: that's mainly apt-setup. It would be possible to pull that back, I think - it just needs some work
[12:08] <twb> Perhaps because the "base" is much bigger for ubuntu-standard than in Debian?
[12:08] <cjwatson> well, no, we know that that particular case is awkward in Debian too
[12:09] <twb> Fair enough.
[12:09] <cjwatson> the technical reason it's like that right now is that some of the bits of apt-setup's interaction require apt to be available
[12:09] <cjwatson> which means that at the moment the base system has to be installed
[12:09] <cjwatson> we'd need to split it into two pieces
[12:10] <cjwatson> I think there's an Ubuntu bug for that - it's certainly a back-burner thing I've wanted to fix for a while
[12:10] <soren> cjwatson: The use case is JeOS (aka "Minimal install"). It's a bit of a stretch to call it "Just enough Operating System" or "Minimal install", when it's really quite a bit more than that.
[12:10] <cjwatson> soren: sure, I think it's entirely reasonable to want to turn it off there
[12:10] <twb> BTW, who decides (and how) what packages are hard (Depends) and soft (Recommends) dependencies in ubuntu-minimal and -standard metapackages?
[12:10] <cjwatson> twb: core developers
[12:10] <soren> cjwatson: Great, that was going to be my next question. :)
[12:11] <twb> soren: minimal install is what debootstrap gives you.  Unless you want a kernel and bootloader, too? ;-)
[12:11] <cjwatson> twb: the general philosophy is described in http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.karmic/revision/912
[12:11] <twb> Thanks.
[12:12] <soren> twb: I'm thinking "Minimal install" as offered by the installer's "F4 menu".
[12:12] <cjwatson> we try to avoid Recommends in minimal, since debootstrap doesn't really implement Recommends handling in the same way as everything else
[12:12] <twb> cjwatson: that seems to be about the -desktop metapackage?
[12:12] <cjwatson> in fact we have no recommends in minimal right now
[12:12] <cjwatson> twb: the general idea is the same
[12:12] <twb> OK.
[12:13] <twb> I remember now!
[12:13] <twb> I was annoyed because ubuntu-standard pulled in udev, which was annoying in my OpenVZ virtual environment.
[12:13] <cjwatson> I don't think there'll be much support for moving udev to Recommends. Too much of the world relies on it now.
[12:13] <twb> No, it was klogd that was the most annoying one, because it just hung inside the VE
[12:14] <cjwatson> I wonder if rsyslog will be happier
[12:14] <twb> I basically wanted to be able to say "just give me a standard-y install base... but not the stuff for running on real hardware!"
[12:14] <twb> It doesn't really matter, because I knew how to mangle around such things with e.g. policy-rc.d
[12:15] <cjwatson> really, our approach should be for the packages needed on real hardware to not break in virtual environments
[12:15] <cjwatson> it works out a lot simpler in the long run
[12:15] <twb> cjwatson: oh definitely :-)
[12:16] <twb> "Bzzt! I am in a VE, so I will noop."
[12:19] <cjwatson> always complicated by virtual environments usually deliberately making it hard to tell whether you're in one or not, of course
[12:22] <twb> Hehe
[12:22] <twb> Could at least check for /proc/user_beancounters, for OpenVZ
[12:23] <twb> Or the uname for Xen?
[12:23] <twb> No /proc fucks up the Sun Java installer royally, because it relies on /proc/self/exe :-///
[12:23] <cjwatson> well, that's the problem, you have to go round whackamoling every single case
[12:23] <twb> Yeah, true
[12:23] <cjwatson> better, if possible, to try to fail gracefully if hardware appears to not be there
[12:24] <twb> Having said that, most stuff does full (para-)virtualization except xen and openvz.
[12:24] <twb> Possibly even xen
[12:25] <twb> But with OpenVZ you can *see* e.g. /dev/sda or /proc/kmem, and root appears to own it, but you can't open it.
[12:25] <twb> I'll be happier when we can roll out KVM here...
[13:09] <twb> Another thing I just noticed
[13:09] <twb> When I hit F6 and change/add vga=790 instead of splash, in an ubuntu-server install...
[13:09] <twb> I add it AFTER the -- arg.  Isn't that supposed to make it end up in grub's menu.lst?
[13:10] <twb> (This is with 8.04.2.)
[13:13] <cjwatson> vga= is explicitly filtered out because it used to be added by gfxboot by default in some cases, and most people using it just in order to make the installer look better don't realise that it breaks suspend/resume
[13:14] <twb> Ah, I didn't know that, either, since I tend not to suspend my servers :-)
[13:14] <twb> Is video=vesafb also filtered out?
[13:23] <twb> cjwatson: is video=vesafb also filtered out?
[13:27] <cjwatson> no (which may or may not be a mistake, but the relevant bit here historically is that gfxboot never added that option)
[13:28] <cjwatson> twb: suspending servers is getting increasingly popular as people realise that their datacentres have small cities' worth of electricity requirements, so I think if anything it deserves increasing consideration
[13:31] <twb> Eheh, my servers provide services to inmates.
[13:31] <twb> Suspended server --> riots, or so I'm told.
[13:32] <twb> Could probably go off overnight, though...
[13:33] <cjwatson> wake-on-LAN may be your friend
[13:33] <twb> Boy, that would make my boss's head spin
[13:33] <soren> twb: It's usually used if you have many identical machines to handle peak load, but only need a few during off hours.
[13:33] <twb> PXE boot roms in the clients waking up the server, which DHCPACKs them
[13:33] <twb> soren: nod.
[14:04] <Daviey> or use nvram-wakeup
[14:05] <Daviey> (if compatiable)
[14:33] <shtylman> cjwatson: when will the grub2 move be made? early on like alpha2? or later in the cycle? (and what will happend to those that have installed karmic with grub1 (from alpha1) and just do a basic apt-get dist-upgrade? will that go smoothly or do they have to reinstall
[14:33] <cjwatson> fairly early on, I hope - I was just looking at the merge
[14:34] <cjwatson> people who are already running grub1 will get the usual grub2 upgrade path - you get an extra menu item letting you chain-load grub2, and explaining how to upgrade permanently if you want
[14:37] <shtylman> gotcha...was just curious :)
[14:38]  * cjwatson -> slightly buried in merges
[15:06] <CIA-9> user-setup: cjwatson * r179 ubuntu/ (74 files in 3 dirs): merge from Debian 1.26
[15:14] <CIA-9> user-setup: cjwatson * r180 ubuntu/debian/ (68 files in 2 dirs):
[15:14] <CIA-9> user-setup: Rearrange our templates file to put all Ubuntu-specific entries at the
[15:14] <CIA-9> user-setup: end, to simplify future merges.
[15:18] <CIA-9> user-setup: cjwatson * r181 ubuntu/ (debian/changelog functions.sh):
[15:18] <CIA-9> user-setup: Drop compatibility for passwd/allow-password-empty, as promised in the
[15:18] <CIA-9> user-setup: changelog for 1.23ubuntu14.
[15:35] <CIA-9> usb-creator: rgreening * r101 usb-creator/ (12 files in 7 dirs):
[15:35] <CIA-9> usb-creator: Initial work to begin KDE interface for usb-creator. Not usable at this point.
[15:35] <CIA-9> usb-creator: Major re-write of kde_frontend.py (pure copy of gtk_frontend.py) will be required.
[15:43] <CIA-9> usb-creator: rgreening * r102 usb-creator/debian/rules: Fix rules file. supposed to add -kde not -gtk
[17:39] <CIA-9> user-setup: cjwatson * r182 ubuntu/debian/changelog: releasing version 1.26ubuntu1