[12:42] <wasabi> cool. minswaps option added to swapd... and also default values for memlimit and swapsize.
[12:42] <wasabi> defaulting to total physical ram.
[12:42] <wasabi> So, with minswap 1, and memlimit and swapsize set to default, it will always create one file the size of your ram.
[12:55] <Keybuk> hplip_0.9.11-2ubuntu3.dsc: invalid Build-Depends field; cannot be parsed by apt.
[12:55] <Keybuk> eh?
[12:57] <ogra__> heh
[01:14] <Keybuk> siretart: ping?
[01:59] <bluefoxicy> sfllaw, lifeless, either of you awake?
[02:01] <lifeless> I appear to me
[02:01] <bluefoxicy> is there somewhere I can track what exactly is going on with AutomatedProblemReports
[02:02] <lifeless> the spec, or pitti
[02:02] <bluefoxicy> ah, so you wouldn't know :>
[02:02] <lifeless> :)
[02:03] <bluefoxicy> I was curious about this part mainly:  "Debug symbols are very big and we want to avoid requiring to download them on the client machine. So we need a server which processes the incoming reports, generates a backtrace from the report data, stack frame, and debug symbols, and adds the stacktrace to the generated report."
[02:03] <bluefoxicy> re "a server" == a daemon or just a Web application like a CMS (i.e. Launchpad) that can take the data over https into a CGI script
[02:04] <bluefoxicy> I guess I'll ask pitti though.
[02:23] <bddebian> Howdy
[02:39] <bluefoxicy> hi bddebian
[02:47] <Keybuk> :p
[02:47] <bluefoxicy> what happen
[02:47] <Keybuk> "oh, I know, I'll just test one more thing ... damn!"
[02:47] <bluefoxicy> did he apt-get build-dep another one of doko's packages?
[02:52] <ogra> woah
[02:52] <bddebian> Hello bluefoxicy
[02:52] <ogra> http://www.dylanknightrogers.com/faster-dapper.sh
[02:52] <tseng> ogra: do i need policykit? :(
[02:52] <ogra> sudo /sbin/hdparm -u1 -m16 -c1 -A1 -a64 -d1 -K1 $INSTALLED_DRIVE > /dev/null
[02:53] <tseng> scary
[02:53] <ogra> LOL
[02:53] <bddebian> Hmm, what to do, what to do..
[02:53] <ogra> # Enable dash as /bin/sh to run shell scripts instead of bloated bash
[02:53] <ogra> # See
[02:53] <ogra> if ( ! dpkg -l dash >/dev/null 2>&1 ); then
[02:53] <ogra>     sudo apt-get install dash && sudo update-alternatives --install /bin/sh sh /bin/dash 1
[02:53] <ogra> else
[02:53] <ogra>     sudo update-alternatives --install /bin/sh sh /bin/dash 1
[02:53] <ogra> fi
[02:53] <ogra> hahahaha
[02:53] <Keybuk> -u often results in massive filesystem corruption
[02:54] <bluefoxicy> # Disable sudo asking for your password for the remainder of the script
[02:54] <bluefoxicy> sudo sed -ie '/^%admin/s/ALL$/NOPASSWD: ALL/' /etc/sudoers
[02:54] <tseng> haha!
[02:54] <bluefoxicy> ogra:  Fuck that.
[02:54] <Keybuk> -m16 is sane
[02:54] <Keybuk> likewise -c1 is sane
[02:54] <tseng> bluefoxicy: easy there killer
[02:54] <bluefoxicy> the moron should have used 'id' to check if he is root; if not, sudo $0
[02:54] <Keybuk> -A1 is the default
[02:55] <ogra> if ( ! grep "Ubuntu 6.06" /etc/issue >/dev/null 2>&1); then
[02:55] <ogra>     echo "This script is only intended for Ubuntu 6.06 Dapper Drake"
[02:55] <ogra>     exit 1
[02:55] <ogra> fi
[02:55] <ogra> *GRIN*
[02:55] <bluefoxicy> tseng:  immediate brain damage
[02:55] <Keybuk> -a64 is probably slower than the default!
[02:55] <bluefoxicy> and a race condition you can exploit to get root
[02:55] <ogra> hah
[02:55] <Keybuk> -d1 is usually set by default
[02:55] <Keybuk> so the usual sane hdparm flags, and some odd ones
[02:56] <ogra> yeah
[02:56] <ogra> the rest of that scripts is similar ...
[02:56] <Keybuk> dash we do by default now
[02:56] <ogra> thats why i laughed my ass off :)
[02:56] <bluefoxicy> ogra: that script installs preload
[02:56] <bluefoxicy> I haven't used preload
[02:57] <bluefoxicy> looking at it I had guessed that it would make the system rather slow as shit, but I haven't actually tried.  Comment?
[02:58] <tseng> bluefoxicy: can you seriously take it down a notch?
[02:58] <tseng> bluefoxicy: you know I would love to ban you
[02:58] <bluefoxicy> tseng:  okay
[03:01] <tseng> thanks.
[03:02] <bluefoxicy> also Method loves to ban me more
[03:02] <tseng> I'm sure he does
[03:03] <tseng> moving right along, policykit anyone?
[03:04] <tseng> is out plan to patch it out?
[03:04] <bddebian> tseng: policykit?
[03:04] <tseng> bddebian: hal policykit
[03:04] <bddebian> Ah
[03:04] <tseng> says "can I do this?"
[03:05] <bddebian> Speaking of policy, anyone want to help me make hamlib conform to the new python policy? :-)
[03:05] <ogra> tseng, we'll likely rather stay with old g-p-m if it doesnt work without plokit
[03:05] <ogra> *polkit
[03:05] <tseng> ogra: well
[03:05] <tseng> ogra: old gpm wont show me battery % anymore
[03:06] <tseng> they are both broken
[03:06] <ogra> then we'll need to fix that ... at least it suspends/hibernates
[03:13] <bddebian> doko: ping again?
[03:14] <ogra> bddebian, 3:14
[03:14] <bddebian> Oh
[03:15] <zul> ogra: oh i know this one...bible verses 3:14 we own your bases
[03:16] <ogra> heh
[03:30] <bddebian> Anyone think doko would care if I uploaded adonthell?
[03:48] <crimsun> hmm
[03:48] <bddebian> Hi crimsun
[03:49] <crimsun> now that I think about it, I have to manually restore my volume in gnome using the hotkeys anyhow. Why does alsa-utils's initscript even bother storing on action-stop?
[03:50] <crimsun> granted not everyone uses gnome, but even kmix and xfce4-mixer AIUT handle restoring the mixer levels
[03:51] <bddebian> WHAT?  No everyone uses Gnome? :-)
[04:16] <wasabi> I take it xorg is broken? Missing fixed. Unless it's moved.
[04:29] <rodarvus> wasabi: what do you mean by "xorg is broken"?
[04:31] <Hobbsee> hi rodarvus 
[04:32] <rodarvus> hi Hobbsee
[04:32] <rodarvus> I was about to turn off my computer but wasabi's comment got my attention :)
[04:33] <rodarvus> wasabi: I've been doing xorg-related uploads all day long, but they shouldn't be related to any fonts brokeness
[04:34] <rodarvus> wasabi: per your description, it seems like you have problems with your fontpath (but that should have been handled by updates done about ten days ago, by now)
[04:34] <fabbione> morning
[04:34] <fabbione> rodarvus: he can open a bug.. go and get some sleep
[04:35] <rodarvus> indeed :)
[04:35] <rodarvus> good night all
[04:35] <bddebian> Gnight rodarvus
[04:40] <wasabi> Ahh. Looks like update-fonts-dir is broke.
[04:41] <wasabi> Breaking because /usr/lib/X11R6/fonts was removed.
[04:41] <wasabi> Quicky find/replace job in it fixed it right up.
[04:42] <wasabi> whoops. wasn't paying attention and missed him.
[04:42] <wasabi> sily VTs.
[05:05] <floam> tseng: any idea how much longer muine will be broke for? I rebuilt it and looked at it a bit, it appears it's not as obvious as I guessed
[05:09] <netdur> ubuntu says I have seven floppy readers, actually I don't have any, I can edit /etc/fstab to fix problem but I want fill bug first... what information should I attach to soon-to-be-opened-bug?
[05:27] <fabbione> netdur: i think there is already a bug open for that
[05:27] <fabbione> netdur: no actually i am pretty sure. i just can't remember against what exact package
[05:28] <Hobbsee> morning fabbione 
[05:28] <fabbione> hey Hobbsee 
[05:28] <fabbione> morning is a big word.. changing TZ is horrible
[05:29] <Hobbsee> fabbione: okay. evening then.  it's not morning here either
[05:30] <netdur> fabbione: thanks, there's no need for dupes :)
[05:30] <fabbione> Hobbsee: it's 5am here now :)
[05:30] <fabbione> well 5:30
[05:30] <Hobbsee> fabbione: urgh.
[05:30] <fabbione> but i have been awake for over an hour
[05:30] <Hobbsee> fabbione: then why are you awake?
[05:31] <fabbione> Hobbsee: to be able to work on cluster. It's too warm during the day to keep all the equipment turned on
[05:31] <Hobbsee> fabbione: ah...yes...of course
[05:31] <Hobbsee> and i'm currently freezing cold.  hum.  that still seems weird ot me :P
[05:32] <fabbione> Hobbsee: ain't my fault if you live on the wrong side of the planet :)
[05:33] <Hobbsee> fabbione: yeah, true.
[06:09] <bluefoxicy> what time is it at pitti's place
[06:09] <Hobbsee> bluefoxicy: europe time?  5-6am?
[06:10] <bluefoxicy> what is his native language anyway
[06:10] <bluefoxicy> talking to him is like talking to trulux, just a little more sane
[06:16] <Hobbsee> bluefoxicy: not sure, i've only been told that he's in europe
[06:16] <fabbione> bluefoxicy: .de. it's 6am now
[06:19] <bluefoxicy> ah
[06:19] <bluefoxicy> lucky, I hear the people in germany are actually friendly
[06:20] <fabbione> bluefoxicy: it really depends with who :P
[06:20] <fabbione> specially after the WC2006 ;)
[07:16] <Hobbsee> hi all
[07:24] <fabbione> init/built-in.o: In function `try_name':
[07:24] <fabbione> do_mounts.c:(.text+0x604): undefined reference to `__stack_chk_fail'
[07:24] <fabbione> grep stack_chk_fail * -r | wc -l
[07:24] <fabbione> 0
[07:24] <fabbione> so what's this now?
[07:24] <fabbione> doko: ^^
[07:30] <bluefoxicy> fabbione:  that should be in glibc
[07:31] <bluefoxicy> fabbione:  what are you building?
[07:31] <fabbione> bluefoxicy: a kernel 
[07:31] <bluefoxicy> .... oh, shit.  Right.
[07:31] <fabbione> i think it's that ssp crap
[07:31] <bluefoxicy> They turned on the stack smash protector by default
[07:31] <fabbione> how do i disable that?
[07:31] <bluefoxicy> probably didn't manage to set it to disable on kernels.
[07:31] <bluefoxicy> -fno-stack-protector
[07:31] <fabbione> it's a custom kernel
[07:32] <fabbione> thnkas
[07:32] <bluefoxicy> you know how to change the flags the kernel uses to build right?
[07:32] <fabbione> 2 hours wasted
[07:32] <fabbione> i am not even going to answer to that question...
[07:32] <bluefoxicy> (I don't remember which lines in the Makefiles to edit anymore)
[07:33] <bluefoxicy> haha.  It's not something you normally gotta screw with :P
[07:35] <pitti> Good morning
[07:35] <pygi> morning pitti
[07:35] <fabbione> pitti: good morning to you too :)
[07:36] <pitti> hi pygi 
[07:36] <pitti> hi fabbione 
[07:36] <pitti> fabbione: -fno-stack-protector, dude :)
[07:36] <fabbione> pitti: can you please add that to gcc man page?
[07:36] <pitti> fabbione: this was a known issue when we discussed how to enable ssp
[07:36] <pitti> fabbione: and we requested to fix that upstream
[07:37] <pitti> fabbione: yep, will prepare a snippet and send it to doko for the next upload
[07:37] <fabbione> because there is the enable flag
[07:37] <fabbione> but not how to disable and crap
[07:38] <fabbione> also with that kind of error mentioned it might help
[07:58] <bluefoxicy> pitti
[07:59] <bluefoxicy> With the AutomatedProblemReports, you mention a "server" to handle incoming requests?
[07:59] <bluefoxicy> Can Launchpad somehow just be extended to accept problem reports submitted over https and index them etc etc?
[08:00] <bluefoxicy> (which would be a "Web application" instead of a "server" I guess...)
[08:04] <pitti> bluefoxicy: we didn't specify that part yet
[08:04] <pitti> bluefoxicy: but we need some backend service which takes core dumps/stack frame dumps and debug symbols and assembles good stack traces out of them
[08:04] <bluefoxicy> pitti:  nods.  I am still overly excited about that :P
[08:05] <bluefoxicy> pitti:  that can likely be done or called from a php or python script.
[08:05] <bluefoxicy> Also, with the stack traces
[08:06] <bluefoxicy> if you have a /proc/PID/maps file and a list of addresses, you can locate what addresses fall in what mappings
[08:06] <bluefoxicy> you can then take said mappings, subtract their offsets from the addresses you have, and produce offsets in those mappings (i.e. relocations!)
[08:07] <bluefoxicy> Then you can load the same library or program, take its base load address, add that to the offset you computed, and you now have the address you need :)
[08:08] <bluefoxicy> I noted this on AutomatedProblemReports somewhere at the end.  Figured it might be helpful.  You can keep the debugging symbols separate from the actual library itself right? (you really should have binarily identical files to do this...)
[08:23] <pitti> bluefoxicy: something like that will be necessary if we don't have a full core dump, yes :/
[08:23] <pitti> bluefoxicy: right, see AptElfDebugSymbols
[08:24] <pitti> bluefoxicy: there's already a package in the archive that automatically builds .ddebs (separate debug symbols)
[08:24] <pitti> bluefoxicy: pkg-create-dbgsym
[08:24] <bluefoxicy> cool.
[08:25] <bluefoxicy> That relocation technique shouldn't be too tough, I mean you can load any program that loads the library or executable image and then tell gdb to give whatever info about the new calculated address.
[08:25] <bluefoxicy> You won't have the convenience of having the heap, stack, and anonmappings from a core dump of course.
[08:25] <bluefoxicy> but you'll at least be able to get a symbolic backtrace.
[08:28] <pitti> bluefoxicy: well, we still need a stack dump for the function arguments
[08:29] <pitti> bluefoxicy: incorporating them will be some more fiddling work
[08:31] <pitti> Riddell: any idea about bug 53518?
[08:31] <Ubugtu> Malone bug 53518 in Ubuntu "Problem with login in!!" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53518
[08:31] <bluefoxicy> a little more work.
[08:31] <bluefoxicy> However, the function arguments are not as important as the function itself; we still have a win if we learn a code path is broken, even if we don't know why it's broken.
[09:07] <dholbach> good morning
[09:12] <bluefoxicy> i have to sleep, it's 3am
[09:31] <Burgundavia> fabbione: I don't know if I am more scared about you becoming a father or the poor child with you as a father ;)
[09:34] <fabbione> Burgundavia: i think my wife is more scared than you are for the poor child to become like me :D
[09:34] <Burgundavia> fabbione: indeed
[09:38] <crimsun> congrats fabbione :-)
[09:40] <fabbione> i am not father yet
[09:40] <fabbione> there is nothing to congratulate...
[09:40] <crimsun> bah
[09:40] <fabbione> you will all know when i will be father
[09:40] <fabbione> trust me on that :D
[09:40] <Burgundavia> crimsun: I was commenting on the scary prospect of fabbione actually having to teach the little rotter about ethics and all that jazz
[09:41] <crimsun> ah
[10:47] <Kamion> mvo: over your holiday, I found some serious weirdness in python-apt, and was trying to decide if it merited a bug report or not
[10:47] <Kamion> mvo: specifically, InstallProgress forks a child process and runs pm.DoInstall() in that
[10:48] <Kamion> mvo: the problem with this is that any exceptions get raised in the child process, rather than in the parent process where the application can actually deal with them anely
[10:48] <Kamion> sanely
[10:48] <mdke> is anyone working on some knot reviews like mgalvin did with the flights at http://www.ubuntu.com/testing ?
[10:48] <Kamion> I rewrote ubiquity's InstallProgress subclass to do it the other way up, which also means it doesn't spin so much on waitpid/read
[10:49] <Kamion> but I don't know if you want to do something similar with apt.progress; I guess you'd have to hunt down and check all the users now
[10:53] <mvo> Kamion: interessting! I will have a look, is it in your ubiquity bzr branch?
[10:55] <Kamion> mvo: yep
[10:58] <dholbach> heya seb128!
[10:58] <seb128> hey dholbach
[11:10] <Kamion> mvo: the only downside is that if the work done to process apt status messages is remotely likely to raise an exception, then there isn't much that can be done to get that exception out to the main program
[11:10] <Kamion> but it seemed better to me to make the trade-off that way
[11:10] <seb128> ogra: did you send that mail about gnome-power-manager?
[11:16] <dholbach> can somebody get jokosher out of NEW? ;)
[11:21] <Kamion> in a bit
[11:21] <dholbach> yoohoooo!
[11:28] <pygi> dholbach: :)
[11:29] <fabbione> let's not make my work useless..
[11:29] <simira> who's fault is it that my sd-card isn't automatically mounted when I insert it in the reader (on my laptop)?
[11:29] <fabbione> FYI in .18-rc statfs call uses dentry while in .17 uses sb
[11:29] <fabbione> now.. you might think who cares...
[11:30] <fabbione> that it wasted about one day of work to understand why a FS doesn't work and you get 20GB instead of 200GB of free space (when not oopsing)
[11:30] <fabbione> (and let's skip the story in the middle of changing HW and stuff.. ok?)
[11:33] <ogra> seb128, the error must be on my side or a bug ... seems its supposed to work without plokit according to hughsie
[11:33] <seb128> ogra: you mailed him?
[11:33] <ogra> seb128, i talked to him
[11:33] <seb128> ok
[11:33] <ogra> i'll dig for the reason 
[11:34] <seb128> vuntz: looks like g-p-m 2.15 doesn't require policykit, it should work without
[11:34] <seb128> ogra: ok, thank you
[11:35] <ogra> seb128, thanks me if i got it workig ;P
[11:35] <ogra> ugh ... i should train typing 
[11:36] <ogra> *thank me if i got it working ;P
[11:38] <seb128> ogra: "get"? :p
[11:39] <vuntz> seb128: ok
[11:40] <seb128> lu vuntz ;)
[11:41] <ogra> oh, that reminds me ... 
[11:41] <tseng> floam: its not obvious, im assuming its calling dbus_session_closed or whatever they just took out of the api
[11:42] <tseng> floam: the weekend is coming up, I might manage to fix it, might not... now accepting patches
[11:42] <seb128> Kamion: do we need an UVF for gstreamer or is that the same exception than GNOME?
[11:43] <ogra> seb128, isnt it a requirement of gnome ? 
[11:43] <seb128> ogra: it is, like xorg is one too, doesn't mean xorg has a permanent UVF :p
[11:43] <dholbach> http://gstreamer.freedesktop.org/releases/gstreamer/0.10.9.html looks quite good :)
[11:44] <ogra> seb128, right, but if it doesnt work without :)
[11:47] <ogra> huggers !
[11:48] <ogra> vuntz, is there something planned for pessulus that makes it possible to edit profiles of other users ? or do i need to copy gconf stuff around ? 
[11:49] <Kamion> seb128: I don't know about permanent UVF exceptions, but I'm OK with you uploading that
[11:49] <seb128> Kamion: ok, that's slomo who did that update actually but should be fine too, thank you :)
[11:49] <Kamion> ok, I think the seed/cdimage world is a bit saner now
[11:49] <seb128> slomo: read that? 
[11:50] <ogra> vuntz, see "Lockdown on the fly" for why i'm asking: https://wiki.edubuntu.org/StudentControlPanelCompletion
[11:50] <Kamion> adding new seeds that should end up on the CD generally doesn't require coordination with me any more now
[11:50] <slomo> Kamion, seb128: ok, i'll upload gst and gst-plugins-base then... thanks :)
[11:50] <seb128> cool
[11:50] <Kamion> you just have to make sure that the ship seed inherits from those seeds (in the STRUCTURE file)
[11:50] <Kamion> this meant I had to go around editing STRUCTURE files in old releases, but that's life
[11:51] <vuntz> ogra: would this be running on the same computer?
[11:51] <ogra> vuntz, yes, its a ltsp server, everything runs on one machine
[11:51] <Kamion> ship> or server-ship for the server build
[11:52] <vuntz> ogra: and I guess you don't want to disable the command line for the user using the control panel
[11:52] <aliasfred>  q. does the apt source list support something like /etc/apt/sources.d/[list of file]  with each of the file in the list contains repository description ?
[11:52] <ogra> vuntz, not really ... that will run under sudo :)
[11:53] <vuntz> ogra: it should be easy to do what you want
[11:53] <ogra> is there a howto or something ? 
[11:53] <vuntz> nope :-)
[11:53] <ogra> or do i need to su $USER pessulus ?
[11:53] <vuntz> you just need to change the GCONF_MANDATORY_SOURCE variable in pessulus
[11:53] <ogra> (that would be my ugliest fallback)
[11:53] <ogra> ah !
[11:54] <ogra> cool
[11:54] <vuntz> so it should be possible to patch pessulus to take a command line argument to do so
[11:54] <Kamion> aliasfred: yes, sources.list.d
[11:54] <vuntz> ogra: well, I believe this should be enough. You'd have to verify ;-)
[11:54] <ogra> yeah, that should be no problem ... 
[11:54] <aliasfred> Kamion: thanks
[11:54] <ogra> vuntz, thanks for now  :)
[11:55] <vuntz> ogra: feel free to open a bug upstream (and attach a patch there if you do one)
[11:55] <ogra> vuntz, only if thats necessary :)
[12:03] <doko> pitti, fabbione: read the manpage. it's there
[12:03] <doko> bddebian: no, I don't care, even not at 3am ;-)
[12:07] <mvo> ogra: what is it doing?
[12:08] <ogra__> mvo, nothing anymore ... i just killed it with a failed hibernate attempt ...
[12:08] <ogra__> mvo, welcome back btw ! :)
[12:09] <mvo> ogra__: ah, ok. thanks for the welcome, its good to be back (although it was good to be away too ;)
[12:09] <ogra__> heh
[12:10] <mvo> *ick* moving is no fun!
[12:10] <ogra__> nah ...
[12:11] <ogra__> i'm all alone and the heat doent really help 
[12:11] <ogra__> *doesnt
[12:11] <mvo> :(
[12:12] <ogra__> well, i'll make it ... and then i'll enjoy the new luxury \o/
[12:12] <ogra__> the new house is so lovely with all its gadgets :)
[12:13] <mvo> it has a pool and/or a sauna, right?
[12:13] <ogra__> nope, not yet
[12:13] <ogra__> thats stuff i'll add
[12:13] <mvo> "yet"
[12:13] <sivang> re all
[12:14] <doko> mvo: apt-get dselect-upgrade isn't yet fixed in 0.6.44.2ubuntu3
[12:14] <ogra__> but it has a solar powered heating, electrical time/brightness based window blinds .... and the most square thing evah, an electrical garage door :)
[12:15] <ogra__> sauna and hot tub are planned for autumn :)
[12:16] <mvo> doko: with ubuntu4?
[12:16] <mvo> doko: that was the version I uploaded
[12:16] <Kamion> .2ubuntu3 was my upload and wasn't expected to fix dselect-upgrade :)
[12:16] <doko> mvo: not yet built/in the archives ..
[12:16] <mvo> doko: please keep me updated once it hits the archive 
[12:20] <ogra> hmm, where is my cloak
[12:22] <tseng> ogra: i see it.
[12:22] <tseng> ogra: cloaks are inherently racy
[12:22] <ogra> hmm, i see dip.t-dialin.net
[12:23] <tseng> whois says masked
[12:23] <ogra> i also got no message from nickserv
[12:23] <ogra> usually it tells me it sets the cloak
[12:28] <aigarius> can anyone point me towards where to dig to find all hardware dependant bits of a fresh Dapper install? i.e. what bits can change when installed on a different hardware?
[12:30] <Kamion> all the stuff hw-detect does; /etc/{mkinitramfs,initramfs-tools}/conf.d/resume (oops, need to fix ubiquity for the new location); /boot/initrd.img-*; /etc/network/interfaces; /etc/iftab
[12:30] <Kamion> I think that's about it
[12:31] <Kamion> you can look through the stuff ubiquity does
[12:31] <Kamion> (scripts/install.py)
[12:31] <aigarius> thanks, will look at that.
[12:33] <Mithrandir> hmm, bzrk seems to be broken in dapper.
[12:33] <tseng> Mithrandir: hasnt worked for me in awhile
[12:33] <tseng> Mithrandir: but i blamed my ssh X forwarding or something
[12:34] <Mithrandir> bzr: ERROR: exceptions.AttributeError: 'BzrBranch5' object has no attribute 'get_revision' at /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrk/graph.py line 42 in distances
[12:34] <tseng> thats it
[12:34] <Mithrandir> doesn't look like SSH breakage. :-P
[12:34] <tseng> yeah :p
[12:34] <tseng> I screwed up some permissions, too
[12:34] <tseng> having 3 people edit in a directory is bad news
[12:35] <tseng> (I use bzr to merge between devel and production, not between developers.. they arent totally up on the VCS bit yet) :(
[12:35] <dsas> Mithrandir: that's supposed to have been fixed once. bug #37162
[12:35] <Ubugtu> Malone bug 37162 in bzrk "bzrk is broken with current version of bzr in dapper" [High,Fix released]  http://launchpad.net/bugs/37162
[12:36] <pygi> released, but not commited perhaps?
[12:36] <tseng> pygi: that doesnt make sense.
[12:36] <ogra> pygi, no, sivang uploaded that to dapper
[12:36] <ogra> but bzr might have changed since :)
[12:39] <thom> tseng: ACLs for the win, in that case, i guess :-)
[12:39] <gnomefreak> is there a plan to add opera to dapper repos?
[12:39] <tseng> thom: yeah that would be nice
[12:39] <Kamion> gnomefreak: it's in dapper-commercial
[12:39] <ogra> ??
[12:39] <tseng> thom: or not letting networking guys write code
[12:39] <ogra> gnomefreak, its there :)
[12:39] <gnomefreak> Kamion: can someone add that to the site
[12:39] <ogra> ah, damned lag
[12:39] <Kamion> archive.canonical.com
[12:39] <Kamion> gnomefreak: -v
[12:40] <Kamion> also gnome-app-install in dapper will list it
[12:40] <gnomefreak> this is what im talking about http://www.ubuntu.com/news/opera9
[12:40] <Kamion> gnomefreak: er, -v => please be more verbose. what site?
[12:40] <Kamion> gnomefreak: upgrade to current dapper-updates and add/remove programs will list it
[12:40] <ogra> gnomefreak, whats wrong with that page ? i find it pretty clear
[12:41] <Kamion> it should tell you that you need to upgrade, but I can't edit that page
[12:41] <Kamion> there is an Ubuntu contact e-mail address at the bottom of that page
[12:41] <gnomefreak> ok ty
[12:42] <thom> tseng: heh, or that
[12:42] <mdke> it's not clear about how to install it without add/remove programs though, he has a point
[12:42] <ogra> seb128, is it intentional that my volume mutimedia keys dont follow the selected soundcard in the volume control applet ?
[12:43] <gnomefreak> im emailing yates
[12:43] <ogra> they appear to always only work for the internal one ... 
[12:46] <dholbach> heya rodarvus!
[12:46] <rodarvus> dholbach: hi there!
[12:46] <dholbach> you did rocking work on the X front!
[12:46] <mdke> anyone with access to the fridge? can you add the docteam meeting of today at 19UTC?
[12:47] <dholbach> mdke: if everything else fails, frigde-devel@ might help - but i guess you know that already
[12:47] <rodarvus> dholbach: thanks :)
[12:47] <rodarvus> theres lots of stuff to do, though :/
[12:48] <dholbach> i can imagine - how many source package are those?
[12:48] <rodarvus> I have to finish updating the rest of the libs (15-20, I think), and then theres xorg-server, mesa, and aaaaall the drivers
[12:48] <rodarvus> I think 100+
[12:48] <mdke> dholbach: yeah, will try that
[12:48] <rodarvus> not counting apps, which are less important
[12:49] <dholbach> time to attract followers to a x team :)
[12:50] <Kamion> ooh, Debian fixed the yaboot initramfs/XFS bug
[12:50] <HiddenWolf> rodarvus: I noticed x detects my resolution wrongly on the knot-1 livecd, which data should I gather for a proper bug report?
[12:50] <dholbach> I started https://wiki.ubuntu.com/XSwat and worked on an announce of the team, but infinity and fabbione never found the time
[12:51] <rodarvus> let me take a look there
[12:52] <ogra__> mumble mumble ...
[12:53] <rodarvus> HiddenWolf: to be sincere, I haven't touched any bits regarding xorg configuration during install, yet (so I'm not completely aware of the installer log files) - but /etc/xorg.conf and /var/log/Xorg.0.log are a good start
[12:53] <rodarvus> also possibly the output of lspci -v
[12:53] <HiddenWolf> rodarvus: Right, i'll start there then.
[12:55] <bishop> ogra__: gnome-power-manager indeed does work when configured with --disable-policykit
[12:55] <ogra__> bishop, it didnt two weeks ago
[12:56] <ogra__> but actually it does now ...
[12:56] <ogra__> (just uploaded it)
[12:56] <bishop> ogra__: yes, theres some fancy charting and projecting in it now
[12:56] <dholbach> yay
[12:56] <ogra__> i suspect we're missing a versioned dependency on something
[12:56] <bishop> ogra__: on eissue is that i have two batteries and when I swap them the new one is not recognized
[12:56] <ogra__> bishop, no need to tell me that i spend about 4 workdays on it ;)
[12:57] <ogra__> dholbach, i left the icon stuff in the source package, just disabled it in rules so you can fix/add the new icons and re-enable it ...
[12:57] <dholbach> ok
[12:57] <dholbach> merci beaucoup
[12:58] <ogra__> but beware, there are a lot new ones and 50% need to be resized
[12:58] <dholbach> will you do gnome-screensaver next?
[12:58] <ogra__> is there a new one ? 
[12:58] <ogra__> then i'll do it indeed
[12:58] <dholbach> 2.15.4
[12:58] <ogra__> oh, right 
[12:59] <dholbach> ogra__: do you use a rss reader?
[12:59] <ogra__> nope, but i can :)
[12:59] <dholbach> http://ftp.gnome.org/pub/GNOME/LATEST.xml
[12:59] <dholbach> they have a mailing list as well, but it was broken some days ago, and i prefer rss anyway ;)
[01:00] <dholbach> liferea is good stuff since slomo maintains it
[01:00] <dholbach> hehe
[01:00] <dholbach> gotta collect them all
[01:00] <ogra__> its the only reason i listen to intern radio all the day :)
[01:00] <ogra__> *internet
[01:00] <ogra__> just for the RB icon :P
[01:00] <slomo> dholbach, ogra: but the mozilla/firefox backend is broken in latest edgy :( use the gtkhtml one for now
[01:00] <StevenK> "I listen to Internet radio for the tray icons."
[01:00] <dholbach> slomo: yeah
[01:01] <dholbach> 'i don't know what this "gnutella thing" does, but it has a nice trayicon'
[01:01] <ogra__> lol
[01:01] <StevenK> Heh
[01:01] <bishop> ogra__: which package is responsible for detecting that a battery has been swapped for another one?
[01:01] <ogra__> bishop, hal
[01:02] <bishop> ogra__:  ok, but /proc/acpi/battery is not changed
[01:02] <bishop> as well
[01:02] <ogra__> that sounds like a kernel prob then
[01:02] <bishop> ogra__: so i file a bug against linu?
[01:02] <bishop> x
[01:03] <ogra__> i'd start with that ... the kernel team will point you in the right direction if its wrong
[01:05] <bishop> ogra__: ok thanks. i'm down to 47% capacity on my small battery :(. something the new g-p-m made me aware of.
[01:06] <ogra__> slomo, 
[01:06] <ogra__> ogra@edubuntu:~/packages$ LANG=C liferea
[01:06] <ogra__> A stale lockfile has been found, and was deleted.
[01:06] <ogra__> No browser module configured!
[01:06] <ogra__> trying to load browser module Mozilla (liblihtmlm.so)
[01:06] <ogra__> Segmentation fault
[01:09] <dholbach> ogra: what slomosaid
[01:09] <ogra> thats not shipped it seems ...
[01:10] <dholbach> ?
[01:10] <ogra> ** (liferea:8216): WARNING **: Failed to open HTML widget module (/usr/lib/liferea/liblihtmlg.so) specified in configuration!
[01:10] <ogra> /usr/lib/liferea/liblihtmlg.so: cannot open shared object file: No such file or directory
[01:10] <dholbach> sudo apt-get install liferea-gtkhtml
[01:10] <ogra> ah ... just found it with apt-file as well :)
[01:51] <Mithrandir> seb128: why does gnome-system-monitor recommend ligksu2-dev and libsexy-dev?
[02:00] <StevenK> Mithrandir: Because gnome-system-monitor wants more sex appeal.
[02:12] <Mithrandir> Kamion: the live cds include .disk/base_components , base_installable and udeb_include.  That's kinda wrong.
[02:12] <Kamion> I guess, yeah
[02:12] <doko> I LOVE vim's changelog mode ...
[02:13] <Kamion> could you file an ubuntu-cdimage bug about that and I'll clear it up?
[02:13] <Mithrandir> Kamion: sure.
[02:13] <Kamion> ta
[02:13] <zul> hi
[02:25] <ogra> mumble mumble ...
[02:25] <ogra> why the heck cant i convince g-s-s to pick up the xscreensavers ...
[02:26] <ogra> seb128, i'm just stracing the g-s-s preferences gui, is it normap that such apps load all .desktop files on startup ? seems like a major slowdown to me ...
[02:26] <ogra> *normal
[02:29] <seb128> ogra: does it use the .desktop for something?
[02:29] <ogra> nope
[02:29] <ogra> open("/usr/share/applications/rhythmbox.desktop", O_RDONLY|O_LARGEFILE) = 19
[02:29] <ogra> fstat64(19, {st_mode=S_IFREG|0644, st_size=7523, ...}) = 0
[02:29] <seb128> I'll have a look
[02:29] <ogra> thast from the strace
[02:29] <seb128> is it using gnome-menus of libgnome-desktop for something?
[02:30] <ogra> grepping for it doesnt show anything ... 
[02:30] <ogra> i'll upload the output ... wait a sec
[02:30] <seb128> I'll have a look and let you know if I figure something
[02:31] <ogra> i dotn think thats the issue i have here, i just find it weird that it does it
[02:31] <seb128> $ ldd $(which gnome-screensaver-preferences) | grep menu
[02:31] <seb128>         libgnome-menu.so.2 => /usr/lib/libgnome-menu.so.2 (0xb76be000)
[02:31] <ogra> hmm, not in the strace
[02:31] <ogra> http://people.ubuntu.com/~ogra/gss.log
[02:32] <ogra> open("/usr/lib/libgnome-menu.so.2", O_RDONLY) = 3
[02:32] <ogra> err
[02:32] <ogra> why didnt less find it ?
[02:32] <ogra> weird ...
[02:33] <ogra> hmm, seems less doesnt wrap while searching anymore by default ...
[02:36] <seb128> ogra: hum
[02:36] <seb128> "     - suspend and hibernate support need the new hal policy kit now so
[02:36] <seb128>        please dont file bugs about either before that is avaliable in ubuntu"
[02:36] <seb128> ogra: ?
[02:36] <ogra> argh
[02:36] <ogra> sorry
[02:36] <ogra> i forgot to fix the changelog ... sily me
[02:37] <ogra> *silly too
[02:37] <seb128> Mithrandir: because ithey are dlopened at runtime
[02:37] <seb128> ogra: ah ok, so it works? what was wrong before?
[02:37] <tseng> ogra: :D
[02:37] <Mithrandir> seb128: and it doesn't dlopen the soname, but the unversioned one?
[02:37] <tseng> ogra: thanks for the hard work
[02:37] <seb128> Mithrandir: no, the .so
[02:37] <seb128> ups, misred
[02:37] <seb128> misread
[02:37] <ogra> seb128, dunno, i think it required a versioned dependency on something ... hughsie is offline atm, i'll ask him about it later 
[02:37] <seb128> right, it opens the unversioned one
[02:38] <ogra> the rebuild just worked
[02:38] <seb128> Mithrandir: but you are right, that's ugly, I should patch to open the versionned and Recommends the binaries instead of the -dev for them
[02:38] <seb128> ogra: weird, but nice that the update has been done
[02:38] <Mithrandir> seb128: thanks. :-)
[02:39] <seb128> np ;)
[02:39] <ogra> seb128, yep, very weird, i cant imagine what caused it ... but building it 10 days ago resulted in non working binaries ... building the same today worked
[02:39] <seb128> ogra: 
[02:39] <seb128> $ grep gmenu gnome-screensaver-2.15.3/src/gs-job.c | wc -l
[02:39] <seb128> 22
[02:40] <seb128> ogra: src/gs-job.c:   themes_tree = gmenu_tree_lookup ("gnome-screensavers.menu", GMENU_TREE_FLAGS_NONE);
[02:40] <seb128> ogra: must be some gmenu item parsing the .desktop
[02:40] <ogra> hmm, but it should read from "gnome-screensavers.menu" as i understand it
[02:40] <seb128> ogra: might be some performances work to do on it :)
[02:40] <ogra> yeah
[02:41] <ogra> first lest me look if gnome-screensavers.menu is correct :)
[02:42] <ogra> hmm, according to that code we could also drop the --xscreensaver-* options from rules ... 
[02:48] <mvo> hm, strange things after my dist-upgrade with X, it /etc/X11/X points to /bin/true
[02:49] <Hobbsee> hi mvo 
[02:49] <mvo> hi Hobbsee
[02:51] <zul> mvo: yeah that is kind of weird
[02:52] <pitti> mvo: would you object if I just close bug 47592?
[02:52] <Ubug2> Malone bug 47592 in cupsys "breezy->dapper upgrade failure on amd64" [Medium,Unconfirmed]  http://launchpad.net/bugs/47592
[02:52] <ogra> mvo, you picked a bad time for the upgrade :) rodarvus is just switching us over to 7.1
[02:55] <rodarvus> err
[02:55] <rodarvus> I didn't touched /usr/X11/X
[02:56] <ogra> hmm
[02:56] <mvo> pitti: no, go ahead
[02:57] <rodarvus> (not now, at least :) )
[02:57] <robertj> could someone please remind the inhabitants of the mailing list that the list has a lot of traffic anyway and that it's not appreciated when people go on about things that they have no understanding about at all? I'm quite sick of the me-tooing on the list, especiall RE: Avahi
[02:57] <rodarvus> if someone did that, it must have been ocurred about 10 days ago
[02:57] <rodarvus> (so, not very likely)
[02:59] <ogra> yeah, -devel is a pain recently ...
[03:03] <hyperactivecrond> has the installer for knot-1 crashed on x86 for anybody else besides me here?
[03:04] <rodarvus> quite likely :D
[03:04] <hyperactivecrond> i can't seem to find a bug report for it on lp.net
[03:05] <ogra> seb128, what do you think about patching fusa out of g-s-s ad run gdmflexiserver directly ? 
[03:05] <hyperactivecrond> rodarvus: yes it dies close to its finish
[03:05] <rodarvus> hyperactivecrond: please check if this is one of the known problems of the knot-1 livecd, if not, search for bugs like this on LP
[03:05] <ogra> fusa is very confusing since it doesnt prefill the gdm login ... i find it always very confusing that yu can select a user and dont gain anything from that 
[03:06] <rodarvus> finally if they are not there, please report the bug you had
[03:07] <rodarvus> hyperactivecrond: https://wiki.ubuntu.com/DapperReleaseNotes/UbiquityKnownIssues
[03:07] <ogra> seb128, alternatively a --user option to gdmflexiserver that just prefills the username field would work too ...
[03:08] <hyperactivecrond> ugh maybe becuase my /boot is in an xfs partiton :\ duh
[03:09] <hyperactivecrond> alright no bug here then with ubiquity...
[03:09] <hyperactivecrond> i'm going to try with a reiser / partition.. that might get it to install
[03:09] <hyperactivecrond> and if not, bug reports away
[03:17] <wasabi> cant believe this zeroconf thread is still going
[03:18] <Kamion> the XFS thing should be fixed
[03:18] <wasabi> rodarvus: update-font-dirs was breaking. Was trying to update a non existant dir.
[03:18] <Kamion> hyperactivecrond: please just file a bug report about that ubiquity problem regardless
[03:19] <Kamion> I'd much rather get duplicates than not find out about the bug at all
[03:19] <hyperactivecrond> Kamion: it's already listed in the issues
[03:19] <Kamion> hyperactivecrond: XFS?
[03:19] <seb128> ogra: why do you want to do that?
[03:19] <hyperactivecrond> Kamion: will do
[03:19] <hyperactivecrond> Kamion: yes
[03:19] <Kamion> hyperactivecrond: that is supposed to be fixed in knot-1. therefore, I want to know about it when it still fails
[03:19] <ogra> seb128, because it doesnt work intuitive
[03:19] <hyperactivecrond> oh ok i will do that then Kamion
[03:19] <Kamion> i.e. the partitioner is meant to just disallow XFS /boot
[03:20] <seb128> ogra: there is a list of user and you can just pick one, no?
[03:20] <ogra> seb128, if you click switch user in the locked screensaver it opens a userlist ... if you select a user there and move on you get a gdm login but not the user prefilled
[03:20] <hyperactivecrond> What would be useful for ubiquity though would be the option to change the FS type
[03:20] <hyperactivecrond> it currently does not allow one to change the partition type.. or reformat as a different FS
[03:20] <ogra> seb128, yes, sure, but selecting one doesnt result in anything :)
[03:20] <gnomefreak> Kamion: the XFS is same with mac/yaboot?
[03:21] <hyperactivecrond> Kamion: i'll also attach fdisk -l 's output for my partition table
[03:21] <ogra> seb128, as long as it doesnt work as expected its just one unecessary click i have to do ... 
[03:21] <Kamion> gnomefreak: sort of
[03:21] <ivoks> howdy
[03:21] <Kamion> hyperactivecrond: the logs requested in the crash message are all I care about
[03:22] <hyperactivecrond> Kamion: ok will do
[03:22] <Kamion> you can attach other random stuff if you like but I'll ignore it :)
[03:22] <zul> Hobbsee: a mental filter is a nice thing to have as well
[03:22] <Hobbsee> zul: that is true.
[03:22] <Kamion> gnomefreak: XFS breaks with yaboot at present due to a yaboot bug, although there's a fix for that in Debian which we'll get soon
[03:22] <seb128> ogra: I think there is some bug about it, gdm needs a --user option
[03:23] <hyperactivecrond> Kamion: i'm installing right now...
[03:23] <seb128> gdmflexiserver rather
[03:23] <pygi> hey ivoks
[03:23] <gnomefreak> ok im gonna look for the bug that i am thinking of
[03:23] <Kamion> hyperactivecrond: please make sure to grab those logs before you reboot
[03:23] <hyperactivecrond> btw when one tries to install xchat-gnome in knot-1 find complains about hard link count not being correct
[03:23] <hyperactivecrond> Kamion: will do
[03:24] <ogra> seb128, yes, either is fine ...
[03:24] <Kamion> hard link count is a known weirdness with squashfs/unionfs; it's no big deal
[03:24] <ogra> seb128, as i said above :)
[03:24] <seb128> ogra: http://bugzilla.gnome.org/show_bug.cgi?id=342100
[03:24] <Ubug2> Gnome bug 342100 in Applet "switch user should pre-fill the username for gdm" [Normal,New]  
[03:24] <hyperactivecrond> Kamion: ok just making sure
[03:24] <ogra> ah cool
[03:24] <ogra> Click System  lock screen.
[03:25] <ogra> hm, nifty ... whats the keycode for that triangle ?
[03:25] <hyperactivecrond> Is the splash screen supposed to look ghetto in knot?
[03:25] <Kamion> yes
[03:25] <Kamion> it's a test card
[03:26] <Mithrandir> U+25BA BLACK RIGHT-POINTING POINTER
[03:26] <seb128> ogra: gucharmap, open the search and copy the char
[03:26] <Mithrandir> seb128: or unicode(1)
[03:26] <hyperactivecrond> Kamion: ok just making sure that its not a bug with usplash
[03:26] <ogra> Mithrandir, thanks )
[03:26] <ogra> :)
[03:26] <rodarvus> wasabi: strange, this bug was supposed to be fixed
[03:26] <rodarvus> (actually, it was supposed to exist only for a few days, during transition)
[03:27] <ogra> rodarvus, i told you abuout it ...
[03:27] <rodarvus> *nods* you did :)
[03:27] <ogra> rodarvus, and you told me that we'd get a new version with 7.1 anyway :) 
[03:27] <ogra> so just mae sure its fixed there :)
[03:27] <ogra> *make
[03:28] <sladen> keybuk: do we really have to put  TEST CARD  in really big letters for people to realise?
[03:28] <Kamion> sladen: yes :-(
[03:28] <ogra> wow, i wonder where that gnome-screensavers.menu.in came from its as wrong as it can be
[03:28] <tseng> sladen: i kind of hoped that Keybuk's mail at the begining of the cycle would do it
[03:28] <Kamion> sladen: (Keybuk's not here)
[03:29] <tseng> sladen: so much for that
[03:29] <tseng> we are unbroken enough to get your "crack-o-the-day" kids testing now
[03:29] <hyperactivecrond> i'm not sure if this a gnome bug but shouldn't 'lock screen' be seperate from the 'quit' dialog box?
[03:29] <wasabi> rodarvus: Eh, well, as of last night, fully apt-get updated, it happened.
[03:29] <tseng> they didnt get the memo.
[03:29] <wasabi> rodarvus: I fixed it by just killing those parts of the update-font-dirs script
[03:29] <ogra> hyperactivecrond, you mean in a separate popup box ?
[03:29] <wasabi> update-fonts-alias failed too for the same reason I believe.
[03:29] <hyperactivecrond> ogra: in a seperate 'system' menu entry
[03:30] <rodarvus> wasabi: I'll take a good look at it today, thanks for the report!
[03:30] <ogra> nope
[03:30] <ogra> that was dropped long ago
[03:30] <hyperactivecrond> well that's a gnome quirk then ok
[03:30] <ogra> at the beginning of dapper somewhere
[03:30] <wasabi> Gnome-screensaver locking even though it's set not to lock in the panel known?
[03:31] <ogra> wasabi, on which occasion ? by pain screensaving or after suspend ? 
[03:31] <hyperactivecrond> i dont know if this would be a place for suggestions but maybe we should put xchat-gnome in the knot cds so that people can access this channel, rather than having to add the pkg first?
[03:31] <ogra> *plain
[03:32] <Mithrandir> hyperactivecrond: you can irc using gaim
[03:32] <wasabi> plain.
[03:32] <wasabi> It's a probably for me for a second reason: it won't let me unlock. ;0
[03:32] <Kamion> xchat-gnome was intentionally removed from desktop in the dapper cycle
[03:32] <hyperactivecrond> Mithrandir: i completely forgot about that. +1 branfart for me
[03:32] <wasabi> s/probably/problem/
[03:33] <hyperactivecrond> s/bran/brain
[03:33] <ogra> wasabi, hmm ... are you sure your account is ok ? do you use any weird keymap setting or something ?
[03:34] <wasabi> Oh. I'm quite sure my pam setup is breaking that part.
[03:34] <wasabi> xscreensaver wouldn't let me unlock either.
[03:34] <wasabi> Either way, I can't seem to turn it off. ;)
[03:35] <ogra> can you look in your gconf-editor if there are any left over settings under /apps/gnome-screensaver (i.e. ones with no key owner or something)
[03:36] <ogra> (they should all be owned by g-s-s)
[03:36] <wasabi> dpms_suspend
[03:36] <wasabi> that's it.
[03:36] <ogra> hmm, thats moved to g-p-m since ages ...
[03:36] <wasabi> lock_enabled is false
[03:36] <ogra> can you change the values (i.e. check/uncheck lock_enabled)
[03:37] <wasabi> Yeah. It's false.
[03:37] <wasabi> But I still woke up this morning and had to kill it because it was locked.
[03:37] <hyperactivecrond> Kamion: crashed. right now. during 'installing bootloader'
[03:37] <hyperactivecrond> ..and i'm filing a bug report
[03:38] <ogra> wasabi, hmm ...
[03:38] <Kamion> ok
[03:38] <ogra> wasabi, are you sure you only run g-s-s and dont have the x-s-s daemon installed/running
[03:39] <wasabi> Yes.
[03:41] <ogra> is /apps/gnome-power-manager/lock_use_screensaver_settings probably unset but /apps/gnome-power-manager/lock_on_blank_screen set ?
[03:42] <wasabi> lock_on_blank is.
[03:42] <ogra> yep .. thats it then ...
[03:42] <wasabi> that's probably it.
[03:42] <ogra> :)
[03:42] <wasabi> where the hell is the setting in the UI?
[03:42] <ogra> there is none ...
[03:42] <wasabi> super. ;)
[03:42] <doko> mvo: dselect-upgrade works now
[03:43] <wasabi> So the whole "lock the screen" option in the g-s-s settings is pretty useless.
[03:43] <hyperactivecrond> what is the package for ubiquity? ubiquity?
[03:43] <ogra> as long as that default is set in g-p-m yes
[03:43] <wasabi> Ahh. Well. Something should obviously be done about that. ;)
[03:44] <wasabi> One of these days I'll fix teh actual unlocking problem, too.
[03:44] <Kamion> hyperactivecrond: yes
[03:44] <ogra> well, there were a lot of bugs for either side ... i think Kinnison just made *a* decision
[03:45] <ogra> but while it makes sense to lock on hibernate and suspend by default, we should probably leave this one off
[03:46] <hyperactivecrond> Kamion: just put the contents of the files it requests to be posted in the "further information, etc." section?
[03:49] <Kamion> hyperactivecrond: file the bug, then use the "Add Attachment" link for each file
[03:49] <Guard] [an> hello
[03:50] <ogra> meh
[03:50] <mvo> doko: thanks
[03:50] <Guard] [an> i'm not sure it's the good place to ask, but still, where could i find the api reference for X11 ?
[03:50] <Guard] [an> i need to learn how to code for X, without using GTK or QT
[03:51] <ogra> seb128, dholbach, i cant copy/paste more than 50 lines from gnome-terminal anymore neither by select+middleclick, nor by shift+ctrl+c/v
[03:51] <ogra> known ?
[03:52] <ogra> s/50/~50/ (didnt count them)
[03:53] <ogra> counted ... its 30
[03:53] <hyperactivecrond> ugh great... i just put everything together as one
[03:53] <hyperactivecrond> https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/53642
[03:54] <Ubug2> Malone bug 53642 in ubiquity "When installing with /boot as an XFS partition, the installer crashes" [Untriaged,Unconfirmed]  
[03:56] <Kamion> don't worry about it
[03:56] <hyperactivecrond> Kamion: alright... i'm going to manually set the partition types with cfdisk then install
[03:57] <Kamion> should be no need for that
[03:57] <hyperactivecrond> Kamion: my / is an xfs partition.
[03:57] <seb128> ogra: not by me, but that's rather dholbach who is maintaining that package
[03:57] <Kamion> hyperactivecrond: create an ext3 /boot, then
[03:57] <hyperactivecrond> Kamion: alright..
[03:57] <ogra> seb128, oki
[03:58] <Kamion> fiddling with partition types will not help you
[03:58] <hyperactivecrond> Kamion: i haven't used a /boot in a while.. 320.79 mb should be enough?
[03:59] <Kamion> hyperactivecrond: should be more than enough yes
[04:03] <Kamion> BenC: we have a problem with the libata transition
[04:04] <Kamion> BenC: the installer's mkswap has never set uuids on swap partitions
[04:04] <dholbach> ogra: gnome bugs 348038 (vte), fixed in CVS
[04:04] <Ubug2> Gnome bug 348038 in VteTerminal "Cannot mark and copy text larger than visible terminal area" [Normal,Resolved: fixed]  http://bugzilla.gnome.org/show_bug.cgi?id=348038
[04:04] <ogra> dholbach, thanks :)
[04:04] <Kamion> BenC: I can fix this for installs going forward, but for the upgrade process, we're going to have to mkswap again (and be VERY CAREFUL about possible hibernate images etc.)
[04:05] <hyperactivecrond> I shall see if that grub bug while dealing with windowsXP dualbooting is still around, too
[04:06] <hyperactivecrond> providing this install works
[04:18] <hyperactivecrond> Kamion: it worked this time with /boot as ext3
[04:20] <siretart> Keybuk: pong
[04:21] <Keybuk> siretart: so, err, what's with /etc/rc0.d/S15wpa-ifupdown
[04:21] <Keybuk> ie. what the hell is it doing?
[04:22] <Kamion> 15:03 < Kamion> BenC: we have a problem with the libata transition
[04:22] <Kamion> 15:04 < Kamion> BenC: the installer's mkswap has never set uuids on swap partitions
[04:22] <Kamion> 15:04 < Kamion> BenC: I can fix this for installs going forward, but for the upgrade process, we're going to have to mkswap again (and be VERY CAREFUL about possible hibernate images etc.)
[04:22] <Kamion> Keybuk: ^--
[04:22] <Mez> Kamion, will you be at LRL this year?
[04:22] <Kamion> Mez: no, afraid not
[04:22] <pitti> Keybuk: dhcp3-server can also drop it's stop script at 0 and 6; do you already have a pending package or shall I care for this?
[04:23] <pitti> Keybuk: ... and festival
[04:23] <Mez> Kamion: shame :(
[04:23] <pitti> Keybuk: ... and klogd
[04:24] <Keybuk> pitti: festival and klogd should be in the archive (source wise)
[04:24] <Keybuk> I didn't touch dhcp3-server because it wasn't a dep of ubuntu-desktop, feel free to do that one yourself
[04:24] <pitti> Keybuk: ah, cool
[04:24] <BirthdayHobbsee> Kamion: thanks for some of the syncs :)
[04:24] <ogra> iwj, ping ... arent you a iptables specialist ? i'm looking for a hint
[04:24] <Keybuk> Kamion: hmm, interesting
[04:24] <Kamion> BirthdayHobbsee: no worries
[04:24] <Kamion> and happy birthday, it appears ;)
[04:25] <BirthdayHobbsee> Kamion: hehe, thankyou.  there are still some more that i'm waiting on :)
[04:25] <hyperactivecrond> Grub now plays nicely with windowsxp
[04:25] <BirthdayHobbsee> Kamion: hence the "some" bit :)
[04:25] <ogra> BirthdayHobbsee, birthdays ?
[04:25] <Keybuk> Kamion: if the swap is active, there won't be any hibernate image in it :)
[04:25] <BirthdayHobbsee> ogra: hmmm?
[04:25] <ogra> BirthdayHobbsee, we hope so :)
[04:25] <ogra> BirthdayHobbsee, "  there are still some more that i'm waiting on :)"
[04:26] <hyperactivecrond> Kamion: iirc this is already reported, /etc/apt/sources.list only contains edgy-security
[04:26] <Kamion> BirthdayHobbsee: yeah, I was just doing a few of them because rodarvus had an urgent pair
[04:26] <Kamion> hyperactivecrond: yep, already reported thanks
[04:26] <BirthdayHobbsee> ogra: ah, right, yeah
[04:26] <ogra> :)
[04:26] <BirthdayHobbsee> Kamion: if you could put thru dar in your next batch, i'd appreciate it - then i can finish off kdar.
[04:27] <Kamion> Keybuk: does swapon check for the hibernate signature?
[04:27] <hyperactivecrond> Kamion: is it safe to put just edgy instead of edgy-security in /etc/apt/sources.list?
[04:28] <Kamion> hyperactivecrond: "instead of" => "as well as"
[04:28] <hyperactivecrond> Kamion: never mind
[04:28] <Keybuk> Kamion: I assume so, you can't swapon a swap partition that's still got a hibernate thingy in it
[04:28] <hyperactivecrond> Kamion: can i see a working /etc/apt/sources.list for edgy that contains something other than security?
[04:29] <Kamion> Keybuk: right, just saying then that we need to check whether the swap is active as well as just whether it's in sources.list
[04:29] <Kamion> hyperactivecrond: ok, come on dude, check the bit about support in the topic
[04:29] <Kamion> sources.list fragments are trivial to find
[04:29] <Mez> !tell hyperactivecrond about source-o-matic
[04:30] <hyperactivecrond> Kamion: i heartily apologize
[04:30] <hyperactivecrond> Mez: thx
[04:30] <Keybuk> Kamion: fstab ;)
[04:31] <Kamion> Keybuk: er right :)
[04:31] <Kamion> thinking about two things at once
[04:31] <Mez> hyperactivecrond, did that actually send you anything ? it used to confirm it with me
[04:31] <Mez> wqhen it sent something
[04:31] <Kamion> Mez: we don't have the bot here
[04:31] <Kamion> (deliberately)
[04:32] <Mez> Kamion: ah
[04:32] <Mez> whoops
[04:44] <BenC> Kamion: how hazardous is that mkswap transition?
[04:46] <bddebian> Heya
[04:47] <Kamion> BenC: it's *probably* ok with the check Keybuk suggested (is the swap active?)
[04:48] <Keybuk> the only worry is that an upgrade isn't the time to call "swapoff" ?
[04:49] <BenC> so it's something that'll be done on reboot?
[04:49] <BenC> since the UUID stuff isn't need till the next reboot, that sounds safe enough
[04:50] <Kamion> oh, huh, that's awkward
[04:50] <BenC> actually, no it isn't
[04:50] <Kamion> we'd need to check for the hibernate signature by hand rather than relying on whether the swap is currently active
[04:50] <BenC> if the driver goes hda->sda, then it's too late
[04:51] <Keybuk> right, swap devices a little more difficult
[04:52] <Keybuk> Kamion: ?
[04:52] <BenC> so you can't change the UUID of a swap partition while it's in use, like you can for ext2/ext3?
[04:53] <Kamion> Keybuk: we need to ensure not to re-mkswap something that contains a hibernate image
[04:53] <Keybuk> Kamion: right, if it's active, that's the clue -- no?
[04:53] <Keybuk> also you can't make a UUID for a swap partition, no?  I thought they could only have labels
[04:53] <Kamion> but if we can't do the mkswap until reboot, it won't be active any more
[04:53] <Kamion> they can have uuids too, there's a slot in the v1 swap area header
[04:53] <Keybuk> we can't do the mkswap after reboot, because the drive assignments will have changed by that point
[04:54] <Kamion> if we could change it while it's in use, that would be ideal I guess
[04:54] <Keybuk> yeah, I wonder whether we could just edit the active swap partition ;)
[04:54] <Keybuk> I don't see why not
[04:54] <fabbione> if they have space in the header area
[04:54] <iwj> ogra: I can probably help you with iptables, yes.
[04:54] <Kamion> two things: (a) will the kernel just overwrite it again (i.e. does it remember the existing header and blat it back out), (b) can we safely change UUID on an S1SUSPEND area too
[04:54] <fabbione> i don't see why just change it on the fly
[04:55] <Keybuk> Kamion: I don't know the answer to these two things ... what does an S1SUSPEND area look like?
[04:55] <Keybuk> does it replace the swap header, or go after it?
[04:55] <BenC> interesting, my swap has a UUID
[04:55] <Keybuk> BenC: how did you find out?
[04:55] <Kamion> Keybuk: the problem is probably that the UUID goes after the first page
[04:55] <Kamion> of the swap
[04:56] <fabbione> Keybuk: what will happen to special devices like RAID when you change the underlay device from hd* to sd*?
[04:56] <BenC> ls /dev/disk/by-uuid/
[04:56] <Keybuk> fabbione: no idea
[04:56] <BenC> fabbione: LVM will handle it nicely
[04:56] <fabbione> is somebody going to test this stuff before hand?
[04:56] <fabbione> BenC: LVM i know.. what about RAID
[04:56] <BenC> you'll have to edit the md config by hand
[04:56] <Kamion> I'm not sure, but I have a suspicion that swsusp uses the area that swap uses for the UUID for something else
[04:57] <Kamion> Keybuk: vol_id can parse it too
[04:57] <ogra> iwj, i want to build a transparent content filter ... i have an OUTPUT nat rule that forwards everything from port 80 to another port ... i know there is a possibility to exclude by pid s the locally running content filter would be excluded from that port 80 rule, do you know any example pages where i could read up about that pid thing ?
[04:57] <iwj> You mean an intercepting proxy ?
[04:57] <Keybuk> Kamion: right, we'll have to find out how these partitions are structured
[04:57] <fabbione> BenC: md config isn't of any use anymore.. the devices are autodiscovered via md magic sb
[04:57] <Keybuk> and find someone with a laptop that has working suspend
[04:57] <Keybuk> fabbione: autodiscovered devices should still work. no?
[04:57] <BenC> fabbione: then the magic should still work
[04:57] <iwj> I don't think you want to exclude by pid.  You want to exclude by local username, surely ?
[04:57] <ogra> i mean a locally running transparent proxy without proxying but content filter rules :)
[04:58] <Keybuk> fabbione: it's my understanding that they all just look for partitions with a given signature -- which will work fine
[04:58] <BenC> fabbione: if it autodiscovers based on something other than hda/sda naming
[04:58] <fabbione> Keybuk: i need to check, but i think RAID sb has hardcoded info of the other drives in the RAID
[04:58] <ogra> well, then the app would need a own user, but that would work as well, yes
[04:58] <iwj> (Also, please reconsider whether an intercepting poxy is the right answer.  They're generally a bad idea.)
[04:58] <Keybuk> fabbione: if it has hardcoded kernel device names, that will need to be fixed
[04:58] <iwj> ogra: check out iptables(8) and --uid-owner.
[04:58] <ogra> iwj, its for ltsp servers that have no separate box for content filtering (its also not proxying, only a fiter)
[04:58] <iwj> You almost certainly want that instead of eg --pid-owner.
[04:59] <ogra> iwj, thanks ! thats the hint i was after :)
[04:59] <Keybuk> let's move this into #ubuntu-kernel, because there are too many conversations going on at once
[04:59] <iwj> If you want to enforce the use of the proxy, better to block port 80 rather than intercept it.
[04:59] <BenC> Kamion: if it overwrites swap partitions UUID, then we are screwed anyway
[04:59] <BenC> so either the UUID is good, or this whole excecise is futile
[05:00] <fabbione>         __u32 major;            /* 1 Device major number                      */
[05:00] <fabbione>         __u32 minor;            /* 2 Device minor number                      */
[05:00] <fabbione> it stores info on major/minor for each device on each disk
[05:00] <fabbione> at least this is according to the sb struct
[05:00] <fabbione> how it's handled is something that needs to be verified
[05:00] <ogra> iwj, i want it transparent ...
[05:01] <BenC> yeah, because the device majors for hd and sd are different
[05:01] <ogra> so users dont even have the ability to change proxy settings at all
[05:01] <iwj> ogra: You mean you want it intercepting.  Why ?
[05:01] <iwj> You can enforce the use of the proxy by blocking port 80.
[05:01] <ogra> iwj, sure, but that means additional setup for the sysadmin
[05:02] <ogra> since he will need to point the proxy settings to the proxy port then
[05:02] <iwj> Err, you mean by default it will be set up not to use a proxy and the interception will get it ?
[05:02] <ogra> yep
[05:02] <iwj> Do we not have a way of setting the proxy settings globally ?
[05:02] <ogra> totally transparent
[05:02] <BenC> Kamion, Keybuk: I was able to run "sudo mkswap -L `uuidgen` /dev/hda4" on an active swap partition, and it didn't redo-the swap
[05:02] <ogra> sure we have ... but it should hook in at a lower level 
[05:02] <iwj> No, `transparent' is the wrong word.
[05:02] <iwj> You mean `intercepting'.
[05:02] <ogra> ok
[05:03] <Keybuk> BenC: "redo the swap" ?
[05:03] <iwj> I know marketroids use the word `transparent' for this because it sounds more friendly.
[05:03] <ogra> for the sysadmin its transparent behavior :)
[05:03] <iwj> But actually it's the opposite of transparent.
[05:03] <BirthdayHobbsee> Keybuk: any reason why the -sa flag wouldnt be in merge-genchanges and merge-buildpackage, for the MoM scripts, for some merges?
[05:03] <BenC> Keybuk: as in erase it
[05:03] <ogra> the thing is that if the proggy is installed it should just work without configuration ...
[05:03] <Keybuk> BenC: ok, so you can tune a swap on the fly?
[05:04] <ogra> (on either side)
[05:04] <Keybuk> BenC: what happens if you change the version? :p
[05:04] <BenC> Keybuk: it would seem so
[05:04] <Keybuk> BirthdayHobbsee: if the upload shouldn't need it because the orig.tar.gz should already be in the archive
[05:04] <BenC> Keybuk: that's probably not possible :)
[05:04] <BirthdayHobbsee> Keybuk: right, okay, that's what i thought
[05:05] <iwj> RFC2616 `A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification'
[05:05] <Keybuk> BirthdayHobbsee: sometimes it gets it wrong, dunno why
[05:05] <BirthdayHobbsee> Keybuk: yeah, that's what i was thinking....
[05:05] <iwj> ogra: See RFC3143 for why you don't want an intercepting proxy.
[05:06] <iwj> `Known HTTP Proxy/Caching Problems'
[05:07] <iwj> ogra: See in particular 3143 s2.2.1.
[05:07] <iwj> `if the proggy is installed it should just work without configuration'> You mean it should do the configuration.
[05:07] <iwj> Is there a spec for this ?
[05:08] <iwj> `Solution(s)       Eliminate the need for interception proxies and IP spoofing, ...'
[05:09] <ogra> iwj, nope its a SoC project ... and you cant do it differently on a ltsp server ...
[05:09] <iwj> Why can't you do it differently ?
[05:09] <ogra> at least if you dont have a second machine
[05:09] <iwj> What's the second machine got to do with it ?
[05:09] <iwj> I'm not suggesting you should have a second machine.
[05:10] <ogra> well, thast the other way to set up a so called "transparent proxy"
[05:10] <iwj> I'm suggesting you should reconfigure the UA to know to talk to the proxy; if you want to enforce use of the proxy you can block other processes' attempts to connect to port 80.
[05:10] <iwj> I'm saying you DON'T WANT AN INTERCEPTING PROXY
[05:10] <iwj> ARE YOU LISTENING TO ME ?
[05:10] <ogra> yes
[05:10] <iwj> So what is `thast the other way to set up a so called "transparent proxy"
[05:10] <iwj> '
[05:11] <iwj> That's not relevant at all.
[05:11] <iwj> I know how one might set up an intercepting poxy on one or on two machines.
[05:11] <iwj> I'm saying you shouldn't do it.
[05:11] <iwj> You should block, not intercept, port 80.
[05:11] <iwj> And reconfigure the browser.
[05:11] <ogra> well the usual reciepe is to have a GW with nat rules where dansguardian or something similar runs ...
[05:12] <iwj> I'm saying you DON'T WANT AN INTERCEPTING PROXY
[05:12] <ogra> forwarding port 80 to something internally
[05:12] <iwj> I'm saying you DON'T WANT AN INTERCEPTING PROXY
[05:12] <pygi> iwj: can you please stop shouting? thanks :)
[05:12] <ogra> i'm outlining what our userbase falls back to
[05:12] <iwj> ogra: I'm saying you don't want an intercepting poxy.  Are you listening to me ?  Do you understand what I mean ?
[05:13] <ogra> iwj, yes, and i dont want to have blocked settings in the ui
[05:13] <iwj> Our aim is to produce sensible working setups, right ?  Discussion of crazy semi-broken setups is not interesting.
[05:13] <lifeless> iwj++
[05:13] <lifeless> interception is evil.
[05:13] <ogra> i'D have to disable the ability to change the proxy settings if i do it your way
[05:13] <lifeless> please dont make baby jebus kill butt plugs
[05:13] <lifeless> ogra: that does not follow
[05:14] <ogra> lifeless, well, some thousands of school sysadmins would disagree 
[05:14] <Kamion> ogra: transparent proxies aren't. They cause all kinds of subtle problems that school sysadmins probably shrug their shoulders and try to ignore.
[05:14] <lifeless> ogra: I'm spoken to god knows how many of them on IRC and email w.r.t. squid and interception
[05:14] <ogra> its what they use everywhere 
[05:14] <lifeless> ogra: and its broken everywhere!
[05:14] <Kamion> that's not a good reason to perpetuate it
[05:15] <Kamion> in order for a proxy to work correctly, the client needs to know that it is talking to a proxy
[05:15] <ogra> i'm still not taking about a proxy at all ...
[05:15] <ogra> but well
[05:15] <lifeless> HTTP does not define semantics for interception. there have been uncountable many bugs related to interception-caching, and there will be uncountable more
[05:15] <ogra> i'll look into it
[05:16] <lifeless> if you hijack port 80, its interception
[05:16] <ogra> i wsnt arguing that :)
[05:16] <ogra> *wasnt
[05:16] <iwj> uncountable many bugs> RFC3143 (from June 2001) is just the start of it.
[05:16] <lifeless> if you give it to anything other than the requested port, and the thing you give it to may honour the request - then its a proxy
[05:18] <wasabi_> Hmm. Cool. Fixed up swapd.
[05:18] <wasabi_> It now creates one swap file minimum, and defaults to autodetecting the ram size.
[05:20] <sladen> so.  We all in a agreement that Transparent Proxies are teh evil now?  Or perhaps so more shouting and burning of small children would help.
[05:20] <lifeless> iwj: yahuh.
[05:21] <lifeless> it was surprising to see it even being a subject for debate here. 
[05:21] <lifeless> I *thought* we were all sane.
[05:23] <lifeless> gnight
[05:23] <BirthdayHobbsee> night lifeless 
[05:23] <geser> is it possible to still use file-rc (an alternative to sysv-rc) on edgy?
[05:24] <iwj> ogra: You don't need to disable the ability to change the proxy settings.  You can just firewall out port 80 so that if they change the proxy settings it stops working completely.
[05:25] <ogra> iwj, yes, that apparently what i have to do ... even the traffic isnt even touched by the app ...
[05:26] <ogra> *thats
[05:26] <iwj> I'm afraid I can't make sense of that.
[05:27] <sladen> ogra: "[x]  block direct web connections to the Internet (prevent proxy bypassing)"
[05:28] <ogra> it works like a pipe ... delays the answer, recieves what the user wanted, does a bayesian check, if the target is not worth to be fitered it removes the delay and pipes the traffic ...
[05:29] <ogra> thats all ... no rewriting of headers or the like ...
[05:30] <iwj> ogra: Have you read RFC3143's comments on interception ?  If not go away and do so and come back when you understand.  If you don't think you want to or can understand then take the advice of people who do ?
[05:30] <ogra> i'm just fearing that if we dont have the buzzword "transparent" anywhere teachers wont adopt it... but i'll try other solutions ...
[05:30] <iwj> You can use the buzzword `transparent' whenever you like.  Remember that it's a marketing term and can mean whatever you like.
[05:31] <ogra> yes, i know ... but it has certain expectations attached to it
[05:31] <ogra> like you dont have to adjust anything :) but i'll find a way without interception ...
[05:39] <Kamion> ogra: doesn't this content filter ever deny requests?
[05:40] <ogra> it drops the traffic and puts a "access denied " page in place ...
[05:40] <ogra> its very minimalistic
[05:40] <Kamion> ogra: then it is an intercepting proxy within the meaning of RFC3143
[05:40] <ogra> ok
[05:40] <Kamion> it doesn't matter how small the changes it makes are
[05:40] <Kamion> 200 -> 403 is a pretty big change all by itself :-)
[05:41] <ogra> yep
[05:41] <ogra> i'll go sladens way i guess ...
[05:42] <bddebian> doko: around?
[05:42] <ogra> even though its not what the teachers want ...
[05:43] <Kamion> you're making the mistake of taking requirements at the wrong level
[05:43] <Kamion> the requirement is not <particular technical implementation>
[05:43] <Kamion> the requirement is <particular result for users>
[05:43] <ogra> nope, its marketing driven
[05:43] <ogra> yeah
[05:43] <Kamion> you can write whatever you like in marketing, as iwj says
[05:43] <Kamion> "transparent configuration of content filter"
[05:44] <ogra> heh
[05:44] <Kamion> also, marketing can be tweaked
[05:44] <bddebian> Am I correct in understanding the Python policy that if it uses Python modules, it still needs the versioned python dependencies? (i.e. usr/lib/python2.x)?
[05:44] <Kamion> marketing expectations I mean
[05:45] <Kamion> if you do most of what people want, they will give you a bit more slack if you're different in one particular area, and eventually that approach may become the standard and they'll start asking others why they don't do it that way
[05:45] <ogra> yes ... we'll see how it works out ... as long as i dont have to install squid on already extrabusy servers i'm fine
[05:45] <Kamion> c.f. Ubuntu's sudo configuration, which was very unusual in the Linux world when we first did it
[05:45] <ogra> but its userfriendly ...
[05:46] <ogra> this is the exact opposite t the existing used setups ... from a userfriendlyness POV
[05:46] <doko> seb128, dholbach: in unstable libgnomevfs2-dev depend on libbonobo2-dev, but not in edgy, leading to an OOo build failure. please fix or I'll rename the package to gopenoffice.gorg
[05:46] <jdub> ogra: not to many traditional unix users
[05:46] <Kamion> ogra: only if you don't put the effort in to make it user-friendly. :-)
[05:46] <ogra> jdub, i'm talking about teachers 
[05:46] <Kamion> ogra: and ultimately, not randomly breaking people's web browsing is user-friendly
[05:46] <dholbach> doko: we're happy that gnomevfs doesn't use bonobo anymore - the situation is 'fixed'
[05:47] <jdub> ogra: (re: sudo)
[05:47] <ogra> Kamion, yes i uderstand and agree
[05:47] <ogra> jdub, ah, right ...
[05:47] <doko> dholbach, seb128: will that be changed in unstable as well?
[05:47] <dholbach> doko: that's a change in gnome (gnomevfs) 2.15
[05:47] <dholbach> doko: yes, once they use 2.15 too
[05:52] <bddebian> Do be do be dooo
[05:53] <seb128> doko: when GNOME 2.16 is packaged, which might be after etch
[05:54] <seb128> doko: gnome-vfs uses dbus instead of libbonobo now
[05:54] <seb128> doko: anyway, if OOo uses libbonobo it should have an explicit Build-Depends on it and don't expect that some other lib grab it 
[06:07] <pitti> Keybuk: do you have a script anywhere (from MoM) that takes two changelogs and merges them together? svn merge produces nothing but a mess :(
[06:07] <Keybuk> I have some python
[06:08] <Keybuk> pitti: merge_changelog() in produce-merges.py
[06:08] <Keybuk> sftp://chinstrap.ubuntu.com/home/warthogs/archives/scott/merge-o-matic
[06:09] <pitti> Keybuk: thanks
[06:21] <dholbach> can somebody get jokosher out of NEW? :-)
[06:33] <geser> does anybody know if it should be possible to use file-rc (an alternative to sysv-rc) on edgy?
[06:33] <geser> because some packages start depending on a specific version of sysv-rc and file-rc and sysv-rc conflict
[06:33] <ogra> fabbione, there is something strange going on with the channel logs ...
[06:33] <ogra> are you working on them ? 
[06:36] <highvoltage> jdub: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-devel-current.html seems confused, it's mixing -devel and -motu
[07:00] <bencer> hi all, i'm looking for documentation about how dapper livecd is generated, there's many info about how to remaster the ubuntu or kubntu livecds, but none about how are them generated by ubuntu team
[07:00] <bencer> could you point me to something interesting ?
[07:11] <fabbione> ogra: no what's wrong with them?
[07:15] <fabbione> test
[07:15] <fabbione> siretart: mind to put the chan topic back?
[07:15] <siretart> fabbione: sorry, wrong alias command. my bad :(
[07:16] <siretart> whats the deal with 'dapper-proposed' and 'edgy-proposed' upload targets? are they pocketed or a free for all upload target?
[07:18] <fabbione> ogra: dude?
[07:20] <fabbione> highvoltage: ping?
[07:20] <fabbione> bah ok logs should be fine again
[07:21] <highvoltage> fabbione: ok, thanks. have a great weekedn!
[07:21] <fabbione> highvoltage: please get somebody from the team to SMS me if it is still broken in let say one hour
[07:21] <fabbione> i can't see anything obvious
[07:21] <fabbione> actually
[07:21] <fabbione> i can check it right now
[07:31] <Kamion> siretart: dapper-proposed is supposed to be a staging area for dapper-updates
[07:31] <Kamion> it's by approval only (uploads there land in the unapproved queue)
[07:34] <Kamion> dholbach: jokosher doesn't follow the new python policy
[07:35] <Kamion> dholbach: how does Jokosher.py get onto the $PATH for use by the .desktop file? (this is why I hate cdbs, it's bloody impossible to figure out what it's going to do short of building the damn thing)
[07:35] <dholbach> Kamion: *whine* you mean that it should install to /usr/lib/python<something>?
[07:35] <Kamion> dholbach: policy says that binaries on $PATH shouldn't have a .py suffix
[07:35] <Kamion> dholbach: no? read the new python policy
[07:36] <Kamion> it allows for private modules in /usr/share/foo
[07:36] <Kamion> but you aren't doing the XS-Python-Version, XB-Python-Version, dh_pycentral/dh_pysupport (pick one) stuff
[07:36] <dholbach> Kamion: the package is more of a hack, since upstream didn't manage to have a proper install/build system and relies on hardcoded paths for their first release
[07:37] <dholbach> Kamion: that's why i adjusted the desktop file
[07:37] <Kamion> sure, but there's no particular need for an upstream build system in order to follow the new python policy
[07:37] <Kamion> you just need a /usr/bin/jokosher -> /usr/share/jokosher/Jokosher.py symlink plus the control/rules stuff
[07:37] <rodarvus> I wonder if build speed on ia64 depends solely on processor speed, or if we are limited by memory/disk too.
[07:37] <dholbach> Kamion: Ok. Thank you very much and I'll read it now.
[07:38] <rodarvus> the ia64 machines on our build farm appear to take much longer to build than other platforms
[07:38] <Kamion> dholbach: also, you need to copy the gstreamer licence exception from COPYING into debian/copyright
[07:38] <dholbach> Kamion: Ok.
[07:38] <Kamion> ah, I see the .desktop file patch now
[07:38] <Kamion> (grr, patch systems, etc.)
[07:39] <dholbach> Kamion: thank alot
[07:39] <Kamion> dholbach: http://people.debian.org/~piman/python-policy/python-policy.html/ and http://wiki.debian.org/DebianPython/NewPolicy may be helpful
[07:40] <dholbach> gracias
[07:40] <elmo> rodarvus: it's a combination of CPU and the compiler being slower on that CPU
[07:40] <elmo> rodarvus: it's certainly not memory or disk
[07:40] <rodarvus> elmo: oh, thats sad news :/
[07:40] <Kamion> dholbach: let me know when you've uploaded an improved version and I'll look at it
[07:40] <dholbach> Kamion: you rock!
[07:40] <rodarvus> means its basically quite hard to do anything there to increase build speed
[07:41] <Kamion> we do need to follow the new python policy though, it's one of our goals for this release
[07:41] <elmo> to be fair, we have realtively slow itaniums.  if we've been willing to spend the $$$, we could have got CPUs that would match or outclass our other platforms
[07:41] <elmo> rodarvus: well, it shouldn't be a problem, ia64 isn't a blocker for anything as it's not a supported platform
[07:41] <rodarvus> binaries are published on a per-arch basis, then?
[07:42] <bddebian> Yep
[07:42] <rodarvus> I'm usually waiting for ia64 to complete its builds, before uploading packages with build-deps
[07:42] <Kamion> yes, the publisher works in units of .changes files
[07:42] <Kamion> which, for us, are either source uploads or the output from a single buildd for a single source package
[07:43] <bddebian> Kamion: Did you happen to see the sync request for xcircuit?
[07:43] <Kamion> bddebian: yes, it's in the queue with the others
[07:43] <bddebian> OK, thanks
[07:43] <Kamion> you can always check https://launchpad.net/people/ubuntu-archive/+subscribedbugs
[07:43] <Kamion> that's what we look at
[07:44] <bddebian> Well I saw some others come through and I thought maybe I forgot to subscribe ubuntu-archive
[07:44] <elmo> rodarvus: you shouldn't need to do that, the build-deps should be automatic, and even if they aren't, the only affected arch ia64
[07:45] <rodarvus> elmo: in this case the package won't wait to build, as there is already an older version of the library installed
[07:45] <bddebian> Can I bug anyone about my python policy question now?
[07:46] <rodarvus> bddebian: don't ask to ask - just ask - someone might pick you question and answer it
[07:46] <elmo> rodarvus: you should be increasing the build-depends in that case
[07:46] <bddebian> rodarvus: I asked earlier :-)
[07:46] <rodarvus> elmo: yeah, but its not a strict versioned build depends, just a "would nice to build with this new version" :)
[07:46] <Kamion> bddebian: I only did a small pass earlier today, not a full one, 'cos I was in a hurry. in any event you can check the URL above to make sure
[07:47] <bddebian> Kamion: Aye, fair enough
[07:47] <Kamion> bddebian: what's your python policy question?
[07:48] <elmo> rodarvus: IMHO those should be in build-depends, but that's just my opinion, I know others on the team disagreee
[07:48] <bddebian> Kamion: If I understand it correctly, if a package uses python extensions, it is still correct to use python2.x build deps and /usr/lib/python2.x/ etc?
[07:48] <elmo> in the long term we should really one day have build-depends-auto and build-depends-for-humans
[07:49] <rodarvus> elmo: you're right, actually - the only reason I (personally) don't add these versioned build depends is to not diverge (more than needed) from debian
[07:49] <Kamion> elmo: (it's awkward when some of what rodarvus is trying to do is sync with Debian)
[07:49] <rodarvus> yup
[07:50] <elmo> right, that's a valid use case for not doing it, I guess
[07:50] <elmo> one day I should spec build-depends-auto
[07:51] <Kamion> bddebian: as in compiled C extensions? build-depend on python-all-dev not pythonx.y-dev, compile for all $(pyversions -r), then install to /usr/lib/pythonx.y/ and use dh_pycentral or dh_pysupport
[07:51] <Kamion> bddebian: please follow the howto in http://wiki.debian.org/DebianPython/NewPolicy for conversion
[07:52] <Kamion> elmo: I sort of feel it should be possible for uploaders to set dep-waits in some limited way
[07:52] <Kamion> dunno how that could be done sanely though
[07:53] <rodarvus> via LP, after an upload, maybe?
[07:53] <bddebian> Kamion: Thanks
[07:53] <infinity> Could be represented at a Build-Depends-Strict in the .changes or something.
[07:53] <infinity> s/at/as/
[07:54] <infinity> (So as to avoid having our .dsc differ from Debian's)
[07:55] <elmo> Kamion: I think build-depends-auto should be generated at build time  from shlibs type files, and shift the burden of what's needed to being by default on the library package as they are for Depends
[07:55] <elmo> Kamion: but keep build-depends as build-depends for humans/backporters or whatever
[07:55] <elmo> (not necessarily specific to ubuntu, I've thought Debian should do this for a long time too)
[07:55] <Kamion> elmo: mm, I could agree with that yes
[07:57] <Kamion> right, another partial sync run I'm afraid, have guests arriving and had to cut it short
[08:04] <bddebian> So this:  mv $(CURDIR)/debian/tmp/usr/lib/python/* $(CURDIR)/debian/python2.3-libhamlib2/usr/lib/python2.3/site-packages
[08:05] <bddebian> would become: mv $(CURDIR)/debian/tmp/usr/lib/python/* $(CURDIR)/debian/python2.3-libhamlib2/usr/lib/python_support/site-packages
[08:05] <bddebian> ?
[08:05] <bddebian> s/python2.3-ham/python-ham/
[08:10] <dholbach> Kamion: I uploaded a new version. I hope it's alright now.
[08:11] <bddebian> And would .dirs be /usr/lib/python-support/site-packages ?
[08:12] <LaserJock> is the NEW queue fisable on LP at all?
[08:12] <LaserJock> s/fisable/visable/
[08:13] <LaserJock> or anywhere for that matter
[08:13] <bddebian> Damn, I think I lost Kamion :-(
[08:15] <infinity> LaserJock: Only to members of the archive team, afaik.
[08:15] <bddebian> Heya infinity
[08:15] <LaserJock> infinity: hmm, to bad :-)
[08:15] <infinity> LaserJock: https://launchpad.net/distros/ubuntu/edgy/+queue <-- Can you see that?
[08:16] <LaserJock> yes
[08:16] <infinity> Oh, then I'm wrong.
[08:16] <LaserJock> oh, that's a nice page
[08:16] <infinity> Not visible if not logged in, which was all I checked.  I don't have an "unprivileged" account to test with.
[08:17] <LaserJock> infinity: are they usually handled FIFO?
[08:17] <infinity> LaserJock: They're handled however we feel like. :)
[08:18] <LaserJock> of course, I should have guessed ;-)
[08:18] <LaserJock> so does bribery help?
[08:18] <infinity> LaserJock: If we need a specific thing for a build-dep, we process it.  If it's an easy package to process, we do it.  If it requires effort and research, it might sit for a bit.
[08:18] <LaserJock> k, no problems, just wondering how the proccess worked
[08:18] <infinity> (ie: sketchy licenses, complex package to give a once-over to, etc)
[08:19] <infinity> LaserJock: What are you after having processed right now?
[08:20] <LaserJock> infinity: not exactly anything in particulare there is an easy one (gisomount) that I'm tracking but that's it
[08:25] <Gloubiboulga> infinity, I have new xubuntu seeds which should resolve the oversize issue, would it possible to run a new Desktop build?
[08:27] <infinity> Gloubiboulga: I can give it a whirl.
[08:28] <Gloubiboulga> infinity, seeds are at http://tiber.tauware.de/~gauvain/bzr/xubuntu-seeds/edgy/desktop, do you need something else (I'm very new to this)?
[08:30] <infinity> Gloubiboulga: Oh, feh.  I thought you'd committed to the main branch and I already started the builds.
[08:30] <infinity> Gloubiboulga: Do you not have access to commit to the seeds in LP?
[08:31] <Gloubiboulga> infinity, if it needs main priviledge uploads, no
[08:31] <infinity> Gloubiboulga: If you don't have the access to do so, can you get janimo to look over your changes, commit them, and do a xubuntu-meta upload.
[08:31] <infinity> Gloubiboulga: THEN, I can spin new CDs.
[08:32] <LaserJock> hehe, I love that phrase
[08:32] <Gloubiboulga> infinity, well, the problem is that janimo doesn't even answer my mails...
[08:33] <Gloubiboulga> that's why I was trrying to make this run myself :)
[08:33] <Gloubiboulga> anyway, I'll wait for his answer
[08:33] <infinity> Gloubiboulga: Perhaps he's away currently?  I dunno.  I prefer not to touch Xubuntu without his consent.
[08:33] <Gloubiboulga> infinity, no problem
[08:35] <bddebian> Kamion: still here?
[08:35] <infinity> bddebian: 11:57 < Kamion> right, another partial sync run I'm afraid, have guests arriving and had to cut it 
[08:35] <infinity>                 short
[08:36] <bddebian> Gah
[08:36] <bddebian> Damnit Jim
[08:36] <infinity> bddebian: For the timezone-impaired, that was about 38 minutes ago.
[08:37] <bddebian> Well shit, hamlib seemed to build with my changes, how do I know if I did it right?
[08:58] <bddebian> Later folks
[08:59] <highvoltage> bye bddebian 
[08:59] <bddebian> Later highvoltage
[09:00] <highvoltage> FINE
[09:11] <jdub> fabbione: ping
[09:35] <fabbione> jdub: pong
[09:36] <fabbione> jdub: i only have 3 minutes or so before the movie start
[09:36] <jdub> fabbione: i looked at the sparc/ pages on the wiki - any more info i should look at about installing on a T2000?
[09:36] <jdub> (specifically dapper)
[09:36] <fabbione> jdub: nope. it should just work
[09:36] <fabbione> jdub: there is only the KnownIssues that you want to be aware of
[09:36] <ogra> fabbione, logs are fine again ... somehow -motu and -devel were merged this afternoon
[09:37] <jdub> so the comments about silo CD booting and stuff is no longer relevant?
[09:37] <jdub> oh
[09:37] <fabbione> ogra: yes i have no idea why because the logs were good here
[09:37] <jdub> so it's relevant?
[09:37] <ogra> (only in ubuntu-devel-current.html )
[09:37] <fabbione> jdub: it's not relevant for the T2000
[09:37] <jdub> ah, ok
[09:37] <fabbione> jdub: it's OBP version dependent
[09:37] <fabbione> jdub: T2K is fine
[09:37] <jdub> sweet
[09:37] <jdub> but skipping 1MB at the start of the disk does apply, etc?
[09:38] <fabbione> jdub: something you really want to do carefully is d-i refresh waiting time
[09:38] <fabbione> jdub: yes that's generic to the sparc disk layoyt
[09:38] <fabbione> layout
[09:38] <jdub> ok
[09:38] <jdub> thanks :-)
[09:38] <fabbione> jdub: *IF* you install via telnet sessions
[09:38] <fabbione> the installer is in *color*
[09:38] <fabbione> serial 9600 bps eyecandy
[09:38] <fabbione> (next will be GLX over 9600)
[09:39] <jdub> heh
[09:39] <fabbione> it takes time to refresh stuff.. let d-i to do the full refresh before you start pushing buttons
[09:39] <fabbione> even when inside a menu
[09:39] <fabbione> otherwise strange things can happen
[09:39] <jdub> right
[09:39] <fabbione> otherwise.. works for me, David Miller, SUN but not for elmo
[09:39] <fabbione> so if you manage to fail, sucks to be you :P
[09:40] <jdub> apparently sparc hardware hates elmo and/or vice versa
[09:40] <fabbione> jdub: ehehe yeah i noticed.. sparc hates znarl too
[09:41] <zul> sorry...i saw that as spaz
[09:41] <LaserJock> yeah, if you spaz I'm sure sparc will hate you
[09:42] <fabbione> ok you are all set
[09:42] <fabbione> have fun
[09:42] <fabbione> -> movie
[09:43] <fabbione> jdub: have fun with the t200
[09:43] <fabbione> jdub: you will notice the typo in the OBP ;)
[09:43] <fabbione> jdub: oh btw.. let me find something for you
[09:44] <fabbione> how much ram do you have on that box?
[09:45] <fabbione> jdub: ?
[09:45] <jdub> fabbione: not sure, the box is in boston
[09:46] <fabbione> jdub: http://sunsolve.sun.com/search/document.do?assetkey=1-21-122430-03-1 <- ALOM/OBP update.
[09:46] <fabbione> jdub: unzip the jar, read the instructions on how to update
[09:46] <fabbione> it's not required
[09:46] <fabbione> but it's nice to have
[09:46] <fabbione> jdub: ok, have fun
[09:46] <fabbione> i am off
[09:46] <jdub> doable with ubuntu?
[09:46] <fabbione> you do the update via the ALOM itself
[09:46] <jdub> oh
[09:46] <fabbione> all the procedure is explained there
[09:46] <fabbione> just read it
[09:47] <fabbione> i did it, you can do it :D
[09:47] <jdub> ;-)
[09:47] <jdub> thanks!
[09:47] <fabbione> cya
[10:12] <djbmister> does anyone have experience with the ubuntu kernel 2.6.15 and powerpc?
[10:12] <djbmister> this question is mostly related to a chrp system - pegasos 2
[10:14] <djbmister> any powerpc devs here?