[12:31] <Thib_> hello, it was suggested I ask this non-support question here rather than in #ubuntu
[12:32] <Thib_> I upgraded from Dapper to Edgy and no longer have a disk management tool out of the box; in Dapper it used to be System > Administration > Tool. Was that functionality removed from the default Edgy menu?
[12:36] <cge> Thib_: If you don't get an answer, you can also ask on the mailing lists, which seem to be the best place to ask nontrivial questions.
[12:39] <lloydinho> Thib_: as far as I understand it, the reason that the Disks tool has been removed is because Upstream (ie. GNOME) no longer maintains that function.
[12:39] <lloydinho> So it has been removed from all of GNOME with 2.16 rather than just from Ubuntu.
[12:39] <Thib_> lloydinho: oh so it *has* been removed.
[12:39] <Thib_> lloydinho: okay that makes perfect sense.
[12:40] <lloydinho> Well, it still sucks to be without a graphical tool for disk management, but I suppose we'll have to manage for now.
[12:40] <Thib_> just to clarify, I didn't mean to imply that was good or bad. Just wanted to know.
[12:40] <lloydinho> :-)
[12:40] <cge> We do have gparted in main.
[12:40] <Thib_> right, I like a graphical tool too.
[12:40] <lloydinho> cge: True. But it isn't as easily discoverable for new users.
[12:41] <Thib_> but since I'm upgrading several machines from Dapper to Edgy and they all "succeeded" i.e. failed slightly in subtly different ways, I'm just trying to determine what is intended changes and what isn't :-)
[12:41] <cge> lloydinho: Yes, it would have to be installed by default.
[12:41] <jordi> lloydinho: afaik there's something new that replaces it?
[12:41] <Thib_> I'm happy with gparted.
[12:42] <lloydinho> jordi, not in the standard installation, as far as I can tell.
[12:42] <cge> Thib_: As you can see, getting answers to questions like that here is much calmer than in #ubuntu.
[12:42] <lloydinho> But when you install Gparted it slots right into the System -> Administration menu.
[12:43] <Thib_> cge: it is :-) I just didn't realize this place existed.
[12:43] <cge> lloydinho: It appears that gparted is installed by default in the LiveCD, but not in the default installation.
[12:43] <Thib_> lloydinho: it does? mine didn't, or maybe I need to log out and back in
[12:44] <lloydinho> Thib_: probably.
[12:44] <cge> Thib_: It does. 
[12:44] <cge> Thib_: You could also try killing the panel.
[12:44] <Thib_> killing the panel?
[12:45] <Thib_> lol I've never thought about doing that :-)
[12:45] <Thib_> does it, like, come back to life?
[12:45] <lloydinho> Thib_: killall gnome-panel
[12:45] <cge> Thib_: gnome-session brings it back to life, yes.
[12:45] <Thib_> aha!
[12:45] <Thib_> yes, now the icon is there
[12:45] <Thib_> brilliant
[12:46] <Thib_> well I learned two things today, that's great
[12:46] <Thib_> many thanks, cge and lloydinho 
[12:46] <lloydinho> Oh, and by the way: It's okay to come in here and ask a few questions when there's little developer activity, but generally the core-devs really like to keep the noise down in here, so they'll send you back #ubuntu
[12:46] <lloydinho> _to:_ #ubuntu
[12:47] <cge> lloydinho: No one answers questions like that #ubuntu, unfortunately.
[12:47] <lloydinho> Hm. That is unfortunate. Maybe we should get Seveas to teach Ubotu about it. :-)
[12:48] <cge> We need an #ubuntu-nontrivial channel.
[12:48] <lloydinho> jeez, there's almost a thousand users in #ubuntu.
[12:49] <cge> lloydinho: And it moves so fast that nontrivial questions become lost.
[12:49] <Thib_> lol
[12:49] <Thib_> well yeah
[12:49] <lloydinho> Yes. Problem would be that everybody will demand Special Attention (TM) and will go straight to the -nontrivial channel.
[12:49] <Thib_> it's okay though, I know when I'm asking something out of the ordinary and I don't expect immediate technical answers, especially in a busy channel.
[12:50] <lloydinho> (at least that was the last explanation I heard).
[12:50] <cge> lloydinho: Yes, that's probably true.
[12:51] <cge> lloydinho: I'll have to think about ways to have a channel like that without having that problem.
[12:52] <lloydinho> cge: Sounds like a good idea. If you come up with something good, write an email to the sounder mailing list or try to put it in a spec for discussion.
[12:52] <cge> lloydinho: I will.
[12:54] <cge> By the way, does anyone know if the official edgy cds that are being sold are pressed? None of the vendors say anything about the actual cds, and since they all sell burned CDs for nearly everything else, they probably need to mention it.
[12:55] <cge> Otherwise very few people are going to want to buy what appears to be a CD-R with edgy on it.
[12:57] <lloydinho> cge: There will be official Ubuntu DVDs that you can buy off amazon and such, I think.
[12:58] <lloydinho> cge: there's a list of authorized vendors as well: http://www.ubuntu.com/products/GetUbuntu#buycurrent
[12:58] <cge> lloydinho: There are places linked from ubuntu.com as selling "Official Ubuntu Edgy CDs", but since those places mainly sell burned CDs of linux distributions, it makes it look like that is what they are selling, even though I think they are selling pressed CDs from Canonical.
[12:59] <lloydinho> cge: oh. Well, I guess that would be their own fault, really.
[12:59] <cge> lloydinho: Ok, I'll try contacting them about it then.
[01:00] <lloydinho> Cool, Goodnight.
[02:31] <kro> When does feisty start?  Whats the best way to keep up with development.  Is there a specific fiesty irc channel/mailing list/etc?
[02:56] <Lathiat> kro: after the development meeting (which is from the 5th to the 10th of november)
[02:56] <Lathiat> kro: this channel the ubuntu-devel mailing lis tis the best place to keep an eye on i guess
[02:56] <giri> I have heard that there was/is some discussion here on ndiswrapper
[02:57] <giri> I am developer of ndiswrapper
[02:57] <giri> wondering if anyone wants to let me know any decisions / feedback / comments
[03:05] <kro> Lathiat: thanks
[03:09] <Lathiat> giri: Doesnt' seem to be too many people around atm, might be best to try another time
[03:09] <Lathiat> I think everybody is celebrating or something :)
[03:09] <giri> Lathiat: heh; ok, thanks
[03:10] <giri> later
[03:43] <soothsay> Should gnome-power-manager run with superuser priviliges?
[03:43] <jdub> soothsay: no, it is a desktop service.
[03:45] <soothsay> Okay, how can I quickly check if it is operating reasonably correctly? Suspend works for me when running the script in /etc/acpid but not through the 'logout' menu. I'm doing gnome-power-manager --verbose: Should it log suspend attempts? AC disconnection?
[03:51] <soothsay> Never mind, was missing --no-daemon
[04:24] <jdub> hrm. 64% into edgy install, access to the CD stops.
[04:24] <jdub> ultimately freezing the entire thing.
[04:54] <maxflax> Whats the deal with ubuntu and alsa-driver 1.0.13 .. ?
[05:00] <crimsun> maxflax: as I've stated in #alsa, if your issues are exhibited in upstream's 1.0.13, it's not Ubuntu's problem
[05:24] <robertj>  is there a way to list all packages that place files in /etc/init.d, even those not instaleld?
[05:26] <neuralis> robertj: apt-get install apt-file; apt-file update; apt-file search init.d
[05:26] <robertj> sweet!
[05:27] <neuralis> robertj: apt-file search etc/init.d if you want to restrict to /etc/init.d, instead of any init.d directory, clearly.
[07:39] <naxx> ||.Req.:||  Help on building a debian package |pm me pls ;)||
[07:39] <Burgundavia> naxx: ask in #ubuntu-motu
[07:40] <naxx> thx
[07:40] <naxx> i'll try
[07:41] <Burgundavia> fabbione: thanks for teh logging
[07:46] <fabbione> Burgundavia: ?
[07:47] <ajmitch> #u-directory channel logging
[07:47] <Burgundavia> yep
[07:48] <fabbione> ah ok
[07:48] <fabbione> mp
[07:48] <fabbione> np
[08:30] <ajmitch> hey pitti!
[08:31] <BHSPitMonkey> hey ajmitch !
[08:32] <ajmitch> hi
[08:32] <pitti> Good morning
[08:32] <pitti> hey ajmitch, how are you?
[08:34] <ajmitch> good, how are you?
[08:34] <mnepton> LARGE AND IN CHARGE!
[08:35] <mnepton> *ahem*
[08:35] <ajmitch> ready for UDS? :)
[08:35] <mnepton> sorry.
[08:35] <ajmitch> hehe
[08:35] <ajmitch> pitti: you don't mind if I start stealing merges of stuff I need? :)
[08:35] <ajmitch> since you touched samba last
[08:35] <pitti> ajmitch: BEWARE!!!1!
[08:36] <pitti> ajmitch: of course I don't, go ahead ;)
[08:36] <pitti> ajmitch: I'd just appreciate a quick ping for every package to avoid duplicate work
[08:37] <ajmitch> pitti: yeah, that's why I'm asking now
[08:38] <pitti> hi slomo_ 
[08:39] <ajmitch> besides, I have to wait until we hear that it's ok to play in the feisty sandpit
[08:40] <fabbione> ajmitch: the toolchain is not there yet
[08:40] <ajmitch> I know
[08:40] <fabbione> but you can still merge and make sure it works
[08:40] <fabbione> once the toolchain is unleashed you can rebuild and retest
[08:40] <ajmitch> I've got enough things to do before I upload
[08:43] <BHSPitMonkey> when do we see a feisty pre-release, darnit!!!
[08:44] <tfheen> BHSPitMonkey: first week of december or thereabouts. 
[08:44] <ajmitch> tfheen: you're RM for feisty?
[08:44] <BHSPitMonkey> seriously? that's actually sooner than I thought.
[08:44] <DaGame> wana fite
[08:44] <BHSPitMonkey> and I was being facetious before 
[08:45] <tfheen> BHSPitMonkey: I'll at least take a look whether it's feasible.
[08:45] <BHSPitMonkey> I'm pretty happy with edgy, although I do have some issues (and I didn't upgrade!)
[08:46] <tfheen> ajmitch: we haven't really discussed it, but both mdz and the rest of the release team seems to be happy with what I did for edgy and it was fun, so I think I'll RM feisty too, yes.
[08:46] <BHSPitMonkey> tfheen, are there even goals set out?
[08:46] <tfheen> BHSPitMonkey: specs have been proposed, but not drafted and approved.
[08:47] <BHSPitMonkey> a lot of the concept of planning features specifically for OS+1 confuses me... it seems like just intentionally holding back a feature
[08:47] <tfheen> BHSPitMonkey: it's only six months until feisty is released.  That's not very much time.
[08:47] <BHSPitMonkey> in order to pretty up a new release
[08:47] <ajmitch> it's often needed in order to have time to get it ready 
[08:48] <tfheen> so it makes sense to plan which direction we want features to take over longer periods of time than just the next six months.
[08:48] <ajmitch> some of our specs may only be implemented in 12-18 months
[08:49] <BHSPitMonkey> no, it's like... "We need this, and this, and this improved! But as soon as it's been coded, let it sit on the shelf until the +1 release, so the release looks really big!"
[08:49] <tfheen> stuff generally don't get implemented and then shelved
[08:49] <ajmitch> what features do you think were held back?
[08:49] <BHSPitMonkey> why not have improvements in constant supply, that's just my dilemma 
[08:50] <ajmitch> anything that's not ready by feature freeze doesn't go in - there has to be tiem to stabilise a release
[08:50] <BHSPitMonkey> and I'm not trying to argue or dissent or anything, I'm saying I don't really understand how these decisions work
[08:50] <tfheen> generally it comes down to whether we have time to implement stuff properly.
[08:50] <tfheen> it's much better to have one well-working feature than three mostly-broken ones
[08:51] <BHSPitMonkey> ok, well how does everything happen to be ready at the time of release
[08:52] <mnepton> define "ready" >:)
[08:52] <BHSPitMonkey> why didn't tomboy or usplash (for vague example) get floated into dapper when they were done
[08:52] <highvoltage> tfheen: is it still a possibility that there might be a permanent 'unstable' release for ubuntu at some stage?
[08:52] <BHSPitMonkey> mnepton, I'm not strong enough to withstand you tonight :S
[08:52] <BHSPitMonkey> it's late
[08:52] <tfheen> BHSPitMonkey: usplash was in dapper.
[08:52] <mnepton> BHSPitMonkey: you can install Tomboy on Dapper, it's just not a package in the defaults.
[08:52] <BHSPitMonkey> tfheen, poorly stated- I meant the "purdy" usplash
[08:53] <tfheen> BHSPitMonkey: and tomboy is in main in dapper too.  It just wasn't part of the default install.
[08:53] <tfheen> BHSPitMonkey: because that wasn't coded until two months after dapper released?
[08:54] <tfheen> and to answer the "how is everything ready" question.  Well, if it's not, we should already have dropped it earlier. :-)
[08:54] <highvoltage> 5~
[09:01] <BHSPitMonkey_> sorry, my ISP gave out on me about 5 minutes ago
[09:01] <BHSPitMonkey_> IP rotation
[09:03] <BHSPitMonkey_> my point before was, why aren't things like those "updates" to dapper? because this way, edgy can look like a bigger deal, right?
[09:04] <fabbione> BHSPitMonkey: dapper has been released as stable and therefor it gets ONLY security or major bug fixes
[09:04] <fabbione> by policy
[09:04] <fabbione> new crack -> new release
[09:06] <BHSPitMonkey_> gotcha
[09:09] <dholbach> good morning
[09:09] <ajmitch> morning daniel :)
[09:09] <dholbach> hey Andrew
[09:09] <ajmitch> excited about feisty? :)
[09:10] <dholbach> YEAH :-)
[09:10] <ajmitch> EXCELLENT!
[09:11] <mvo> hey dholbach!
[09:11] <dholbach> heya mvo
[09:11] <ajmitch> hey mvo 
[09:11] <mvo> hey ajmitch!
[09:32] <pygi> phanatic: ping :P
[10:09] <pitti> hi mdz
[10:10] <mdz> morning
[10:12] <highvoltage> morning mdz 
[10:15] <ajmitch> morning mdz 
[10:24] <cjwatson> BHSPitMonkey: if it helps to understand, note that the new usplash required a bunch of changes in other packages, including a very complicated set of changes in the installer
[10:24] <cbx33> hi guys what's this about Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed
[10:24] <cjwatson> BHSPitMonkey: even if we did do updates of that kind to dapper, this wasn't just one package that could have been dropped in
[10:30] <gebruiker> I created a init script that changes the name of the ubuntu hostname, when should this be executed? At runlevel rcS?
[10:32] <cjwatson> gebruiker: why not just change the file /etc/hostname?
[10:32] <fabbione> cjwatson: it depends when it's executed. you also want /proc/sys/kernel/hostname
[10:33] <cjwatson> /etc/init.d/hostname.sh already reads /etc/hostname and sets the hostname according to that
[10:33] <cjwatson> there is no need for another init script
[10:33] <fabbione> oh right. there is that one too
[10:33] <gebruiker> cjwatson, We are selling ubuntu desktops, one of them contains 3 pc's and a printer, two of them ubuntu and 1 of them windows. We are cloning the hd images. Two computers can't have the same hostname on a lan
[10:34] <cjwatson> gebruiker: set /etc/hostname after cloning
[10:34] <cjwatson> gebruiker: that cannot possibly be harder than adding an init script
[10:34] <gebruiker> I'm able to add a init script, however, I was wondering wheiter it should be added at system level or elsewhere.
[10:35] <cjwatson> there's no point in adding an init script
[10:35] <cjwatson> if you need to set the hostname dynamically, then either edit /etc/init.d/hostname.sh or use DHCP
[10:35] <cjwatson> (there's a "host-name" option in DHCP - it's only honoured if the hostname is not set though)
[10:36] <gebruiker> the script that changes the hostname, invokes  oem-config-prepare. So it has to done correctly.
[10:37] <cjwatson> oem-config-prepare is supposed to be run before shipping to the end user, not after - I can't think why it would need to be run from an init script
[10:38] <gebruiker> the computer is not installed with just ubuntu, it has additional software to.
[10:38] <gebruiker> and pre-installed printer configurations etc.. etc..
[10:54] <pitti> fabbione: FYI, glibc 2.5 is rocking fine here :)
[10:57] <fabbione> pitti: what arch?
[10:57] <pitti> fabbione: amd64
[10:58] <fabbione> pitti: ok. 
[10:58] <fabbione> make sure that you will reinstall them once feisty is open
[10:58] <pitti> sure
[10:59] <giskard> hello
[11:36] <ogra> mvo, do we have a sCIM team in LP to assign bugs to ?
[11:36] <ogra> *SCIM
[11:37] <mvo> ogra: only cjk-testers
[11:37] <mvo> ogra: what bug is it?
[11:37] <ogra> bug 37711
[11:37] <Ubugtu> Malone bug 37711 in scim-qtimm "Qt/SCIM broken (Cannot enter numbers in to spinbox widget)" [High,Confirmed]  http://launchpad.net/bugs/37711
[11:37] <ogra> it evolved from being a scribus bug to becoming a SCIM one ...
[11:39] <sladen> *something* is broken with SCIM and Qt, just that we don't know who/how to debug it
[11:40] <ogra> sladen, right, but i'm not doing anything with SCIM at all ... thats why i wanted to reassign it to the appropriate people 
[11:45] <mvo> hm, 8 duplicates :/
[11:47] <dholbach> it might make sense to rename the cjk-testers into a cjk-hackers team and attract a different set of people also :)
[11:54] <ogra> dholbach, good idea
[11:55] <pitti> hi tkamppeter 
[11:55] <tkamppeter> hi pitti
[12:21] <dholbach> Gloubiboulga: you heard of the xubuntu-derived livecd? http://www.golem.de/0610/48635.html ?
[12:22] <Gloubiboulga> dholbach, yes, that's really good news for the xubuntu team :)
[12:23] <highvoltage> *very* good :)
[12:23] <highvoltage> yay! free hugs!
[12:23] <Gloubiboulga> hehe
[12:23] <Gloubiboulga> I'll give it a try this week
[12:25] <jsgotangco> good question
[12:32] <infinity> highvoltage: Because they have taste.
[12:32] <Fujitsu> :O
[12:32] <doko> seb128, dholbach: (process:7014): Gdk-CRITICAL **: gdk_screen_get_font_options: assertion `GDK_IS_SCREEN (screen)' failed
[12:32] <doko> are these just warnings?
[12:32] <infinity> highvoltage: Alternately, "an MTA flamewar on #-devel is pointless, please don't"
[12:32] <Fujitsu> I can't believe there are exim4-lovers in Melbourne.
[12:33] <seb128> doko: looks like a program bug
[12:33] <highvoltage> infinity: apologies, I had no intention of starting a flamewar, I think my little joke needed a smiley face. I have no grudges against exim4
[12:34] <sladen> Gloubiboulga: is that the offical Xfce livecd?
[12:34] <sladen> Gloubiboulga: is there anything in English to link to?
[12:35] <Gloubiboulga> sladen, http://www.xfld.com/ 
[12:35] <Gloubiboulga> the Xfce devs are not involved in this project AFAIK
[12:37] <pitti> Keybuk: can you please fix MoM to generate changelogs for feisty?
[12:40] <Fujitsu> pitti: I believe it does already, although it will only affect merges generated since that change was made, obviously.
[12:40] <pitti> Fujitsu: ah, ok
[12:40] <StevenK> Fujitsu: In regards to your terrible discovery, are you moving to Sydney? :-P
[12:40] <Fujitsu> I've noted a couple of mine have had feisty there.
[12:41] <Fujitsu> StevenK: Oh no.. Not you too!?
[12:41] <Keybuk> pitti: hmm?
[12:41] <StevenK> Fujitsu: 220 enervated.wedontsleep.org ESMTP Exim 4.63 Mon, 30 Oct 2006 22:41:31 +1100
[12:41] <pitti> Keybuk: see above, seems to be already fixed
[12:42] <Fujitsu> Argh, I live in an Exim-loving nation :(
[12:42] <Keybuk> pitti: I haven't refreshed MoM yet
[12:42] <Keybuk> nor have I begun the syncs
[12:42] <pitti> Keybuk: I started doing my merges, and the current MoM output is good enough for me at least (I check that it has the current version anyway)
[12:43] <Keybuk> you can't test them yet, let alone upload them!
[12:43] <Fujitsu> Keybuk: The latter is understandable, but the former may good to perform...
[12:43] <pitti> Keybuk: I don't upload them yet :)
[12:43] <Fujitsu> Keybuk: But merges can be done, then tested and uploaded later. Less time wastage.
[12:43] <sladen> Gloubiboulga: so this isn't an offical livecd?
[12:43] <pitti> but now is a good time to review diffs, send patches upstream, merge packages, etc.
[12:43] <pitti> and test them with libc 2.5
[12:44] <Keybuk> a fair point
[12:44] <Keybuk> I'll regenerate them
[12:44] <Fujitsu> pitti, exactly. Right now, when there's little else to do, doing merges is a good idea.
[12:44] <Fujitsu> Thanks Keybuk.
[12:44] <fabbione> pitti: glibc ain't enough.. really..
[12:44] <pitti> Keybuk: the only thing that concerns me is that we don't have the newer gcc yet
[12:44] <Keybuk> Fujitsu: specs would be a better idea ? :)
[12:44] <fabbione> pitti: you also need binutils, kernel headers and gcc
[12:45] <fabbione> and glibc still need some love
[12:45] <Fujitsu> Keybuk: Possibly... But I'm not a speccy person :P
[12:45] <pitti> fabbione: I know, but for patch review and initial testing it should be good enough for most packagages
[12:45] <Gloubiboulga> sladen, I don't think so
[12:45] <fabbione> pitti: nope.. not really.. there are some radical changes in binutils/glibc that is not part of the binaries you are using
[12:46] <pitti> fabbione: I can decide whether or not we can drop Ubuntu changes regardless of our toolchain
[12:46] <fabbione> oh yeah that's for sure
[12:46] <pitti> of course I'll test my current stack of merges again with the new toolchain
[12:47] <cjwatson> I can't test most of mine until after they're uploaded anyway (installer)
[12:47] <cjwatson> at least not without vast amounts of effort
[12:47] <Hobbsee> Fujitsu: get writing specs!
[12:47] <cjwatson> it's far more economical for me to chuck them into the archive and test once everything's assembled
[12:48] <infinity> In fact, is there anything in the queue that you didn't upload? :)
[12:48] <cjwatson> not AFAIK :)
[12:48] <fabbione> oh infinity.. somebody should whitelist LP in feisty-changes ML
[12:48] <infinity> fabbione: Yeah, it's not my list.
[12:48] <fabbione> ok...
[12:48] <fabbione> who is the one?
[12:48] <Keybuk> is feisty-changes actually working?
[12:48] <Keybuk> I don't see a mail for base-files
[12:49] <fabbione> Keybuk: read 5 lines above
[12:49] <infinity> feisty-changes list run by lists at admin.canonical.com
[12:49] <Fujitsu> Keybuk: No, hence the need to whitelist LP.
[12:50] <Keybuk> ah, heh
[12:50] <ogra> and someone should do a user migration from edgy-changes to feisty as well 
[12:50] <fabbione> ogra: no you need to subscribe yourself manually
[12:50] <ogra> unless thats already done
[12:50] <cjwatson> infinity: I've got 50+ to merge before the installer works at all, so getting started early has generally proven to be a good plan :)
[12:50] <ogra> fabbione, since when ?
[12:50] <fabbione> since dapper
[12:50] <ogra> we always had auto migration between releases, no ?
[12:50] <fabbione> nope
[12:50] <ogra> oh
[12:50] <ogra> ok
[12:51] <cjwatson> Keybuk: as far as I can see, setup-console-under-usplash will Just Work as soon as I remove the safety catches
[12:51] <Keybuk> cjwatson: isn't that the best kind of spec?
[12:52] <cjwatson> indeed
[12:52] <cjwatson> no kernel problems at all
[12:53] <cjwatson> I took out the setupcon call in /etc/init.d/usplash and took out the check for a running usplash in /etc/init.d/console-setup
[12:53] <doko> infinity: any idea about bug 63676 ?
[12:53] <Ubugtu> Malone bug 63676 in openoffice.org "OpenOffice Crashes on Launch" [Undecided,Needs info]  http://launchpad.net/bugs/63676
[12:57] <Keybuk> cjwatson: what caused the console corruption?
[12:57] <infinity> doko: /usr/lib/libpthread.so.0 isn't a binary we ship (ours is in /lib)
[12:57] <cjwatson> Keybuk: probably attempting to fiddle with usplash's own tty
[12:58] <cjwatson> rather than ttys 1 to 6
[12:58] <infinity> doko: Same with /usr/lib/libc6.so.6
[12:58] <Keybuk> ah, how are we ignoring that now?
[12:58] <Keybuk> 1..6 or checking for !KD_TEXT ?
[12:58] <cjwatson> Keybuk: we aren't - console-setup was fixed to talk to the right ttys
[12:58] <infinity> doko: They have a non-standard libc installed.  Not.  Our.  Problem.
[12:58] <cjwatson> Keybuk: using its existing configuration for which are the active consoles (/dev/tty[1-6] )
[12:58] <Keybuk> ok
[12:59] <Keybuk> my only concern there is that it will break if someone disables tty2, etc.
[12:59] <Keybuk> but that concern is probably petty and woefully misplaced at this time
[12:59] <cjwatson> Keybuk: then it's easy to edit /etc/default/console-setup
[12:59] <ogra> Keybuk, nout for ltsp
[12:59] <Keybuk> might be worth checking the console mode
[01:00] <Keybuk> iterate active vts, check for KD_TEXT, and only then setup ?
[01:00] <Keybuk> that'd skip the X and usplash consoles
[01:00] <cjwatson> would be better to make consolechars (setfont in Feisty) do that check rather than pissing about trying to check it from shell
[01:00] <Keybuk> yes
[01:00] <Keybuk> unless we get /sbin/ioctl :p
[01:00] <Keybuk> which I still want
[01:01] <mark> can someone please update the Release files in edgy-{backports,updates,security} so debmirror will mirror again? :)
[01:01] <doko> infinity: thanks
[01:01] <Keybuk> mmm... /sbin/ioctl KDGETMODE ...
[01:01] <Keybuk> :p
[01:01] <ogra> mjg59 is though
[01:01] <cjwatson> mark: what's wrong with them?
[01:01] <mark> debmirror complains about missing gpg signatures
[01:01] <Keybuk> cjwatson: they don't exist
[01:01] <mark> let me check
[01:01] <Keybuk> uh
[01:01] <infinity> doko: Though the fglrx thing is interesting as well (but I'm not sure I care today)
[01:01] <cjwatson> yes they do
[01:01] <Keybuk> wrong window, and wrong person
[01:02] <pitti> mark: debmirror works fine for me ?!?
[01:02] <Fujitsu> infinity: You mean the lack of DRI in Edgy?
[01:02] <pupeno__> Hello.
[01:02] <infinity> Fujitsu: No.  That's known and a simple workaround.
[01:02] <infinity> Fujitsu: Disable composite, DRI works, the end.
[01:02] <pupeno__> I have just installe Edgy and it seems cryptsetup is broken. I've searched in the bugs database but I've found no mention of it. Does anybody know about this ?
[01:03] <mark> Won't mirror without dists/edgy-updates/main/debian-installer/binary-amd64/Packages.gz signature in Release at /usr/bin/debmirror line 1300.
[01:03] <Fujitsu> pupeno__: What do you mean broken? It won't ask for a password?
[01:03] <pupeno__> Fujitsu: it fails to create a crypted volume, missmatched version of tools and module.
[01:03] <cjwatson> mark: ok, would have helped a lot if you'd mentioned that earlier :)
[01:03] <mark> doh
[01:03] <pupeno__> root@plab:~# cryptsetup -y create pupeno /dev/hda3
[01:03] <pupeno__> Command failed: Incompatible libdevmapper 1.02.07 (2006-05-11)(compat) and kernel driver
[01:03] <mark> there is no debian-installer
[01:04] <cjwatson> indeed
[01:04] <mark> cjwatson: it would've helped a lot if I had used my brain earlier ;)
[01:04] <cjwatson> tell debmirror not to try to mirror it :)
[01:05] <cjwatson> the error message is perhaps not entirely ideal
[01:05] <mark> I just looked at the date 'august 8' of the release files and thought "they must be out of date"
[01:05] <cjwatson> there haven't been any updates published yet
[01:06] <cjwatson> so nothing has caused the Release files to be rewritten
[01:08] <pupeno__> Here: http://paste.lisp.org/display/28971 , some more information. Can anybody confirm/deny this problem ?
[01:08] <mark> assuming dists/edgy/main/debian-installer/ will never change again, I won't have to mirror that dir
[01:11] <Keybuk> pitti: please don't file syncs!
[01:11] <pitti> Keybuk: why not?
[01:11] <Keybuk> we're not in upstream version freeze
[01:11] <Keybuk> so syncs will happen automatically
[01:11] <Keybuk> unless you are meaning that changes are to be dropped from a merge?
[01:11] <pitti> Keybuk: erm, for locally modified packages???
[01:12] <pitti> Keybuk: yes, that's what I do
[01:12] <Keybuk> ok, sorry
[01:12] <pitti> Keybuk: *phew* :)
[01:12] <Keybuk> I didn't see a summary of ubuntu changes in your first mails
[01:12] <Keybuk> so assumed you were doing "update these to Debian" :)
[01:12] <Keybuk> just noticed you added that in a reply to each
[01:12] <pitti> Keybuk: I use requestsync to file them and then add a followup with the explanation
[01:12] <Keybuk> *nods*
[01:12] <Keybuk> I can see that now
[01:13] <pitti> Keybuk: maybe I should teach requestsync to spawn $EDITOR for this case
[01:13] <Keybuk> doesn't matter really, when read in LP it will look normal
[01:13] <Keybuk> I was just reading the e-mail
[01:15] <pupeno__> so, cryptsetup seems to be really broken :(
[01:15] <Hobbsee> pupeno__: file a bug?
[01:16] <pupeno__> Hobbsee: I am in the process, but there are other bugs for it already. What I don't understand is how people got so far to find out the other bugs since the one I've found should have stopped them earlier.
[01:16] <mark> I see startup messages are no longer logged to the serial console in edgy - is this because of upstart/logd?
[01:16] <pitti> Keybuk: gnutls12 was removed in Debian; will some magick indicate that it should be removed from Ubuntu as well, or shall I file a bug for that?
[01:16] <Keybuk> mark: remove "quiet" from the kernel command-line
[01:16] <Keybuk> pitti: file a bug
[01:16] <mark> Keybuk: thanks
[01:18] <tepsipakki> how come the source for pine is not included in ubuntu as it is on debian?
[01:19] <thom> tepsipakki: because pine users should be burnt at the stake (not the correct answer)
[01:20] <thom> tepsipakki: seriously, i suspect because no-one has asked for it, and it would probably need to go into multiverse
[01:20] <tepsipakki> thom: yes, multiverse would be the place
[01:20] <azeem> there should be GNU pain
[01:21] <popey> is there a file like http://changelogs.ubuntu.com/meta-release which gives the correct answer to the question "what are the current supported releases of Ubuntu?" ?
[01:21] <tepsipakki> thom: we have maybe 10000 users who use it more or less frequently. I can already smell them :)
[01:22] <popey> for example that page has Hoary as supported but it's been 18 months since release, so I would expect that to become "Supported: 0"?
[01:22] <thom> tepsipakki: just install mutt with the pine theme and symlink pine to it :-)
[01:22] <tepsipakki> thom: :D
[01:22] <tepsipakki> maybe I'll just grab the source from debian and use that ;)
[01:23] <pitti> popey: https://launchpad.net/distros/ubuntu
[01:23] <popey> ah, of course
[01:26] <cjwatson> mark: dists/edgy/main/debian-installer/ won't change, no
[01:27] <thom> cjwatson: ISTR you mentioning that edgy kickstart was a bit bust at one point; did that get fixed or should I aim for preseed?
[01:27] <mark> now I understand why 'quiet' is the default - with upstart it gets very messy otherwise ;)
[01:28] <cjwatson> popey: hoary hasn't officially reached EOL yet; see https://lists.ubuntu.com/archives/ubuntu-security-announce/2006-October/000418.html
[01:28] <Hobbsee> cjwatson: one more day...
[01:28] <cjwatson> thom: should be fixed
[01:28] <cbx33> hi popey
[01:28] <Hobbsee> cjwatson: in fact, it's the 31st in NZ - so it has :P
[01:29] <popey> hahah
[01:29] <popey> didn't realise it was that close

[01:29] <zul> yehaw i dont have to do security updates for hoary if i was in nz right now
[01:29] <spike> hi there
[01:30] <spike> can anybody comment about the debian-installer?
[01:30] <thom> cjwatson: ah, thanks
[01:30] <spike> "This package currently only contains some documentation for the Debian installer. We welcome suggestions about what else to put in it."
[01:32] <pitti> zul: btw, don't bother with preparing another hoary kernel; none of the outstanding issues are 'OMG the sky has fallen', and we won't be able to push it out today or tomorrow anyway
[01:33] <zul> pitti: consider it done :)
[01:42] <cjwatson> spike: yes, that's all that the debian-installer *binary package* contains
[01:43] <cjwatson> spike: what are you looking for?
[01:43] <spike> cjwatson: so I'm probably missing something... I'm looking at this page: http://www.hands.com/d-i/
[01:43] <spike> cjwatson: the idea is using preesedeeing and boot clients from a network image
[01:44] <spike> via PXE
[01:44] <spike> I'm using FAI atm, I wanted to give preseeding a try
[01:44] <spike> but I cant get a clear picure how what I'm supposed to do
[01:44] <spike> that page says about recompling some custom udebs and so on
[01:44] <cjwatson> I'm not sure we have a lot of the necessary infrastructure by default yet in edgy
[01:45] <cjwatson> if you really want to try it, start with 'apt-get source debian-installer' rather than the debian-installer binary package
[01:45] <cjwatson> but Kickstart will probably be easier
[01:45] <spike> unfortunately there doesnt seem to be any good doc either :/
[01:45] <mark> would you mind joining #ubuntu-installer? :)
[01:46] <spike> that page and http://interthingy.com/digby/ are the only decent resources
[01:46] <spike> yet fairly chaotic and incomplete imho
[01:46] <tepsipakki> what's wrong with nvidia-glx, since it insists on installing linux-image..-386
[01:47] <tepsipakki> which then panics on boot
[01:47] <cjwatson> spike: installation-guide
[02:02] <ogra> cjwatson, would you think it would make sense to have a special ltsp mode for netinst ? i provide the necessary infrastructure anyway 
[02:02] <cjwatson> ogra: what do you mean?
[02:02] <ogra> so you could be off with installing ltsp-server and copy the neinst iso into place
[02:03] <cjwatson> what netinst iso?
[02:03] <ogra> err, s/iso/image
[02:03] <cjwatson> we've never provided netinst, only netboot
[02:03] <ogra> thats what i mean
[02:03] <cjwatson> netinst == installer image plug base system
[02:03] <cjwatson> plus
[02:03] <cjwatson> ogra: netboot needs to stay generic; I don't want to build lots of variants of it
[02:04] <ogra> ltsp-server sets up tftp and the like so you only need to put the image in the right place ...
[02:04] <cjwatson> ogra: you should be able to preseed netboot to do whatever you want to do
[02:04] <ogra> i dont want to touch netboot 
[02:04] <cjwatson> oh, you mean a netboot mode for ltsp?
[02:04] <ogra> preseeding will get me the dhcpd and tftpd infrastructure ready ?
[02:04] <cjwatson> forget what I said
[02:04] <ogra> i mean that you could re-use the ltsp package setup for netboot
[02:05] <cjwatson> ogra: sure, I guess
[02:05] <ogra> i'm expressing myself complicated today, sorry
[02:05] <cjwatson> ogra: sounds like it's entirely up to you
[02:05] <cjwatson> if you have people wanting it, and it's not too hard to do, then do it
[02:06] <ogra> well, i dont
[02:06] <ogra> but i see the question about netboot and how to set up dhcp and tftp more often
[02:06] <cjwatson> then perhaps you should not do it
[02:06] <cjwatson> that's not really connected to LTSP
[02:07] <ogra> so i thought about a howto like: install ltsp-server and copy the image to ... 
[02:07] <cjwatson> it shouldn't be tied into LTSP, IMO
[02:07] <ogra> ...  then boot your client and watch it install
[02:08] <ogra> well, it already is in there ...
[02:08] <ogra> ltsp serts up the services ...
[02:08] <ogra> *sets
[02:09] <cjwatson> ogra: how-to documents for automatic installations that have nothing to do with LTSP shouldn't come with all the other LTSP bits
[02:09] <ogra> right
[02:09] <ogra> well, was just a thought to make it easier for users struggling with dhcp/tftp
[02:10] <cjwatson> http://doc.ubuntu.com/ubuntu/install/i386/ch04s05.html
[02:10] <cjwatson> ^-- existing documentation on setting it up. happy to improve it given specific suggestions
[02:10] <ogra> right, i'll think about it ...
[02:59] <cjwatson> tfheen: do you remember what places in X depend on /etc/X11/xkb and/or /usr/lib/X11/xkb?
[02:59] <cjwatson> tfheen: new xkeyboard-config in Debian uses /usr/share/X11/xkb
[03:00] <cjwatson> (of which I'm all in favour - get rid of 2.7MB from /etc that hardly anyone touches
[03:00] <cjwatson> )
[03:00] <fabbione> cjwatson: iirc we discuss that in edgy merge and decided to keep it in /etc to avoid yet another transition..
[03:01] <fabbione> and it's probably a path in the server
[03:01] <fabbione> or slam a compat symlink
[03:03] <cjwatson> I think just Breaks: xorg-server (<< version-with-new-xkb-path)
[03:03] <cjwatson> making that a compatibility symlink would be a pain, 'cos we'd have to ensure that the directory was nonexistent first, and then what do you do if the user had customised stuff there ...
[03:04] <fabbione> then i suggest to leave it in /etc
[03:04] <tfheen> cjwatson: the X server and xkbcomp/setxkbmap, iirc.  there are a couple of libs.
[03:04] <fabbione> even if there are custom things, once you move and "preserve" them in /usr/share, they will disappear at the first upgrade
[03:06] <cjwatson> I don't want to keep that divergence forever
[03:07] <cjwatson> AFAICT it was a pretty deliberate decision by Denis to move to /usr/share
[03:08] <cjwatson> and I wasn't thinking of trying to dubiously "preserve" conffiles - more a postinst warning and just leave them there
[03:11] <cjwatson> tfheen: does it parse it the wrong way round?
[03:11] <cjwatson> ISTR having trouble with that before
[03:12] <cjwatson> there's also no way to quote it
[03:12] <tfheen> cjwatson: on the kernel command line proper, it just doesn't work.
[03:12] <tfheen> I was a bit heavy-handed when doing a bit of C&P
[03:12] <cjwatson> ah
[03:14] <tfheen> Keybuk: we should probably make it error out in the case above: ^^ ; it effectively didn't have a root= line which makes it spin forever.
[03:15] <Keybuk> interesting
[03:16] <Keybuk> yes, initramfs should do something "sensible" when ROOT=""
[03:25] <arvind_> We are going to deliver ubuntu desktops. We would like to create a costum gnome settings. This includes themes, icons themes, icons on the desktop and panel configuration/settings, font settings. How do I put all this in a skeleton is there a guide?
[03:26] <whiprush> arvind_: google for "sabayon" and the "gnome system administration guide"
[03:49] <sivang> re all
[03:54] <bddebian> Howdy
[04:01] <jono> anyone know Mark Nielson?
[04:14] <keescook> hi all
[04:16] <seb128> hey keescook
[04:16] <keescook> hiya seb128
[04:17] <seb128> keescook: have you planned to get that vino password fix to edgy-proposed? ;)
[04:17] <seb128> keescook: some user asked about it today
[04:17] <keescook> seb128: yup, it's on my todo list.
[04:17] <seb128> cool, thank you
[04:21] <_ion> If i were to propose that feisty should use the "Defaults insults" sudo setting, would there be 0.0% or 0.1% chance of that actually happening? :-)
[04:21] <_ion> (Btw, OpenBSD uses that by default.)
[04:22] <Nafallo> _ion: the what?
[04:22] <thom> heh
[04:22] <thom> no insults by default :-)
[04:23] <_ion> http://johan.kiviniemi.name/tmp/sudo-insults
[04:24] <Nafallo> lol
[04:24] <Nafallo> no
[04:24] <Nafallo> not by default :-)
[04:24] <pitti> hi mbiebl 
[04:25] <mbiebl> pitti: hi
[04:25] <cjwatson> the insults are all very amusing, but no, I don't think so
[04:25] <cjwatson> (-> _ion)
[04:26] <_ion> Hehe, all right.
[04:26] <jdub> Keybuk: http://lwn.net/Articles/205585/
[04:27] <_ion> jdub: Would that make it possible to also relocate blocks for faster startup?
[04:28] <iwj> cjwatson: Could you or mdz prioritise https://features.launchpad.net/distros/ubuntu/+spec/unified-login-unlock-screen please ?
[04:28] <jdub> very likely :-)
[04:28] <iwj> I looked around and amazingly I couldn't find another plan to fix this anywhere.
[04:28] <_ion> jdub: Because that would rule. :-)
[04:28] <bhale> jdub: is that really needed?
[04:29] <jdub> bhale: would be very awesome for optimising boot and application startup.
[04:29] <bhale> jdub: hm oh, not for defrag
[04:29] <bhale> jdub: right on
[04:30] <jdub> bhale: kung fu teaches to use the opponent's inertia in your favour.
[04:30] <_ion> bhale: If something allows the disk IO part of startup to consist of reading a continuous n MiB chunk of data from the HDD, i'd consider it "needed". :-)
[04:31] <PSUSI> fabbione: ping
[04:35] <cjwatson> iwj: I'm not involved in setting priorities at the moment - the tech board is (so try Keybuk)
[04:35] <cjwatson> (mdz's travelling)
[04:36] <_ion> Does anyone know how Windows profiles the startup of programs for block relocation? The profiler itself shouldn't slow things down more than block relocation speeds them up. :-)
[04:36] <Keybuk> _ion: I assume that windows has something that sucks less than inotify
[04:37] <iwj> Keybuk: Thanks.
[04:37] <Keybuk> iwj: I assume you want to propose it for the meeting?
[04:37] <iwj> Yes.
[04:38] <iwj> Although I'd make it `high'.  Have you ever seen a user who didn't know how it works struggle with this madness ?  It's quite crazy.
[04:38] <iwj> Most users seem to assume it's buggy or has crashed or something.
[04:38] <Keybuk> iwj: though it seems to conflict/overlap with both feisty-login and consistent-login-screen
[04:40] <iwj> Dammit, I'm sure I searched the spec list for login before inventing a new one.
[04:40] <iwj> I'll add some cross-references.
[04:42] <iwj> Keybuk: Hmm, can you make consistent-login-screen medium instead ?
[04:43] <Keybuk> done
[04:44] <iwj> Ta
[04:49] <cjwatson> iwj: and that's if they can even find how to switch user; see bug 67730, whose reporter you may recognise
[04:49] <Ubugtu> Malone bug 67730 in Ubuntu "Usability bug - new login" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67730
[04:51] <Gadi> Keybuk, infinity:  Just wanted to let you know how I resolved the boot-by-label issue in the end.  I basically commented out the udev rule in persistent-disks that skips the by-label studd if the ide disk is tagged "removable" and recreated initramfs
[04:51] <iwj> cjwatson: *snort*
[04:51] <Gadi> dont know what other probs this will cause, but wors so far
[04:51] <Gadi> s/wors/works/
[04:52] <Nafallo> jdub: lol
[04:52] <fabbione> PSUSI: pong
[04:54] <pitti> hm, I just tried to sub to feisty-changes again and still didn't get a verification email
[04:55] <cjwatson> pitti: have you already set up procmailery for feisty-changes?
[04:55] <cjwatson> pitti: if so, note that the verification mail may have gone to the mailbox you set up for the list ...
[04:56] <cjwatson> that one gets me nearly every time
[04:56] <pitti> cjwatson: that's what I thought, too
[04:56] <pitti> cjwatson: but .procmail.log doesn't have any sign of the verification mail
[04:56] <pitti> oh, wait, it does, *blush*
[04:56] <Keybuk> Gadi: good luck :)  when your machine locks up on boot, don't file a bug <g.
[04:56] <pitti> cjwatson: landed in spam folder...
[04:57] <Nafallo> hehe
[04:58] <jdub> "For those vendors which have proprietary drivers that enable acceleration, we will consider enabling those drivers by default if they can provide us with an SLA for security and related updates."
[04:58] <jdub> haw haw
[04:58] <^robertj> jdub: aka "no"
[04:59] <PSUSI> fabbione: hey, I noticed you made some changes to the lvm initramfs script since dapper
[04:59] <iwj> `If [condition not going to be met] ' is always easier to say than `no' ...
[04:59] <PSUSI> fabbione: it now assumes a boot path starting with /dev/mapper is LVM, and breaks it into vulume group and volume components, and spins for 3 mins waiting for the vg to appear in /dev
[05:00] <PSUSI> fabbione: this causes dmraid booting systems to appear to lock up for 3 mins during boot, so I was wondering why this change was made?
[05:00] <fabbione> it does only if root is on LVM
[05:00] <PSUSI> right.... it thinks root is on lvm if root is on dmraid
[05:00] <jdub> iwj: versus "uh, we're not going to ship your shit anyway"? :)
[05:00] <PSUSI> that's the problem I ran into
[05:00] <fabbione> PSUSI: it's a problem with some devices that takes longer to apper to the kernel.
[05:00] <PSUSI> but I'm wondering why the script waits for the volume group to appear in dev?
[05:00] <PSUSI> doesn't it just need the volume itself to appear?
[05:01] <fabbione> i am trying to explain.. let me write
[05:01] <PSUSI> k
[05:01] <fabbione> basically in some cases the lvm script was executed before the underneath devices were available
[05:01] <fabbione> making the vgchange command exit immediatly
[05:02] <fabbione> that means that the initramfs would have waited forever for /
[05:03] <fabbione> so lvm needs to wait and scan while devices are appearing in the system
[05:03] <fabbione> once the VG is available it can exit the loop and go to mount root
[05:03] <cjwatson> pitti: heh
[05:03] <_ion> Hm, i think i ran into that, too, when i tried booting the md (RAID-1) + LVM system without the other HDD. Unfortunately i didn't have the chance to look into that because i had to get the 24/7 system running ASAP.
[05:04] <PSUSI> fabbione: isn't udev-settle supposed to hold the scripts until all the devices have been detected?
[05:04] <fabbione> PSUSI: nope...
[05:04] <fabbione> did try to add udev-settle.. doesn't work on slow devices
[05:04] <fabbione> _ion: a degraded raid is a totally different story
[05:04] <PSUSI> hrm...
[05:05] <fabbione> i was still getting lvm executed way before the device was there
[05:05] <Keybuk> udevsettle holds the scripts until devices that HAVE ALREADY BEEN DETECTED have been configured
[05:05] <_ion> fabbione: Ah, ok.
[05:05] <PSUSI> ok.... well, I'd sugest that the loop print something to let the user know that it is still waiting after day, 10 seconds at most, and again if it times out completely
[05:05] <Keybuk> there's obviously no way to wait for devices that have not yet been detected
[05:05] <Keybuk> because if they've not been detected, we don't know to wait for them
[05:06] <PSUSI> doesn't it wait for the bus scan to complete though?  thus we know all devices have been detected?
[05:06] <Keybuk> most modern bus scans have no concept of completion
[05:06] <Keybuk> take USB, for example; how do you know that an arbitrary topology tree-formed bus has completed a scan?
[05:07] <PSUSI> fabbione: hrm.... well can you sugest any way that it could be kept from clashing with dmraid?  Other than just removing lvm from the initramfs?
[05:07] <_ion> fabbione: I take it the delay caused by booting with a degraded RAID-1 is a known problem? (Sorry, didn't yet look at launchpad bugs)
[05:08] <PSUSI> Keybuk: simple... you have queried all the hubs
[05:08] <PSUSI> and all ports on those hubs
[05:08] <fabbione> PSUSI: i am not sure.. the only way we have to know it's to wait for the VG to appear in /dev
[05:08] <Keybuk> PSUSI: and what if a hub is connected to those ports?
[05:08] <fabbione> _ion: i don't know about that bug. what i am saying that the problem you are describing is different from what PSUSI is talking about
[05:08] <Keybuk> what if the hub takes 3s to power up, and doesn't return an announcement of its own presence until then?
[05:08] <_ion> fabbione: Ok, right.
[05:09] <fabbione> _ion: also.. i see no reason why initramfs should hold up on a degraded raid.
[05:09] <PSUSI> fabbione: let me make sure if I get this then.... the VG appears first, then the script must run a command to create the volume itself?
[05:09] <fabbione> _ion: it *CAN* wait only if you have a configured raid and you remove it completely (100%) from the system and that's documented 
[05:09] <PSUSI> Keybuk: then you have not scanned all hubs yet, keep scanning
[05:09] <Keybuk> PSUSI: and how do we know that there's no device on a port?
[05:10] <fabbione> PSUSI: no. the problems are devices that are part of the LVM volume and that are not there when lvm script is executed.
[05:10] <PSUSI> Keybuk: iirc, usb detectes taht there is a device connected to the port via the characteristic impeadence, so its prescense is known immediately
[05:10] <Keybuk> PSUSI: not true
[05:10] <fabbione> PSUSI: the only way to know that root is on lvm is when root=/dev/mapper.. 
[05:10] <Keybuk> a long cable with nothing on it would be detected as a connected device by that means
[05:11] <fabbione> PSUSI: and we know that the VG is active once there is the directory in /dev
[05:11] <Keybuk> which would cause the boot to hang while we waited for the device on the other end to announce itself
[05:11] <PSUSI> fabbione: right, but what creates those devices?  I thought that the scripts ran commands that scanned actual disk devices, and then created the dm devices on top?
[05:11] <PSUSI> fabbione: so the scripts should depend on the real underlying hardware, not the vg device no?
[05:11] <fabbione> PSUSI: vgchange...
[05:12] <PSUSI> Keybuk: which is why there is a maximum cable length
[05:12] <fabbione> PSUSI: not really.. you can't add these information in the initramfs. LVM is way too flexible for that
[05:12] <fabbione> PSUSI: LVM scans the disks for LVM UUIDS to see if all devices to activate a certain VG are there.. regardless of their name (sda sdb..)
[05:12] <fabbione> PSUSI: so a device might appear always with a different name
[05:12] <PSUSI> fabbione: the vg does not appear until you run vgchange though right?
[05:13] <fabbione> and LVM will still work
[05:13] <fabbione> yes right
[05:13] <fabbione> but you don't know what devices are part of the vg
[05:13] <PSUSI> fabbione: is this done by udev callouts or by an vgchange like command?
[05:13] <fabbione> vgchange calls
[05:13] <fabbione> (it's the only way)
[05:14] <PSUSI> called from where?  udev, or the script?
[05:14] <PSUSI> if it is from the script, then the devices should appear synchronously no?
[05:14] <fabbione> or you need a much more complex algo that will still invoke the lvm binary
[05:14] <fabbione> script
[05:14] <fabbione> udev doesn't do anything for us yet
[05:14] <fabbione> (it will in feisty.. HI SCOTT!)
[05:14] <PSUSI> oh wait, ok, I see now... the script just keeps calling the binary to search all known devices for a vg
[05:14] <PSUSI> and it either finds them all and makes the vg or not
[05:14] <fabbione> for THE vg
[05:15] <PSUSI> if not, the script delasy 0.1 seconds, and tries again
[05:15] <fabbione> exactly
[05:15] <fabbione> 0.5 but yes
[05:15] <Keybuk> fabbione: maybe
[05:15] <fabbione> vgchange is expensive
[05:15] <fabbione> Keybuk: just kidding :)
[05:15] <Keybuk> fabbione: we will either use udev callouts for LVM/EVMS/etc.
[05:15] <Keybuk> fabbione: or we will drop support for them entirely
[05:15] <fabbione> Keybuk: drop support is not an option
[05:15] <PSUSI> I'll start working on udevifying dmraid ;)
[05:15] <Keybuk> fabbione: then make sure you're subscribed to the discussion BOFs, and come with information about how to make it possible <g>
[05:16] <PSUSI> discussion bofs?
[05:16] <fabbione> Keybuk: i am subscribed already.. you did... implementation isn't my issue :) i am sure you are going to have a lot of fun testing it :P
[05:16] <Keybuk> https://features.launchpad.net/distros/ubuntu/+spec/udev-device-mapper
[05:16] <Keybuk> https://features.launchpad.net/distros/ubuntu/+spec/udev-lvm
[05:16] <fabbione> Keybuk: i think you subbed me as essential ;)
[05:16] <Keybuk> https://features.launchpad.net/distros/ubuntu/+spec/udev-evms
[05:16] <Keybuk> https://features.launchpad.net/distros/ubuntu/+spec/udev-mdadm
[05:16] <Keybuk> fabbione: yes, testing and understanding is a big part of what we need
[05:16] <fabbione> Keybuk: yeps.. i can help you there
[05:16] <Keybuk> I'm going to put vmware on my laptop so we can set up trials
[05:17] <fabbione> nah.. just keep about 300MB of spare disk space
[05:17] <fabbione> no need to use vmware
[05:17] <Keybuk> ok
[05:17] <fabbione> if you can shrink a partition or something.. just free 2/300 MB
[05:17] <Keybuk> *nods*
[05:17] <fabbione> it's way too much for playing
[05:17] <Keybuk> will do that then
[05:17] <fabbione> plys
[05:17] <fabbione> plus
[05:17] <fabbione> we can use loop devices
[05:17] <fabbione> same results.. faster.. less pain
[05:18] <fabbione> WHO DOESN'T HAVE ROOT ON A RAID5 over LOOP over LVM is just.. .a normal user..
[05:18] <LarstiQ> heh
[05:21] <PSUSI> lol
[05:21] <Keybuk> fabbione: as I've said before, I find it amusing that of all the parts of the system you can play with to make life interesting for yourself, people still choose their root filesystem
[05:22] <PSUSI> well, I didn't have a whole lot of choice actually since I wanted to be able to dual boot with windows which was installed on my hardware fakeraid
[05:22] <fabbione> Keybuk: personally.. i still like my root on lvm.. really.. how other people get to trash it ain't my problem
[05:26] <PSUSI> fabbione: so for dmraid users upgrading to edgy, I should recomend they just remove the lvm script and rebuild their initramfs?
[05:27] <fabbione> PSUSI: your call.. dmraid is universe... but make sure that they are not running LVM on top of dmraid
[05:27] <fabbione> otherwise you are going to mess up for them
[05:27] <PSUSI> oh good god I hope nobody is that crazy
[05:28] <fabbione> why not?
[05:28] <fabbione> you are crazy enough to run dmraid
[05:28] <fabbione> you can't assume
[05:28] <PSUSI> device mapper, on top of device mapper, on top of device mapper?
[05:28] <fabbione> yes of course
[05:28] <fabbione> what's the big deal with that
[05:28] <PSUSI> hehe... all I can say is DAMN!
[05:28] <fabbione> d-m is a fast layer
[05:28] <fabbione> very cheap
[05:28] <PSUSI> yea.... but... well....
[05:38] <iwj> rodarvus: I was wondering if you had any useful opinion about bug 68440, which is quite annoying for me ?
[05:38] <Ubug2> Malone bug 68440 in xorg "X does not work in Xen, causes crash" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68440
[05:41] <rodarvus> iwj, let me take a look at it
[05:41] <iwj> rodarvus: Thanks a lot.
[05:42] <iwj> Various other people have similar setups without trouble so it's probably something specific to my hardware.
[05:50] <mark> is there a system/script for doing automated backports of packages?
[05:50] <mark> backport builds
[05:55] <dholbach> mark: the process is automatic, but each backport has to be requested and approved
[05:56] <mark> I was more wondering if there's an easy way to do this stuff outside debian/ubuntu, without having to build all packages by hand
[05:57] <dholbach> something like          apt-get source -t edgy -b <package>  && sudo dpkg -i *.deb          ?
[05:57] <dholbach> (you'll need a   deb-src   line for edgy)
[05:58] <_ion> build-dep
[05:58] <mark> hmm maybe :)
[05:58] <iwj> Install pbuilder ?
[05:58] <mark> but changing the version number to include something like "~dapper1" would be nice
[06:00] <dholbach> should all be easy to set up, look into dch and pbuilder
[06:00] <mark> okay, thanks
[06:14] <PSUSI> dangit... how do you mark a bug as a duplicate on launchpad?
[06:15] <PSUSI> nevermind... there it is
[06:18] <nkassi> PSUSI: I know what you mean ;0) 
[06:33] <PSUSI> what should I do with a bug that has no ubuntu maintainer and appears to not be modified from debian?  specifically reiserfsprogs
[06:33] <PSUSI> https://launchpad.net/distros/ubuntu/+source/reiserfsprogs/+bug/60894
[06:33] <Ubug2> Malone bug 60894 in reiserfsprogs "mkfs.reiserfs creates an unmountable file system" [Undecided,Confirmed]  
[06:33] <Tonio_> hi
[06:34] <PSUSI> hrm... maybe I'll just assign it to myself?
[06:44] <cjwatson> PSUSI: only if you intend to fix it yourself and push the fix into the archive (via a sponsor or whatever)
[07:23] <elmo> keescook/pitti: well, hmm, infinity doesn't seem to have added edgy-security to the buildds.  I could just try bodging it in if you like?
[07:24] <keescook> elmo: I thought he said he'd built the chroots?
[07:24] <elmo> he has, but the buildds aren't looking at the distro yet
[07:24] <keescook> ah
[07:25] <keescook> so in theory, it might work if it was just added to the buildds?
[07:25] <sladen> PSUSI: file it upstream in Debian, and link to the upstream bugtracker
[07:26] <elmo> keescook: yes, I'll give it a go
[07:30] <fabbione> elmo: infinity was waiting for you to OK dak before adding edgy-security to the buildd...
[07:34] <mattions> Do you know where I can find libgdl-1-dev .deb verion >=0.7 ?
[07:34] <mattions> version*
[07:34] <elmo> PITTI
[07:34] <elmo> pitti: dh_strip killed the screen build?
[07:35] <elmo> dh_strip debug symbol extraction: all non-arch-all packages for this build platform i386: screen 
[07:35] <elmo> dh_strip debug symbol extraction: packages to act on: screen 
[07:35] <elmo> dh_strip debug symbol extraction: ignored packages: 
[07:35] <elmo> make: *** [binary-arch]  Error 1
[07:35] <pitti> arghl
[07:36] <pitti> why didn't this turn up in autobuild?
[07:36] <elmo> well it could be a chroot problem
[07:36] <elmo> however pkg-create-dbgsym is installed
[07:36] <pitti> elmo, keescook: sorry, I have to run in 2 minutes, will look into it later
[07:36] <elmo> as is pkgbinarymangler
[07:37] <elmo> hmm, I wonder if it's installed the in the autotest chroots
[07:37] <elmo> yeah, it is
[07:37] <pitti> elmo: pkg-create-dbgsym FTBFS were uncovered in the autotest cycle
[07:37] <pitti> keescook: please mail me the status, gotta go now
[07:38] <keescook> pitti: okay
[07:38] <ProN00b> why are the ubuntu repos so old ?
[07:38] <Burgwork> ProN00b: old?
[07:38] <Burgwork> define old
[07:39] <cjwatson> don't feed the troll
[07:39] <mattions> cjwatson: I'm not a troll.
[07:39] <mattions> I'm triyng to explained..
[07:39] <mattions> explain*
[07:40] <cjwatson> mattions: I wasn't talking to/about you
[07:40] <Burgwork> mattions: he was talking about me
[07:40] <mattions> cjwatson: no problem ...
[07:40] <mattions> sorry..
[07:40] <cjwatson> Burgwork: no, I was talking to you, not about you
[07:40] <mattions> :)
[07:40] <mattions> well..
[07:40] <ProN00b> old as in no audacious, no bmpx, no gaim beta4, old version of gWget
[07:41] <cjwatson> mattions: Debian has libgdl-1-dev 0.6.1-1, as does Ubuntu, so the answer seems to be "nowhere" at the moment
[07:41] <mattions> ok..
[07:41] <crimsun> 3/4 you refer to, ProN00b, are not even main packages. You should ask in #ubuntu-motu.
[07:41] <mattions> thank you.
[07:42] <_ion> crimsun: Remember what the sign said about feeding it? :-)
[07:42] <ProN00b> crimsun, yeah, thats why i said "no"
[07:53] <PSUSI> sladen: yea, I found a bug in debian bts to link to and added a comment to it
[08:00] <imbrandon> whats the status for us to upload to edgy-backports atm ?
[08:01] <imbrandon> iirc from paris we were going to open it for uploads once the RC freeze was in effect ( and i have a package ready is why i'm asking now )
[08:10] <ajmitch> morning
[08:17] <Burgwork> morning ajmitch
[08:17] <sladen> Burgwork: not in #doc ?
[08:18] <Burgwork> sladen: I am there
[08:26] <Mez> hmm... anyone have any idea how to make it so my resolv.conf doesnt keep getting overwritten (or to kill dhclient3 on start - which I believe is what's causing the issues)
[08:27] <tfheen> Mez: change /etc/dhcp3/dhclient-script?
[08:28] <Mez> tfheen: that doesnt exist... 
[08:28] <tfheen> upgrade to a dhcp client from this century and fix it, then.
[08:28] <Mez> it's annoying - it autodects my modem as the damn DNS thing which keeps returning 1.0.0.0 as any IP
[08:58] <ispiked> iwj: ping
[09:06] <tritium> doko: is spadmin gone in edgy?
[09:09] <tritium> doko: oh, found it.  /usr/lib/openoffice/program/spadmin is a symlink to soffice (odd!), but spadmin.bin works
[09:16] <tritium> well, spadmin.bin is what I was looking for, but it doesn't work
[09:33] <nixternal> [14:29:19]  <floydwilde> Hey the Dupage County Courthouse uses Ubuntu
[09:34] <nixternal> oops, wrong channel
[10:06] <blueyed> What was the channel for the ubuntu webmasters again? I'm wondering why there are edgy-*.torrent files, which differ from the ubuntu-6.10.*.torrent ones here: http://torrent.ubuntu.com:6969/
[10:39] <cjwatson> blueyed: that's got nothing to do with the Ubuntu webmasters
[10:39] <cjwatson> blueyed: the edgy-* files are daily builds predating the release
[10:42] <cjwatson> imbrandon: edgy-backports is open for requests via ubuntu-archive as usual. Manual uploads will land in the unapproved queue where archive admins can look at it
[10:42] <imbrandon> cjwatson, perfect, thanks
[10:43] <blueyed> cjwatson: thanks. But they should get removed then, shouldn't they?
[10:44] <cjwatson> blueyed: yeah, they will be at some point
[10:44] <cjwatson> I'll go and look at that now
[10:44] <cjwatson> blueyed: they would get automatically removed when daily builds for feisty start up; but that won't be for a while
[10:45] <cjwatson> oh, they're just xubuntu images by the looks of things
[10:45] <ulaas> apt-get refuses to install sun-java5
[10:46] <ulaas> can anyone check?
[10:47] <cjwatson> blueyed: ok, most of them should be gone once the mirrors sync
[10:47] <cjwatson> ulaas: 'dpkg-reconfigure debconf' and make sure the frontend isn't set to noninteractive. If you originally installed from certain pre-release dapper desktop CDs then you'll have that problem.
[10:48] <ulaas> cjwatson: i surely coming from early edgy development.
[10:48] <ulaas> cjwatson: is 'dpkg-reconfigure debconf' enough?
[10:48] <ulaas> cjwatson: or do i need to do something for the frontend isn't set to noninteractive thing..
[10:48] <cjwatson> early edgy> could be a different problem then. If it's the problem I'm thinking of, then 'dpkg-reconfigure debconf' is sufficient, but if it's some other problem then I do not know.
[10:49] <cjwatson> (the usual default for the frontend is dialog)
[10:49] <cjwatson> ulaas: failing that try 'sudo env DEBCONF_DEBUG=developer apt-get install sun-java5' for a better debug trace that you can put in a bug report
[10:50] <ulaas> cjwatson: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process
[10:52] <cjwatson> ulaas: you have apt or dpkg running in another window
[10:52] <cjwatson> or perhaps suspended
[10:53] <ulaas> cjwatson: checking
[10:53] <cjwatson> (or else you're running debconf-communicate or something by hand but in that case you ought to know enough to put the pieces back together for yourself :-) )
[10:56] <ulaas> cjwatson: i think i seem to fix my problem. thanx. however i am using adept as package manager
[10:56] <ulaas> cjwatson: and if dialog is set to dbconf will it open up a console automagically?
[10:57] <ulaas> cjwatson: or just fail again with a dead apt in the back
[10:57] <cjwatson> I don't know what adept does if a program tries to read from the terminal; sorry
[10:57] <cjwatson> try it
[10:58] <ulaas> cjwatson: i will try to use kde as a frontend.
[10:58] <ulaas> cjwatson: thanks for all dude.
[10:58] <cjwatson> make sure you have libqt-perl installed if you do that
[10:58] <ulaas> sure. thanx
[11:04] <Riddell> ulaas: adept and sun-java packages don't mix
[11:14] <ulaas> Riddell: now they do :)
[11:14] <Riddell> ulaas: how?
[11:14] <ulaas> Riddell:  follow cjwatson's answers to me.
[11:39] <sladen> mjg59: I've just been ignoring usplash say that I can have the moral high-ground of being able to say "well, *I* didn't break it" :)