[03:46] <ashok> hi friends
[03:46] <ashok> anyone here
[04:02] <mneptok> nope
[04:02] <ashok> oh
[04:02] <ashok> i am a new developer
[04:03] <ashok> want to contribute to ubuntu
[04:03] <ashok> can u help me where to start with
[04:03] <mneptok> https://wiki.ubuntu.com/MOTU
[04:03] <ashok> seen it
[04:14] <`23meg> ashok, https://wiki.ubuntu.com/NewDeveloperProcess
[05:46] <Hobbsee> hi all
[05:47] <Burgundavia> hey Hobbsee
[05:47] <ion_> Hi
[05:48] <Hobbsee> :)
[06:49] <Hobbsee> Keybuk: ping @ MOM
[08:16] <pitti> Good morning
[08:21] <Hobbsee> morning pitti!
[08:22] <pitti> hey Hobbsee 
[08:52] <viviersf> Mithrandir, ping
[08:56] <Mithrandir> viviersf: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
[08:57] <Hobbsee> bitten by contentlessping.pl...
[08:57] <viviersf> lol
[08:58] <viviersf> Mithrandir, i spoke to you about uswsusp a while back and i was just wondering if it was goign to be standard on gutsy ?
[08:58] <Mithrandir> viviersf: nobody has picked it up and run with it, so I would be surprised if that happens.
[08:59] <viviersf> Mithrandir, okay cool thx
[09:02] <Hobbsee> seriously, why cant windows software just work?  that includes labview.
[09:02] <Hobbsee> grrr.
[09:05] <stdin> umm, because it's windows?
[09:06] <viviersf> Hobbsee, cos then you wouldnt need to buy updated versions ?
[09:07] <Hobbsee> mmm. *grumbles a bit more*
[09:07] <Hobbsee> i think i'm actually using a more updated version than what's on the lab computers anyway
[09:10] <StevenK> viviersf, Mithrandir: I've been merging it for Gutsy, but that's about it.
[09:11] <viviersf> StevenK, i know ive filed sum bugs on it with patches for you
[09:11] <viviersf> StevenK, i got an issue with it when upgrading kernels :(
[09:12] <StevenK> Don't suspend if you're going to boot a new kernel.
[09:13] <LaserJock> Hobbsee: you working on Labview today?
[09:13] <Hobbsee> LaserJock: yeah.  attempting to.  but the ppt that i was working from doesnt seem to wish to open
[09:18] <Lure> Mithrandir: can you give-back strigiapplet on i386 (not sure why only i386 got old version of libstrigihtmlgui-dev)
[09:19] <Mithrandir> Lure: given-back
[09:19] <Lure> Mithrandir: thanks
[09:22] <viviersf> StevenK, i know that :)
[09:34] <hunger> I got a strange effect: I can log into my box in X, all the apps from my session start up fine. But I can not have new apps connect to the X server anymore...
[09:34] <hunger> DISPLAY is set, I am running gutsy.
[09:38] <hunger> Sorry... my mistake: Mounted /tmp over the X server named pipes:-)
[09:46] <mitsuhiko> doko: got a second?
[09:47] <cjwatson> dholbach: gnome-orca's uninstallable on the CDs because it depends on libgnome-speech3 rather than the current libgnome-speech7. I had a look at the source but the control file has weird hardcoded dependencies and I wasn't sure I could safely touch it. Could you sort it out?
[09:48] <dholbach> cjwatson: sure
[09:49] <cjwatson> thanks
[09:50] <doko> mitsuhiko: sure
[09:51] <mitsuhiko> doko: i recently encountered some problems with pycentral. really, really strange ones
[09:51] <doko> bug number?
[09:51] <mitsuhiko> i then contacted Piotr Oarowski who maintains my python packages in debian and he had no idea
[09:51] <mitsuhiko> i haven't filed a bug because i don't have any information to offer
[09:52] <mitsuhiko> the only thing i know is that it broke completely after i installed a python 3000 build
[09:53] <mitsuhiko> i can file a bug if wanted, but the only thing i know is that most of the prerm scripts now break because they are unable to locate the python version
[09:53] <mitsuhiko> symlink of python points to python2.5
[09:54] <mitsuhiko> and also this:
[09:54] <mitsuhiko> $ pycentral showdefault
[09:54] <mitsuhiko> in/python2.5
[09:55] <doko> pycentral showdefault is deprecated; pyversions -d should replace it
[09:55] <doko> I haven't tested the support tool with python3000 yet 
[09:55] <doko> where is python3000 installed?
[10:02] <mitsuhiko> doko: i have removed it in the meantime
[10:02] <mitsuhiko> it was in /usr/local
[10:02] <mitsuhiko> doko: i know that it's deprecated, but it shouldn't fail tough
[10:03] <mitsuhiko> is there some database pycentral has?
[10:04] <mitsuhiko> because even reinstalling pycentral hasn't fixed the problems
[10:05] <doko> no state information
[10:06] <doko> ls -l /usr/bin/python ?
[10:06] <mitsuhiko> lrwxrwxrwx 1 root root 18 2007-05-13 16:11 /usr/bin/python -> /usr/bin/python2.5
[10:07] <mitsuhiko> (interesting permissions Oo)
[10:07] <cjwatson> symlinks are always like that
[10:07] <mitsuhiko> okay
[10:08] <mitsuhiko> doko: also pyversions -i only shows python2.4 and python2.5 although i have python2.3 too
[10:10] <mitsuhiko> alright. i have more information now
[10:11] <cjwatson> lrwxrwxrwx 1 root root 9 2007-05-24 17:29 /usr/bin/python -> python2.5
[10:11] <cjwatson> looks like pycentral doesn't like the /usr/bin/ on the front
[10:11] <mitsuhiko> http://beta.paste.pocoo.org/show/168
[10:11] <doko> mitsuhiko: you did change things manually?
[10:12] <mitsuhiko> doko: i changed the python symlink a couple of times i guess
[10:12] <mitsuhiko> and my python3 installation of course. but i now use that only in my local folder
[10:13] <mitsuhiko> s/local/~/p3yk/
[10:13] <doko> mitsuhiko: pycentral could be a more robust, but changing anything in /usr, which is not in /usr/local or /etc may break your system
[10:13] <doko> so this should make it work again: ln -sf python2.5 /usr/bin/python
[10:14] <mitsuhiko> doko: yeah. that works indeed
[10:17] <mitsuhiko> doko: awesome. thanks :D
[11:06] <jdub> Keybuk: yay, esr hot potato for you!
[11:06] <Keybuk> jdub: he's been hanging out on #upstart for a few days
[11:07] <Keybuk> his chkconfig thing does look useful
[11:09] <highvoltage> Keybuk: just be careful, you might just end up on ELER ;)
[11:15] <Keybuk> I love petunias, don't you?
[11:17] <siretart> Mithrandir: there is something fishy with ffmpeg, the source is in main, but the binaries are in universe. could you please move libavcode-dev, libpostproc-dev, libavformat plus their dependencies on the respective library packages to main and give back xine-lib on all archs?
[11:28] <Mithrandir> doko: your ia32-libs upload seems to be missing a replaces on ia32-libs-gtk, or it should not include libXcursor.
[11:29] <doko> Mithrandir: I didn't merge that, or is this an earlier upload?
[11:29] <Mithrandir> doko: hm, I thought it was you
[11:30] <Mithrandir> ah, pitti is the uploaded.
[11:30] <doko> heh, it's universe now :-)
[11:30] <Mithrandir> uploader, even
[11:30] <Mithrandir> doko: that doesn't help when it's still installed on lots of systems.
[11:31] <Hobbsee> Mithrandir: yes, that was pitti.  i've been meaning to bug him about that, as it meant one of my packages ftbfs
[11:31] <pitti> Mithrandir: oh, will fix
[11:31] <Hobbsee> there's a few related bug reports for those packages
[11:31] <pitti> siretart: ^ maybe you can incorporate this small change into your prepared upload which merges the games stuff?
[11:33] <pitti> Mithrandir: so, I'll coordinate this with siretart to avoid two uploads of that huge beast in a row
[11:35] <Mithrandir> pitti: sure, thanks.
[11:35] <Mithrandir> I just noticed it's been like that for a few days, and getting it fixed would be good
[11:40] <pitti> Mithrandir: I think we'll just fix it for good and merge ia32-libs and -gtk
[11:40] <Keybuk> Hobbsee: you ping'd?
[11:41] <Hobbsee> Keybuk: indeed.  
[11:42] <Hobbsee> Keybuk: MOM appears not to have picekd up that i merged sword a while ago.  i've recently been notified that the new patch is not on patches.ubuntu.com.  I'm not sure where the proceedure is breaking down, but it being broken isnt so great.
[11:42] <Hobbsee> and i've got no idea who to poke about it not beign on p.u.c - perhaps you could deal with it and/or pass it on?
[11:42] <Keybuk> patches.ubuntu.com is MoM
[11:43] <Hobbsee> point.  then it's your domain, i believe.
[11:43] <Keybuk> which sword package?
[11:43] <Keybuk> (full source package name)
[11:44] <Hobbsee> er, sword.
[11:44] <Keybuk> no such source package
[11:44] <Hobbsee> it is the source package name.
[11:44] <Keybuk> try again :)
[11:44] <Hobbsee> it's listed on MOM as sword
[11:44] <Keybuk> hmm
[11:44] <Keybuk> oh
[11:44] <Keybuk> it's blacklisted
[11:44] <Hobbsee> ah right
[11:45] <Keybuk> removed it from the blacklist, it'll show up soon
[11:45] <Hobbsee> great :)
[11:45] <Keybuk> tollef blacklisted it because it caused a sync problem
[11:45] <Hobbsee> ahhh
[11:45] <Hobbsee> yes, differing tarballs
[11:45] <Hobbsee> one day, hopefully upstream will release a new tarball, and it can stay synced forever more.
[11:45] <StevenK> Keybuk: Is MoM able to show something is blacklisted?
[11:45] <Hobbsee> same to kguitar.
[11:46] <Hobbsee> i just look forward to that day.
[11:46] <Keybuk> StevenK: it's a general archive blacklist
[11:46] <Keybuk> http://people.ubuntu.com/~ubuntu-archive/sync-blacklist.txt
[11:46] <StevenK> Ah
[11:46] <Mithrandir> I should find some free time to nuke the top of the blacklist
[11:49] <StevenK> hotplug # all hail udevd
[11:50] <StevenK> Hah, there's one worse.
[11:52] <elmo> I'm glad someone cleaned up that file before publicizing it - the version in the dak tree had err, much more interesting comments
[11:53] <StevenK> elmo: Actually, you're in it with "elmo, comment lost" a little bit
[11:54] <elmo> yeah, I know
[11:54] <elmo> the original version of that, f.e. was:
[11:54] <elmo> # old MOTU removals - use to have reasons, but I trashed the blacklist file by mistake.  go me. [JT] 
[11:54] <StevenK> Muahaha
[11:54] <StevenK> I'm curious about some of these much more interesting comments, though. :-)
[11:55] <Mithrandir> they'
[11:55] <Mithrandir> argh
[11:55] <cjwatson> it is possible that we artificially lost some of those reasons
[11:55] <Mithrandir> they're actually lost, not just put in revision control.
[11:55] <Mithrandir> cjwatson: *cough*. :-P
[11:56] <Hobbsee> haha
[11:56] <Hobbsee> cjwatson: data loss bug.  totally coincidental.
[11:56] <Hobbsee> and the backups failed.
[11:57] <Mithrandir> we use the Linus Backup Strategy, didn't you know?
[11:57] <Mithrandir> publish your stuff on an ftp site and let the world mirror it.
[11:58] <zakame> lol
[12:00] <cjwatson> speaking of madison, anyone fancy porting rmadison to Ubuntu? madison.php is available from debian-qa CVS, and I'm sure it could be run easily enough on rookery or somewhere else with a full mirror
[12:01] <StevenK> Must it be PHP? :-)
[12:02] <cjwatson> I'm no PHP fan, but it's what's there; at least it should have a compatible interface
[12:02] <cjwatson> rmadison already supports multiple backends
[12:02] <Keybuk> there was certainly a pert turn of phrase we used in some cases
[12:03] <Mithrandir> hm, what does rmadison do again?
[12:03] <cjwatson> remote madison; talks to a CGI
[12:04] <Mithrandir> ah, ok.
[12:04] <cjwatson> debian-qa CVS> I mean svn these days
[12:04] <Mithrandir> my ~/bin/madison is ssh merkel.debian.org madison "$@"
[12:07] <cjwatson> ooh, there's a perl implementation
[12:07] <cjwatson> I might just spend ten minutes deploying that this afternoon
[12:07] <Keybuk> you have 10 minutes of CFT?  you clearly don't have enough to do <g>
[12:08] <cjwatson> you just work for ten more minutes in the evening :P
[12:08] <StevenK> Finally. Memory usage isn't 100%
[12:09] <Keybuk> cjwatson: David knows where the circuit breakers are
[12:09] <Mithrandir> Keybuk: 10 hours of battery life and neighbour with wifi. :-P
[12:09] <StevenK> I have one, but not the other. Pity.
[12:10] <Keybuk> my neighbours use *my* WiFI
[12:10] <StevenK> Figure out which neighbours and bill them?
[12:19] <Hobbsee> heh, another good removal message...
[12:19] <Hobbsee> ltsp-utils # ogra wails like a girl if this gets sync'd
[12:19] <lathiat> heh
[12:20] <siretart> pitti: right, I think we should just merge all three of ia32-libs{,-gtk,-sdl}
[12:20] <pitti> siretart: I agree; easier to maintain and update
[12:20] <ogra> Hobbsee, how did you know :)
[12:21] <ogra> Hobbsee, but its a) blacklisted and b) i talked to the DD who agreed to drop it from debian
[12:21] <Mithrandir> ogra: Hobbsee was reciting from the sync-blacklist.
[12:21] <Hobbsee> ogra: haha
[12:22] <pitti> siretart: hmm, you already added some GTKish bits to your version, didn't you? does -gtk actually contain anything on top of that?
[12:22] <ogra> Mithrandir, ah
[12:27] <siretart> pitti: I've added the packages that where comment out in the previous version of the package
[12:27] <siretart> pitti: the comment was that they were in universe. most probably some of them are in ia32-libs-gtk as well
[12:27] <pitti> siretart: ah, ok; do you feel like merging -gtk, too, or do you want to send me your current patch and I finish it for -gtk?
[12:28] <siretart> pitti: If you have time now, I'd prefer to send you my patch
[12:28] <siretart> (/me at work now and has to fight a lot with perl :/)
[12:28] <pitti> siretart: not now, probably on Monday
[12:28] <siretart> ah, ok. 
[12:29] <pitti> siretart: tomorrow might work too if archive stuff doesn't keep me busy all the day
[12:29] <siretart> so either I find the time tomorrow or I'll send you the patch
[12:29] <pitti> siretart: good luck with Perl :)
[12:29] <pitti> siretart: so, if you can send me the patch, then I'll look into it ASAP unless you IRC-ping me about it and beat me to it
[12:29] <siretart> pitti: you said that running fetch-source.sh with BUILD=0 was okay, right?
[12:29] <pitti> siretart: fetch-and-build.sh, yes
[12:30] <siretart> err, yes. okay
[12:30] <pitti> siretart: those are perfectly valid buildd generated .debs, so I don't see a reason to not use them
[12:30] <siretart> okay
[12:30] <siretart> I'll add a note to the readme about that
[12:44] <Keybuk> cjwatson: http://merges.ubuntu.com/stats.txt
[12:45] <StevenK> Keybuk: Should you comment out events that fall off the front of the graph like Edgy Release and Edgy's archive being open?
[12:48] <Mithrandir> the code should remove them, IMO
[01:04] <fabbione> Seveas: ping?
[01:09] <fabbione> so it is safe to upgrade gutsy with the new lvm/raid stuff?
[01:10] <fabbione> or can i expect the world to explode?
[01:15] <cjwatson> $ scripts/rmadison.pl -u ubuntu -s gutsy -c main -a i386 man-db man-db |    2.4.4-3 |         gutsy | i386
[01:15] <cjwatson> excellent
[01:15] <cjwatson> (ignoring stupid irssi line-wrapping; anyone know how to turn that off?)
[01:16] <cjwatson> $ scripts/rmadison.pl -u ubuntu -s gutsy -c main -a i386 man-db
[01:16] <cjwatson>     man-db |    2.4.4-3 |         gutsy | i386
[01:16] <cjwatson> better; /set paste_join_multiline off
[01:18] <StevenK> cjwatson: Oh neat. I've been wondering how to stop irssi doing that.
[01:19] <StevenK> cjwatson: How many lines is rmadison.pl ?
[01:20] <cjwatson> 233
[01:29] <pitti> mjg59: can we trade merges? I'd like to avoid breaking laptop-mode-tools and hand this off to you, and in return grab dhcdbd from you
[01:29] <Hobbsee> mergebay again!
[01:29] <pitti> yay
[01:30] <Lure> pitti: if you can let exiv2 and libkdcraw past binary NEW it would make new digikam build ;-)
[01:31] <pitti> Lure: looking
[01:31] <Lure> pitti: thanks
[01:31] <pitti> Lure: there's no exiv2 in NEW
[01:32] <pitti> neither is kdcraw
[01:32] <pitti>      exiv2 |     0.14-1 |         gutsy | source
[01:32] <pitti>      exiv2 |     0.14-1 | gutsy/universe | amd64, i386, ia64, powerpc, sparc
[01:32] <seb128> pitti: I accepted them before lunch, why?
[01:32] <pitti> looks current
[01:32] <pitti> seb128: ah :)
[01:33] <pitti> seb128: because Lure asked
[01:33] <seb128> ah, k
[01:33] <elmo> why does our tzdata package ask me questions  in it's postinst ?
[01:33] <elmo> like, not even with debconf
[01:34] <pitti> elmo: erm, it's not supposed to; we fixed the debconfishness right at the beginning of gutsy 
[01:34] <pitti> elmo: what does it ask?
[01:34] <elmo> pitti: ok, this is feisty
[01:34] <elmo> Your current time zone is set to Unknown
[01:34] <elmo> Do you want to change that? [n] :
[01:34] <pitti> elmo: right, it didn't have any debconf stuff in feisty yet
[01:34] <fabbione> if [ "$USER" = "*elmo*" ] ; then debconf_ask_random_question; fi
[01:34] <elmo> pitti: ok, as long as it'll go away at some point
[01:35] <pitti> elmo: is that true? I. e. did you really not have a TZ set before? or is that an upgrade bug?
[01:35] <elmo> pitti: it's a chroot
[01:35] <elmo> pitti:  I probably didn't have a TZ set
[01:35] <pitti> ah, I see
[01:35] <elmo> (ronne's feisty-amd64 chroot to be precise)
[01:35] <pitti> elmo: in gutsy that's properly debconfified now
[01:35] <elmo> cool
[01:36] <Lure> pitti: sorry, seb128 was too fast
[01:36] <Lure> pitti: so libkdcraw is fine for main inclusion?
[01:36] <pitti> Lure: I didn't look at it yet
[01:37] <StevenK> (I need to upload a build1 of a rdepends)
[01:37] <Lure> StevenK: great - I was just preparing the list for Riddell ;-)
[01:38] <StevenK> Lure: And what did main ever do to it?
[01:38] <StevenK> I didn't think that was much that depends on exiv2
[01:39] <pitti> BenC: FYI, I don't NEW the new kernel as long as it's FTBFS on powerpc, to avoid unnecessary ABI bumps in case the powerpc build fix needs to change ABI
[01:40] <BenC> pitti: sure things, I have another upload ready
[01:40] <pitti> BenC: oh, good morning. Early bird :)
[01:41] <fabbione> hey BenC 
[01:41] <fabbione> BenC: upload? please pull the gfs2 stuff from kernel.org pretty please?
[01:41] <fabbione> BenC: and add the 3 extra symbols?
[01:42] <fabbione> BenC: and re-enable gfs1? :P
[01:42] <fabbione> (don't pull from my tree.. it's borked)
[01:42] <BenC> fabbione: I'll see what I can do, I didn't want to have to go through another round of build/boot tests...but for you, I might :)
[01:42] <fabbione> BenC: ok.. if it's not this one, can you please make sure it's queued for the next?
[01:42] <fabbione> BenC: i can't build userland without the new headers
[01:43] <BenC> definitely
[01:43] <fabbione> and i need to start doing some QA on that stuff before we find that the world crashes 2 days before release
[01:43] <BenC> need to get some coffee, just rolled out of bed
[01:43] <fabbione> ehhe
[01:43] <fabbione> enjoy
[01:43] <pitti> yay Priority: headers! /me hugs cjwatson; gutsy debootstrap works again
[01:44] <cjwatson> yeah, it's healthier now
[01:57] <dholbach> MOTU Q&A session in 3 minutes in #ubuntu-classroom
[02:14] <fabbione> Keybuk: ping?
[02:15] <fabbione>  /etc/udev/rules.d/75-persistent-net-generator.rules <- rewriting config files, isn't that a policy violation?
[02:15] <Keybuk> no
[02:15] <Keybuk> rewriting conffiles is a policy violation
[02:15] <ogra> conffiles is :)
[02:15] <Keybuk> rewriting config files is entirely valid <g>
[02:16] <ogra> even though the definition in the policy is not very precise there, i often have that discussion with DDs as well
[02:17] <fabbione> anyway that script is buggy...
[02:17] <fabbione> a lot :)
[02:17] <fabbione> it's breaking my decnet setup...
[02:18] <fabbione> how can i live without decnet ?
[02:18] <fabbione> :P
[02:19] <Keybuk> hmm?
[02:19] <Keybuk> what's the bug?
[02:19] <fabbione> Keybuk:  i am kidding.. it's not serious..
[02:19] <Keybuk> it's an upstream script, so we should probably fix it if it's broken for something
[02:20] <fabbione> decnet protocol changes mac address on the interface in a very consistent way to define the "node address" (similar to the ip address)
[02:20] <fabbione> that creates 2 entries in the rules
[02:20] <nosrednaekim> hello,does anyone know what language the restricted manager is written in? I would like to port it to kubuntu
[02:20] <fabbione> and the interface that was named eth0 all of a sudden becomes eth1
[02:21] <fabbione> decnet setup can break and so does the ip because there might be no entry for eth1 in interfaces
[02:21] <Keybuk> fabbione: they're named eth* ?
[02:21] <fabbione> decnet breaks because you can specify what interface to use
[02:21] <ion_> nosrednaekim: Python, and its core functionality is separate from the UI, so it should be somewhat trivial.
[02:21] <fabbione> Keybuk: yes..
[02:21] <Riddell> nosrednaekim: we already have someone working on that
[02:21] <nosrednaekim> ion_: cool, I know Python!
[02:21] <fabbione> Keybuk: there is no reason to change iface name.. just the mac address
[02:21] <Keybuk> fabbione: we can add a rule to skip the script if we know a little more about it
[02:21] <nosrednaekim> Riddell: great minds think alike.. oh well
[02:22] <Riddell> nosrednaekim: although there are other programmes to be ported if you feel the urge
[02:22] <fabbione> Keybuk: second.. let me gather enough info...
[02:22] <Keybuk> or we can add decnet support to the script
[02:22] <nosrednaekim> Riddell: ok,like what? I really only know python
[02:22] <fabbione> Keybuk: dnet-common or dnet-progs use /etc/default/decnet.
[02:23] <fabbione> Keybuk: in that file there is: DNET_INTERFACES=""
[02:23] <Riddell> nosrednaekim: ltsp-manager for example https://wiki.kubuntu.org/EdubuntuKDE
[02:23] <fabbione> if empty .. decnet won't run
[02:23] <Keybuk> fabbione: oh, it's a software thing and not a kernel thing?
[02:23] <fabbione> all = get all interfaces in decnet mode/mac
[02:23] <fabbione> nope.. it's all userland.. well the part that interest us at least
[02:23] <fabbione> or a list of iface/ifaces
[02:23] <Keybuk> so you can do decnet on any ethernet card?
[02:23] <fabbione> yes
[02:24] <fabbione> it's enough you can change the mac address
[02:24] <fabbione> i am no decnet expert.. really. what i found was by mistake
[02:24] <fabbione> i thought it was worth mentioning it
[02:24] <Keybuk> I'll raise it upstream :)
[02:24] <fabbione> there might be other protocols doing stuff like this
[02:24] <fabbione> yup.. fair enough..
[02:25] <Keybuk> best fix would be to identify the cards participating in decnet by some other means than their mac address
[02:26] <fabbione> well you have that config file
[02:26] <fabbione> and the initscript for decnet to look at
[02:26] <Keybuk> that config file takes interface names <g>
[02:26] <Keybuk> which aren't stable unless you have this config file
[02:26] <fabbione> right...
[02:26] <Keybuk> which would change the names assigned by that config file
[02:26] <Keybuk> chicken
[02:26] <Keybuk> egg
[02:26] <Keybuk> cluck
[02:26] <fabbione> bzzzt
[02:26] <fabbione> no.. they solved that problem a while ago
[02:26] <nosrednaekim> Riddell: I was also thinking about adding a wattmeter to guidance-power-manager
[02:26] <fabbione>  /. for it
[02:26] <Keybuk> hmm
[02:26] <fabbione> :)
[02:27] <Keybuk> you use decnet?
[02:27] <fabbione> not yet.. i installed the packages to do some testing
[02:27] <Keybuk> unless I'm mistaken here (tracking workflow)
[02:27] <Keybuk> this will work just fine
[02:27] <Keybuk> 1) kernel adds network interface
[02:27] <Keybuk> 2) udev renames it according to its hardware mac address
[02:28] <Keybuk> 3) decnet picks up interface from DNET_INTERFACES according to its udev-fixed name
[02:28] <fabbione> yes...
[02:28] <Keybuk> 4) decnet changes mac address
[02:28] <Keybuk> udev won't change the name again, because it's already set
[02:28] <Keybuk> that's what the NAME!="?*" thing is for
[02:28] <fabbione> 5) network manager takes down the interface and reset it...
[02:28] <cjwatson> ooh, ooh, debmake is up for demotion since dmapi stopped using it
[02:28] <Keybuk> fabbione: network manager only downs the interface
[02:28] <Riddell> nosrednaekim: interesting idea, although I do wonder if the best place for it is ksysguard
[02:28] <cjwatson> *clicketyclick*
[02:28] <Keybuk> it doesn't pull out the card
[02:28] <fabbione> 6) udev picks an up/down and rename it
[02:28] <Riddell> nosrednaekim: but I'm sure if you did that we'd include it
[02:28] <StevenK> cjwatson: Yay!
[02:29] <Keybuk> no, udev picks up hardware insertion/removal
[02:29] <Keybuk> not interface config changes
[02:29] <Keybuk> that's HAL-land
[02:29] <fabbione> Keybuk: well something is renaming it and once i cleaned the 70*.rule i got my eth0 back
[02:29] <Keybuk> you'd have a suspend/resume issue, since the hardware does get removed and re-inserted
[02:29] <fabbione> [   51.927759]  skge eth0: addr 00:13:d4:85:0f:a4
[02:29] <fabbione> [   90.967360]  skge eth1: enabling interface
[02:29] <fabbione> notice this in dmesg
[02:30] <fabbione> 39 seconds in between
[02:30] <fabbione> this is a clean boot
[02:30] <Keybuk> but after the resume, the card would have its hardware mac again, so you'd need to reapply dnet again
[02:30] <Keybuk> sure
[02:30] <Keybuk> it'll get renamed to a persistent name
[02:30] <Keybuk> that just means that last time you booted, some other card had eth0
[02:30] <nosrednaekim> Riddell: it only works on very new machines which have acpi 2, but I have the python framework which prints out the readings to the command line. If you are interested
[02:30] <Keybuk> so that card is "eth1", and should be referred to as such in DNET_INTERFACES
[02:30] <Keybuk> it won't get renamed after dnet tarts
[02:30] <fabbione> in the rule file I had eth0 with the decnet mac address
[02:30] <fabbione> and eth1 with the real address
[02:30] <Keybuk> rule file?
[02:30] <Keybuk> oh
[02:30] <fabbione> the 70-generated...
[02:31] <Keybuk> that probably *is* a postinst bug
[02:31] <Keybuk> in that the postinst ran while you were using decnet, and seeded the initial copy of the file
[02:31] <fabbione> oooooo...
[02:31] <Keybuk> that's just a temporary hack anyway
[02:31] <fabbione> yeps.. ok.. then we are at the same page
[02:31] <Keybuk> I meant to copy iftab in, and let the others fix at reboot time
[02:31] <fabbione> ok.because i had iftab.. and it was ignored
[02:31] <Keybuk> but didn't get around to fully testing the perl, so went with the hack for now
[02:31] <fabbione> ok..
[02:31] <fabbione> fair enough
[02:32] <fabbione> at the next update i will see how it explodes :)
[02:32] <Keybuk> the actual proper udev rule stuff shouldn't break
[02:32] <Keybuk> if you rmmod and insmod the module, the software mac address will be forgotten anyway
[02:32] <fabbione> i will test that at the next reboot
[02:32] <fabbione> yes and that's fine..
[02:32] <Keybuk> interestingly, dnet should probably have a udev rule to run every time a network interface is inserted, no? :p
[02:32] <fabbione> Keybuk: sounds like a good idea...
[02:34] <pitti> Mithrandir: can you please give-back hplip?
[02:35] <Mithrandir> pitti: backgegubt.
[02:35] <pitti> :)
[02:38] <Lure> nosrednaekim: does it get info through HAL? we would not like to add too many interfaces beside HAL to it...
[02:39] <Lure> nosrednaekim: and you may want to join #kubuntu-devel
[02:39] <nosrednaekim> Lure: will do.
[02:40] <nosrednaekim> Lure: sent you a message over there
[02:59] <dholbach>  dpkg-source -b libgdamm3.0-2.9.5
[02:59] <dholbach> Undefined subroutine &main::warn called at /usr/bin/dpkg-source line 349.
[02:59] <dholbach> debuild: fatal error at line 1239:
[02:59] <dholbach> ^- anybody had that problem too?
[03:02] <pitti> dholbach: I suspect it's from yesterday's dpkg merge
[03:02] <dholbach> hrm
[03:02] <pitti> dholbach: that looks like a function that my Mainainer: check calls
[03:02] <dholbach> right
[03:03] <StevenK> pitti: use Carp instead?
[03:04] <StevenK> I love doing use Carp; cluck("");
[03:04] <pitti> StevenK: I don't know; the previous dpkg had that function
[03:05] <StevenK> pitti: Bug iwj where it went?
[03:05] <pitti> looks like a simple s/warn/warning/
[03:10] <pitti> dholbach, iwj: I'll fix it
[03:10] <dholbach> you ROCK
[03:10] <dholbach> ...but you know that already
[03:12] <kwwii> dholbach: the way things are now, to use the automaticartworkbuilder and artist needs to take an existing theme (like oransoda) and edit everything yet some things are pretty technical (like oransun-look.sh)...is there a way to remove parts of the theme without borking everything?
[03:12] <kwwii> dholbach: btw, I am working on the documentation for that stuff :-)
[03:13] <dholbach> kwwii: I read that you were working on that and was very pleased
[03:13] <dholbach> kwwii: what about example-theme?
[03:13] <robertj> hrmm patch 98_automake from gnome-system-tools won't revert...is that considered a bug?
[03:17] <kwwii> dholbach: well, it means that I'll be asking you lots of questions :p (and I could not find the example-theme package on launchpad)
[03:18] <dholbach> kwwii: http://code.launchpad.net/example-look
[03:18] <kwwii> lol, that is easy
[03:19] <kwwii> well "devel(+n)]  [Act: 2,4,5,7,8] 
[03:19] <kwwii> oops
[03:19] <kwwii> bzr: ERROR: Not a branch: https://code.launchpad.net/example-look/
[03:20] <kwwii> ok, I get it, sorry
[03:24] <ogra> oooh, someone fixed jadetex, my pbuilder works
[03:29] <pitti> dholbach: do you already know whether the -fPIC fix to texlive-bin was really necessary or just a fallout from the missing dependencies? I. e. did you get the same FTBFS locally?
[03:29] <pitti> dholbach: Debian applied all other changes, this is the only one left
[03:31] <dholbach> pitti: sorry, I didn't try it yet - let me try
[03:38] <cjwatson> stgraber: I'm just reading over https://wiki.ubuntu.com/IsoTestTracker
[03:38] <iwj> Oh, no wonder I'm so sleepy.  I have forgotten to drink any coffee today.
[03:39] <cjwatson> stgraber: my biggest concern at the moment is providing a way for release managers to sign off on problems, so that we can look through at the end and say "yes, all these problems have been noted but we're not concerned about them for release" or "oh dear, this problem is a blocker although these other 17 aren't"
[03:39] <cjwatson> stgraber: do you think that's something that could be added? I'd be willing to approve the spec with that addition
[03:39] <cjwatson> heno: ^--
[03:42] <elmo> cjwatson: so, I'm installing windows and it's playing music, like an actual song at me - when's ubiquity getting that feature? :-P
[03:42] <seb128> elmo: you have a full desktop you can use while ubiquity is running ;)
[03:43] <StevenK> elmo: When you run Rhythmbox while installing? :-)
[03:43] <seb128> that includes totem and rhythmbox ;)
[03:43] <robertj> elmo: after sitting through Apple's introductory song 100 times, hopefully never
[03:43] <pitti> elmo: Around the same time when ubiquity is ported to beryl, I think
[03:43] <robertj> (10.2 had the best one)
[03:43] <kylem> pitti, woah, that's a fantastic idea.
[03:43] <cjwatson> elmo: there's a really old community spec for that ...
[03:44] <pitti> kylem: we totally need 3D shuffling in the partitioner
[03:44] <kylem> pitti, when it's finished, the installer window could catch fire!
[03:44] <robertj> pitti: and multiple-cursor support
[03:44] <cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/music-while-installing
[03:44] <StevenK> pitti: That's about the only place I can see beryl being useful.
[03:44] <dholbach> ubiquity-sudoku-integration
[03:45] <siretart> imagine burning windows as metaphor for segfaulting applications.. brrr
[03:46] <robertj> StevenK: nahh, you just have to think about watching all the document icons fly from one drive to another during user migration ;)
[03:52] <cjwatson> bryce: any progress on the X spec changes I asked for? the deadline is today
[03:56] <dholbach> pitti: seems we can sync texlive-bin again
[03:56] <dholbach> pitti: thanks for prodding me again
[03:57] <pitti> dholbach: hm, so is the .so still built with -fPIC? if not, that'd be a bug
[03:57] <dholbach> the real bug seems to have been the missing depends
[03:57] <ogra> gah, g-p-m moved all hal code away, crap
[03:57] <pitti> dholbach: ah, yes, it is
[03:58] <pitti> dholbach: so I guess you tried adding -fPIC and it succeeded because you had libkpathsea4 installed
[03:58] <dholbach> pitti: yes, that must have been it
[03:58] <pitti> dholbach: I just checked http://buildd.debian.org/fetch.cgi?pkg=texlive-bin;ver=2007-10;arch=amd64;stamp=1180550786
[03:58] <pitti> dholbach: kpathsea uses -fPIC, so all is well
[03:58] <dholbach> yoooho
[03:58] <pitti> dholbach: thanks for checking!
[03:58] <dholbach> np
[04:21] <hjmf> hi pitti 
[04:21] <hjmf> Just read your email 'Collection of useless top functions in Apport stack traces'
[04:21] <hjmf> what I usually do are *mozilla retraces* so I look for the string '<signal handler called>' and the next 9 - 10 stacks
[04:21] <pitti> hey hjmf 
[04:22] <hjmf> last examples of it are bug 117951 home-retraced and bug 117827 from apport retracing service output
[04:22] <ubotu> Launchpad bug 117951 in firefox "[FEISTY]  firefox crashed [@IM_get_input_context]  [@nsWindow::IMELoseFocus]  (dup-of: 85627)" [High,Needs info]  https://launchpad.net/bugs/117951
[04:22] <ubotu> Launchpad bug 85627 in firefox "MASTER firefox crash [@ IM_get_input_context] " [High,Needs info]  https://launchpad.net/bugs/85627
[04:22] <ubotu> Launchpad bug 117827 in firefox "firefox crashed [@??]  [@~nsCOMPtr_base]  [@nsSoftwareUpdate::InstallJarCallBack] " [High,Needs info]  https://launchpad.net/bugs/117827
[04:22] <pitti> hjmf: thanks; you were one of the key persons ;)
[04:22] <hjmf> :)
[04:22] <hjmf> If you want I can email the related functions I use
[04:23] <pitti> hjmf: that would be very helpful indeed
[04:23] <hjmf> are for personal use thoug
[04:24] <hjmf> pitti: Ok then, I'll translate the comments, and I'll email you
[04:24] <pitti> hjmf: hm, how do you mean 'personal use'? I shouldn't put them into apport (or a .d directory which packages fill themselves or so)?
[04:24] <pitti> hjmf: thanks a lot!
[04:25] <hjmf> oh, I meant by that that was coded w/o to much care :)
[04:26] <pitti> hjmf: oh, I only need the function names and patterns, no code
[04:26] <pitti> hjmf: <signal handler called> is indeed very common, if I can rely on that for Mozilla, that would be sufficient
[04:27] <cjwatson> seb128: what are we going to do about desktop-volumes-representation? I assume you saw my comments on it
[04:27] <hjmf> pitti: it mozilla it is common for almost all the retraces, so that's all I guess
[04:27] <pitti> indeed
[04:28] <hjmf> pitti: what I do is check for that string and then the next 10 sacks, 
[04:28] <pitti> hjmf: this <signal handler called> is certainly something that should be in apport itself rather than a package specific pattern file
[04:28] <heno> cjwatson: that was the intention with marking a bug as 'Serious'. The release manager can change the seriousness of a bug and only keep the release blockers at 'Serious'. In practice it wasn't used that way, so I can see the case for adding another knob.I'll do that now.
[04:28] <hjmf> if the string is not indeed the just pick up the first 10 stacks :)
[04:29] <pitti> hjmf: My idea was to unwind Stacktrace down to that line and then generate StacktraceTop starting from that; that should give us what we want wrt. https://wiki.ubuntu.com/ApportCrashDuplicates
[04:29] <pitti> hjmf: yep, same approach here :)
[04:29] <hjmf> ah OK, the for mozilla will be OK :)
[04:29] <hjmf> the/then
[04:30] <mjg59> pitti: Sure
[04:30] <pitti> hjmf: also, I made various improvements to the retracer and the ddeb archive now, let's hope that the auto retraces are much less crappy in the future
[04:30] <pitti> mjg59: thanks, I'll appreciate
[04:30] <hjmf> pitti: good! 
[04:31] <hjmf> pitti: bye then :)
[04:31] <seb128> cjwatson: yes I read your comment, I've updated the implementation part to list only the things we want to do (ie, not change ubiquity nor gparted)
[04:31] <pitti> hjmf: bye, and thanks a lot
[04:32] <hjmf> pitti: yw
[04:35] <cjwatson> heno: thanks, yeah, I don't think the seriousness knob worked all that well partly because some of the people who should have been able to set it had no idea how to. :)
[04:35] <Mithrandir> heno: I'm looking at the mobile-onscreen-keyboard spec.  The mockups there are meant as examples, not necessarily what we will want to end up with?
[04:36] <heno> Mithrandir: examples of what is possible, yes
[04:36] <heno> I should make that clear in the spec
[04:37] <Mithrandir> heno: yes, that would be good, since it's very easy to look at the screenshots and go "I like this"/"I don't like this" and think the screenshots are binding for the spec.
[04:39] <heno> Mithrandir: agree. done.
[04:49] <cjwatson> heno: looking at installer-for-windows; do you think wubi could be taught to use the CD as an alternative to loop-mounting the install image?
[04:50] <heno> cjwatson: you mean run from the CD or make an ISO image in Windows first?
[04:51] <cjwatson> heno: either, but run from the CD seems more efficient?
[04:52] <heno> it has been raised, certainly saves a download
[04:52] <cjwatson> and we know we can boot Ubuntu from the CD :-)
[04:52] <cjwatson> in fact, it's clear this is doable; why don't I just go ahead and change it
[04:52] <heno> cjwatson: I'm sure Wubi could be taught to do one of those
[04:52] <heno> cjwatson: please do
[04:56] <Mithrandir> heno: do we know who'll implement the mobile onscreen keyboard?
[04:57] <heno> Mithrandir: Chris Jones (the maintainer) has said he'll work on it after his exams
[04:58] <heno> Mithrandir: being a community contribution, it's not guaranteed of course
[04:58] <heno> (nor is anything really)
[04:58] <cjwatson> mdz: could you re-review installer-for-windows? I've addressed your comments
[05:00] <mdz> cjwatson: could you send me email so I remember after the meeting?
[05:01] <cjwatson> mdz: will the mail from LP do?
[05:01] <mdz> cjwatson: yes, if I haven't received it yet
[05:01] <mdz> yep, just came in
[05:11] <Mithrandir> pitti: but, esc is just, esc?
[05:12] <pitti> Mithrandir: vim user :)
[05:12] <pitti> Mithrandir: I told my keyboard to swap esc and caps lock
[05:12] <Mithrandir> then make esc a compose key. :-P
[05:12] <pitti> (which is why I screw up on pretty much every other keyboard I sit at :) )
[05:29] <ogra> pitti, gpm-button.c:329: error: 'udi' undeclared (first use in this function)
[05:30] <ogra> do you know if there is something in hal now that provides udi ?
[05:30] <pitti> ogra: no idea, there's too little context for me; however, that looks like a local variable
[05:30] <ogra> seems all hal related code was moved out of gpm now ....
[05:30] <pitti> thus nothing to do with hal
[05:34] <BenC> offtopic> Anyone know a video/audio encoder that actually _uses_ threads for multicore/smp systems?
[05:35] <BenC> converting videos for my blackberry, and it seems a real waste of hw to do it on a 8-way 2.6ghz xeon and only have it use one thread
[05:35] <kylem> multithreaded codecs are difficult, i don't know of one offhand.
[05:35] <ogra> pitti, gah, silly me, it was from one of our patches
[05:36] <BenC> supposedly xvid does it, but it doesn't seem to be working
[05:36] <BenC> maybe mencoder isn't using the API right
[05:37] <pitti> BenC: hm, maybe just convert 8 videos in parallel?
[05:37] <bryce> cjwatson: re X spec changes, yes I have some further info to add; I'll get it finished up today
[05:37] <BenC> pitti: I'm going dvd->mpeg4/mp3, so the dvd extraction is the thread bottle neck for that
[05:39] <BenC> not sure why I'm so worried about it, since it only takes 20-30 minutes to convert in in single thread, but I just hate seeing it go to waste :)
[05:46] <bryce> cjwatson: same with the bulletproofX spec; I have some code for that too
[05:47] <cjwatson> bryce: ok, please let me know when you're done and I'll look over it again
[05:50] <bryce> ok great
[06:29] <Seveas> fabbione, pong
[06:30] <Seveas> Keybuk, I spec-i-fied the usplash design yesterday
[06:30] <Seveas> ah, you approved it already (just reading mail), gracias!
[06:35] <nnonix> Please excuse the OT question, but what do you guys think of the Dell E1505n notebook?
[06:36] <nnonix> I'm considering it due to the dell/ubuntu deal.
[06:37] <bryce> nnonix: I ordered the E1505n.  Scheduled to arrive tomorrow :-)
[06:43] <xivulon> Keybuk are you around?
[06:44] <Keybuk> xivulon: yup, what's up?
[06:44] <xivulon> hi I am ago
[06:44] <xivulon> One of Wubi devs
[06:45] <xivulon> I had a conversation with cjwatson and he referred me to you
[06:45] <xivulon> www.wubi-installer.org
[06:46] <Keybuk> ok ...
[06:46] <xivulon> Some of the functionality of wubi will be incorporated into gutsy
[06:47] <xivulon> At the moment there is a problem in the shutdown sequence
[06:47] <xivulon> https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/87763
[06:47] <ubotu> Launchpad bug 87763 in sysvinit "killall5 in /etc/init.d/sendsigs should not kill ntfs-3g and other fuse filesystems" [Wishlist,Confirmed]  
[06:47] <xivulon> colin mentioned that it could be addressed via session support
[06:48] <xivulon> and that is how your name came about
[06:48] <xivulon> I just heard about session support today
[06:49] <xivulon> I had a very nasty hack to go around the problem and would like to use a proper one
[06:49] <Seveas> I sent keybuk a patch for killall5 -x, could be useful as well xivulon :)
[06:49] <xivulon> Seveas will that address the bug above?
[06:49] <Seveas> (-x for excluding pid's)
[06:49] <Seveas> xivulon, it helps
[06:49] <xivulon> nice
[06:50] <Seveas> I need it for usplash :)
[06:53] <xivulon> so I'd need to patch sendigs so that it finds processes that rely on fuse and add pass them -x
[06:53] <xivulon> How does session support come into the picture?
[06:54] <Seveas> I don't know what cjwatson had in mind
[06:54] <Seveas> probably something better, since this is a hack :)
[06:55] <Keybuk> I don't know what cjwatson had in mind either
[06:55] <Keybuk> but excluding processes from killall is trivial, since it's just a for() loop :p
 sure, though it doesn't sound to me like sendsigs itself should be changed at all
[06:57] <Seveas> kylem, shouldn't filsystems (except /) already be unmounted before sendsigs is called?
 perhaps it would be better to get the fuse processes into the same session as sendsigs
[06:58] <Seveas> err, Keybuk*
 the session support is there to make that kind of thing unnecessary
[06:58] <Seveas> xivulon, I'm not sure that is true
[06:59] <Seveas> ah, it is
[06:59] <Seveas> that would indeed help
[06:59] <xivulon> Could you explain pls?
[06:59] <xivulon> I know nothing about session support
[06:59] <Seveas> apt-get source sysvinit, read src/killall5.c, line 639-646
[07:00] <Seveas> actually, those line numbers may be off
[07:00] <xivulon> Not on a ubuntu machine atm
[07:01] <xivulon> Will have a look toonight
[07:01] <Seveas> 611-613
[07:01] <Keybuk> Colin is clearly barmy
[07:01] <Seveas>         for (p = plist; p; p = p->next)
[07:01] <Seveas>                 if (p->pid != pid && p->sid != sid && !p->kernel)
[07:01] <Seveas>                         kill(p->pid, sig);
[07:02] <Keybuk> the only way for killall and fuse/ntfs-3g to be in the same session is for them to have been spawned by the same process
[07:02] <Seveas> ah
[07:02] <Keybuk> that code is literally just there to stop killall killing the shell that ran it
[07:02] <Keybuk> (or the shell script that it's running from)
[07:03] <Seveas> ah, setsid isn't used to set the sid but to create new ones
[07:03] <xivulon> So I guess that -x is my best shot
[07:03] <Keybuk> right
[07:03] <Keybuk> setsid() creates a new session, with the sid equal to your pid
[07:03] <Seveas> bummer
[07:03] <Keybuk> it also creates a new process group (pgrpid == sid)
[07:03] <Keybuk> and your process becomes the leader of that process group
[07:04] <Keybuk> (which is to do with terminals and stuff, mostly)
[07:05] <Seveas> Keybuk, what is this stevens set you talk about? Useful programming books?
[07:06] <Seveas> http://www.computerboek.nl/boekeninfo.asp?CODE=nhqmmncqbqihr&RefererID=NHP_int
[07:06] <Seveas> looks useful :)
[07:07] <glatzor> mpt: I redesigned the dialog and just wrote an email to the ubuntu-dekstop list
[07:08] <Keybuk> W. Richard Stevens
[07:08] <Keybuk> Advance Programming in the UNIX Environment
[07:09] <Keybuk> UNIX Network Programming vol 1 + 2
[07:09] <Keybuk> TCP/IP Illustrated
[07:09] <Keybuk> those four books are pretty much essential bibles for programming
[07:09] <Keybuk> they're also very useful for reaching high shelves
[07:10] <Seveas> yeah, found them all
[07:10] <Seveas> ordering the first one now
[07:10] <Keybuk> I've not seen the Rago re-work of APUE yet
[07:12] <cypherbios> glatzor: I made a small patch to software-properties adding the --add-cdrom command-line call method
[07:12] <glatzor> oh cool cypherbios
[07:12] <cypherbios> glatzor: I'll work on a --hide-main-window later
[07:12] <cypherbios> glatzor: it works for both -gtk and -kde
[07:14] <Riddell> cypherbios: how does it work under kde?
[07:15] <cypherbios> Riddell: it's just a small path that add the parser option --add-cdrom, which call the on_button_add_cdrom_clicked()
[07:16] <glatzor> Riddell: you wrote the KDE frontend :)
[07:16] <Riddell> cypherbios: that button doesn't do anything on the kde frontend, since we don't have a gui way to add CDs
[07:16] <cypherbios> :)
[07:16] <glatzor> cypherbios: how do you plan to detect the correct frontend?
[07:16] <cypherbios> Riddell: yes, we have a KDE gui for add cds
[07:16] <cypherbios> Riddell: you made the GUI :)
[07:17] <cjwatson> Keybuk: heh, ok
[07:17] <cjwatson> Keybuk: I think I must have thought that init had its own session that got used for init scripts or something
[07:17] <cjwatson> although this doesn't stand up to the cold light of day
[07:17] <bryce> cjwatson: ok this one is ready to go:  https://wiki.ubuntu.com/Xorg7%2e3Integration
[07:18] <cypherbios> glatzor: I didn't take a look how to detect yet. But I plan to check if the software-properties-gtk is installed first, if yes use it (software-properties-gtk --hide-main-window --add-cdrom) if isn't installed use the -kde version instead
[07:18] <cjwatson> Seveas: sendsigs is called before umountfs and umountroot
[07:18] <Keybuk> cjwatson: sysvinit gives each entry in inittab a new session
[07:18] <Keybuk> upstart gives each job a new session
[07:18] <Riddell> cypherbios: does it work for you?
[07:18] <cjwatson> which is pretty much required since you need to kill off processes that might have things open on those fses
[07:19] <Keybuk> Seveas: since otherwise you can't unmount /usr cause processes are using it
[07:19] <cjwatson> it's just a bit unfortunate for userspace filesystems, which need to be excluded
[07:19] <cypherbios> Riddell: in the s-p-kde you have the button 'Add CDROM' right?
[07:19] <cjwatson> would it be possible to identify processes that are implementing userspace mounts at the killall5 level
[07:19] <cjwatson> ?
[07:19] <cjwatson> I don't really like the idea of having sendsigs have to go round identifying those processes
[07:19] <Keybuk> dunno
[07:20] <Keybuk> I don't think it shows up anywhere
[07:20] <Riddell> cypherbios: yes
[07:20] <Seveas> Evrrything's possible, identifying them in sendsigs seems easier though
[07:20] <cypherbios> Riddell: in the third-party software tab
[07:20] <Keybuk> it's not as if there's something as elegant as a pid in /proc/mounts
[07:20] <Riddell> cypherbios: it doesn't seem to work adding a dapper CD
[07:20] <Keybuk> (cause that'd be useful)
[07:20] <Keybuk> there might be something in /proc/fuse, if such a thing exists
[07:21] <Seveas> fuser /dev/fuse
[07:21] <cypherbios> Riddell: so what my patch does is just add a call method (--add-cdrom) tho use s-p-{kde|gtk} to call the function def on_button_add_cdrom_clicked()
[07:21] <Seveas> gives you the pids of fuse things
[07:22] <Keybuk> Seveas: relying on fuser scares me
[07:22] <Keybuk> since you can have two /dev/fuse
[07:22] <ogra> not with our udev rule
[07:22] <ogra> (but indeed that might change)
[07:23] <Seveas> lsof | grep /dev/fuse any better? (don't know much about how either works) 
[07:23] <Keybuk> ogra: cp /dev/fuse /tmp
[07:23] <Keybuk> Seveas: same problem
[07:23] <Keybuk> cp -a
[07:23] <cypherbios> Riddell: What the s-p does is just use python-apt to add the repository-medium as apt source, so the GUI for doing this doesn't matter, I think the GUI just show a progress dialog (gtk or qt) showing the progress and asking for a medium
[07:23] <Seveas> grep /usr/lib/libfuse.so /proc/*/maps
[07:23] <ogra> Keybuk, heh, right, didnt think of that
[07:23] <Keybuk> oh,
[07:24] <Keybuk> there's a fuse filesystem
[07:24] <ogra> yep
[07:24] <ogra> since recently
[07:24] <ogra> pre last upload to feisty brought it
[07:24] <Keybuk> it bogusly wants to mount under /sys though
[07:24] <Keybuk> tsk
[07:24] <Keybuk> don't suppose anyone has active fuse mounts right now?
[07:25] <ogra> i can create one in a second
[07:25] <Seveas> I have
[07:25] <Seveas> sshfs#blackbird:/tmp on /home/dennis/p type fuse (rw,nosuid,nodev,max_read=65536,user=dennis)
[07:26] <Riddell> cypherbios: ok, still doesn't work for me though
[07:26] <Riddell> but that's my problem
[07:26] <ogra> ltspfs /tmp/.ogra2-ltspfs/edubuntu fuse rw,nosuid,nodev,user_id=1002,group_id=1002 0 0
[07:26] <Keybuk> Seveas: could you try for me
[07:26] <Keybuk> mount -t fusectl none /sys/fs/fuse/connections
[07:26] <Keybuk> and then look in that directory
[07:26] <Riddell> glatzor: I still think s-p should include commercial and backports
[07:26] <ogra> Keybuk, that dir should be there if the module is loaded
[07:27] <Seveas> mount failed indeed, it existed 
[07:27] <Seveas> nothing useful though
[07:27] <ogra> Keybuk, but by nature for fuse you cant rely on being able to read the subdir contents
[07:27] <cypherbios> Riddell: actually I didn't tried the Add CDROM option of software-properties. Until now I've just used the synaptic --ask-cdrom to do it graphically
[07:27] <ogra> s/for/of/
[07:27] <Riddell> cypherbios: yeah, that's the one we're missing (in adept)
[07:27] <glatzor> Riddell: it already includes backports and if commercial is added to the third party tab is not my decision.
[07:27] <Seveas> root@mirage:~# ls /sys/fs/fuse/connections/
[07:27] <Seveas> 1
[07:27] <Seveas> root@mirage:~# cat /sys/fs/fuse/connections/1/*
[07:27] <Seveas> cat: /sys/fs/fuse/connections/1/abort: Invalid argument
[07:27] <Seveas> 0
[07:28] <glatzor> cypherbios: if there is a problem, it is a bug
[07:28] <Seveas> (the 0 is the contents of a file called waiting)
[07:28] <Riddell> glatzor: where does it include backports?
[07:28] <glatzor> Or does it not?
[07:28] <glatzor> Riddell: i have to check :)
[07:29] <glatzor> Riddell: "Not supported updates (feisty-updates)"
[07:29] <cypherbios> glatzor: I have a lot of repository CDs and DVDs here, I'll test the s-p Add CDROM function and see what happens, but I think it works
[07:29] <glatzor> (feisty-backports)
[07:29] <ogra> Seveas, 
[07:29] <ogra> ogra@laptop:~/packages/gnome-power-manager-2.19.2$ mount |grep fuse
[07:29] <ogra> ltspfs on /tmp/.ogra2-ltspfs/edubuntu type fuse (rw,nosuid,nodev,user=ogra2)
[07:29] <ogra> ogra@laptop:~/packages/gnome-power-manager-2.19.2$ sudo ls /tmp/.ogra2-ltspfs/edubuntu
[07:29] <ogra> ls: /tmp/.ogra2-ltspfs/edubuntu: Permission denied
[07:29] <glatzor> Riddell: it is on the updates tab
[07:29] <ogra> fuse has some weird features :)
[07:29] <Seveas> ogra, I know
[07:30] <cypherbios> Riddell: what doesn't work for you when adding a CD with s-p-kde?
[07:30] <Seveas> ogra, I implemented my own fuse fs once, wrapping gnomevfs. Didn't really work
[07:30] <Riddell> cypherbios: progress dialogue just sits there doing nothing
[07:30] <glatzor> Riddell: Canonical only has to add their disabled apt line somewhere in the sources.list with a comment and it would show up.
[07:31] <Keybuk> ogra: why can't you guarantee it?
[07:31] <glatzor> Riddell: I even bloged about this some days ago.
[07:32] <Seveas> Keybuk, because the userland fs implementation can do what it wants
[07:32] <ogra> Keybuk, sorry i was misled, i thought the Permission denied issue for rrot also applies to the sysfs data
[07:32] <ogra> *root
[07:32] <cypherbios> Riddell: you are trying using the alternate ubuntu cd?
[07:32] <Keybuk> sure
[07:32] <Riddell> glatzor: so I just need to convince cjwatson :)
[07:32] <cypherbios> *are you
[07:32] <Riddell> cypherbios: ah, no, that could help 
[07:32] <Riddell> duh
[07:32] <cypherbios> :)
[07:32] <ogra> but apparently i can still access the sysfs data as root (even i cant see the fs contents)
[07:32] <cypherbios> heheh
[07:32] <Keybuk> ok ...
[07:33] <Keybuk> what is in the sysfs data?
[07:33] <Keybuk> (trying to get back to answering the original question)
[07:33] <ogra> ogra@laptop:~/packages/gnome-power-manager-2.19.2$ sudo ls /sys/fs/fuse/connections/1/
[07:33] <ogra> abort  waiting
[07:33] <ogra> waiting contains a zero
[07:33] <Seveas> abort has mode 200, waiting mode 600 and contains 0
[07:33] <ogra> ah, thats why i cant read it :)
[07:33] <Seveas> actually, waiting has mode 400
[07:34] <Seveas> echo 1 > abort --- seems to have no effect
[07:34] <Keybuk> ok
[07:34] <Keybuk> what do the files contain?
[07:34] <ogra> 0
[07:35] <ogra> nothing else
[07:35] <Seveas> ah, wait
[07:35] <Keybuk> bugger
[07:35] <Seveas> after echo 1 > abort, i get this:
[07:35] <Keybuk> so nothing useful like the pid of the daemon
[07:35] <Seveas> dennis@mirage:~$ ls p
[07:35] <Seveas> ls: p: Transport endpoint is not connected
[07:35] <ogra> what does mount think ?
[07:35] <Seveas> mount still thinks it's there (that misled me)
[07:39] <cjwatson> Riddell: I'm ok with it being added commented out; file a bug on apt-setup?
[07:40] <Riddell> cjwatson: ok, cool
[07:40] <Keybuk> ogra: so is there any way to determine the list of fuse processes
[07:41] <cypherbios> Riddell: I just tested the s-p-kde to add a CDROM (also using the --add-cdrom) and it works for me (very well I'd say). But seems it needs some error handle -- for example when add a invalid media (such a live cd ;))
[07:44] <Riddell> cypherbios: does the gtk frontend have that error handler do you know?
[07:44] <ogra> Keybuk, not to my knowledge
[07:44] <ogra> they run as users ...
[07:45] <ogra> so there is no central point apart from probably the fusectl fs (which doesnt contain anything)
[07:47] <ogra> best would likely be to patch fusermount to drop the pid into /sys/fs/fuse/connections/
[07:47] <cypherbios> Riddell: For me it works (both kde and gtk), even if I add a invalid media its says: Error sanning the CD\n Unable to locate any package files, perhaps this is not a Debian Disc
[07:47] <xivulon> Keybuk, Seveas, ogra can I assume you'll try to take care of the sendsigs/fuse issue? 
[07:47] <Keybuk> cjwatson: don't poke where I'm poking, we might tear a hole
[07:48] <cypherbios> Riddell: I mean, if is a valid media it works well, if it's not says that the media is invalid -- A good behavior at all
[07:48] <Riddell> cypherbios: it seems to sometimes work and sometimes leave progress dialogues doing nothing (for invalid media)
[07:48] <cypherbios> Riddell: what version of s-p are you trying?
[07:49] <Seveas> xivulon, don't count on me :)
[07:50] <Riddell> cypherbios: feisty version
[07:51] <cypherbios> Riddell: me too, the 0.59.4 version. But I'm testing using directly the source package (runing python software-properties-kde --add-cdrom), but it shouldn't matter
[07:53] <glatzor> Riddell: how does apt-cdrom behave on the broken medias?
[07:53] <Keybuk> ok
[07:53] <Keybuk> so the tricky thing is that a fuse filesystem is valid as long as any process holds open the file descriptor that opened /dev
[07:54] <Keybuk> (I wonder how many fuse daemons remember to close-on-exec that fd <g>)
[07:54] <cypherbios> glatzor: it usually says: "E: Unable to locate any package files, perhaps this is not a Debian Disc" indeed
[07:54] <Riddell> glatzor: complains normally and quits.  the problem will just be in the creating and deleting (or not) of dialogues
[07:54] <Keybuk> so it's valid for a fuse daemon to open("/dev/fuse"), set up a filesystem, and then spawn unrelated children passing that file descriptor to them
[07:54] <Keybuk> it's also valid for unrelated daemons to pass the fuse file descriptor between each other using a unix domain socket
[07:54] <Keybuk> (and thus the filesystem stays open and is valid)
[07:54] <cjwatson> so you really want lsof("/dev/fuse"?
[07:54] <cjwatson> )
[07:55] <cjwatson> oh, but those might have /usr open ...
[07:55] <Keybuk> cjwatson: no, since that only tells us who's opening that inode
[07:55] <Keybuk> and yeah, then we're into tricky territory
[07:55] <Keybuk> what happens if the fuse filesystem daemon is in /usr/sbin and being used to mount /usr/local ? :p
[07:55] <cjwatson> so IMHO there's only one thing we really care about here, and that's if a fuse filesystem daemon is used for /
[07:56] <Keybuk> right
[07:56] <Keybuk> well
[07:56] <Keybuk> no
[07:56] <Keybuk> actually I think it's still valid to not kill them
[07:56] <Keybuk> since they'll be killed by unmounting the fuse filesystem anyway
[07:56] <Keybuk> it just means we have to unmount the fuse one first ?!
[07:56] <Keybuk> bah
[07:56] <Keybuk> -TERM them :)  they should cleanly unmount the filesystem damnit
[07:56] <Keybuk> yeah
[07:56] <Keybuk> we only care about /-on-fuse
[07:56] <cjwatson> it means we have to go round and round until everything dies, in umountfs
[07:57] <Keybuk> Dear Kernel Developers,
[07:57] <Keybuk> THIS is why these things belong in kernel-space, not userspace
[07:57] <Keybuk> fortunately they realised the same thing about splitting out the partition code before they went ahead with it!
[07:57] <kylem> ssh does not believe in the fecking kernel.
[07:57] <kylem> ;-)
[07:57] <kylem> er, belong
[07:57] <cjwatson> -TERM should do, I guess
[07:57] <Keybuk> kylem: killing ssh doesn't normally trash your root filesystem <g><
[07:58] <cjwatson> I'd be curious to know if ntfs-3g cleanly unmounts on -TERM
[07:58] <Keybuk> hmm
[07:58] <cjwatson> that's the concrete use here
[07:58] <Keybuk> do we care about /-on-fuse right now?
[07:58] <cjwatson> yes, installer-for-windows
[07:58] <Keybuk> why is that fuse?
[07:59] <Keybuk> surely that's just loop?
[07:59] <cjwatson> loop on ntfs
[07:59] <cjwatson> stable ntfs support => ntfs-3g => fuse
[07:59] <Keybuk> oh
[07:59] <Keybuk> that makes things even worse
[07:59] <Keybuk> since / isn't fuse
[07:59] <cjwatson> ntfs-3g installs a SIGTERM handler which appears to exit cleanly
[07:59] <Keybuk> so "is / fuse?" won't work
[08:00] <cjwatson> point
[08:00] <Keybuk> since the answer is N, / is loop
[08:00] <Keybuk> I really can't say a way around this right now
[08:00] <cjwatson> this is beginning to sound like the initramfs code that mounts the ntfs bit should leave a note for sendsigs
[08:00] <cypherbios> Riddell, glatzor: all CD/DVD I've created using aptoncd and also some Ubuntu (alternate) and Debian ones works well with sofware-properties's Add CDROM -- I think everything is fine
[08:00] <Keybuk> kernel engineering to export the list of pids using a particular file descriptor associated with each /dev/fuse connection
[08:00] <Riddell> cypherbios: groovy
[08:00] <cjwatson> which I guess leads us back to changing sendsigs
[08:01] <Keybuk> yes, I think we're back to a "don't kill THIS pid" file
[08:01] <cjwatson> sigh. oh well, it's doable
[08:01] <Keybuk> we have a patch to change sendsigs anyway, for usplash
[08:01] <cjwatson> is killall5 -x reasonable?
[08:01] <Keybuk> so if we're taking the hit, we may as well go for full guts and gore
[08:01] <Keybuk> it's not unreasonable
[08:01] <cjwatson> sendsigs --shaun-of-the-dead
[08:02] <Keybuk> it's kinda "I promise these pids are only in / and don't have anything opening for writing"
[08:02] <sladen> using lsof style stuff it should be possible to check that
[08:03] <Keybuk> err
[08:03] <Keybuk> I think we're into "contract" here, rather than "check"
[08:03] <kylem> cjwatson, LOL.
[08:09] <cjwatson> [ job kbd_1.12-18ubuntu1_source from kbd_1.12-18ubuntu1_source.changes
[08:10] <cjwatson> yay for untested weirdness
[08:13] <glatzor> cypherbios: Oh, I can relax now again :)
[08:18] <cypherbios> glatzor: you guys have done a good work, there is nothing to fear about it ;)
[09:26] <glatzor> Riddell: it would be nice if the guidance python packages would be part of module
[09:26] <glatzor> Riddell: e.g. guidance.displayconfigabstraction
[09:49] <ogra> cjwatson, how am i supposed to get usplash installed currently ? 
[09:49] <ogra> ltsp-build-client fails on it
[10:08] <bryce> cjwatson: ok, this spec is updated too:  https://wiki.ubuntu.com/BulletProofX
[10:17] <glatzor> bryce: could you sponsor a new upload of displayconfig-gtk?
[10:18] <glatzor> bryce: it now uses the guidance-backends instead of shipping our own copy
[10:18] <bryce> glatzor, unfortunately I don't currently have upload privs.  We could ask kees or kylem
[10:19] <glatzor> bryce: oh, I can also drop an email to dholbach
[10:19] <glatzor> bryce: he is my nanny as long as mvo is on vac :)
[10:19] <bryce> ok cool.  :-)
[10:20] <bryce> btw, I'd appreciate your comments on that bulletproof-x spec too - there's a few items there we'll need from displayconfig-gtk to support it, so I'd like to get your input on them
[10:22] <cypherbios> glatzor: my patch is ready to review. I added the --add-cdrom and when using it doesn't show the main window -- works for both gtk and kde. Could you review and let me know what you think?
[10:23] <cypherbios> Riddell: are you interested in take a look too?
[10:24] <glatzor> cypherbios: for sure. just drop me an email. but I am in the kitchen now.
[10:25] <glatzor> cypherbios: it is getting quite late in GB. So I am not sure if Ridell is still around
[10:25] <cypherbios> glatzor: no hurry. I'm going to a meeting right now, then to home. If you want to tell me something drop me an email ;)
[10:26] <cypherbios> here it's about 5pm, time to go home :D
[10:48] <ogra> that new X is awesome
[10:48] <bryce> heya ogra
[10:48] <bryce> good to hear :-)
[10:49] <ogra> all my thin clients boot without xorg.conf it seems
[10:49] <ogra> and to the right resolution
[10:49] <ogra> that will gain us over 20 seconds bootspeed
[10:49] <ogra> (in ltsp)
[10:49] <bryce> awesome
[10:49] <ogra> eah, you really rock 
[10:49] <ogra> :)
[10:50] <pygi> auto-magic sometimes isn't good :)
[10:50] <bryce> also, I hear we can run with incomplete xorg.conf's, although I haven't tested that myself - in theory you can specify keyboard layouts, but leave out the Screen, Device, and Monitor sections
[10:50] <ogra> well, i can script that as well to be done at rutime ...
[10:50] <ogra> *runtime
[10:50] <bryce> ah, cool
[10:51] <ogra> xmodmap and xrandr should do here ... so we can get the greeter up even earlier but unresponsive and greyed out until the setup is done ... so the user has something to look at
[11:20] <bryce> glatzor: I've updated the displayconfig spec:  https://wiki.ubuntu.com/DisplayConfigGTK
[11:20] <cjwatson> ogra: usplash installs fine in a clean chroot for me. What's the problem?
[11:20] <bryce> glatzor: mostly I just folded the user and UDS comments into the main, and added a test plan section, but it would be good to review it in detail in case there are any other corrections needed
[11:21] <ogra> it wont install without artwork here and the artwork doesnt want to get onfigured without usplash installed
[11:21] <ogra> it will take me a while to get the exact error again (i dropped usplash for now during testing here and need to rebuild the chroot first)
[11:22] <ogra> hmm
[11:23] <cjwatson> I just installed it here without artwork
[11:23] <glatzor> bryce: oh, fine. I haven't found the time to do this
[11:23] <ogra> just apt-get'ing in the installed chroot works fine
[11:23] <ogra> how strange
[11:24] <cjwatson> happy to help once you have a better idea of what's going on ;-)
[11:25] <cjwatson> if you can, perhaps try building the ltsp chroot with DEBCONF_DEBUG=developer to see if it's usplash's debconf interaction that's going wrong
[11:25] <bhale> has anyone renewed their coredev membership yet?
[11:25] <bhale> i imagine it is the same as the new member policy
[11:26] <ogra> cjwatson, i'll rebuild the chroot ... must be related to ltsp-build-client's settings somehow
[11:26] <cjwatson> I certainly wouldn't rule out a usplash bug, just don't know what it is yet ...
[11:27] <glatzor> bryce: could you set the sub dialog thing to should be decided later
[11:28] <glatzor> bryce: system > administration > screen and graphics  seems to be a better place
[11:29] <bryce> I wonder if it wouldn't hurt to have it both places?
[11:29] <bryce> which sub dialog thing?
[11:29] <glatzor> bryce: the advanced button
[11:30] <bryce> hmm, mdz was fairly specific to do it that way though
[11:30] <cjwatson> bryce: "Tools which need to override portions of xorg.conf (Kickstart, displayconfig-gtk, etc.) should be modified to cause a full xorg.conf to be written out before they add their overrides."
[11:31] <cjwatson> bryce: that can't be done in the case of Kickstart - that code runs at the very start of installation
[11:31] <bryce> hmm
[11:31] <glatzor> bryce: mdz said that he would not like to fight with me :)
[11:32] <glatzor> bryce: but having feedback on this won't be the worst idea
[11:32] <cjwatson> bryce: the way it works is that the person doing the installation provides an installation script which may include various X settings, and our Kickstart implementation translates those into preseeded values in the debconf database which are (much) later honoured by the X maintainer scripts while generating xorg.conf
[11:32] <cjwatson> so Kickstart is very different from displayconfig-gtk in this regard - it's just telling the X maintainer scripts what to do
[11:33] <bryce> cjwatson: ok; would Kickstart be able to deal with an incomplete xorg.conf?  I think for moving ahead with enhanced use of config autodetection, we're going to need it to accept that?
[11:33] <cjwatson> bryce: I'd say that if there are preseeded values in the debconf database in the fresh-install case then X should honour them and skip autoconfiguration
[11:33] <cjwatson> bryce: when Kickstart runs, xorg.conf is a distant dream
[11:33] <cjwatson> this is in the alternate installer, pre-X
[11:34] <glatzor> bryce: furthermore we provide the same features as the GNOME dialog. and even more.
[11:34] <bryce> glatzor: ok, why don't you make that change, and then if there is still strong feelings in favor of that, you can discuss it further at that point
[11:34] <cjwatson> it is certainly possible (and common enough) to omit X configuration in a Kickstart file, which should cause autodetection to be used
[11:34] <cjwatson> but if it's explicitly configured there, it seems that it should be honoured ...
[11:35] <bryce> cjwatson: ok, sounds good
[11:36] <glatzor> bryce: I am going to bed. See you!
[11:36] <bryce> glatzor: sure, cya tomorrow
[11:37] <bryce> cjwatson: I guess my one concern is if this may narrow the situations where autoconfig is used to only a very small set of cases (but maybe that's good?)
[11:39] <cjwatson> bryce: I shouldn't think so; Kickstart is used by a relatively small number of people doing large deployments
[11:39] <bryce> ah ok cool
[11:39] <cjwatson> the set of people doing that sort of automatic installation are generally expected to be relatively clueful
[11:40] <bryce> ok maybe I misinterpreted "preseeded values in debconf database"
[11:40] <bryce> I take it this means, preseeded prior to installation by the user?
[11:41] <cjwatson> bryce: may be worth reading https://help.ubuntu.com/7.04/installation-guide/i386/appendix-preseed.html
[11:41] <cjwatson> right
[11:41] <cjwatson> the effect of preseeding is to set a value for a question in the debconf database, and generally also to set the 'seen' flag on that question that indicates that it's been asked
[11:42] <bryce> okay, gotcha
[11:42] <cjwatson> unfortunately (?) this is indistinguishable from the question already having been asked in a previous dpkg run - sort of by design
[11:42] <bryce> I've added a 5. in Autoconfiguration support for this
[11:43] <cjwatson> but xserver-xorg's maintainer scripts already check whether they're doing a fresh install or doing an upgrade, which is sufficient to disambiguate
[11:43] <cjwatson> because on upgrades I imagine you'd often want to convert to autodetection
[11:43] <tepsipakki> some of the xserver-xorg debconfage has been removed by debian, but only the uninteresting ones (like modules, fontserver)
[11:45] <cjwatson> tepsipakki: the stuff nobody bothered to preseed anyway? :)
[11:46] <tepsipakki> cjwatson: right, and where the defaults cover 99,999% of cases :)
[11:48] <alex-weej> Xorg CPU usage spikes to 100% when i move my mouse - only started happening today. Any idea how to debug?
[11:50] <bryce> alex-weej: there's been several 100% CPU Xorg bugs reported
[11:51] <bryce> so I'd start by searching for them in LP
[11:51] <alex-weej> ca you give me a hint to their content so i can take a look?
[11:51] <alex-weej> any words to search for
[11:51] <bryce> sure, one sec
[11:51] <alex-weej> i thought it was a problem when dragging windows at first :(
[11:51] <tepsipakki> alex-weej: feisty or gutsy?
[11:51] <alex-weej> feisty
[11:52] <bryce> here's a search that seems to pull many of them up:  https://bugs.launchpad.net/ubuntu/+source/xorg?field.searchtext=100+CPU&orderby=-importance&search=Search&field.status%3Alist=Unconfirmed&field.status%3Alist=Confirmed&field.status%3Alist=In+Progress&field.status%3Alist=Needs+Info&field.status%3Alist=Fix+Committed&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
[11:53] <alex-weej> ok thanks
[11:53] <alex-weej> was there an Xorg update over the last few days?
[11:53] <alex-weej> 'cause like i said i only started noticing it today
[11:53] <tepsipakki> alex-weej: nope
[11:53] <alex-weej> weeks? :E
[11:53] <bryce> I haven't run across ones that display 100% CPU on mouse movement, so that could be new.  But I haven't gone through the mouse-related bugs yet
[11:53] <bryce> alex-weej: yeah xserver 1.3 went through a couple weeks ago
[11:54] <alex-weej> i'm still on 7.2.0 apparently?
[11:54] <bryce> also mesa got upgraded recently, although I doubt that'd result in this
[11:54] <bryce> you mean xserver 1.2?
[11:54] <alex-weej> i guess, i just ran Xorg -version
[11:54] <bryce> oh sorry, these changes were for gutsy not feisty
[11:54] <alex-weej> ok
[11:55] <bryce> there hasn't been any x changes for feisty in a while
[11:55] <alex-weej> hm
[11:55] <ogra> cjwatson, ok, the exact error is "Keine Alternativen fr usplash-artwork.so." (sorry there is no easy way to override ltsp-build-cliet using the system locale)
[11:55] <tepsipakki> sigh, this crappy gprs/3G connection has too much latency for IRC :I
[11:56] <Mithrandir> tepsipakki: it's often better to run the IRC client locally on GPRS connections
[11:57] <ogra> cjwatson, i'll see how to inject the DEBCONF_DEBUG=developer in there to get more details
[11:57] <alex-weej> oh damnit
[11:57] <alex-weej> stracing Xorg and then doing it caused it to go mental
[11:57] <cjwatson> ogra: ok, I'll fix that, ignore the debconf comment
[11:58] <alex-weej> damn, bonobo-activation-server still refuses to quit on logout
[11:59] <cjwatson> ogra: it was dpkg --compare-versions lt rather than lt-nl for upgrade checks
[11:59] <cjwatson> dunno why it didn't break for me though
[11:59] <ogra> ah
[12:00] <ogra> well, it doesnt break if i manually apt-get it in the chroot
[12:00] <ogra> only from ltsp-build-client 
[12:01] <tepsipakki> Mithrandir: yep, probably so
[12:03] <Rinchen> Greetings.  Has anyone run across a situation where some system process on Feisty Linux c14n 2.6.20-15 and -16 smp continually writes to the harddisk? Every 30 seconds or so my harddisk starts grinding on my notebook. My desktop, same general config (diff hw) doesn't exhibit the problem.  
[12:03] <cjwatson> ogra: it's a behaviour change in update-alternatives and only happens with new dpkg
[12:03] <cjwatson> thanks for spotting that
[12:03] <Rinchen> I've shutdown almost every process (even klogd) and it still happens
[12:03] <cjwatson> you can't update-alternatives --auto an alternative that doesn't exist any more
[12:04] <ogra> oh, then i'll have to check edubuntu-artwork :)
[12:04] <Rinchen> I've also posted to the forum with no luck. I had hoped to find a clever way spying on the hd writes but haven't found one.
[12:05] <cjwatson> ogra: why?
[12:06] <cjwatson> I know it uses update-alternatives, but surely only on alternatives that exist?
[12:06] <ogra> i think i might use --auto in there, not sure its a while ago i had to touch the maintainer scripts there
[12:06] <pkl_> j #ubuntu-kernel
[12:06] <cjwatson> --auto is fine as long as the alternative can be guaranteed to exist
[12:06] <cjwatson> otherwise use || true
[12:06] <ogra> yeah
[12:06] <alex-weej> ok... linux-2.6.20-16 reintroduces a bug that stops it booting without "irqpoll" on my hardware :(
[12:07] <ogra> thats what i'm doing anyway in maintainer scripts... 
[12:07] <alex-weej> it's all going wrong for me today
[12:07] <Rinchen> fwiw, I though it was hal harddisk polling but with hal stopped it still does it
[12:08] <ogra> Rinchen, my disk is quiet here in the laptop
[12:08] <ogra> well, on half upgraded gutsy but with feisty kernel ...
[12:08] <Rinchen> Yeah that's what's annoying.  I'm on a system76 darter and others on feisty don't seem to have this problem.  My harddisk runs almost continuously.
[12:09] <Rinchen> I'm at a loss as to how to continue to diagnose it.
[12:09] <ogra> but it didnt use to do that in festy either
[12:09] <ogra> *feisty
[12:10] <ogra> does something continously write logs ? 
[12:11] <Rinchen> ogra, yeah that's what I was thinking. I'll have a look at /var/logs again. I didn't see any updates when I had kill everything I could kill