[00:01] <timothywcrane>  are there by any change some ubuntu core-dev in here? I have 2 fixes for the repos concerning Sauerbraten. (It cannot get futher updates without these fixes)
[00:02] <timothywcrane> I will be first to admit, my tactic of the day is begging
[00:02] <timothywcrane> it is in bug report. But I wanted to give asking a shot
[00:03] <timothywcrane> but only core-dev can upload
[00:03] <Adri2000> timothywcrane: are you sure this package is in main.
[00:03] <Adri2000> ?
[00:03] <timothywcrane> fixes on launchpad board
[00:03] <timothywcrane> no it is not
[00:03] <Adri2000> then you need a motu, not a core-dev
[00:03] <Adri2000> -> #ubuntu-motu
[00:03] <timothywcrane> motu?
[00:03] <timothywcrane> thanks
[00:04] <timothywcrane> there now, thxamill
[00:08] <lucas> how can I know why ruby1.9 was moved from universe to main?
[00:10] <Burgundavia> ask the security guys
[00:11] <lucas> what do the security guys have to do with that decision?
[00:13] <stealth`gentoo> hi all
[00:13] <stealth`gentoo> i have this BIG problem
[00:13] <stealth`gentoo> http://91.121.166.117/ -> i don`t see index.php
[00:13] <stealth`gentoo> but i donwload it.
[00:13] <stealth`gentoo> Who can help
[00:16] <tormod> stealth`gentoo: wrong channel
[00:16] <stealth`gentoo> sir tormod - i have asked on my IT language channel and on #ubuntu ...
[00:16] <stealth`gentoo> more person ask me to enter here ...
[00:16] <stealth`gentoo> so =p i want a simple help
[00:27] <RainCT> stealth`gentoo: do you have libapache2-mod-php5 installed?
[00:29] <stealth`gentoo> yes dude
[00:30] <RainCT> stealth`gentoo: I get The requested URL /index.php was not found on this server.
[00:32] <RainCT> stealth`gentoo: is the index caled .php or .phtml?
[00:33] <stealth`gentoo> RainCT wait i create it
[00:33] <wgrant> lucas: Because somebody decided that we wanted ruby1.9 rather than ruby1.8 in main, perhaps!?
[00:34] <stealth`gentoo> index.php
[00:34] <slangasek> RainCT: would you mind taking this to #ubuntu?  I really can't imagine that this is the result of an Ubuntu bug, so it's really off-topic here...
[00:35]  * wgrant gives stealth`gentoo a hint before he leaves: don't expose phpMyAdmin to the web.
[00:35] <stealth`gentoo> wgrant don`t found :D
[00:35] <stealth`gentoo> ghgh
[00:35] <RainCT> I'm about to leave anyway, good night
[00:36] <stealth`gentoo> have you fun RainCT.
[00:36] <stealth`gentoo> so - nothing help.
[00:39] <slangasek> stealth`gentoo: whoever directed you to this channel has done so in error; I'm sorry, I don't know why they've done that, but as the topic states, this is not a support channel
[00:40] <stealth`gentoo> Ok sir or madam, no problem.
[00:40] <stealth`gentoo> I only tell sorry me for inconvenienze and for disturb.
[00:40] <stealth`gentoo> Have you fun all :P
[00:40] <stealth`gentoo> kiss
[00:45] <emgent> persia: can you take a look in freqtweak merge debian/copyright ?
[00:45] <emgent> debian people remove your reference
[02:03] <lifeless> slangasek: ping
[02:04] <lifeless> slangasek: I wanted to ask your opinion; I'm thinking of starting a thread about config files - all the ones with comments and explicitly-set-to-the-default values
[02:05] <lifeless> slangasek: I think they are harmful and all such things should be in foo.default files; which the user never edits - this would massively reduce upgrade conflicts for foo.
[02:08] <slangasek> lifeless: there are two reasons I find default config files useful; first, for improved discoverability (what is the config file for foo?  what are the options I need to edit?), and to get file permissions on the config file right when they need to be something other than the system default
[02:08] <lifeless> slangasek: I'm not saying remove default config _files_ I'm saying remove 'foo=bar' and '# foo=bar' and '# this does xxx' from the file contents
[02:08] <infinity> Not to be an elitist or anything, but if people are editing config files, they should be able to deal with conflicts.
[02:09] <lifeless> slangasek: see for instance squid.conf and squid.conf.default
[02:09] <lucas> wgrant: well ruby1.8 is in main too, and 1.9 is a development version
[02:09] <infinity> Or, to put it the other way, if our "normal" users need to edit config files, we messed up.
[02:09] <lifeless> infinity: they do
[02:09] <slangasek> lifeless: ah, yes, I agree that explicitly setting defaults in config files is silly
[02:09] <lifeless> infinity: we've messed up systematically across the board
[02:09] <slangasek> (the samba package has recently been cleaned up in this regard)
[02:09] <slangasek> well
[02:09] <slangasek> ok, not quite
[02:10] <slangasek> we're not /setting/ default values any more, but we do include some comments for documentation purposes...
[02:10] <lifeless> I just did fisty->gusty->hardy
[02:11] <lifeless> and had way too many conflicts on files that I'd either never edited, or the conflict was the maintainer fixing a typo and causing several hundred lines of region to resolve
[02:11] <lifeless> Trivially,
[02:11] <lifeless> # comment
[02:11] <lifeless> setting = chosen-value
[02:12] <elmo> lifeless: conflicts on files you didn't edit is always a packaging bug somewhere
[02:12] <lifeless> will - even in three-way merge - conflict if the comment has a typo the maintainer (or upstream) fix *and* the user has changed setting
[02:12] <slangasek> maybe we need better three-way merging? :)
[02:12] <lifeless> elmo: there are/(were?) a bunch of packages that get values set into config files from debconf; so 'never edit' doesn't mean 'never specified' :/
[02:13] <slangasek> lifeless: anything that's populated by debconf is not allowed to be a conffile
[02:13] <lifeless> slangasek: presumably I ran into bugs then
[02:13] <slangasek> I guess so; bugs I haven't seen myself, fwiw
[02:13] <lifeless> anyhow; speaking as a VCS head the easiest way to avoid spurious conflicts is to have unrelated data in separate places
[02:13] <infinity> Or, someone using the ever-fun debconf + ucf combination and messing it up.
[02:14] <slangasek> infinity: ucf == lurv
[02:14] <infinity> slangasek: When properly used, yes. :)
[02:14] <infinity> slangasek: Some people don't quite seem to grasp the concept.
[02:14] <slangasek> right, such as the nfs-kernel-server maintainer :/
[02:15] <slangasek> lifeless: I as a user find having comments in the default config file /very/ helpful to me; having to context-switch between two files, or a file and a manpage, is irksome
[02:16] <slangasek> it would really be nice to have a better three-way-merge algorithm in ucf...
[02:17] <lifeless> slangasek: honestly, I think its off into AI land to fix it as it stands via 'better merge'
[02:17] <lifeless> the squid config file is a particular good example
[02:17] <slangasek> hmm :(
[02:17] <lifeless> I'm pretty sure we stopping shipping a long config upstream years ago
[02:18] <lifeless> and we now ship a small active config
[02:18] <lifeless> with a .default that documents everything
[02:19] <lifeless> 140K of config file is not a sane thing to inflict on users
[02:19] <slangasek> true
[02:19] <lifeless> just checked, we switched to squid.conf.default at least 3 years ago
[02:20] <lifeless> so the question is, does the peanut gallery here think this is a semi-sane suggestion, if so I'll take it to the list(s) for larger discussion
[02:20] <lifeless> if not, I'll just bitch and moan at every release
[02:20] <lifeless> :P
[02:20] <slangasek> using samba again as an example, the config we ship is 12K, and includes a very limited subset of all available options - the ones that a user is likely to need to tune
[02:21] <lifeless> how much of that is documentation and manually listing default values?
[02:21] <slangasek> lifeless: if you bitch and moan /before/ the release, I'll be very happy to smack anyone who's caused a conflict prompt on an unedited config file
[02:21] <slangasek> $ grep -c '^[;#]' /usr/share/samba/smb.conf
[02:21] <slangasek> 216
[02:21] <lifeless> slangasek: production servers at home -> I always upgrade afterwards
[02:21] <slangasek> $ wc -l /usr/share/samba/smb.conf
[02:21] <slangasek> 312 /usr/share/samba/smb.conf
[02:22] <lifeless> so 2/3 rds of that file are comments which are subject to being wrong and thus causing conflicts
[02:22] <lifeless> :)
[02:22] <slangasek> sure
[02:22] <slangasek> which is why I'd like a better merge algorithm :)
[02:25] <slangasek> but while we could strip all the comments out of the default config, that would leave users without the guidance that we, and upstream, are trying to provide with the examples and comments
[02:29]  * Hobbsee wishes for intelligent merging.
[02:29] <Hobbsee> i'm getting bored of modifying the blacklist every single time.
[02:29]  * LaserJock often wishes for intelligence but doesn't often find it
[02:30] <lifeless> slangasek: I disagree aout the guidance thing
[02:31] <lifeless> slangasek: a simple two-liner never-changed comment at the top of the file can refer users to comprehensive documentation and examples
[02:32] <RAOF> lifeless: But I, at least, find it much more convenient to have a nicely commented hugely redundant config file to start with.
[02:32] <lifeless> slangasek: certainly as an upstream [squid] I want Debian and Ubuntu to ship squid.conf.default and use squid.conf for only active set values
[02:32] <lifeless> RAOF: are you serious? or taking the piss?
[02:34] <RAOF> lifeless: I'm serious.  I find them useful.
[02:34] <lifeless> do you remember the gutsy cycle tracker config file?
[02:34] <RAOF> No?
[02:35] <lifeless> massively long config file full of explicit defaults and comments most of which were totally pointless and something the program would have to change in future anyhow
[02:35] <lifeless> anyhow, no huge 'yes this works' reaction, so I'll leave it alone for now
[02:35] <lifeless> all of you, go admin 10 or 20 squid servers with squid.conf.default as your starting config file.
[02:35] <RAOF> Right.  I'm aware that there are downsides to a hugely verbose over-specific default conifg file, I'm just saying that I find them useful.
[02:36] <lifeless> come back to me when you've seen the light
[02:36] <RAOF> My finding them useful shoudln't inhibit someone from changing the way config is done, though.
[02:39]  * Chipzz wishes for a "resolve differences manually" option (for example through vimdiff) option when there are conflicts in config files
[02:41] <Chipzz> slangasek: my opinion on the default settings is: can be quite usefull. I had to do an emergency migration from docvecot to courrier a couple of weeks ago on a server, and courrier config files ship with the default options commented out, which helped alot in getting it up and running faster
[02:42] <Chipzz> also, in the case where there is no man page for the config file (which would be a bug in itself though) the default settings and comments *are* the documentation
[02:43] <Chipzz> I guess this is often the case for files in /etc/default/; only other option is to look at the init-script itself then
[02:45] <slangasek> well, it's a shame that ESR was the one to say it, because he got it right - if the user has to consult the documentation to find out how to do what they need to do, you've failed
[02:45] <slangasek> (unless they're trying to do something *really* uncommon)
[02:46] <Chipzz> some things are just inherently complex, and hence inherently require reading documentation
[02:46] <slangasek> gcc is inherently complex, but users can do a lot with it without having to consult gcc documentation :)
[02:48] <Chipzz> depends on your pov I guess ;)
[02:49] <LaserJock> hmm, I don't think I've ever read documentation for gcc itself
[02:51] <Chipzz> slangasek: btw, I was reading my backlog earlier and saw your griefs about the CD size
[02:51] <Chipzz> now I don't have any personal experience with that
[02:51] <slangasek> which round of them? :-)
[02:52] <Chipzz> but there are still some things in a default ubuntu installation which shouldn't be there by default IMO
[02:52] <Chipzz> for example, some packages ship .devhelp files in non-development packages
[02:52] <lifeless> Chipzz: so I'm saying have the docs, but in separate files
[02:53] <Chipzz> lifeless: at which point I need to have 2 editors open, and constantly switch between them
[02:53] <Chipzz> not very convenient
[02:53]  * lifeless hands Chipzz vim
[02:54] <Chipzz> lifeless: I use vim. extensively. but in most cases I have only one file open in vim
[02:54] <Chipzz> never really quite got the hang of using multiple buffers extensively
[02:55] <lifeless> I know, we could put every single config in the system into one big file :)
[02:55] <lifeless> and call it the registry
[02:55] <Chipzz> and still, having 2 files open in 1 vim still requires a mental context switch
[02:55] <lifeless> :vsplit
[02:55] <lifeless> is your friend
[02:55]  * RAOF is more a fan of C-x 3, but whatever floats your boat.
[02:55] <LaserJock> Chipzz: how big are devhelp files?
[02:55] <LaserJock> I can't imagine them taking up very much space
[02:56] <slangasek> Chipzz: huh, interesting, good point; the devhelp files do seem rather small, though
[02:56] <slangasek> so I think cleaning that up is more a conceptual cleanliness thing rather than a space-saver
[02:57] <Chipzz> LaserJock: hrrrm not too big apparently; 50KB'ish
[02:57] <Chipzz> slangasek: I brought up the issue with seb128 in the past already
[02:57] <Chipzz> he didn't seem too interested in fixing it
[02:57] <Chipzz> those are some offenders:
[02:57] <Chipzz> -rw-r--r-- 1 root   root    7921 Sep 17  2007 /usr/share/gtk-doc/html/bonobo-activation/bonobo-activation.devhelp
[02:58] <Chipzz> -rw-r--r-- 1 root   root    8634 Sep 17  2007 /usr/share/gtk-doc/html/bonobo-activation/bonobo-activation.devhelp2
[02:58] <Chipzz> -rw-r--r-- 1 root   root   59312 Oct 22  2007 /usr/share/gtk-doc/html/evince/evince.devhelp
[02:58] <Chipzz> -rw-r--r-- 1 root   root   66496 Oct 22  2007 /usr/share/gtk-doc/html/evince/evince.devhelp2
[02:58] <Chipzz> -rw-r--r-- 1 root   root   22545 Sep 18  2007 /usr/share/gtk-doc/html/gdict/gdict.devhelp
[02:58] <Chipzz> -rw-r--r-- 1 root   root   26253 Sep 18  2007 /usr/share/gtk-doc/html/gdict/gdict.devhelp2
[02:58] <Chipzz> -rw-r--r-- 1 root   root   54983 Sep 17  2007 /usr/share/gtk-doc/html/libbonobo/libbonobo.devhelp
[02:58] <Chipzz> -rw-r--r-- 1 root   root   60917 Sep 17  2007 /usr/share/gtk-doc/html/libbonobo/libbonobo.devhelp2
[02:58] <slangasek> Chipzz: send patches? :)
[02:58] <Chipzz> -rw-r--r-- 1 root   root    8990 Sep 19  2007 /usr/share/gtk-doc/html/pygtksourceview2/pygtksourceview2.devhelp
[02:58] <Chipzz> -rw-r--r-- 1 root   root   52236 Apr  7  2007 /usr/share/gtk-doc/html/rhythmbox/rhythmbox.devhelp
[02:58] <Chipzz> -rw-r--r-- 1 root   root   58543 Apr  7  2007 /usr/share/gtk-doc/html/rhythmbox/rhythmbox.devhelp2
[02:58] <Chipzz> slangasek: the issue was more an issue about seb128 not wanting to create seperate packages for them
[02:58] <Chipzz> and
[02:58] <Chipzz> they were in -common packages for example
[02:59] <Chipzz> which are arch-independant
[02:59] <slangasek> why would you need separate packages, instead of shipping them in the -dev packages?
[02:59] <Chipzz> moving those files would increase package sizes of arch-dependant packages
[02:59] <Chipzz> slangasek: well currently there is no policy on where to ship them
[03:00] <slangasek> it would increase the package sizes by, what, 2K compressed?
[03:00] <Chipzz> -rw-r--r-- 1 root   root    4943 Sep 17  2007 /usr/share/doc/libbonoboui2-common/html/libbonoboui.devhelp.gz
[03:00] <Chipzz> -rw-r--r-- 1 root   root    5040 Sep 17  2007 /usr/share/doc/libbonoboui2-common/html/libbonoboui.devhelp2.gz
[03:00] <Chipzz> ^^^ we're not even consistent about the directory we ship them in even
[03:03] <Chipzz> anyway probably not much of a win... I thought those were bigger
[03:05] <ion_> tjaalton: Yay for input hotplug! \o/
[03:05] <Chipzz> slangasek: anyway, I made a list once of all devhelp files and which packages contained them (but that was a while (about a year) ago); I can still send that file somewhere though
[03:05] <Chipzz> -rw-r--r-- 1 root root 21410 Aug 17  2007 devhelp.list
[03:05] <Chipzz> heh
[03:06] <slangasek> Chipzz: to ubuntu-devel, to try to get a consensus?
[03:06] <Chipzz> just under a year ago apparently :)
[03:06] <slangasek> it's pretty obvious to me that they ought to be in the -dev packages, but
[03:06] <Chipzz> well
[03:06] <Chipzz> in some cases they are in the -doc packages
[03:06] <Chipzz> in some cases in the -dev packages
[03:06] <Chipzz> and still other cases in a random package
[03:07] <Chipzz> now should that be -doc or -dev then?
[03:11] <slangasek> Chipzz: if the -doc package is documentation for a library, then -doc is suitable; if there's no -doc package, then -dev is suitable; all IMHO
[03:13] <Chipzz> *nod*; but then the question may popup when it's worthwhile to create a seperate -doc package and when it isn't
[03:13] <Chipzz> ah well
[03:14]  * Chipzz goes to sleep
[03:14] <Chipzz> past 4AM :P
[03:15] <ion_> ogra: Could you please share your VCS branch for the initramfs-tools packaging, or alternatively something i can dget, so i can implement the percentage thing properly and without stepping on your toes? Thanks.
[03:24] <Hobbsee> tjaalton: are we going to get a fix for the keyboard breakage soon?
[03:36] <ion_> hobbsee: Breakage?
[03:37] <Hobbsee> ion_: yeah.  i upgraded to the latest version, and it doesn't work inside of X.
[03:37] <ion_> hobbsee: Huh. Could i see your Xorg.0.log?
[03:39] <Hobbsee> ion_: http://hobbsee.com/tmp/Xorg.0.log
[03:40] <Hobbsee> i added the server flags after, and restarted X.  but i think that's the first log
[03:41] <ion_> (EE) Failed to load module "evdev" (module does not exist, 0)
[03:42] <ion_> That is reeeeally strange.
[03:44] <ion_> hobbsee: Do you have xserver-xorg-input-evdev installed?
[03:44] <Hobbsee> ion_: nope
[03:44] <ion_> hobbsee: That’s probably the problem. Something really should depend on it now that input hotplug uses evdev. :-)
[03:44] <Hobbsee> i presume i need to, and that's the input hotplug?
[03:44] <ion_> Try installing it and restarting X.
[03:45] <Hobbsee> right.  yeah, i didn't have -input-all installed
[04:36] <johanbr> ion_: I have  xserver-xorg-input-evdev and it's still fairly broken for me.
[04:37] <johanbr> Arrow keys not working, for instance.
[04:42] <ion_> Xorg.0.log?
[04:46] <johanbr> ion_: http://nullinfinity.org/tmp/Xorg.0.log
[05:01] <johanbr> ion_: This seems pretty weird: (II) XINPUT: Adding extended input device "Video Bus" (type: KEYBOARD)
[05:11] <ion_> johanbr: Ok, i see nothing obvious, but try what happens without an xorg.conf.
[05:11] <ion_> johanbr: Perhaps there are InputDevice sections or something that interact with input-hotplug badly.
[05:13] <johanbr> ion_: Alright, I'll give that a try. Thanks.
[05:35] <emgent> moin
[05:40] <nxvl> emgent: :D
[05:40]  * nxvl waves on emgent 
[05:42] <TheMuso> kirkland: WHy subscribe me to bug 33649?
[06:22] <dholbach> good morning
[07:12] <pitti> Good morning
[07:12] <nxvl> hi!
[07:13] <pitti> hey nxvl, how are you?
[07:13] <StevenK> Morning pitti
[07:13] <nxvl> pitti: would you like to sponsor one of my package updates into debian and then sync it into ubuntu :D?
[07:13] <pitti> nxvl: probably not today, I have an ultra-tight schedule today; but I'm happy to do it tomorrow if you mail me?
[07:14] <StevenK> pitti: You said you didn't care about hppa depends, so libgmime-2.0-2 and libxml++2.6c2a can be NBS'd out
[07:14] <nxvl> ok
[07:14] <nxvl> wrinting mail
[07:14] <nxvl> tomorrow sound perfect for me
[07:14] <pitti> StevenK: right, in fact that's the very first thing I'm starting with today, to clean up various other lists as well
[07:14] <StevenK> Yay!
[07:14] <pitti> StevenK: thanks a lot for your work on that
[07:15] <StevenK> pitti: Also, compare and contrast, 'rmadison -u debian twin' and 'rmadison twin'
[07:15] <StevenK> pitti: No problem :-)
[07:15] <pitti> StevenK: twin> fun
[07:16] <StevenK> pitti: Fix it? :-)
[07:16] <StevenK> pitti: When the list looks a little cleaner, point me at it, and I'll shake out another few to do.
[07:16] <nxvl> pitti: sent
[07:17] <TheMuso> pitti: Do I have to do somethng other than change a MIR's bug back to new to get it looked at again, or are those who are processing the MIR queue not through/behind with the queue?
[07:21] <pitti> TheMuso: setting back to NEW is ok, preferably with a comment
[07:21] <TheMuso> pitti: Right done that, thanks, I'll let you get on with your morning. :)
[07:24] <pitti> StevenK: "fix"?
[07:24] <pitti> StevenK: the package is newer in Ubuntu, and nobody filed a removal request
[07:25] <StevenK> pitti: Only because I fixed it so it wasn't a broken pile of crap.
[07:25] <pitti> StevenK: ah, that was you? :-)
[07:25] <StevenK> And then filed a Serious bug in the Debian BTS, which got closed
[07:25] <persia> StevenK: Isn't it better to file removal requests in those situations?
[07:26] <pitti> StevenK: so, if you want me to remove it, can do
[07:26] <StevenK> Now I'm exacting revenge
[07:26] <StevenK> pitti: Can we remove it, NEW and then remove it again? I'm feeling fairly vindictive toward it
[07:26] <pitti> lol
[07:27] <StevenK> Maybe getting elmo to rm the files off librarian would make me feel better
[07:28]  * pitti NBS-removes 15 packages
[07:28] <StevenK> \o/
[07:28] <StevenK> pitti: If you want a removal request, I'll file one, I just thought that since we remove stuff when Debian does, and twin isn't even in *stable*, we could skip it.
[07:29] <pitti> StevenK: I can remove it right now
[07:29] <kirkland> TheMuso: hiya, I thought you had grub expertise?
[07:29] <TheMuso> kirkland: No.,
[07:29] <kirkland> TheMuso: and I thought cjwatson and evand|vacation were out on holiday
[07:30] <kirkland> TheMuso: ah, sorry then, feel free to unsubscribe
[07:30] <TheMuso> kirkland: cjwatson still has Friday left I think, but I know evand is on vacation.
[07:30] <TheMuso> kirkland: I hear about that bug via the installer bugs anyway.
[07:31] <kirkland> TheMuso: gotcha...  well, this is more of the make-raid-work-right patches ;-)
[07:31]  * pitti discovers some cycles in the NBS dependencies and slaughters even more
[07:31] <StevenK> Whee
[07:34] <ScottK> pitti: We have a new team you might want to join: https://edge.launchpad.net/~ubuntu-cruft-busters
[07:36] <slangasek> and then after pitti joins it, be sure to add the group to ~we-love-pitti
[07:37] <Hobbsee> LOL!
[07:37] <Hobbsee> that actually exists...
[07:37]  * StevenK joins
[07:37]  * StevenK is a pitti fanboi
[07:38]  * persia fears the high annual membership fee to ~we-love-pitti
[07:42]  * warp10 reassures persia: first year is free!
[07:44] <nxvl> actually we should create the pitti-lovers lp team
[07:44] <nxvl> :P
[07:45] <Koon> nxvl: isn't that what ~we-love-pitti is ?
[07:45]  * Koon joins
[07:45] <nxvl> it actually exists?
[07:45] <nxvl> i thought it was a joke
[07:45]  * nxvl joins
[07:45] <Koon> nxvl: otherwise it wouldn't be as fun
[07:45]  * StevenK chuckles
[07:46]  * dholbach thought that's what ~ubuntu-6had was about
[07:46] <dholbach> "We, who believe Martin Pitt is more powerful than Chuck Norris"
[07:46]  * Koon is a true pitti fanboy, I've been for years
[07:46] <dholbach> althought I'm not so convinced about the vehement dislike for CDBS :)
[07:46] <persia> Chuck Norris doesn't have a chance when faced with a decent collection of NBS.
[07:47] <emgent> lol
[07:49] <pitti> tjaalton, bryce: xresprobe wants to go to universe, is that ok?
[07:49]  * pitti chuckles
[07:50] <nxvl> mmm that team should be open
[07:50] <nxvl> i really need to blog about this
[07:50] <pitti> StevenK: applied for joining cruft-busters; I love to clean up the house :)
[07:50] <nxvl> will do tomorrow
[07:50] <nxvl> see you!
[07:50] <slangasek> dholbach: please see the debdiff against debian/rules in the latest libgweather upload and tell me how much you love CDBS :-P
[07:50] <StevenK> Haha
[07:51] <warp10> nxvl: only True Pitti Lovers (TM) can join, we need to check candidates first ;)
[07:51] <nxvl> heh
[07:51] <nxvl> :D
[07:51] <dholbach> slangasek: I didn't say "it's the greatest thing ever", in a lot of cases it just makes things easier :)
[07:51] <emgent> bad icons..
[07:51] <emgent> similar to Pirelli :)
[07:51] <StevenK> dholbach: And in few cases, it makes slangasek cry.
[07:52] <ScottK> cdbs is really great when it works.
[07:52] <ScottK> But that's pretty much true of everything.
[07:52] <StevenK> ScottK: Didn't you go to bed, again?
[07:52] <slangasek> cry for my Axe of Code Cleaving?
[07:52] <StevenK> Haha
[07:52] <ScottK> Still working on it.
[07:52] <nxvl> cdbs is a nightmare sometimes
[07:53] <nxvl> i still prefer debhelper
[07:53] <ScottK> If you want to cry, look at debian/rules for sendmail.
[07:53] <StevenK> I want to cry, not have my eyes bleed
[07:53] <nxvl> i don't even want to check a sendmail configuration file
[07:53] <pitti> StevenK: look at doko's patch "systems" then :)
[07:53] <pitti> StevenK: e. g. in python2.5
[07:53] <StevenK> pitti: Dun wanna
[07:54] <ScottK> nxvl: The debian/rules look like something someone that likes Sendmail CF would write.
[07:55] <NCommander> pitti, welcome to cruft busters :-)
[07:55] <pitti> NCommander: thanks :)
[07:55] <NCommander> I think I birthed something that is quickly going to grow to become an offical MOTU team
[07:55] <nxvl> ScottK: sendmail added to my black list
[07:56] <pitti> tjaalton, bryce: discover1 has been removed from Debian,but it's still in Ubuntu main; do we want to keep it?
[07:56] <NCommander> ugh, what rules looks like sendmail.cf
[07:56]  * persia has a rule that no CDBS debian/rules with more than 20 lines is acceptable
[07:56] <persia> (this includes whitespace and comments)
[07:56] <pitti> tjaalton, bryce: oh, that's not actually your fault, but ltsp's, so never mind
[07:56] <tjaalton> pitti: right, xserver-xorg no longer needs it
[07:57] <pitti> tjaalton: what about xresprobe? that can go as well?
[07:57] <pitti> go to universe, I mean
[07:57] <tjaalton> yep
[07:57] <slangasek> --- libgweather-2.23.6.orig/debian/rules
[07:57] <slangasek> +++ libgweather-2.23.6/debian/rules
[07:57] <slangasek> @@ -0,0 +1,20 @@
[07:57] <slangasek> persia: what do I win? :)
[07:58] <pitti> can't that be fixed in cdbs proper?
[07:58] <slangasek> pitti: sure, it can be fixed by reverting the change for Debian bug #387103, which you and I both commented on years ago :-)
[07:58] <persia> slangasek: If you were putting the package for my review, you'd not get rejected for having an unmaintainable debian/rules.
[07:59] <StevenK> Unmaintainable!?
[07:59] <slangasek> pitti: I've committed the change already to the cdbs bzr branch, and filed a bug with Debian about it; feel free to review and upload
[07:59] <slangasek> pitti: I haven't uploaded yet because I wanted more eyeballs on it first
[07:59] <pitti> slangasek: great, thanks
[08:00] <pitti> slangasek: libgweather uses tarball.mk?
[08:00] <slangasek> pitti: no
[08:00] <slangasek> pitti: understand now my rage :)
[08:00] <slangasek> the change made *for* tarball.mk broke simple-patchsys use when you need to patch the buildsystem
[08:01] <pitti> slangasek: hm, did you push? I pulled, and nothing new from you
[08:01] <slangasek> pitti: hmm, I used debcheckout, let me check
[08:01] <slangasek> wasn't sure if that would branch or checkout
[08:02] <slangasek> right, pushing now
[08:02] <slangasek> done
[08:02] <StevenK> slangasek: bzr info will tell you
[08:02] <pitti> slangasek: so if that change works for you in libgweather, I'll test it with a normal and a tarball.mk package
[08:03] <slangasek> StevenK: yes, I seem to have gotten distracted between the time I ran that command, and the time I should have gone to look at the output :)
[08:03] <nxvl> ok blogged
[08:03] <StevenK> slangasek: Haha
[08:03] <nxvl> pitti: it's now announced, so you will receive an avalance of official fanboys
[08:03] <pitti> nxvl: argh noo!
[08:03] <pitti> it's embarassing enough as it is...
[08:03] <StevenK> Haha
[08:03] <nxvl> :D
[08:04] <StevenK> pitti: You've beaten NBS into submission?
[08:04] <Koon> nxvl: you should have blogged tomorrow, so that we joined one day before everyone else
[08:05] <pitti> StevenK: I cut a fair dent into it, anyway
[08:05] <emgent> nxvl: ln -s /usr/bin/sudo /usr/bin/pitti
[08:05] <nxvl> Koon: for me it's 2 am
[08:05] <warp10> nxvl: :D
[08:05] <Koon> heh
[08:05] <StevenK> pitti: Is the list updated too, or I need to wait for a regen?
[08:05] <nxvl> emgent: please! pitti is more powerfull that root or sudo!
[08:05] <pitti> StevenK: needs publisher first, then I can manually regen
[08:06] <emgent> nxvl: lol
[08:06] <StevenK> pitti: This run that started ~ 3 minutes ago, or another?
[08:06] <Koon> emgent: and pitti is not symbolic, he's hard
[08:07] <nxvl> i need to move to europe, europe mornings are funnier that american ones
[08:08] <nxvl> ok it's official, my post reached planet ubuntu
[08:10] <nxvl> dholbach: you've got your team too
[08:10] <nxvl> dholbach: https://edge.launchpad.net/~dholbach-huggers
[08:10] <kirkland> does anyone here move hard drives installed with ubuntu around between machines?
[08:11] <warp10> nxvl: heh :D
[08:11] <dholbach> hahaha
[08:11]  * dholbach hugs nxvl and warp10
[08:11] <dholbach> :)
[08:12] <Koon> nxvl: you need a logo or I won't join.
[08:12] <kirkland> i do...  i have a Thinkpad t61p with a 14" screen, and a much smaller x61 with a 12" screen...  the smaller one is *great* for travel, planes, trains, sprints, etc.
[08:12]  * warp10 hugs back dholbach 
[08:12] <emgent> warp10: please remove pitti group icon :)
[08:13] <nxvl> emgent: why?
[08:13] <nxvl> it's cool
[08:13] <warp10> emgent: ?
[08:13] <kirkland> everything works swimmingly, except for my xorg.conf is not portable between the two machines.  one is nvidia, the other is fglrx.  on is 1400x1050, the other is 1024x768
[08:13] <nxvl> Koon: daniels head sounds good for you?
[08:13] <emgent> warp10: it`s horrible, similar to Pirelli
[08:13] <emgent> hahah
[08:13] <kirkland> i added this to my x11-common: http://pastebin.ubuntu.com/35434/
[08:14] <kirkland> perhaps I'll talk to bryce about that tomorrow....
[08:14] <Koon> nxvl: daniels head sounds good to everyone.
[08:14] <slangasek> kirkland: hrm, why do you have an xorg.conf at all?  that's deprecated
[08:14] <pwnguin> kirkland: is HAL not appropriate?
[08:14] <pwnguin> xorg.conf isn't quite dead yet =(
[08:14] <warp10> emgent: because power is nothing without control
[08:15] <Koon> warp10: :)
[08:15] <pitti> slangasek: unfortunately the patch to prefer nvidia on autodetection was reverted upstream after only a day or so
[08:15] <pitti> kirkland: ^
[08:15] <kirkland> slangasek: I don't have "an" xorg.conf.... I have 19 :-)
[08:15] <slangasek> I still have a few, but I'm trying to cut back
[08:15] <emgent> warp10: lol
[08:15] <kirkland> pwnguin: hmm, I'm interested, how would HAL solve this?
[08:15] <ion_> I don’t have an xorg.conf. Period. ;-) Now the xorg in Ubuntu does all i need without a conf.
[08:15] <pitti> slangasek: http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=66fb253082ea42179180303393e48846208987fa FYI
[08:16] <pwnguin> kirkland: based on the laptop id, set a preferred driver?
[08:16] <pitti> tjaalton, bryce: btw, maybe we should consider applying this in Ubuntu? ^
[08:16] <pwnguin> uh, wasn't that nuked by xorg?
[08:16] <persia> kirkland: I know people who move drives like that, although I don't personally.
[08:16] <kirkland> pwnguin: i'd need to set a preferred driver, and a preferred screen resolution
[08:16] <pwnguin> pitti: if i recall, upstream soundly rejected that patch
[08:16] <pitti> pwnguin: yes, reverted because they thought that Thou Shall Not Use Nvidia
[08:17] <kirkland> persia: thanks for the validation...  i do it all the time
[08:17] <pitti> apparently they rather want you to use Windows than linux with the nvidia driver, or so :(
[08:17]  * persia wants a GEM/TTM decision and nouveau
[08:17] <kirkland> pitti: pfft...  well, i'm no fan of the nvidia driver, but it's the only option out there that let's me use my hardware thoroughly :-/
[08:17] <pwnguin> indeed, it would help if intel hadn't coopted xorg =/
[08:18] <pitti> kirkland: same here (luckily I have intel, but many people don't have a choice)
[08:18] <slangasek> pwnguin: how would that help?
[08:18] <pitti> kirkland: and nv wouldn't even play videos on my amd64 desktop
[08:18] <pwnguin> slangasek: gem/ttm might be solved by now?
[08:18] <pitti> kirkland: and that's a sacrifice I'm not wanting to make
[08:18] <dholbach> hi mvo
[08:18] <slangasek> pwnguin: hum, ok
[08:18] <pitti> mvo: morschn
[08:18] <kirkland> pitti must like his videos :-)
[08:19] <pitti> I don't have a TV :)
[08:19] <nxvl> Koon: it already have icon
[08:19] <pitti> kirkland: you should have seen my wife during the EURO soccer championship :)
[08:19] <kirkland> pitti: ah, that'll do it...  yeah, i love Google Earth and Scorched3D, both of those need good hw acceleration
[08:20] <kirkland> pitti: watching on a laptop, fun, i'm sure ;-)
[08:20] <pitti> kirkland: well, laptop with a 19" TFT attached
[08:20] <tjaalton> pitti: probably, then jockey would not need to mess with xorg.conf
[08:20] <kirkland> ah, that's better
[08:20] <pitti> kirkland: I'm using a docking station with a proper keyboard and TFT
[08:21]  * pitti doesn't ever want to give up his Kinesis Ergo keyboard
[08:21] <kirkland> pwnguin: I'm still curious how to solve this with HAL?
[08:22] <pwnguin> kirkland: im not entirely sure either
[08:22] <mvo> hey dholbach and pitti
[08:22] <kirkland> slangasek: and what is to be used instead of xorg.conf, to define my video driver and default resolution?
[08:22] <pwnguin> afaik, HAL
[08:23] <persia> Yes, HAL ought have enough information to do that.
[08:23] <slangasek> kirkland: well, I thought we were supposed to already be to the point of not needing xorg.conf for anything other than keyboard map settings, as of hardy; but apparently I was wrong
[08:23] <pwnguin> hardy doen't handle tablets either
[08:24] <persia> slangasek: Also required for some other input devices, screens with inaccurate EDID, and other oddities.
[08:24] <slangasek> though screens with inaccurate EDID also can (and should) be quirked
[08:25] <persia> slangasek: All of them?
[08:25] <slangasek> yes? :)
[08:25]  * persia suspects the same is true for odd input devices, but quails at the volume of quirks
[08:26] <tjaalton> kirkland: the xserver knows what driver to load based on the pci-id
[08:26] <kirkland> tjaalton: does that get detected on every boot?
[08:27] <slangasek> it gets detected every time the X server runs
[08:27] <tjaalton> kirkland: boot == xserver load, yes
[08:27] <tjaalton> kirkland: see the link pitti posted
[08:27] <kirkland> tjaalton: the git commit?
[08:28] <pwnguin> yea, it changes what gets loaded on pci-id
[08:28] <tjaalton> running without xorg.conf works fine, provided that you use us layout and HAL is running
[08:28] <kirkland> tjaalton: so should the xserver be able to automagically handle me moving an entire hard disk back and forth, between two laptops, with different (nvidia, ati) drivers, and different resolutions (1400x1050, 1024x768)?
[08:28] <ion_> tjaalton: Huh? I’m running without xorg.conf and i have a very specific configuration for keyboard in /etc/default/console-setup.
[08:28] <kirkland> tjaalton: because it does not handle that gracefully
[08:29] <tjaalton> kirkland: no, you can't have both nvidia and flgrx installed
[08:29] <tjaalton> ion_: intrepid?
[08:29] <pwnguin> kirkland: or if you have xorg.conf, i think it'll use that instead
[08:29] <ion_> tjaalton: Yes. XKBLAYOUT="us,fi" XKBVARIANT=",kotoistus" XKBOPTIONS="lv3:ralt_switch,ctrl:nocaps,grp:alt_shift_toggle,compose:rwin"
[08:29] <tjaalton> ion_: should've mentioned that I meant hardy :)
[08:29] <ion_> tjaalton: Ah, ok
[08:29] <tjaalton> in intrepid you have input-hotplug
[08:29] <ion_> Yes
[08:30] <ion_> Which rules. :-)
[08:31] <tjaalton> you can also set other options via HAL, unless they are ServerFlags, so setting the mode and stuff _should_ work using an fdi file
[08:31] <tjaalton> or driver options
[08:32] <pwnguin> did bryce write this up in the wiki yet?
[08:32] <tjaalton> there's something yes, but I havent' had time to read it through yet
[08:32] <pwnguin> https://wiki.ubuntu.com/X/Config
[08:34] <kirkland> tjaalton: linux-restricted-modules provides both an nvidia and an fglrx kernel module....  do you mean the xserver drivers specifically conflict?
[08:34] <tjaalton> kirkland: no, the userland libgl libs
[08:34] <tjaalton> how have you managed to install those?-)
[08:34] <tjaalton> since the drivers conflict each other
[08:35] <tjaalton> +with
[08:35] <kirkland> tjaalton: i haven't yet, i'm still trying to figure this out
[08:35] <tjaalton> heh, ok
[08:35] <tjaalton> which ati do you have?
[08:35] <tjaalton> chip
[08:36] <tjaalton> if it's r5xx series, you shouldn't need fglrx anymore in intrepid
[08:37] <tjaalton> lspci -vnn |grep VGA
[08:38] <kirkland> tjaalton: sorry, no hard drive in that machine at the moment ;-)
[08:38] <tjaalton> heh, ok
[08:39] <kirkland> tjaalton: i'm slightly baffled, though, because according to http://www.thinkwiki.org/wiki/Category:X61 it has an Intel Graphics Media Accelerator X3100
[08:39] <kirkland> tjaalton: and I swear I thought it was an ATI driver....
[08:40] <pwnguin> well, lspci will know for sure
[08:40] <pwnguin> there might be an optional ati graphics
[08:40] <tjaalton> I've got a X61 myself, and it's intel. but there are a lot of variations
[08:40] <kirkland> tjaalton: right... ThinkWiki is generally dead on, on the options
[08:40] <kirkland> more informative than ibm/lenovo.com :-)
[08:41] <kirkland> tjaalton: okay, in that case, I'm switching between nVidia Corporation Quadro FX 570M and Intel Graphics Media Accelerator X3100
[08:42] <tjaalton> kirkland: right, and even then you wouldn't have 3D on the intel, since nvidia replaces the libs
[08:42] <kirkland> tjaalton: same problem then
[08:43]  * kirkland wonders if it would be possible to make those libs update-alternatives savvy....
[08:43] <tjaalton> uh no please, dpkg-divert is enough of a nightmare :)
[08:44] <slangasek> pitti: btw, yes, I confirm that the cdbs patch works for libgweather
[08:44] <pitti> slangasek: and I just finished the other two tests
[08:44] <pitti> slangasek: uploaded then
[08:44] <pitti> slangasek: thanks for the fix
[08:44] <slangasek> sure
[08:44] <pitti> so feel free to do another sanitized upload with the appropriate build dep
[08:45] <pitti> 0.4.52ubuntu6
[08:45] <kirkland> tjaalton: interesting okay.... so it looks like i'd need to apt-get install/remove the libs each time I move HD's
[08:45] <slangasek> tomorrow :)
[08:46] <pitti> oh, dhcdbdbdbd wants to go to universe \o/
[08:46] <pitti> kirkland: btw, could you please seed ecryptfs somewhere? it wants to go back to universe
[08:46] <tjaalton> kirkland: well, unless you can manage having metacity on intel :)
[08:46] <kirkland> pitti: hmm, yeah, i'd like to...  slangasek and mathiaz were debating the best place to put it
[08:47] <slangasek> I wasn't debating anything :)
[08:47] <kirkland> pitti: i'd like to make it a "recommends" of either xdg-user-dirs or adduser
[08:48] <pitti> kirkland: uh, that doesn't sound appropriate to me TBH
[08:48] <kirkland> pitti: let me bounce this off of you...
[08:48] <pitti> kirkland: it's a relatively independent new feature, so shouldn't it become an ubuntu-standard recommends:?
[08:49] <pitti> or put into both desktop-common and the server seed?
[08:49] <pitti> it shuold be uninstallable without much pain
[08:49] <kirkland> pitti: okay
[08:56] <kirkland> pitti: https://code.launchpad.net/~kirkland/ubuntu-seeds/247400
[08:58] <pitti> kirkland: oh, a full branch wouldn't have been necessary, but sure :)
[08:58] <Koon> slangasek: about the base-files merge, I found where the libc6 amd64 depends comes from -- /usr/lib64 and /lib64 symlinks where moved to libc6 at 3.1.9ubuntu8, then you need to depend on a libc6 new enough that we get /lib64 created BEFORE we remove our copy
[08:58] <pitti> kirkland: I guess we want it on desktop, too?
[08:58] <kirkland> pitti: i would like to see it there too, doesn't have to be on the cd, i don't suppose
[08:58] <kirkland> pitti: which seed do you recommend?
[08:59] <pitti> kirkland: if we want it by default -> desktop-common, if we only want to make it available -> supported
[08:59] <slangasek> Koon: I don't see any code in the diff currently that does a removal of /lib64; can this go away now?
[08:59] <pitti> kirkland: but for the latter case, the server seed is enough already
[08:59] <Koon> slangasek: it was probably a diff to debian that was dropped
[09:00] <kirkland> pitti: okay, here's what I'm thinking.....
[09:00] <pitti> kirkland: merged your branch
[09:00] <kirkland> pitti: eventually, perhaps intrepid+1, i'd like to hook adduser to run ecryptfs-setup-private, which sets up ~/Private to be encrypted perhaps by default
[09:01] <kirkland> pitti: for intrepid, i'm thinking it should be more of a conscious opt-in deal
[09:01] <pitti> agreed
[09:01] <kirkland> pitti: so how about this....
[09:01] <Koon> slangasek: I don't think we'll have an upgrade scenario now that makes it required, so I'll drop it
[09:01] <slangasek> Koon: ok, thanks :)
[09:02] <kirkland> pitti: add a ~/Private directory to the skeleton, and in there, drop a symlink to ecryptfs-setup-private, and name it something informative, like "Setup this directory for encryption" or some such
[09:02] <kirkland> pitti: user clicks on it or runs it from a command line, and voila, they're setup
[09:03] <pitti> kirkland: sounds great
[09:03] <pitti> or they can just delete the dir if they don't want it
[09:03] <kirkland> pitti: right
[09:03] <kirkland> pitti: okay, i'll work on that a bit next week
[09:03] <liw> uh, more useless semi-mandatory directories in user's home directories... why skel? why not create it when it's set up?
[09:04] <kirkland> pitti: i'd also like to get ~/Private translatable, via xdg-user-dirs or somesuch
[09:04] <kirkland> liw: it would be created, if the user runs "ecryptfs-setup-private" ...  but how do we expose that?
[09:05] <kirkland> liw: ie, how does a non-sophisticated ubuntu user find that magic command
[09:05] <liw> kirkland, let me ask a counter-question: how do they find any other magic command?
[09:07] <kirkland> liw: the Applications menu ... however, this is a script that a user could/would/should run only one time
[09:07] <kirkland> liw: and by "a user", I mean each user on the system
[09:08] <liw> kirkland, the encrypted ~/Private directory never, ever needs to be maintained? its passphrase never needs to be changed?
[09:09] <kirkland> the passphrase is randomly generated, and then wrapped with the user's login passphrase.  pam takes care of unwrapping that passphrase on login, and mounting/unmounting on login/logout
[09:10] <liw> kirkland, even a random passphrase may need to be updated (e.g., if the passphrase generator was buggy)
[09:11] <kirkland> liw: see: ecryptfs-wrap-passphrase, ecryptfs-unwrap-passphrase, ecryptfs-rewrap-passphrase
[09:12] <kirkland> liw: and you'd need to re-encrypt every file on the mountpoint
[09:15] <liw> kirkland, the need to re-encrypt smells like there needs to be a tool for that; include that in the same tool that sets things up in the first place, and launch that tool from the menu
[09:15] <liw> that way, it's discoverable, and doesn't pollute the user's name space with yet another generically named directory that overlaps the user's existing stuff
[09:17] <kirkland> liw: sounds good, when can I expect the patch?  :-)
[09:17] <kirkland> liw: us server guys are not allowed to write gui's :-)
[09:18] <liw> kirkland, so the Applications menu was a red herring?
[09:19] <liw> I don't see how creating a ~/Private will help someone discover a script
[09:20] <kirkland> liw: not really.... you've convinced me that a longer term nice-to-have would be something in Applications -> System Tools -> eCryptfs Management ...  a little python utility with gui wrappers for all of the ecryptfs-* command line utilities I know and love
[09:21] <kirkland> liw: because we already have a ~/Public ... this ~/Private would be its encrypted, 700-permed sister
[09:22] <liw> ah yes, ~/Public, yet more invasion of _my_ name space :)
[09:22] <kirkland> http://ubuntu.dustinkirkland.com/manpages/intrepid/man1/rmdir.html
[09:23] <liw> I know how to remove them, but that didn't stop f-spot from becoming terminally confused when the ~/Photos directory it found was something altogether strange...
[09:23] <pwnguin> hmm. perhaps if there was a way to simply mount the ecryptfs over a given dir
[09:24] <kirkland> yurp...  f-spot is one of the first things I remove with prejudice everytime i install ubuntu
[09:24] <pwnguin> have some encrypted dir stored in ext, then the script mounts over it
[09:24] <kirkland> pwnguin: i'm going to hack on that a bit next week
[09:25] <kirkland> pwnguin: the mount command is a custom setuid binary, so the namespace of legal dirnames needs to be tightly constrained
[09:25] <pwnguin> fusermount?
[09:25] <kirkland> pwnguin: nope
[09:26] <kirkland> pwnguin: ecryptfs is in the kernel
[09:27] <liw> there must be a better solution than willy-nilly creation of directories in $HOME for users... especially since old accounts won't get them for new services
[09:28] <liw> (assuming that the ~/Private I created fifteen years ago is the ~/Private that should be used with ecryptfs seems like a massively bad idea to me)
[09:29] <pitti> zul: can you confirm bug 241041?
[09:33] <pitti> StevenK: http://people.ubuntu.com/~ubuntu-archive/NBS/ updated now
[09:33] <StevenK> pitti: \o/
[09:33] <pitti> StevenK: oh, that apt-howto stuff is brand new, seems I can kill that as well
[09:34] <pitti> hm, in fact i just removed the source package
[09:34] <pitti> I think that's just temporary noise
[09:37] <StevenK> pitti: Ignoring it
[09:42]  * StevenK blinks.
[09:45]  * StevenK tries to unravel a mess
[09:49] <pitti> Riddell: should I accept source-NEW packages which include debian/cdbs/kde.mk? or reject them and ask to use cdbs' built in version now?
[09:58] <thorwil> is that normal that decrypting a launchpad key confirmation takes ages and chews cpu like crazy?
[09:58] <StevenK> Depends how large your key is
[09:59] <StevenK> (Somewhat)
[09:59] <thorwil> all defaults. 2048
[10:00] <thorwil> evolution is at 0% since at least 4 minutes
[10:01] <thorwil> arg, nevermind, a 2nd authorization dialog was below the main window, sorry
[10:01] <thorwil> head->desk
[10:45] <tjaalton> asac: cool, 3G works fine with nm0.7 :)
[10:45] <tjaalton> it did ask a password, but for the network provider it was simply "internet"
[10:45] <tjaalton> (Finnish Elisa)
[10:49] <asac> tjaalton: https://wiki.ubuntu.com/NetworkManager/Hardware/3G
[10:49] <tjaalton> asac: it's the same device as mdz has
[10:49] <asac> tjaalton: ok. add that info anyway ;)
[10:50] <tjaalton> asac: yeah I will, had the page open already :)
[10:54] <tjaalton> pitti: looks like hotkey-setup initscript depends on discover (but the package didn't), but that should be easy to fix
[11:02] <tkamppeter> pitti, hi
[11:14] <mvo> pitti: the localegen hang you looked at some days ago, did you found out more about it? any news?
[11:18] <YokoZar1> kees: ping
[11:18] <YokoZar> Does anyone know how the new /etc/sysctl.d/ folder works with sysctl?  It's totally undocumented
[11:19] <Riddell> pitti: hmm, good question, I guess they ought to be rejected, but Debian don't have kde4.mk in cdbs so it could be justified that it's closer to debian not to
[11:19] <Riddell> (sorry for the late reply, was getting ready for trip to akademy)
[11:20] <Trewas> tjaalton: actually "internet" is the APN, and no username/password for elisa... at least that's how I have set up with wvdial
[11:37] <tjaalton> Trewas: ah, ok. for wvdial "internet" was the password
[11:41] <Trewas> nm 0.7 (hardy version from https://launchpad.net/~network-manager/+archive) does not seem to react at all when I plug in nokia 6120 with usb-cable... it shows up as /dev/ttyACM0 and the network connection works with wvdial
[11:50] <Riddell> Trewas: report a bug adding the relevant parts of lshal
[12:50] <cjwatson> lool: for the most part I just symlinked lpia to i386; it at least built, which is a fairly good sign since the d-i build process is quite picky
[12:50] <cjwatson> (for which read "insanely sensitive to local build environment")
[12:56] <lool> cjwatson: Ok; when I looked into it, it seemed amd64 was slightly cleaner than i386 in that it didn't carry backward compatibility modules and configs, so I thought the same cleanups could be beneficials for lpia; all I care about is that it works though  :-)
[12:57] <lool> cjwatson: You plan to enable builds on cdimage of e.g. the alternate CD?  I guess plenty of udebs are still missing for lpia
[12:57]  * lool needs to disappear for a phone call &
[13:04] <zul> pitti: acked
[13:04] <pitti> zul: thanks
[13:04] <pitti> hi tkamppeter
[13:04] <pitti> mvo: no, I couldn't reproduce it at all, with several attempts; did you?
[13:05] <geser> soren: bug #256037
[13:05] <pitti> Riddell: ok, I'll accept it then if you are comfortable with this
[13:06] <mvo> pitti: no, I tried it too, but no luck, I was just curious
[13:09] <pitti> tkamppeter: ah, got your cups package reply, thanks for working on this! I guess Mike will be happy about a working patch which integrates into cups' build system
[13:09] <cjwatson> lool: I suspect most of the udebs are already there
[13:10] <cjwatson> lool: I'd be happy to build alternate CD images under ports, just haven't turned it on yet :-)
[13:27] <pitti> seb128: workrave is seeded on the dvd; WDYT, promote or unseed?
[13:27] <pitti> seb128: how well is it maintained upstream?
[13:27] <seb128> pitti: no clue
[13:27] <seb128> I don't use it and I don't maintain it
[13:27] <seb128> I asked about demotion some time ago because the only changes had were language packs one
[13:28] <seb128> mdz agree on moving it to universe
[13:28] <pitti> ok, thanks
[13:28] <seb128> dunno about the DVD
[13:28] <pitti> I'll unseed it then and wait for complaints :)
[13:34] <ScottK> pitti: I just ran across a case where apport duped a public bug to a private bug and then Launchpad hid the public bug from default searches.  Bug in apport or Launchpad?
[13:35] <pitti> ScottK: it's controlled by apport
[13:35] <pitti> ScottK: when it encounters a dup, it marks the bug as public and drops all apport attachments from it
[13:35] <pitti> if that is too confusing, we can keep the duplicate private as well
[13:36] <ScottK> This one was manually filed.
[13:36] <ScottK> I think.
[13:37] <ScottK> I take that back.
[13:37] <pitti> seb128: gnome-panel recommends menu-xdg which in turn depends on menu; I don't think we want either in main, right?
[13:37] <pitti> seb128: mind if I do an upload to drop the recommends?
[13:38] <ScottK> pitti: I think that's sensible.  Perhaps apport could leave a comment describing what it's doing.
[13:38] <seb128> pitti: for for it
[13:38] <seb128> pitti: Suggests is good
[13:41] <pitti> seb128: done, merci
[13:42] <pitti> asac, Riddell: network-manager-kde recommends n-m-{pptp,openvpn,vpnc}; are these obsolete, or should they rather become recommends of the network-manager package?
[13:43] <asac> pitti: they should become recommends of network-manager package as soon we have a working snapshot for them
[13:43] <asac> pitti: currently they should be banned
[13:43] <pitti> because they want to go to main due to that
[13:43] <asac> but ill get them up as soon as i have stabilized them
[13:43] <pitti> asac: ah, so they don't currently work even?
[13:43] <asac> yes
[13:43] <asac> broken
[13:43] <pitti> asac: ok, and then n-m itself will pull them in?
[13:43] <pitti> then it seems dropping them from -kde is the right thing here
[13:43] <asac> pitti: i hope we can get them to a quality level that allows us to do that. right
[13:44] <asac> pitti: ack.
[13:44] <devfil> pitti: I'm working to fix knetworkmanager FTBFS, so in the debdiff I also drop them?
[13:44] <asac> devfil: in ~networkmanager PPA we have a snapshot
[13:44] <pitti> devfil: oh, I was in the middle of doing that; please do that then
[13:44] <asac> doesnt that build anymore?
[13:44] <pitti> devfil: thank you, good timing!
[13:46] <devfil> pitti: I've already done it, I was just pinging Riddell to upload it, so I need only to drop the n-m-{vpnc,opnvpn,pptp}
[13:48] <devfil> all done
[13:49] <devfil> pitti: can you take a look at the debdiff?
[14:20] <pitti> devfil: where can I find it?
[14:20] <devfil> pitti: http://pastebin.ubuntu.com/35520/
[14:21] <pitti> devfil: looks good; I'll add a slightly better rationale for the recommends drop and upload
[14:21] <devfil> ok
[14:22] <pitti> devfil: done, thank you
[14:38] <cjwatson> lool: lpia alternate CDs should start building tomorrow
[15:06] <persia> cjwatson: Will that come with an uninstallable binaries mail?  To which list would that mail go?
[15:07] <ScottK> bryce: Are you close to being ready to ask for displayconfig-gtk to be removed?
[15:08] <cjwatson> persia: hmm, don't have an arrangement to do that per-arch at the moment
[15:08] <persia> cjwatson: OK.  Where do the reports go now?
[15:08] <cjwatson> persia: cjwatson@ubuntu.com tfheen@ubuntu.com adconrad@ubuntu.com martin.pitt@ubuntu.com steve.langasek@ubuntu.com
[15:09] <cjwatson> I can add something else to that list if you'd like
[15:09] <persia> Sure.  Add me.
[15:09] <pitti> hm, is edubuntu-meta still relevant at all?
[15:09] <pitti> it didn't have a single upload in intrepid
[15:09] <pitti> cjwatson: ^ do you happen to know?
[15:11] <pitti> Riddell: edubuntu-desktop depends on khelpcenter kdeartwork-theme-icon; however, kdeartwork-theme-icon conflicts to kdelibs-data, and khelpcenter depends on kdelibs-data; what's the correct thing here?
[15:11] <pitti> Riddell: edubuntu-desktop-kde, I mean
[15:11] <cjwatson> pitti: I'm not sure; for the moment you should probably feel free to render it uninstallable
[15:11] <pitti> cjwatson: s/render/keep/, I guess
[15:12] <pitti> cjwatson: I cannot even ./update it, it falls apart with a 404 (it probably just needs some ports.u.c. URL change)
[15:12] <pitti> cjwatson: ok, if it's not critical for alpha4, I won't touch it for now
[15:15] <cjwatson> pitti: I'll fix its ./update in a moment
[15:15] <pitti> cjwatson: ok, thank you
[15:17] <cjwatson> persia: done
[15:17] <persia> cjwatson: Thank you.
[15:17] <cjwatson> persia: I just gave you the Ubuntu mail, figured you wouldn't care about other derivatives
[15:18] <persia> cjwatson: That's likely best.  I get mail on one derivative now, and may want more later (depending on how those shape up), but that is probably best through the derivative lists rather than directly.
[15:21] <pitti> soren: so, libvirt0-dbg depends on libvirt0, but libvirt0 conflicts to libvirt0-dbg; that doesn't make sense to me; should that be a versioned conflict, or is -dbg obsolete?
[15:27] <pitti> tseliot: oh, argh
[15:27] <pitti> tseliot: nvidia-glx-* is uninstallable on amd64, since it depends on ia32-libs
[15:27] <pitti> tseliot: what do they need ia32-libs for?
[15:29] <tseliot> pitti: I want ia32-libs to be installed first so as to divert some of its libraries. If you install ia32libs (e.g. for flash) you automatically screw up the 32bit compatibility libraries of the nvidia driver
[15:29] <pitti> tseliot: right, just reading the bug
[15:30] <pitti> tseliot: but that's pretty unfortunate; shouldn't that be possible to fix in the preinst as well?
[15:30] <pitti> tseliot: ia32-libs is huge, and not many people need it
[15:30] <pitti> first, it's in universe, so we can't depend on it in main/restricted
[15:30] <tseliot> pitti: did you have a look at how ia32-libs is packaged?
[15:30] <pitti> and second we shuoldn't force it upon every nvidia user just becaues of that workaround
[15:30] <pitti> tseliot: I know the basics, I did some updates, yes
[15:31] <tseliot> pitti: basically the preinst of ia32-libs should look for diversions of the certain libraries done by the nvidia-glx-VER packages
[15:32] <pitti> tseliot: so n-glx' libraries should win?
[15:33] <tseliot> pitti: yes
[15:33] <RainCT> mvo: Hey. Have you seen my improvements for AptUrl?
[15:33] <pitti> so n-glx ships its own 32 bit compat libraries arleady
[15:33] <pitti> tseliot: that shuold be possible in the preinst, in theory
[15:33] <pitti> tseliot: brb
[15:34] <mvo> RainCT: no, but I was a bit swamped this week, let me have a look
[15:36] <pitti> tseliot: mind if I reopen the bug, so that we don't forget?
[15:36] <RainCT> mvo: lp:~rainct/apturl/ubuntu
[15:36]  * mvo merges
[15:38] <tseliot> pitti: feel free to reopen it
[15:39] <pitti> tseliot: is libGLl.so.1 already a diversion, or a normal file?
[15:39] <pitti> lib32GL.so.1 I mean
[15:39] <pitti> argh
[15:39] <pitti> /usr/lib32/libGL.so.1 -> that one
[15:39] <cjwatson> pitti: fixed edubuntu-meta
[15:39] <pitti> cjwatson: thanks
[15:40] <pitti> zul: dbconfig-common? argh, that thing is a mess
[15:40] <zul> pitti: heh dont shoot the messenger ;)
[15:41] <pitti> tseliot: ok, commented on the bug
[15:42] <pitti> asac: should I move nspr to updates without nss? or both at the same time?
[15:43] <asac> pitti: both at the same time ... i am currently installing a fresh gutsy chroot so i can verify the gutsy upgrade again
[15:43] <asac> pitti: actually doesnt matter if both at the same time, but i think we should move both at once
[15:44] <DktrKranz> pitti, if you plan to manage verified SRUs for universe, could you please take into account ocamlsdl (bug 249355) too? It doesn't show bug number in pending-sru list, but it received verification.
[15:44] <tseliot> pitti: libGL.so is a symlink to libGL.so.173.14.09
[15:44] <tseliot> libGL.so.1 is a symlink to libGL.so.$VERSION
[15:44] <tseliot> libGL.so.$VERSION (e.g. libGL.so.173.14.09) is the real file
[15:44] <tseliot> by libGL.so.173.14.09 I meant libGL.so.$VERSION
[15:45] <tseliot> in the 1st line
[15:47] <bryce> ScottK: not yet
[15:47] <ScottK> bryce: OK.  We may not be very far from that being the last user of guidance-backends.
[15:48] <pitti> tseliot: ok, so we just need to divert the symlink, that should be easy
[15:49] <bigon> !!
[15:50] <bryce> ScottK: I sent mdz some mail about the situation.  He'd sort of like to see a replacement rather than just rip it out with nothing to stick in, since for the failsafe-x mode it'll mean returning the users to the old blue text screen of death
[15:50] <tseliot> pitti: but wouldn't this break the nvidia driver in so doing?
[15:50] <bigon> ark sorry for that
[15:50] <bryce> however I don't think there is any drop in replacement available yet
[15:50] <superm1> what was the deficiency in the current tool?
[15:50] <ScottK> bryce: Right.  tseliot has a new xorg.conf parser.
[15:50] <pitti> tseliot: oh, right, hang on, we want nvidia's to win
[15:51] <tseliot> pitti: that was the problem ;)
[15:51] <ScottK> superm1: Fundamentally broken with modern X11 that has no xorg.conf and needs a major rewrite to use xrandr.
[15:51] <pitti> tseliot: so, for installing nvidia after ia32-libs, nvida just needs to Replaces: ia32-libs
[15:52] <pitti> tseliot: and for installing ia32-libs after nvidia we should add a diversion of that file, shouldn't that work?
[15:52] <superm1> i believe i am missing something, but don't you still need xorg.conf for situations that you want to impose configuration that you are forcing though?
[15:52] <superm1> such as particular video drivers or monitor configurations that should be valid before entering {,x,k}ubuntu ?
[15:52] <pitti> tseliot: that should force dpkg to unpack ia32-libs's libGL.so.1 to somewhere else
[15:53]  * pitti hasn't personally used diversions yet, but believes that this is their purpose
[15:53] <tseliot> pitti: currently nvidia-glx-VER adds a diversion on that file. Installing ia32-libs is the problem
[15:53] <ScottK> superm1: Right, but guidance-displayconfig and guidance-displayconfig-gtk need rewriting to use xrandr.
[15:54] <pitti> tseliot: weird; ia32-libs doesn't respect the diversion?
[15:54] <bryce> superm1: guidance has a design assumption that all of the configuration is listed in xorg.conf, so if you give it a semi-empty xorg.conf like we currently ship, it breaks in myriad ways
[15:54] <superm1> ScottK, but that's what i'm getting at, these tools are only useful in situations that the automatic detection fail.  They restart the session
[15:54] <superm1> bryce, ah
[15:55] <tseliot> pitti: ia32-libs simply tries to overwrite the file
[15:55] <ScottK> It used to break if it was missing too, but I at least got that sort of working in Hardy.
[15:55] <superm1> bryce, ScottK so the problem is more that they don't parse/get along with hardy/intrepid xorg confs moreso then them not using xrandr
[15:55] <bryce> ScottK: I'm quite conversant with x-kit.  ;-)
[15:55] <ScottK> Great.
[15:55] <bryce> superm1: no, both are problems
[15:55] <superm1> bryce, is the upstream to displayconfig-gtk not receptive to such problems?
[15:56]  * ScottK watches bryce look in the mirror.
[15:56] <bryce> ScottK: ??
[15:56] <ScottK> There isn't particularly an upstream for the gtk variant is there?
[15:56] <bryce> superm1: the upstream has gone away
[15:57] <pitti> tseliot: I did "sudo dpkg-divert  --divert /usr/bin/pmount.foo --add /usr/bin/pmount" and then apt-get install pmount
[15:57] <superm1> bryce, oh that does make for trouble then
[15:57] <pitti> tseliot: that correctly unpacks it as /usr/bin/pmount.foo
[15:58] <bryce> ScottK: X-kit is just one piece of what's needed.  Like I said we currently do not have a drop-in replacement for displayconfig-gtk
[15:59] <bryce> so a new one would need to be developed based on X-Kit and pieces of displayconfig-gtk.  but that's not something anyone is working on currently
[15:59] <tseliot> bryce: and porting displayconfig-gtk to x-kit would mean writing it from scratch
[16:00] <tseliot> bryce: I could work on that too but I guess it's too late for Intrepid, isn't it?
[16:00]  * ScottK ponders renaming kde-guidance to gtk-guidance.
[16:00] <bryce> yeah it's too late for Intrepid
[16:01] <tseliot> pitti: ok, so we should simply put the diversion in the preinst, right?
[16:01] <bryce> tseliot: yeah I figure a rewrite is needed, and that it's a significant amount of work - which is why I've not mentioned it to you.  ;-)  Better to get X-Kit solid first
[16:01] <pitti> tseliot: didn't you say it already had one?
[16:01] <pitti> tseliot: right, but I was confused. it needs to be in nvidia's preinst, not in ia32-libs'
[16:01] <tseliot> pitti: see my new comment in the bugreport
[16:02] <tseliot> bryce: right
[16:02] <bryce> also, I'm not entirely sure if a displayconfig-gtk-like tool is the right thing for the failsafe mode.
[16:03] <bryce> probably we need something simpler and more robust.  A lot of the functionality in displayconfig-gtk - like setting up resolutions and such - isn't necessary these days
[16:03] <bryce> well, not often
[16:04] <pitti> tseliot: hm, seems something is wrong with that diversion then
[16:04] <tseliot> bryce: maybe phase 2 of the blueprint could replace it
[16:04] <pitti> tseliot: I have release team meeting now, let's figure it out later
[16:04] <tseliot> pitti: ok, see you later
[16:05] <pitti> tseliot: I think that install should be reattempted under observaition, with properly checking dpkg-divert --list and everything
[16:05] <tseliot> pitti: ok, I'll have another look at it
[16:06] <tseliot> bryce: I'm afraid that the xorg options editor wouldn't be as user-friendly as displayconfig-gtk
[16:10] <cjwatson> mvo: have you had a chance to look at bug 255545? it's about to come up in the release team meeting
[16:11] <bryce> tseliot: yep I know.  no worries, we'll get there eventually
[16:11] <mvo> cjwatson: I haven't. when is the release team meeting?
[16:11] <cjwatson> mvo: now :-)
[16:11] <cjwatson> mvo: (it's ok, it's not a meeting blocker, just wanted to know if you'd seen it and had any thoughts about whether it was feasible for intrepid)
[16:12] <cjwatson> it'd be a nice 1.5MB saving
[16:14] <cjwatson> TheMuso: are you likely to be able to upload your new-and-improved ubuntu-sounds for a4?
[16:16] <bronson> I'm getting a ftbfs for libwebkitgtk1d.
[16:16] <bronson> apt-get source libwebkitgtk1d; sudo apt-get build-dep libwebkitgtk1d
[16:17] <bronson> cd webkit-0~svn29752; dpkg-buildpackage -rfakeroot
[16:17] <seb128> bronson: what ubuntu version do you use?
[16:17] <bronson> Oh, right.  seb128, Hardy.
[16:18] <bronson> The error is a little confusing, "/usr/include/zlib.h:218: error: expected constructor, destructor, or type conversion before ‘extern’"
[16:19] <pitti> seb128: that brings me an idea: pm-utils already do suspend/hibernate, why shouldn't pm-utils do shutdown/reboot as well? that would be a fitting place, without layer violation
[16:19] <bronson> This is on i686, haven't tried amd64 yet.
[16:21] <bronson> Any ideas on why my build fails?
[16:23] <seb128> pitti: looks like a solution indeed
[16:24] <seb128> bronson: no, it built fine on the official buildds, did you do any change?
[16:24] <bronson> seb128, none at all.
[16:24] <seb128> bronson: why do you need to build it?
[16:25] <bronson> I'm trying to figure out why my app, using webkit, won't use plugins.
[16:25] <seb128> maybe try to build the intrepid version
[16:25] <bronson> I wanted to make sure that the configure step is being performed the way I expect.
[16:26] <bronson> Guess so...  I'm off to install +1.
[16:27] <seb128> bronson: you can look at the build logs on launchpad
[16:27] <bronson> ooh, neat.  I'll look.
[16:30] <bronson> I'm getting "No matching builds" for libwebkitgtk1d
[16:30] <bronson> Is https://launchpad.net/ubuntu/hardy/+builds?build_text=libwebkitgtk1d&build_state=all the right place?
[16:34] <tseliot> superm1: in vnc.py you assume that a Screen section is available. Is this always the case when you run the program?
[16:36] <superm1> tseliot, well not necessarily i suppose
[16:36] <bronson> seb128, Any idea why there are no builds for libwebkitgtk1d?
[16:37] <superm1> tseliot, is there xkit functionality to add the screen section as necessary?
[16:37] <bronson> That page shows builds for all the other packages I've tried.
[16:37] <tseliot> superm1: I can see how many screen sections are available
[16:38] <tseliot> and add a new one if len == 0
[16:38] <tseliot> superm1: I'll deal with it. I just wanted to be sure
[16:39] <superm1> tseliot, okay sounds good
[16:41] <seb128> bronson: the source package is named webkit
[16:41] <bronson> Ah, I thought the source package was "webkit-0~svn29752"  :)
[16:43] <kirkland> slangasek: ping me here with your 33649, when you get time
[16:43] <kirkland> slangasek: also, i wanted to touch base with you on ecryptfs-utils + auth-client-config's replacement
[16:53] <superm1> pitti, now that DKMS is in main, would you mind adding it as an installable item from DVDs?
[16:54] <pitti> superm1: hm, TBH I'd rather have it as a dependency of a driver we ship
[16:54] <pitti> superm1: e. g. I see nothing wrong with putting the nvidia and fglrx drivers onto the DVD
[16:54] <pitti> (and had always assumed they were already)
[16:55] <superm1> pitti, I'm not sure if they were previously, but yeah that would actually make life even simpler
[16:55] <pitti> those will pull in dkms
[16:55] <superm1> yup
[16:56] <jarson> pitti, well they violate kernel policy/license for a first, but yeah i won't start a religious war
[16:56] <superm1> jarson, the kernel modules for them aren't precompiled
[16:56] <pitti> jarson: we don't install them by default, just ship them
[16:57] <jarson> superm1, i see
[16:57] <pitti> so that won't change license situations
[16:58] <superm1> pitti, that just invoked a thought of mine.  with jockey now being split into a frontend/backend, wouldn't you be able to ask the user to restart the X session w/ the new module rather than rebooting too then?  (Possibly allowing the usage of these drivers in a live cd environment too then)
[16:58] <mkrufky> does ubuntu distribute all DKMS prerequisites by default?  ...or does a user have to actually install DKMS and its dependencies first before ebing able to install a DKMS package?
[16:59] <pitti> superm1: that's independent of the split, but yes, I should do that; please file a bug
[16:59] <pitti> superm1: sorry, have to leave now
[16:59] <superm1> pitti, no problem.
[16:59] <seb128> sjoerd: around?
[16:59] <sjoerd> yeah
[17:00] <seb128> sjoerd: you don't like msn and icq users? ;-)
[17:00] <sjoerd> pff
[17:00] <sjoerd> no, i don't want random connection managers in empathy's recommends
[17:00] <sjoerd> In Suggests is fine
[17:01] <seb128> we want msn working out of the box
[17:01] <seb128> and Suggests will not assure that
[17:01] <seb128> not sure why you think users don't use msn nowadays
[17:01] <sjoerd> ``we''
[17:01] <sjoerd> Define we here
[17:02] <seb128> anybody distributing empathy
[17:02] <seb128> GNOME, debian, ubuntu
[17:02] <sjoerd> people can install haze and/or butterfly if they want
[17:02] <sjoerd> i don't think it should be a recommend
[17:02] <seb128> sjoerd: I think having msn not working out of the box is a disfavor to users
[17:02] <sjoerd> but your free to do for ubuntu whatever you like
[17:03] <seb128> what is your issue with butterfly?
[17:03] <seb128> users will not read documentation or look at suggest
[17:03] <sjoerd> again, i just don't think we should list all possible CM's in Recommends
[17:03] <seb128> they will just complain about msn not working
[17:03] <seb128> me neither
[17:03] <seb128> I think we should have jabber and msn working out of the box though
[17:03] <seb128> icq too probably
[17:04] <seb128> recommends means "user probably want to use that but they can remove it if they want"
[17:04] <seb128> and I think it's fair to say most im users want to be able to connect to msn
[17:04] <seb128> no?
[17:05] <sjoerd> Recommends means, You can use this program without these packages, but it's really not recommended
[17:05] <sjoerd> That's not true for haze or butterfly
[17:05] <sjoerd> also -gabble and -salut are our two most featurefull and core CM's so if any are in recommends then it should be those
[17:05] <seb128> I don't discuss those
[17:06] <seb128> I just discuss how useful is an im for users if it doesn't do msn nowadays
[17:06] <seb128> but let's say we disagree, we will just modify the ubuntu package then, thanks
[17:06] <sjoerd> yeah, i'm entirely happy to disagree on this :)
[17:06] <dholbach> seb128: ubuntu-desktop can recommend them ;-)
[17:07]  * seb128 slaps dholbach
[17:07] <sjoerd> hehe
[17:08] <bigon> or telepathy-meta :p
[17:09] <bronson> Interesting...  Ubuntu's build uses regular quotes '_xmlEntity::checked', mine uses screwy quotes ‘_xmlEntity::checked’
[17:09] <bronson> *buildd's build
[17:10] <cjwatson> you're using a UTF-8 locale (as is the default). 'export LC_ALL=C' if you want the buildd's behaviour.
[17:10] <seb128> bigon: well, the thing "use synaptic to install empathy" case to give something useful
[17:10] <bronson> Will do.  I'm surprised buildd doesn't use the default.
[17:11] <seb128> bigon: and having only jabber working will not match this definition for our users
[17:16] <slangasek> kirkland: ok, I think I'm around now :)
[17:17] <kirkland> slangasek: cool
[17:17] <kirkland> slangasek: you wanna talk grub first?
[17:17] <slangasek> either way
[17:18] <kirkland> slangasek: okay, what's your feedback on 33649
[17:18] <tseliot> superm1: I have added the support for x-kit here: https://code.edge.launchpad.net/~albertomilone/mythbuntu/mythbuntu-common-xkit
[17:18] <slangasek> kirkland: so I saw your follow-up in 33649, and I think I'm concerned about the idea that a grub-install /dev/sda will auto-detect the RAID and automatically write to /dev/sdb at the same time
[17:18] <tseliot> superm1: I haven't tested it yet though. I'm sure you have your own test suite to do that.
[17:19] <slangasek> kirkland: this seems to fail at least-surprise, and seems to make it impossible for a user to upgrade grub on one device at a time for testing
[17:19] <kirkland> slangasek: what do you suggest the interface look like?
[17:19] <seb128> StevenK: why do you need to build the clutter-gtk documentation at build time?
[17:20] <slangasek> kirkland: shouldn't supporting grub-install /dev/md0 be enough, without changing the behavior of the other cases?
[17:22] <kirkland> slangasek: i could agree with that, with one extension....
[17:23] <kirkland> slangasek: I'd like grub-install /dev/sda and grub-install /dev/sdb to do the installation of grub to each of those disks individually...  currently, only one of the two exist in device.map, so grub-install /dev/sdb does NOT work
[17:24] <slangasek> why is that?
[17:24] <kirkland> slangasek: so i'd change it to relax the device.map check, if the disk is part of a raid device providing /boot
[17:25] <kirkland> slangasek: can you have both hd(0) /dev/sda and hd(0) /dev/sdb in device.map?
[17:25] <slangasek> I think you can?
[17:25] <kirkland> slangasek: hmm, i'll need to test that...
[17:25] <kirkland> slangasek: i assumed no
[17:25] <slangasek> since, contrary to sense, the mapping is from right to left
[17:26] <kirkland> slangasek: but that could be wrongage on my part
[17:27] <kirkland> slangasek: in any case, i accept your feedback...  grub-install /dev/sda doing the installation to sda and sdb is perhaps misleading (though my intentions are noble)
[17:27] <kirkland> slangasek: I'll fix that, but I'll also make absolutely sure in my testing that one can grub-install to /dev/md0 (hitting both sda and sdb), and individually to each device
[17:28] <slangasek> awesome
[17:28] <kirkland> slangasek: and perhaps what I need to fix is the device.map generation
[17:28] <kirkland> slangasek: to plop each disk into the device.amp
[17:28] <kirkland> slangasek: I'll have to do some hunting to figure out where that gets pooped out
[17:28] <slangasek> from an invocation of the grub shell by grub-install
[17:29] <cjwatson> kirkland: have I pointed you at lilo/README.raid1 yet? it offers several alternative modes
[17:29] <slangasek> $grub_shell --batch $no_floppy --device-map=$device_map <<EOF >$log_file
[17:29] <cjwatson> I wonder if an option to grub-install would be worthwhile
[17:29] <kirkland> cjwatson: you did, i read it, i'll refer back to it
[17:29] <cjwatson> ok, thanks
[17:30] <kirkland> slangasek: that says, "use it", not "generate it", no?
[17:30] <cjwatson> beyond that I'll defer to Steve, Classmate is EATING MY BRAIN just now
[17:30] <kirkland> cjwatson: ;-)
[17:30] <slangasek> kirkland: nope, that's how it generates it when it's not already present
[17:30] <kirkland> slangasek: cool, i'll check it out
[17:30] <kirkland> slangasek: this is well within scope, i'll update the patch today
[17:30] <kirkland> cjwatson: please holdoff on committing that patch
[17:30] <slangasek> great :)
[17:30] <asac> pitti: i have finished nspr/nss verification
[17:31] <kirkland> cjwatson: perhaps slangasek can sponsor it, once i get it steve-proof?
[17:31] <cjwatson> that would be fine by me
[17:31] <cjwatson> since he's already been through it
[17:31] <kirkland> slangasek: okay, item2, ecryptfs-utils
[17:31] <slangasek> indeed
[17:32] <kirkland> slangasek: i blogged about it this week, and a number of people have started testing it
[17:32] <kirkland> slangasek: most feedback positive, though a number of people have complained about the pam configuration part, why that can't be part of the package installation
[17:32] <slangasek> the ETA I gave pitti, who is also blocked on the PAM refactoring, is late next week
[17:32] <kirkland> slangasek: cool
[17:32] <kirkland> so not this alpha, but perhaps next?
[17:33] <slangasek> I would love to give you a head start, getting the config snippet ironed out so that it can be ready to go the same time pam itself lands
[17:33] <slangasek> yes, I want to have this all in and done by alpha-5
[17:33] <kirkland> slangasek: okay...  what can I do?
[17:34] <slangasek> you saw the sample config file format in the spec?
[17:34] <slangasek> is it self-explanatory, or do I need to improve the documentation any?
[17:34] <kirkland> slangasek: let me refresh my memory
[17:34]  * kirkland goes re-read the spec
[17:36] <slangasek> I do have a feature branch for this stuff at http://bzr.debian.org/bzr/pkg-pam/debian/features/config-framework/ ; though alioth's http bzr seems to not be working so well for people, so maybe I should copy that over to LP...
[17:37] <kirkland> slangasek: so would the configuration files i need live in ecryptfs-utils along with the pam module, or in this pam config framework package?
[17:37] <slangasek> kirkland: they would live in the same package that ships the pam module
[17:37] <kirkland> slangasek: oh, good
[17:38] <slangasek> that way, the maintainer scripts themselves can take care of registering/unregistering
[17:38] <slangasek> (that part isn't congealed quite yet, so I can't give you maintainer script samples)
[17:43] <kirkland> slangasek: okay, based on https://wiki.ubuntu.com/PAMConfigFrameworkSpec, i think there's still a bit of documentation missing
[17:43] <kirkland> slangasek:  http://pastebin.ubuntu.com/35591/
[17:44] <kirkland> slangasek: something like that ^ is what I'd naively create based on the spec
[17:44] <slangasek> kirkland: so you want the module added to each of /etc/pam.d/common-{auth,session,password}?
[17:44] <kirkland> slangasek: yep, "optional" in all 3 cases
[17:45] <kirkland> slangasek: I'm not sure about final, but it needs to be down below pam_unix
[17:45] <kirkland> slangasek: ie, after the password has been received
[17:46] <slangasek> kirkland: you're right, clearly my documentation is lacking :-)
[17:46] <kirkland> slangasek: well, as I said before, I'm happy to be a lab rat
[17:46] <slangasek> kirkland: the "final" means "this is the snippet to use /when/ we're stacked last"
[17:47] <slangasek> but all "additional" modules will always be stacked after all "primary" modules
[17:47] <slangasek> so that part doesn't matter at all
[17:47] <kirkland> slangasek: okay, so that should push me far enough down in the stack
[17:47] <kirkland> slangasek: i just need to make sure i don't get stuck after a module that would exit the stack prematurely (with success)
[17:48] <slangasek> right; that would be forbidden in this framework
[17:48] <kirkland> slangasek: i think that might have been how "requisite" was explained to me?
[17:48] <slangasek> actually, requisite will only short-circuit on failure
[17:48] <slangasek> not on success (that's "sufficient")
[17:48] <kirkland> slangasek: poor choice of words...  "how I understood requisite?"
[17:48] <kirkland> :-)
[17:48] <kirkland> slangasek: ah, okay....
[17:49] <kirkland> slangasek: good, i think we're okay
[17:49] <kirkland> slangasek: so how would you rewrite http://pastebin.ubuntu.com/ ?
[17:49] <kirkland> http://pastebin.ubuntu.com/35592/
[17:49]  * kirkland is not asking slangasek to re-implement a pastebin :-)
[17:50]  * kirkland is confident, though, that such and effort would involve a lot of 'sed' :-)
[17:50] <slangasek> http://pastebin.ubuntu.com/35594/
[17:51] <kirkland> slangasek: ah, i see...  yeah, that's logical
[17:51] <slangasek> heh, there are some things that even I won't use sed for ;)
[17:54] <kirkland> slangasek: thanks, that looks good to me, i'll save that off somewhere
[17:54] <slangasek> ok, cool
[17:54] <slangasek> btw, what do the auth and session bits of the module do when you *don't* pass the 'unwrap' option? :)
[17:55] <kirkland> slangasek: would have to look at the code, but my guess is that "unwrap" says "use the login passphrase to unwrap the keyfile and insert into the kernel keyring", and no "unwrap" probably just inserts the keyfile in the keyring as is
[17:56] <kirkland> slangasek: i can go read the code right quick, if it's important to you
[17:56] <slangasek> kirkland: ah - not that important, I was just wondering why whatever it does isn't the default, since that's apparently the only way we're using it :)
[17:56] <kirkland> slangasek: i just read the code, it is exactly as I explained
[17:57] <slangasek> ok :)
[17:57] <kirkland> if () ecryptfs_insert_wrapped_passphrase_into_keyring; else ecryptfs_add_passphrase_key_to_keyring;
[17:58] <kirkland> slangasek: probably defaulting to wrapped passphrases, and allowing a legacy "nounwrap" might be better, but meh
[17:59] <kirkland> slangasek: let me go hack on grub for a bit and I'll ping you when i have something FVT'd
[17:59] <kirkland> slangasek: thanks for your time!
[18:32] <bronson> Hm, I've verified that there are no substantial differences between my build and buildd's
[18:33] <bronson> Just noise like "+dpkg-buildpackage: source changed by Mike Hommey <glandium@debian.org>"
[18:33] <bronson> (at least, I think it's noise)
[18:33] <bronson> So, I'm off to install Intrepid and see what happens there.
[18:39] <Treenaks> Wow.. I just had to restart metacity, because it was updating /desktop/applications/window_manager a few times per second
[18:40] <Treenaks> (you wouldn't believe how slow that makes your machine feel :))
[19:02] <slangasek> E: base-files: needlessly-depends-on-awk depends
[19:02]  * slangasek shakes his head sadly at lintian
[19:28] <alex-weej_> something in pulseaudio is still gobbling memory and bringing my machine to a complete freeze
[19:28] <alex-weej_> if a sink vanishes, something just keeps on eating memory
[19:28] <alex-weej_> now what i don't get is that i have 2 GB of RAM and a 450MB swap partition
[19:28] <alex-weej_> my disk thrashed for a good ten minutes while i waited for the kernel to just kill it
[19:29] <alex-weej_> it doesn't take ten minutes to fill 450MB - what's happening here?
[19:29] <alex-weej_> and is there some way i can make linux kill processes that try to eat too much memory?
[19:29] <alex-weej_> and if there is, can we turn it on by default?
[19:30] <alex-weej_> having a computer be rendered useless (without magic sysrq keys) is very Windows 95.
[20:38] <mvo> quick poll: I would like to see a option to prevent gdm from starting (at the kernel/grub commandline). I added bug 256125 with patch. is that a) something that more people than just me want b) is "nogdm" a good option? or should it be "noxdm", "nox" instead?
[20:39] <cjwatson> other thoughts (not particularly implying these are better): textonly, textmode, text
[20:40] <cjwatson> casper supports a 'textonly' option although I don't think you should necessarily feel obliged to follow it
[20:40] <jcastro> mvo: as in, no gdm at all, it just goes right into the gnome session? or a text login?
[20:40] <cjwatson> on a) I think it would be a good thing to clearly support
[20:41] <mvo> jcastro: as in "gdm should not start", just text login
[20:41] <cjwatson> I think the positive formulation ("text", rather than "not <thing>") is possibly clearer and avoids the "nokdm", "noxdm", etc. thing
[20:42] <jcastro> that sounds sane to me
[20:42] <seb128> noxdm was mean no be a no?dm
[20:42] <seb128> meant
[20:42] <cjwatson> RH-based systems just do this with runlevels so we probably can't look to them for parallels
[20:42] <seb128> noxdm was meant to be a no?dm
[20:42] <cjwatson> seb128: I understand, although I'm not sure that that would be entirely clear to everyone
[20:43] <cjwatson> "nodm" if you want that, but it gets a bit cryptic
[20:43] <seb128> I think a text* would work fine too
[20:43] <cjwatson> for a different viewpoint, "nox" parallels a number of package names (we still have emacs-nox, don't we?)
[20:43] <mvo> I like "text"
[20:47] <mvo> text or textmode? I guess text is better (shorter)
[20:48] <pwnguin> what's the motivation for this?
[20:50] <pwnguin> i mean, we already have a root console thing from grub.
[20:50] <mvo> pwnguin: to be able to boot into the system faster for me and do some quick changes, I need it not very often, but often enough to miss that feature
[20:50] <cjwatson> I can think of all sorts of reasons. "gdm is busted, let me just get to text mode so I can get my work done." "I don't have much battery left and don't want to waste time starting a desktop, but I want to look at this file."
[20:50] <mvo> yeah, but it comes up without virtual consoles (just a single terminal) etc
[20:50] <cjwatson> pwnguin: grub recovery mode gives you an emergency system, not one you can work in
[20:50] <pwnguin> even faster! ;)
[20:50] <pwnguin> alrighty
[20:51] <cjwatson> it's not designed for people who just don't want X to start for whatever reason
[20:55] <pwnguin> mvo: does that patch work?
[20:55] <cjwatson> mvo: BTW the [ -e ] is unnecessary - just use grep -qs
[20:56] <mvo> pwnguin: I think it does
[20:56] <cjwatson>        -s, --no-messages
[20:56] <cjwatson>               Suppress  error  messages about nonexistent or unreadable files.
[20:56] <mvo> cjwatson: right, thanks
[20:56] <pwnguin> oh
[20:56] <pwnguin> duh
[20:57] <pwnguin> /proc/cmdline isnt the process's commandline
[20:57] <pwnguin> it's the kernels
[20:57] <mvo> yep
[20:57] <cjwatson> you're thinking of /proc/<number>/cmdline
[20:57] <pwnguin> yea
[20:57] <mvo> cjwatson: thanks, I will change that, use text and then just upload I think (if seb128 is happy with that)
[20:57] <pwnguin> i was wondering how "text" got from point a to point b... but i get it now =)
[20:58] <seb128> mvo: works for me
[21:04] <warren> What version of libcurl.so.X is in Ubuntu 8.04 LTS/
[21:04] <warren> ?
[21:04] <stgraber>   libcurl3 | 7.18.0-1ubuntu2 |         hardy | amd64, i386
[21:04] <warren> that contains libcurl.so.3?
[21:05] <warren> so you don't ship libcurl.so.4 anywhere?
[21:05] <cjwatson> FWIW http://archive.ubuntu.com/ubuntu/dists/hardy/Contents-i386.gz can answer these kinds of questions
[21:06] <cjwatson> full file list correlated with package names
[21:07] <cjwatson> libcurl3 does appear to ship libcurl.so.4 although I can't speak to the reasons
[21:07] <warren> oh
[21:07] <cjwatson> I can only assume something weird went on and would have to check the bug history
[21:08] <cjwatson> Debian has the same
[21:08] <cjwatson> libcurl.so.3 is a symlink to libcurl.so.4 (!)
[21:09] <slangasek> upstream bumped the soname
[21:09] <slangasek> and upstream was wrong
[21:09] <slangasek> so I twisted the maintainer's arm into keeping it unchanged in Debian :)
[21:11] <slangasek> so the unmodified upstream soname is shipped, for complete compatibility with third-party software, and the symlink is included with the package name unchanged, for compatibility with previous package builds
[21:11] <warren> cjwatson: what?!
[21:11] <warren> cjwatson: that sounds wrong.
[21:11] <cjwatson> well, it would be wrong if they were in fact ABI-incompatible
[21:11] <warren> you're serious, it is actually compatible?
[21:11] <slangasek> yep
[21:11] <warren> wow
[21:11] <warren> hm
[21:11] <slangasek> the only difference was an API deprecation
[21:12] <slangasek> which doesn't require rebuilds, curl properly handles deprecated options in its API to begin with
[21:12] <cjwatson> I remember this happening but wasn't following the byzantine mail threads at the time. :)
[21:13] <cjwatson> the reason the package name is libcurl3 rather than just libcurl4 Provides: libcurl3 is that Provides aren't allowed to satisfy versioned dependencies (a long-standing maybe-bug in dpkg)
[21:14] <cjwatson> so keeping the package name saved a lot of upgrade complexity, and simplified Debian testing maintenance
[21:14] <sistpoty> hm... I doubt virtual package versioned deps is a bug... how would you define the version if two packages provide a virtual package?
[21:14] <cjwatson> sistpoty: you'd have Provides: libcurl3 (= some-version). Please refer to the innumerable Debian mail discussions on the subject
[21:14] <slangasek> :)
[21:14] <sistpoty> ah... will do, thanks :)
[21:15] <cjwatson> I'm afraid I don't have links to hand but "versioned provides" would be the search term
[21:30] <alex-weej_> http://alex-weej.blogspot.com/2008/08/sucata-run-2008.html
[21:31] <alex-weej_> http://alex-weej.blogspot.com/2008/08/sucata-run-2008.html
[21:35] <cjwatson> alex-weej_: once is enough, thanks
[21:35] <alex-weej_> cjwatson: please don't make me have to /amsg that i didn't realise /amsg worked for all networks simultaneously in xchat
[21:35] <mvo> cjwatson: hm, I noticed that you made openssh-blacklist a suggestion now instead of a recommends. this might be a problem on some systems because the auto-remove now thinks that it can be remove. was that recommend dropped because of the CD size?
[21:38] <LaserJock> mvo: time to discuss moving DVDs again perhaps?
[21:38] <mvo> I send a mail to ubuntu-devel about possible solutions, not sure why it has not shown up yet :)
[21:39] <norsetto> mvo: it has
[21:39] <mvo> oh, then just not for me yet
[21:39]  * mvo kicks his mail provider
[21:39] <cjwatson> mvo: yes, I was aware it was a problem but your guess as to the reason is correct
[21:40] <mvo> ok, I think I could add some magic to the release upgrader so that is not a problem for people upgrading
[21:40] <cjwatson> mvo: that said, as I noted in the changelog, I suspect most affected systems will have gone through an upgrade cycle that caused them to install openssh-blacklist, by now
[21:40] <cjwatson> but it does of course weaken our protection somewhat
[21:40] <mvo> aha, ok, I misread the comment then
[21:40] <alex-weej_> before anyone else grills me for spam, sorry. "/amsg" works for all networks at once in X-Chat, CAUTION!
[21:40] <cjwatson> if we can ever manage to free up enough space, I would like to put it back in
[21:41] <cjwatson> unfortunately this doesn't seem that likely
[21:41] <mvo> I would be interessted in your opnion on the idea of having the CD build with --no-recommends and a ubiquity mode like for the missing language packs as part of the install where it offers to download more stuff
[21:50] <LaserJock> mvo: would that be an interim solution?
[21:50] <mvo> I guess so, until we move to bigger media (which I suppose we will have to at some point in the future
[21:51] <LaserJock> I tend to think it's a bad idea to have people install a different set of packages than if they just apt-get install ubuntu-desktop
[21:51] <mvo> because it affects only provides, the stuff would still be useful and a user with internet after the install would always use synaptic to install the missing pieces
[21:51] <LaserJock> if Recommends really is what it says it is, then we know basically everybody will want them
[21:52] <cjwatson> mvo: I posted to ubuntu-devel a while back about that saying I really wasn't keen on that approach
[21:52] <mvo> LaserJock: I agree, I was just bringing it up as a compromise idea, because to me the idea demoting a lot of the (useful) recommends to suggests is not ideal either
[21:52] <cjwatson> for much the reasons LaserJock says
[21:52] <LaserJock> mvo: it's certainly a lot better than dropping Recommends altogether
[21:52] <cjwatson> I don't see how that would help this case at all though
[21:53] <mvo> cjwatson: oh, I think I missed that (or don't remember it). if that has been discussed before, I'm sorry to bring it up again
[21:53] <cjwatson> the problem is not that recommends is included (and actually recommends makes this situation a lot easier because lots of people get annoyed if I make openssh-client have a hard dependency on openssh-blacklist) - it's that the CDs are too damn full :)
[21:53] <mvo> cjwatson: the case with the openssh-blacklist? because it would still be a recommends, the auto-remove would leave it alone at least :)
[21:54] <cjwatson> really, I want it on the CD
[21:54]  * mvo nods
[21:54] <cjwatson> I don't want it downloaded from the network maybe if the moon is in the right phase :)
[21:54] <cjwatson> our installs are a bit too nondeterministic for my taste already, and we get quite a lot of bugs from those places
[21:54] <cjwatson> hence the work in hardy to try to make language pack installation more robust
[21:55] <cjwatson> perhaps a different compromise would be to allow indicating that *specific* Recommends should not be included during CD building
[21:55] <cjwatson> I don't like doing it across the board, but I can see that it could make sense in certain cases
[21:56] <cjwatson> we do have a blacklist feature in germinate already, but it's a very crude hammer
[21:56] <cjwatson> I'd have to put some thought into something more fine-grained
[21:56] <cjwatson> mvo: would that be acceptable, do you think?
[21:56] <mvo> I believe it would be a bit less problematic than the language packs, because all the information what is needed (what reocmmends are missing) is available for libapt itself, whereas with the languages the policy is not in libapt but in language-selector. but I don't want to press the point, it was just a idea that I wanted feedback on
[21:57] <cjwatson> well, the problem is different results from initial installation depending on whether you have Internet access or not, and depending on whether that Internet access is available during installation
[21:57] <LaserJock> we could drop OO.o to it's own addon CD ;-)
[21:57] <seb128> cjwatson: if you really want something on the CD seed it as we did until now?
[21:57] <cjwatson> it multiplies the test matrix by at least three
[21:57] <cjwatson> seb128: I know how to get things onto the CD :-) but it's too big
[21:57] <cjwatson> hence why I took it off
[21:57] <mvo> cjwatson: a fine-grained blacklist sounds like a good idea as well, so eg openssh-blacklist would still be a recommend but not on the CD?
[21:57] <cjwatson> mvo: yeah, something like that
[21:58] <cjwatson> I'm still not entirely content with it but it could work and it might address some of the complaints about recommends-by-default
[21:58] <seb128> I mean, better to not use recommends to build CD and seed things we do that dropping valid recommends just to accomodate the CD space
[21:58] <cjwatson> seb128: both of those two extremes have problems, so I'm suggesting a compromise between those two
[21:59] <cjwatson> I'm suggesting putting them back to Recommends, but having a way to annotate *some* Recommends as not to be used for CD building
[21:59] <seb128> that would be nice too indeed
[21:59] <cjwatson> I do not think it's appropriate to omit Recommends from CD building across the board; if they really are valid Recommends, then the CD is the most usual case and the recommended package should be found together with the recommending package
[21:59] <cjwatson> the language of policy practically mandates that valid recommends be included on CDs
[22:00] <cjwatson> but we could perhaps make some exceptions
[22:00] <seb128> well CD where full before we started installing recommends
[22:00] <seb128> so it's a wonder that we manage to keep any of those new recommends
[22:00] <cjwatson> sure, I understand the problems
[22:00] <cjwatson> although I would say that recommends are not nearly so useless now as you make out
[22:00] <seb128> my impression on the GNOME packages is that we dropped everything which was not on the CD to Suggests to accomodate the CDs
[22:01] <seb128> oh I don't say they are useless
[22:01] <seb128> but I'm not that happy to have to drop valid recommends, your alternative solution would solve that too though
[22:01] <cjwatson> they're still very useful in the areas of the archive not on the CD, or not in the desktop edition, and we've been able to drop some incorrect Depends to Recommends as a result of recommends-by-default
[22:01] <sistpoty> oh, mvo: could you take a look at bug #229489... I'm still puzzled why this situation could have happened in the first place (maybe some partial-upgrade magic?)?
[22:01] <cjwatson> I would say you have probably been worst hit by the problems
[22:01] <seb128> probably ;-)
[22:02] <cjwatson> anyway, I won't be able to think about it until week-after-next, but will do so then
[22:02] <seb128> I think a featurefull desktop installation simply doesn't fit on a CD nowadays
[22:02] <seb128> which is the real issue
[22:02] <mvo> sistpoty: yes, looking
[22:02] <cjwatson> I think people have been saying that since warty
[22:02] <sistpoty> thanks mvo
[22:02] <cjwatson> and yet we always manage to do it and people love the fact that we do
[22:02] <seb128> right, but difficulties increase every cycle
[22:03] <cjwatson> I know, but I really think they are worth it
[22:03] <seb128> right but at some price
[22:03] <cjwatson> and the pressure is good for us in some ways
[22:03] <LaserJock> well
[22:03] <cjwatson> forcing us to keep installation image size down also encourages us to keep installed-system size down, which is good for users without huge systems
[22:03] <seb128> we discussed it with pitti some days ago, I think it would be nice to have a "limited" desktop install on CD and a featurefull image on 1Gb usb key images for example
[22:04] <cjwatson> mm, when we have double the available resource on cdimage maybe we can think about that ;-)
[22:04] <cjwatson> and double the space on releases.u.c mirrors
[22:04] <ScottK> Heya LaserJock: There's going to be a matplotlib upload in Debian today, so we probably ought to catch morph on #debian-python if we've got anything they ought to get in Lenny.
[22:05] <LaserJock> perhaps gradually more attention will be paid to the DVD?
[22:05] <LaserJock> the 1 CD OS is still a real nice thing to have
[22:05] <seb128> DVD is too big to download
[22:05] <LaserJock> people do it all the time ...
[22:05] <cjwatson> I expect so, but I don't think we can ditch the CD
[22:05] <seb128> 1Gb usb key would not be much bigger and would be nice though
[22:05] <cjwatson> *some* people do it all the time
[22:05] <cjwatson> most people do not
[22:05] <LaserJock> well, in terms of distros
[22:05] <LaserJock> they went DVD
[22:05] <johanbr> How about 2 cd's ?
[22:06] <LaserJock> and are now going back to DVD + LiveCDs
[22:06] <cjwatson> LaserJock: and look how much more popular Ubuntu is
[22:06] <LaserJock> we're just kind of the opposite
[22:06] <LaserJock> I'm saying that perhaps the best is to have good offerings of both CD and DVD
[22:06] <cjwatson> johanbr: going from install CD + live CD to install/live combination CD slashed Canonical's shipit costs by a factor of three
[22:06] <cjwatson> johanbr: so I guess it depends how long you'd like shipit to continue ...
[22:07] <cjwatson> it turns out that single-CD sleeves are significantly cheaper to manufacture and ship
[22:07] <cjwatson> DVDs are about triple the cost of CDs, I think, last I checked
[22:07] <LaserJock> well,  you wouldn't have to ship DVDs
[22:08] <LaserJock> but a download would be nice
[22:08] <cjwatson> LaserJock: I know, just for information
[22:08] <cjwatson> s/would be/is/ surely, since we do provide it
[22:08] <LaserJock> the USB stick thing is intriguing
[22:08] <cjwatson> seb128: the problem with a separate 1GB USB image is that as long as we still support the CD that means we've gone from 700MB to 1700MB for each desktop edition
[22:08] <LaserJock> I'm not sure how many machines boot easily from USB
[22:08] <cjwatson> seb128: which blows some of our current resource constraints out of the water
[22:09] <seb128> cjwatson: right, there is just no easy solution to the problem
[22:09] <cjwatson> in a world of unlimited resource and bandwidth I'd agree with you
[22:09] <seb128> I guess I would be fine with what you suggest
[22:09] <seb128> a way to list recommends which should not be on the CD
[22:09] <cjwatson> but that's why I'm proposing the approach of automatically generating the USB image from the CD image (which Evan's working on) as a way to get us started on USB image distribution
[22:09] <seb128> so we would not have to drop valid recommends
[22:09] <cjwatson> it's just a whole lot more practical right now
[22:09] <seb128> right, agreed
[22:10] <Chocobo> Hi all.. where would I go or what do I do to build the current "tightvnc" package?   I am a little confused by the debian/ubuntu build process.
[22:10] <cjwatson> syntax suggestions for the seeds welcomed at cjwatson@ubuntu.com ;-)
[22:10] <cjwatson> I think I'm running out of punctuation characters
[22:10] <cjwatson> Chocobo: sudo apt-get install fakeroot devscripts (you only need to do this bit once); sudo apt-get build-dep tightvnc; apt-get source tightvnc; cd tightvnc-*; debuild -b
[22:11] <cjwatson> if you want a different package to what apt-get source gives you, then download the source package separately and use dpkg-source -x foo.dsc to unpack it
[22:12] <Chocobo> Wow, thanks cjwatson.  That is much more straightforward than what I was reading about (pbuilder)
[22:13] <cjwatson> pbuilder is for when you feel your normal system won't be suitable for building it for one reason or another, and want to guarantee a clean build environment
[22:13] <cjwatson> if you routinely install lots of packages from different sources, then you might find your normal system will fail to build a lot of things
[22:13] <cjwatson> particularly if you mix releases a lot
[22:14] <Chocobo> Ahh, alright.  Is there a document that I should read so that I don't need to be a bother in here?
[22:14] <cjwatson> so pbuilder will work in adverse circumstances, but you can just as well build in your normal system if it works
[22:14] <Chocobo> I see, it is sort of like a sandbox or something similar.
[22:15] <cjwatson> err, there's almost certainly something on the wiki (maybe something better-written on help.ubuntu.com/community/) but the "you have to use pbuilder for everything" meme is quite prevalent so I'm not offhand sure where
[22:15] <cjwatson> for various reasons it's not practical for me to look it up right now
[22:16] <mvo> sistpoty: the problem seems to start with "ghc-pkg: cannot find package gtkglext-0.9.12^M" in th prerm, the new prerm is empty, might that already be the problem? some sort of transiton in how the haskel registration is done (sorry, I have no idea about ghc)
[22:17] <cjwatson> Chocobo: apt-get and debuild have good man pages though
[22:17] <mvo> sistpoty: oh, I'm reading more of the report now, that looks more complicated
[22:18] <sistpoty> mvo: yes, I've only partially looked through the logs, and I can't seem to find the big picture of what is wrong (apart from that the new maintainer scripts don't support rollback)
[22:18] <Chocobo> Wow, alright.  Thanks cjwatson.  Unfortunately the tightvnc build failed... so it looks like perhaps I need to use pbuilder.   ...  it is complaining about all the /usr/include/X11/* files.
[22:22] <cjwatson> Chocobo: I don't use pbuilder often, but I think that 'sudo pbuilder create --distribution=hardy' (once only) and then 'apt-get source tightvnc; sudo pbuilder --build tightvnc_*.dsc' should be about it
[22:22] <cjwatson> that's just from its man page thouygh
[22:27] <Chocobo> Thanks for the help cjwatson.  the first method is working on a 2nd computer, so I think we will go with that :)
[22:34] <cjwatson> Chocobo: there's also https://wiki.ubuntu.com/PackagingGuide, which goes through this stuff, though you may have seen it already
[22:43] <mvo> cjwatson: if you are still around, when you build the cdrom without the packages, was there a packages.gz on it?
[22:44] <mvo> cjwatson: is the test-image you used available somewhere?
[22:46] <cjwatson> mvo: I literally just took an alternate CD, ran find -name Packages | xargs rm on it, and re-mkisofsed it
[22:46] <cjwatson> mkisofs -r -V 'Ubuntu 8.10 i386' -o intrepid-alternate-i386-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new-i386
[22:46] <mvo> cjwatson: ok, thanks
[22:49] <cjwatson> (so yes, there was a Packages.gz on it)
[22:49] <mvo> cjwatson: yeah, thanks, I think I have the info I needed
[23:09] <mvo> cjwatson: I should have a patch that makes the "no Package file" case work I think (for when you come back :)
[23:32] <wasabi> jelmer: welcoem to the team. it's sort of dead though.
[23:32] <jelmer> wasabi, :-(
[23:32] <wasabi> you may revive it. :0
[23:32] <wasabi> nobody who was in it had any time to contribute...
[23:32] <wasabi> and it never generated interest from canonical (which was my intention)
[23:32] <slangasek> "the team"?
[23:33] <wasabi> slangasek: ubuntu-directory
[23:33] <slangasek> ah
[23:38] <kirkland> slangasek: The drive (hd0) is defined multiple times in the device map /boot/grub/device.map
[23:38] <kirkland> slangasek: so that's not gonna work...  i'm going to need a special case, i think for md
[23:38] <kirkland> slangasek: i'm nearly done testing it
[23:39] <slangasek> kirkland: ok
[23:49]  * mcasadevall_ is stuck in hell :-)
[23:50] <cjwatson> mcasadevall_: three bridge players with packs of cards?
[23:50] <mcasadevall_> hey StevenK
[23:51] <elmo> cjwatson: you know, 8 UDSes in and we still haven't managed a game of bridge
[23:51] <elmo> (unless I just missed it/wasn't invited ;-)
[23:51] <cjwatson> I tried at the sprint but only managed me+lifeless
[23:51] <cjwatson> so we ended up playing two-handed 500 instead
[23:52] <mcasadevall_> cjwatson, worse, I'm trapped at JFK airport terminal six for two more hours with just enough bandwidth to not have freenode time out
[23:52] <cjwatson> maybe I should try at the distro managers sprint week after next
[23:52] <cjwatson> mcasadevall_: you get to practice your morse
[23:52] <mcasadevall_> Although NCommander will tell you otherwise :-P
[23:55] <mcasadevall_> cjwatson, ... . -. -.. -- --- .-. . -... .- -. -.. -..- .. -.. - ....
[23:55] <azeem> mcasadevall_: apparently you still have enough bandwidth to top-post on debian-devel :P
[23:56] <mcasadevall_> azeem, top post?
[23:56] <mcasadevall_> azeem, I sent that from my blackberry ;-)
[23:56] <mcasadevall_> they aren't the best in push email for nothing
[23:57] <cjwatson> mcasadevall_: .. -... . - - .... .- - ... .-- .... .- - -.-- --- ..- ... .- -.-- - --- .- .-.. .-.. - .... . -... --- -.-- ... ...-.-
[23:59] <NCommander> cjwatson, -.-- --- ..- .-.   -- --- - .... . .-.