[12:32] <keescook> wow.  *that* reboot was exciting.
[12:32] <sfllaw> Mithrandir, cjwatson: Re: Bug 74004...  Have you also accepted the changes to initramfs-tools to edgy-proposed?
[12:32] <Ubugtu> Malone bug 74004 in udev "Doesn't include qla2xxx firmware" [High,Confirmed]  http://launchpad.net/bugs/74004
[12:33] <sfllaw> Mithrandir, cjwatson: Nevermind, I see it now.
[12:36] <BenC> can someone publish linux-source-2.6.20 and accompanying packages please?
[12:38] <jdub> fisty's switching to python2.5?
[12:39] <bhale> aha fisty
[12:40] <bhale> hi jdub 
[12:41] <jdub> yo bhale
[12:41] <jdub> i have an autocorrect in irssi to do that ;)
[12:41] <LaserJock> hmm, "Fisty - the Break My Python release"
[12:41] <LaserJock> so many ways that could be taken wrongly :/
[12:42] <bhale> The Fawning Fist 6.09
[12:43] <jdong> bhale: that doesn't sound right....
[12:43] <bhale> yeah no kidding
[12:43] <jdong> that sounds like a terrible joke I'd make
[12:43] <jdong> I've seen worse though
[12:43] <bhale> bluefoxicy isnt here
[12:43] <bhale> im filling in
[12:43] <jdong> one particular non-fluent english speaker at the forums....
[12:44] <jdong> in a thread he used "suppository" rahter than "repository" at least 20 times
[12:44] <LaserJock> hah
[12:44] <bluefoxicy> hahaha
[12:44] <jdong> eventually I had to go through and edit most of that
[12:44] <jdong> and pm him informing him of what suppository means
[12:44] <bluefoxicy> You need to take this with a half a glass of water
[12:44] <jdub> with a nick like jdong, of *course* it sounds like a terrible joke you'd make!
[12:44] <jdong> because people were making terrible cracks (eugh pun) about it
[12:45] <jdub> <- win!
[12:45] <bhale> jdub ftmfw!
[12:45] <jdong> lol
[12:51] <jdong> ok, there needs to be a really brute-force rough-around-the-edges nuclear superhammer for dealing with 3rd party stuff breaking core ubuntu functionality
[12:51] <jdong> ;-)
[12:52] <LaserJock> "core"? :-)
[12:52] <LaserJock> nv is workin' just great for me :p
[12:53] <jdong> LaserJock: I was referring to a mass apt-get install --reinstall, apt-get remove $unofficial_packages
[12:53] <jdong> :)
[12:53] <keescook> jdong: probably scriptable by examining the install source of a package.  :)
[12:53] <jdong> keescook: certainly it's very scriptable
[12:54] <jdong> just someone needs to have the guts to write it :D
[12:54] <LaserJock> hah, do we need a vsabdfl package?
[12:54] <keescook> haha
[12:55] <jdong> keescook: and did I read my inbox correctly  that there's more clamav patching fun for {dapper,edgy} now?
[12:55] <ajmitch> afternoon
[12:55] <keescook> jdong: yeah, there is.  the update is giant; I've got it prep'd for dapper/edgy already, but haven't had a chance to test it yet.
[12:55] <keescook> hiya ajmitch 
[12:55] <jdong> k
[12:55] <jdong> not in a hurry
[12:55] <jdong> just noted it
[12:56] <jdong> I'm just considering infinitely backporting from edgy-security for now :D
[12:56] <keescook> heh
[12:56] <jdong> of course that's nowhere near LTS timeframe
[12:56] <jdong> but meh
[12:57] <jdong> that'll give me 13 more months to come up with a better idea
[01:35] <arpu> hi @all i hvae this problem  usb 3-1: device descriptor read/64, error -71 please can anybody help me ? 
[01:36] <bluefoxicy> 
[01:36] <bluefoxicy> I can past ehere
[01:36] <bluefoxicy> pasting in firefox crashes oOo
[01:37] <arpu> but i tested it with different kernels 
[01:37] <arpu> so i think is not a kernel problem 
[01:38] <arpu> a know this usb works for some time 
[01:39] <_ion> arpu: Press the grey button on the device, the one to the right from the LED. That will definitely fix the problem.
[01:39] <arpu> _ion: sorry i do  not understand 
[01:40] <arpu> this is a webcam with pwc modul i pached the modul  with the unofficell pc modul 
[01:40] <arpu> pwc ^
[01:40] <minghua> arpu: please ask on #ubuntu for support, or file bugs in launchpad
[01:40] <minghua> arpu: this is not a support channel
[01:41] <arpu> minghua: ok thx a lot but i found a bug report but no solution 
[01:41] <arpu> mom i search 
[01:41] <bluefoxicy> this isn't a bug channel either
[01:41] <minghua> arpu: please add your comments in that bug then
[01:41] <bluefoxicy> as much as I flame the devs periodically for the particularly annoying ones.
[01:42] <bluefoxicy> i.e. the ones that cause me to lose data 6 times in 5 minutes
[01:42] <arpu> minghua bluefoxicy sorry and thx for your time and ork on ubuntu 
[01:54] <arpu> minghua: https://bugs.launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/54419 ii do not know what i can write to help 
[01:54] <Ubugtu> Malone bug 54419 in linux-source-2.6.15 "usb change between 2.6.15-23 and 2.6.15-26 breaks working setup" [High,Confirmed]  
[01:58] <minghua> arpu: I don't know anything about kernel either, sorry
[01:59] <locsmif> hi, i'm looking for the much talked about 'livecd.sh' script, where can i find it? (trying to rip ideas from it)
[02:07] <LaserJock> locsmif: "much talked about", hmmm
[02:09] <locsmif> mostly infinity and mithrandir, from what i could find on google
[02:10] <locsmif> if it's public i'd like to take a look at it and rip ideas from it for my own ubuntu or debian based livecd possibly :)
[02:11] <Seveas> locsmif, afaik it's not public
[02:12] <locsmif> oh..ok
[02:13] <locsmif> Well, at least i can stop looking for it then ;)
[02:13] <locsmif> ty
[02:13] <LaserJock> they might be able to give you a cleaned up version or something
[02:14] <LaserJock> I'm not sure
[02:14] <delire> isn't the livecd.sh used in http://reconstructor.aperantis.com/  or have i got my proverbial wires crossed?
[02:15] <LaserJock> I doubt it, if it's the script I'm thinking of
[02:15] <delire> ok
[02:16] <LaserJock> changing an existing .iso is quite a bit different then making it frm scratch
[02:34] <alex-weej> dmix is causing crackling in my stock u610 installation... :(
[02:34] <twb> Mithrandir: OK, at last I'm trying to boot the merged caspre via NFS.
[02:34] <twb> Sadly, ipconfig can no longer see eth0, a sis900-based NIC.
[02:37] <crimsun_> alex-weej: and not reproducible with plughw:0 itself?
[02:37] <twb> If, at the fallback initramfs shell, I do `modprobe sis900', ipconfig can detect eth0.
[02:37] <alex-weej> crimsun_: correct
[02:37] <twb> Any idea what's responsible for doing that modprobe when things are working?  I suspect udev.
[02:45] <twb> It appears that casper is not doing the 0x02 udev magic, which is in the nfs-top/udev script.  I'm gonna try that myself, now.
[02:54] <Chipzz> twb: sure ipconfig can't see it; that's because iPconfig is a windows command ;P
[02:55] <twb> Chipzz: nope
[02:55] <twb> ipconfig is a klibc command
[02:55] <twb> And doing the 0x02 thing fixed it.
[02:55] <twb> Yaaaay!
[02:58] <ulinskie> hello!
[02:58] <ulinskie> anybody here from ubuntu trademarks?
[02:59] <twb> Mithrandir: any idea where casper-premount/udev comes from?
[03:08] <LaserJock> ulinskie: "from" Ubuntu trademarks?
[03:09] <LaserJock> ulinskie: http://www.ubuntu.com/ubuntu/TrademarkPolicy
[03:30] <jdub> `anthony: oi.
[03:38] <twb> Mithrandir: aha, the udev file is in the udev package.
[05:15] <fabbione> morning
[05:59] <imbrandon> moins fabbione 
[06:00] <glick> hi
[06:01] <BlackCheese> hi
[06:01] <glick> i have a question
[06:01] <glick> i work with redhat at work
[06:01] <BlackCheese> fire away
[06:01] <glick> and the way they bring up the different runlevels with S scripts and K scripts is what im used to
[06:01] <glick> how does ubuntu do it
[06:01] <glick> i guess to bring up runlevel 3 it just runs the scripts in rc3.d?
[06:01] <glick> but i dont see any kill scripts
[06:02] <glick> all S scripts
[06:02] <fabbione> glick: they are no different
[06:02] <BlackCheese> Ubuntu does E and J scripts mostly and ubuntu is unfit so it doesnt runlevel it walklevels with I scripts. Here at Ubuntu we believe Jebus is the light.... We take all very seriously
[06:03] <imbrandon> ?
[06:03] <fabbione> BlackCheese: ???????
[06:03] <fabbione> glick: the only main difference is that we use rc2 by default
[06:03] <glick> fabbione, so how does it switch from level 4 to 3 for example
[06:03] <fabbione> glick: the same way as redhat does
[06:03] <glick> how does it stop services
[06:03] <fabbione> glick: same way
[06:03] <glick> fabbione, but i dont see K scripts
[06:03] <fabbione> note:
[06:03] <glick> only S scripts
[06:04] <fabbione> yeah let me write :)
[06:04] <fabbione> most of the K scripts are totally unnecessary
[06:04] <fabbione> they are only missing from rc0 and rc6
[06:04] <fabbione> because no matter what you do
[06:04] <fabbione> the system sends a kill to all processes
[06:04] <fabbione> and that's the same as using a K script
[06:05] <fabbione> the few apps that still require a K script will retain it
[06:05] <fabbione> the others have been removed
[06:05] <glick> fabbione, hah ok
[06:05] <glick> i see em
[06:06] <fabbione> one of the side effects is a faster reboot/shutdown
[06:06] <glick> ubuntu doesnt have a runlevel where it doesnt include X?
[06:06] <fabbione> less code to run that's going to die anyway
[06:06] <fabbione> glick: not as RH does
[06:07] <imbrandon> glick: not really ( other than single user mode , but its not the same )
[06:07] <glick> why not add such a runlevel?
[06:07] <imbrandon> if there isnt a need , why add it :)
[06:07] <fabbione> glick: google for it :)
[06:07] <fabbione> glick: there have been tons of discussions about it
[06:07] <glick> imbrandon, i don know there might be a need
[06:08] <glick> i guess thats what server edition is for though
[06:08] <glick> so i guess its not needed in the desktop distro
[06:08] <imbrandon> or you could simply tell gdm/kdm/xdm not to start :)
[06:08] <imbrandon> but exactly
[06:08] <glick> do i use the service command in ubuntu like in redhat?
[06:08] <fabbione> glick: really... google for it to find all possible reasons/objections/discussions
[06:09] <imbrandon> you'll also notice too coming from redhat that we done beleive in having services installed that arent used, like sshd etc thus the split between ssh-client and -server
[06:09] <imbrandon> but yea you have /etc/init.d/service stop|start|blah 
[06:10] <imbrandon> but as fabbione said there is tons of disscussions that can be found on good as to why its done this way
[06:10] <imbrandon> google*
[06:12] <pitti> good morning
[06:12] <imbrandon> moins pitti 
[06:13] <ajmitch> morning pitti 
[06:13] <pitti> hi imbrandon, hey ajmitch
[06:14] <imbrandon> anyone know the reason ( other than everyone is super busy ) we've been holding off on apache2.2 ?
[06:15] <Chipzz> fabbione: there's another difference
[06:15] <pitti> imbrandon: I filed a sync request yesterday
[06:16] <glick> heh ive used redhat so much
[06:16] <glick> im used to it now
[06:16] <Chipzz> fabbione: we start gdm from /etc/rc?.d/, while redhat starts gdm from init(tab)
[06:16] <glick> and i cant stand redhat!
[06:16] <fabbione> Chipzz: i am sure there are...
[06:16] <imbrandon> pitti: rock on, good i found out i needed it today on my edgy webserver :(
[06:16] <imbrandon> hopefully it wont be too much of a pita for me to backport
[06:16] <imbrandon> :)
[06:16] <Chipzz> so to stop gdm, on redhat you have to go to runlevel 3 (instead of 5), and on ubuntu you can do /etc/init.d/gdm stop
[06:18] <imbrandon> Chipzz: or just install broken drivers and wait for gdm to time out </sarcasim>
[06:18] <Chipzz> imbrandon: hehe :)
[06:18] <imbrandon> sadly i know that from experince
[06:18] <imbrandon> evil evil X :P
[06:20] <Chipzz> yea, me too
[06:24] <glick> hey in the next ubuntu release where compbiz an xgl will be the default, will there be easy options to not install them?
[06:24] <glick> i mean will it be a choice? like install 3d desktop yes or no?
[06:25] <pitti> glick: I truly hope so :)
[06:25] <somerville32> Me too
[06:25] <imbrandon> yes it should be a choice and it hasent been decided if its compiz or beryl and it most likely WONT be xgl, it will be AIGLX
[06:25] <pitti> glick: right now, the desktop-effects package allows you to easily enable it
[06:25] <somerville32> I have a 333mhz w/ 128mb of ram - 3d stuff would kill my box.
[06:25] <glick> i just dont want it forced upon me
[06:25] <imbrandon> somerville32: sounds like a good xubutu canidate :)
[06:25] <pitti> glick: if we enable it by default, the same switch should be available to turn it off
[06:25] <glick> im happy living in my 2d desktop world
[06:25] <somerville32> imbrandon, Thats what I'm running ;] 
[06:26] <glick> pitti, but it just seems like it should be off by default and enabled by a switch
[06:26] <pitti> glick: I feel with you, I tried out compiz yesterday and found it so utterly broken that I immediately returned
[06:26] <glick> especially if you have crappy vid hardware
[06:26] <twb> The equivalent of service(8) in Ubuntu is invoke-rc.d(8).
[06:26] <glick> i just dont want to see ubuntu become one of those annoying distros where you have to disable a bunch of stuff for it to be bearable
[06:26] <twb> For interactive use, it's better to use /etc/init.d/<service>
[06:27] <HrdwrBoB> glick: otoh, if it works, it's *amazing*
[06:27] <glick> i still use dapper on my desktop
[06:27] <twb> It's just chrome
[06:27] <ajmitch> HrdwrBoB: I don't find it that special
[06:27] <glick> HrdwrBoB, but its highly experimental software, im sure it has dozens of security holes in it
[06:28] <HrdwrBoB> glick: security holes in my window manager isn't going to ruin my day
[06:28] <imbrandon> dozens? wow they must have plugged some up /me stops
[06:28] <imbrandon> time for sleep yall, gnight
[06:29] <pitti> glick: I'm rather concerned about usability and hardware support here
[06:29] <glick> HrdwrBoB, its more then a window manager
[06:29] <glick> and it certainly can ruin your day
[06:29] <glick> well it can ruin my day cause i have important files on my pc
[06:29] <HrdwrBoB> well, it's unlikely to ruin my day, but it would be quite possible to ruin lots of peoples days 
[06:30] <HrdwrBoB> glick: attack vectors on your window manager  are very little
[06:30] <glick> HrdwrBoB, its not just a window manager
[06:30] <glick> it has kernel access to hardware
[06:30] <twb> Uh, surely the window manager has permission to exec and permission to talk to the x server.
[06:30] <imbrandon> aiglx does not compiz :)
[06:31] <imbrandon> anyhow any holes are not good holes
[06:31] <HrdwrBoB> imbrandon: absolutely
[06:31] <HrdwrBoB> but in order to own your WM, you'd have to run compromised code
[06:31] <HrdwrBoB> .. in which case all bets are off in any case
[06:31] <glick> Xserve and X.org have been around like 20 years, regular 2D and are still full of security holes
[06:32] <glick> i mean i know you cant get ANY software completley bug free
[06:32] <glick> but you can asomtotically approach an "acceptable" level
[06:32] <imbrandon> glick: you know aiglx is part of x.org right, you guys are mixing the X server and the WM and the composite manager
[06:32] <imbrandon> anyhow really really off
[06:33] <glick> imbrandon, yeah
[06:33] <glick> imbrandon, thats what im saying its not just a WM
[06:33] <twb> If it really worries you, don't run X.
[06:33] <twb> You can play dvds and look at pictures on the framebuffer.
[06:33] <glick> sure would be faster :)\
[06:34] <glick> but not as sexy
[06:34] <twb> Actually, framebuffer terminals are significantly slower than 2d-accelerated X servers running xterm.
[06:35] <twb> They also don't do antialiased fonts :-(
[06:53] <twb> So yeah, I fixed a bug in the udev package.  Anyone interested?
[06:54] <Hobbsee> twb: keybuk or someone probably is, when they're here.  would help if you gave the bug #
[06:54] <twb> I haven't filed a bug yet.
[06:55] <twb> The bug is actually introduced by feature patch that I'm waiting for Mithrandir to pull into the casper package.
[07:15] <keescook> hey fabbione, can you have a look at an mdadm patch I pulled together?  I ran into a race with initramfs+md.  #75681
[07:15] <fabbione> keescook: edgy or feisty?
[07:16] <keescook> fabbione: feisty.
[07:16] <pitti> hi keescook, still up?
[07:16] <keescook> basically, my sata drives come online after local-top/mdadm has already aborted
[07:16] <keescook> hiya pitti!  yeah, long evening.  :)
[07:16] <pitti> short night for me :)
[07:16] <fabbione> keescook: you have done a lot of work that has been already done and needs to be moved to udev-mdadm
[07:17] <fabbione> +  wait=$(sed -e 's/ /\n/g' < /etc/mdadm/mdadm.conf | grep ^devices= | cut -d= -f2- | sed -e 's/,/ /g')
[07:17] <fabbione> you have no guarantee that devices are listed in mdadm.conf
[07:17] <keescook> fabbione: yeah, i know.  :P
[07:17] <keescook> actually, that's a requirement for mdadm now (says the readme)
[07:18] <fabbione> keescook: hem no.. it's not
[07:18] <fabbione> ARRAY /dev/md0 level=raid5 num-devices=4 UUID=e4ac4774:c730d28b:0978c89e:2173da3d
[07:18] <fabbione> this won't match anything in your entry
[07:18] <fabbione> and stall
[07:18] <keescook> aaah, you mean the device= isn't a requirement... good point
[07:19] <fabbione> keescook: just wait for the spec to be implemented.. really
[07:19] <fabbione> keescook: i didn't spend time fixing mdadm in feisty..
[07:19] <keescook> the udev-md spec says it's implemented, so this led to my confusion.  :)
[07:19] <fabbione> see the big SRU for mdadm in edgy
[07:19] <fabbione> no it has been mistakely marked as implemented and reassigned to me
[07:19] <keescook> oh! hah.  okay.  :)
[07:19] <jdong> keescook: is it true that madwifi has some buffer overflow
[07:20] <keescook> jdong: yup.
[07:20] <jdong> keescook: exploitable to gain root?
[07:20] <jdong> keescook: lovely :)
[07:20] <jdong> but there is good news?
[07:20] <keescook> jdong: unsure if it's been proven to gain root, but it's a stack attack, so it's likely.
[07:20] <jdong> keescook: mmm :-/ not something I like to wager :D
[07:21] <keescook> fabbione: cool, I'll leave my patch in place on my machine for now.  Let me know when you want beta code tested.  :)
[07:21] <fabbione> keescook: i am blocked by Keybuk that needs to do a udev upload
[07:22] <fabbione> keescook: and i have plenty of raids to test, but yes.. i will let you know..
[07:22] <fabbione> one more test > *
[07:22] <keescook> :)
[07:25] <desrt> pitti; hello :)
[07:25] <pitti> hey desrt 
[07:25] <desrt> do you know when the new kernel for dapper will be out?
[07:26] <pitti> desrt: erm, the ones I released yesterday?
[07:26] <desrt> ((btw: having my security notifications signed by someone whose pgp key i have signed directly is cool))
[07:26] <pitti> heh
[07:26] <desrt> the firewall fix isn't in the dapper kernel
[07:26] <desrt> you mentioned that in your mail, i think
[07:27] <pitti> desrt: ah, right; there was some serious trouble with backporting that patch
[07:27] <pitti> desrt: we have a patch which is currently reviewed by upstream
[07:28] <pitti> desrt: so I hope we can get another update in January
[07:28] <desrt> !!
[07:28] <desrt> well, in any case,  idon't think the bug affects me
[07:29] <desrt> i guess if you have fragment reassembly in place then it doesn't matter
[07:31] <desrt> it sort of makes me consider upgrading to edgy, though
[07:35] <pitti> desrt: argh, I should have mentioned that it only affects IPv6
[07:36] <pitti> done
[07:40] <desrt> oh.  nice.
[07:41] <desrt> ipv6 is for suckas :)
[07:41] <fabbione> desrt: ipv6 is teh winnar.. you suck
[07:42] <fabbione> pitti: dude...
[07:42] <fabbione> usn-395-1
[07:42] <desrt> ya.  seriously.
[07:42] <fabbione> pitti: CVE-2006-5648 affects sparc too. the kernel is patched, but the USN needs to be updated
[07:43] <fabbione> pitti: 
[07:43] <fabbione>   * [SPARC64] : Fix futex_atomic_cmpxchg_inatomic implementation.
[07:43] <fabbione>     Upstream GIT-SHA: c7fed9d75074f7c243ec8ff2c55d04de2839a6f6
[07:43] <fabbione>     - Malone #68266
[07:43] <Ubugtu> Malone bug 68266 in linux-source-2.6.17 "unkillable cpu-eating zombie children left by glibc build" [Medium,Fix released]  http://launchpad.net/bugs/68266
[07:44] <desrt> that bug has, perhaps, the best summary ever
[07:44] <fabbione> desrt: luckly i didn't do the usual make -j 4096
[07:45] <desrt> holy crap.  i haven't signed martin at all.
[07:45] <desrt> !
[07:45] <desrt> travesty
[07:45] <fabbione> desrt: did i ever sign you?
[07:45] <desrt> yes
[07:45] <fabbione> desrt: i am pretty sure i did.. 
[07:45] <fabbione> ok
[07:45] <desrt> and i signed you and emailed the sigs
[07:45] <fabbione> yeps
[07:45] <desrt> but you couldn't open them or something
[07:45] <fabbione> yeah i think i did it
[07:45] <desrt> oh.  good :)
[07:46] <fabbione> what's your gpg uid?
[07:46] <desrt> afaa6ff6
[07:46] <fabbione> uid as in email
[07:46] <desrt> desrt@desrt.ca
[07:47] <desrt> lots of gdm flaws today
[07:47] <fabbione> hmmm
[07:48] <pitti> fabbione: ok, /me fixes wiki page
[07:49] <desrt> eep.  only one flaw.  just looked like lots from the volume of emails i got
[07:49] <fabbione> pitti: thanks
[07:49] <fabbione> desrt: it looks like i don't have them.. oh well
[07:49] <desrt> fabbione; i used scott's script.  at the time you said you were having difficulty opening them
[07:49] <desrt> fabbione; you could probably check in your received mail for them
[07:50] <desrt> (if you really care) :)
[07:50] <fabbione> desrt: no i am sure i don't have them in my inbox
[07:50] <pitti> fabbione: done, thanks
[07:50] <fabbione> desrt: i guess we will resign next time
[07:51] <desrt> fabbione; i'm sure i'll see you soon :)
[07:51] <desrt> any word on where the next one will be?
[07:51] <fabbione> desrt: and if not.. i wish you a good travel in the other life
[07:56] <desrt> pitti; on your laptop?
[07:57] <pitti> desrt: both amd64 desktop and ppc laptop
[07:57] <fabbione> looks good on sparc
[07:57] <desrt> hold it up to your ear
[07:57] <desrt> is it ticking anymore?
[07:57] <pitti> desktop is running now
[07:58] <pitti> argh, usb 2.0 broken
[07:58] <desrt> usb 2.0 was broken before you rebooted your desktop, dear :)
[08:03] <pitti> desrt: 'ticking'???
[08:03] <desrt> pitti; the new kernels are supposedly "tickless"
[08:03] <desrt> or, rather, circa 2.6.17-8 i heard "we'll be tickless by 2.6.20"
[08:04] <desrt> ie: the timer interrupt (HZ) no longer constantly runs
[08:04] <desrt> but, rather, is only scheduled when it needs to be
[08:04] <pitti> ah, I remember
[08:05] <desrt> not sure how you find out if you're tickless or not
[08:05] <desrt> (i doubt the trick with holding it up to your ear actually works)
[08:06] <jdong> desrt: pfft
[08:06] <jdong> desrt: doesn't fix C3/C4 buzzing on my laptop
[08:07] <jdong> desrt: tickless patches that is
[08:07] <desrt> well
[08:07] <desrt> that's because the entire userland is retarded
[08:07] <jdong> I hope that's why
[08:07] <desrt> come see my talk at linux.conf.au about how to fix it :)
[08:07] <jdong> :)
[08:07] <jdong> I see the .au and somehow think it won't happen :D
[08:07] <desrt> dude.  summer in january.
[08:07] <jdong> but i'll be awaiting the day I can send my alptop to C3
[08:24] <pitti> cjwatson_: may I nag you about the SRU bug 59946 again?
[08:24] <Ubugtu> Malone bug 59946 in gnome-system-tools "Admin tools require admin group membership" [High,In progress]  http://launchpad.net/bugs/59946
[08:38] <twb> Anybody know if usplash can be made to work over pxelinux?
[08:38] <twb> s/over/with/
[08:39] <fabbione> twb: what do you mean over pxelinux?
[08:39] <fabbione> usplash starts from initramfs
[08:40] <pitti> argh, why does gdb get more broken with every release recently?
[08:40] <twb> I think the underlying problem is that the framebuffer isn't being used.
[08:40] <fabbione> twb: pxelinux is just a minimal piece of code to download kernel and initramfs
[08:40] <twb> I just get a boot: prompt instead of the full gxfboot thing that you get when booting with isolinux.
[08:43] <fabbione> works fine here
[08:43] <twb> Hmm, maybe it's because I'm using CentOS4's pxelinux.0 instead of Ubuntu's
[08:43] <twb> (I'm stuck with CentOS on the server, against my will)
[08:44] <fabbione> you can still use pxelinux.0 from ubuntu
[08:44] <twb> That's what I'm about to do.
[08:44] <fabbione> anyway this is become #ubuntu stuff
[08:44] <twb> Sorry.
[08:50] <twb> fabbione: (moved to #ubuntu)
[08:52] <Zober> Is there an svn system out there that does not require installation?  For example, if i want to host a repository on my site, but its a shared host with no shell privilages.
[08:53] <pitti> Zober: setting up svn requires shell access TTBOMK
[08:53] <Zober> is there a knockoff of svn that run on say php/mysql?
[08:53] <Zober> or perl and mysql or something
[08:54] <pitti> Zober: however, bzr does not :) it can use sftp, rsync, or you can copy it with ftp, or whatever
[08:54] <Zober> nice!

[08:57] <desrt> sigh.
[08:57] <desrt> every time i read a get-women-involved-in-linux document i am depressed
[08:58] <desrt> i'm like "oo.  magic solution"
[08:58] <desrt> and then it's either the same-old, or worse
[08:58] <desrt> :/
[08:59] <dade`> don't go to bed
[08:59] <dade`> we have 2.6.20 \o/
[09:00] <dade`> desrt: have you tried it ?
[09:01] <Zober> pitti, have you ever set up bzr?
[09:01] <pitti> Zober: sure, I use nothing else :)
[09:01] <Zober> where is the server side portion of it?
[09:02] <Zober> in downloading the client
[09:02] <Zober> screenshots look something like tortoise
[09:02] <pitti> Zober: this is off-topic here, btw
[09:02] <pitti> Zober: there is no server-side
[09:02] <pitti> Zober: please read the tutorial on https://bazaar-vcs.org
[09:02] <Zober> thanks
[09:28] <pitti> Lathiat: I'm going to update dapper's and edgy's avahi now; did you see any regression with the current patch? (I didn't)
[09:29] <pitti> Lathiat: I know you wanted to actually test injecting bad netlink packets, but since it's such a serious regression, I'd rather make it work RSN
[09:31] <Mithrandir> so, what should we do about the missing update-inetd?  Fix the apps or add the dependency and wait until shit is fixed in Debian?
[09:38] <pitti> seb128: so, the pkg-create-dbgsym testsuite works for you on current feisty?
[09:38] <pitti> seb128: if you boot to 2.6.20, could you run it again and compare? I'd appreciate that
[09:38] <pitti> seb128: to see the comparision between i386 and amd64
[09:38] <seb128> let me try
[09:39] <seb128> I just need to build pkg-create-dbgsym ?
[09:39] <pitti> seb128: no, just apt-get source and ./testsuite
[09:39] <seb128> running
[09:41] <seb128> brb
[09:44] <pitti> wb seb128 
[09:44] <seb128> re pitti
[09:45] <seb128> pitti: "2.6.20" on my chinstrap user dir, that the testsuite on i386 with 2.6.20
[09:45] <pitti> seb128: did it succeed?
[09:45] <seb128> no
[09:45] <seb128> well, there is some PASS and some FAIL too
[09:46] <pitti> seb128: right, the failed ones are the gdb
[09:46] <seb128> compare with 2.6.17 at the same place
[09:46] <pitti> seb128: and it passed on 2.6.17
[09:46] <seb128> exact
[09:47] <pitti> seb128: ok, I wait until the gdb testsuite (and thus the package build) has finished here and test on amd64 again
[09:47] <pitti> seb128: fun, with our current feisty package, gdb failed *all* tests...
[09:47] <seb128> for some value of fun :p
[09:47] <seb128> I'm happy to be still running 2.6.17 :p
[09:49] <pitti> seb128: why doesn't .19 work for you? for me, it only breaks the nvidia driver resolution
[09:49] <seb128> my network card stop communicating after some time
[09:49] <seb128> and the only way to get network again is to reboot
[09:49] <pitti> hey dholbach 
[09:49] <seb128> some time being 30min to one hour usually
[09:50] <dholbach> good morning
[09:50] <dholbach> hey pitti, hey seb128
[09:51] <seb128> hi dholbach
[09:51] <somerville32> Good Morning! :)
[09:51] <dholbach> heya somerville32
[09:51] <seb128> hi somerville32 Keybuk
[09:51] <Keybuk> morning
[09:58] <fabbione> cjwatson_: i did test network-console and found only 3 minor issues. Do you have time to discuss them when you will be around?
[10:01] <pitti> seb128: \o/ my gdb loves me again
[10:02] <pitti> and so does apport again
[10:03] <seb128> how did you fix it?
[10:03] <pitti> seb128: I grabbed the patch to support the .gnu.hash ELF section from upstream CVS
[10:06] <pitti> seb128: ok, I uploaded the new gdb; it would be great if you could test it again on i386 once it's built
[10:06] <seb128> pitti: sure
[10:09] <fabbione> hmmmmmmmmmmm
[10:09] <fabbione> who broken samba upgrade? ...
[10:09] <fabbione> Mithrandir: don't you feel guilty today? :P
[10:11] <pitti> argh, vmware doesn't like 2.6.20, brb
[10:11] <fabbione> actually
[10:11] <fabbione> Mithrandir: never mind.. it's that update-inetd thingy
[10:13] <seb128> fabbione: https://launchpad.net/distros/ubuntu/+source/samba/+bug/73734 ?
[10:14] <Ubugtu> Malone bug 73734 in samba "update-inetd dependency missing on 3.0.22-1ubuntu4 (feisty)" [Unknown,Fix released]  
[10:14] <fabbione> seb128: yes... that one
[10:14] <seb128> there is a patch if you feel like sponsoring the upload :)
[10:14] <fabbione> seb128: that's why i removed Mithrandir from the list of suspicious people
[10:14] <fabbione> seb128: i think Mithrandir is working on a more general thing
[10:14] <seb128> ok
[10:21] <Mithrandir> fabbione: the general fix is "add the missing dependencies". :-P
[10:21] <Mithrandir> fabbione: the limit of my guilt would be "not testing the package prior to upload", but I just changed the build-deps, so. :-P
[10:22] <fabbione> Mithrandir: you still touched it last :P
[10:32] <doko> Mithrandir: are you able to requeue packages?
[10:32] <cjwatson_> 21:00 < twb> I notice the isolinux.cfg for Edgy includes a ramdisk_size kernel argument.   What does this do, and what are the consequences of changing the ramdisk without updating or removing this argument?
[10:32] <cjwatson> twb: I think ramdisk_size is actually unnecessary now; I removed it from feisty CDs a week or two back
[10:33] <cjwatson> twb: it was a hangover from when we used to use an initrd rather than an initramfs
[10:33] <Mithrandir> doko: yes
[10:33] <cjwatson> twb: gfxboot != usplash; I don't think pxelinux has been fully educated about gfxboot yet, so you'd need to do so. Assembly hacking ahoy
[10:33] <cjwatson> fabbione: network-console> sure
[10:34] <doko> Mithrandir: please requeue eclipse on ia64, maybe on another machines. looks like random failure to me
[10:35] <Mithrandir> doko: given-back
[10:36] <fabbione> cjwatson: ok.. so the 3 things i noticed are: network-console did not run automatically even if installed. from the partitioner i went back to the main menu and netcon entry was before (higher priority?) of choose mirror. when ssh into the system and selected to run the installer, i was in very low debconf priority. AFAICT we should move netcon after choose-mirror (otherwise on netinstall you don't have netcon installed when it's supposed 
[10:36] <fabbione> to run). Probably we need to increase it's priority to make it run by default when selected (assuming this isn't just a fallout from the previous issue) and last we should preserve the default debconf priority when ssh'ing into
[10:37] <fabbione> cjwatson: last problem is that i am not sure how to do any of the above....
[10:37] <fabbione> cjwatson: so i am seeking your god-alike 31337 sk1ll5 here
[10:38] <cjwatson> well, this is kind of awkward
[10:38] <cjwatson> network-console should be as early as possible after the network is up, to avoid having to use the serial console more than you have to; remember that there are situations where it's included in the initrd, and moving it after choose-mirror would be suboptimal for those
[10:39] <cjwatson> this is really http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288053
[10:39] <Ubugtu> Debian bug 288053 in network-console "network-console - Regression: is not correctly added in menu" [Important,Closed]  
[10:39] <fabbione> cjwatson: ok, than we have some kind of chicken-egg problem because if we need to download it from the mirror then choose-mirror is mandatory
[10:39] <cjwatson> or we could just include it in the initrd *shrug*
[10:40] <fabbione> i vote against initrd
[10:40] <fabbione> i'd rather ask one more question in console
[10:40] <fabbione> the real pain of console is the partitioner and the package installation
[10:40] <cjwatson> well, I don't approve, I'd rather fix that main-menu bug somehow
[10:41] <fabbione> dropping netcon in the initrd means pulling in sshd and ssl
[10:41] <fabbione> that would be a bloat IMHO
[10:42] <cjwatson> fixing the main-menu bug would be optimal and would avoid the need for either of these breakages
[10:42] <cjwatson> needs some care though
[10:42] <cjwatson> I don't understand why the priority would be any different
[10:42] <fabbione> i wouldn't know how to.. i did never fiddle with main-menu
[10:42] <cjwatson> network-console doesn't set it
[10:43] <fabbione> cjwatson: probably the drop of debconf priority is a fallback from me having to <go back> to main menu to select it
[10:44] <cjwatson> oh, probably. main-menu knows to restore that, but it probably doesn't get a chance in this case
[10:44] <cjwatson> I'm not concerned about that, then
[10:44] <fabbione> i have the feeling that 2 of these issues are just fallouts of netcon not being configured automatically... 
[10:45] <fabbione> well you understand what i mean
[10:45] <fabbione> i am not too concerned either.. i just would like to verify that sometimes
[10:47] <cjwatson> yes, the priority is just fallout
[10:50] <twb> cjwatson: thanks.
[10:52] <twb> Mithrandir: merged casper that works for me is available
[10:53] <fabbione> cjwatson: what would be your ideal solution in the short term that won't require casting black magic on main-menu?
[10:55] <cjwatson> fabbione: ENOENT
[10:55] <cjwatson> fabbione: fixing main-menu (or having time to investigate without being asked for workarounds) is my ideal solution
[10:55] <cjwatson> Scots I think
[10:56] <Mithrandir> looks like it
[10:56] <fabbione> cjwatson: ok.. i will let you quiet.. i didn't expect you to dig into this fast
[10:57] <cjwatson> fabbione: the reason that it's currently skipped is Debian bug #224633
[10:58] <twb> sco Scots Scoats leid; Lallans
[10:58] <twb> http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes
[10:58] <fabbione> cjwatson: feh yeah i remember that too
[11:06] <Mithrandir> twb: coolie, what's the URL?
[11:07] <twb> http://twb.ath.cx/~twb/scratch/casper/
[11:08] <twb> Mithrandir: I had to make a minor change to udev, too, to make it load the network drivers before trying to nfsmount.
[11:08] <twb> http://twb.ath.cx/~twb/scratch/udev/
[11:08] <twb> ...that change is only needed if you are netbooting, however.  You can boot from a CD-ROM without it.
[11:10] <Mithrandir> twb: I'll take a look at it; thanks a lot!
[11:12] <twb> No no, thank you!  Once it gets into feisty, I can just install it via apt-get instead of having to ship the .debs around myself.
[11:22] <fabbione> Keybuk: davem is working on the kernel to export that sysfs attrib we did talk about.
[11:25] <Keybuk> sweet
[11:28] <twb> Keybuk: I found a typo in the udev bzr branch.
[11:32] <Keybuk> twb: oh?
[11:32] <twb> Keybuk: yeah, in debian/udev.docs
[11:36] <Keybuk> twb: what's the typo?
[11:37] <twb> -doc/writing_udev_rules/index.html
[11:37] <twb> +docs/writing_udev_rules/index.html
[11:38] <Keybuk> twb: where's that referenced?
[11:39] <Keybuk> it is docs here
[11:39] <twb> http://bazaar.launchpad.net/~ubuntu-core-dev/udev/ubuntu/
[11:40] <twb> Admittedly, I may be branching the wrong branch.
[11:41] <Mithrandir> there, main fixed wrt update-inetd mess.
[11:41] <StevenK> Keybuk: What do you think about putting a "Last updated: <date>" on the MoM pages?
[11:44] <Keybuk> StevenK: *shrug* just look at the date in the header, or on the listing?
[11:44] <Keybuk> twb: oh, that branch has never been used
[11:44] <Keybuk> udev isn't in bzr
[11:45] <twb> Why are there branches for it, then?
[11:45] <StevenK> Keybuk: On the listing.
[11:45] <StevenK> Keybuk: Just to give a clue that MoM isn't updating, or so.
[11:48] <Keybuk> twb: because I attempted to put it into bzr, and gave up
[11:49] <twb> Bummer.
[11:49] <Keybuk> and there's no way of deleting branches in LP
[11:51] <twb> Keybuk: so if I want a change to the initramfs stuff that udev installs for casper, what's the best way to go about it?
[12:00] <Keybuk> twb: send me a patch
[12:00] <Keybuk> apt-get source udev to get the current code
[12:00] <twb> OK.
[12:02] <twb> Basically the file that ends up in casper-premount/udev needs an extra
[12:02] <twb>  /sbin/udevtrigger -s -Bpci -Iclass=0x02*
[12:02] <Keybuk> ?
[12:02] <Keybuk> that file doesn't exist in feisty
[12:03] <twb> Hmm.
[12:03] <twb> I'm working with edgy atm
[12:03] <Keybuk> (and why do you need network cards to mount the casper root fs?)
[12:03] <twb> Keybuk: because the casper rofs is on an NFS export, not a CD.
[12:10] <Keybuk> I see
[12:10] <Keybuk> you'll have better lucky with feity, as that just triggers everything
[12:10] <twb> If casper-premount/udev is not in feisty, what has replaced it?
[12:11] <Keybuk> nothing
[12:11] <Keybuk> the init-premount script (that starts udevd) now just calls udevtrigger on everything
[12:11] <Keybuk> that only takes 0.03s on my laptop
[12:11] <twb> I see.
[12:11] <twb> Why didn't it do that in Edgy?
[12:12] <Keybuk> because we needed to settle the events in edgy
[12:12] <Keybuk> (ie. wait for them to actually finish)
[12:12] <Keybuk> feisty it's ok for them not to be finished, any script should expect the device it wants to not be ready yet
[12:12] <Keybuk> e.g. mountroot spins
[12:12] <twb> Does it spin asynchronously?
[12:13] <twb> Perhaps that question doesn't make sense.
[12:15] <cjwatson> fabbione: untested main-menu patch heading towards http://bugs.debian.org/288053
[12:15] <twb> When does feisty release?
[12:15] <Keybuk> April 19th
[12:17] <ogra> you should ask "when is feistys feature freeze ?" rather ;)
[12:21] <fabbione> cjwatson: ok..
[12:43] <fabbione> cjwatson: got the patch.. i will try to build an installer either later today or tomorrow to test it.
[12:43] <cjwatson> ok
[12:44] <fabbione> bah screw that.. 
[12:57] <Lathiat> pitti: i havent seen any problems
[12:57] <Lathiat> pitti: so if youd like should be ok
[12:58] <pitti> Lathiat: great, thanks; /me releases
[01:04] <fabbione> cjwatson: booting the image now...
[01:17] <fabbione> cjwatson: nope.. didn't work...
[01:17] <fabbione> bahhhh
[01:17] <fabbione> nevermind
[01:17] <fabbione> scratch that
[01:29] <fabbione> cjwatson: I LOVE YOU..
[01:29] <fabbione> that patch seems to work just fine'
[01:42] <pitti> fabbione: yay
[01:43] <fabbione> pitti: we still need cjwatson supermagic power for main-menu fix
[01:43] <fabbione> otherwise it works
[01:43] <Mithrandir> fabbione: now we just need tftp over ssl.
[01:43] <fabbione>    | To continue the installation, please use an SSH client to connect to  |    
[01:43] <fabbione>    | the IP address 192.168.1.5 and log in as the "installer" user.        |    
[01:43] <fabbione> Mithrandir: sickness :P
[01:44] <ogra> openvpn ?
[01:44] <Mithrandir> ogra: do you know of any firmwares that support openvpn?
[01:44] <ogra> Mithrandir, firmware ? didnt you talk about tftp ?
[01:45] <Mithrandir> ogra: yes, firmwares often support tftp for you know, netbooting. :-P
[01:45] <fabbione> ogra: patches to OBP are welcome :P
[01:45] <ogra> pfft ... that use for tftp is totally overrated :P
[01:46] <ogra> we were experimenting with openvpn initramfs inbtegration for ltsp ... but indeed thats after tftp :=)
[01:47] <fabbione> ogra: dude.. you start to scare me now....
[01:48] <ogra> fabbione, why ? whats wrong with wrapping nfs into a vpn tunnel to make it more secure ? :)
[01:48] <fabbione> ogra: nothing wrong.. but at that point you might as well send the entire installation in the initramfs :)
[01:49] <ogra> haha
[01:49] <ogra> there is a guy who does that ... as an alternative to ltsp ...
[01:49] <ogra> its pretty ugly, but seems to work
[01:49] <Mithrandir> ogra: it's only ever-so-slightly stab-yourself-in-the-eye, but apart from that, it's nice and lovely.
[01:50] <dholbach> heno: you're not in #ubuntu-bugs! :-)
[01:50] <pitti> doko: did you already do anything with till's new hplip package?
[01:50] <dholbach> heno: how's it going?
[01:50] <doko> pitti: no, not yet
[01:50] <fabbione> ogra: what's wrong with that? you can get almost full OS with less than 40Mb of compressed initramfs
[01:50] <fabbione> ok..
[01:50] <fabbione> time to stop
[01:50] <ogra> fabbione, right ... 
[01:50] <fabbione> cya later at the meeting
[01:50] <pitti> doko: ok, since AFAIR you cannot test it either any more, I just eyeball and upload, ok?
[01:51] <doko> pitti: ok with me
[01:51] <pitti> doko: argh, I wish he would put source.changes there, not i386.changes
[01:51] <heno> dholbach: yeah I don't auto register to many channels, was just sitting in on the LP meeting as distro rep, will report later
[01:52] <dholbach> heno: ah nice
[01:52] <fernando> moin all
[01:56] <neutrinomass> mjg59: (I was redirected to you ) On what basis are acpi issues assigned to the kernel vs. acpi-support ?
[02:01] <dholbach> ogra: there's a new dia release
[02:02] <ogra> dholbach, thanks
[02:02] <dholbach> de rien
[02:04] <mjg59> neutrinomass: If it's a bug in the kernel, it goes against the kernel. If it's a bug in the shell scripts, it goes against acpi-support.
[02:04] <mjg59> Which means that it should pretty much always be against the kernel
[02:05] <neutrinomass> mjg59: Ok, thanks 
[02:06] <seb128> mjg59: hi
[02:08] <seb128> mjg59: sorry to ping you again about the new compiz, I just want to get that moving and in shape before then people try to replace it by beryl
[02:08] <seb128> mjg59: if you don't have time to work on the update I can do it, just let me know
[02:09] <mjg59> Ok. Feel free to do so - I'm busier than expected right now
[02:10] <seb128> mjg59: ok, I'll just do the update to the new version for now, we can discuss package split and other changes later
[02:11] <mjg59> Ok
[02:32] <ogra> dholbach, hmm, that dia release is called 0.96-pre1 ... not sure we want that ...
[02:38] <seb128> ogra: why not?
[02:38] <ogra> we never used the -pre versions ...
[02:39] <seb128> well, depends if they will have 0.96 before feisty
[02:40] <ogra> they are not followint the gnome schedule, do they ? 
[02:40] <ogra> *following
[02:40] <seb128> no
[03:04] <cjwatson> fabbione: woo, nifty. rock on untested patches
[03:11] <Lathiat> pitti: your goign to love me
[03:17] <dholbach> ogra: it's still a while until uvf :)
[03:17] <ogra> hmm, it ftbfs'es anyway with a tom of compiler errors
[03:17] <ogra> *ton
[03:18] <dholbach> nice :)
[03:36] <bddebian> Heya
[03:43] <salgado> I assume dpkg-buildpackage -nc is the fastest way to rebuild a package after I did some changes to it, is that right?
[03:44] <cjwatson> pitti: reading the g-s-t bug now
[03:45] <cjwatson> pitti: so this is basically just reverting the auth mechanism to dapper?
[03:45] <pitti> cjwatson: right
[03:45] <cjwatson> pitti: did you grep for anything else that does the same sort of thing done by time-tool?
[03:45] <pitti> cjwatson: plus reintroducing the gksudo calls from various applets
[03:46] <pitti> cjwatson: those were the fixes we made in dapper; I didn't grep the archive for more, just discussed that with seb128 
[03:46] <pitti> and I went through the menus to find more, but didn't
[03:47] <pitti> cjwatson: oh, the time-admin patch is not 'reverting to dapper', it's a new patch
[03:47] <pitti> cjwatson: since dapper's time-admin didn't yet try to talk to the session dbus
[03:47] <pitti> cjwatson: the patch is in feisty for a while
[03:47] <cjwatson> pitti: ok, I'm happy with the general approach; could you upload that lot?
[03:47] <pitti> cjwatson: sure, thanks
[03:48] <cjwatson> I'd like to be able to use Breaks for this, but I suspect that is not really safe for edgy-{proposed,updates} since upgrades from dapper will use that
[03:49] <pitti> right, the newer s-t-b breaks the older g-s-t
[03:49] <cjwatson> pitti: in edgy, doesn't it have to be gksudo rather than gksu? I thought the sudo-mode stuff was new in feisty
[03:50] <pitti> hmm, AFAIR I did test it in edgy, but I'll do it again just to be 100% sure
[03:50] <pitti> cjwatson: but from what I can see it was in dapper
[03:50] <pitti> gksu (1.3.7-0ubuntu7) dapper; urgency=low
[03:50] <pitti>   * debian/patches/02_ubuntu_gksuexec.patch:
[03:50] <pitti>     - removed, no longer needed because we can always use gksu and
[03:50] <pitti>       it will use a gconf key to determine what backend (su, sudo) to use
[03:50] <cjwatson> hmm, ok
[03:51] <cjwatson> maybe I'm thinking of when corresponding changes were introduced in Debian
[03:51] <seb128> mjg59: in fact that compiz upgrade is not that easy that I though since there is no .diff.gz but everything to the tarball. Is there any distro change we should keep? If that's the case I'll let you do it rather than dropping changes because I don't know about them
[03:52] <cjwatson> pitti: your gnome-applets change has a memory leak: you need to (a) free application and gksu in the early return since one of them might be non-null (b) free gksu at the end
[03:54] <pitti> cjwatson: oh, good catch; I'll fix that
[03:54] <cjwatson> pitti: would it be a good idea to drop to SUDO_GID as well as (before) dropping to SUDO_UID?
[03:55] <cjwatson> I know that ubiquity does that when poking gnome-screensaver
[03:55] <pitti> cjwatson: it's not necessary for connecting to the session dbus
[03:55] <pitti> cjwatson: my initial patch had that, but I removed it since I didn't see a benefit
[03:55] <cjwatson> ok, I guess it's not a big deal
[03:55] <pitti> and I prefered a smaller patch
[04:02] <cjwatson> all the diffs are fine with the exception of the gnome-applets one
[04:02] <pitti> cjwatson: updated gnome-panel is building
[04:02] <pitti> erm, -applets
[04:02] <cjwatson> can we maybe add a Conflicts or something in s-t-b?
[04:03] <cjwatson> if it breaks the old g-s-t, then we could end up in a situation where users can't run any administrative tools ...
[04:03] <cjwatson> well, they could run synaptic and update-manager I suppose, but still
[04:03] <cjwatson> would need to be on g-s-t plus the other binaries you changed
[04:03] <pitti> cjwatson: if that wouln't disrupt apt, I'm fine with that
[04:04] <cjwatson> well, it's no worse than any of the other Conflicts << in the archive
[04:04] <pitti> cjwatson: the other changes are not really that important IMHO, they are just convenience shortcuts
[04:04] <cjwatson> ok, then just on g-s-t
[04:04] <pitti> cjwatson: ok, could you please rejest the s-t-b upload?
[04:05] <cjwatson> done
[04:05] <pitti> Conflicts: liboobs-1-1 (<< 0.5), gnome-system-tools (<< 2.15.5-0ubuntu3~prop1)
[04:05] <pitti> (the liboobs one was there before)
[04:05] <cjwatson> yep
[04:06] <cjwatson> does the new g-s-t also break the old s-t-b?
[04:06] <cjwatson> I guess not
[04:06] <pitti> cjwatson: no, that way works
[04:06] <cjwatson> well, it won't be able to talk to the user's session bus
[04:06] <pitti> cjwatson: that's fine, since the session bus fix is in g-s-t itself
[04:06] <pitti> not in s-t-b
[04:07] <pitti> i. e. the new gst is fully operational with the old s-t-b
[04:07] <cjwatson> right, ok, all the other dbus communication is on the system bus?
[04:07] <pitti> right
[04:07] <pitti> I verified that with a grep
[04:07] <pitti> and, of course, by testing all the apps
[04:07] <cjwatson> ok
[04:12] <pitti> cjwatson: ok, new g-applets work fine with new patch, also tested with mv /usr/bin/gksu{,.old}
[04:13] <pitti> cjwatson: new patch attached, I marked the old one as [obsolete] 
[04:16] <pitti> cjwatson: g_free(NULL) is safe, thus this works
[04:18] <cjwatson> pitti: right, my thought too
[04:22] <ogra> ogra@edubuntu:~/packages/edsadmin-1.0$ dpkg -S /var/lib/python-support/python2.5/gtk-2.0/gobject/_gobject.so
[04:22] <ogra> dpkg: /var/lib/python-support/python2.5/gtk-2.0/gobject/_gobject.so not found.
[04:22] <ogra> ????
[04:22] <ogra> seb128, ^^^ any hint ?
[04:23] <seb128> ogra: 
[04:23] <seb128> $ dlocate gobject.so
[04:23] <seb128> python-gobject: /usr/lib/python-support/python-gobject/python2.5/gtk-2.0/gobject/_gobject.so
[04:23] <seb128> python-gobjec
[04:24] <seb128> grumpf
[04:24] <seb128> python-gobject: /usr/lib/python-support/python-gobject/python2.5/gtk-2.0/gobject/_gobject.so
[04:24] <seb128> python-gobject: /usr/lib/python-support/python-gobject/python2.4/gtk-2.0/gobject/_gobject.so
[04:24] <seb128> without _ :)
[04:24] <ogra> ah
[04:24] <seb128> ups
[04:24] <seb128> yeah, it's available correctly for me
[04:24] <cjwatson> moved to /usr
[04:24] <ogra> oh
[04:24] <ogra> right, i didnt even see that
[04:25] <ogra> anyway, this package build deps on python-gtk2 ... isnt that a metapackage that should pull in python-gobject ?
[04:25] <ogra> or do i need to explicitly list all pygtk bindings nowadays ?
[04:25] <pitti> cjwatson: fine to upload gnome-applets?
[04:26] <fabbione> cjwatson: well dude.. you rock.. we know that...
[04:27] <seb128> ogra: ?
[04:27] <pitti> seb128: ah, your g-s-t upload to edgy-updates beat mine
[04:27] <seb128> ogra: python-gtk2 Depends on it
[04:27] <cjwatson> pitti: yeah
[04:27] <ogra> seb128, i have a package that build-deps on python-gtk2, configure of this package runs "import gobject" to check for pygtk availability
[04:28] <ogra> apparently it fails, even though the build dep is there
[04:28] <seb128> ogra: weird, what is the package? something I can try from a pbuilder?
[04:29] <ogra> its edsadmin, let me look up the repo url
[04:29] <ogra> http://mrroach.okmaybe.com/software/edsadmin/debian/
[04:30] <cjwatson> pitti: edgy-updates language-packs belatedly accepted
[04:31] <cjwatson> pitti: except for language-pack-af, which for some reason soyuz isn't letting me accept
[04:32] <pitti> cjwatson: g-s-t and friends all uploaded, I got accepted mails
[04:32] <pitti> cjwatson: is there anything special about -af?
[04:33] <cjwatson> I think it was my fault - there may have been some weirdness during queue processing that led to a duplicate item in unapproved
[04:33] <cjwatson> it's in the accepted queue as well, so I've just rejected it
[04:36] <Keybuk> cjwatson: there's a pesky soyuz bug
[04:37] <Keybuk> I've ended up with things in multiple queues simultaneously when doing syncs
[04:38] <ogra> woah ... gnome-screensaver is evil ...
[04:39] <Treenaks> ogra: it is?
[04:39] <ogra> yeah, 2.17.3 just kills my session if i lauch the settings tool
[04:39] <Treenaks> ogra: cool
[04:41] <ogra> intrestingly that happens wit the 3d bubbles hack selected ... which is unlike the name suggests a 2d screensaver
[04:42] <ogra> damned, who had this crappy idea to translate all the hacks in the g-s-s UI ...
[04:43] <Treenaks> ogra: your employer? :P
[04:51] <dholbach> snu u u  u
[04:52] <radix> man that is not a thing that should be possible
[04:52] <Spads> haha
[04:52] <Spads> that is some fantastic abuse of unicode
[04:53] <Spads> although gnome-terminal doesn't handle the overwrite control stuff very well
[04:53] <dholbach> xchat-gnome neither
[04:53] <Spads> perhaps that ought to go on the agenda :)
[04:55] <ogra> hmm, my i is broken if its upside down
[04:57] <Spads> ogra: he was using U+0131  LATIN SMALL LETTER DOTLESS I and U+0323   COMBINING DOT BELOW
[04:57] <radix> yeah, I just figured that out with python :P
[04:57] <radix> isn't there a LATIN SMALL LETTER TURNED I? :)
[04:58] <Spads> ogra: and gnome-terminal doesn't seem to do combining characters very well
[04:58] <ogra> yeah
[04:58] <Spads> a ought to just look like 
[04:58] <radix> gedit messes up the i + combined dot
[04:58] <radix> as well
[04:58] <Spads> there are a lot of problems with even attempting to support fixed-width unicode
[04:59] <Spads> so I'm not surprised
[04:59] <seb128> ogra: 
[04:59] <seb128> # grep Build-Depends edsadmin-1.0/debian/control 
[04:59] <seb128> Build-Depends: debhelper (>= 4.0.0)
[05:00] <ogra> seb128, so sorry ... 
[05:00] <psusi> pitti: ping
[05:00] <seb128> ogra: np
[05:00] <pitti> psusi: in a meeting, pong
[05:01] <seb128> ogra: happens to everybody no worry ;)
[05:01] <psusi> pitti: ok.... just wanted to let you know in case you had not yet noticed, I updated bug #60894 with a debdiff and assigned it to you since you were the last person to update the reiserfsprogs package
[05:01] <Ubugtu> Malone bug 60894 in reiserfsprogs "mkfs.reiserfs creates an unmountable file system" [Unknown,Confirmed]  http://launchpad.net/bugs/60894
[05:02] <pitti> psusi: ah, fine
[05:02] <psusi> pitti: someone else could upload it I'm sure, but I figured you might want to since you touched the package last
[05:02] <Chipzz> anyone seen this? http://parker1.co.uk/satanic/

[05:03] <pitti> psusi: I don't have a particular affection for the package, but if it just comes down to sponsoring, that's fine for me
[05:03] <psusi> pitti: if you think you will get to it soon great, otherwise if you don't care I can ask for someone else to sponsor
[05:03] <pitti> psusi: I set it to 'in progress' to catch my attention
[05:03] <pitti> psusi: but it might take until January
[05:04] <pitti> psusi: if you find someone who has time for it now, go ahead
[05:04] <psusi> lol... ok... I'll try to find another sponsor to upload ;)
[05:04] <psusi> so... anyone else have time to upload a very simple patch correcting the man page of mkreiserfs? ;)
[05:05] <pitti> psusi: oh, just the manpage? consider it done then
[05:05] <pitti> psusi: I thought it was something that requires much brainpower to check
[05:05] <psusi> pitti: hehe, ok... yea... I just fixed the man page to note that the kernel does NOT support block sizes other than 4096 bytes
[05:05] <pitti> psusi: ok, will upload in some minutes
[05:06] <psusi> cool
[05:06] <psusi> I also emailed the debdiff to the debian bts
[05:08] <psusi> pitti: well I replied to your email about the local file mount in gnome, but it's currently waiting for moderator approval... anyhow... why do we no longer use pmount?  don't we want devices that are either flagged as user or not in fstab at all to be mountable by non admins?
[05:10] <pitti> psusi: we do, but the hal backend + gnome-mount do that now
[05:11] <psusi> pitti: oh, it sounded like you were saying that it now required sudo to do the mount
[05:11] <pitti> psusi: no, only for fixed hard disk partitions; that didn't work at all before
[05:12] <psusi> yea, that's what I'm talking about... if you have a fixed partition that is marked as user mountable, you shouldn't need sudo to mount it
[05:12] <pitti> psusi: ah, right, that's a special case
[05:13] <psusi> and I'm not entirely sure I agree with non admins not being able to mount fixed partitions that don't appear in fstab at all
[05:13] <pitti> I'm paranoid about that
[05:13] <pitti> other partitions == other Unix systems, windows systems, etc.
[05:13] <psusi> if it is really a fixed disk, then it should have an entry in fstab
[05:13] <psusi> and if the admin doesn't want users to mount it, it should say noauto nouser
[05:14] <pitti> but admin has super-powers, it's not an 'user'
[05:14] <psusi> I'm talking about a non admin user.... unless the admin set fstab to say nouser noauto, then the non admin user should be able to moutn it I think
[05:15] <pitti> no, that should be an opt-in, not an opt-out
[05:15] <pitti> and the 'user' flag is not relevant here anyway
[05:15] <psusi> how isn't it?  it means that non admin users are allowed to mount/unmount it
[05:16] <pitti> psusi: right, but this spec is entirely about providing access to devices for admins through the GUI :) (devices normal users don't have access to)
[05:16] <psusi> pitti: right... but non admin users should also be able to mount partitions shown in fstab as user... and I think partitions not found in fstab at all.
[05:17] <pitti> psusi: I agree to the first one; can you please file a bug about it?
[05:17] <psusi> that's how pmount behaved before and I agreed with it
[05:17] <pitti> (I'm not sure whether it works, didn't test it)
[05:17] <pitti> pmount didn't mount fixed partitions which weren't in fstab
[05:17] <psusi> ok.... I'll test it to make sure if it works or not first
[05:17] <pitti> great, thanks
[05:17] <psusi> yes, it did... it's just that g-v-m did not try to call pmount on fixed partitions
[05:18] <pitti> noauto,user might already be handled by g-v-m
[05:18] <psusi> pmount's rule was if it isn't in fstab, go ahead and let users mount it... that's what it was created for afaik
[05:18] <pitti> psusi: it didn't; at least it's not supposed to, if that works on your hardware, I'll issue an USN for that :)
[05:18] <pitti> psusi: ... *and* if the device is removable/hotpluggable
[05:19] <psusi> hrm... I thought it was g-v-m that checked that?
[05:19] <pitti> psusi: that would be pretty pointless
[05:19] <psusi> I could have sworn I tried manually using pmount on disk partitions and it worked as a non admin if the partition was not in fstab
[05:19] <pitti> since it wouldn't be a security policy any more
[05:19] <pitti> psusi: if that worked, please file a critical bug and assign it to me
[05:20] <psusi> the security policy is to honor fstab, but if there is no fstab entry, default to allowing non admins to mount it
[05:20] <psusi> that is why pmount was created as I understand it
[05:20] <pitti> psusi: no, pmount was created to mount removable devices
[05:20] <pitti> I'm the original designer and sole upstream :)
[05:20] <psusi> right, but that is just a specific case of "no fstab entry?  let user mount it"
[05:20] <psusi> ahhh
[05:20] <pitti> psusi: right, 'no fstab entry && removable'
[05:21] <pitti> (&& a couple of other conditions)
[05:21] <psusi> I see....
[05:21] <pitti> hey sbalneav 
[05:21] <psusi> so why treat non removable disks differently though I guess is my question?
[05:21] <sbalneav> sorry, quick logout-n-in needed
[05:22] <psusi> especially since the removable or not information is not 100% accurate ;)
[05:22] <pitti> psusi: you can't trust removable hard disks anyway
[05:22] <pitti> psusi: right, not 100%, but it errs on the side of caution
[05:22] <pitti> psusi: but at least in certain environments people do trust their internal hard disks
[05:22] <psusi> what harm could be done by allowing users to mount non removable disks?
[05:23] <psusi> ( that don't have an fstab entry )
[05:23] <pitti> psusi: modifying other OS installs, spying out passwords, breaking hibernation images from Windows, accessing other user's files, etc.
[05:23] <psusi> pitti: isn't it the responsibility of the admin to set permissions within those filesystems, and fstab itself, appropriately?
[05:24] <pitti> psusi: permisssions within that file system are fairly moot if you allow a user to access it...
[05:24] <pitti> noone guarantees that uids match, let alone that the other fs even has uids
[05:25] <pitti> psusi: oh, btw, reiserfsprogs uploaded
[05:25] <psusi> pitti: true.. but that's why we have fstab; so the admin can set it to not be mounted... 
[05:25] <psusi> cool
[05:25] <psusi> one bug down... 9 million to go ;)
[05:26] <pitti> psusi: so the admin can as well configure it to allow users to mount it (that's what you can do in theinstaller)
[05:27] <psusi> true.... if it really is a permanent fixed disk....
[05:29] <psusi> and one of these days I need to go through and slap around ext2/3/reiser/etc and make them respect the uid/gid/umask mount options
[05:29] <psusi> at least I got udf to do so
[05:30] <psusi> but reiser might make more sense on a large removable disk... but you probably don't want to rely on the ids on the filesystem as they may differ between multiple systems that you plug the disk into
[05:30] <pitti> psusi: uid= makes sense for udf (but already supports it)
[05:30] <pitti> psusi: I have my doubts for real unix file systems like extN and reiser
[05:31] <cjwatson> ogra: 
[05:31] <cjwatson>         Packages must not modify their own or other packages conffiles
[05:31] <cjwatson>         programmatically.
[05:31] <psusi> pitti: I had to patch it a few months ago because it would not honor uid= properly... it used it as a default if the id on disk was -1, but ignored it if there was a non -1 id on disk
[05:31] <cjwatson> ogra: what in particular was vagrant referring to?
[05:31] <cjwatson>         Packages must not modify other packages' configuration files
[05:31] <cjwatson>         except by an agreed upon APIs (eg, a /usr/sbin/update-foo command).
[05:31] <cjwatson> there's that
[05:31] <cjwatson> agreeing an API would make sense, though, and shouldn't block your work?
[05:31] <ogra> cjwatson, gimme a sec, i'll look it up in the archive
[05:31] <cjwatson> it's just a little more effort
[05:31] <psusi> pitti: the other filesystems shuold respect it as well since you can be mounting a filesystem that belongs to another instal or os with different uids
[05:31] <psusi> pitti: or used on a shared removable disk ;)
[05:32] <ogra> cjwatson, http://lists.alioth.debian.org/pipermail/pkg-ltsp-devel/2006-December/000537.html
[05:32] <pitti> psusi: I have a bad feeling about that, though; if you don't want permissions on such devices, then use udf or vfat, not an unix fs
[05:32] <pitti> otherwise the semantics of uid= would just be to turn ext2/reiserfs etc. into something like vfat
[05:32] <cjwatson> mdz: in practice RMs decide what counts as a serious bug, which is pretty close to deciding on policy. It's a very old RM vs. policy maintainer dispute ...
[05:32] <ogra> mdz, RM's apparently decide what NEW packages are allowed to get in right before the freeze
[05:33] <ogra> and it seems vagrant was quite late with the request for ltspfs
[05:33] <mdz> cjwatson: I think there's a clear line between interpreting policy and setting new policy
[05:33] <psusi> pitti: vfat sucks though due to poor space use and such... and udf has shortcomings as well.... and that still doesn't accoun for the case of mounting a hard disk partition that belongs to another os
[05:33] <Mithrandir> cjwatson: that bit also comes from policy, IIRC.
[05:33] <mdz> this is clearly the latter, and it isn't done well
[05:33] <Mithrandir> (the "not change other package's configuration files")
[05:33] <cjwatson> actually, it seems pretty sensible to me
[05:33] <cjwatson> "don't screw around with configuration files when you can't guarantee that their format won't change on you"
[05:34] <mdz> cjwatson: that's not what it said
[05:34] <mdz> it said "other packages' configuration files"
[05:34] <mdz> and configuration files which aren't conffiles often don't have a clear owner
[05:34] <cjwatson> mdz: also, it looks like an interpretation of policy 10.7.4 to me
[05:34] <mdz> like /etc/modules
[05:34] <cjwatson> "sharing configuration files"
[05:34] <cjwatson> If it is desirable for two or more related packages to share a configuration
[05:34] <ogra> well
[05:34] <cjwatson> file and for all of the related packages to be able to modify that
[05:34] <cjwatson> configuration file, then the following should be done:
[05:34] <cjwatson> One of the related packages (the "owning" package) will manage the
[05:34] <cjwatson> configuration file with maintainer scripts as described in the previous
[05:34] <ogra>  /etc/modules isnt owned by *anything* 
[05:34] <cjwatson> section.
[05:35] <cjwatson> The owning package should also provide a program that the other packages may
[05:35] <cjwatson> use to modify the configuration file.
[05:35] <Mithrandir> ogra: it's probably owned by base-files?
[05:35] <cjwatson> /etc/modules is a difficult case, but there are many easy cases where the above does make sense
[05:35] <ogra> Mithrandir, so created == owned ?
[05:35] <Mithrandir> ogra: not necessarily.
[05:36] <ogra> right
[05:36] <pitti> ogra: it's mainly a matter of defining an owned package; the package which exposes the interface gets to be the owner, I'd say
[05:36] <psusi> pitti: also udf wasn't usable before my patch because pmount would give uid= and the user would create files, then when it was unmounted, the kernel actually wrote uid=0 to the disk... so when you remoutned it, the file that had been yours was now root's
[05:36] <pitti> ogra: simple then: coreutils is the owner, and the interface is 'cat' :-P
[05:36] <cjwatson> ogra: (in particular the installer creates certain configuration files, but can't own them)
[05:36] <ogra> right
[05:37] <cjwatson> I think it's OK for the API to be "it's a text file, one module per line, feel free to change it" as long as the owning package documents that
[05:37] <ogra> i think /etc/modules is a very grey area here ...
[05:37] <cjwatson> it's just that that's not OK for some files people like to modify ...
[05:37] <ogra> right
[05:37] <cjwatson> sshd_config is a nice case - the key names keep changing
[05:37] <pitti> cjwatson: oh, that's certainly a conffile?
[05:38] <pitti> oh, it's not
[05:38] <cjwatson> nope
[05:38] <cjwatson> its contents used to vary based on debconf questions - they don't any more, but it's too hard to retrofit conffile-ness
[05:38] <pitti> cjwatson: if the key names keep changing, how do you manage upgrades? is upstream friendly enough to read older versions (and key names)?
[05:39] <cjwatson> no, openssh-server.postinst gets to fiddle the file on upgrade
[05:39] <cjwatson> s
[05:39] <cjwatson> it's not a lot of fun
[05:39] <pitti> cjwatson: heh, same boat then
[05:39] <cjwatson> I can patch in older key names, but I prefer not to do that indefinitely - easier to migrate
[05:40] <pitti> right, so did I
[05:46] <ogra> ??
[05:47] <ogra> why would you use gnome-typing-monitor then ?
[05:47] <somerville32> Doesn't that defeat the purpose of the application? lol <g>
[05:47] <Keybuk> I don't understand the question
[05:47] <Keybuk> the application forces me to take hourly typing breaks
[05:47] <Keybuk> there are occasions (such as team meetings) where that's not possible
[05:47] <ogra> right, thast its purpose
[05:48] <ogra> ah
[05:48] <Keybuk> a checkbox to temporarily disable it during those times would be useful
[05:48] <thom> Keybuk: just use workrave then?
[05:48] <Keybuk> workrave is ... over the top
[05:48] <Keybuk> I've never managed to configure it to not take up most of the panel; and just lock the screen once an hour
[05:50] <seb128> BenC: any news on the directfb merge?
[05:50] <BenC> seb128: With 2.6.20 finally uploaded, I'll be able to do some merges this next week
[05:51] <ogra> does that mean the alternate installer will switch to directfb as debian did ?
[05:51] <fabbione> BenC: i did look at it... it's a pain
[05:51] <BenC> fabbione: Doesn't looking at it mean you accept responsibility for it? :)
[05:52] <fabbione> BenC: forget it :) i was trying to merge it to satisfy a Depends and i had to tell myself: "Screw that.. i so much do NOT need this app"
[05:52] <cjwatson> ogra: probably not
[05:52] <seb128> BenC: ok
[05:52] <ogra> ah, good
[05:52] <BenC> hehe
[05:52] <pitti> BenC: do you accept bribes for the apport stuff? such as me taking merges from you or so? :)
[05:53] <cjwatson> ogra: I have absolutely no problem with the idea, but the execution of it isn't ready yet
[05:53] <BenC> pitti: I'll have time after the meeting to discuss it if you want
[05:53] <ogra> oh, i thought etch will ship with it
[05:53] <pitti> BenC: would be great; although it's mainly a matter of finding time to implement it, unless I wrote something unclear into the spec
[05:54] <ogra> (i'm fine with alternate as is ...)
[05:54] <cjwatson> ogra: etch will, although optionally
[05:54] <BenC> pitti: Ok, I'll refresh myself with the spec and go from there
[05:54] <cjwatson> the newt installer ain't going away any time soon
[05:55] <ogra> thats good
[05:57] <pitti> ogra: is my grep-dctrl fu not strong enough, or do we really not have an inetd in main yet?
[05:57] <ogra> netkit-inetd
[05:57] <cjwatson> unfortunately we need a libd-i fix and ABI change to make it possible to start doing proper cdebconf plugins to improve the UI
[05:58] <pitti> ah, right, that doesn't Provide:.*inetd of course
[06:00] <pitti> ogra: can we drop netkit-base to universe then? IOW, adding openbsd-inetd should fully replace netkit-inetd?
[06:01] <ogra> yeps it should
[06:01] <ogra> debian made the transition some months ago
[06:02] <pitti> yay
[06:02] <pitti> well, it replaces another source and it has openbsd in the name, how much better can it get? :-P
[06:03] <thom> um.
[06:03] <pitti> hey thom, how are you?
[06:04] <thom> hungover. office party last night ;-)
[06:04] <thom> other than that, good. you?
[06:04] <pitti> good as well, without the hungover :)
[06:18] <somerville32> pitti: Just to be on the safe side, have you seen this bug?: https://launchpad.net/distros/ubuntu/+source/fai/+bug/75779
[06:18] <Ubugtu> Malone bug 75779 in fai "fai-doc: Root password hash stored in log files." [Undecided,Unconfirmed]  
[06:18] <pitti> somerville32: no, didn't see it so far
[06:22] <somerville32> pitti: Should it be marked as a security vulnerability?
[06:23] <pitti> somerville32: I don't understand the bug from the brief description yet, I'll write a followup question
[06:23] <pitti> somerville32: not sure what fai-doc has to do with root password hashes
[06:24] <ogra> it documentzs the password for later use :P
[06:26] <cjwatson> rather reminiscent of the breezy installer vulnerability, that
[06:26] <cjwatson> I'm perversely glad that somebody else's installer had the same kind of thing ;)
[06:26] <ogra> :)
[06:26] <pitti> somerville32: the password of the buildd root account?
[06:27] <pitti> anyway, I'll look into it
[06:27] <ogra> just call it a feature :) you will never lose your root pw with it :)
[06:27] <somerville32> pitti: I didn't report it :P
[06:27] <pitti> glad that it's universe, though
[06:27] <pitti> spares us another brown-paperbag USN
[06:27] <jdong> cjwatson: haha, is it healthy to take relief in others' security bugs? ;-)
[06:27] <Mez> any idea why I get this: 
[06:27] <Mez> checking whether the C++ compiler (gcc   ) works... no
[06:27] <Mez> configure: error: installation or configuration problem: C++ compiler cannot create executables.
[06:27] <pitti> jdong: shared blame is half the blame ;)
[06:28] <pitti> Mez: did you try CXX=gcc?
[06:28] <cjwatson> jdong: schadenfreude, baby
[06:28] <ogra> Mez, get a sane compiler ? 
[06:28] <pitti> Mez: gcc -> C, g++ -> C++
[06:28] <pitti> cjwatson: wow, Schadenfreude is used in English?
[06:28] <Mez> ogra: I'm using the ubuntu ones
[06:28] <Mez> pitti: hmm - I'll have to hack on the damn code now
[06:28] <ogra> pitti, did you know that doppelgaenger is used in english ?
[06:29] <cjwatson> pitti: I'm not sure it's universally understood, but yes
[06:31] <pitti> ogra: I knew that one from a Star Trek episode
[06:31] <ogra> ah, i never watched them unduubbed
[06:31] <ogra> -u
[06:32] <Ng> we say kindergarten too, for pre-school. basically the english will steal anyone's words ;)
[06:32] <ogra> and zeitgeist :)
[06:32] <bhale> thats funny
[06:32] <somerville32> pitti: IF there is a bug report that says that a security update borked something, should I subscribe you?
[06:33] <pitti> somerville32: absolutely
[06:33] <thom> dubbing is utter crack :-)
[06:33] <pitti> somerville32: and IRC-ping me, for the sake of prioritizing (my bug inbox is as big as a planet)
[06:33] <ogra> thom, hey, all our actors live from it in germany 
[06:33] <somerville32> Low priority: https://launchpad.net/distros/ubuntu/+source/dovecot/+bug/75785
[06:33] <Ubugtu> Malone bug 75785 in dovecot "After security update (1.0.beta3-3ubuntu5.4), no service" [Undecided,Unconfirmed]  
[06:34] <pitti> somerville32: hm, I was so proud of my thorough testing :/
[06:34] <pitti> somerville32: will look, thnaks
[06:34] <somerville32> k
[06:36] <dade`> somehow in my ubuntu hald starts before acpi stuff
[06:37] <dade`> starts before acpi modules are loaded
[06:37] <dade`> this way acpi does not know about my battery
[06:38] <jdong> doesn't the acpid init script modprobe all the acpi modules?
[06:38] <dade`> it does, but does it after hald has beel started
[06:38] <ogra> arent they loaded in initramfs already ?
[06:38] <ogra> (just guessing)
[06:39] <dade`> no
[06:39] <dade`> hmm
[06:39] <dade`> wait
[06:41] <somerville32> Whats the name of that new program that automatically collects crash data?
[06:41] <ogra> apport
[06:42] <jdong> better known as "what's making my differential backups 3x larger"
[06:42] <somerville32> ogra: I thought the name was something like a bomb or something, lol. Are you sure it is apport?
[06:42] <ogra> pretty sure, yes
[06:42] <pitti> yes, it is :)
[06:43] <somerville32> Does apport do the balloon notification or does it use the notification daemon?
[06:44] <jdong> it does its own balloon to my knowledge
[06:44] <pitti> somerville32: n-d does the bomb and notification
[06:44] <jdong> it's a sad day when it's faster to compress something on that box by mounting sshfs over adhoc B wifi and having my other boxes do it
[06:44] <pitti> somerville32: and n-d calls apport-gtk when you click onto the bomb
[06:44] <somerville32> Is the bomb in the systray on in the balloon?
[06:46] <somerville32> The systray
[06:46] <somerville32> So what if the systray crashes?
[06:46] <shawarma> somerville32: It'll show up some other time.
[06:48] <jdong> LOL
[06:48] <jdong> what if apport crashes? ;-)
[06:48] <somerville32> jdong: Don't laugh :P I'm trying to figure where to reassign this bug report (Bug #62705) to :P
[06:48] <Ubugtu> Malone bug 62705 in xubuntu-meta "[edgy xubuntu uptodate]  "report crash" balloon should be clickable" [Wishlist,Confirmed]  http://launchpad.net/bugs/62705
[06:49] <pitti> jdong: the code jumps through some hoops to defend against that, but if the phython interpreter dies underneath apport, then things go bad, of course
[06:49] <pitti> somerville32: erm, it is clickable... anyway, it's update-notifier
[06:50] <somerville32> In Xubuntu though?
[06:50] <pitti> no idea if they use u-n
[06:50] <somerville32> We should get ubugtu to have someway to easily check to see if a package is in the seeds
[06:51] <pitti> somerville32: apt-cache rdepends update-notifier|grep desktop
[06:51] <pitti> somerville32: not in xubuntnu
[06:51] <pitti> s/nu$/u/
[06:54] <pitti> ogra: approved openbsd-inetd
[06:56] <ogra> thanks !
[06:58] <ogra> is there anything else in main depending on netkit-inetd ? 
[06:58] <ogra> i'm fine caring for the transition if there is
[06:58] <ogra> (actually i'd expect the debian transition to be fine though)
[06:58] <pitti> ogra: can't see anything
[06:59] <pitti> ogra: openbsd-inetd Provides:/Replaces: netkit-inetd
[06:59] <ogra> great ... i'll monitor anastacia
[06:59] <pitti> so it should Just Work (tm) with Dependencies
[06:59] <ogra> yeah
[06:59] <pitti> something needs to force the upgrade for users, though
[06:59] <ogra> in case of ltsp its simply ltsp-server ... 
[07:00] <pitti> so that they don't get into using an universe package after an upgrade
[07:00] <ogra> i'll look around for other possible candidates
[07:00] <pitti> ogra: I'm afraid we'll need a proper transitional package
[07:00] <pitti> n-inetd has very few rdepends
[07:00] <ogra> meh, ok, i'll do one ...
[07:01] <pitti> unfortunately openbsd-inetd version < netkit-inetd version
[07:01] <ogra> ah, k i didnt notice that 
[07:01] <pitti> ogra: Debian has to cope with that as well, did they epoch o-i?
[07:01] <ogra> (simply because i didnt look :) )
[07:02] <ogra> not that i know of, we should have their latest package ...
[07:02] <ogra> and ours has no epoch
[07:03] <ogra> anyway, i need a break, back in 30
[07:03] <pitti> mdz: FYI: https://blueprints.launchpad.net/distros/ubuntu/+spec/live-system-fs-mounting
[07:04] <mdz> pitti: thanks
[07:04] <pitti> ogra: if we don't care about netkit-inetd any more at all, we could just change the current package to become transitional
[07:04] <pitti> ogra: although, no, that'd mean to keep it in main
[07:29] <tkamppeter> There was a program to easily auto-generate patches, one started it, it opened a shell in which one did changes and after typing "exit" one got a patch, only I have no idea any more of the name of this program. can someone help me?
[07:30] <bhale> tkamppeter: dpatch-edit-patch, cdbs-edit-patch
[07:30] <tkamppeter> Thanks.
[07:30] <jdong> wow, that's sweet
[07:31] <jdong> to think I was using bzr for stuff like that...
[07:31] <bhale> cdbs-edit-patch gives you a "plain" patch
[07:31] <bhale> thank pitti 
[07:32] <psusi> hrm... can't view the changelog of a package on launchpad eh?
[07:35] <psusi> hrm... I bet you could rewrite those patch management tools to use a unionfs instead of copy/chroot/diff/delete... would probably be faster since you could avoid making all the copies
[08:02] <pitti> jdong: https://wiki.ubuntu.com/MOTU/School/PatchingSources, FYI
[08:27] <cjwatson> pitti: the Conflicts in the s-t-b change has the wrong version
[08:27] <cjwatson> +Conflicts: liboobs-1-1 (<< 0.5), gnome-system-tools (<< 2.15.5-0ubuntu3~prop1)
[08:28] <cjwatson> should be 0ubuntu5~prop1 in both places
[08:29] <cjwatson> pitti: I'm rejecting s-t-b on that basis; please reupload once you've corrected that. The others look fine so far and I'm accepting them
[08:39] <BenC> any archive folks alive?
[08:42] <cjwatson> BenC: very briefly ...
[08:44] <BenC> cjwatson: Nm, I forgot lowlatency went into universe and not main
[08:44] <cjwatson> ok, I'm slightly bemused but no problem :)
[08:47] <pitti> cjwatson: done; thanks for catching
[08:47] <pitti> cjwatson: I uploaded s-t-b before bumping the g-s-t version
[08:49] <seb128> BenC: what information would be useful on a bug "network card stop working after a while with 2.6.19 and 2.6.20" out of syslog messages and lspci?
[08:59] <siretart> mmmh. after upgrading to feisty, mdadm barks with 'mdadm: No devices listed in conf file were found'. Does anyone happen to know whats going on here?
[11:15] <jpetso> hi all. i got a question with packaging. very basic, very newbie, i hope i don't offend anyone by asking such easy questions ;) anyways...
[11:15] <jpetso> i'm maintaining the lila icon set, or at least the kde part of it, and somebody uploaded some control files to make a .deb package to http://revu.tauware.de/details.py?upid=3333
[11:16] <jpetso> now... how can i rebuild this package on my own?
[11:16] <jpetso> so that we can offer it through our website, and update it timely, and stuff
[11:19] <keescook> hm... gdb has FTBFS on i386/amd64.