[12:41] <Kano> hi, how did you parse the UUIDs
[12:42] <Kano> in the fstab
[12:42] <jdong> vol_id $device | sed -ne (just kidding)
[12:42] <jdong> actually that would probably work
[12:43] <Kano> thanks it would
[12:43] <Keybuk> vol_id -u $device
[12:43] <jdong> that works too
[12:43] <Keybuk> (that's how we got them *into* the fstab)
[12:43] <jdong> sheesh Keybuk why doesn't dpkg-parsechangelog have flags like that!
[12:43] <Keybuk> jdong: it does
[12:43] <jdong> really?
[12:43] <jdong> for just printing the version?
[12:45] <jdong> nope it doesn't :(
[12:45] <jdong> oh well, good old sed...
[12:46] <Keybuk> hmm, maybe it doesn't
[12:46] <Keybuk> Kano: mount can accept UUID=... directly
[12:46] <Keybuk> quest scott% sudo mount UUID=43DB-3ADE /mnt
[12:46] <Keybuk> quest scott%
[12:46] <jdong> Kano: are you the Kanotix guy by any chance?
[12:47] <jdong> Keybuk: and doesn't /dev/disk/by-uuid/$uuid exist?
[12:47] <Keybuk> jdong: yes
[12:47] <Kano> jdong: i am
[12:47] <jdong> cool honor to meet you. Love kanotix :)
[12:47] <Kano> why do you have it twice in udev + volumeid package
[12:47] <Keybuk> Kano: have what twice?
[12:47] <Kano> vol_id
[12:47] <Keybuk> we don't
[12:48] <Keybuk> it's only in volumeid
[12:48] <Kano> i diffed it
[12:48] <Kano> same tool at /lib/udev/vol_id
[12:48] <Keybuk> lrwxrwxrwx 1 root root 12 2006-10-17 17:54 /lib/udev/vol_id -> /sbin/vol_id*
[12:48] <Keybuk> it's a symlink ;)
[12:48] <Kano> hmm ok, on debian there is no symlink
[12:48] <Keybuk> yes
[12:48] <Keybuk> Debian and Ubuntu have entirely different udev packages
[12:48] <Kano> only at the lib position, so a script should not use it
[12:49] <Kano> i found some errors directly when i installed ubuntu ;)
[12:49] <Kano> or better kubuntu
[12:49] <Keybuk> oh?
[12:49] <Kano> just counting em ;)
[12:50] <Kano> streamtuner for example needs xmms dependency and streamripper suggest
[12:50] <Kano> and it is in main, no excuse possible ;)
[12:50] <Keybuk> oh, I thought you meant errors in udev
[12:50] <Kano> no not in udev
[12:50] <Keybuk> *shrug* there's always bugs
[12:51] <Keybuk> file them in LP
[12:51] <Kano> sure, but i know this bug is ubuntu specific
[12:51] <jdong> Kano: kanotix is moving to a kubuntu/ubuntu base, right?
[12:52] <Kano> jdong: depends
[12:52] <Kano> when the error count of ubuntu is low enough, or say lower than etch
[12:52] <Keybuk> streamtuner isn't in main
[12:52] <Kano> well maybe universe main
[12:52] <Keybuk> no such thing as univers main
[12:52] <Keybuk> main = supported
[12:52] <Keybuk> universe = community maintained
[12:53] <Kano> kanotix has a differnet package selection
[12:53] <Keybuk> streamtuner doesn't appear to need an xmms dependency?
[12:53] <Kano> well you can configure it differently
[12:53] <Keybuk> it suggests it already
[12:53] <Keybuk> arguably that should be a recommends
[12:54] <Keybuk> anyhoo, file a bug
[12:54] <Keybuk> or, reopen 46124
[12:54] <Kano> well i collect em and put em on my homepage when i am done ;)
[12:55] <Keybuk> put them in Malone, please
[12:55] <Keybuk> otherwise our developers won't be able to process them properly
[12:56] <Kano> will look into it
[12:56] <Kano> just not now, as this is only minor
[12:57] <Kano> the default homepage of firefox is not available in kubuntu
[12:57] <Kano> how is the screen res detected?
[12:57] <Riddell> Kano: should be, except for localised pages, that's a known bug
[12:58] <Kano> of course i installed it for germany
[12:58] <Riddell> mm, yes, not sure how to fix that, altough I'll need to ponder it
[12:58] <Kano> also in the contact module
[12:58] <Riddell> font DPI is set in /etc/init.d/kde-guidance if that's what you were asking
[12:58] <jdong> Kano: dpkg-reconfigure xserver-xorg is used
[01:00] <Kano> jdong: no i mean something like xresprobe
[01:00] <Riddell> Kano: if you have any kubuntu specific questions feel free to join us in #kubuntu-devel any time (although I'm off to bed now)
[01:00] <Keybuk> we use xresprobe
[01:00] <Kano> there is no manpage
[01:00] <Kano> what is the driver needed
[01:00] <Riddell> would be cool to have kanotix using Kubuntu, I'd be interested to hear what the issues are
[01:01] <Kano> Riddell: be sure i find many ;)
[01:02] <Kano> Riddell: for vfat for example is the default fstab line not optimal
[01:03] <Kano> maybe utf8 is short for iocharset=utf8,but then you still miss: shortname=mixed,quiet
[01:04] <Kano> Riddell: did you think of adding ntfs-3g support to pmount
[01:04] <Kano> same options are needed for pmount of course
[01:06] <Kano> like when you mount it with the fstab you are getting errors with media:/
[01:09] <Kano> i found a pcitable file in guidance
[01:09] <Kano> do you really use it
[01:11] <Kano> maybe leftover ;)
[01:47] <Kano> bye for now
[02:07] <spike> cjwatson: I will try tomorrow. thanks
[04:20] <cjwatson> fdoving: good point, fixed
[04:24] <ajmitch> cjwatson: do you have the britney config you use to get the list of uninstallable packages for main? I'd like to check it for universe on a regular basis
[04:26] <cjwatson> ajmitch: it takes an amount of time I've never determined to run it for universe, but certainly in excess of 6 hours on beefy hardware
[04:26] <cjwatson> are you sure? :)
[04:27] <ajmitch> sure
[04:27] <ajmitch> I've got beefy hardware at home
[04:27] <ajmitch> I know it's ram-hungry
[04:30] <cjwatson> ajmitch: ok, well it's http://people.ubuntu.com/~cjwatson/tmp/britney-archive.diff on top of http://people.ubuntu.com/~cjwatson/bzr/britney/cdimage/
[04:30] <cjwatson> few random other changes in there - the trees aren't very clean I'm afraid
[04:32] <ajmitch> great, thanks
[06:11] <twb> Mithrandir: ping?
[06:12] <twb> Mithrandir: I'm gonna take a crack at integrating Debian's casper changes; I've got nothing else to do.
[06:34] <bronson> Is anyone working on linux-vserver for Feisty?
[06:34] <bronson> I remember seeing some discussion on this but I don't see anything in the wiki.
[08:35] <siretart> bronson: I know some ppl who are using linux-vserver with ubuntu dapper and edgy, but they use custom kernels.
[08:47] <twb> Are there Ubuntu equivalents of the Debian New Maintainer and Policy manuals?
[08:48] <Burgundavia> twb: what specifically are you looking for?
[08:48] <twb> Well, I'm already a Debian developer.  I'm not familiar with creating and maintaining packages for Ubuntu.
[08:49] <Burgundavia> right
[08:49] <Burgundavia> are there Ubuntu specific things you want to do to your packages?
[08:49] <twb> I don't know.
[08:50] <Burgundavia> basically, the easiest course is to maintain those packages in Debian and they will get autosynced to Ubuntu
[08:50] <twb> Burgundavia: that assumes that someone from Ubuntu (other than me) wants those packages in Ubuntu.
[08:51] <Burgundavia> what specific packages are they?
[08:51] <twb> I currently maintain paredit-el and mg in Debian.
[08:51] <twb> I mean, I don't even know what the process is that determines if/when/how Debian packages become Ubuntu packages.
[08:52] <twb> That is the sort of information I would expect to find in the newmaint and policy manuals.
[08:52] <Burgundavia> right
[08:53] <Burgundavia> Ubuntu takes nearly everything from Debian and simply rebuilds it
[08:53] <Burgundavia> http://www.ubuntu.com/ubuntu/relationship <-- this is a good doc
[08:53] <twb> Similarly, when an Ubuntu user reports a bug (via Ubuntu's reporting process), what is the process whereby it gets pushed to me, the Debian maintainer?
[08:53] <Burgundavia> http://www.ubuntu.com/ubuntu/components
[08:53] <Burgundavia> as it that
[08:53] <twb> Looking...
[08:54] <Burgundavia> there is no formal method of getting bugs from Ubuntu to Debian, currently
[08:54] <twb> Is there a committee or working group currently investigating such issues?
[08:55] <Burgundavia> https://wiki.ubuntu.com/DCT
[08:56] <lucas> Burgundavia: no.
[08:56] <lucas> DCT has been dead for months, because nobody is really interested in it
[08:56] <Burgundavia> lucas: ?
[08:56] <Burgundavia> ah, yes
[08:56] <lucas> it's a bit easy to point to it each time a DD asks about feeding bugs back to debian
[08:57] <Burgundavia> lucas: the problem is mostly time
[08:58] <siretart> twb: you might find https://wiki.ubuntu.com/DeveloperResources useful
[09:02] <twb> typo, http://www.ubuntu.com/ubuntu/licensing, first paragraph "and by default" should be "and be installed by default"
[09:09] <minghua> twb: please report a bug against ubuntu-website: https://bugs.launchpad.net/products/ubuntu-website/+filebug
[09:09] <minghua> twb: thanks
[09:09] <twb> OK.
[09:10] <twb> If someone duploads an Ubuntu package which has (closes Malone #NNNNNN) or similar in the ChangeLog, does Malone automatically know about that and mark the bug as done in that version?
[09:11] <minghua> twb: I think right now it doesn't.   ;)
[09:32] <Mithrandir> crimsun: hi dude, how did the Xubuntu testing go yesterday?
[09:33] <siretart> twb: malone offers an email interface, so you can report and manipulate bugs via gpg signed mail
[09:33] <bronson> Is there any way to get a 2.6.18 version of the Ubuntu kernel?  Or did BenC go straight from .17 to .19?
[09:34] <twb> siretart: right, but I need to login at least once via the web ui to enable the mail UI.
[09:34] <bronson> I'd like a 2.6.18 so I can apply a recent linux-vserver patch.
[09:34] <Mithrandir> bronson: there's no 2.6.18 version, no.
[09:35] <bronson> Is anyone talking about packaging linux-vserver anymore?
[09:35] <bronson> I'm wondering how much effort I should put into making generic, Feisty-ready packages.
[09:35] <crimsun> Mithrandir: I haven't tested i386 beyond 20061204 daily, but I'll pull down i386 20061205 daily-live and daily now
[09:36] <crimsun> Mithrandir: the ppc & amd64 testers are likely asleep atm
[09:36] <Mithrandir> crimsun: cheers.
[09:36] <Mithrandir> crimsun: slackers. :-P
[09:36] <Mithrandir> crimsun: any idea when they'll be around?
[09:36] <Mithrandir> hi Andreas
[09:37] <bronson> Hm...  Guess I'll go straight to 2.6.19.  How exciting.  :)
[09:37] <bronson> Mithrandir: thanks
[09:40] <Mithrandir> hmm, publishing herd-1 as herd-1 and not knot-3 is probably a good idea..
[09:41] <Mithrandir> (history ftw)
[09:44] <Burgundavia> Mithrandir: are we about to go live? shall I move it over to the website?
[09:44] <crimsun> Mithrandir: found an amd64 & ppc 20061205 daily-live tester
[09:44] <Mithrandir> Burgundavia: yes, please.
[09:45] <Burgundavia> moving
[09:45] <Mithrandir> Burgundavia: can you do the kubuntu one too or should I chase down a kubuntu person for that?
[09:45] <Mithrandir> crimsun: yay, excellent.
[09:45] <Burgundavia> Mithrandir: I don't have access to the Kubuntu website
[09:45] <Mithrandir> Burgundavia: ok.
[09:45] <Burgundavia> for the Knot pages, they were just left on the wiki
[09:46] <Mithrandir> Riddell: do you want the herd 1 page to be moved to the main kubuntu website or is it ok to have it on the wiki?
[09:46] <Riddell> Mithrandir: wiki is fine
[09:47] <Mithrandir> Riddell: ok
[09:47] <Riddell> but I should check it for sanity first, what's the URL?
[09:47] <pitti> Good morning
[09:47] <Mithrandir> Riddell: https://wiki.kubuntu.org/FeistyFawn/Herd1/Kubuntu
[09:47] <Mithrandir> at least that was the one I found
[09:48] <Riddell> that's the one
[09:48] <Mithrandir> http://err.no/tmp/herd-1.txt is the announcement ; proofreading would be nice.
[09:48] <Mithrandir> (yes, the ubuntu URL will then need changing)
[09:50] <Burgundavia> Mithrandir: should probably link directly to https://www-master.ubuntu.com/testing/herd1
[09:51] <Mithrandir> s/-master// ?
[09:51] <seb128> Mithrandir: you can mention GNOME 2.17.2 too to the "The primary changes from Edgy"
[09:52] <Burgundavia> "We refer to..."
[09:52] <Mithrandir> seb128: I moved that bit from the announcement to the wiki page; do you disagree about that?
[09:53] <Burgundavia> well, I need to sleep
[09:53] <Burgundavia> page is up and /testing links to /testing/herd1
[09:53] <seb128> Mithrandir: no, that's fine with me. You mentioned 2.6.19 in the mail so I didn't notice you did that ;)
[09:53] <Mithrandir> seb128: yeah, since it's common between all variants.
[09:53] <Mithrandir> Burgundavia: cheers.
[09:53] <seb128> right
[09:56] <Riddell> Mithrandir: announcement reads good to me
[09:57] <dholbach> good morning
[09:59] <pitti> hi dholbach
[10:01] <dholbach> hi pitti
[10:06] <ajmitch> morning dholbach
[10:06] <dholbach> hey ajmitch
[10:09] <sivang> morning
[10:11] <dholbach> doko: good morning - we had a question about eclipse over here: https://lists.ubuntu.com/archives/ubuntu-motu/2006-December/001000.html
[10:15] <cjwatson> Mithrandir: all the current CD images should already have hw-detect/start_pcmcia=false, shouldn't they?
[10:16] <Mithrandir> cjwatson: oh, I didn't see a response to whether you fixed that or not.
[10:16] <cjwatson> I did. I'll check that they've all been rebuilt
[10:16] <Mithrandir> cjwatson: if it's there, I'll just add a note saying that pcmcia is disabled.
[10:16] <Mithrandir> cjwatson: Kubuntu might not have picked it up, since we didn't do the last rebuild for those.
[10:16] <cjwatson> right, my thought too, also Xubuntu
[10:17] <doko> dholbach: you can't use uupdate with a zip file
[10:17] <Mithrandir> cjwatson: ok, expanded a little bit now.  Looks better?
[10:18] <cjwatson> Mithrandir: Xubuntu isn't fixed, but all the others are, including Kubuntu
[10:18] <cjwatson> Mithrandir: so s/Ubuntu and Edubuntu/Ubuntu, Kubuntu, and Edubuntu/ but otherwise fine
[10:18] <cjwatson> is the read-from-wrong-terminal thing new in feisty? what changed?
[10:19] <dholbach> doko: I passed on the message
[10:19] <cjwatson> Mithrandir: otherwise all looks fine
[10:19] <Mithrandir> cjwatson: updated the first one.
[10:20] <cjwatson> Mithrandir: s/We refer/Please refer/ maybe
[10:20] <Mithrandir> cjwatson: the casper thing is some weird usplash/upstart interaction.  I'm going to just make casper use the input mechanism in usplash, but I just haven't had time.
[10:20] <Mithrandir> cjwatson: fixed.
[10:20] <cjwatson> it's always weird reading your announcements. I can see the bits that were descended from announcements I wrote. :)
[10:20] <Mithrandir> heh, yeah, it's a cut&paste job from the earlier ones.
[10:21] <cjwatson> s/The herd images/The Herd images/?
[10:21] <Mithrandir> sure, fixed
[10:21] <Mithrandir> the URLs need checking too, but that doesn't happen until I do sync-mirrors
[10:23] <doko> cjwatson: updated the changelog and description of bug 68396 and uploaded to edgy-proposed. yes, sd.sal_uInt32_aslong.diff the is the fix for the amd64 crash
[10:23] <Ubugtu> Malone bug 68396 in openoffice.org "openoffice.org for edgy-updates" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68396
[10:23] <Mithrandir> doko: I presume you saw the sun-java5 build failure on ppc?
[10:24] <cjwatson> doko: thanks, looks better, will process this morning
[10:27] <doko> Mithrandir: yes, do you want to port it to powerpc? ;)
[10:27] <Mithrandir> doko: no, but it should probably be PaS-ed
[10:30] <Mithrandir> maswan: can you give us a cdimage mirroring run when I ask for it?
[10:31] <maswan> Mithrandir: sure
[10:31] <doko> Mithrandir: agreed, then on sparc and hppa as well
[11:05] <sivang> mjg59: is there anything we do to shutdown idle wlan network interfaces by default?
[11:15] <sivang> Riddell: I managed to get Belhaven St. Andrew's Ale around here, some private dude that periodically visits the UK and scotland in particular started to import small quantities just for the love of it. There's also a "Scottish Ale" by Belhaven which I didn't taste yet.
[11:17] <Riddell> excellent!
[11:23] <sivang> Riddell: sure is, apparently there's few folks around the north and center of the country then know about it (among them is that importer dude) ;)
[11:24] <ailean> Belhaven Best is a tasty beer
[11:24] <sivang> Riddell: right, I need to call him and suggest he'll bring some Best(s) as well
[11:24] <ailean> Riddell, can i ask you a couple of qs about becoming linux certified?
[11:25] <ailean> Riddell, i know you're in scotland too, so i was wondering about where to go to learn it and where to go to take the exam
[11:25] <maxb> Hi. There is a bug filed against apache2 in launchpad with a fairly thorough analysis of the problem, such that it should not be difficult to fix, but the maintainer does not seem to have noticed. What is the best way for me to politely attract the attention of someone who could fix the package? Thanks.   ( the bug is https://launchpad.net/bugs/62748 )
[11:25] <Ubugtu> Malone bug 62748 in subversion "2.0.55-4ubuntu4 update causes svn failure" [Undecided,Confirmed]
[11:26] <Riddell> ailean: #kubuntu better
[11:26] <ailean> ok
[11:27] <Mithrandir> maxb: it'll be fixed when apache 2 is upgraded to 2.2
[11:27] <Ubugtu> Apache bug 2 in Layout "Just testing the Boogzeela setup for log4j" [Normal,Closed: fixed]  http://issues.apache.org/bugzilla/show_bug.cgi?id=2
[11:28] <pitti> haha
[11:28] <pitti> Mithrandir: just for the record, apache2 is currently on my merge list, but infinity asked me not to merge 2.2 ATM
[11:30] <maxb> Well... ok... but it renders libsvn-javahl unusable, so any chance of it being considered for an edgy-update? And if not, could there be an official comment in the bug explaining the situation?
[11:31] <spike> cjwatson: hi, you around by any chance?
[11:32] <spike> I had a look into that parted_devices
[11:32] <spike> unfortunately it's not very helpful, as it just prints the device as in fdsik, /dev/cciss/c0d0<PHONE_NUMBER>80    Compaq Smart Array
[11:33] <spike> I'm running it on the installed system, dunno if that makes any difference, tho
[11:33] <spike> cjwatson: can I just use that /dev/cciss/c0d0 in the preseed file?
[11:34] <cjwatson> spike: that was the point of getting you to run parted_devices, and why it is helpful. the device names it prints are what you can preseed
[11:34] <cjwatson> so yes
[11:34] <cjwatson> would be better to run it in the installer, but it *should* be the same in edgy
[11:35] <cjwatson> if this is dapper, then you should definitely run it in an interactive installer session to check
[11:35] <spike> yeah, it's dapper
[11:36] <spike> cjwatson: can I run the install manully without preseeding, and then choose to drop to a shell? will be the command available via busybox?
[11:37] <doko> cjwatson: do you know the origin of the gfxboot patch for syslinux?
[11:37] <cjwatson> spike: alt-f2 gives you a shell (alt-f1 to return); yes, the command will be available
[11:37] <cjwatson> doko: suse
[11:38] <doko> cjwatson: do you have an URL for their packages?
[11:38] <cjwatson> doko: afraid not, I don't seem to have kept it
[11:40] <spike> cjwatson: ok, cheers. btw, the device will be different anyway, and I dont wanna dup all my preseed file just for those bunch of boxes. I read there are means to include custom bits at runtime, not quite sure what's the right way to do it
[11:40] <spike> can I just run something with the early_command and the outpu will be included into the preseed file?
[11:40] <cjwatson> not as such
[11:41] <cjwatson> there are some related possibilities
[11:41] <crimsun> Mithrandir: i386 daily fails pretty badly on my hardware (either can't detect atapi cdrom or partitioner fails), but daily-live works fine (both clean install and resizing ntfs)
[11:42] <cjwatson> spike: you could try something like this in an early_command:
[11:42] <cjwatson> . /usr/share/debconf/confmodule
[11:42] <Mithrandir> crimsun: hmm, ok.  Do you want me to drop Xubuntu for herd 1 or respin?  I don't want to hold up the others any longer.
[11:43] <cjwatson> db_set partman-auto/disk "$(parted_devices | head -n1 | cut -f1)"
[11:43] <crimsun> Mithrandir: no need to block on xubuntu
[11:43] <cjwatson> i.e. use first disk no matter what. might need to be careful to exclude floppies and CDs there
[11:43] <Mithrandir> crimsun: ok, I'll drop it for Herd 1 and wish you better luck next time around, then.
[11:44] <crimsun> Mithrandir: ok, thanks
[11:45] <admin123> :)
[11:47] <Mithrandir> maswan: please sync now.
[12:02] <maswan> Mithrandir: running
[12:06] <twb> On my launchpad `homepage', is it appropriate to include a link to my CV?
[12:07] <pitti> twb: I don't see why not, it's the place for personal information after all (disclaimer: purely my personal opinion)
[12:08] <twb> That was my expectation.  Some organizations have vehement views about linking to such stuff.
[12:08] <shackan>  why?
[12:09] <twb> I guess because its the thin end of the wedge that link-bombing wiki pages is the thick end of.
[12:18] <sivang> Keybuk: morning
[12:18] <Keybuk> hey
[12:18] <sivang> Keybuk: I wonder if you had seen my bug report already, or you need to grab your coffe before checking out ifupdown and possibly related to upstart bugs ;)
[12:19] <Keybuk> I just read it
[12:19] <Keybuk> almost certainly kernel
[12:21] <sivang> Keybuk: okay, so how can we work this out? I'm using 2.6.19-7-lowlatency that crimsun tells me still doesn't really include the pre-empt "fix"
[12:22] <sivang> Keybuk: (I tried to use the lowlate kerns due to http://sivang.blogspot.com/2006/12/surely-not-way-to-do-performance.html)
[12:26] <Keybuk> sivang: no idea
[12:26] <Keybuk> find out when it broke
[12:28] <sivang> Keybuk: sure, how do I debug something like that?
[12:29] <Keybuk> sivang: the usual way
[12:29] <Keybuk> find out how to make it fail consistently
[12:29] <Keybuk> find out how to make it work consistently
[12:29] <Keybuk> bisect the difference
[12:30] <sivang> Keybuk: that's easy, everytime I ifup eth1, it just shuts down the power, consistently :)
[12:31] <sivang> Keybuk: to make it work, I just ifdown eth1, and dhclient eth1
[12:31] <sivang> Keybuk: ;)
[12:31] <Keybuk> ifdown and dhclient ?!
[12:31] <Keybuk> Now, since about a couple of upgrades, ifupdown seems to have gone mad
[12:31] <Keybuk> completely:
[12:31] <Keybuk> --
[12:31] <popey> is there a method for proposing a package for inclusion on the live/alternate CD?
[12:31] <Keybuk> so find out which upgrade broke it
[12:32] <sivang> Keybuk: eh :)
[12:32] <Keybuk> that's a quote from your bug
[12:32] <Keybuk> you say something broke it
[12:32] <Keybuk> what broke it?
[12:32] <StevenK> If the breakage shutdowns the machine, it's a little hard to diagnose, no?
[12:33] <sivang> Keybuk: If I had known, I would have been a miilionaire :p
[12:33] <Keybuk> sivang: find out then
[12:33] <Keybuk> you have /var/log/dpkg.log
[12:33] <Keybuk> roll back each upgrade until you find the one that makes it work again
[12:33] <Keybuk> try stock ubuntu kernels
[12:33] <sivang> Keybuk: I'l see what I can come up with, or just write  a script that probes for DNS and when it can't resolve do the ifdown, dhclient dance for me automatically :)
[12:34] <Keybuk> if you do that, I'll reject the bug
[12:34] <sivang> Keybuk: okay, thakns for the guidance
[12:34] <sivang> Keybuk: that was a joke , seriously
[12:34] <Keybuk> this is obviously not happening for anyone else
[12:34] <Keybuk> there's a lot of ipw2200 users out there
[12:34] <Keybuk> so it must be something you've installed on your machine, or some change you've made, that's caused it to break
[12:35] <Keybuk> check for scripts in /etc/network/*
[12:35] <Keybuk> also try booting into windows
[12:35] <Keybuk> the card might be wedged in some invalid state that only the windows driver can fix
[12:36] <Keybuk> I don't know if that affects the ipw2200 specifically, but it's a common fix for firmware cards
[12:36] <sivang> Keybuk: could it be the hardware just broke?
[12:36] <Keybuk> yes
[12:37] <sivang> Keybuk: (it works in windows quite fine, although I've had a couple of simialr mishaps there as well)
[12:37] <Keybuk> ok, if it works in windows, and continues to not work in Linux; I'd suggest the following
[12:37] <Keybuk> - install stock ubuntu kernel (not the low-latency one)
[12:37] <Keybuk> - check /etc/network/* for problems
[12:37] <Keybuk> - check packages are all up to date, and not from other sources
[12:38] <Keybuk> - is it just "ifup" that breaks?  what about "ifconfig eth1 up" ?
[12:38] <mnepton> - how about invoke-rc.d network restart
[12:40] <sivang> mnepton: that's like doing /etc/init.d/network restart no?
[12:42] <spike> cjwatson: where's the limit with that? cant I just run a shell script I wget from somewhere that will set all the answers I need?
[12:43] <mnepton> sivang: it is
[12:43] <cjwatson> spike: sure, that's possible too, noting that early_command only runs after the preseed file has been fetched of course
[12:43] <mnepton> except you should use invoke-rc.d these days)
[12:43] <cjwatson> spike: depends on your personal tolerance for maintainability of twisty little piles of shell scripts
[12:44] <spike> cjwatson: "after the preseed file has been fetched of course", uhm, does that mean I cant modify the answers at that time? ie, from a completely external script
[12:45] <spike> or couldnt I just wget some script that would rewrite the preseed file, ie, replace variables/placeholders based on the hw/machine
[12:45] <Keybuk> mnepton: that's a bogus command
[12:45] <Keybuk> a) you should not use invoke-rc.d; that's for maintainer scripts only
[12:45] <spike> cjwatson: the idea idea I had was generating the preseed file on the fly, so wget actually calls a cgi that dumps a preseed file run-time generated based on the ip
[12:45] <Keybuk> b) the network init script isn't what starts hardware network interfaces anyway
[12:46] <sivang> Keybuk: no luck, the only thing that manages to bring power up on the interface is ifdown eth1
[12:47] <Keybuk> sivang: does ifconfig eth1 down bring power up?
[12:47] <cjwatson> spike: there's an example of doing this in the installation-guide, under preseed/include_command; see there
[12:47] <spike> nmmh, k, ta
[12:48] <StevenK> cjwatson: Should I remind you at some further point to please accept the wlassistant upload to edgy-updates?
[12:48] <cjwatson> by "after the preseed file has been fetched", I simply meant the stage of the installer; your preseed file could just be early_command or whatever and nothing else
[12:48] <cjwatson> StevenK: no need
[12:48] <sivang> Keybuk: strangely, no
[12:48] <Mithrandir> maswan: it seems the world is a bit slow now and I really want to release and we're apparently fine when it comes to bandwidth, so I'll drop ACC from the herd 1 announce this time.
[12:49] <Keybuk> sivang: ok, then it's likely a script in /etc/network/*; what do you have in there?
[12:49] <Keybuk> and what's in /etc/network/interfaces ?
[12:49] <cjwatson> spike: note that preseed files are basically just fed to debconf-set-selections. You can do the same thing either in the same way or by using debconf commands directly. If you want to do funky stuff, apt-get source preseed and see how it does it.
[12:49] <StevenK> cjwatson: Okay, I'll continue to exercise patience. Thanks. :-)
[12:50] <\sh> Mithrandir: do we have a good traffic report for dapper and edgy for mirrors? I would like to try to setup an official mirror here in our company
[12:51] <Mithrandir> \sh: ask<EMAIL_ADDRESS>[12:51] <StevenK> \sh: What arches?
[12:51] <elmo> (the answer is no we don't.  it varies from mirror to mirror.  a traffic report would be non-sensical)
[12:51] <\sh> StevenK: all
[12:51] <StevenK> \sh: And source?
[12:51] <sivang> Keybuk: /me checks
[12:51] <\sh> StevenK: 10GBit/s needs some action
[12:52] <StevenK> \sh: Oh, I thought you were talking size.
[12:52] <Znarl> \sh : Can you join #ubuntu-mirrors and we'll help you setup a mirror, if you like.
[12:53] <\sh> StevenK: oh I think I can host the complete source/binary collection of debian/ubuntu/redhat/suse on one machine ;) 7TB as Raid6 is enough on one machine? if not I use 3 or 4 of them ;)
[12:53] <StevenK> \sh: Bastard. :-P
[12:53] <Mithrandir> \sh: if you have the bandwidth and disk space, cdimage mirrors are always useful.
[12:53] <\sh> Znarl: sure, but I need some infos about traffic, bandwidth, what you need as lowest level bandwidth etc. to give it to my managers...to decide...the rest will be easy then :)
[12:53] <Mithrandir> (it's only close to 1T, but still)
[12:54] <\sh> Mithrandir: shouldn't be a problem with space...not even bandwidth...I just need an ok of my managers :)
[12:55] <\sh> and right now it's a good time to ask for it :)
[12:55] <Znarl> \sh : You're in the US?  So your mirror will be listed under United States?
[12:55] <\sh> Znarl: germany...with decix peering...and officially 20GBit/s level 3 connection...europes finest private datacenter
[12:56] <fernando> \sh: i can to have a ssh access in this poor machine/bandwidth/storage? heheheh :P
[12:57] <Znarl> \sh : A full mirror of releases.ubuntu.com is just under 30gigs.  archive.ubuntu.com is around 190gigs and slowly growing.
[12:57] <fernando> s/i\ can/can\ i/
[12:57] <dade`> why do you escape spaces ?
[12:58] <fernando> i need to review my machine/bandwidth concepts hehehe
[12:59] <StevenK> dade`: Because he isn't quoting it.
[12:59] <StevenK> Mithrandir: Nice! Well done.
[12:59] <Mithrandir> yay us! :-)
[01:00] <highvoltage> Ubuntu GNU/Herd 1 :)
[01:00] <HiddenWolf> congrats
[01:00] <highvoltage> they beat FSF to it!
[01:00] <sivang> highvoltage: hehe
[01:00] <bhale> didnt we have a Herd animal before?
[01:00] <doko> cjwatson: updated syslinux. I would appreciate a review before upload to feisty: http://people.ubuntu.com/~doko/syslinux/
[01:17] <pitti> wow, ubuntu-changes spam \o/
[01:17] <ajmitch> yay!
[01:18] <spike> cjwatson: /bin/sh: parted_devices: not found , using BusyBox v1.01 (Debian 1:1.01-4ubuntu3) Built-in shell (ash)
[01:18] <spike> booting dapper amd64 ubuntu-installer
[01:19] <cjwatson> doko: meep, um, I'm buried in libparted right now, later
[01:19] <cjwatson> doko: please try a modified Ubuntu CD with your version of syslinux on it to make sure that gfxboot works
[01:19] <jdub> open("/var/cache/apt/pkgcache.bin", O_RDONLY) = 5
[01:19] <jdub> fcntl64(5, F_SETFD, FD_CLOEXEC)         = 0
[01:19] <jdub> fstat64(5, {st_mode=S_IFREG|0644, st_size=9749120, ...}) = 0
[01:19] <jdub> mmap2(NULL, 9749120, PROT_READ, MAP_SHARED, 5, 0) = 0xb7246000
[01:19] <jdub> stat64("/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_feisty_main_binary-i386_Packages", {st_mode=S_IFREG|0644, st_size=5684810, ...}) = 0
[01:19] <jdub> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[01:20] <jdub>
[01:20] <cjwatson> spike: continue through the installer a bit before running it
[01:20] <StevenK> jdub: Neat.
[01:20] <jdub> $ sudo apt-get upgrade -u
[01:20] <jdub> Segmentation fault (core dumped)
[01:20] <jdub>
[01:20] <cjwatson> spike: it won't be available right at the start. this is normal.
[01:20] <jdub> ^ awesomo 4000!
[01:20] <seb128> could anybody give a retry to yelp on all arches?
[01:20] <spike> cjwatson: oh, I see, thanks.
[01:20] <StevenK> jdub: Now you have a core file, you can use pitti's leet debug debs to figure it out.
[01:21] <sivang> jdub: heh
[01:21] <StevenK> Oh no, qdvdauthor, you will not do this to me.
[01:22] <StevenK> Sigh. qdvdauthor's upstream, *please* learn to reap your children when you get a SIGCHLD!
[01:23] <seb128> jdub: does removing /var/cache/apt/*.bin fix it?
[01:23] <dholbach> jdub: try moving away pkgcache.bin - I think mvo is aware of the problem
[01:23] <seb128> dholbach: too slow young padawan :p
[01:23] <jdub> haha
[01:23] <dholbach> pfft
[01:23] <seb128> ;)
[01:23] <gnomefreak> seb128: yes it fixes it he uploaded a fix for it
[01:23] <Treenaks> The Dynamic Duo Strikes Again :)
[01:23] <jdub> seb128, dholbach: rock on, thanks :-)
[01:24] <dholbach> :)
[01:24] <seb128> np
[01:24] <seb128> jdub: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=81829 for info
[01:24] <Ubugtu> Debian bug 81829 in apt "segfaults" [Grave,Open]
[01:25] <gnomefreak> seb128: libapt-front_0.3.9ubuntu4 should fix the apt crashing
[01:25] <seb128> gnomefreak: I don't have a such lib installed
[01:26] <gnomefreak> he uploaded it this morning sometime according to the bug report
[01:26] <gnomefreak> bug 61708
[01:26] <Ubugtu> Malone bug 61708 in apt "apt-index-watcher corrupts the apt cache database" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61708
[01:27] <seb128> gnomefreak: it looks like that change prevent the corruption for apt-index-watcher
[01:27] <seb128> gnomefreak: it doesn't fix apt crashing when the index is corrupted
[01:28] <seb128> gnomefreak: apt is not using libapt-front
[01:28] <gnomefreak> the index is corrupting apt/cache
[01:29] <maswan> Mithrandir: *nods*
[01:30] <sivang> Keybuk: do we have anything to reduce power consupmtion when a NIC is inactive that could come in the way?
[01:30] <Keybuk> sivang: only the driver
[01:31] <Keybuk> that I know of, anyway
[01:31] <sivang> Keybuk: is it reasonable for a straying wpa key specificed to the interfaces file to cause the odd ifdown to bring NIC power up symptom?
[01:32] <Keybuk> no
[01:32] <Keybuk> could be wpa supplicant bug
[01:33] <sivang> hmm, I wonder if I could just remove wpa supplicant and leave without it, oh it's part of -minimal
[01:38] <cjwatson> doko: I wish you'd stuck with the applied-patches scheme I was using
[01:38] <maswan> Mithrandir: I don't quite know why it is slow, but it is updating
[01:38] <cjwatson> dpatch--
[01:39] <Keybuk> cjwatson: applied-patches hurts my brain
[01:39] <Keybuk> I never remember to update them
[01:39] <cjwatson> it's better than dpatch
[01:39] <doko> cjwatson: then please show me where upstream has the single patches. the srpm only has one diff.
[01:39] <cjwatson> doko: please make sure that you carried over my patches
[01:39] <doko> I didn't convert to dpatch, that was the debian maintainer
[01:40] <cjwatson> ah, if they did that then I guess we have to :-(
[01:40] <cjwatson> IIRC I had to extract it from the suse diff
[01:40] <Keybuk> cjwatson: I dislike dpatch more than the next man, but at least there's a script to deal with it
[01:40] <Keybuk> I don't need to fiddle with applying and unapplying, just dpatch-edit-patch
[01:41] <cjwatson> *shrug* it's moot in this case if the packaging's already changed in Debian; I hadn't realised that
[01:42] <\sh> Mithrandir:congrats to the herd 1 release :)
[01:42] <Mithrandir> thanks. :-)
[01:45] <sladen> the FSF will be pleased
[01:45] <sladen> they've been waiting 20years for that
[01:46] <cjwatson> doko: you seem to have discarded my DATE/HEXDATE fix and my fix to ensure the screen gets cleared when switching back to text mode on localboot
[01:46] <cjwatson> (3.11-2ubuntu5)
[01:47] <cjwatson> and 3.11-2ubuntu4
[01:48] <doko> cjwatson: do you still know what exactly to remove from the suse diff?
[01:49] <cjwatson> not offhand
[01:50] <Keybuk> Mithrandir: you misspelled "Hurd" in the announcement
[01:50] <cjwatson> doko: sorry, afraid it requires actual thought ;-)
[01:50] <Mithrandir> Keybuk: I considered using "The Hurd, or the GNU Hurd, is the set of servers, it is not an operating system, and since it runs in user space, it is not what we call a kernel. ``Hurd'' means ``Hird of Unix-Replacing Daemons'' and ``Hird'' means ``Hurd of Interfaces Representing Depth'', but all of them are spelled like the word ``herd'', which is the real meaning of this name: the GNU Hurd is a herd of gnus." as the quote..
[01:52] <\sh> argl...launchpad fools me
[01:53] <Keybuk> The launchpad strikes!  You feel fooled!
[01:55] <\sh> http://bugs.launchpad.net/distros/ubuntu/feisty/+source/xdrawchem doesn't show any open bugs to this source..but http://b.l.n/distros/ubuntu/+source/xdrawchem/+bugs shows open bugs...that's definitly a user fooling experience ;)
[01:57] <fbond> keybuk: ping
[01:57] <\sh> or we have to change the "file sync request bug reports" a bit, to include the release
[01:57] <Keybuk> fbond: hi
[01:58] <fbond> Keybuk, hi
[01:58] <fbond> I am supposed to contact you Re: mounting usbfs by default
[01:58] <fbond> https://bugs.launchpad.net/distros/ubuntu/+bug/70968
[01:58] <Ubugtu> Malone bug 70968 in Ubuntu "Ubuntu Should Automatically Mount usbfs At Boot Time" [Wishlist,Needs info]
[01:59] <Keybuk> usbfs is mounted by default
[01:59] <Keybuk> quest scott% ls /proc/bus/usb
[01:59] <Keybuk> 001/  002/  devices@
[01:59] <Keybuk> admittedly, that's not usbfs, but a gross hack
[01:59] <Keybuk> but the gross hack should be sufficient for your needs
[02:00] <fbond> hmm.  My knowledge may not be technical enough in this area to argue the case well.
[02:00] <Keybuk> what's the problem?
[02:00] <Keybuk> perhaps we can work out from there
[02:00] <fbond> I have packaged midisport-firmware for universe.
[02:00] <doko> cjwatson: suse has integrated your two patches
[02:00] <Keybuk> ok ...
[02:00] <fbond> This package uses libusb and udev to load firmware onto the USB device.
[02:01] <Keybuk> this uses /proc/bus/usb/XXX/YYY to load the firmware?
[02:01] <Keybuk> right
[02:01] <fbond> The current situation doesn't seem to be conducive to this approach...
[02:01] <Keybuk> which current situation?
[02:01] <fbond> Edgy
[02:01] <Keybuk> edgy should be fine
[02:01] <Keybuk> assuming you're using the release
[02:01] <Keybuk> may I see the package?  is it in the archive?
[02:01] <fbond> Keybuk, it didn't quite make it into edgy
[02:02] <Keybuk> is it in feisty?
[02:02] <fbond> let me see if it's lying around on revu or elsewhere ...
[02:02] <fbond> crimsun had suggested I bring this up with you.  He knows more technical details related to the problem.
[02:02] <Keybuk> I suspect crimsun's knowledge is out of date
[02:02] <fbond> http://revu.tauware.de/details.py?upid=3063
[02:02] <fbond> Perhaps.
[02:03] <Keybuk> we implemented a udev-driven /proc/bus/usb for edgy
[02:03] <fbond> Well, my device does eventually work, if I do one of the following after booting: unplug and re-plug the device or restart udev
[02:04] <Keybuk> have you mounted usbfs yourself by hand?
[02:04] <cjwatson> doko: I checked, and that did not appear to be the case.
[02:04] <cjwatson> doko: unless you mean in a patch that wasn't in the source package you posted
[02:04] <cjwatson> in which case, great
[02:04] <fbond> Keybuk, I had done that before, but am not currently.
[02:04] <Keybuk> fbond: is there anything in /proc/bus/usb
[02:04] <fbond> yes
[02:04] <Keybuk> is /proc/bus/usb/devices a symlink?
[02:05] <cjwatson> \sh: the release should only be used when backporting fixes for bugs to earlier releases
[02:05] <Keybuk> oh, I see
[02:05] <fbond> Keybuk, yes
[02:05] <Keybuk> the udev rules in the orig.tar.gz are COMPLETELY wrong
[02:05] <Keybuk> that's why it doesn't
[02:05] <Keybuk> work
[02:05] <fbond> oh
[02:05] <cjwatson> \sh: so no, the sync policy should stay as it is
[02:05] <fbond> interesting
[02:05] <Keybuk> totally, and utterly bogus
[02:06] <Keybuk> they should like something like
[02:06] <doko> * Mon Jan 23 2006 -<EMAIL_ADDRESS>[02:06] <doko> -<EMAIL_ADDRESS>support big-endian cpio archives (#140119)
[02:06] <doko> - support direct driverupdate loading from CD-ROM (feat #152):
[02:06] <doko>   o initrd loading errors are no longer fatal
[02:06] <doko>   o if initrd name starts with '+' ask for CD change
[02:06] <doko> * Wed Dec 14 2005 -<EMAIL_ADDRESS>[02:06] <doko> - really disable text messages
[02:06] <doko> -<EMAIL_ADDRESS>turn off graphics for localboot
[02:06] <doko> which is in the diff
[02:06] <Keybuk> ACTION=="add", SUBSYSTEM=="usb_device", SYSFS{idVendor}=="0763", SYSFS{idProduct}=="1001", RUN+="@fxload@ -s<EMAIL_ADDRESS>-I<EMAIL_ADDRESS>[02:07] <Keybuk> note the use of the usb_device subsystem, not the usb subsystem (which means you can drop the devpath match)
[02:07] <Keybuk> that way the RUN rule will be run *after* the device appears in /proc/bus/usb -- rather than before

[02:07] <fbond> Hmm.  Upstream has not been terribly friendly to me, unfortunately.  I do not know if this will forward well.
[02:07] <fbond> But, at least, I can get this into Feisty in working order.
[02:08] <Keybuk> udev is still in heavy development
[02:08] <Keybuk> so what rules work for one distribution, with one version of udev, will likely not work on another
[02:08] <fbond> I see.
[02:08] <cjwatson> doko: I checked the diff you posted, and it was definitely missing the DATE/HEXDATE fix, and it looked to me as if it at least did not have all of the localboot fix
[02:08] <Keybuk> changing the SUBSYSTEM is the key here
[02:08] <fbond> udev remains to be grey magic to many of us who consider ourselves pretty familiar with Linux systems.
[02:08] <Keybuk> the "usb" subsystem is responsible for the device itself, and whatever interfaces it exposes
[02:08] <Keybuk> it doesn't have anything in /dev usually
[02:09] <Keybuk> the "usb_device" subsystem is responsible for the raw access devices
[02:09] <Keybuk> you want the raw access devices, so you want that subsystem
[02:09] <fbond> Is there a good source of information that covers this kind of topic?
[02:09] <StevenK> fbond: That's because it is. The kernel sends a bunch of strings to a userspace program that just does stuff, based on rules that look somewhat evil. Complete magic.
[02:10] <Keybuk> StevenK: bah, it's easy
[02:10] <Keybuk> fbond: lots
[02:10] <fbond> StevenK, well I ain't afraid of a little magic :)  Documented magic would be nice though.
[02:10] <cjwatson> doko: they only applied an earlier version of my change, not the whole thing. Please check again.
[02:10] <Keybuk> start at the udev manpages and documentation
[02:10] <fbond> alright, I can do that.
[02:10] <Keybuk> e.g. man udev, and /usr/share/doc/udev/writing_udev_rules/
[02:10] <StevenK> The manual pages are incredibly terse, from what I recall.
[02:10] <fbond> thanks very much for your help, Keybuk.
[02:10] <Keybuk> also look through the kernel documentation on sysfs
[02:11] <cjwatson> and unless they did something else to avoid the need for this:
[02:11] <cjwatson>   * Makefile: Just export DATE and HEXDATE rather than playing with $(MAKE);
[02:11] <cjwatson>     current make applies an extra shell evaluation pass to the latter
[02:11] <cjwatson> ... it's still relevant
[02:11] <cjwatson>     approach and so fails.
[02:11] <Keybuk> fbond: no problem
[02:11] <StevenK> Maybe I'm just turned off by Marco d'Annoyi^WItri saying "This udev stuff is so important and hard! *snap* *bite*"
[02:11] <Keybuk> bah
[02:11] <Keybuk> it's important, yes
[02:11] <Keybuk> really damned useful
[02:11] <Keybuk> but not hard
[02:11] <StevenK> Keybuk: Stop saying bah, Scrooge. :-P
[02:12] <Keybuk> Every driver, device, interface, etc. in the kernel has a structure of information about it
[02:12] <Keybuk> it chains those structures up in a pretty tree which it exposes in /sys
[02:12] <Keybuk> and whenever it adds or removes items, it sends a message out so userspace can react
[02:12] <fbond> Well, I like udev in principle.  I don't think anyone dislikes the goals of udev.
[02:12] <Keybuk> udev listens to those messages, and uses them to maintain /dev, and run other programs, etc.
[02:13] <Keybuk> it's obviously important that you listen to the right messages, and use the right information
[02:13] <Keybuk> unfortunately that's the poorly documented bit, because it's kernel stuff, and they're notoriously bad at it :p
[02:13] <StevenK> I recall Herbert Xu somewhat not liking udev, since he didn't see the huge problem of a static /dev in the normal use cases.
[02:13] <StevenK> But Herbert is strange like that. :-)
[02:14] <Keybuk> the advantage and disadvantage of a static /dev is pretty much swings and roundabouts
[02:14] <mjg59> Well, if you never hotplug anything, there's no real problem with a static /dev
[02:14] <Keybuk> certainly having mknod run for you if you're missing a device is useful
[02:14] <StevenK> Or if all the devices you hotplug already have /dev nodes.
[02:14] <Keybuk> the principal advantage of udev is that, once you know you *have* the /dev node, you can do other things
[02:14] <Mithrandir> having an /etc which actually reflects your system is nice too.
[02:15] <Mithrandir> makes tab completion and such so much easier.
[02:15] <cjwatson> you mean a /dev?
[02:15] <Mithrandir> uh, yes.
[02:15] <StevenK> Heh
[02:15] <mjg59> StevenK: Device ordering isn't guaranteed
[02:15] <Keybuk> the other useful side-effect of a dynamic /dev is that we can name things statically
[02:15] <Keybuk> you can't guarantee which disk is sda, and which is sdb
[02:15] <StevenK> mjg59: That's a good point.
[02:15] <jdub> Spads: thanks re: ubuntu world wide
[02:15] <Keybuk> but you can use udev to examine the disks, and give us /dev/disk/by-uuid
[02:15] <mjg59> StevenK: So if you want specific permissions with a static /dev, you *still* need something like udev
[02:16] <Keybuk> imagine having /proc/bus/usb as a "static device tree"
[02:16] <Spads> jdub: no problem
[02:16] <Keybuk> you'd need /proc/bus/usb/000 thru 999/000 thru 999
[02:16] <Keybuk> lots and lots of notes
[02:16] <Keybuk> uh, nodes
[02:16] <Mithrandir> StevenK: I'm a bit unsure what uetc wouduld do..
[02:16] <Mithrandir> would, even
[02:16] <Spads> jdub: I notice that the terminator doesn't shift because it's not regenerating if there's no cache miss
[02:17] <ajmitch> Mithrandir: I don't think you'd want to know..
[02:17] <StevenK> Mithrandir: :-P
[02:17] <ajmitch> sounds like another wild idea of StevenK's :)
[02:17] <Mithrandir> ajmitch: if I were to write it, I'd surely want to know what it would do..
[02:17] <StevenK> Oh, I don't have wild ideas.
[02:18] <Mithrandir> I have some nice ideas and some really insane ones.
[02:18] <Keybuk> /Programs
[02:18] <Mithrandir> Keybuk: no, that's just crack. :-P
[02:19] <Keybuk> /Users/Scott James Remnant/Configuration/Upstart
[02:19] <Keybuk> /Users/Scott James Remnant/Desktop
[02:19] <Keybuk> /Users/Scott James Remnant/Documents
[02:19] <StevenK> Why the Mac OS X layout....
[02:20] <Keybuk> acciiiiiiiiiiiiid
[02:21] <pitti> hey thom, how's it going?
[02:22] <thom> i have just defeated d-i, so it's going well. how about you?
[02:22] <fbond> Keybuk: little help?
[02:22] <Keybuk> fbond: ?
[02:22] <fbond> ENV{PRODUCT}=="763/1014/*" -> SYSFS{idVendor}=="0763", SYSFS{idProduct}=="1001"
[02:22] <fbond> ENV{PRODUCT}=="763/1031/121" -> ?
[02:22] <fbond> what do I do with the 121?
[02:22] <Keybuk> ENV{PRODUCT}=="763/1014/*" -> SYSFS{idVendor}=="0763", SYSFS{idProduct}=="1014"
[02:22] <Keybuk> :p
[02:23] <fbond> um, right
[02:23] <fbond> copied the wrong line :)
[02:23] <fbond> question stands, however ...
[02:24] <Keybuk>         if (add_uevent_var(envp, num_envp, &i,
[02:24] <Keybuk>                            buffer, buffer_size, &length,
[02:24] <Keybuk>                            "PRODUCT=%x/%x/%x",
[02:24] <Keybuk>                            le16_to_cpu(usb_dev->descriptor.idVendor),
[02:24] <Keybuk>                            le16_to_cpu(usb_dev->descriptor.idProduct),
[02:24] <Keybuk>                            le16_to_cpu(usb_dev->descriptor.bcdDevice)))
[02:24] <Keybuk> ok
[02:24] <fbond> oh right
[02:24] <fbond> "documentation"
[02:24] <Keybuk> best kind there is <g>
[02:24] <fbond> :)
[02:24] <fbond> bcdDevice -> SYSFS{bcdDevice} ?
[02:24] <Keybuk> ENV{PRODUCT}=="763/1031/121" -> SYSFS{idVendor}=="0763", SYSFS{idProduct}=="1031", SYSFS{bcdDevice}=="0121"
[02:25] <fbond> ok, thanks!
[02:25] <Keybuk> on feisty, you'd need to use ATTRS{...}==
[02:25] <StevenK> Binary Coded Decimal Device .... Hrm, doesn't sound right.
[02:25] <Keybuk> StevenK: version number
[02:25] <Keybuk> ie. 1.21 :p
[02:25] <fbond> hmm.
[02:25] <StevenK> How does bcd == Version ? :-P
[02:25] <Keybuk> OMG ... I can recall pieces of the USB spec; I am doomed
[02:26] <Keybuk> StevenK: version numbers are usually encoded in bcd because hardware people are strange
[02:26] <fbond> Hopefully the feisty documentation has been updated to reflect that change?
[02:26] <Keybuk> fbond: yes
[02:26] <StevenK> Oh, right.
[02:28] <fbond> Keybuk, in feisty, udev rules are completely different, i.e. don't have all those SYSFS{...} bits?
[02:29] <jdub> Setting up sun-java5-plugin (1.5.0-10-0ubuntu1) ...
[02:29] <jdub> update-alternatives: unable to make /usr/lib/iceweasel/plugins/libjavaplugin.so.dpkg-tmp a symlink to /etc/alternatives/iceweasel-javaplugin.so: No such file or directory
[02:30] <StevenK> jdub: Known. I think ....
[02:30] <Keybuk> fbond: in feisty, you need to change the word "SYSFS" to the word "ATTRS"
[02:30] <Keybuk> ATTRS{idVendor}=="0763", ATTRS{idProduct}=="1031", ATTRS{bcdDevice}=="0121"
[02:30] <Keybuk> ^ like that
[02:31] <fbond> oh, and that's it; there is a 1:1 mapping from SYSFS -> ATTRS ?
[02:33] <Keybuk> yup
[02:33] <Keybuk> the new name is intended to make it more obvious that it checks the attributes in the current sysfs object and all parent objects
[02:33] <Keybuk> personally I hate it, but hey ho
[02:34] <fbond> is it also intended to make maintainers of firmware packages have to rewrite their udev rules on a 6 mo schedule? :)
[02:35] <Keybuk> apparently so
[02:35] <Keybuk> btw, in Ubuntu you probably want your firmware in /lib/firmware
[02:36] <Lathiat> jdub:yeh i get the same thing
[02:37] <fbond> Keybuk: ok, didn't want to step on toes by moving things into /lib/firmware
[02:37] <fbond> thought that might be reserved for "official" firmware
[02:38] <pitti> sjoerd: ping
[02:39] <Keybuk> no
[02:39] <sjoerd> pitti: pong
[02:39] <Keybuk> /lib/firmware/$(kernel version) is official
[02:39] <Keybuk> /lib/firmware itself is intended for unofficial
[02:39] <pitti> sjoerd: I just fixed hal to not rely on volume.ignore for allowing/refusing mount
[02:40] <sjoerd> rock!
[02:40] <pitti> sjoerd: instead I added code to check policy for the non-policykit case
[02:40] <sjoerd> how?
[02:40] <pitti> sjoerd: upstream only checks the policy if #ifdef HAVE_POLKIT
[02:40] <pitti> sjoerd: and didn't check it *at all* if nto
[02:40] <pitti> sjoerd: not, even
[02:40] <pitti> sjoerd: so I added an #else and added a function check_nonpolkit_security_policy (privilege, invoked_by_uid);
[02:41] <\sh> guys, do we have a policy for dealing with iceweasel/icedove build-deps/deps from debian to ubuntu? or are we providing iceweasel/icedove in our ff/tb packages?
[02:41] <sjoerd> and check_nonpolkit_security_policy does pmount like checking of things ?
[02:42] <pitti> sjoerd: no, not yet; these checks need to become a bit more invasive
[02:42] <pitti> sjoerd: most of them shouldn't be a problem to port, but one is hard: replacing getenv ("HAL_METHOD_INVOKED_BY_UID")
[02:42] <pitti> sjoerd: I have no idea how to determine the uid from the other dbus end from the hal callout
[02:43] <sjoerd> you can't
[02:43] <pitti> that's what I thought, too
[02:43] <sjoerd> you need to trust hal on that one..
[02:43] <pitti> so the whole 'replace hal property checking by sysfs checks' is pointless
[02:43] <sjoerd> yup
[02:44] <pitti> sjoerd: but at least I would like to check for removable/fixed policy on its own rather than relying on volume.ignore
[02:44] <pitti> sjoerd: specifically because we want to set it to false for non-fstab fixed disks
[02:44] <sjoerd> yup
[02:44] <pitti> sjoerd: so that gksu gnome-mount /dev/hdxx works
[02:44] <sjoerd> i'd like to remove the volume.ignore hack from the debian package completely
[02:44] <pitti> sjoerd: that's what I am going to do
[02:44] <sjoerd> rock :)
[02:45] <sjoerd> you could try :)
[02:45] <pitti> sjoerd: oh, btw, do you still have the debian-ubuntu diff explanation mail I sent you the other day? shall I send it to someone else if you are busy?
[02:45] <sjoerd> yeah i still have it, sorry about that
[02:45] <sjoerd> please forward it to the pkg-utopia-maintainers (or whatever it's called list)
[02:46] <pitti> sjoerd: ok, will do
[02:46] <sjoerd> did i already say that you rock ? :)
[02:46] <pitti> thanks ;)
[02:47] <pitti> sjoerd<EMAIL_ADDRESS>won't work?
[02:48] <sjoerd> dunno, that'll probably just mail to the maintainers address right ?
[02:48] <sjoerd><EMAIL_ADDRESS>is the right one
[02:49] <pitti> alright
[02:50] <pitti> sjoerd: sent
[02:53] <twb> Who or what is `the SABDFL'?
[02:55] <xhaker> twb, it's Mark Shuttleworth, Ubuntu founder.
[02:55] <twb> Ah, BDFL = benevolent dicatator for life.
[02:56] <sivang> twb: SA=Self Appointed/ SouthAfrica ;)
[02:56] <twb> Ah.
[02:57] <sivang> twb: the .za part was my joke
[02:58] <xhaker> it was mildly funny
[02:58] <sivang> xhaker: nah, you're too kind
[02:58] <sivang> xhaker: it was bad :)
[02:58] <twb> When I register my key, I get a mail from launchpad with no instructions attached.
[02:58] <twb> What do I do next?
[02:59] <twb> s/key/gpg key/
[03:00] <gnomefreak> good morning mvo
[03:01] <twb> Ah, it's encrypted as well as signed.
[03:01] <mvo> hey gnomefreak!
[03:02] <ajmitch> hello mvo
[03:27] <pitti> Mithrandir: just for the sake of coordination, what are your plans for n-m? (merging, patching, etc.)
[03:28] <Mithrandir> pitti: it hasn't actually been on my radar yet; I want to update it to the newest upstream version and add a hook for it to call network-admin
[03:29] <pitti> Mithrandir: ok; I have a pending patch for zeroconf stuff and I wondered whether I should apply it to the current feisty version or wait for the merge
[03:30] <Mithrandir> pitti: feel free to apply it and I'll bring it forward.
[03:30] <pitti> Mithrandir: ok; it isn't really intrusive, so it shouldn't cause problems
[03:30] <pitti> Mithrandir: oh, right, I remember -- the current n-m is FTBFS, so I'd need to throw two patches into it to fix that
[03:31] <pitti> they can be just dropped when merging
[03:31] <Mithrandir> pitti: oh, please. :-)
[03:31] <pitti> Mithrandir: alright, thanks; then I won't get in your way any more with the zeroconf stuff
[03:32] <Mithrandir> pitti: no worries.
[03:32] <maxb> pitti | Mithrandir: Any thoughts about my apache2 bug question from earlier today? (62748)
[03:33] <pitti> maxb: not really from my side, sorry
[03:33] <Mithrandir> maxb: not offhand, sorry.  My brain is just about fried.
[03:35] <maxb> Ah. A case of too much going on with feisty, tearing attention away from edgy bugs?
[03:37] <Mithrandir> a case of "Tollef has been trying to push out a milestone for a week and needs a little more than two hours before he focuses heavily on something else"
[03:53] <Keybuk> doko: NEVER upload MoM output without altering the changelog to your name, and listing the remaining changes
[03:53] <Keybuk> you must've tried pretty hard to force that
[03:54] <doko> Keybuk: ok. no, just signed with -k
[03:54] <Keybuk> naughty
[03:57] <sivang> Keybuk: heh
[04:02] <xhaker> doko: please don't forget eclipse-cdt :P
[04:03] <doko> xhaker: I don't touch eclipse-cdt
[04:03] <xhaker> i thought you were the eclipse wiz
[04:04] <xhaker> nvm then
[04:04] <pirast> doko, hi
[04:13] <bddebian> Heya
[05:11] <pitti> Keybuk: could you please promote avahi-autoipd to main? (binary-only promotion)
[05:12] <Keybuk> pitti: ok, update the queue please
[05:12] <pitti> Keybuk: 'update the queue'?
[05:12] <Mithrandir> pitti: done.
[05:12] <pitti> Mithrandir: merci
[05:12] <Mithrandir> Keybuk: binary-only, doesn't need MIR or stuff.
[05:13] <pitti> ah, that queue; yes, avahi is in promoted already
[05:15] <Keybuk> good point
[05:15] <Keybuk> double-done then :p
[05:31] <pitti> iwj: what's the correct way of renaming a conffile nowadays? IIRC you considered http://wiki.debian.org/DpkgConffileHandling overkill?
[05:34] <Keybuk> heh
[05:34] <Keybuk> if anything, that's underkill
[05:34] <Keybuk> it doesn't account for upgrades being aborted; you need equivalent in postrm and preinst too
[05:46] <iwj> pitti: Hmmm.  I think the right answer is to have the preinst make a symlink.
[05:46] <iwj> Certainly you shouldn't do what that wiki page says.
[05:46] <iwj> No grepping /var/lib/dpkg/status (!)
[05:46] <pitti> iwj: hm, but I really need to get rid of the old file, or things will break
[05:47] <iwj> Oh, that's a pain.  Why ?  Can you avoid that ?
[05:47] <pitti> iwj: is grepping dpkg -s slightly better?
[05:47] <iwj> Yes.
[05:47] <pitti> iwj: I could hack around it by changing a conffile in a different package, but then I need to touch two packages, and it would be a *really* nasty hack
[05:48] <pitti> problem is a script .d directory starting with 'd', but really needs to be executed last
[05:48] <pitti> so I need to rename it as zzzz_dhcdbd
[05:48] <iwj> A whole directory ?
[05:48] <pitti> iwj: no, just the script in the .d directory
[05:49] <iwj> This is going to be quite complicated and bI'd have to
[05:49] <iwj> think about it.
[05:49] <iwj> Excuse me, I seem to have keyboard/finger interaction problems today ...
[05:49] <pitti> iwj: I wanted to have a slightly modified recipe: if the old conffile is unmodified, I remove it; if it's modified, I rename it
[05:50] <pitti> and thus get the dpkg conffile question, which is really what I want here
[05:50] <iwj> Does the contents as well as the filename change ?
[05:50] <pitti> iwj: depends, if you upgrade from edgy, yes
[05:51] <pitti> (so you'd get the question anyway)
[05:51] <iwj> Keybuk: I need to have a proper conversation with you about UdevLvm and things surrounding it.  I think there are some wrong assumptions in the spec or in me.
[05:51] <iwj> pitti: But you don't want to get the question if the user's file is identical to the old version.
[05:51] <pitti> iwj: right
[05:51] <pitti> iwj: that's why I remove it if the md5sums match
[05:52] <pitti> (in the preinst)
[05:52] <pitti> since then the new one will just get unpacked from the .deb
[05:52] <Keybuk> iwj: oh?
[05:53] <iwj> Keybuk: Well, the spec deals just with getting vgchange run but it doesn't deal with what happens next.  Which, as it happens, is nothing at all.
[05:53] <Keybuk> iwj: what should happen next?
[05:53] <iwj> Keybuk: Well, it should perhaps be mounted by something.
[05:53] <Keybuk> vgchange is sufficient to get the lvm volume mountable
[05:54] <Keybuk> which is as far as the scope of that spec cares
[05:55] <iwj> pitti: Without thinking about it too hard I think that's not an unreasonable approach but you have to think carefully about error handling.
[05:55] <iwj> You'll have to (eg) save the old file somewhere.
[05:55] <iwj> Keybuk: The spec doesn't say what happens next.  Apparently the idea is that some udev event calls `the mountroot script' (which I can't seem to find atm ...)
[05:56] <Keybuk> iwj: the spec doesn't need to
[05:56] <iwj> But what if it's not / but /usr ?
[05:56] <Keybuk> its scope is limited
[05:56] <iwj> I need to understand what's happening next so that I can test it.
[05:56] <pitti> iwj: http://people.ubuntu.com/~pitti/tmp/dhcdbd.preinst is my current version, with dpkg -s and simplification (no postinst code)
[05:56] <iwj> I don't care what you think should or should not be in this spec.
[05:56] <Keybuk> the new block device will cause udev to emit a block-device-added event to upstart
[05:56] <Keybuk> which will trigger an upstart job that will mount the partition
[05:57] <pitti> iwj: it would currently do the wrong thing if unpacking the new version would fail
[05:57] <Keybuk> or, in the initramfs, the device existing will stop the mountroot() function from spinning, and let it mount it
[05:57] <cjwatson> I wish dpkg -s weren't so slow
[05:57] <iwj> pitti: Right.  It doesn't look unreasonable.
[05:57] <cjwatson> I often find myself looking at /var/lib/dpkg/status just because it's slothful otherwise
[05:57] <iwj> cjwatson: Well, err, yes ...
[05:57] <cjwatson> why isn't it just morally a sed script, anyway?
[05:58] <iwj> Keybuk: Where is this code - in particular, the upstart code ?
[05:58] <iwj> Or doesn't it exist yet ?
[05:58] <Keybuk> iwj: doesn't exist yet
[05:58] <iwj> Ah, tricky.
[05:59] <iwj> Maybe I should wait with this until that's ready.  It's a shame that this interdependency wasn't clearer earlier ...
[05:59] <pitti> iwj: the good side is that it will never remove a modified conffile, just an unmodified one, so nothing really precious will get lost
[05:59] <iwj> pitti: Yes, but dpkg treats removed as a kind of changed.
[05:59] <Keybuk> iwj: it's not a dependency
[06:00] <Keybuk> the lvm stuff is just as useful beforehand
[06:00] <cjwatson> removing it works if the thing you're trying to do is move a conffile from one package to another
[06:00] <iwj> Keybuk: Well, it helps a bit but if it doesn't mount automatically then you've not really gained much.
[06:01] <Keybuk> iwj: we've gained the loss of a race condition
[06:01] <iwj> cjwatson: Err, you don't need to do anything special to do that any more.  I fixed that.
[06:01] <Keybuk> in particular, you should be able to use udevmonitor to see the events happening in the right order
[06:01] <Keybuk> and write udev rules that use the /dev/mapper directory to access LVM devices
[06:01] <cjwatson> iwj: you do if you're writing code that needs to run with sarge dpkg, as I was doing last night :-(
[06:01] <Keybuk> being able to mount an LVM USB stick through HAL would be a good test
[06:01] <pitti> Keybuk: btw, that test works in feisty right now
[06:02] <iwj> Keybuk: USB stick> That's exactly what I'm trying.
[06:02] <iwj> And the current udev rules completely suppress all dm devices.
[06:02] <pitti> i. e. standard luks-encrypted usb stick will not mount in feisty
[06:02] <cjwatson> pitti: my usual is (1) preinst install|upgrade: mv -f foo foo.moved-by-preinst; (2) postinst configure: rm -f foo.moved-by-preinst; (3) postrm abort-install|abort-upgrade: mv -f foo.moved-by-preinst foo
[06:02] <Keybuk> iwj: because udev-devmapper hasn't been implemented yet
[06:02] <pitti> and suddenly will work as soon as you remove the dmX udev naming rule
[06:02] <cjwatson> with appropriate version checks, and replace mv with something else as appropriate
[06:02] <iwj> I think loss of a race which would break something from working is not interesting unless the thing it's racing against might work if the race were fixeds.
[06:02] <Keybuk> pitti: work with a race condition
[06:03] <pitti> Keybuk: right, I meant for the sake of testing
[06:03] <cjwatson> hmm, I suppose I should make that be dpkg-moved-by-preinst to avoid run-parts badness
[06:03] <iwj> pitti: Yes, cjwatson has the right approach.
[06:03] <iwj> cjwatson: sarge> Yes.
[06:03] <pitti> cjwatson: great, thanks
[06:03] <Keybuk> cjwatson: that's my approach too, iirc
[06:03] <iwj> Keybuk: So what I'm saying is that udev-lvm doesn't do anyone any good without at least some additional work.
[06:03] <Keybuk> iwj: yes
[06:03] <Keybuk> it was one small spec in a set
[06:04] <iwj> Right.  The `sister' specs like udev-evms were clear to me and are mentioned but the other parts (up and down the stack, as it were) weren't.
[06:04] <Keybuk> iwj: they're right there, in LP
[06:05] <Keybuk> marked as dependencies and dependers in either direction
[06:05] <iwj> Oh, there.  Sorry, I'm a fool.
[06:05] <cjwatson> sigh, it would be nice if resize2fs had machine-parseable progress display
[06:06] <Keybuk> cjwatson: yeah, I move the modified in preinst/install|upgrade; remove unmodified or complete the move in postinst/configure; and undo the move in postrm/abort-install|abort-upgrade
[06:06] <Keybuk> (udev has a copy of my usual prep_rm_conffile/prep_mv_conffile/rm_conffile/mv_conffile/undo_rm_conffile/undo_mv_conffile functions
[06:06] <Keybuk> iwj: heh, what does that make the rest of us then? :p
[06:06] <cjwatson> Keybuk: I was having fun with openssh upgrades from sarge last night, so it's still fresh in my mind
[06:07] <cjwatson> iwj: BTW, do you happen to remember if said conffile bug in dpkg that you fixed was non-deterministic in any way? I couldn't reproduce the ssh->(openssh-client,openssh-server) upgrade problems that people were reporting, but I have no reason to doubt that they're there sometimes
[06:07] <iwj> Keybuk: Right, UdevDeviceMapper makes life a lot clearer and I'll go away and play with things some more.
[06:08] <cjwatson> or was it the every-other-conffile-in-status-file thing I vaguely remember?
[06:08] <iwj> cjwatson: I don't think it was actually nondeterministic but IIRC it could depend on things that the correct processing wouldn't depend on.
[06:08] <iwj> In particular, it could depend on whether you removed one package and installed the other, or did a Replaces/Conflicts in-one-go.
[06:08] <cjwatson> oh joy
[06:10] <cjwatson> hey, e2fsck has nice-ish machine progress information though
[06:13] <cjwatson> ... but mke2fs' is crap
[06:13] <iwj> I wish udev had better debugging support.
[06:16] <Keybuk> iwj: what's wrong with it?
[06:16] <iwj> Devel team meeting is 0800Z tomorrow, isn't it ?
[06:17] <iwj> Keybuk: Well, it's a programming language but I can't get a good trace of who did what.
[06:17] <Keybuk> did you increase the log level?
[06:17] <Keybuk> udevcontrol log_priority=info
[06:18] <bluefoxicy> I have a simple question:  Is Ubuntu/Canonical making any money through CD sales?
[06:18] <iwj> Keybuk: Yes, I had that already.
[06:18] <bluefoxicy> (More directly, would it be a huge sin to release a program that downloaded an official CD/DVD image and label; printed the label on standard templates; and burned the CD, thus simulating a pressed+printed CD)
[06:19] <iwj> Keybuk: But I have to go catch my train to Stowmarket to go climbing now.  Talk to you tomorrow if you like ...
[06:20] <Keybuk> sure
[06:20] <Keybuk> you can turn on full debugging with a recompiel
[06:20] <Keybuk> it's off because it can effectively fill an entire disk with a single boot <g>
[06:21] <Keybuk> anyway
[06:21] <Keybuk> tomorrow
[06:31] <dholbach> Gloubiboulga: YOU ROCK :)
[06:38] <pitti> cjwatson: wrt. your conffile approach, don't the postrm bits need to go into the old version of the package?
[06:39] <cjwatson> pitti: n
[06:39] <cjwatson> no
[06:39] <cjwatson> the new postrm is called when rolling back
[06:40] <pitti> oh, how convenient
[06:40] <pitti> thanks
[06:40] <cjwatson> for precisely this reason, I suspect :)
[06:42] <pitti> hi erdalronahi
[06:42] <erdalronahi> hi
[06:43] <erdalronahi> Pitti, I always mix up you and doko
[06:43] <erdalronahi> the openoffice-langpack is his work, isnt it?
[06:43] <pitti> right
[06:44] <erdalronahi> the new packs in -proposed are fine as I can see
[06:44] <pitti> erdalronahi: ah, thanks for testing; did you look at both edgy/dapper?
[06:45] <erdalronahi> no, not at dapper
[06:45] <erdalronahi> well, I looked at Dapper,
[06:46] <erdalronahi> but didn't test it carefully
[06:46] <erdalronahi> Anyway, as long as there is not multicast, we do not work on Dapper
[06:46] <erdalronahi> was it "multicast"?
[06:48] <dholbach> SUPER-PITTI!
[06:48] <pitti> hm?
[06:49] <dholbach>  P I T T I !
[06:49] <dholbach> you just uploaded a network-manager fix :-)
[06:49] <derekS> dholbach: you are a maintener of a package i like, and a new version is out, when you have a minute, can you upload the new one?
[06:50] <derekS> would help if i gave the package name
[06:50] <derekS> "tilda"
[06:50] <dholbach> 0.09.4?
[06:50] <pitti> dholbach: well, it won't work before I actually finish this dhcdbdbdbd package (2 minutes for the fix, one hour to get the upgrade right *sigh*)
[06:51] <keescook> I reported to someone that they should use strncpy instead of strcpy
[06:51] <dholbach> keescook: what's wrong?
[06:51] <dholbach> derekS: 0.09.4?
[06:51] <pitti> keescook: and they forgot to ensure the terminating 0?
[06:51] <keescook> They replaced their strcpy with: strncpy( dest, src, strlen(src) + 1)
[06:51] <cjwatson> haha
[06:51] <pitti>  hahaha
[06:51] <cjwatson> please to be aiming gun *away* from foot
[06:51] <derekS> dholbach: yeah
[06:52] <dholbach> derekS: already uploaded some days ago
[06:52] <derekS> dholbach: oh, mybad
[06:52] <derekS> sorry about that :)
[06:52] <derekS> thanks
[06:52] <dholbach> derekS: we were frozen for herd1 for a while
[06:52] <siretart> is it nowadays possible to configure static ips with network-manager?
[06:52] <derekS> dholbach: ahh, thats why it didn't make it... i waited for a while, figured i would ask
[06:52] <dholbach> right
[06:52] <derekS> thanks
[06:53] <dholbach> anytime
[06:53] <derekS> when does the freeze end?
[06:53] <pitti> derekS: some hours ago
[06:54] <derekS> pitti: so packages should start to make there way into the repos soon?
[06:54] <cjwatson> they already have
[06:54] <pitti> derekS: the sources already did
[06:54] <pitti> derekS: the buildds have to chew through them now, of course
[06:54] <derekS> ahh... is there away to get the buildlogs
[06:54] <derekS> like we used to?
[06:55] <pitti> derekS: see DeveloperResources wiki page
[06:55] <derekS> thanks
[06:55] <HumanPrototype> siretart, I sure hope someone says yes
[06:56] <derekS> have a nice afternoon
[06:58] <pitti> cjwatson: ./update'ing ubuntu-meta fails with a 404 on downloading the ia64 package lists; did we drop ia64?
[07:00] <cjwatson> not to my knowledge, and it worked for me when I last tried
[07:01] <pitti> hmm, I tried it twice now
[07:01] <cjwatson> ah, somebody broke ports
[07:01] <cjwatson> elmo: http://ports.ubuntu.com/ubuntu-ports/ no longer exists; what happened?
[07:02] <elmo> gar, sorry
[07:02] <elmo> cjwatson: the machine got upgraded, space wise and apparently that got lost
[07:02] <alex-weej> so i just installed a fresh ubuntu
[07:03] <alex-weej> and my LC_* variables are all en_US.UTF-8
[07:03] <alex-weej> i'm sure i told it to be normal english on installation...o_0
[07:03] <cjwatson> that is normal English
[07:03] <alex-weej> or was that just keyboard prefs?
[07:03] <cjwatson> i.e. it's the default
[07:03] <cjwatson> YM British English?
[07:04] <alex-weej> i mean English English, bitch! :P
[07:04] <alex-weej> (yes)
[07:04] <cjwatson> I speak British English too, but I'm also aware of what the defaults are ;)
[07:04] <alex-weej> ok
[07:04] <alex-weej> so is this a bug?
[07:04] <cjwatson> alex-weej: hang on
[07:04] <alex-weej> or did i just imagine that i told ubiquity i was from the UK
[07:04] <cjwatson> look at /var/log/installer/syslog
[07:05] <alex-weej> cjwatson: on it
[07:05] <cjwatson> unfortunately I've just been reminded that I have to go to take the child to chess club
[07:05] <cjwatson> back in a bit ...
[07:05] <alex-weej> cjwatson: ok, cya
[07:07] <Spads> cjwatson: can you check for me if ubuntu-ports looks good now?
[07:07] <tsmithe> bah british english should be the default! we are the original english!
[07:07] <pitti> Spads: works here
[07:08] <_ion> Finnish English!
[07:09] <alex-weej> Lojban should be the default
[07:09] <alex-weej> i can't find any reference to locale settings in the installer log
[07:10] <_ion> alex-weej: http://imgs.xkcd.com/comics/lojban.png
[07:10] <alex-weej> _ion: :P
[07:10] <alex-weej> ok
[07:10] <alex-weej> first of all
[07:10] <alex-weej> what is the ubuntu way of changing my locale settings to their rightful en_GB? :P
[07:11] <alex-weej> is it the LANG setting in /etc/environment?
[07:11] <alex-weej> actually I'm sure i need to generate my locales first
[07:12] <Lure> alex-weej: there is also /etc/default/locale
[07:12] <alex-weej> hmm
[07:12] <alex-weej> not good
[07:12] <alex-weej> why two places? :S
[07:13] <Spads> pitti: cool, thanks
[07:14] <seb128> alex-weej: use system, admin, language
[07:14] <_ion> alex-weej: If you're running X, gnome-language-selector handles installing packages and generating locales.
[07:14] <seb128> alex-weej: otherwise /etc/environment is the place
[07:15] <_ion> /etc/default/locale doesn't exist on my system.
[07:15] <alex-weej> seb128, _ion: ok thanks
[07:15] <seb128> np
[07:15] <alex-weej> _ion: it does on my fresh edgy
[07:15] <alex-weej> seb128: interestingly, firing it up for the first time prompts me to install language stuff for Ooo
[07:16] <alex-weej> should i file a bug?
[07:16] <seb128> yeah, I think dictionnaries etc don't fit on the CD
[07:16] <alex-weej> oic
[07:16] <alex-weej> ok next question
[07:16] <seb128> speak to cjwatson about it when he's back
[07:16] <alex-weej> now that I've just set it for "new accounts and the login screen"
[07:16] <alex-weej> how do i set it for my existing account?
[07:16] <seb128> he probably knows if those things should be installed with the language-packs after install
[07:17] <seb128> alex-weej: it'll use the system default, or pick a different language from gdm before login
[07:17] <pitti> seb128: 'those things'?
[07:17] <seb128> pitti: <alex-weej> seb128: interestingly, firing it up for the first time prompts me to install language stuff for Ooo
[07:17] <seb128> pitti: looks like -support not installed
[07:17] <pitti> alex-weej: ^ right, that's what it's supposed to do, complete language support for you
[07:18] <alex-weej> pitti: it didn't even give me the option of doing anything, as soon as i ran it it said i was missing stuff
[07:18] <seb128> pitti: why does it wait for the language-selector to be started? shouldn't that be installed with language-packs from internet by ubiquity?
[07:18] <pitti> seb128: -en is a special case, since the en-gb OO.o help is not a dependency of l-support-en
[07:19] <pitti> seb128: so this will happen for en_GB folks
[07:19] <alex-weej> ok next thing to throw in the pot
[07:19] <alex-weej> i ran dpkg-reconfigure on locales
[07:19] <pitti> the reason is that we want l-support-en on CD
[07:19] <seb128> pitti: well, it's confusing :)
[07:19] <pitti> and thus it can't depend on the en-gb OO.o help
[07:19] <pitti> seb128: right, it is
[07:19] <pitti> alex-weej: that won't do what you want
[07:19] <alex-weej> it generated all the other en_* locales (en_US was already "up to date"). what's with that? were they not already generated? would language-selector have dealt with it if i hadn't done so prior to running it?
[07:20] <pitti> alex-weej: I strongly presume that the locales were okay before
[07:20] <pitti> just the caching code is a bit broken
[07:20] <alex-weej> pitti: it seems a bit of a coincidence that en_US was up to date
[07:20] <alex-weej> i will make a note and investigtae
[07:23] <alex-weej> seb128: did i accidentally choose en_US in ubiquity then?
[07:23] <alex-weej> seb128: or does it just not even ask?
[07:24] <pitti> alex-weej: it's been a while since I did an English install, I'm not sure; d-i does ask for a region, not sure about ubiquity
[07:24] <mjg59> It's based on the area you select in the timezone selection
[07:25] <alex-weej> i don't think anyone living in Europe/London wants to use en_US
[07:25] <alex-weej> :P
[07:25] <mjg59> At least, I think so. I haven't checked the code.
[07:25] <alex-weej> ok
[07:25] <mjg59> alex-weej: I always get en_GB
[07:25] <alex-weej> i will have a look some time
[07:25] <mjg59> So there's not a general failing
[07:39] <alex-weej> ok i got another one for yas
[07:39] <alex-weej> https://launchpad.net/distros/ubuntu/+bug/74657
[07:39] <Ubugtu> Malone bug 74657 in Ubuntu "floppy0 comes out of nowhere" [Undecided,Unconfirmed]
[08:06] <lamont> doko: curious about your bind9 upload...
[08:06] <lamont> or rather, curious about why ubuntu switched to only allowing recursion on localnets...
[08:06] <lamont> since (1) localnets is generally incorrect for the application...
[08:13] <cjwatson> alex-weej: as mjg59 says - I've never encountered that particular problem. wouldn't mind looking at the syslog in case it's illuminating in any way, and a precise description of what you did would be good
[08:13] <cjwatson> it's possible that going back and forward in ubiquity could confuse that bit of code
[08:13] <alex-weej> i didn't go back and forth
[08:13] <cjwatson> ok
[08:13] <alex-weej> i'll post my installer log later
[08:13] <alex-weej> mates cooking curry
[08:14] <alex-weej> gotta join
[08:14] <cjwatson> sure
[08:14] <alex-weej> cya in a bit
[08:14] <cjwatson> lojban> we don't have a lojban installer translation ;-)
[08:15] <jdong> lol
[08:31] <Balachmar> Hi, I might have found a bug, which I would like to get resolved.
[08:31] <Balachmar> I can't seem to find the ubuntu-bugs channel
[08:31] <Balachmar> So I thought to drop it here...
[08:32] <Adri2000> Balachmar: /join #ubuntu-bugs
[08:32] <Balachmar> ok, sorry :)
[08:57] <Adri2000> any idea how to fix a FTBFS like that?
[08:57] <Adri2000> /usr/bin/ld: cannot find -ldbus-glib-1
[08:57] <Adri2000> collect2: ld returned 1 exit status
[08:58] <mjg59> build-depend on whatever package provides that
[09:00] <slomo> Adri2000: or add a dependency on libdbus-glib-1-dev to the package that references it via a pkg-config file or .la or whatever...
[09:04] <Adri2000> the package I'm trying to build is gnome-phone-manager, it built fine on edgy buildds, but now it doesn't build either in an edgy pbuilder or a feisty pbuilder
[09:05] <Adri2000> slomo: libdbus-glib-1-dev is a new package?
[09:06] <slomo> no
[09:06] <Adri2000> currently there is no *dbus* build-dep, and it built fine in edgy
[09:07] <slomo> it's probably one of the build depednencies of gnome-phone-manager that needs this added
[09:08] <Adri2000> something that used to depend on libdbus-glib-1-dev, and doesn't anymore in feisty? is it possible?
[09:09] <slomo> no, something that did not depend on dbus-glib in edgy but does now in feisty... and someone forgot to add the dependency
[09:10] <Adri2000> slomo: are we talking of the same "something"? :p I meant something = a build-dep of gnome-phone-manager
[09:11] <slomo> Adri2000: yes, that's the something i meant too ;) well, let's see...
[09:12] <seb128> I think that's a gnome-vfs change
[09:12] <seb128> you need libgnomeui uptodate
[09:13] <seb128> I didn't rebuild 3 packages which mentionned wrongly libdbus-glib after the gnome-vfs change
[09:13] <seb128> libbonobo(ui) libgnomeui and some other one
[09:13] <seb128> the libgnomeui build has probably be blocked by the freeze for herd1 though
[09:13] <Chipzz> seb128: libdbus-glib-1 doesn't exist anymore iirc, it's libdbus-glib-1-2
[09:14] <seb128> grab the new version now and retry with it
[09:14] <Mithrandir> Chipzz: next version is going to be libdbus-glib-1-2-3 ?
[09:14] <seb128> Chipzz: the -dev is still named libdbus-glib-1-dev
[09:14] <Chipzz> seb128: ah k
[09:15] <Chipzz> the vmware guys should rebuild vmware player and server against new dbus :(
[09:15] <seb128> Adri2000, slomo: read what I just write
[09:15] <Chipzz> bleh
[09:15] <seb128> wrote
[09:15] <ulaas> my mx3000 logitech usb mouse went crazy after upg to feisty
[09:15] <ulaas> where should i report.
[09:15] <Adri2000> seb128: that is what someone said to me, but I saw a new libgnomeui today, isn't it the right one?
[09:15] <Chipzz> Mithrandir: dbus is supposed to be stable now ;)
[09:15] <seb128> Adri2000: grep libdbus-glib /usr/lib/*.la
[09:16] <Chipzz> didn't we get rid of all .la files?
[09:16] <seb128> Chipzz: no
[09:16] <Chipzz> (or most of them anyway)
[09:16] <slomo> Chipzz: libdbus is meant to be stable now... but not the glib, qt, whatever bindings
[09:16] <seb128> Chipzz: we are getting there but not yet
[09:16] <seb128> going there
[09:17] <Chipzz> seb128: that's what I thought, but wasn't that like half a year ago or more? I presumed we would already be there by now ;)
[09:18] <seb128> Chipzz: well, getting ride of a .la usually force to rebuild all the package mentionning it and in the right order
[09:18] <Adri2000> seb128: grep libdbus-glib /usr/lib/*.la < it should find something?
[09:18] <seb128> Chipzz: which can be hundred of packages
[09:18] <Chipzz> Mithrandir: and the next version will probably be libdbus-glib-1-3
[09:18] <Chipzz> ;)
[09:18] <slomo> seb128: how would a rebuild fix this? it's a missing dependency of one -dev package... in this case libgnomebt-dev
[09:19] <Adri2000> seb128: in my pbuilder-feisty, with libdbus-glib-1-dev, it finds nothing
[09:19] <ulaas> slomo, oh hi.
[09:19] <seb128> Adri2000: yep, or the bug is not the one I'm thinking about
[09:19] <slomo> hi ulaas :)
[09:19] <seb128> Adri2000: and the package fails to build
[09:19] <seb128> slomo: it's not, it's an inflated depends to .la
[09:19] <Adri2000> yes
[09:19] <seb128> slomo: rebuild get ride of the .la extra entry
[09:20] <slomo> seb128: ah ok
[09:20] <seb128> Adri2000: does your package use dbus directly?
[09:21] <ulaas> hehe! gotta love bitchx
[09:21] <seb128> Adri2000: what package do you try to build?
[09:22] <Adri2000> seb128: it's gnome-phone-manager, and I only made a fix for the icon file
[09:22] <Adri2000> so I don't really know about dbus :)
[09:22] <seb128> Adri2000: let me look
[09:22] <ulaas> no one else has crazy mouse symptoms around?
[09:22] <seb128> ulaas: no
[09:23] <seb128> ulaas: xorg didn't change for a while now
[09:23] <ulaas> seb128 kernel related?
[09:23] <seb128> might be
[09:23] <seb128> do you use some sort of special device?
[09:23] <ulaas> seb128: i have a combo mx3000 from logitech
[09:24] <sladen> ulaas: PS/2 interface, or USB?
[09:24] <ulaas> seb128: same conf as then one i used in edgy
[09:24] <ulaas> seb128: USB
[09:24] <ulaas> seb128: i mean a usb receiver
[09:25] <bhale> maybe... you have a dead battery
[09:25] <jdong> ha
[09:25] <ulaas> bhale: maybe upgrading to feisty made it die :)
[09:25] <jdong> hardware problem
[09:25] <jdong> :)
[09:26] <maswan> Mithrandir: I have _no_ idea why I'm only getting 200k/s update speed.
[09:26] <maswan> Mithrandir: I'm getting good numbers to the filesystem
[09:26] <Mithrandir> maswan: according to Znarl, the routing is fine, so something is really weird, somewhere.
[09:26] <Mithrandir> (or at least was fine this morning)
[09:27] <maswan> Mithrandir: *nods*
[09:27] <ulaas> ok! i am not here for a solution. just wanted you good people to know there is such a thing. If you find out some other people are effected as well please let me know. maybe i can help. my launchpad nick should be ulaas.
[09:28] <seb128> ulaas: ok, thank you for pointing the issue, maybe opening a launchpad bug would be a good idea too
[09:28] <ulaas> seb128: will do so when i finished investigating more
[09:29] <maswan> Mithrandir: Hmm.. I'm not getting better speeds from cdimage.u.c from other hosts though.
[09:29] <maswan> (just tried 3 different networks)
[09:30] <Mithrandir> maswan: might be slow now due to herd 1, though I somewhat doubt it.
[09:30] <Mithrandir> maswan: I also get shit speed to it now.
[09:30] <maswan> Mithrandir: *nods*, so we'll poke Znarl tomorrow during dc business hours? ;)
[09:31] <Mithrandir> hmm, something weird here, from a host which usually gives me ~45Mbit, I now get ~4.5Mbit.
[09:31] <Mithrandir> maswan: yeah, I guess so
[09:33] <tsmithe> Mithrandir, something weird here
[09:33] <tsmithe> from a host that usually gives me ~2MBit, i'm getting ~0.5Mbit
[09:33] <tsmithe> so yours is pretty bloody fast
[09:35] <maswan> Mithrandir: Well it was slow to begin with, since I only got 400kB/s starting out at the mirroring
[09:35] <Mithrandir> maswan: yeah, and that was before the announce and all, so it shouldn't have had any load to speak of then anyway.
[09:37] <maswan> Mithrandir: my first directory (/releases) went at 470k/s, second (edubuntu/releases) went at 222k/s, third dir is still running
[09:39] <seb128> Adri2000:
[09:39] <seb128> # grep dbus-glib-1 /usr/lib/*.la
[09:39] <seb128> /usr/lib/libgnomebt.la:dependency_libs='
[09:39] <seb128> etc
[09:39] <seb128> Adri2000: on my feisty pbuilder
[09:39] <seb128> Adri2000: libgnomebt needs a rebuild, I'll do that now
[09:39] <Adri2000> seb128: with what packages installed?
[09:40] <seb128> apt-get build-dep gnome-phone-manager from a clean pbuilder
[09:40] <seb128> i386 feisty
[09:40] <seb128> with apt-get update before
[09:40] <seb128> so it's current uptodate
[09:41] <seb128> weird that you don't have that
[09:42] <Adri2000> I had only installed libdbus-glib-1-dev
[09:42] <seb128> Adri2000: well
 seb128: grep libdbus-glib /usr/lib/*.la < it should find something?
 seb128: in my pbuilder-feisty, with libdbus-glib-1-dev, it finds nothing
[09:43] <seb128> that is weird
[09:43] <seb128> are you sure you had all the build-depends for gnome-phone-manager installed?
[09:44] <Adri2000> no :) I'm installing all the build-dep at the moment
[09:45] <Adri2000> with all the B-D it works
[09:46] <seb128> Adri2000: sure, you installed dbus-glib-dev
[09:46] <seb128> anyway get the new libgnomebt when gnome-bluetooth has built
[09:46] <seb128> I've just uploaded the package
[09:47] <seb128> you can upload gnome-btdownload if you want
[09:47] <seb128> ups
[09:47] <seb128> gnome--phone-manager
[09:47] <seb128> gnome-phone-manager
[09:49] <Adri2000> seb128: so gnome-phone-manager should build when the new libgnomebt/gnome-bluetooth is built?
[09:50] <seb128> correct
[09:51] <seb128> I've deleted /usr/lib/libgnomebt.la in my pbuilder and retried and it built fine
[09:54] <Adri2000> ok, thank you :)
[10:01] <alex-weej> ok
[10:01] <alex-weej> it seems disc drives are statically configured in fstab - is there no way to dynamically detect drives as well as the media that goes in them?
[10:03] <alex-weej> i don't think people would normally think of updating an fstab if they installed a new DVD burner
[10:05] <seb128> Adri2000: np
[10:17] <alex-weej> here's a question for the pros, can i safely read-only mount a filesystem on a loop that is actively being written to?
[10:17] <alex-weej> sorry wrong channel
[10:23] <T`> hi.. i want to repackage my own deb package from new sources for verve-plugin... is there some tutorial on how to do this? and is there a .spec equivalent for .deb?
[10:25] <mc44> T`: ask for help in #ubuntu-motu
[10:25] <T`> mc44, thanks
[11:12] <superm1_> i was looking at the source for ubuntu-meta, and I don't see how "ubuntu-desktop" gets placed into the "Meta Packages" section.  debian/control doesn't specify a section.
[11:12] <superm1_> could someone explain how it is getting placed here?
[11:18] <jorgp> where should I go for a backporting pbuilder problem? #ubuntu-motu everyone is asleep
[11:18] <superm1_> jorgp, how did you generate the P builder?
[11:18] <superm1_> from the ubuntu packaging guide?
[11:18] <superm1_> *pbuilder
[11:19] <superm1_> http://doc.ubuntu.com/ubuntu/packagingguide/C/gs-pbuilder.html ?
[11:19] <jorgp> im using edgy, wanted to backport a package to dapper
[11:19] <superm1_> right
[11:19] <superm1_> so did you make a dapper pbuilder
[11:19] <superm1_> per that guide?
[11:19] <jorgp> I did sudo pbuilder create --distribution dapper
[11:20] <jorgp> yes
[11:20] <superm1_> does the package depend on anything in universe or multiverse?
[11:20] <jorgp> that part works fine
[11:20] <jorgp> no
[11:21] <jorgp> my problem is the package when I run sudo pbuilder build package.dsc
[11:21] <superm1_> okay well that looks right then
[11:21] <superm1_> what package?
[11:21] <jorgp> the configure of the package says configure: error: C compiler cannot create executables
[11:21] <jorgp> wine
[11:22] <superm1_> had to pick one i cant try on amd64 huh?
[11:22] <_ion> Have you installed build-essential?
[11:22] <Chipzz> jorgp: wrong channel
[11:22] <Chipzz> jorgp: check config.log
[11:22] <jorgp> yes
[11:22] <superm1_> jorgp your not trying on AMD64 too are you?
[11:22] <jorgp> no
[11:22] <Chipzz> jorgp: this channel is about the development OF ubuntu, not development WITH ubuntu
[11:22] <superm1_> okay msg me
[11:30] <cjwatson> superm1_: metapackages> it's overridden centrally in the archive
[11:30] <cjwatson> should probably be synced into the package at some point
[11:30] <superm1_> cjwatson, so if i wanted to create a package that went into the Meta Packages group, would i add "Section Meta\ Packages" to debian/control?
[11:31] <cjwatson> there is no space, and no capitals
[11:31] <cjwatson> "Section: metapackages"
[11:31] <superm1_> ah
[11:31] <cjwatson> "Meta Packages" is just presentation
[11:31] <superm1_> that explains my build problems that were failing at the very end
[11:31] <superm1_> i see
[11:33] <superm1_> thanks cjwatson.  your also the main dev on ubiquity right?
[11:34] <cjwatson> yes
[11:34] <superm1_> well i wanted to ask you how you would feel about a second ubiquity installer, derived from it for installing a mythtv specific system
[11:35] <geser> would an update to gnupg2 2.0.1 (plus fix for CVE-2006-6235) be accepted for feisty?
[11:35] <superm1_> i was planning such a project in the coming months, and would like to have it included during the normal ubiquity build, and jst generate two different binaries
[11:35] <superm1_> an ordinary ubiquity installer and the mythtv version
[11:36] <superm1_> the plan would then be to have live disks that could be distributed to install myth specific systems
[11:36] <superm1_> and i really didnt want to bring this into a derivative project, but keep it in the ubuntu family
[11:37] <crimsun> geser: what does 2.0.1 add over 2.0.0?
[11:39] <crimsun> geser: check w/ keescook, btw, since he uploaded gnupg
[11:39] <geser> it has some support for the keypad of my smartcard reader which I would like to use
[11:40] <keescook> geser: from the security perspective, as long as the CVE fix is included, I don't mind (I actually just uploaded gnupg2 with the CVE fixed)
[11:41] <crimsun> yep, that's what I figured, since I saw gnupg uploaded
[11:42] <geser> keescook: would you sponsor the upload once I've packages ready?
[11:43] <keescook> geser: sure. is the 2.0.1 from Debian, or new packaging?
[11:45] <geser> Debian has no 2.0.1 yet (and with the upcoming freeze I don't really believe it will be included)
[11:45] <geser> it's a new orig.tar.gz with the current diff.gz (minus the .in changes)
[11:46] <keescook> geser: sounds like a quick review.  :)  sure, let me know when you have it ready.
[11:50] <superm1_> cjwatson, i'm not sure you saw what i posted above, but what do you think of this idea?
[11:52] <linux__> leute
[11:56] <cjwatson> superm1_: if you just need it to install different stuff, all you need to do is make the fillive filesystem have different contents
[11:57] <cjwatson> you don't need to modify the installer for that
[11:57] <superm1_> well some of the installed stuff will be custom
[11:57] <superm1_> say for a frontend only box
[11:57] <superm1_> versus a backend only box
[11:57] <superm1_> but i'd like to be able to install from the same disk for both cases
[11:58] <superm1_> so i was figuring have the common packages on the disk, but then an extra section to install the extra packages for each in the installer
[11:59] <cjwatson> I'm happy to discuss that sort of thing, but a separate ubiquity binary isn't appropriate - that sort of thing should be configuration
[11:59] <superm1_> Ok.
[12:00] <cjwatson> mail me with specifics of the situation and I can make suggestions
[12:00] <superm1_> Okay i will do.  i have to finish brainstorming some ideas, and then i will
[12:00] <superm1_> thanks for the help
[12:01] <cjwatson> np
[12:09] <jmg> hello all
[12:09] <jmg> is anyone aware of issues with lvm support in edgy
[12:09] <jmg> i only see one open bug in launchpad
[12:10] <jmg> i am experiencing extremely unusual behavior
[12:11] <LaserJock> if a bug is open then people then I guess people are aware