[07:03] <dholbach> jamesh:
[09:33] <huats> Morning evryone
[09:37] <mvo> hey huats!
[09:37] <mvo> hey MacSlow
[09:38] <mvo> and seb128 of course :)
[09:38] <huats> hello mvo and crevette
[09:38] <huats> :)
[09:38] <MacSlow> Greetings everybody!
[09:38] <huats> and of course "the never quitting the chanel" : seb128
[09:38] <huats> !)
[09:39] <huats> morning MacSlow
[09:41] <MacSlow> hey mvo, huats, seb128
[09:52] <lool> seb128: Do you use f-spot from time to time?
[09:53] <lool> It's often hanging when I close it; I was also surprized not to have anything happening when I plugged my camera in on my Ubuntu desktop
[09:53] <lool> (I'm uploading the apport crash ATM)
[09:55] <seb128> lool: yes, I use it to manage my photos
[09:56] <lool> seb128: Does it come up for you when you plug your camera?
[09:56] <seb128> dunno about the nautilus action not happening, I didn't look at it recently
[09:56] <lool> seb128: Does it hang when you try to close it?
[09:56] <seb128> there was a bug about that IIRC
[09:56] <lool> Under Debian, I get a popup to import my photos, but when I chose to, nothing happens...
[09:56] <lool> The new version is really superb though
[09:56] <seb128> debian is likely still using gnome-volume-manager
[09:56] <seb128> where we use nautilus gvfs for those actions
[09:57] <lool> Ah right
[09:57] <lool> NB: my camera does PTP; I don't think it can pretend to be a mass storage device
[09:59] <seb128> that should make no difference to applications using libgphoto
[10:01] <hggdh> do we have a problem on glib? Anyone noticed the number of g_slice_alloc SIGSEGV we have on LP?
[10:01] <seb128> hggdh: not that I know, and no
[10:02] <seb128> is that recent? on what components?
[10:03] <hggdh> seb128: evolution, npviewer.bin, sshfs, gvsd-trash, gvfsd-sftp, nautilus, totem*, gnome-mplayer, file-roller, evince, and so on
[10:05] <hggdh> at least 50 are quite new, with bug #s > 190000
[10:06] <seb128> hggdh: there is 42 titles with this function on launchpad, not an issue I would say
[10:07] <hggdh> seb128, there are also some invalid that were closed for lack of supporting docs...
[10:07] <hggdh> but it was just a question... I started to see that on Evo, and cannot see them as an Evo issue
[10:07] <seb128> hggdh: looking at some example they are different issues
[10:09] <seb128> hggdh: well, I would say that's incorrect memory management bugs and they crash in the allocator
[10:09] <seb128> hggdh: ask for a valgrind log as described on the wiki, that will give better indications
[10:10] <hggdh> seb128 I do agree... the problem is how long it takes for one to be hit, and there is not much of a chance of one running valgrind for hours...
[10:10] <seb128> hggdh: right, so not a lot we can do
[10:10] <hggdh> such is life ;-)
[10:10] <seb128> hggdh: until other indication I tend to thing those are application bugs
[10:11] <seb128> they are usually invalid memory usage
[10:11] <seb128> or using wrong free function
[10:11] <hggdh> seb128 usually I would look at the smack on as appl issues, but then we have a lot of appl issues... I do not remember Gutsy as this
[10:11] <hggdh> s/at the/at them as
[10:12] <seb128> you mean gusty had less crashers?
[10:12] <seb128> I don't think so
[10:12] <hggdh> for g_slice_alloc, yes, AFAICK
[10:12] <seb128> but we had update-notifier buggy and apport was not running until beta or something
[10:12] <hggdh> huh, ok, forgot about that... :-(
[10:13] <seb128> well, that could be glib issue, but we don't have enough informations to lead to this right now
[10:13] <seb128> and I don't have every desktop app crashing every 10 minutes either
[10:13] <seb128> I would have say that it could be a gio issue
[10:13] <seb128> but evolution doesn't use gio yet I think
[10:14] <hggdh> yep. Will keep on monitoring, just in case. I have another SIGSEGV in poll() to look at, anyways
[10:18] <hggdh> seb128: just a comment -- when I started in system programming we had a mitzvah that stated a system library should never fail because of bad input. This is why I raised the issue
[10:20] <seb128> hggdh: was is a bad input?
[10:21] <seb128> hggdh: is doing a 3gigabytes malloc a bad input or just something your system doesn't handle correctly? ;-)
[10:21] <seb128> hggdh: well, anyway those error are not bad input usually, they are things like trying to access a pointer after freeing it
[10:23] <hggdh> seb128 -- yes... but, nevertheless, poll(), and g_slice_alloc(), should not die because of that. This is indeed bad input. If the system does not have 3G to give on a malloc, it should return an error, not die
[10:23] <seb128> right, that was a bad example
[10:23] <seb128> that's likely crashes in malloc you get
[10:23] <seb128> usually the crash is not in malloc
[10:24] <seb128> that's just that when you start accessing freeed memory you get corruption
[10:24] <seb128> and that leads to corrupted stacktrace
[10:24] <seb128> that's not because gdb shockes on malloc or another memory handling function that the crash happened due to it
[10:25] <seb128> s/likely/similar to
[10:25] <hggdh> yes, the price we pay for not having hardware-enforced boundary checks on memory :-( I remember a system I used to work with that had it)
[10:26] <seb128> yeah, might be, but anyway that's out of the glib scope
[10:26] <hggdh> I now agree ;-)
[10:31] <lool> hggdh: This can happen when a new type of objects moves to slices and many apps use g_free instead of g_foo_unref() or whatever
[10:32] <hggdh> lool: thank you -- I do not use them, so I did not know about that. Will check on Evo for that
[10:37] <hggdh> ugh! this will take much longer than I expected, will have to restrict my search... 3916 g_free's, and 1938 g_.*_unref's (evo only, and not counting other variations...) Guess I will have to keep just at the code path that failed...
[10:37] <mvo_> pitti: could you please have a quick look at http://paste.ubuntu.com/5763/ ? I would like to upload that, showed up in gutsy->hardy upgrade testing
[10:38] <pitti> mvo_: to which binary does this apply?
[10:38] <pitti> oh, -dev
[10:38] <pitti> mvo_: sure, no problem
[10:39] <seb128> pitti: if you look at the queue could you accept my gdm file-roller uploads there?
[10:39] <pitti> seb128: was this discussed with Steve, is he aware of it?
[10:40]  * pitti looks at the diff
[10:41] <mvo_> pitti: thans
[10:41] <mvo_> thanks even :)
[10:41]  * pitti hugs mvo_
[10:45] <pitti> seb128: gdm> ah, speedup love?
[10:45] <seb128> pitti: yes
[10:45] <pitti> too bad that we didn't get the improved prefetch thingy into hardy :(
[10:46] <seb128> pitti: no, that was not discussed with Steve, I did work during the weekend but didn't do IRC nor did want to ping him during non work time
[10:46] <pitti> seb128: did anyone else test this version?
[10:46] <pitti> seb128: curious, how much login speedup does it buy you?
[10:47] <pitti> f-roller accepted
[10:49] <seb128> pitti: thanks
[10:50] <seb128> pitti: I don't think so
[10:50] <mvo_> seb128: yeah, what do we look like now with the delayed apt-check ?
[10:50] <pitti> dholbach: FYI, XS-Vcs-Bzr is now called Vcs-Bzr (just saw it in your gnome-user-docs upload)
[10:50] <seb128> with the current hardy and the prefetch my laptop does 19 seconds
[10:51] <seb128> where it was 36 seconds before starting the changes
[10:51] <mvo_> that sounds pretty good to me :)
[10:51]  * mvo_ hugs seb128
[10:51] <pitti> wow
[10:51] <seb128> between we removed deskbar, tracker, you guys delayed jockey and apport-check and there is prefetch now
[10:51] <pitti> apt-check?
[10:51]  * pitti didn't delay apport yet
[10:52] <dholbach> pitti: thanks for letting me know - will bear that in mind next time
[10:52] <pitti> dholbach: any idea why your upload also removes .pot files?
[10:52] <pitti> dholbach: like /user-guide.pot?
[10:53] <pitti> well, it's the only pot file removed in fact
[10:53] <pitti> dholbach: anyway, accepted
[10:53] <mvo_> pitti: thats the part of update-notifier that checks for updates, its quite IO intensive
[10:53] <dholbach> pitti: no idea why it should remove the .pot files
[10:53] <pitti> seb128: ok, still enough time to change/fix/revert, so I'll accept it
[10:54] <mvo_> we look pretty good upgrade wise in my current tests (if anyone is interessted :) main-all from gutsy->hardy works, that is something like ~5000 pkgs at the same time
[10:54] <pitti> wow
[10:54] <pitti> mvo_: anything significant in the /etc diff?
[10:54] <pitti> mvo_: I just recently fixed some bugs which led to broken init scripts on update, etc.
[10:55] <mvo_> pitti: meh, sorry, I haven't generated it for this image, its takes quite a bit to build the reference image
[10:55]  * mvo_ needs to fix that
[10:55] <pitti> mvo_: libgphoto2 accepted
[10:55] <mvo_> great, thanks pitti!
[10:55]  * mvo_ hugs pitti
[10:55] <seb128> pitti: thanks
[10:56] <seb128> pitti: yes, apt-check, sorry ;-)
[10:56]  * pitti takes off the deputy RM hat again and goes back to bug triage
[10:56] <pitti> seb128: apport crash check is done by update-notifier, I don't think that it imposes a lot of overhead
[10:57] <pitti> and it's already delayed a bit
[10:57] <seb128> yeah I noticed
[10:57] <seb128> but it's not a lot of IOs
[10:57] <seb128> right
[11:18] <pitti> seb128: hm, bug 202457
[11:18] <ubotu> Launchpad bug 202457 in gnome-volume-manager "Preferences option for Removeable Drives doesnt control Removeable drives" [Undecided,New] https://launchpad.net/bugs/202457
[11:18] <pitti> seb128: seems that we shuold rename this menu entry
[11:18] <seb128> indeed
[11:19] <pitti> I'll report it upstream, we shuoldn't have ubuntu specific strings
[11:21] <seb128> right
[11:21] <seb128> upstream didn't change g-v-m yet though
[11:25] <pitti> (done)
[11:25] <pitti> seb128: well, since GNOME did change nautils, the 2.20 upstream release is quite broken in that regard? (double mounting)
[11:25] <pitti> or did they disable nautilus automounting?
[11:26] <seb128> pitti: it's broken I think
[11:26] <seb128> 2.22 you mean, right?
[11:26] <seb128> 2.22.0 is a bit rough on the edges
[11:30] <pitti> mvo_: can you please have a quick look at bug 202548? is it possible to leave postgresql-X.Y installed after upgrade, even if it is in universe?
[11:30] <ubotu> Launchpad bug 202548 in update-manager "Upgrade 7.10 to 8.04 should preserve previous DB data" [Undecided,New] https://launchpad.net/bugs/202548
[11:38] <pitti> "[Bug 202994] Re: Nautilus opens more pipes than a plumber"
[11:38]  * pitti chuckles
[11:38] <ubotu> Launchpad bug 202994 in esound "Nautilus opens more pipes than a plumber (dup-of: 183411)" [Low,Fix released] https://launchpad.net/bugs/202994
[11:38] <ubotu> Launchpad bug 183411 in esound "libesd leaks pipe file descriptors" [Undecided,Fix committed] https://launchpad.net/bugs/183411
[11:38] <lool> haha
[11:41] <seb128> pitti: any reason this fix didn't make to gutsy-updates by now?
[11:42] <pitti> seb128: nobody followed up with any kind of testing confirmation
[11:42] <seb128> ok
[11:42] <pitti> three people shouting "installed that version, no problems encountered" would be enough
[11:42] <pitti> I'm not that fussed about reproducing the bug and test cases, etc.
[11:42] <pitti> but about "OMG the package miscompiled, and now everything is crashed"
[11:42] <pitti> crashing, even
[11:43] <pitti> seb128: oh, just noticed that nautilus now opens f-spot? or at least, is supposed to?
[11:43] <seb128> well, we have the change in hardy for month, and it's not exactly complicated
[11:43] <seb128> pitti: it's supposed
[11:44]  * pitti ponders dropping g-v-m completely for hardy
[11:44] <pitti> it's an almost useless daemon nowadays
[11:47] <Ng> would stuff like camera photo importing still happen without it?
[11:47] <seb128> Ng: <pitti> seb128: oh, just noticed that nautilus now opens f-spot? or at least, is supposed to?
[11:48] <Ng> oh, yes backscroll. doh ;)
[11:48] <Keybuk> pitti: really?  I thought it still did the HAL event->open program glue?
[11:48] <pitti> sane and f-spot are the only two programs left in g-v-m
[11:48] <pitti> Keybuk: most of it went into nautilus in 2.20 (gvfs)
[11:48] <Keybuk> where has that glue moved to for other things?
[11:48] <Keybuk> ahh
[11:49] <pitti> nautilus doesn't handle scanners, though
[11:49] <pitti> meh, this should really have been thought out much better by upstream for the final release
[11:52] <seb128> pitti: upstream has limited manpower and an huge quantity of things to do there
[11:52] <pitti> right, I understand
[11:52] <pitti> seb128: WDYT, should we add scanners to nautilus and drop g-v-m, or keep gvm for scanners only?
[11:53] <pitti> (or just ignore scanners and have people open xsane/gimp manually?)
[11:53] <pitti> personally I find the xsane popup quite annoying, but that's just me maybe
[12:01] <seb128> pitti: do you think the options which are not used by default are useful to some users?
[12:02] <pitti> seb128: the ones for video cam, web cam, and PDA are, IMHO
[12:03] <pochu> hi all
[12:03] <seb128> pitti: ok, so better to keep it running
[12:22] <mvo_> pitti: sure, I can add postgresql-8.2 to the removal blacklist
[12:22] <pitti> mvo_: that would be great
[12:22] <pitti> mvo_: postgresql-* in general maybe?
[12:22] <pitti> since we'll hit the same problem with every release
[12:22] <pitti> and people upgrading from dapper will upgrade 8.1 to 8.3
[12:24] <mvo_> pitti: sure, that would work too, isn't poststres-* a bit too generic? how many packages do we have that look like that?
[12:26] <pitti> mvo_: that would include the -client, -contrib, -plpython, etc., too
[12:26] <pitti> but in order to not break your existing DBs, you need them, too
[12:27] <mvo_> aha, ok
[12:27] <pitti> mvo_: there might be some extensions, though, I see what you mean
[12:27] <pitti> ah, but not in main
[12:27] <pitti> but if they were, they should be kept, too, IMHO
[12:28] <pitti> mvo_: since they should all depend on the server, removing the server version later will remove the extensions, too
[12:31] <mvo_> pitti: ok, I added it to the blacklist now
[12:38] <gicmo> pedro_: hey there
[12:38] <pedro_> hey gicmo
[12:39] <gicmo> pedro_: about https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/199301
[12:39] <ubotu> Launchpad bug 199301 in gvfs "gvfs-fuse-daemon crashed with SIGSEGV in pthread_mutex_lock()" [Medium,Triaged]
[12:39] <gicmo> pedro_: that is most likely not a gvfs bug
[12:39] <gicmo> pedro_: its crashing inside fuse
[12:39] <pedro_> gicmo: ok, will re assigned it then, thanks you
[12:39] <gicmo> pedro_: wait a sec
[12:40] <gicmo> pedro_: also http://bugzilla.gnome.org/show_bug.cgi?id=522944 like a bit like it was the same issue
[12:40] <ubotu> Gnome bug 522944 in gphoto backend "gvfsd-gphoto2 crashed with SIGSEGV in pthread_mutex_lock()" [Critical,Unconfirmed]
[12:40] <gicmo> any chance somebody fucked up libc or pthreads or something in ubuntu?
[12:40] <gicmo> mvo_, pitti?
[12:42] <pedro_> gicmo: does this works for you? bug 203041
[12:42] <ubotu> Launchpad bug 203041 in nautilus "davs:// protocol is not properly supported" [Undecided,New] https://launchpad.net/bugs/203041
[12:45] <gicmo> pedro_: that is a nautilus issue
[12:45] <gicmo> pedro_: see http://bugzilla.gnome.org/show_bug.cgi?id=522445 and dups
[12:45] <ubotu> Gnome bug 522445 in GIO "connect to server error" [Normal,Resolved: duplicate]
[13:01] <hggdh> by the way, seb128, evolution *is* using gio
[13:05] <seb128> hggdh: to do what?
[13:05] <hggdh> I do not know yet... I just saw it on a bt
[13:06] <hggdh> on e-d-s
[13:09] <hggdh> but I still hope it is not a direct use, searching for it
[14:05] <slytherin> gicmo: dholbach told me to contact you. I was trying to fix evolution-scalix FTBFS. I created patch for configure(.in). But I am not able to solve compilation problems.
[14:06] <gicmo> hey slytherin
[14:06] <gicmo> FTBFS?!
[14:06] <gicmo> ;-)
[14:07] <dholbach> fails to build from source
[14:07] <slytherin> gicmo: The version, 10.0.1.1-0ubuntu2 which was supposed to be rebuild against latest libcamel fails to build
[14:07] <dholbach> bug 193764
[14:07] <ubotu> Launchpad bug 193764 in evolution-scalix "evolution-scalix FTBFS with current evolution" [High,Confirmed] https://launchpad.net/bugs/193764
[14:07] <dholbach> I pinged you about it as I didn't know
[14:08] <dholbach> bug 198733 might be the same problem
[14:08] <ubotu> Launchpad bug 198733 in evolution-scalix "evolution-scalix not installable on hardy (missing libcamel)" [Undecided,New] https://launchpad.net/bugs/198733
[14:08] <slytherin> gicmo: in fact this was the first time the package was changes in hardy. The last changelog entry is from feisty.
[14:08] <gicmo> ohh, hmm I have stopped using scalix myself and I am not working for them anymore so I wouldnt notice, but lets see what I can do about it
[14:09]  * dholbach hugs gicmo
[14:09]  * gicmo hugs dholbach ;-)
[14:09] <slytherin> gicmo: I will attach my diff.gz tonight to the bug which will at least run configure script without fail and start compilation. You can take it from there. :-)
[14:11] <gicmo> slytherin: thanks
[14:11] <slytherin> gicmo: oops, someone has already attached patch for configure failure. I will check if it is better than me?
[14:12] <gicmo> as long as it picks up the right stuff, I dont care where it is coming from ;-)
[14:23] <seb128> pitti: are you fine doing approvals or should I rather wait for steve?
=== belou_ is now known as belou
=== dholbach_ is now known as dholbach
[16:53] <lool> seb128: Hmm the totem mythtv plugin pulls a lot
[16:53] <lool> seb128: libgmyth, libmysql, mysql-common...
[16:55] <lool> LP #191952
[16:55] <ubotu> Launchpad bug 191952 in gst-plugins-bad0.10 "Remove mysql dependency for LPIA" [Undecided,New] https://launchpad.net/bugs/191952
[17:07] <seb128> lool: I'm pondering creating a totem-plugins-universe and move things there
[17:08] <lool> seb128: Good idea
[17:09] <seb128> that would allow having bugs about totem not depending on python-gdata for example
[17:09] <seb128> there is quite some plugins which have extra depends or are not really stable
[17:12] <Amaranth> mvo: so is there any hope of getting a new snapshot in before beta? :)
[17:13] <mvo> Amaranth: not really, htat is going to be very difficult. however, if we can point to a number of LP bugs that are fixed with it, the chances will raise dramatically
[17:22] <huats> mvo: hello
[17:22] <huats> mvo: any idea why gnome-commander has not been built in i386 ?
[17:23] <Amaranth> mvo: alright, let me try to make a list here :)
[17:26] <Amaranth> mvo: huge one right here http://bugs.opencompositing.org/show_bug.cgi?id=793
[17:26] <ubotu> bugs.opencompositing.org bug 793 in Core "Impaired UI performance with Firefox in full screen mode (F11)" [Normal,Resolved: fixed]
[17:29] <Amaranth> basically all the problems with fullscreen apps when using unredirect fullscreen windows seem to be solved
[17:29] <Amaranth> and unredirect fullscreen windows works correctly when the app changes the screen resolution
[17:36] <Amaranth> vuntz: it looks like a recent commit to compiz is going to break how libwnck deals with compiz window decorations
[17:37] <Amaranth> the bit added to libwnck to account for window decorations when moving a window, specifically
[17:37] <Amaranth> http://cgit.compiz-fusion.org/compiz/commit/?id=61f8473ed79d679f0c9dd068340b14ad964dda12
[17:41] <vuntz> Amaranth: hrm
[17:42] <vuntz> Amaranth: I think it's already fixed in libwnck 2.22.0, isn't it?
[17:43] <Amaranth> vuntz: isn't the fix to take window decorations into account before moving?
[17:43] <Amaranth> it seems like this commit to compiz will make libwnck move things too far now
[17:43] <Amaranth> but i haven't tested so i might be wrong
[17:45] <vuntz> Amaranth: there are two kinds of move :-)
[17:45] <vuntz> either with decorations or without decorations
[17:45] <vuntz> we're missing one public API for the one without decorations, though, iirc
[17:46] <vuntz> and the one "with decorations" was broken and has been fixed for 2.22.0
[17:46] <Amaranth> ah
[17:47] <Amaranth> vuntz: don't suppose you got a chance to look at my patch for scrolling on the workspace switcher with compiz :)
[17:48] <vuntz> Amaranth: not yet, but later this week
[17:48] <vuntz> Amaranth: there are 4-5 libwnck patches I want to commit
[18:02] <crevette> Amaranth, you should read that http://svn.gnome.org/viewvc/gdm/trunk/ChangeLog?revision=6031&view=markup
[18:02] <crevette> at least the first commit :)
[18:03] <Amaranth> neat but that's intrepid stuff
[18:03] <crevette> I don't like the key name
[18:04] <crevette> the name is harcoded, I would have preferred custoim_wm
[18:04] <crevette> custom_wm, or something like thazt
[18:05] <crevette> something which would have more WM agostic
[18:05] <crevette> agnostic
[18:07] <crevette> anyway, time to go back home, see you
[18:19] <mvo> lool: I would like to upload http://paste.ubuntu.com/5786/ - is that ok with you? the "fix" works around a problem in the apt ordering code
[19:12] <lapo> ciao
[19:12] <mvo> Amaranth: what is up with the session plugin? another abi change?
[19:13] <Amaranth> yes :/
[19:13] <Amaranth> maniac redid the mechanism for getting session events
[19:18] <mvo> Amaranth: ok, thanks. I noticed the load of fixes in compiz git, its pretty amazing. I will have a log at the git log but my guess is that we will have a hard time pushing more than specific patches at this point, may get easier after beta again
=== asac_ is now known as asac
[20:03] <lool> mvo: But how do we guarantee that people don't install nautilus 2.20 with the new glib?
[20:03] <lool> well << 2.20 rather
[20:03] <mvo> lool: I'm investigating currently, maybe there is a better way
[20:03] <mvo> lool: its a bit of a desperate move from my side :)
[20:04] <lool> mvo: Ack; if you don't find a way, let's do this
[21:44] <alex-weej> is there something that can be done about CPU load drastically affecting audio performance?
[21:44] <alex-weej> since the switch to PulseAudio it's gotten a lot worse
[21:45] <alex-weej> but it was bad even with just ALSA
[21:45] <lool> Check whether you have freq scaling
[21:45] <alex-weej> stuff is underrunning like mad as i run updates
[21:45] <alex-weej> lool: what is that and how do i do it?
[21:46] <lool> alex-weej: Does your CPU frequency change depending on the load?
[21:46] <lool> This might cause audio glitches
[21:46] <alex-weej> i don't think so, it's a Pentium 4
[21:46]  * lool goes to bed now &
[21:46] <alex-weej> ah xorg is eating all my CPU time
[21:47] <alex-weej> christ on a bike
[21:47] <alex-weej> it was the new system monitor graphs eating all my time
[21:50] <seb128> alex-weej: that's a known issue
[21:50] <seb128> alex-weej: likely cairo being slow on your video card or driver
[21:50] <alex-weej> seb128: it's more like it's saturating the server with drawing commands
[21:50] <alex-weej> try resizing it as it draws and it continues servicing old drawing requests for the wrong size
[21:51] <seb128> cairo performances are bad with some drivers
[21:51] <alex-weej> ati here, ftr
[21:52] <seb128> are you use EXA or XAA?
[21:52] <alex-weej> i'm not sure to be honest, but given that the "smooth" scrolling barely works i think we should find a way to disable it for hardy release
[21:52] <alex-weej> most people report that it jerks
[21:53] <seb128> alex-weej: grep for EXA and XAA in you Xorg.0.log
[21:54] <alex-weej> This is a pre-release version of the X server from The X.Org Foundation.
[21:54] <alex-weej> uh...
[21:54] <alex-weej> bug in log viewer :P
[21:54] <alex-weej> XAA
[21:56] <seb128> alex-weej: https://bugs.freedesktop.org/show_bug.cgi?id=4320
[21:56] <ubotu> Freedesktop bug 4320 in Driver/Radeon "Over from xrgb8888 pictures not fast-pathed in XAA" [Normal,Assigned]
[21:56] <alex-weej> Secure Connection Failed
[21:56] <alex-weej> ephy/xulrunner is absolute crap since Fx 2.0 :(
[21:56] <alex-weej> any idea if ephy/webkit is likely to be supported soon?
[21:57] <seb128> alex-weej: not this cycle, webkit is not usuable yet
[21:57] <seb128> alex-weej: you should be able to accept certificates now, no?
[21:57] <alex-weej> i am really pissed off that the design of xulrunner even seems to let any of this stuff seep through
[21:57] <seb128> I copied the firefox on some weeks ago so I didn't notice if that has been fixed yet or not
[21:57] <alex-weej> no obvious way to do it seb
[21:58] <seb128> open the website in firefox
[21:58] <alex-weej> oh right... that doesn't count :P
[21:58] <seb128> and copy cert8.db
[21:59] <alex-weej> there are buttons to do it in Firefox on the chrome page
[22:00] <seb128> yes, epiphany should do the same
[22:00] <seb128> asac should know better about that
[22:04] <alex-weej> speaking of this... has anyone ever expressed any interest in getting a "gnomebuntu-desktop" metapackage made up?
[22:08] <asac> certs is the last important fix we need
[22:08] <seb128> alex-weej: we have ubuntu-desktop
[22:09] <alex-weej> asac: ah, about:config is working now i see :D
[22:09] <asac> gtk
[22:09] <alex-weej> seb128: ubuntu-desktop is a bit of a mish mash though, pidgin over gossip, compiz over metacity, firefox over ephy?
[22:09] <alex-weej> the kubuntu guys get to have kontact, kwin, konq
[22:10] <alex-weej> having a gnomebuntu metapackage at least would be useful for people wishing to use all gnome software
[22:10] <alex-weej> asac: gtk?
[22:10] <asac> good to know
[22:10] <seb128> alex-weej: you can install gnome-desktop-environment from universe
[22:13] <alex-weej> asac: ?
[22:24] <calc> isn't there some new gdm gui that is supposed to be in hardy?
[22:24] <calc> or did that not make it in time for this release?
[22:25]  * calc installed fedora 8 yesterday in vmware and thought their gdm was nifty
[22:25] <tedg> calc: It was decided early on to push it to the next release.
[22:25] <calc> tedg: ah ok
[22:25] <calc> tedg: i had forgotten about it until i saw the fedora gdm yesterday
[22:30] <pochu> calc: in fact GNOME 2.22 ships with gdm 2.20 IIRC
[22:32] <calc> pochu: ah, yea that makes sense given what i heard about gdm 2.22
[22:32] <calc> pochu: aiui gdm 2.22 is a complete rewrite
[22:35] <pochu> yes, http://live.gnome.org/GDM/NewDesign has the details
[22:55] <alex-weej> asac: have you noticed that trying to edit properties in about:config doesn't work? i get a dialogue with no text, no window title, and just a text field, ? icon and OK and Cancel (that don't do anything when you click them)
[22:55] <alex-weej> only way to get it to go away is to hit the window X
[22:55] <alex-weej> (and it doesn't actually apply the setting you typed)
[23:17] <seb128> slomo: did you try the new totem youtube thing?
[23:18] <seb128> slomo: bug #203336 seems to be a gstreamer issue
[23:18] <ubotu> Launchpad bug 203336 in gstreamer0.10 "Youtube plugin don't work" [Undecided,New] https://launchpad.net/bugs/203336
[23:18] <slomo> seb128: will test in a few minutes
[23:18] <slomo> seb128: thanks
[23:29] <alex-weej> is VT switching completely broken now in Hardy? last time i checked, consolekit was doing something funky that just took me straight back to my X VT
[23:30] <alex-weej> but now the ctrl+alt+f-keys don't even do anything
[23:32] <Amaranth> works great here
[23:32] <Amaranth> it even mutes sound when you switch away from the VT where sound is playing