[12:08] <Ingmar^> ati radeon
[12:08] <Ingmar^> xserver-xorg-video-ati got an update yesterday, but downgrading & restarting my xserver didn't solve it
[12:09] <Ingmar^> got any idea how I can  
[12:09] <Ingmar^> got any idea how I can narrow the problem down & find what's wrong ?
[12:19] <jdub> fabbione: ping
[01:08] <jdub> with the latest kernel/initramfs combination, myu machine stops booting aafter fsck
[01:08] <jdub> it boots going back to -9-generic and its old initramfs (haven't tried rebuilding it though, will do now)
[01:15] <elmo> ehm, dumb question, but how in edgy are you meant to tell firefox to handle file types differently, e.g. not use totem to play video?
[01:19] <_ion> Edit  Preferences  Content  File Types: Manage  for each format you don't want a plugin to be used, Change Action and select what suits you best.
[01:19] <_ion> The MediaPlayerConnectivity extension > the Totem plugin. :-)
[01:21] <elmo> I don't have a MediaPlayerConnectivity extension?  that dialogue you showed me only lists flash as a Download Action I can change
[01:23] <_ion> Just choose e.g. Save to disk.
[01:24] <elmo> that's the point dude - I don't get that option in edgy anymore
[01:25] <_ion> Oh... Worksforme.
[01:25] <_ion> Unless there has been a Firefox update during the last 4 hours or so.
[01:26] <jdub> (from above) seems okay after redoing the initramfs for -10-generic
[01:27] <jdub> i wonder what was out of sync
[01:27] <jdub> during upgrade
[01:27] <_ion> Did you backup the faulty initramfs? Do a diff.
[02:14] <wasabi_> Hmm. I guess it works right, but getting an expense form in .xls is silly. ;)
[02:16] <simpla> hi guys
[02:17] <simpla> I have a question on development on ubuntu, can I ask that here?  Or is this channel for development of ubuntu?
[02:17] <zul> development of ubuntu
[02:18] <simpla> ok, is there a channel for development on ubuntu?
[02:18] <zul> i dont think so at least i dont know of one
[02:18] <simpla> ok thanks
[02:19] <Fade> development on ubuntu isn't any different than development on any given *nix platform.
[02:19] <Fade> too fast. ;)
[03:04] <zul> heh come to the dark side have we kylem 
[03:04] <kylem> ? i parted a while ago to reclaim some much needed irc tabs.
[03:04] <zul> ah
[04:58] <PorkkroP> Hello =>
[05:21] <fabbione> morning
[07:32] <fabbione> Treenaks: you around?
[07:38] <Treenaks> fabbione: yes
[07:38] <fabbione> Treenaks: yo dude.. i was looking into my irclogs to dig out how to run compiz, but i think they have been lost somehow
[07:38] <fabbione> Treenaks: mind to give me again the cmd line you use?
[07:38] <Treenaks> compiz --strict-binding --indirect-rendering gconf
[07:38] <Treenaks> and gnome-window-decorator --replace
[07:38] <Treenaks> (compiz might need --replace too)
[07:39] <Treenaks> and I don't know if 'gconf' is still possible in current edgy
[07:40] <Treenaks> Also, I saw a git commit (23a6f97e08fd49e1cae03cd97cae67a5f06b7634) in xf86-video-ati that might finally fix bug 20283 \o/
[07:40] <Ubugtu> Malone bug 20283 in xserver-xorg-driver-ati "[fgl v5000]  really bad sync" [Unknown,Needs info]  http://launchpad.net/bugs/20283
[07:41] <fabbione> Treenaks: i think i pulled that in yesterday in ubuntu3 (edgy)
[07:41] <Treenaks> fabbione: it's 11 hours old..
[07:41] <fabbione> but i can't access gitweb on freedesktop for some reasons
[07:42] <Treenaks> ""
[07:42] <Treenaks> "FP timing regs required for both internal and external TMDS"
[07:42] <fabbione> upstream didn't push that one to me
[07:44] <Treenaks> so how do I test? get a clean copy from git, an put in a debian/ dir, or get the package, and just apply the single patch from git?
[07:44] <fabbione> Treenaks: can you actually access the commitdiff on gitweb?
[07:44] <Treenaks> fabbione: yes
[07:45] <fabbione> it hangs here
[07:45] <fabbione> waiting for..
[07:45] <Treenaks> strange..
[07:48] <fabbione> it's a network problem or so it seems...
[07:50] <bronson> Is it possible for mere mortals to download a package from Revu?
[07:50] <bronson> I need http://revu.tauware.de/details.py?upid=3297 but I can't figure out where the .deb is.
[07:50] <ajmitch> bronson: revu generally only has source packages
[07:51] <bronson> source is fine -- I don't mind building it.  All I can find is the individual files that I'd have to wget -r to build.  :)
[07:52] <ajmitch> .dsc, .diff.gz, .orig.tar.gz
[07:52] <ajmitch> so the first 3 on the page
[07:57] <bronson> ok.  ajmitch, thanks.
[08:04] <dholbach> good morning - HAPPY HUG DAY!
[08:04] <tfheen> hello Daniel
[08:04] <Hobbsee_> hey dholbach 
[08:05] <dholbach> hey Tollef, Sarah!
[08:05] <tfheen> 'morning Sarah
[08:05] <Hobbsee> :)
[08:11] <pitti> Good morning
[08:46] <bronson> Trying out my new network-manager-openvpn package...
[08:46] <fabbione> Treenaks: that commit won't work in edgy tree and doesn't fix that bug
[08:48] <fabbione> Treenaks: and the fix is post-super-patch-of-death-after-release.. that means chances that it applies are < 0
[09:03] <tepsipakki> before I file a wishlist bug, why is /etc/mtab a file and not a link to /proc/mounts? Surely /proc is always present on ubuntu..
[09:03] <tfheen> because mtab includes more information than /proc/mounts
[09:04] <tepsipakki> tfheen: seems to be the other way around here
[09:04] <tfheen> /etc/mtab:/home/tfheen/live/iso/casper/filesystem.squashfs /mnt squashfs rw,loop=/dev/loop0 0 0
[09:04] <tfheen> /proc/mounts:/dev/loop0 /mnt squashfs ro 0 0
[09:05] <tepsipakki> ok, loop-fs..
[09:05] <tepsipakki> but is that fixable?
[09:06] <tfheen> probably
[09:06] <tfheen> but it's not fixed
[09:06] <bronson> ajmitch: that worked great.  thanks for the hint.
[09:06] <tepsipakki> tfheen: that's true ;)
[09:06] <tepsipakki> tfheen: now that we are at it, do you know why /proc/mounts lists tmpfs's twice?
[09:07] <tfheen> tepsipakki: it doesn't for me
[09:07] <tepsipakki> oh..
[09:07] <tfheen> : tfheen@golem ~/live/chroot > grep volatile /proc/mounts
[09:07] <tfheen> tmpfs /lib/modules/2.6.17-10-generic/volatile tmpfs rw 0 0
[09:07] <tepsipakki> ah
[09:07] <tepsipakki> that's an exception, yes
[09:08] <tepsipakki> but /var/run etc
[09:08] <tepsipakki> actually three times here
[09:08] <tfheen> they're probably mounted more than once, then
[09:08] <tepsipakki> duh
[10:04] <sivang> morning
[10:05] <jdub> Keybuk: your website is timing out for me
[10:05] <Keybuk> whew, anastacia is looking somewhat sassier this morning
[10:05] <Keybuk> jdub: blame thom
[10:05] <jdub> well, /blog/ actually
[10:06] <jdub> www appears to be fine
[10:06] <Keybuk> works for me
[10:06] <jdub> oh, but it has moved to blog.
[10:06] <jdub> and now i don't get dns for it
[10:06] <Keybuk> no, it hasn't moved to blog.
[10:06] <Keybuk> clear your cache
[10:06] <Keybuk> that was a temporary thing
[10:06] <Keybuk> mozilla is "helpfully" caching the bogus redirect
[10:06] <jdub> you should fix the link on the front page
[10:07] <Kamion> Keybuk: anastacia> nice
[10:07] <jdub> mmm, /blog/ is still taking time
[10:07] <Keybuk> jdub: ah, well spotted
[10:08] <Keybuk> taking time => ruby on rails is teh suck
[10:08] <tfheen> is there a way to list the bugs for a package which are targetted to a particular milestone?
[10:09] <pitti> tfheen: yes; display the package's bug page -> advanced search -> tick the release
[10:09] <Keybuk> Kamion: btw, always meant to ask ... there's no way to completely fulfill jessica's wishes and assign priority on a per-arch basis?
[10:09] <tepsipakki> how come there are no xfonts-*-transcoded -packages?
[10:09] <tfheen> pitti: oh, point.
[10:10] <Kamion> Keybuk: correct, unfortunately
[10:11] <Keybuk> *nods* I tend to just make sure i386/amd64 are right
[10:11] <Kamion> yeah, that's reasonable
[10:11] <fabbione> Kamion: hey dude.. when you have 10 spare minutes would you mind to help me with a bug in debconf usage?
[10:11] <Kamion> actually I think with soyuz you probably can do per-arch priorities
[10:11] <Kamion> but it's not exactly heavily tested
[10:12] <Kamion> change-override.py has an -a option
[10:12] <Kamion> fabbione: sure, now's fine
[10:12] <fabbione> Kamion: ok great! can you grab redhat-cluster-suite from edgy?
[10:12] <fabbione> the 2 scripts are cman.config and cman.preinst
[10:12] <fabbione> i wrote them based on your input
[10:12] <Kamion> 2.20061002-0ubuntu1 OK?
[10:13] <fabbione> yeps
[10:13] <fabbione> for some reasons that i can't understand when i do dapper -> edgy upgrades, no matter what i answer it fails
[10:13] <Kamion> ok, got them
[10:13] <Kamion> fails how?
[10:13] <fabbione> if i just dpkg -i cman it works
[10:13] <Keybuk> Kamion: it does?  it's not in --help
[10:13] <fabbione> it hits one of the "exit 1"
[10:13] <Kamion> Keybuk: oh, maybe it doesn't then
[10:14] <Kamion> obviously I'm mad
[10:14] <fabbione> dpkg: error processing /var/cache/apt/archives/cman_2.20061002-0ubuntu1_i386.deb (--unpack):
[10:14] <fabbione>  subprocess pre-installation script returned error exit status 1
[10:14] <fabbione> (that was from running apt-get install cman
[10:14] <Keybuk> Kamion: then what does that make the rest of us? :)
[10:15] <Kamion> fabbione: can you run it with DEBCONF_DEBUG=developer and put the output somewhere for me please?
[10:15] <fabbione> Kamion: sure...
[10:18] <fabbione> http://people.ubuntu.com/~fabbione/debconf.output
[10:18] <tepsipakki> so, there was the bug #39560 already filed
[10:18] <Ubugtu> Malone bug 39560 in xfonts-core "The xfonts-*-transcoded packages are missing from Breezy onwards" [Medium,Confirmed]  http://launchpad.net/bugs/39560
[10:18] <fabbione> Kamion: i can see now where it hits the exit 1
[10:19] <fabbione> but i am not sure why we did it that way
[10:20] <Kamion> oh, your error is in assuming that db_input critical failing means that we're noninteractive
[10:21] <Kamion> it might equally mean that the .config is being run second time round
[10:22] <Kamion> fabbione: I suggest just moving lines 13 to 19 of the .config (db_input to db_fset) inside the 'if [ "$RET" = false ] ' block just above
[10:23] <Kamion> you don't need to bother asking the question if seen_in_2.0_upgrade is true (i.e. .config being run second time round)
[10:23] <fabbione> ok!
[10:28] <tfheen> Kamion: did you just upload a new casper or just commit?
[10:33] <fabbione> Kamion: thanks
[10:33] <Kamion> tfheen: upload
[10:34] <tfheen> Kamion: ok.
[10:34] <Kamion> wanted to fix that KDE bug
[10:34] <Kamion> sorry if I got in your way
[10:34] <tfheen> you did, but that's ok.
[10:44] <Kamion> Riddell: is there a reason qt3-designer isn't in main?
[10:50] <AnAnt> I got a problem in Edgy, I upgraded from Dapper to Edgy, now whenever I boot the laptop when connected to LAN, I first get an IP address, then when the boot completes I lose that address, so I have to unplug & plug again to fix that , why is that happening ?
[10:50] <AnAnt> note: i got whereami & ifplugd installed
[10:50] <AnAnt> oh btw, there is a bug I think in the Ubuntu Help documents
[10:50] <AnAnt> I mean the System documentation
[10:50] <AnAnt> sometimes it misses some words
[10:51] <AnAnt> for example in the Adding Extra repositories page: in step 1 it says "Open ."
[10:51] <AnAnt> that seems to be something wrong !
[10:52] <Keybuk> meh
[10:52] <Keybuk> does anyone know how to either
[10:52] <Keybuk> a) make sed case-insensitive
[10:52] <Keybuk> b) lower-case something without using tr
[10:53] <pitti> Keybuk: use s/foo/bar/i ?
[10:53] <pitti> that replaces foo, Foo, or FOO with 'bar'
[10:54] <Keybuk> pitti: that doesn't work for /.../ though
[10:54] <Kamion> use sed's y/// command?
[10:55] <Keybuk> Kamion: doesn't accept ranges
[10:56] <Kamion> Keybuk: there's a GNU extension /.../I
[10:56] <Kamion> for case-insenstivity
[10:56] <Keybuk> I guess we can rely on those
[10:56] <pitti> Keybuk: echo 'Hello' | sed -r '/hello/I d' works fine
[10:59] <Keybuk> don't need the -r ?
[10:59] <pitti> yes, true
[10:59] <pitti> autofinger...
[11:04] <agutierr> hello all: I have a problem using  preseeds: process is fine before unpacking language-pack-en: then the installation process becomes slow, and do nothing... I dont know what is wrong. Someone has used an automated install with ubuntu ? Thanks!
[11:06] <tepsipakki> agutierr: it is generating locales, so it takes time
[11:06] <agutierr> the installer log shows: Generation complete
[11:06] <agutierr> but nothing happers
[11:06] <agutierr> happens
[11:07] <tepsipakki> on edgy?
[11:07] <agutierr> dapper
[11:07] <tepsipakki> how long have you waited?
[11:08] <tepsipakki> have you checked what processes are running?
[11:09] <agutierr> Umm
[11:09] <agutierr> let me a moment
[11:10] <agutierr> well
[11:10] <agutierr> generation is complete
[11:10] <agutierr> now the problem is
[11:10] <agutierr> the package isntallation is sooo slow
[11:10] <agutierr> now its installating xresprobe
[11:10] <agutierr> but... every package takes about 5 minutes
[11:11] <agutierr> it isnt usual I think
[11:12] <tepsipakki> does the machine have enough RAM?
[11:13] <agutierr> 512 M
[11:13] <tepsipakki> (just guessing here)
[11:13] <tepsipakki> ok, plenty
[11:13] <agutierr> previously
[11:13] <agutierr> i use a debian preseed
[11:13] <agutierr> it works fine
[11:13] <tepsipakki> I have ~220 dappers running and havent seen similar
[11:13] <Keybuk> sweeeet
[11:14] <Keybuk> C-A-F1, then C-A-D twice very quickly ... :)
[11:15] <agutierr> Umm
[11:15] <agutierr> For what ?
[11:17] <AlinuxOS> Hello, how can I report a bug for Debian if I use Ubuntu ?
[11:18] <agutierr> my preseed file is: http://paste.uni.cc/10557
[11:18] <pitti> AlinuxOS: http://www.debian.org/Bugs/Reporting
[11:18] <pitti> AlinuxOS: in short, install Debian's reportbug and use that
[11:18] <AlinuxOS> pitti, ;) thank yuu and good morning!
[11:18] <pitti> AlinuxOS: Good morning, pal :)
[11:19] <AlinuxOS> I have reportbug package installed
[11:19] <AlinuxOS> is it useful ?
[11:20] <siretart> AlinuxOS: yes. just be sure to use the '--bts debian' option.
[11:20] <seb128> hum
[11:21] <seb128> pitti: do you know if that might be an apport bug
[11:21] <seb128> most of the gaim crash bugs look like
[11:21] <seb128> " Program terminated with signal 6, Aborted.
[11:21] <seb128>  #0  0x00002baaa029747b in *__GI_raise () from /lib/libc.so.6
[11:21] <seb128>  #0  0x00002baaa029747b in *__GI_raise () from /lib/libc.so.6
[11:21] <seb128>  No locals.
[11:21] <seb128>  #1  0x00002baaa0298da0 in *__GI_abort () from /lib/libc.so.6
[11:21] <seb128>  No locals.
[11:21] <seb128>  #2  0x00000000004c0afc in main ()
[11:21] <seb128>  No symbol table info available."
[11:21] <AlinuxOS> I so I launch it "reportbug --bts" <---that's ok I think.
[11:21] <pitti> seb128: well, ATM we catch SIGABRT
[11:22] <pitti> seb128: I agree that this stack trace is useless, though; gaim seems to have its own signal handler?
[11:23] <seb128> that's possible, looking
[11:25] <seb128> pitti: right, they have
[11:26] <pitti> seb128: and if it catches a SEGV, it calls abort?
[11:26] <pitti> seb128: probably priting something to stderr before
[11:26] <seb128> 	case SIGSEGV:
[11:26] <seb128> 		fprintf(stderr, "%s", segfault_message);
[11:26] <seb128> 		abort();
[11:26] <seb128> 		break;
[11:26] <pitti> ok, that would spoil the apport report
[11:26] <seb128> k
[11:26] <seb128> so should I just patch that out?
[11:27] <pitti> seb128: I think we should prefer proper apport reports over stderr messages, yes
[11:27] <seb128> doing that
[11:27] <pitti> seb128: so a mini-patch which just disables the sigaction() call for SIGSEGV etc.?
[11:27] <seb128> that explain all the useless bt we get ;)
[11:27] <seb128> just dropping the 
[11:27] <seb128> "		fprintf(stderr, "%s", segfault_message);
[11:27] <seb128> 		abort();"
[11:27] <seb128> should be enough no?
[11:28] <pitti> seb128: no, then you won't get any crash report at all
[11:28] <lifeless> have to drop the handler
[11:28] <lifeless> if you catch the exception, you have to processit
[11:28] <pitti> seb128: and if you catch a SIGSEGV in gaim, then you need to abort the program anyway
[11:28] <pitti> it's pretty dangerous to continue the program after a segv
[11:28] <lifeless> unless you are a VM
[11:28] <pitti> seb128: the safest thing would be to not catch it at all
[11:29] <lifeless> if you are a VM, then segv is sometimes /used/ :(
[11:29] <seb128> static int catch_sig_list[]  = {
[11:29] <seb128> 	SIGSEGV,
[11:29] <seb128> 	SIGHUP,
[11:29] <seb128> 	SIGINT,
[11:29] <seb128> 	SIGTERM,
[11:29] <seb128> 	SIGQUIT,
[11:29] <seb128> 	SIGCHLD,
[11:29] <seb128> 	-1
[11:29] <seb128> };
[11:29] <seb128> I'll just drop SIGSEGV from that list then
[11:29] <pitti> seb128: right
[11:30] <pitti> seb128: so it doesn't intercept SIGFPE, SIGBUS, and friends. good
[11:30] <Keybuk> pitti: it's not _that_ dangerous
[11:30] <pitti> Keybuk: well, true, s/dangerous/fragile/
[11:30] <Keybuk> not even fragile
[11:30] <pitti> if you examine the situatioon properly, you can probably handle it
[11:30] <pitti> but not at all in a general catch-all segv handler
[11:31] <Keybuk> usually one does something like siglongjmp to a known good point in the execution
[11:33] <AlinuxOS> I've allredy filed a bug against console-setup in rosetta...is it enough for Debian ?
[11:34] <Fujitsu> AlinuxOS, Malone is the Launchpad bug system, Rosetta just does translations...
[11:35] <AlinuxOS> sorry
[11:35] <AlinuxOS> malone :D
[11:35] <AlinuxOS> yes
[11:35] <AlinuxOS> I meant malone Fujitsu you've right :)
[11:35] <Fujitsu> Good, I was hoping you hadn't found a way to use Rosetta to report a bug :S
[11:36] <AlinuxOS> Fujitsu, no, just want to know If I report a bug in malone, is it assigned to Debian too ? Has Debian benefits or something ?
[11:36] <tepsipakki> can backports add source packages?
[11:36] <cbx33> seb128, did gconf update go ok?
[11:37] <Fujitsu> AlinuxOS, no, you'd need to report it seperately in Debian.
[11:37] <AlinuxOS> or should I use "reportbug --bts debian"
[11:37] <tepsipakki> ie. if I'd like to have new versions of xfonts-{base,75dpi,100dpi} which all have their own source now
[11:37] <seb128> cbx33: I got swaped with other issues, please stop pinging me every day, pressure is no fun, I'll do it when I've time, thank you
[11:38] <seb128> swamped
[11:38] <cbx33> sorry seb128, wasn't pressurising, just a casual enquiry as to gconf as a whoole
[11:38] <cbx33> my apologies
[11:38] <cbx33> I'll say no more
[11:38] <seb128> yeah, people enquiring every day if they bug is fixed is not really useful :p
[11:38] <seb128> np ;)
[11:38] <seb128> s/they/their
[11:38] <cbx33> point taken
[11:43] <__keybuk> *sigh*
[11:43] <__keybuk> why does X-Chat SEGV every time it's closed?
[11:44] <lifeless> Keybuk: because it can ?
[11:44] <AlinuxOS> mmm, I prefer malone then Debian reportbug :/
[11:47] <Fujitsu> Keybuk, I noticed that too.... It's /really/ annoying. Any ideas why it does it?
[12:00] <cbx33> who would I talk to about someone sponsoring a teamspeak server for a few hours so we cna have a collaborative sound session?
[12:01] <highvoltage> cbx33: I thought anyone can create a room?
[12:01] <cbx33> highvoltage: yes, but I need a nice high bandwidth server ;)
[12:02] <cbx33> fast and speedy
[12:02] <highvoltage> ah ok :)
[12:02] <cbx33> since I don;t know how many people are going to want to participate
[12:03] <cbx33> but I have several people interested already
[12:09] <sivang> highvoltage, cbx33 : this is for mountain view?
[12:10] <highvoltage> I think cbx33 wants to do this now.
[12:11] <sivang> highvoltage: ah :)
[12:11] <highvoltage> (or before MV, at least)
[12:20] <cbx33> sivang: I was hoping to do it sometime next week
[12:21] <cbx33> I have a server in the states but it's not the fastest ;)
[12:27] <popey> cbx33: how much bandwidth do you think it would need?
[12:27] <popey> I have a machine in the uk with some bandwidth
[12:27] <ogra> ...Option 4: use the Ubuntu logout dialog.
[12:27] <ogra> http://www.manucornet.net/ubuntu/JPEG/Logout_dialog.png
[12:27] <ogra> It has a poor UI, but with smaller icons and another ordering, we can make it something good...
[12:27] <ogra> heh
[12:28] <cbx33> popey: not sure.....I did it once and had a 1.5 hour conversation with someone else and the total bandwidth was 10Mb
[12:28] <cbx33> :p
[12:28] <cbx33> I'm thinking we'd have about 10 people or so
[12:28] <cbx33> and the quality would be upped
[12:29] <Kamion> AlinuxOS: there was already a commit to Debian's console-setup svn repository regarding Georgian fonts; I don't think another report is needed
[12:30] <AlinuxOS> Kamion, I've done in both places...as some people said to me that I should file bug everywhere.
[12:31] <Kamion> AlinuxOS: svn://svn.debian.org/svn/pkg-kbd/people/zinoviev/console-setup
[12:31] <Kamion>   * New mini-font georgian16.bdf to be used for the Georgian letters in
[12:31] <Kamion>     Fixed16, author: Gia Shervashidze.  Thanks to Vladimer Sichinava.
[12:31] <cbx33> popey: what do you think?
[12:31] <Kamion> like I say, no need for another bug
[12:31] <AlinuxOS> hm Kamion , so why no one noticed me ? :(
[12:31] <Kamion> AlinuxOS: because people are not omniscient :-)
[12:31] <cbx33> is it a fast connection?
[12:32] <Kamion> AlinuxOS: just leave it alone now, one notification is enough; I'll pull the fix into Ubuntu's console-setup
[12:33] <AlinuxOS> Kamion, sorry me...just understand me (no communication, no feed back) so I bugging people like you :)
[12:33] <AlinuxOS> If I only knew about it :(
[12:33] <Kamion> AlinuxOS: yeah, Anton probably just forgot to mail you back
[12:33] <Kamion> he's normally pretty good about that
[12:33] <AlinuxOS> definitely yes.
[12:35] <Keybuk> mjg59: around?
[12:37] <Riddell> Kamion: re qt3-designer, no reason it's not in main, it just hasn't been seeded
[12:40] <ogra> Kamion, there is either a bug in germinate or rather the liveFS build scripts or i'm seeding something wrong ... somehow the gcompris-sound packages end up on the ppc liveCD 
[12:40] <cbx33> ogra: eeek
[12:40] <ogra> (according to the .manifest file)
[12:40] <ogra> i guess thast my 40MB oversizedness
[12:58] <popey> hehe cbx33 have you seen 61530 :)
[12:58] <popey> that's bug 61530
[12:58] <Ubugtu> Malone bug 61530 in ubuntu-sounds "Shutdown sound is truncated" [Medium,Confirmed]  http://launchpad.net/bugs/61530
[01:02] <cbx33> hahahahahaha
[01:03] <popey> why don't you have a launchpad account?
[01:03] <popey> silly rabbit
[01:03] <cbx33> yeh the shutdown sound is getting dropped
[01:03] <cbx33> of course I do silly rabbit
[01:03] <popey> :)
[01:03] <popey> and :( shutdown sound
[01:03] <popey> what, completely dropped?
[01:03] <cbx33> yup completely dropped
[01:03] <cbx33> https://launchpad.net/people/petesavage
[01:04] <TheMuso> heh
[01:04] <cbx33> heheh
[01:04] <cbx33> frank suggested we just drop it completely as a lot of machine shutdown in a few seconds
[01:04] <cbx33> and alsa is one of the first things to go :(
[01:04] <popey> they do?
[01:04] <popey> blimey
[01:04] <cbx33> apparently
[01:04] <cbx33> in edgy that is
[01:04] <popey> it's not alphabetical is it?
[01:04] <cbx33> hehe
[01:04] <popey> make it zalsa :)
[01:05] <popey> aaaanyway
[01:05] <cbx33> I would have liked to keep it
[01:05] <cbx33> and shorten it 
[01:05] <popey> yeah, me too
[01:05] <popey> right, going to shutdown and see how long it takes
[01:05] <cbx33> well I have my new sound card now
[01:05] <cbx33> so I'll make one up
[01:05] <cbx33> and we'll see what frank thinks
[01:06] <cbx33> ou have a fairly kickass machine don't you
[01:06] <popey> ~20+ seconds :(
[01:06] <popey> not today, today I'm on a 1.1GHz celery
[01:06] <cbx33> ahhh
[01:06] <popey> but yes, I do have a kick ass machine :)
[01:06] <popey> http://gallery.popey.com/gallery/misc/DSC02495 :D
[01:07] <cbx33> grr our DNS servers are still down I can't see it
[01:07] <cbx33> HAHAHA
[01:07] <cbx33> what proc is in there?
[01:07] <popey> Core 2 Duo 6700 2.66GHz
[01:08] <popey> twin NVidia cards in SLI mode
[01:08] <Kamion> ogra: it's another side-effect of arch-specific task headers not working yet
[01:08] <Kamion> ogra: infinity's working on an apt-utils backport for drescher, after which I'll fix up cron.germinate
[01:09] <Kamion> infinity: (how's that going?)
[01:09] <cbx33> popey: nice
[01:10] <ogra> Kamion, ok, thanks
[01:10] <cbx33> mdz: I do have an LP account - I just subscribed
[01:11] <cbx33> to that bug
[01:11] <infinity> Kamion: Doing now, will hand it off to soyuz and the admin team before I head to bed.
[01:11] <Kamion> cool, thanks
[01:11] <infinity> Should cook it on mawson for at least a couple of days before we go break drescher, so I'd expect a rollout and invalidating the cache on drescher early next week (or the weekend, if we're lucky)
[01:12] <infinity> Invalidating the cache will take like a day, so would be nice to do it on a weekend.
[01:12] <ogra> infinity, we still need to talk about the ltsp tarball generation (sigh) can you dedicate some time for that tomorrow ?
[01:12] <infinity> ogra: Sure thing.  My tomorrow, or yours?
[01:12] <infinity> ogra: Like, give me an "in X hours" thing, or a UTC time. :)
[01:12] <ogra> yours ?
[01:13] <ogra> heh
[01:13] <tfheen> ogra: how's your ltsp fix coming along?
[01:13] <ogra> tfheen, which fix ? 
[01:13] <tfheen> ogra: 62750
[01:14] <tfheen> you're aware the RC is merely two weeks away, I presume
[01:14] <Treenaks> fabbione: remember that X bug I told you about this morning? I got a reply (through upstream bugzilla).. I have to send my bios (and they're working on it)
[01:14] <ogra> oh, thats fixed locally already i just need some other tweaks that should also go into the next upload
[01:14] <fabbione> Treenaks: i know.. i reported to Ben and Dave directly on irc :)
[01:15] <fabbione> Treenaks: but read about the patch.. it won't work on our ati driver
[01:15] <tfheen> ogra: ok, good.
[01:15] <ajmitch> tfheen: what package should I open a bug task on for the mono issues on the live cd?
[01:15] <ajmitch> I've got it open against f-spot at the moment
[01:16] <ogra> Keybuk, would you mind me fixing 62036 ?
[01:16] <AnAnt> why doesn't edgy accept this redirection:  >&    ?
[01:16] <ogra> (not sure if thats enough though)
[01:16] <sivang> AnAnt: probably since it uses dash or so
[01:16] <AnAnt> why doesn't edgy accept this redirection:  >&    from shell scripts ?
[01:17] <sivang> AnAnt: the default is dash now which is a stricter POSIX shell, IIRC
[01:17] <Treenaks> fabbione: ok, nice to know
[01:17] <tseng> you shell scripts should have #!/bin/bash if they are going to be bash specific
[01:17] <ogra> AnAnt, 2>&1 works fine here ...
[01:17] <AnAnt> ogra: thanks
[01:17] <ogra> even with dash
[01:18] <AnAnt> ogra: I didn't but 2 & 1 before, thanks
[01:18] <AnAnt> but that doesn't work fine !
[01:19] <AnAnt> I don't get redirection !
[01:19] <Kamion> AnAnt: see http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_07
[01:19] <Kamion> 2>&1 not "2 & 1"
[01:20] <AnAnt> Kamion: yes, I meant that I didn't put 2 nor 1 before
[01:20] <Kamion> ">filename 2>&1" is the usual way to redirect both standard output and standard error to filename
[01:21] <AnAnt> oh
[01:21] <Kamion> (2>&1 redirects standard error to standard output)
[01:21] <Kamion> the order is important
[01:21] <AnAnt> k, it worked
[01:21] <ogra> 2 & 1 would append 2 to the first command and background it and then try to execute 1 (which is no command)
[01:21] <AnAnt> I used to do >& filename
[01:21] <Kamion> yes, that's a bashism
[01:23] <sivang> AnAnt: sart bash and try it , it will work again
[01:23] <sivang> *start
[01:23] <AnAnt> sivang: yeah, it worked, thanks
[01:23] <Kamion> or just fix the script, it's usually not hard
[01:24] <Kamion> and makes your script a lot more likely to be portable to other systems
[01:24] <AnAnt> Kamion: did that 
[01:25] <AnAnt> k, now something else, the networking
[01:26] <Keybuk> ogra: I was holding off on that for some reason, but I've forgotten why -- so sure
[01:26] <AnAnt> my laptop is connected to LAN, when I boot the laptop it gets an IP at the beginning, but for some reason, it loses that IP when the booting finishes
[01:27] <ogra> Keybuk, do you think that suffices to get the right lenght of the progressbar ?
[01:27] <Keybuk> ogra: that should fix it, yes
[01:27] <ogra> ok
[01:27] <Keybuk> assuming you call usplash start from that init script, it would kill usplash anyway :)
[01:28] <Keybuk> so it certainly can't go further
[01:29] <Keybuk> cbx33: I'd argue to get rid of the "startup" sound too ;)
[01:29] <Keybuk> or, at least, change where it's played
[01:29] <Keybuk> instead of being "music to listen to while you wait" have it as a "sound that alerts you that your machine is now ready"
[01:29] <cbx33> Keybuk: I agree with you on the where
[01:30] <cbx33> thought this isn't possible to be changed is it?
[01:30] <cbx33> not now anyway
[01:30] <Keybuk> not now
[01:30] <cbx33> indeed
[01:38] <infinity> Keybuk: What's the point of your fglrx.modprobe?
[01:39] <infinity> Keybuk: If it's mean to prevent hotplug auto-loading, it probably belongs in lrm-common, not in xorg-driver-fglrx, if it's meant to prevent autoloading from the X driver, that makes no sense at all, since the driver will only try to load fglrx if it's in xorg.conf to start with.
[01:40] <Keybuk> ah, I did ask whether there was a "common", but got a "no"
[01:40] <Keybuk> should the nvidia equivalent be moved there too (from nvidia-kernel-common) ?
[01:40] <infinity> Keybuk: Well, it clearly doesn't belong with the X driver, it belongs with the module.
[01:40] <infinity> Keybuk: Yeah, there's already some nvidia modprobe stuff in lrm-common.
[01:41] <infinity> Keybuk: Or.. Wait.. Is there?  No, my crazy nvidia hack is in nvidia-glx-legacy, for other sketchy reasons.
[01:41] <infinity> Keybuk: May want to look at that to make sure yours isn't stepping on toes.
[01:41] <infinity> Keybuk: Anyhow, again, is there really a point to all this?
[01:41] <infinity> Keybuk: fglrx.ko doesn't autoload on my box unless I'm running the fglrx X driver.
[01:42] <Keybuk> mjg59 whinged a lot
[01:42] <infinity> It's only loaded by the X driver, not via hotpluggy stuff.
[01:42] <Keybuk> ah, then it differs from the nvidia one, which is loaded by udev
[01:43] <infinity> Well, fglrx.ko has no modalias or PCI IDs or anything.
[01:43] <infinity> So, perhaps we should drop that hack altogether.
[01:43] <gnomefreak> infinity: you got minute? bug 45705 was fixed wasnt it?
[01:43] <Ubugtu> Malone bug 45705 in ia32-libs "Error in Dist-upgrade on Dapper" [High,Confirmed]  http://launchpad.net/bugs/45705
[01:43] <Keybuk> yup, agree
[01:43] <infinity> gnomefreak: Erk.  It might not have been, actually. :/
[01:43] <gnomefreak> oh
[01:43] <Keybuk> infinity: you want to drop it, or shall i?
[01:43] <Kamion> cjwatson@drescher:~/germinate-test/ubuntu-misc$ egrep 'gcompris-sound-(de|en)' more-extra*
[01:43] <Kamion> gcompris-sound-de/i386  Task  edubuntu-desktop
[01:43] <Kamion> gcompris-sound-en/i386  Task  edubuntu-desktop
[01:43] <Kamion> gcompris-sound-en/amd64  Task  edubuntu-desktop
[01:43] <Kamion> that's more like it
[01:43] <Kamion> now with any luck apt-ftparchive will understand that once it's upgraded
[01:44] <infinity> Keybuk: You should look at nvidia-glx.postinst.in and see if your nvidia hack is going to wreak havoc with that.
[01:45] <infinity> Keybuk: I can drop the fglrx thing in the upload I need to do right now, but first look at the nvidia thing and tell me if the world is going to explode.
[01:45] <Keybuk> yup, the hack will break that entirely
[01:45] <doko_> keescook, pitti: wrong upload queue for python2.4 hoary-security
[01:45] <Keybuk> why the hell do you do that in postinst, instead of shipping a conffile?
[01:47] <infinity> Keybuk: Because I want to remove it in prerm, even if the package isn't purged.
[01:47] <pitti> doko_: yeah, I noticed, I uploded it into the correct queue afterwards
[01:47] <infinity> Keybuk: Too many people remove without purging, which would cause module loading to just explode.
[01:48] <doko_> pitti: thanks!
[01:48] <Keybuk> hmm, so how do we attack this
[01:48] <Keybuk> mjg59 doesn't want nvidia drivers loaded if the X server isn't going to be used
[01:48] <Keybuk> the X server can't be trusted to auto-load the driver
[01:48] <doko_> pitti: will you upload the package I prepared for dapper (the one with the extra fix)?
[01:48] <infinity> Keybuk: The X driver WILL (and does) autoload the nvidia module.
[01:48] <Keybuk> infinity: no, it doesn't
[01:48] <Keybuk> it kernel panics, crashes the machine, etc.
[01:48] <pitti> doko_: yes, that's what I did; thanks for preparing it
[01:48] <infinity> Keybuk: If we remove the modalias from the kernel module (can we?), the problem goes away.
[01:49] <Keybuk> it appears to be directly related to SLI
[01:49] <infinity> Keybuk: Err, come again?  It always used to autoload it.
[01:49] <Keybuk> if you have SLI, you get crashes, etc.
[01:49] <infinity> Kay.  So it needs to be loaded by udev if you have SLI?  Cute.
[01:49] <Keybuk> and given that I have that configuration, I'm not about to upload anything that breaks my X server ;)
[01:49] <infinity> Looks like it's time for a little shell script instead of a hideous modprobe line.
[01:50] <Keybuk> "little shell script" ?
[01:50] <infinity> Something clever enough to detect A) if you're using the nvidia driver, and B) if it's legacy or non-legacy.
[01:50] <infinity> Then use that as our install target.
[01:50] <Keybuk> install that at S08?
[01:50] <Keybuk> oh, I see
[01:52] <Keybuk> sure, if you like
[01:53] <infinity> Kay, I guess I'll just do that too in this upload.
[01:53] <AnAnt> how can one do field splitting in dash ?
[01:53] <infinity> AnAnt: read?
[01:54] <infinity> (Or any of a dozen other tricks)
[01:54] <Keybuk> infinity: be sure to put nvidia-kernel-common back to how it was?
[01:54] <AnAnt> read ?
[01:55] <infinity> Keybuk: Well, it might belong there anyway.  But whatever I do, I'll end up uploading both LRM and n-k-c, yeah.
[01:55] <Keybuk> echo foo bar baz | read FOO BAR BAZ
[01:55] <Keybuk> infinity: cool
[01:57] <AnAnt> how can one do field splitting of a variable in dash ?
[01:57] <Keybuk> echo $VAR | read FOO BAR BAZ
[01:58] <Keybuk> anant: http://www.amazon.com/Portable-Shell-Programming-Extensive-Collection/dp/0134514947
[02:11] <Kamion> Riddell: FYI I'm doing a keyboard variant selector for KDE ubiquity now
[02:11] <Kamion> (hence fighting with qt3-designer)
[02:12] <Riddell> Kamion: let me know if you want me to take over
[02:12] <Kamion> I think I've got the hang of it, just fighting with the bizarre layout stuff
[02:13] <Kamion> and its excessive application of fixed geometries
[02:15] <Kamion> it's good for me to be able to do this stuff, anyway
[02:17] <tfheen> Seveas: you've been doing a bit of usplash hacking, haven't you?
[02:17] <Seveas> I have
[02:17] <Seveas> but only the non-difficult parts
[02:18] <simira> mvo: I dig update-manager!
[02:19] <mvo> simira: hello! what do you mean exactly?
[02:19] <Seveas> tfheen, for edgy+1 I have some more usplash plans
[02:19] <cbx33> Seveas: cool
[02:19] <tfheen> Seveas: I need somebody to bounce ideas off, basically, so if you have a bit of time?
[02:20] <tfheen> Seveas: this is for casper; I'm trying to fix https://launchpad.net/distros/ubuntu/+source/casper/+bug/61535
[02:20] <Ubugtu> Malone bug 61535 in casper "usplash progress reporting is not very accurate for casper" [Low,Confirmed]  
[02:20] <tfheen> if I try to use PULSATE, that ends once I call log_end_msg
[02:20] <tfheen> (which is done half a zillion times in casper)
[02:20] <Seveas> hmm
[02:21] <Seveas> log_end_msg calls PROGRESS?
[02:21] <tfheen> log_end_msg calls update_progress which calls usplash_write "PROGRESS", yes.
[02:22] <tfheen> also, it seems like it doesn't actually increase PROGRESS_STATE at all?
[02:22] <Seveas> I'm not too familiar with what log_*_msg do currently
[02:22] <Seveas> let's see
[02:23] <tfheen> look in /usr/share/initramfs-tools/scripts/functions
[02:24] <Seveas> ah, in initramfs log_*_msg is different than in /lib/lsbinit-functions?
[02:24] <Seveas> :q
[02:25] <tfheen> seems like it, yes.
[02:27] <simira> mvo: it asked me if I wanted to do a dist-upgrade
[02:29] <Seveas> tfheen, you might just want to disable the entire progress updating code in /usr/share/initramfs-tools/scripts/functions if you want to pulsate
[02:29] <Seveas> init will reset the progressbar when it takes over
[02:30] <tfheen> Seveas: does anything use pulsate ATM?
[02:30] <Seveas> no
[02:30] <Kamion> Riddell: is there a way to stop qt designer sticking fixed geometry properties all over the place? your .ui file only seems to have them at the very top level
[02:31] <tfheen> any reason why we can't have PULSATE START and PULSATE STOP or something then?
[02:31] <tfheen> hi Henrik
[02:31] <Seveas> forcing people to be careful 
[02:31] <kristog> hello 
[02:31] <simira> hi heno, how's living in Norway?
[02:32] <Riddell> Kamion: you place them roughly where you want them as fixed geometries then click the layout buttons to put them into horizonal/vercial/grid layouts
[02:33] <heno> simira: Hei! Still a bit chaotic, but nice overall :)
[02:33] <Kamion> Riddell: I think I'd broken the top grid layout by accident. It still wants to assign a fixed geometry to the topmost grid layout (the one with the WidgetStack, back, next, cancel, etc. in it), though
[02:33] <Kamion> is there a way to say "just use the whole window"?
[02:33] <simira> heno: yes, all that nice weather and stuff must feel comforting, almost like Bergen :p
[02:34] <Riddell> Kamion: click on the widget background and click the grid layout button in the toolbar and it should put it into a layout again
[02:34] <heno> heh, almost as nice ;)
[02:34] <tfheen> Seveas: well, sure.. I wouldn't consider that a problem, though
[02:34] <Kamion> oh I *see*
[02:34] <Kamion> it didn't occur to me that clicking on the background would be useful
[02:34] <Kamion> thanks
[02:37] <Kamion> ah yes, that works a *lot* better
[02:38] <Seveas> tfheen, making usplash ignore PROGRESS between PULSATE START and PULSATE STOP is trivially implemented though, I can do that in < 10 minutes -- but you may want to run that past mdz/mjg59, now that Ubuntu is rather deep frozen
[02:39] <tfheen> Seveas: sure, it's not the implementation I'm asking about.  I can do that trivially myself.
[02:40] <tfheen> Seveas: do you have another suggestion for how to fix it for the bug I mentioned?
[02:40] <Seveas> semantically I would prefer that initramfs doesn't call PROGRESS if it doesn't want it to be displayed
[02:41] <tfheen> Seveas: oh, true, but my scripts really just call log_msg_end, which they have to for the SUCCESS prompt to be displayed properly.
[02:43] <Seveas> could this work:
[02:43] <Seveas> #!/bin/sh
[02:43] <Seveas> source initramfs-tools/scripts
[02:43] <Seveas> update_progress() { }
[02:44] <Seveas> (aka, turning that into a noop)
[02:44] <tfheen> Seveas: yes, it's possible to work around it.
[03:00] <sivang> cbx33: let me know if you managed to get a hold of pygi
[03:01] <cbx33> ok
[03:07] <tfheen> fabbione: uh, why is https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/62485 assigned to me?
[03:07] <Ubugtu> Malone bug 62485 in linux-source-2.6.17 "[SPARC]  - Regression - Niagara does not reboot properly" [High,Confirmed]  
[03:08] <ogra> tfheen, because that validates you to get some of this nice HW as well ;)
[03:14] <tfheen> Kamion: does ubiquity currently mount the squashfs-es by itself?  I'm looking at fixing https://launchpad.net/distros/ubuntu/+bug/62756
[03:14] <Ubugtu> Malone bug 62756 in Ubuntu "mono confused by the desktopCD" [High,Confirmed]  
[03:14] <Kamion> tfheen: ye
[03:14] <Kamion> yes
[03:15] <Kamion> well, if they aren't already mounted
[03:15] <tfheen> ok, goodie.  I'll just remove that code bit from casper, then
[03:22] <keebler> What would the command be to install usplash-dev on dapper, other than make/make install? dpkg something, iirc.
[03:27] <Kamion> Do any developers object to drescher (the archive publishing machine) being taken down for upgrade at some point on Friday? archive.ubuntu.com will remain available as usual, but there'll be a period when uploads won't be processed.
[03:27] <keebler> Let me rephrase. I downloaded the Usplash-dev source from the FTP. I'm looking to build it on my system, but as I understand it, the conventional method of build won't work. Now I'm confused.
[03:27] <keebler> I'm trying to "backport" it to Dapper, if possible. And mjg59 is afk or somesuch.
[03:27] <Kamion> uh, if you're not familiar with dpkg, I'm not sure that backporting usplash is a good idea, to be honest ...
[03:28] <Kamion> 'dpkg -i foo.deb' is the command to install a single .deb
[03:28] <keebler> Kamion: You're probably right. But I'm trying to learn.
[03:28] <Kamion> that won't process dependencies, unlike apt
[03:28] <Kamion> or at least it won't go and fetch dependencies for you
[03:28] <keebler> Kamion: Well, I'm not looking to install a deb.
[03:28] <tfheen> Kamion: do we have any idea about how much downtime?  I'm fine with it.
[03:28] <Kamion> keebler: sure you are
[03:28] <keebler> Well.
[03:28] <keebler> lol
[03:28] <Kamion> keebler: you asked what the command would be to install usplash-dev; usplash-dev is a .deb
[03:28] <keebler> Not a .deb, trying to build it from source.
[03:29] <keebler> tar.gz
[03:29] <Kamion> oh, dpkg-buildpackage -b
[03:29] <keebler> Thats the one!
[03:29] <Kamion> tfheen: couple of hours
[03:29] <tfheen> Kamion: ok; I don't mind (with any of my hats)
[03:29] <Kamion> well, an hour or two for the dapper upgrade, then about a day for apt-ftparchive to rebuild its cache
[03:29] <keebler> mjg59: Told me, but I lost my last system after getting it to install/build. I'm currently reading the man page, but I was trying to take a shortcut by asking here.
[03:29] <Kamion> that day will probably stretch over into the weekend
[03:30] <tfheen> better then than closer to RC
[03:45] <keebler> Well that rocked. usplash-test.sh (usplash-dev) worked pretty swell on Dapper.
[03:46] <keebler> Or, atleast I think it did what it was supposed to. :) Mostly red and blue, with a progress bar in the middle and various numbers and gradients?
[03:54] <Kamion> keebler: you'll probably want a theme as well
[03:54] <Kamion> rather than the testcard - say usplash-theme-ubuntu
[04:03] <bddebian> Howdy folks
[04:04] <jdong> howdy, bddebian
[04:04] <bddebian> Heya jdong
[04:16] <infinity> mvo: clean targets that call configure are evil.
[04:17] <ogra> ++
[04:17] <ogra> gave me headdaches often enough ... and are used way to often in debian
[04:18] <infinity> Well, I use it in Debian, but only in a semi-intelligent "if we're not unpatching, don't run configure" way, so it's skipped over on a pure source build.
[04:18] <infinity> apt just unconditionally runs it on every clean, afaict.
[04:19] <ogra> yep
[04:19] <infinity> s/configure/autoconf/ rather.
[04:19] <infinity> People running configure on clean should REALLY be shot.
[04:20] <ogra> there are a lot of them ...
[04:20] <mvo> infinity: apt?
[04:20] <ogra> i guess you'd need a machine gun :)
[04:20] <ogra> mvo, apt-get source -b
[04:20] <infinity> mvo: apt runs autoconf on clean to get the version in the configure script.
[04:21] <mvo> infinity: right
[04:21] <infinity> mvo: Not a huge deal, just annoyed me briefly to have to wait for autoconf to get installed before doing a source build. :)
[04:22] <mvo> infinity: I think apt should just get a build-system that is not so "special" ... 
[04:23] <infinity> Err, it also doesn't build-dep on autoconf for that feature.
[04:23] <infinity> Cute.
[04:23] <Kamion> just to get the version? is that all?
[04:23] <Kamion> I did this in ubiquity:
[04:23] <Kamion> VERSION := $(shell dpkg-parsechangelog | awk '/^Version:/ { print $$2 }')
[04:23] <Kamion> AC_VERSION := $(shell grep -w '^AC_INIT' configure.ac | cut -d' ' -f2 | \
[04:23] <Kamion>                         sed 's/[] [,] //g')
[04:23] <Kamion> ifneq ($(VERSION),$(AC_VERSION))
[04:24] <Kamion> $(warning Version $(VERSION) in debian/changelog does not match $(AC_VERSION) in configure.ac!)
[04:24] <Kamion> endif
[04:24] <doko_> infinity: what happended to the gcc-snapshot build on floe(ia64)=
[04:24] <doko_> s/=/?/
[04:27] <infinity> doko_: Looks like floe's having problems with life.  I'll fix.
[04:28] <janimo> seb128: hi, ping re python-gnome2
[04:28] <seb128> janimo: I'm working on it for some days, python-support and random packages are broken making impossible to build python-gnome
[04:29] <seb128> janimo: I've just sorted pyorbit and rebuilt python-gnome 5 min ago
[04:29] <seb128> s/are/were rather
[04:29] <janimo> seb128: ah ok, nice :)
[04:29] <seb128> your patch had some issues, I've fixed them
[04:29] <seb128> like your Conflicts,Replaces was on version 2.6.16
[04:35] <janimo> infinity, tfheen: hi, is anything using stacked filesystems on the liveCD ATM? I'd like to see if that can be used for xubuntu a11y
[04:36] <infinity> janimo: No, there isn't currently.
[04:37] <janimo> infinity: is the code done though? Is this a buildd side thing only?
[04:37] <infinity> janimo: I failed to deliver it in time for beta, so now I'm running an internal "do I defer it, or try to convince people to let it in after the weekend" debate.
[04:38] <infinity> janimo: The casper code is there and appears to work, the buildd side is buggy and not rolled out, and got side-tracked when I missed the beta deadline and had other pressing stuff to attend to all week.  It's a solid day of debugging and work to get it rolled out, I suspect.
[04:39] <janimo> infinity: thanks. I'll have a look at the casper part, in case the buildd side will get done as I see no other way to optionally install a few packages on the liveCD depending on boot menu selection
[04:39] <heno> rodarvus, fabbione: did either of you make changes in xorg relating to wacom tablets? I need some help with this gok bug: https://launchpad.net/distros/ubuntu/+source/gok/+bug/48074
[04:39] <Ubugtu> Malone bug 48074 in gok "gok gives an X Window System error" [Medium,Confirmed]  
[04:39] <Keybuk> janimo: you need to file MIRs for gxine and pyxfce
[04:40] <Keybuk> seb128: likewise for meanwhile
[04:40] <janimo> Keybuk:  I have
[04:40] <janimo> Kemaybe not for pyxfce though
[04:40] <Keybuk> janimo: have you asked pitti to review them?
[04:40] <seb128> Keybuk: pitti approved meanwhile on monday
[04:40] <Keybuk> seb128: so he did, I ken't spel
[04:40] <seb128> :)
[04:41] <janimo> Keybuk: yup, he said he'd get around to it
[04:41] <seb128> https://wiki.ubuntu.com/MainInclusionReportMeanwhile
[04:41] <Keybuk> seb128: promoted
[04:41] <seb128> thank you
[04:41] <seb128> will gaim automatically retry?
[04:41] <Keybuk> Riddell: kiosktool
[04:41] <Keybuk> seb128: I thiiiink so
[04:42] <infinity> seb128: Yes.
[04:42] <seb128> cool
[04:43] <Riddell> Keybuk: what about it?
[04:43] <Keybuk> Riddell: you need an MIR for it
[04:43] <Keybuk> or you need to remove it from your supported seed
[04:44] <Riddell> Keybuk: ok, I'll remove it from the seeds for now, it still needs a root password
[04:44] <Keybuk> okies
[04:46] <jdong> Keybuk: your sed script for fglrx doesn't work
[04:46] <Keybuk> jdong: ?
[04:46] <jdong> jdong@jdong-laptop:~$ cat /etc/X11/xorg.conf 2>/dev/null | sed -n -e '/^[ \\t] *section[ \\t] *"device"/I,/^[ \\t] *endsection/I{/^[ \\t] *driver[ \\t] */I{s/^[ \\t] *driver[ \\t] *"*//I;s/"*[ \\t] *$//;p}}'
[04:46] <jdong> jdong@jdong-laptop:~$                 
[04:46] <jdong> Keybuk: it's not matching anything
[04:46] <jdong> Keybuk: and my xorg.conf does use fglrx
[04:46] <janimo> seb128: do you know if onboard is still in the plan? it's still in universe
[04:46] <Keybuk> jdong: hmm
[04:46] <Keybuk> you need to escape it
[04:46] <Keybuk> modprobe drops one set of \s
[04:47] <jdong> oh
[04:47] <infinity> Being replaces in a few minutes anyway. :)
[04:47] <jdong> let me take a look then
[04:47] <Keybuk> quest scott% sh
[04:47] <Keybuk> $ cat /etc/X11/xorg.conf 2>/dev/null | sed -n -e '/^[ \t] *section[ \t] *"device"/I,/^[ \t] *endsection/I{/^[ \t] *driver[ \t] */I{s/^[ \t] *driver[ \t] *"*//I;s/"*[ \t] *$//;p}}'
[04:47] <Keybuk> nvidia
[04:47] <Keybuk> -- 
[04:47] <jdong> there, that works
[04:47] <jdong> now, why didn't it work the last time I booted...
[04:48] <jdong> AHA
[04:48] <jdong> fglrx.dpkg-old
[04:48] <jdong> stupid dpkg
[04:48] <jdong> ok, rebooting, will come back to yell at you again if I don't get fglrx loaded :D
[04:48] <janimo> Keybuk: removed python-xfce from seeds, as it's not needed by anything essentuial after all
[04:49] <Kamion> jdong: is there something that doesn't ignore .dpkg-old?
[04:49] <Kamion> damn, too late
[04:50] <heno> pitti: about janimo's question, can you (or someone) review onboard?
[04:50] <heno> https://wiki.ubuntu.com/MainInclusionReportOnBoard
[04:51] <pitti> heno: ok, if it's urgent
[04:52] <heno> pitti: it is rather yes, thanks
[04:52] <pitti> heno: quality-wise you are happy?
[04:52] <heno> pitti: I am. Less features but more stable than gok
[04:53] <Keybuk> Kamion: yo
[04:53] <Keybuk> installer seed
[04:53] <jdong> Keybuk: k, works well, nvm
[04:53] <Keybuk> why does the regex for the i386 kernel modules have .*-386-di in it
[04:53] <Keybuk> when all the others just have .*-di ?
[04:53] <pitti> heno: ok, deb and packaging looks fine, I'll approve
[04:54] <heno> pitti: \o/ thanks!
[04:54] <rodarvus> heno, I haven't made any changes related to wacom tablets
[04:54] <Kamion> Keybuk: workaround for a germinate bug that was sucking -generic-di onto the seeds and I didn't know wy
[04:54] <Kamion> why
[04:54] <Kamion> at the time I did that, I didn't have time to investigate properly
[04:54] <Keybuk> don't we WANT -generic-di in the seeds?
[04:54] <Kamion> no
[04:54] <Kamion> well, maybe soon :-)
[04:54] <heno> rodarvus: ok, any idea how that config issue can be worked around?
[04:54] <Keybuk> ext2-modules-2.6.17-10-generic-di | 2.6.17-10.26 | edgy/main/debian-installer | i386
[04:54] <Keybuk> ^ so how come that's in main, and not in anastacia
[04:54] <Keybuk> yet
[04:54] <Kamion> but not right now - the default kernel for the alternate install CD is still -386
[04:55] <Keybuk> cdrom-modules-2.6.17-10-generic-di | 2.6.17-10.26 | edgy/main/debian-installer | i386
[04:55] <pitti> heno: doing p-virtkey now, too
[04:55] <Kamion> please leave them in main
[04:55] <Keybuk> ^ that _is_ in anastacia
[04:55] <Keybuk> ?
[04:55] <Kamion> I'll sort them out and figure out what crack germinate/anastacia are smoking soon
[04:55] <Keybuk> ok
[04:55] <rodarvus> heno, I wasn't here at the time wacom tablets started being automatically added to xorg.conf, but I'd say the fix is not to add them to *every* configuration, as its done currently
[04:55] <Kamion> I don't know exactly what the problem is at the moment, and IIRC it's a bit confusing
[04:55] <rodarvus> (I mean, this happened on dapper development cycle)
[04:55] <Keybuk> I don't want to end up accidentally removing things next time there's an ABI dump ;)
[04:56] <Kamion> just dump the whole kernel into main every time
[04:56] <Keybuk> there'd be in the ultra-long-list that I never read <g.
[04:56] <heno> rodarvus: ok, is that a change we can make now or is it too late
[04:56] <Kamion> at the moment though, I'm trying to beat the string freeze with a few bits and pieces
[04:57] <heno> I think it's the non-core pointer stuff they both do (gok and wacom) that causes the problem
[04:57] <rodarvus> heno, not sure. I'll ask fabbione when he is around (I'm unaware of the implications touching this part of the config might have, and how many users it might affect)
[04:57] <heno> rodarvus: ok, will do, thanks
[04:58] <rodarvus> heno, I subscribed to this bug report, and will talk to fabbione about it - wacom tablets seem to be a source of problem to other users too
[04:58] <dholbach> janimo, Gloubiboulga: did you think about having new gnumeric and new goffice?
[04:58] <dholbach> janimo, Gloubiboulga: it seems to have lots of fixes
[04:58] <pitti> Gloubiboulga, janimo: @ gxine MIR: can you please use the standard template in the future? this report is very short
[04:59] <pitti> Gloubiboulga, janimo: gxine *did* have security issues in the past, too (the report claims not)
[04:59] <janimo> pitti: ok, sorry about that
[04:59] <heno> rodarvus: as does gok. I think we should remove it from main for Edgy+1
[04:59] <janimo> dholbach: you mean a sync from debian? I'll have alook
[05:00] <dholbach> janimo: not sure if debian has it already
[05:00] <dholbach> I don't think so
[05:00] <dholbach> it was just released or a day ago
[05:00] <janimo> dholbach: hmm it needs an UVF exception I assume?
[05:00] <janimo> even if its not on the ubuntu CD
[05:01] <dholbach> I suppose so - is it on the xubuntu cd?
[05:01] <janimo> it is, yes :)
[05:02] <janimo> dholbach: just that I am entirely unfamiliar with gnumeric source and devs to asses if it's better to have this except by lookign at the changelog
[05:02] <dholbach> janimo: and new goffice and gsf too
[05:02] <janimo> but it;s a point release so I guess it ihas to be better :)
[05:02] <dholbach> janimo: I just saw it on the ftp-release list and saw the list of things it fixes (from the news file)
[05:02] <dholbach> just as a headsup :)
[05:03] <pitti> janimo: what do you use right now as media player in xubuntu? (any chance we can drop a package in favor of gxine?)
[05:03] <pitti> Keybuk: can you please approve the langpacks in dapper-proposed?
[05:03] <janimo> pitti, it was xfmedia and is no longer in the seeds
[05:04] <pitti> ah, nice
[05:04] <janimo> dholbach: thanks ;)
[05:04] <pitti> janimo: ok, approved; I'll process this dict-plugin now, then the queue is reasonably clean again
[05:05] <janimo> seb128: are you going to look at python-gnome2-extras or should I make a patch for similar breaking out binaries?
[05:05] <janimo> pitti: \o/
[05:05] <seb128> janimo: I doubt we are going to split extras for edgy
[05:05] <seb128> janimo: what to split will not be that easy to decide for it
[05:05] <janimo> seb128: at least the gtkhtml2 part, it is needed by gnome-app-install. 
[05:06] <seb128> not for edgy
[05:06] <janimo> the main reason why I started the discussion
[05:06] <Keybuk> pitti: do you have bugs for each, with debdiffs?
[05:06] <janimo> gconf was worked around in u-m
[05:06] <janimo> that is not possible with gtkhtml2
[05:06] <janimo> not all the small bits, but this single gtkhtml2 so
[05:06] <janimo> as simole as gconf and canvas
[05:06] <pitti> Keybuk: mdz was fine to special-case them :)
[05:07] <Keybuk> pitti: *shrug* I'm not going near them if they break the policy
[05:07] <janimo> s/simole/simple/
[05:07] <pitti> Keybuk: but he wanted to use the proposed->updates staging
[05:07] <Keybuk> not unless you have signatures from mdz and sabdfl in triplicate :)
[05:07] <seb128> janimo: I understand that you want to split gtkhtml2, we might want to split other parts too, needs some discussion
[05:07] <janimo> seb128: so to not make it too compliated when we converge with debian when they split,
[05:07] <janimo> we can just take a single package out whioch they will surely split as well
[05:07] <seb128> I'll think about it later
[05:08] <janimo> seb128: ok, I only said the single one to keep it as simple as possible
[05:08] <janimo> seb128: ok, thanks
[05:08] <seb128> np
[05:08] <Keybuk> pitti: sorry to be silly; but there's a written policy, and threats of dire consequence to one's employment if it's not obeyed
[05:08] <pitti> Keybuk: ok, can you then please approve cupsys (bug 54277) and hal (bug 56484) uploads?
[05:09] <elmo> uploads and builds are going to be down for an hour or so while the ftp-master machine is upgraded
[05:09] <elmo> apologies for the inconvenience
[05:10] <Keybuk> pitti: err. in an hour, apparently ;)
[05:10] <pitti> Keybuk: I can forward you mdz's mail about that topic, or do you want to ask him yourself?
[05:10] <pitti> Keybuk: heh, ok :) bad timing
[05:10] <Keybuk> pitti: I probably won't catch him this evening (gym day)
[05:10] <Keybuk> I'll e-mail him for confirmation
[05:10] <pitti> Keybuk: ok, thanks
[05:13] <pitti> janimo: '#!/usr/bin/make -f\ninclude /usr/share/cdbs/1/class/xfce.mk' <= that's the whole debian/rules? remarkable :)
[05:14] <Keybuk> sfllaw: errr, ping
[05:14] <jdong> dholbach: I put diffstats and changelogs on the wine uvf request
[05:14] <dholbach> jdong: cool
[05:15] <dholbach> jdong: it says so on http://wiki.ubuntu.com/MOTU/Processes/UVF - else it's always hard to judge
[05:15] <jdong> dholbach: yeah, I noticed that document after filing that UVF
[05:15] <dholbach> ok
[05:15] <jdong> dholbach: my 2nd one (x264) was much more thorough :)
[05:17] <janimo> pitti, yup I chuckled when I saw that as well :) (Gauvain packaged that one)
[05:22] <bddebian> Gawd I hate my freakin' life somedays.. :'-(
[05:22] <bddebian> Oops, wrong chan, sorry
[05:22] <jdong> lol
[05:22] <pitti> bddebian: indeed, in this channel it is required to be happy when writing 
[05:23] <jdong> bddebian: stop trying to package azureus!
[05:23] <bddebian> pitti: It's the second happiest place on earth? ;-)
[05:23] <zul> pitti: heh like shiney happy people
[05:23] <bddebian> jdong: Heh, I WISH that was what I was working on..
[05:23] <seb128> what is the first one?
[05:23] <bddebian> seb128: DisneyWorld, of course :-)
[05:23] <heno> BenC: did you have to do a lot of code cleanup to get the speakup stuff into the kernel? (I'm trying to nudge the speakup people to try to get it into the default kernel)
[05:24] <BenC> heno: Not really...I cleaned up the keyboard.c changes so it was a bit cleaner, but other than that, it was pretty straight forward
[05:25] <heno> BenC:  Coding style was ok too?
[05:25] <BenC> heno: I didn't really review it that much
[05:26] <heno> ok, thanks
[05:26] <BenC> but that's what the lkml is for...if they send a patch for inclusion, they'll get a lot of feedback
[05:27] <BenC> just the little bit of code review I did found one bug with the locking of the prov file, I'm sure the lkml will find others, and generally improve the code
[05:27] <BenC> *proc
[05:27] <heno> BenC: yep, seems they did that got some constructive feedback but didn't take it very well and ran away
[05:27] <heno> They might just need some guidance through that process
[05:27] <BenC> heno: you have to have pretty tough skin to get through that process
[05:28] <BenC> but it's worth it, if only for the code and the users of it
[05:28] <heno> Yep, that's what I'll be telling them :)
[05:28] <BenC> hell, I've been trying to get a single document in the kernel, not even code, and I've been in the process for months now
[05:29] <BenC> mostly due to me not having time between edits, but still :)
[05:31] <zul> heh excuses excuses :)
[05:31] <zul> ..ill shut up and get back to what i was doing
[05:33] <Chipzz> 17:33 <@Chipz> I go back upstairs, announce a reboot of defcon1 in 10 minutes, and do sleep 300 ; shutdown -r 0
[05:33] <Chipzz> hrrrm
[05:33] <Chipzz> wrong channel
[05:34] <Ng> ok folks, uploads and builds should be going again, the ftp-master machine upgrade is done.
[05:34] <thom> Chipzz: are we allowed to laugh at you for doing sleep... shutdown anyway?
[05:35] <Chipzz> thom: you lack some mathematecial skills my dear friend ;)
[05:36] <thom> well, no
[05:36] <thom> you lack some manpage skills _and_ some mathematical skills
[05:36] <Chipzz> thom: you obviously never read http://bofh.ntk.net/bastard.html
[05:37] <Chipzz> which that was actually a parody of :P
[05:37] <thom> parody is supposed to be funny. anyway, i still intend to laugh at you for using sleep then shutdown
[05:37] <sfllaw> Keybuk: errr, pong?
[05:37] <jdong> grr, how do I get pbuilder to do some make parallelism?
[05:38] <Chipzz> thom: then again, it was torn out of context, and never intended to be pasted here
[05:38] <jdong> I'd love for my second core to be doing some work
[05:38] <Keybuk> sfllaw: you were inventing times for the team meeting?
[05:38] <Chipzz> s/torn/ripped/
[05:40] <sfllaw> Keybuk: I was?
[05:40] <sfllaw> Oh, I misread the time, didn't I?
[05:40] <sfllaw> Sorry.
[05:40] <Keybuk> sfllaw: 19:00Z ?
[05:41] <Keybuk> you mean 0700 UTC
[05:41] <sfllaw> Well, 07:00Z is fine as well.
[05:41] <Keybuk> (the Z is a curiously american thing that most people probably won't recognise, btw)
[05:41] <popey> zulu?
[05:41] <popey> I thought it was a Military thing
[05:42] <sfllaw> Uhm, that's obviously me being super archaic by accident.
[05:42] <sfllaw> I'll resend.
[05:43] <Keybuk> I could be extremely pedantic at this point, and go on to point out that Zulu time, GMT and UTC are not the same thing
[05:43] <Kamion_> http://wwp.greenwichmeantime.com/info/timezone.htm
[05:43] <Keybuk> but I won't ;)
[05:43] <Kamion_> I always assumed that zero => Z => Zulu, but evidently not
[05:44] <sfllaw> Z is the zero time zone.
[05:44] <sfllaw> Which is GMT.
[05:44] <sfllaw> Which is UT1.
[05:44] <Keybuk> no
[05:44] <Keybuk> Z is UTC
[05:44] <Keybuk> which is almost, but not quite, precisely the same as GMT
[05:44] <Keybuk> they can be different by as much as 2-5 seconds
[05:44] <infinity> Either way, Zulu isn't an "American thing".
[05:44] <Keybuk> usually no more than 1-2s though
[05:45] <sfllaw> Resent.
[05:45] <infinity> It's used for military and aerospace all over the world.
[05:45] <Kamion_> sfllaw: as the above link notes, it's a mapping of letters of the alphabet to zones, rather than z => zero
[05:46] <Keybuk> infinity: either way, it's not that appropriate for a u-d-a mail ;)
[05:46] <infinity> :)
[05:46] <sfllaw> Kamion_: I think the timezones start from Z at Greenwich and are split in two by it.
[05:46] <sfllaw> So it really is zero.
[05:47] <heno> sfllaw: so east and west london are in separate time zones? :)
[05:49] <Keybuk> When a positive leap second occurs, it is denoted as "23:59:60" in UTC
[05:49] <Keybuk> ...interesting
[05:49] <Keybuk> I wonder how many millions of lines of code fail to parse that? :)
[05:51] <elmo> heno: next time I'm late to the office, that's so going to be my excuse
[05:52] <elmo> "I had to cross a timezone to get here!!"
[05:53] <popey> there was a leap second last new year
[05:53] <popey> iirc
[05:53] <sivang> heno: I have a certificate that I stood up on the 0 degree line :-)
[05:53] <Keybuk> popey: there was
[05:53] <Keybuk> UTC is now 0.4 seconds ahead of GMT
[05:54] <Keybuk> or is it behind?
[05:54] <popey> heh
[05:54] <Keybuk> sivang: the 0 degree line goes through my dad's old house
[05:54] <Kamion> elmo: how do you define "late to the office"? :-)
[05:55] <Keybuk> Kamion: turning up on Tuesday morning, bright and fresh for work on Monday
[05:55] <sivang> Keybuk: wow cool, I was really amazed by the green park straight off Greenwich pier and the excellent mushroom soup serving tea house in it's middle.
[05:56] <Keybuk> there's a little statue on the south coast where the meridian enters the UK
[05:56] <pitti> argh, whoever designed the banshee UI deserves a hit on the head
[05:56] <pitti> HiddenWolf: that's what I'm using usually, I just installed banshee to debug an apport issue ;)
[05:57] <HiddenWolf> Good luck. :)
[05:57] <fabbione> heno, rodarvus: no, i made no changes. the wacom stuff comes from mjg59 
[05:58] <Keybuk> sivang: og?
[05:58] <Keybuk> of?
[05:59] <rodarvus> fabbione, thanks for clearing this up
[05:59] <rodarvus> mjg59, ping :)
[05:59] <sivang> Keybukkyou know me, can't type and can barely walk :-)
[05:59] <Keybuk> http://www.flickr.com/photos/leewalton/89309189/
[06:00] <heno> mjg59: I know you would recommend people use dasher, but could you help us unbreak gok anyway? :)
[06:03] <Kamion> ok, this should be a worthwhile ubiquity change, for those who watch its bug list
[06:04] <Kamion> +  * Catch ENOENT, EIO, ENOTDIR, and EROFS while copying files, try to figure
[06:04] <Kamion> +    out what filename they relate to, and display a useful error message
[06:04] <Kamion> +    explaining that this is probably a CD or hard disk fault (as
[06:04] <Kamion> +    appropriate) and how to deal with this. Closes about a million bugs.
[06:04] <Kamion> won't catch all the weirdness, since after all ubiquity is running off the CD, but ...
[06:04] <sivang> Keybuk: http://muse.19inch.net/~sivan/P1030888.JPG my gf standing next to the line, better put her's photo then my fat self :-)
[06:05] <Keybuk> of course, the absolute best thing about the zero meridian is that it doesn't run through Paris ;)
[06:05] <sivang> Keybuk: how so?
[06:06] <thom> sivang: geography?
[06:06] <sivang> s/how so/why so/
[06:06] <sivang> thom: ^^
[06:06] <sivang> ;-)
[06:09] <Ng> Keybuk: the current one at least ;)
[06:11] <Keybuk> sivang: France wanted it to go through Paris, and even after it was decided it would go through London, sulked and for decades continued to ignore that and use one that went through Paris on all of their maps
[06:16] <Keybuk> sivang: of course, the line you stood on is actually just over 100m from the modern meridian ;)
[06:26] <jdong|laptop> Kamion: what are your thoughts towards a ntfsprogs 1.13 sync from debian?
[06:26] <jdong|laptop> Kamion: 1.13 adds support for dealing with hardware faults
[06:26] <jdong|laptop> (bad sectors, IO errors)
[06:28] <Kamion> jdong|laptop: feel free to send me a mail
[06:29] <jdong|laptop> Kamion: will do
[06:34] <JB[away] > moin
[06:35] <sivang> Keybuk: ah, so *where* is the modern meridian? :-)
[06:35] <JB[away] > pitti are you here ?
[06:36] <pitti> JB[away] : yes
[06:37] <Keybuk> sivang: like I said, about 100 metres to the east
[06:37] <JB[away] > pitti: you know my bug report?
[06:37] <twb> Is 6.10b known to (not) work under Qemu (with kQemu loaded)?
[06:37] <JB[away] > https://launchpad.net/distros/ubuntu/+source/apache2/+bug/62820
[06:37] <Ubug2> Malone bug 62820 in apache2 "RPC over HTTP" [Undecided,Unconfirmed]  
[06:37] <pitti> JB[away] : the apache2 one with mod-proxy?
[06:37] <JB[away] > yes
[06:38] <JB[away] > i read on the changelog
[06:38] <JB[away] >  Add 048_reverse_proxy_fix, to resolve a regression in 2.0.55 with
[06:38] <JB[away] >       mod_proxy, mod_ssl and HTTP POST requests (upstream bug #37145)
[06:38] <Ubug2> Malone bug 37145 in linux-source-2.6.15 "UniChrome Pro IGP not shown in lspci; X doesn't work" [Medium,Needs info]  http://launchpad.net/bugs/37145
[06:38] <JB[away] > that is fix ?
[06:38] <pitti> JB[away] : maybe
[06:39] <pitti> I didn't check
[06:39] <JB[away] > for me dont work 
[06:39] <JB[away] > i think adam do a mistake
[06:42] <thom> hrm, how does one teach ubugtu that apache's bugzilla is at http://issues.apache.org/bugzilla/ ?
[06:43] <HiddenWolf> thom: one talks to Seveas
[06:44] <thom> JB[away] : those two look unrelated at first glance
[06:45] <thom> in fact, see http://issues.apache.org/bugzilla/show_bug.cgi?id=37145#c23 and c24
[06:46] <Ubug2> issues.apache.org bug 37145 in mod_proxy "data loss with httpd-2.0.55 reverse proxy method=post" [Critical,Resolved: fixed]  
[06:47] <thom> Seveas: apache's bugzilla is at http://issues.apache.org/bugzilla/ ; please could you do the correct magic to teach ubugtu about it?
[06:47] <JB[away] > thom @ Ubug2 see my Bug Report on https://launchpad.net/distros/ubuntu/+source/apache2/+bug/62820
[06:47] <Ubug2> Malone bug 62820 in apache2 "RPC over HTTP" [Undecided,Unconfirmed]  
[06:48] <thom> JB[away] : yes, i have seen that one
[06:48] <thom> that is why i said "those two look unrelated"
[06:48] <JB[away] > the bug is fixed on 2.0.56
[06:48] <JB[away] > but not in ubuntu apache packages
[06:48] <sivang> Keybuk: ^^
[06:49] <JB[away] > today i read the changelog and the bug was fixed but not really
[06:49] <sivang> Keybuk: that's lots of greens very different to our lots of brown and yellow landscape.
[06:49] <thom> JB[away] : no, the patch that fixed 37145 was applied. THAT IS NOT THE BUG YOU ARE SEEING
[06:50] <JB[away] > ???
[06:51] <JB[away] > you mean the problem is not fixed?
[06:52] <pitti> JB[away] : that's why the bug is still open
[06:52] <thom> there is no reason that the patch that was applied would fix the bug you are reporting
[06:53] <JB[away] > is this a apache problem or ubuntu guys?
[06:53] <thom> it could just as well be a connectivity issue between the proxy and the upstream server
[06:54] <thom> since the errors are saying "we timed out trying to get content from blah"
[06:54] <JB[away] > on debian sarge with 2.0.54 works fine
[06:54] <JB[away] > with same config
[06:58] <thom> on the same machine? with the same networking?
[06:58] <JB[away] > same network config
[06:58] <JB[away] > but not same machine
[07:16] <Seveas> @bugtracker add apache bugzilla http://issues.apache.org/bugzilla/ Apache
[07:16] <Seveas> apache bug 37145
[07:16] <Ubugtu> Apache bug 37145 in mod_proxy "data loss with httpd-2.0.55 reverse proxy method=post" [Critical,Resolved: fixed]  http://issues.apache.org/bugzilla/show_bug.cgi?id=37145
[07:17] <Seveas> thom, --^
[07:17] <JB[away] > Critical,Resolved: fixed :)
[07:17] <thom> Seveas: grazi mille
[07:17] <thom> JB[away] : it's still NOT the same bug
[07:18] <JB[away] > than i must to create a new bug report to apache?
[07:20] <thom> no, please don't
[07:23] <JB[away] > thom why not?
[07:31] <thom> you have filed the bug on your distribution of choice
[07:31] <thom> let them sort out whether it should go upstream or not
[07:32] <JB[away] > i dont think that ubuntu fix the bug :)
[07:32] <BenC> how do I check on the build status of a dapper-proposed upload of linux-source-2.6.15?
[07:33] <Keybuk> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15
[07:33] <BenC> Keybuk: it doesn't show up in there
[07:33] <Keybuk> oh, that's missing  proposed
[07:33] <BenC> I uploaded it awhile back
[07:33] <Keybuk> ahh
[07:33] <Keybuk> did you have it approved yet?
[07:33] <BenC> guess not :)
[07:33] <Keybuk> that would be why then
[07:34] <BenC> can I get it approved?
[07:34] <BenC> mdz: Can I get approval on the dapper-proposed upload of 2.6.15?
[07:38] <jdong|laptop> BenC: how's my favorite kernel guy doing today :D
[07:38] <BenC> jdong: so far, great...how about you?
[07:39] <BenC> jdong: I have your patch ready for a final kernel upload tomorrow
[07:39] <jdong|laptop> BenC: awesome. i'm doing just fine. edgy's looking really nice now :)
[07:40] <BenC> feh, edgy's old news :)
[07:40] <jdong|laptop> crimsun: are you around?
[07:40] <BenC> Linux gullible 2.6.19-1-generic #4 SMP Wed Oct 4 12:24:59 EDT 2006 i686 GNU/Linux
[07:40] <jdong|laptop> BenC: LOL wow
[07:40] <jdong|laptop> BenC: is that recommended? ;0
[07:40] <jdong|laptop> ;)
[07:40] <mdz> BenC: is there an email somewhere in my inbox about it?  it's a bit full at the moment and I didn't see it
[07:40] <mjg59> BenC: Uh. You want to do the final kernel upload tomorrow?
[07:41] <BenC> mdz: No, I wasn't aware that we needed approval for proposed, thought it was only for -updates
[07:41] <jdong|laptop> crimsun: http://ubuntuforums.org/showthread.php?t=270676
[07:41] <BenC> mjg59: Near final...I'm almost sure we'll have some last minute stuff..I uploaded bcm43xx patch today though
[07:41] <mdz> BenC: the procedure is at http://wiki.ubuntu.com/StableReleaseUpdates
[07:41] <mdz> I emailed about it but only to -devel
[07:41] <jdong|laptop> crimsun: this user seems to report that the acer alc883 probleem still exists in dapper
[07:41] <BenC> mdz: I saw it, and read it, but I guess I misunderstood that part :)
[07:42] <mjg59> BenC: There's still several regressions that need fixing up
[07:42] <BenC> mjg59: Yeah, there's quite a few
[07:43] <BenC> there's at least one suspend regression from dapper
[07:43] <mdz> BenC: maybe it could be more explicit
[07:44] <jdong|laptop> mjg59: are you aware of but 61711?
[07:44] <jdong|laptop> bug 61711 even
[07:44] <Ubugtu> Malone bug 61711 in usplash "no boot splash and very slow booting" [Undecided,Confirmed]  http://launchpad.net/bugs/61711
[07:44] <mdz> we want to have some discussion about the update ideally before it's prepared
[07:44] <jdong|laptop> mjg59: that nabbed me on my other amd64 box
[07:44] <mjg59> jdong|laptop: Yes
[07:44] <mjg59> jdong|laptop: Nvidia?
[07:44] <jdong|laptop> yep
[07:44] <jdong|laptop> nforce mobo
[07:44] <mjg59> jdong|laptop: Yes, so it's the same one you told me about before?
[07:45] <jdong|laptop> mjg59: no
[07:45] <jdong|laptop> mjg59: each of my 3 boxes has a different usplash bug :)
[07:45] <Kamion> hmph, bug 61576 is going to be a bit of a pain to fix
[07:45] <Ubugtu> Malone bug 61576 in kickseed "Disk selector appears with kickstart " [Undecided,Confirmed]  http://launchpad.net/bugs/61576
[07:45] <Kamion> finding the first device is easy - list-devices disk | head -n1
[07:45] <BenC> mdz: Why is it so hard to get stuff into proposed...I would have expected -proposed to be a little slack, and -updates to be difficult
[07:45] <Kamion> but you can't assume that hard disk devices are available until after hw-detect has run
[07:46] <Kamion> and IIRC there's no hook between hw-detect and partman
[07:46] <mjg59> jdong|laptop: Ok. It's almost certainly the same thing.
[07:46] <BenC> mdz: I never want to migrate my kernels from -proposed to -updates, for example...it's just an "official" testing facility for me
[07:46] <Kamion> I think I might have to have kickseed install its own partman script ...
[07:46] <mdz> BenC: the idea of -proposed is to stage the update; we don't want things to go into -proposed unless there's certain to be a corresponding -updates upload
[07:46] <mdz> BenC: so we need to agree in advance about the appropriateness of the upload
[07:47] <BenC> mdz: because of the -updates/-security weirdness, that'll surely never happen for me
[07:47] <jdong|laptop> mjg59: ok, if you say so
[07:47] <jdong|laptop> mjg59: would you know why my vt's are corrupted on my ATI?
[07:47] <jdong|laptop> mjg59: bug 63558
[07:47] <Ubugtu> Malone bug 63558 in usplash "Latest usplash leaves my consoles corrupted" [Low,Confirmed]  http://launchpad.net/bugs/63558
[07:47] <jdong|laptop> mjg59: it used to work before the last usplash upload :)
[07:48] <BenC> mdz: I don't think -proposed is what I want for these kernels, but that leaves me with no place to have them available for broad testing
[07:48] <mdz> BenC: what kind of things do you want to publish?
[07:49] <BenC> mdz: What I want is to be able to patch up kernels with a lot of simple, but important fixes (missing PCI ID's, sound fixes, patches backported from edgy, etc...)
[07:50] <BenC> the jmicron thing for example, so people can install dapper on these new core 2 duo's, and the scsi_slave fix like what porkpie in #ubuntu-kernel needs
[07:50] <elmo> Kamion: dude, will edgy on powerpc let me do root raid?
[07:51] <mdz> BenC: -backports?
[07:51] <mdz> either -backports or a PPA
[07:51] <BenC> PPA == personal package archive?
[07:51] <infinity> We don't do direct uploads to -backports, and PPA doesn't exist. :)
[07:52] <jdong|laptop> backports probably won't work too well for this purpose
[07:52] <BenC> infinity: how does -backports work?
[07:53] <jdong|laptop> BenC: a script automagically pulls an edgy source package, mangles the version, and sends it to build
[07:53] <jdong|laptop> no source modification is allowed, etc
[07:54] <BenC> oh, yeah, that's not what I want
[07:54] <jdong|laptop> right
[07:54] <BenC> *sigh*
[07:54] <BenC> I need -proposed-never-send-to-updates
[07:54] <BenC> it's not even that bad :)
[07:54] <infinity> BenC: What you really want is PPA, mdz is right, it just doesn't exist yet.
[07:55] <mdz> infinity: we can do direct uploads to -backports
[07:55] <Kamion> elmo: I've heard reports of broken RAID in the edgy installer, so at the moment I can't say for sure
[07:56] <elmo> doh
[07:56] <mdz> we had a policy against it, but the last time this came up the consensus was that modified source uploads from -core-dev were OK for backports
[07:57] <infinity> mdz: Does the upload policy actually allow for it currently?
[07:57] <jdong|laptop> mdz: I've recently heard that soyuz was locked down to disallow even core-devs?
[07:57] <infinity> At any rate, this hardly qualifies as a "backport", so still feels like a bad fit.
[07:57] <jdong|laptop> infinity: can you still check the source for me?
[07:58] <jdong|laptop> infinity: I got a few backports up my sleeve if that's the case
[08:01] <mdz> infinity: that part is unknown
[08:01] <mdz> infinity: (the upload policy)
[08:02] <mdz> I'm not sure whether the upload policy for -backports actually enforces the way we have been using it, to be honest
[08:02] <mdz> infinity: from Ben's description, it sounds like select backported fixes
[08:02] <mdz> it's actually the "backported support for new hardware" channel that has been discussed but is not properly specified yet, much less implemented
[08:06] <BenC> basically it is backported patches
[08:06] <BenC> but they are also patches that I want migrated eventually into dapper point releases
[08:07] <BenC> some of them need installer/cd rebuilds in order to test (like jmicron)
[08:07] <mdz> hmm
[08:07] <BenC> this is only something I would need for dapper too
[08:07] <mdz> we don't yet have a proper plan for how to provide updated installer/cd builds for new hardware support in older releases; it's something we should talk about in november
[08:07] <BenC> edgy isn't going to be as important for this
[08:08] <BenC> mdz: Can I get my kernels blindly accepted into -proposed for now given that they aren't going to be considered for -updates, and I have no other channel? Until november where we can discuss a better plan?
[08:09] <mdz> BenC: they will be clobbered by later uploads destined for -updates anyway
[08:09] <BenC> mdz: Not really, I had setup the ABI for these as -50, so that -security never clobbers them
[08:10] <BenC> but I will be merging -security stuff into these kernels as they come out
[08:10] <mdz> BenC: they're built from the same source, though, no?
[08:10] <BenC> seperate git branch
[08:10] <mdz> we can't have two versions of the same source package in -proposed
[08:10] <BenC> same .orig.tar.g
[08:10] <BenC> there will only be one version in -proposed
[08:11] <mdz> you have 1) a kernel which isn't destined for -updates, but which you want built and published for testing, and 2) a kernel which is destined for -updates, fixing regressions in dapper
[08:11] <mdz> no?
[08:12] <BenC> mdz: Because of the -updates/-security cross version brokeness that I've been warned about, the updates would eventually migrate to -security uploads with a security release
[08:12] <BenC> so dapper has two git tree's (same .orig.tar.gz base)...the -security is just the same kernel we've always had
[08:13] <jdong|laptop> mdz: does dapper-updates take universe packages?
[08:13] <mdz> but non-security changes should be staged in -proposed now
[08:13] <mdz> jdong|laptop: sure
[08:13] <jdong|laptop> k
[08:13] <mdz> at the discretion of MOTU
[08:13] <BenC> mdz: That's where I wanted to stage them
[08:13] <mdz> BenC: we're talking about two different sets of non-securiy changes, though, right?
[08:14] <BenC> mdz: But when they get enough testing, and are approved, they would have to be migrated with a security upload
[08:14] <mdz> yes
[08:14] <mdz> agreed
[08:14] <BenC> so nothing ever goes into -updates
[08:14] <BenC> do you want to discuss this over the phone?
[08:15] <BenC> might be easier to explain
[08:15] <zul> maybe have a edgy-git kernel in universe
[08:15] <mdz> ok
[08:15] <mdz> landline?
[08:26] <sabdfl> mjg59: really love the new usplash!
[08:37] <BenC> mdz: StableReleaseUpdates is updated
[08:39] <jdong> sabdfl: yeah, it really does rock (when it works!)
[08:39] <jdong> sadly, each of my 3 boxes has a unique usplash bug :)
[08:41] <mdz> BenC: thanks, will have a look
[08:42] <LaserJock> does StableReleaseUpdates apply equally to Universe?
[08:47] <LaserJock> mdz: ^^? or do you want MOTUs to decide that?
[08:48] <mdz> LaserJock: the latter
[08:49] <mdz> though I strongly recommend using StableReleaseUpdates or something very close to it
[08:49] <jdong> mdz: so currently does backports allow core-dev to do manual uploads?
[08:49] <jdong> I'd like to do a backport of edgy's readahead
[08:50] <LaserJock> mdz: should we be using -proposed too? or is that too much archive-admin work
[08:50] <jdong> I've tested it well, and the only source mod it needs is to have Dapper's boot.list put back in
[08:50] <mdz> jdong: I do not know whether that is the case
[08:50] <mdz> but that is how it should work
[08:51] <mdz> it will need a Launchpad admin to confirm
[08:51] <jdong> hmm, what would happen if a core-dev uploads, and it's not the case?
[08:51] <jdong> woudl it just get rejected?
[08:53] <mdz> jdong: same answer; I'm not sure
[08:53] <mdz> it depends on exactly how it's set up on the launchpad side of things
[08:53] <jdong> ok
[08:59] <Kamion> I'm not sure either, but chances are either a reject or dropped-on-the-floor in such a way that only archive admins can find out why
[09:02] <jdong> mdz: would you be OK with a backport of https://launchpad.net/products/dapper-backports/+bug/63275
[09:02] <Ubugtu> Malone bug 63275 in dapper-backports "readahead-list " [Undecided,Confirmed]  
[09:02] <jdong> mdz: I have tested it very extensively on my machines
[09:02] <jdong> I've made this procedure as a forum howto and received no negative feedback on it
[09:05] <mdz> jdong: it only changes the file list, right? absolutely
[09:06] <jdong> mdz: well, my only modification is to revert the file list to dapper's list. Edgy's list doesn't make sense on dapper
[09:06] <mdz> jdong: oh, so you want to backport edgy readahead minus the list changes?
[09:06] <mdz> I'm OK with that as well
[09:06] <jdong> mdz: correct
[09:07] <seaLne> does anyone know whether encrypted root should work in edgy?  i've seen some debian bug reports but not sure if they effect us
[09:07] <jdong> mdz: we all love faster bootups :)
[09:10] <jdub> argh, python-2.5
[09:11] <LaserJock> anybody seen jono today?
[09:39] <jdong> seb128: do you have a moment?
[09:47] <jdong> Kamion: Tonio_ uploaded the readahead-list backport... does anything appear to be happening at your end?
[09:49] <Kamion> Listing ubuntu/dapper-backports (UNAPPROVED) 1/1
[09:49] <Kamion> ---------|----|----------------------|----------------------|---------------
[09:49] <Kamion>   104064 | S- | readahead-list       | 1:0.20050517.0220-0u | nine minutes
[09:49] <jdong> ooh, so it worked and landed in unapproved?
[09:49] <infinity> Apparently.
[09:49] <jdong> Kamion: can you approve it? :)
[09:51] <Kamion> just done
[09:51] <seb128> jdong: pong
[09:52] <Kamion> seems to have worked perfectly
[09:52] <jdong> seb128: the nautilus 100% CPU usage bug has been really plaguing me recently
[09:52] <Kamion> (famous last words)
[09:52] <jdong> seb128: I can perfectly reproduce it... how can I help you get more debug info about it?
[09:52] <seb128> jdong: ah, I didn't hear of it for some time
[09:53] <seb128> jdong: describe a way to get it
[09:53] <seb128> the issue is that I don't get it, so not easy to debug
[09:53] <jdong> seb128: open up a nautilus to your home folder or somewhere else
[09:53] <jdong> seb128: in the same folder, do " mencoder test.avi -o test2.avi -oac copy -ovc copy"
[09:53] <jdong> to create a new avi, and slowly stream some data into it
[09:54] <jdong> refresh nautilus a few times
[09:54] <jdong> and watch CPU usage skyrocket
[09:54] <_MMA_> Hello room. My name is Cory. (MetalMusicAddict on the forums) Im heading the Mubuntu Project: https://wiki.ubuntu.com/Mubuntu Is there someone I can speak with who is good at creating meta-packages?
[09:55] <seb128> _MMA_: "good at" is not easy to determine, better to ask your question
[09:55] <seb128> I assume a bunch of people there know about how to do one
[09:55] <sivang> _MMA_: essentially a meta package just exists to depend on other packages
[09:55] <_MMA_> I dont know how to make them. I need someone to help me on my team. :) I guess thats the short of it.
[09:55] <sivang> _MMA_: you can take as an exampl eubuntu-desktop
[09:55] <jdong> seb128: using that procedure reproduces the bug 100% of the time for me....
[09:56] <Ubugtu> Malone bug 100 in rosetta "uploading po file overwrites authors list" [Medium,Fix released]  http://launchpad.net/bugs/100
[09:56] <_MMA_> I know.
[09:56] <sivang> sorry, ubuntu-desktop
[09:56] <jdong> seb128: it's really irritating when it causes a 12-hour encode to take twice as long :)
[09:56] <sivang> see how it was built, and try to immitate, replacing the package name and switching in your dependencies
[09:57] <_MMA_> Honestly, Im looking for a team member. I have so much to do myself now as it is. Im good at figuring things out if I have the time. Time is the one thing Im lacking.
[09:58] <_MMA_> Im here "recruiting". If someone has the time.
[10:00] <seb128> jdong: spatial or browser mode, icon or list view?
[10:00] <seb128> jdong: no issue with a few tries on my box
[10:00] <jdong> seb128: spatial mode, icon view
[10:00] <jdong> refreshing a few times while the avi is generating leads to the problem
[10:00] <jdong> (you gotta catch it while the avi is generating)
[10:00] <seb128> _MMA_: not the right change to recrut, most of people here are already overworked, better trying #ubuntu-motu
[10:01] <seb128> jdong: ok, thank you, I'll try to get it that way
[10:01] <jdong> mencoder test.avi -o test2.avi -oac copy -ovc x264 -x264encopts bitrate=400
[10:01] <jdong> that should give you ample time :)
[10:01] <seb128> is nautilus having the thumbnail update clock when you get the issue?
[10:01] <Kamion_> jdong: I must say I'm not overly convinced that the "only ubuntu-core-dev can upload directly to backports" rule is implemented; it looks like just the normal component checks are applied
[10:02] <Kamion_> jdong: however, that's ok, because it all lands in unapproved anyway and we can check it
[10:02] <Kamion_> (sorry, not sure if you saw me say that earlier because I think I had already dropped off)
[10:03] <_MMA_> seb128: Ok. I thought that channel was more for maintaining Universe. Ill give 'em a ring, see what happens. Thank you.
[10:05] <seb128> _MMA_: it is for universe, the point is than most of people on #ubuntu-devel are already doing lot of things and not likely wanting to step to work on a new subproject
[10:06] <jdong> seb128: yes, I get the thumbnail update clock
[10:06] <jdong> Kamion: ok, thanks for the heads-up
[10:06] <seb128> jdong: you should not while it's working
[10:06] <seb128> it tries to thumbnail only if the file didn't change for 5s
[10:06] <jdong> seb128: well, I do.... :(
[10:06] <seb128> which should not happen while mencoder is running
[10:08] <jdong> seb128: it is indeed a clock icon
[10:08] <[Pitcher] > hi all, new server of support to ubuntu /server -m irc.ubuntuzone.org:6668 ;)
[10:08] <seb128> the standard clock icon?
[10:08] <[Pitcher] > hi all, new server of support to ubuntu /server -m irc.ubuntuzone.org:6668 ;)
[10:08] <seb128> or the icon it's using while generating a thumbnail?
[10:08] <Tonio_> mdz: talking about backports, I was thinking about proftpd
[10:09] <Tonio_> mdz: the mysql part doesn't work at all with the current dapper version, see bug 59359
[10:09] <Ubugtu> Malone bug 59359 in proftpd "proftpd-mysql-1.2.10-27ubuntu3 has stopped authenticating with mysql" [Undecided,Confirmed]  http://launchpad.net/bugs/59359
[10:09] <jdong> seb128: oh wait, never mind
[10:09] <seb128> ?
[10:09] <jdong> seb128: the bug happens with an incomplete avi it seems like
[10:09] <Tonio_> mdz: that's pretty annoying for a 5 years (server) supported version...
[10:10] <jdong> seb128: let me try to get you better instructions on reproducing it
[10:10] <seb128> jdong: ok
[10:10] <_ion> Is [pitcher]  a spambot?
[10:10] <Tonio_> mdz: I attempted to backport the edgy version and it works like a charm.... interested in an upload to dapper ?
[10:10] <tseng> _ion: i dont think so
[10:10] <tseng> Tonio_: 5 year server support doesnt apply to universe
[10:10] <mdz> Tonio_: backports -> jdong
[10:11] <tseng> Tonio_: its a best effort by the community
[10:11] <jdong> seb128: ok, with nautilus open looking at the directory, do the mencoder command
[10:11] <jdong> seb128: while that's running, press F5 like 5 times
[10:11] <jdong> seb128: now, CTRL+C on the mencoder
[10:12] <Tonio_> tseng: yes I know, but proftpd is a major component on the server part, especially for people using LAMP
[10:12] <tseng> Tonio_: you could argue alot of things are a major component of something or other
[10:12] <Tonio_> tseng: heh, true :)
[10:12] <tseng> Tonio_: there is a clear line in the sand between main and unvierse, proftpd is currently out
[10:12] <[Pitcher] > hi all, new server of support to ubuntu /server -m irc.ubuntuzone.org:6668 ;)
[10:12] <[Pitcher] > hi all, new server of support to ubuntu /server -m irc.ubuntuzone.org:6668 ;)
[10:13] <Tonio_> tseng: that doesn't prevent to close the bug by a backport afaik
[10:13] <jdong> Tonio_: does proftpd build in a pbuilder?
[10:13] <Tonio_> jdong: yup
[10:13] <tseng> Tonio_: not at all.
[10:13] <_ion> tseng: Still think it was not a spambot? :-P
[10:13] <tseng> _ion: dunno, it's gone
[10:14] <jdong> Tonio_: then I've got no issue with it... let me verify first
[10:14] <jdong> Tonio_: open that ticket as also affecting upstream dapper-backports
[10:14] <seb128> jdong: nop, no bug, maybe my box is too fast or something, do you have a slow box?
[10:14] <jdong> seb128: happens on my core duo and amd64
[10:15] <tseng> jdong: both smp?
[10:15] <jdong> tseng: nope, one smp
[10:16] <seb128> jdong: I think it's http://bugzilla.gnome.org/show_bug.cgi?id=357704
[10:16] <Ubugtu> Gnome bug 357704 in Monitoring (inotify) "Infinite loop in monitoring code" [Critical,Unconfirmed]  
[10:16] <seb128> jdong: no really idea on how to fix it for now though
[10:17] <jdong> seb128: could be.... :-/
[10:42] <jdub> i think it might be time to upgrade my linode to edgy
[10:42] <tseng> jdub: mine is staying on dapper
[10:42] <tseng> jdub: i dont see the impetus to move forward
[10:42] <tseng> LTS rules
[10:43] <jdub> perhaps in that case, we should've stuck with breezy, the best release yet ;)
[10:43] <tseng> breezy wasnt developed with LTS in mind
[10:43] <HiddenWolf> seriously, what's the drive to go to edgy?
[10:43] <tseng> and a guarantee of security updates
[10:43] <jdub> tseng: no, but it was better than dapper :)
[10:44] <HiddenWolf> Dapper does pretty much everything, unless you run into a bug.
[10:44] <HiddenWolf> jdub: how so?
[10:44] <gnomefreak> is edgy defaulting to python2.5 now?
[10:44] <infinity> gnomefreak: No.
[10:44] <gnomefreak> oh
[10:45] <jdub> HiddenWolf: breezy was a better release in general, dapper got messy (next time, hopefully we know an LTS will be an LTS at least 12 months ahead, instead of six)
[10:45] <gnomefreak> on a basicly clean install (other than heldback poython packages i just got updates for python-minimal2.5
[10:45] <jdub> gnomefreak: some python-gnome packages were built against it - probably a buildd / conflicts problem
[10:45] <gnomefreak> ah ok
[10:47] <gnomefreak> well i will file bug on the syntax errors
[10:48] <seb128> jdub: dude, breezy was not better than dapper
[10:48] <HiddenWolf> seb128: well, that depends. Dapper has a bug that bugs me that wasn't in breezy. ;)
[10:48] <jdub> seb128: it so was :)
[10:48] <seb128> HiddenWolf: that's not a troll chan, thank you
[10:49] <seb128> jdub: thank you for assuming the 6 weeks I spent fixing desktop bug were useless
[10:49] <seb128> jdub: we did fix a lot of small glitches and bug for dapper we didn't have time to fix with any previous version
[10:49] <jdub> seb128: i'm not -- just in general, i felt breezy was more solid, and that applies to everything from upstream, installer, etc.
[10:49] <seb128> really not my feeling
[10:50] <jdub> seb128: i also think gnome 2.12 was more solid than 2.14
[10:50] <seb128> not to speak we pushed lot of fix to dapper-updates compared to previous -updates
[10:50] <jdong> seb128: my  dapper box does not exhibit the 100% cpu bug
[10:50] <seb128> jdub: you must think that 2.16 is a joke then :/
[10:50] <jdub> seb128: yeah, the amount of updates has influenced my appreciation of dapper too
[10:50] <seb128> jdub: 2.12 had gst0.8
[10:51] <seb128> jdub: how can you consider it better than gst0
[10:51] <seb128> 0.10
[10:51] <jdub> seb128: i don't
[10:51] <seb128> I think 2.14 was good
[10:51] <seb128> 2.16 is not
[10:51] <seb128> gtk2.10 has issues, the gnome-vfs etc switch to dbus has issues too
[10:51] <jdub> but again, i felt breezy was a better release *in general* (not specific to gnome, etc)
[10:51] <seb128> k, I disagree ;)
[10:52] <jdub> yeah, some biggish changes that haven't had much testing
[10:52] <seb128> jdub: you should compare breezy installer to dapper alternative, not ubiquity :p
[10:52] <seb128> alternate
[10:52] <jdub> heh
[10:52] <jdub> but Real Users wouldn't :)
[10:53] <seb128> real users would think dapper has the same old good text based installed and new cool desktop CD one ;)
[10:54] <infinity> seb128: Is there a new pygtk on the way that reverts to python2.4 instead of python2.5?
[10:54] <seb128> infinity: what python2.5?
[10:54] <infinity> seb128: apt-cache show python-gtk2 | grep python2.5
[10:55] <seb128> infinity: $ dpkg -L python-gtk2  | grep python | grep gtk.so
[10:55] <seb128> /usr/lib/python-support/python-gtk2/python2.5/gtk-2.0/gtk/_gtk.so
[10:55] <seb128> /usr/lib/python-support/python-gtk2/python2.4/gtk-2.0/gtk/_gtk.so
[10:55] <seb128> infinity: ?
[10:55] <seb128> infinity: you know, we have that new policy things
[10:55] <seb128> several versions of python to the same package
[10:55] <infinity> Depends: python2.5
[10:55] <seb128> balem python-support? :p
[10:55] <Amaranth> Provides: python2.5-gtk2, python2.4-gtk2
[10:55] <Amaranth> Depends: python (<< 2.6), python-support (>= 0.3.4), python (>= 2.4),
[10:56] <seb128> blame
[10:56] <seb128> infinity: what arch is that?
[10:56] <seb128> I've "Depends: python (<< 2.6), python-support (>= 0.3.4), python (>= 2.4)" on my edgy amd64
[10:58] <infinity> seb128: i386... I have what you show for 2.10.3-0ubuntu1, but have python2.5 for 2.10.3-0ubuntu2
[10:58] <seb128> infinity: ah, I've not apt-get updated yet, will have a look on it
[10:58] <infinity> So, yes, I'd guess python-support 0.5.2 was the culprit.
[10:59] <infinity> Or not... Both were built with that version.
[10:59] <infinity> Hrm.
[11:00] <sbalneav> Is fuse-utils now putting the fuse module into /etc/modules?  Seems that way from the logs.
[11:02] <AnAnt> anyone knows where to get info (other than dash manual) about field expansion in dash ? the problem is that I got a variable VAR=foo1 foo2 ... , and I need to access a certain field (either foo1 or foo2 , ...)
[11:04] <sbalneav> Seems so, from dpkg -e.  OK, I don't need to do that in ltspfs then.
[11:04] <infinity> seb128: Hrmph.  Scanning edgy-changes, I don't immediately see anything uploaded/changed between ubuntu1 and ubuntu2 that sticks out as a scapegoat.
[11:05] <seb128> infinity: the new version installs /usr/bin/pygtk-demo which uses "#! /usr/bin/python2.5"
[11:05] <seb128> infinity: I'll fix that
[11:06] <infinity> Oh, duh.
[11:06] <infinity> That'd do it alright. :)
[11:06] <infinity> Thanks.
[11:06] <seb128> np
[11:06] <seb128> thank you for pointing it
[11:06] <seb128> and sorry for the bug ;)
[11:09] <Kamion> seb128: I'd very much rather have built ubiquity over two releases, the first one as non-default, rather than blasting it straight in as the default
[11:09] <Kamion> seb128: but commercial pressures meant that wasn't possible
[11:10] <seb128> right
[11:11] <seb128> not speaking about ubiquity I find the dapper polish level better than for previous versions
[11:27] <jdub> Kamion: what's marc brockschmidt's nick? (is he an ircer?)
[11:28] <elmo> jdub: HE
[11:29] <jdub> thanks elmo 
[11:29] <jdub> oh, that means i have to oftc or something
[11:30] <jdub> ahr, here, but not here
[11:37] <AnAnt> wifi-radar daemon ends after a short while, I think it is a bug
[12:02] <illovae> ohayo :)
[12:03] <illovae> first sorry for my english, but it's not my native langage
[12:03] <seb128> hi
[12:03] <illovae> i know there is an option -g for cp who make a progress bar avalaible while copying big files
[12:04] <illovae> when i test it on my dapper, it doesn't work
[12:04] <illovae> is it possible that the option is not integrated in the coreutils in the dapper version ?
[12:05] <illovae> i can give you my source on linuxfr.org but it's in french
[12:06] <illovae> i don't know if the coreutils are developed by the UbuntuDevels
[12:06] <illovae> or if it's just a port from debian
[12:06] <illovae> so...
[12:06] <illovae> i ask here anyway
[12:06] <seb128> illovae: we sync the packages on Debian, version might mismatch though
[12:06] <seb128> illovae: is that a new cp feature?
[12:07] <illovae> i don't know, i was just seaching for a tool who give a progress bar while copying files like wget