[00:59] <kklimonda> hmm.. I remember reading about packaging gnome-shell for ubu 9.10.. who's doing that?
[01:12] <TheMuso> kklimonda: I believe its in the Ubuntu desktop team PPA.
[01:13] <kklimonda> heh, only for karmic.. maybe it's time to update. :)
[01:13] <kklimonda> TheMuso: thanks
[01:17] <TheMuso> np
[01:17] <TheMuso> There is a lot of stuff in karmic that is not very easily backported.
[01:18] <TheMuso> Or so far as I have seen anyway.,
[07:02] <pitti> Good morning
[07:04] <ruslanr> pitti: good morning
[07:04] <pitti> hey ruslanr
[09:18] <mvo> hey glatzor
[09:21] <glatzor> morning mvo!
[09:53] <slomo> seb128: hi :) please sync orc from debian/experimental
[09:53] <seb128> slomo, hey, what is orc?
[09:54] <slomo> seb128: the successor of liboil, it provides a runtime compiler for a assembly-like language, etc that then creates optimized code for mmx, sse, altivec or what else the machine supports
[09:54] <seb128> ok
[09:54] <slomo> seb128: some gstreamer plugins will probably use it soon
[09:56] <seb128> slomo, synced
[09:58] <slomo> thanks :)
[10:13] <seb128> hey robert_ancell
[10:13] <robert_ancell> hey seb128
[10:13] <seb128> robert_ancell, how is the spanish GUADEC? ;-)
[10:13] <robert_ancell> It's not all Spanish...
[10:14] <seb128> oh good ;-)
[10:23] <seb128> pitti, hey
[10:24] <seb128> pitti, is "you need a password to unmount a CD you just inserted" a known issue? gvfs or devicekit rather?
[10:24] <pitti> seb128: devkit-disks
[10:24] <pitti> seb128: bonjour
[10:25] <seb128> pitti, ok, danke
[10:25] <seb128> brb trying client side gtk
[10:26] <seb128> seems to work!
[10:27] <seb128> pitti, do you want a bug in launchpad or is that something you are already tracking?
[10:27] <pitti> seb128: gtk> yay
[10:27] <pitti> seb128: bug> it's not known to me
[10:27] <seb128> you want me to open the bug upstream directly rather?
[10:27] <pitti> seb128: please attach devkit-disks --dump output with the cdrom
[10:27] <pitti> seb128: if you would? I'd just forward it upstream anyway
[10:28] <pitti> even if I work on them
[10:28] <pitti> seb128: please tell me the bug#, I'll subscribe to it
[10:28] <seb128> "  mounted by uid:          0"
[10:28] <seb128> hum
[10:29] <pitti> ah, that would be it, I guess
[10:29] <pitti> seb128: can you please add the "mount" output when the CD is mounted?
[10:29] <seb128> pitti, devkit-disks --dump seems to always display uid: 0
[10:30] <seb128> it does that too for my usb key which I can eject
[10:30] <seb128> "/dev/sr0 on /media/cdrom0 type iso9660 (ro,nosuid,nodev,user=seb128)"
[10:30] <pitti> seb128: ok, then I'm afraid david needs to look at this (he's usually pretty fast with devkit bugs)
[10:30] <pitti> I'll also take a look at the code
[10:30] <seb128> don't bother I will see that with davidz
[10:30] <pitti> but I guess I'll finish wrangling with gdm first, this week
[10:31] <seb128> I'm wondering if that's the same issue than "gvfs asks for passwords to mount an usb key"
[10:31] <pitti> seb128: I'd like to squash bug 395324 and bug 395591
[10:31] <pitti> seb128: quite possibly; it seems to get confused about them
[10:31] <pitti> seb128: since usually, when I abort this and try a second time, it mounts fine as user
[10:32] <seb128> well the autospawned try seems to fail
[10:32] <seb128> but clicking on the icon next works
[10:32] <seb128> anyway I will talk to davidz, thanks
[10:32] <pitti> seb128: I'm curious what's this "client-side gtk"?
[10:33] <seb128> pitti,
[10:33] <seb128> "GDK now maintains
[10:33] <seb128>   its own window hierarchy client-side, and only uses X windows where
[10:33] <seb128>   unavoidable. Some of the benefits of this change are
[10:33] <seb128>   - Reduced flicker
[10:33] <seb128>   - The ability to do transformed and animated rendering of widgets
[10:33] <seb128>   - Easier embedding of GTK+ widgets e.g. into Clutter scene graphs"
[10:34] <seb128> pitti, demo on http://blogs.gnome.org/alexl/2009/06/12/the-return-of-client-side-windows
[10:35] <seb128> or http://live.gnome.org/GTK%2B/ClientSideWindows for details
[10:35] <seb128> pitti, it's basically gdk doing the handling directly rather than using the x apis for that
[10:37] <pitti> hah, nice effects
[10:37] <seb128> indeed ;-)
[10:37] <seb128> another gtk test before uploading brb
[10:45] <crevette> hello
[10:49] <chrisccoulson> i took a look at that demo a few days ago - looks awesome :)
[11:05] <chrisccoulson> nice, http://live.gnome.org/Tracker/Roadmap
[11:05] <chrisccoulson> there might be a 0.7 release within the next month according to the ML
[11:05] <chrisccoulson> might be time to get an unstable snapshot in Karmic soon
[11:10] <asac> seb128: new gtk introducies this gdk window management?
[11:10] <Laney> I had to give my password to mount a usb drive too, fwiw
[11:10] <asac> or isnt that new?
[11:10] <asac> http://bugzilla.gnome.org/show_bug.cgi?id=581526
[11:10] <seb128> asac, yes, 2.17.3 just uploaded to karmic
[11:11] <seb128> asac, client side has been merged to git one week ago and the tarball uploaded to karmic 15 minutes ago
[11:11] <seb128> asac, your bug is probably not due to it
[11:11] <asac> right
[11:11] <asac> wonder if its fixed by this though ;)
[11:11] <seb128> dunno
[11:12] <asac> we will see ;)
[11:13] <chrisccoulson> Laney - bug 386699? (sorry if I missed part of your conversation ;))
[11:14] <seb128> chrisccoulson, do you still work on the g-c-c update?
[11:14] <Laney> could be
[11:14] <Laney> I didn't dig into it that much
[11:14] <Laney> thanks though, I'll subscribe
[11:15] <chrisccoulson> seb128 - yeah, i'm still looking at that
[11:15] <seb128> chrisccoulson, ok thanks
[11:15] <chrisccoulson> sorry, i got sidetracked with the metacity issue and some other stuff
[11:15] <seb128> that's ok, I was just looking at what is outdated to clean the table
[11:16] <chrisccoulson> i'll hopefully finish that today, as I finish work at lunchtime
[11:20] <Laney> ah yes
[11:20] <Laney> f-spot can be synced for a sexy space saving now
[11:24] <chrisccoulson> seb128 - i notice we patch some stuff in g-c-c to use ubuntu-system-service to apply some gconf settings system-wide
[11:24] <seb128> right
[11:25] <chrisccoulson> but gconf already provides a way of doing this, which is currently used by g-p-m
[11:25] <chrisccoulson> it seems the functionality is duplicated
[11:26] <chrisccoulson> should these be ported to use the gconf-defaults mechanism instead?
[11:31] <seb128> chrisccoulson, talk to mvo, there was already the gconf feature when he added that I think
[11:31] <seb128> it might have not been working correctly or something
[11:31] <seb128> I'm not sure about the specifics
[11:32] <chrisccoulson> thanks - i'll try and discuss it later with mvo if he's available. i think it works okay at the moment, as the g-p-m preferences dialog and gconf-editor are using it now
[11:33] <seb128> when I played with gconf-editor previous time that didn't work
[11:33] <seb128> that was a month ago or so
[11:33] <seb128> nothing was actually being set
[11:37] <seb128> Laney, f-spot synced
[11:37] <Laney> seb128: thanks, my requestsync was broken
[11:47] <pitti> seb128: oh, did Debian take our patch for the dir selector?
[11:48] <pitti> indeed
[11:49] <seb128> pitti, yes
[11:49] <seb128> pitti, Laney did a good job to get it in sync with debian
[11:49]  * pitti hugs Laney
[11:50] <Laney> \o
[11:50] <mvo> chrisccoulson: hi, I'm happy to discuss that with you now (or later :)
[11:51] <chrisccoulson1> hey mvo - i just had a quick look at the u-s-s source, and I think I've answered my own query
[11:52] <chrisccoulson1> it doesn't really duplicate functionality like i thought
[11:53] <mvo> ok, cool
[11:54] <chrisccoulson1> sorry ;)
[11:54] <mvo> np :)
[11:55] <chrisccoulson1> i think i misunderstood what it did with the keyboard settings - i didn't realise it edited /etc/default/console-setup
[11:55] <chrisccoulson1> which is obviously quite a lot different to what gconf-defaults does;)
[12:29] <chrisccoulson> seb128 - do you know if there are any upstream plans for a graphical tool to configure GDM?
[12:34] <pitti> asac: bug 347972 is fixed "upstream", but open in ubuntu; so that just needs an upload, but is otherwise "done"?
[12:35] <pitti> fta: could you please give me a quick update of bug 387042? this initially looked like "needs an upload", but the most recent comment looks bad
[12:36] <asac> pitti: ubufox will be uploaded in time for the alpha
[12:36] <pitti> asac: i. e. "no blocker here"
[12:36] <pitti> asac: thanks
[12:37] <asac> pitti: pywebkitgtk update isnt needed ... at least not for gwibber
[12:37] <asac> i updated gwibber
[12:37] <asac> in archive and it works well
[12:37] <asac> let me look at  bug
[12:38] <asac> pitti: dont see why its actually filed against pywebkitgtk. i think at some point gwibber wasnt compatible because the pywebkitgtk we had was too new
[12:39] <pitti> asac: ah, it should probably be moved back to gwibber itself
[12:39] <pitti> asac: so this bug was fixed by the newer gwibber snapshot you uploaded?
[12:39] <asac> pitti: the bug is fixed
[12:39] <pitti> asac: and the recent comment is a separate issue?
[12:39] <pitti> asac: cool, thanks
[12:40] <asac> pitti: i uploaded latest gwibber because it didnt work at all
[12:40] <asac> (i had exactly this bug in mind, but couldnt find it because it was not filed against gwibber package)
[12:40] <asac> let me update it
[12:40] <pitti> already done
[12:40] <pitti> thanks for the heads-up
[12:40] <asac> done
[12:52] <seb128> re
[12:52] <seb128> hate hate karmic
[12:52] <seb128> it keeps crashing while I'm away
[12:52] <chrisccoulson> i was thinking of upgrading this weekend;)
[12:52] <chrisccoulson> maybe i'll delay
[12:52] <pitti> seb128: crashing what? x/kernel/gnome?
[12:53] <pitti> seb128: when the screensaver kicks in?
[12:53] <seb128> pitti, dunno what, screen doesn't wake up when I come back
[12:53] <seb128> numlock, etc don't work
[12:53] <seb128> neither do vt switch
[12:54] <pitti> seb128: for some time I had the problem that a DPMS blank would kill the machine
[12:54] <seb128> could be that
[12:54] <pitti> apparently that got fixed a while ago (xorg-edgers, at least)
[12:54] <pitti> can you ssh in?
[12:54] <pitti> or is it completely gone?
[12:54] <pitti> anyway, /me -> lunch
[12:54] <seb128> I just walked away for lunch and when I come back no way to get the machine back working
[12:55] <seb128> dunno I've no other box on to ssh and I rebooted
[12:55] <chrisccoulson> Do any of the Alt+SysRq keys not work?
[12:55] <seb128> I will try next time
[12:55] <seb128> dunno, I never used alt-sysrq and I don't know the combinaisons
[12:55] <chrisccoulson> Alt+SysRq+t will dump some useful information in to the kern.log if the machine is sufficiently alive
[12:56] <geser> chrisccoulson: Hi, do you have time to process your motu application now in #ubuntu-meeting? the MC is having an impromptu meeting (finally got quorum)
[12:56] <chrisccoulson> geser - i'm currently at work at the moment, so it would be a bit difficult for me
[12:57] <seb128> chrisccoulson, you are chatting on IRC though? ;-)
[12:57] <geser> ok, I just wanted to ask as you seem to be around
[12:57] <chrisccoulson> geser - how long will you be there for?
[12:58] <geser> we just started
[12:58] <chrisccoulson> if you give me 5 minutes, i might be able to find myself a quiet room
[12:58] <geser> sure
[12:59] <chrisccoulson> thanks, brb (hopefully)
[12:59] <seb128> trying gnome-do I'm not sure what people like there
[13:00] <seb128> the first dialog has an ugly blurry icon and it seems a slower run command dialog than the default one
[13:00] <seb128> not very easily discoverable either
[13:00] <seb128> it might take some getting used to
[13:02] <Laney> I don't think it's discoverable at all
[13:19] <seb128> chrisccoulson1, \o/ for being a motu now ;-)
[13:20] <chrisccoulson1> thanks seb128:)
[13:23] <Laney> congrats!
[13:24] <chrisccoulson1> thanks:)
[13:24] <chrisccoulson1> right, it's time for me to go home now
[13:26] <lool> seb128: can you confirm packages bdeping on scrollkeeper should now build-dep on rarian or rarian-compat?
[13:27] <seb128> lool, rarian-compat indeed if scrollkeeper commands are really required
[13:29] <pochu> there's no rarian anyway ;)
[13:30] <lool> seb128: thanks
[13:39] <seb128> hey rickspencer3, still on a weird timezone? ;-)
[13:40] <rickspencer3> seb128: yes :(
[13:40] <rickspencer3> I just installed Empathy, and am using it now
[13:40] <rickspencer3> seb128: any tips?
[13:41] <Zdra> rickspencer3: which problem do you have with empathy?
[13:41] <rickspencer3> Zdra: none so far
[13:41] <Zdra> rickspencer3: you can ask for help on #telepathy
[13:41] <pitti> just works here, as well
[13:41] <Zdra> ah :D
[13:41] <pitti> hey rickspencer3
[13:41] <seb128> rickspencer3, tips about? start it and enjoy? ;-)
[13:41] <rickspencer3> I'm updating my desktop to have all the stuff we plan to ship with Karmic
[13:41] <rickspencer3> so I've got grub2, ff 3.5, etc...
[13:42] <rickspencer3> Zdra: it seems to work fine, but could use some usability tweaks here and there
[13:42] <Laney> I noticed that telepathy-haze didn't show the facebook account type from pidgin-facebookchat without some hacking
[13:42] <Laney> might be worth patching
[13:45] <pitti> seb128: do you know what roughly happens for session saving if you stop a session?
[13:45] <pitti> seb128: i. e. apparently programs have to register to gnome-session, and the gdm simple launcher doesn't, or so
[13:45] <pitti> s/launcher/greeter/
[13:47] <seb128> pitti, right, you need to register to the session using smclient I think
[13:47] <pitti> seb128: so we either need to do that, or properly exit the greeter before shutting down the session?
[13:48] <seb128> I don't know the specifics though you might want to ask mvo or vuntz
[13:48] <pitti> ok, thanks
[13:48] <seb128> pitti, if you don't register your program will probably just not be session handled
[13:49] <mclasen> pitti: I've fixed the greeter a while ago; I think those fixes should be in git master
[13:50] <pitti> mclasen: ah, thank you; will build and try that
[13:50] <mclasen> maybe I can convince someone to roll a gdm release...
[13:51] <seb128> mclasen, could you also convince somebody to review the stack of patches in bugzilla.gnome.org? ;-)
[13:51] <mclasen> not so sure about that...
[13:52] <seb128> do you know who could be pinged about that?
[13:53] <pitti> http://git.gnome.org/cgit/gdm/commit/?id=758666242f97ff02c826ee37f2965ac5a828402d \o/
[13:53] <mclasen> the most likely candidate is halfline
[13:53] <seb128> pitti, http://git.gnome.org/cgit/gdm/commit/?id=51443645f2e394c1f138fd285fbbe56962d34779 too maybe
[13:53] <mclasen> pitti: yeah, that is the patch
[13:54] <pitti> seb128: right, while I'm at it
[13:54] <seb128> pitti, I mean that might be worth backporting too
[13:54] <seb128> pitti, thanks!
[13:54] <seb128> mclasen, ok thanks
[13:55] <pitti> mclasen: I wonder why nobody else seems to hit gnome bug 572765; I sent a patch for this, but this bug is too obvious to go unnoticed
[13:56] <mclasen> pitti: there is some nondeterministic behaviour in keyboard handling :-(
[13:58] <mclasen> pitti: the patch makes some sense to me, but it only treats a symptom, no ?
[13:58] <pitti> mclasen: it's not a symptom AFAICS
[13:58] <mclasen> I mean, if the users layout combo is empty, there is a more serious issue...
[13:58] <pitti> gdm doesn't have a keyboard selector and always sets $GDM_KEYBOARD_LAYOUT=us
[13:58] <pitti> and even if it had a keyboard selector, why should the default layout be "us"?
[13:58] <mclasen> why does your gdm not have a keyboard selector ?
[13:59] <pitti> we have X read the default layout from hal, etc.
[13:59] <pitti> mclasen: I don't know, should it?
[13:59] <mclasen> ours does
[13:59] <seb128> pitti, keyboard selection works correctly there
[13:59] <pitti> I only have a locale selector
[13:59] <pitti> mclasen: ok, that's interesting; I'll investigate that
[13:59] <mclasen> it needs one, so people can type their password
[14:00] <pitti> seb128: in gdm?
[14:00] <seb128> the combo is only displayed when an user is selected
[14:00] <seb128> but it's there
[14:01] <pitti> seb128: where should that be? next to the locale selector?
[14:01] <pitti> but either way, if you don't use/select this, it shouldn't hardcode "us" and overwrite hal
[14:02] <seb128> in fact ti's a locale selector right
[14:02] <pitti> seb128: okay, *phew*; I already wondered which s3kr1t gdm you are using :)
[14:03] <pitti> mclasen: so, I found http://live.gnome.org/GDM/Screenshots?action=AttachFile&do=view&target=simple-greeter-user-selected-fedora.png
[14:03] <mclasen> pitti: we used to have a patch in fedora to pick the system layout from /etc/sysconfig/keyboard
[14:03] <pitti> mclasen: this has a "sessions" selector (which we miss as well, looking)
[14:03] <seb128> pitti, I've locale and session combos there
[14:04] <mclasen> pitti: nowadays, we read the system default from hal
[14:04] <pitti> mclasen: right, we have something similar, hal picks the layout from /etc/default/console-setup
[14:04] <pitti> mclasen: so gdm is supposed to read the layout from hal and export it as $GDM_KEYBOARD_LAYOUT?
[14:05] <pitti> mclasen: and wrt. the screenshot, you have a third selector somewhere for keyboard?
[14:05] <mclasen> pitti: yeah, there's a third combo
[14:05] <pitti> oh, there's one on http://live.gnome.org/GDM/Screenshots?action=AttachFile&do=view&target=gdm-a11y-dialog.png
[14:05] <mclasen> pitti: it is all a bit complicated, the gdm daemon has no X connection, so it can't fall back to the layout that X picked
[14:06] <mclasen> pitti: that is why we fall back to hal (where X got its layout in the first place...)
[14:06] <seb128> pitti, http://bugzilla.gnome.org/show_bug.cgi?id=521100
[14:07] <mclasen> and all this is only for the initial situation, before the user picked the right layout once
[14:07] <mclasen> once he did that, it is remembered in .dmrc
[14:07] <pitti> mclasen: ah, perhaps it's http://cvs.fedoraproject.org/viewvc//devel/gdm/gdm-system-keyboard.patch?view=markup
[14:08] <mclasen> yes
[14:09] <pitti> ok, sooner or later that will become obsolete anyway, AFAIK Peter Hutterer is working on a hal -> udev migration in X
[14:09] <pitti> mclasen: thanks for your help!
[14:10] <mclasen> np
[14:18] <pitti> seb128: ok, so above patch didn't help for the greeter session bug
[14:18] <seb128> do you get a similar issue if you use compiz?
[14:19] <pitti> seb128: in gdm?
[14:19] <seb128> yes
[14:19] <seb128> could be a bug on the wm side
[14:19] <pitti> (gnome-settings-daemon:26519): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
[14:19] <seb128> or a gnome-session one
[14:19] <pitti> Fenstermanager-Warnung: Gespeicherte Sitzungsdatei /var/lib/gdm/.config/metacity/sessions/10f5e667d3a443982124723185079248100000265130000.ms konnte nicht gelesen werden: Datei »/var/lib/gdm/.config/metacity/sessions/10f5e667d3a443982124723185079248100000265130000.ms« konnte nicht geöffnet werden: No such file or directory
[14:19] <pitti> that might be related
[14:20] <pitti> "couldn't read saved session file"
[14:20] <pitti> (/var/lib/gdm/.config/ is in fact empty)
[15:00] <pitti> chrisccoulson: congratulations to your MOTU ranks! finally!
[15:00]  * pitti hugs chrisccoulson
[15:01]  * chrisccoulson hugs pitti
[15:01] <chrisccoulson> thanks:)
[15:06] <pitti> seb128: ah, got the keyboard selector now;  missing xklavier b-dep
[15:06] <seb128> pitti, oh, good catch!
[15:12] <pochu> chrisccoulson: congrats :)
[15:12] <chrisccoulson> thanks pochu:)
[15:27]  * seb128 is away for some errants bbl
[15:28] <fta> why is xchat no longer in the tray when started with the gnome session?
[15:32] <seb128> fta, dunno xchat is an universe software we don't work on it
[15:32] <seb128> I use xchat-gnome
[15:32] <seb128> and other people there is command line utilities or their im client
[15:34]  * hyperair uses irssi in screen
[15:34] <fta> i guess it's more a tray issue
[15:40] <hyperair> fta: perhaps xchat started before the panel =\
[15:41] <fta> hyperair, that's my guess too, but it's a regression
[15:41] <hyperair> in that case, it would be because gnome-panel's starting later or something =\
[15:41] <hyperair> either way, i believe the bug would lie with xchat for not automatically detecting the tray's appearance
[15:42] <hyperair> e.g. when you kill the panel, and the panel restarts, i dont think the xchat icon comes back
[15:51] <chrisccoulson> fta - how do you have xchat start with the session? did you add it to startup applications or is it via a saved session?
[15:52] <fta> startup applications
[15:52] <chrisccoulson> in that case, it's guaranteed to start after the panel
[15:53] <chrisccoulson> the panel starts in an earlier phase, and gnome-session doesn't progress to the application phase (where xchat will be) until all stuff in the panel phase finished loading
[15:53] <chrisccoulson> at least, it should work like that;)
[15:54] <fta> if i restart xchat, it appears in the tray as before.
[15:54] <chrisccoulson> hmmmm:-/
[15:55] <chrisccoulson> when did it stop working?
[16:36] <pochu> fta: there was a similar bug reported against amule IIRC
[16:37] <fta> chrisccoulson: not sure, i'd say no more than 2 weeks old
[16:50] <chrisccoulson> fta - i wonder if xchat should connect to the size-changed signal on the GtkStatusIcon? I notice that other applications which work ok already do this (eg, network-manager-applet redraws the icon on this signal), but xchat does not
[16:51] <chrisccoulson> (i'm just trying to think of why other applications work correctly, but xchat does not)
[16:56] <chrisccoulson> hmmm, it's not that
[17:05] <fta> chrisccoulson, are you able to reproduce?
[17:08] <chrisccoulson> fta - i haven't actually. but i've been trying to look at the differences between apps which work and which don't
[17:08] <chrisccoulson> you're using karmic right?
[17:08] <fta> yes
[17:08] <chrisccoulson> heh. might help if i try with the same version as you;)
[17:12] <chrisccoulson> fta - i can reproduce it on karmic too
[17:12] <fta> so i'm not alone, good :)
[17:13] <chrisccoulson> i've got to disappear now, but i might take a look later to see if i can figure out whats going on
[17:14] <fta> thanks
[17:14] <Laney> you also need to make your inaugral upload ;)
[17:15] <chrisccoulson> Laney - i do ;)
[17:55] <pitti> have a great weekend everyone
[18:08] <lool> Laney: Are you working on a tomboy SRU or do you know who would be?
[18:08] <Laney> lool: what for?
[18:10] <lool> Laney: In 345166 someone mentions a probable SRU
[18:10] <Laney> bug 345166
[18:11] <lool> ""
[18:11] <lool> ""
[18:11] <lool> My understanding is that 0.14.2 is going to be in an upcoming Jaunty update. I'm not really involved in Ubuntu packaging, though.
[18:11] <Laney> Not that I know of
[18:12] <lool> Laney: Is it worth pushing a SRU just for this bug?
[18:12] <lool> Laney: I don't run tomboy myself, this is via the main sponsorship queue
[18:12] <Laney> lool: I'll have a look in a min, busy ATM
[18:14] <lool> Ok
[18:15] <lool> I have a debdiff ready
[18:18] <asac> superm1: hi. did you ever find the time to check if blueman has any deficiencies over gnome-bt for the test devices you have?
[18:18] <superm1> asac, so i was able to make all of my devices work with blueman
[18:19] <superm1> there were some UI deficiencies I saw where I got confused at times, but everything was functional
[18:19] <asac> superm1: UI deficicies? compared to gnome-bt ?
[18:19] <asac> or general?
[18:20] <superm1> asac, well there are a couple of ways to associate the device in blueman, and i wasn't successful with all of them
[18:20] <superm1> i just think it's a few bugs in blueman that need to be cleaned up
[18:20] <asac> yeah ok
[18:20] <superm1> but compared to gnome-bt, blueman was more functional for me (since it got me DUN too)
[18:20] <superm1> and after enabling the blueman pulse plugin, that actually worked properly for me too
[18:21] <asac> superm1: if you scratch network support from the comparison
[18:21] <asac> do you see any benefit of gnome-bt over blueman?
[18:21] <superm1> well, in it's current state no
[18:21] <superm1> the biggest thing probably is knowing upstream's intent for each of the projects though
[18:22] <superm1> and how well they will be supported and responsiveness to bug fixing
[18:23] <asac> yeah. so gnome-bt guy says there wont be any changes ... but his mail didnt really sound like he was interested in talking
[18:23] <asac> also gnome-bt needs this new obexd thing
[18:23] <asac> which sounds messy as we wont be able to replace obex-data-server completely
[18:23] <superm1> oh yeah, file transfer works perfectly both ways with blueman
[18:23] <jcastro> I am at GCDS with upstream, what questions do I need to ask?
[18:23] <superm1> forgot about that
[18:24] <asac> jcastro: with blueman folks?
[18:24] <jcastro> the fork that bastien started
[18:24] <asac> jcastro: i got what i wanted to know from him
[18:24] <jcastro> lool: if you have a debdiff for .14.2 that would be great, seb told me he would look at pushing out .14.2 next week
[18:25] <jcastro> lool: upstream is keen on getting those fixes to jaunty users
[18:25] <superm1> asac, so the things that gnome-bt would be missing in the current state are: pulse association when pairing, DUN, and file transfer receiving
[18:25] <superm1> all of which blueman does
[18:26] <asac> superm1: the question is what would blueman be missing
[18:26] <asac> i am leaning towards using blueman, because a) its more mature and has a nice UI that even my mother would feel comfortable with
[18:26] <asac> b) doesnt require obex-data-server, which is pretty new and most likely buggy
[18:26] <asac> err obexd
[18:26] <superm1> i think you guys will need to lean in on the usability folks yet before i'd say it's good for mom and grandma and stuff
[18:27] <superm1> but it's a lot closer than bluez-gnome and gnome-bt
[18:27] <asac> superm1: i am sure that my mother would feel more comfortable without asking usability folks ;)
[18:27] <jcastro> wait, there's another bluetooth thing?
[18:27] <asac> we can ask usability folks how to further improve it
[18:27] <superm1> right
[18:27] <asac> jcastro: blueman
[18:27] <asac> jcastro: blueman
[18:27] <jcastro> so there's bluez-gnome, gnome-bt, and blueman?
[18:28] <asac> blueman, gnome-bt and blue-gnome ;)
[18:28] <superm1> as for what it's missing, it needs to have pulse support turned on by default
[18:28] <asac> in that order ;)
[18:28] <superm1> otherewise i think it hits the services/features that we were looking for
[18:28] <asac> superm1: ok. thats a packaging thing i guess
[18:28] <asac> i took notes and will check them out with blueman upstream
[18:29] <superm1> as for bluez on the foundations side, i mentioned switching to dynamically spawning bluetoothd when an adapter is detected
[18:29] <superm1> i've got a new package ready for that (all the code is finally upstream), but it is having some weird interactions with udev
[18:30] <superm1> it doesn't work if the adapter is plugged in during boot
[18:30] <asac> superm1: do you have it somewhere?
[18:30] <superm1> but if you plug it in later it's fine
[18:30] <asac> superm1: do you use dbus activation through a dbus-send or something?
[18:30] <superm1> asac, just locally, I was hoping to sort it out before uploading to the archive
[18:30] <superm1> it's a udev rule that looks for the "add" action of something in the bluetooth subsystem
[18:30] <superm1> and spawns bluetoothd when that happens
[18:31] <asac> superm1: yeah. just wondered if the spawning happens through dbus activation
[18:31] <superm1> if i can't sort it out later, i'll throw it on a PPA and see if I can get some more eyeballs on it
[18:31] <asac> or could you already identify that the problem is that this add action isnt run at all?
[18:31] <superm1> i dont think it's ran, but i cant figure out how to get udev to verbosely log during boot to show me all the actions ran
[18:31] <superm1> and when they try to get ran
[18:32] <asac> superm1: saying, if its using dbus-send .... explicitly wait for a reply to avoid a race condition bug that eats dbus messages if the sender exits too quickly
[18:32] <superm1> it definitely does run (and work properly) after the system is booted and you plug in an adapter
[18:32] <asac> we had that in NM a lot
[18:32] <asac> e.g. the "networking disabled after resume"
[18:33] <superm1> there's an annoying problem related to dell  bt hardware after resume that is eating me up inside too, but that's besides the point..
[18:33] <asac> superm1: just curious could you post the udev rule?
[18:33] <superm1> sure, sec
[18:33] <jpds> asac: blueman rocks!
[18:33] <asac> yay!
[18:34] <superm1> (from source): scripts/bluetooth.rules.in:ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="@prefix@/sbin/bluetoothd --udev"
[18:34] <jcastro> yeah, mine worked ootb. (blueman)
[18:34] <superm1> (of course during build, prefix is changed)
[18:34] <lool> jcastro: I only have a debdiff for the particular bug I mentionned; upstream seems nice, but I don't use tomboy so it's a bit misplaced for me to prepare a SRU
[18:34] <lool> I could but well
[18:34] <jcastro> lool: ask seb first I think, he said he was on it for next week.
[18:34] <lool> seb128: Oh cool, you're working on a tomboy SRU?
[18:35] <lool> jcastro: thanks for the info!
[18:35] <jcastro> lool: I wined and dined him and begged him. :p
[18:44] <lool> jcastro: Any other SRU you'd need from me?   O:-)
[18:46] <jcastro> heh, not that I know of, I'm sure there's plenty
[18:47]  * lool will find a way to get dined and wined too
[18:48] <asac> superm1: can you file a bug about automatic pulse in http://bugs.launchpad.net/ubuntu/+source/blueman please?
[18:49] <superm1> asac, sure, bug 397924
[18:50] <asac> superm1: anything else you could file? also will help us to test upstream reactions
[18:51] <superm1> asac, regarding my pairing deficiency, let me rerun my case through and take notes and then i'll file that
[18:51] <superm1> won't be able to until early next week though
[18:51] <asac> superm1: greawt
[18:51] <asac> thats good enough
[18:53] <superm1> did you find any problems with your hardware when you tested?
[18:57] <seb128> lool, you can do the tomboy sru if you want, I told jcastro I would do it but I didn't start yet
[19:58] <Laney> lool: I don't mind. I'll prepare the 0.14.2 SRU if it's approved but I don't think any of the bugs are that critical.
[21:04] <lool> Laney: Apparently you might want to check with seb128 as he might be preparing it too