[01:37] <robert_ancell> TheMuso, are you going to package gnome-mag 0.15.7?
[02:34] <TheMuso> robert_ancell: oh I missed that upload. Yes, I will do it, thanks.
[02:35] <robert_ancell> TheMuso, cool.  I thought it might have slipped through
[03:41] <robert_ancell> TheMuso, can you upload compiz 0.8.2-0ubuntu15?
[03:45] <TheMuso> robert_ancell: Sure. I assume its in bzr?
[03:46] <TheMuso> nvm found it
[03:49] <TheMuso> robert_ancell: where is ubuntu15?
[03:53] <robert_ancell> TheMuso, yes, it's in bzr
[03:56] <TheMuso> hrm ok, I don't see it anywhere
[04:00] <robert_ancell> TheMuso, oh, it's under the compiz user: lp:~compiz/compiz/ubuntu
[04:06] <TheMuso> Yeah thats what I pulled.
[04:07] <TheMuso> oh its ubuntu14
[04:07] <TheMuso> ...or not
[04:07] <TheMuso> LP might be playing up.
[04:09] <robert_ancell> TheMuso, my bad.  I hadn't pushed.  Should be there now
[04:10] <TheMuso> Ok thanks.
[04:16] <TheMuso> robert_ancell: The package FTBF sfor me.
[04:16] <TheMuso> *FTBFs for
[04:17] <robert_ancell> TheMuso, hmm... i'll fix that...
[04:28] <robert_ancell> TheMuso, the compiz package has patches that apply to files in debian/ - have you ever seen that before?  I'm probably going to remove those patches and just apply directly
[04:29] <TheMuso> robert_ancell: No never seen that. Thats rather stupid if you ask me.
[04:56] <robert_ancell> TheMuso, ok, updated.  Should build now
[05:15] <TheMuso> robert_ancell: ok thanks
[05:31] <TheMuso> robert_ancell: uploaded.
[05:54] <robert_ancell> TheMuso, thanks
[06:00] <TheMuso> robert_ancell: np
[06:20] <robert_ancell> TheMuso, btw, are you also aware onboard 0.91.2 has been released?
[06:35] <TheMuso> robert_ancell: No, I will update it later.
[07:34] <pitti> Good morning
[07:35] <pitti> mac_v: no manpages for gdm.schemas; gconf provides inline explanations (or not, if the author didn't supply them)
[07:35] <pitti> hyperair: sounds like a known bug
[07:45] <mac_v> pitti: the gconf doesnt have all the options, listed in the gdm.schemas , or maybe i'm not looking at the right place... i just want to turn on the auto login and set the timer from 30->10 secs... any ideas?
[07:49] <pitti> mac_v: timed login doesn't work ATM, I'm afraid; autologin is currently defined in /etc/gdm/custom.conf
[07:50] <mac_v> pitti: ok.... also do you have any plans on removing/moving the Language,accesibility & keyboard options?
[07:50] <pitti> "moving"?
[07:50] <pitti> well, the entire design of that greeter is at disposition, I guess
[07:50] <pitti> but for now I'm still worried in making it work (DX team will make it pretty)
[07:51]  * pitti pokes at bug 401201 and bug 395103
[07:51] <mac_v> pitti: moving the those options to a menu item labelled "Options" , as they are not frequently used anyway
[07:54]  * mac_v feels uncomfortable with the gdm , likes the gdm to look something non-fedora
[08:00] <asac> hi
[08:01] <mac_v> pitti: i just need to add "AutomaticLoginEnable=True"  in /etc/gdm/custom.conf after the [daemon] line.. right? just asking , dont want to mess things up
[08:01] <pitti> hey asac
[08:01] <asac> moin moin ;)
[08:02] <pitti> asac: yes, and AutomaticLogin=yourusername
[08:02] <pitti> erm, mac_v ^
[08:02] <mac_v> pitti: ok... thank you
[08:04] <mac_v> asac: about editing the ff35 link which points to your blog? , for the firefox-3.5-gnome-support
[08:06] <robert_ancell> hey pitti
[08:10] <pitti> hey robert_ancell, how was your weekend?
[08:10] <robert_ancell> pitti, good
[08:10] <asac> mac_v: what?
[08:11] <asac> mac_v: what do you suggest?
[08:13] <mac_v> asac: we discussed the other day on the ubuntu mozilla irc,maybe you forgot, you could add a mention in the firefox 3.5 link that mentions the need to add the firefox-3.5-gnome-support package in addition in Jaunty, some users are getting confused, why firefox 3.5 doesn get set as the default
[08:13] <mac_v> !ff35
[08:14] <mac_v> s/that mentions/to mention
[08:19] <asac> mac_v: thanks for the reminder. added
[08:23] <pitti> geser: are you sure that the bug in gdm is exactly the same? when I switch to German keyboard layout in console-setup, now gdm itself uses US layout
[08:24] <chrisccoulson> good morning everyone
[08:25] <pitti> hey chrisccoulson
[08:25] <chrisccoulson> hey pitti
[08:25] <chrisccoulson> good weekend ?
[08:28] <pitti> yes, I had; quiet, but relaxing; and you?
[08:28] <seb128> good morning there
[08:29] <seb128> hey pitti!
[08:29] <pitti> bonjour seb128
[08:31] <chrisccoulson> pitti - my weekend was quite relaxing too, apart from moving my computer in to its new home
[08:31] <chrisccoulson> hey seb128
[08:31] <seb128> hi chrisccoulson
[08:31] <pitti> chrisccoulson: you move your computer without moving along yourself?
[08:32] <chrisccoulson> pitti - i only moved it in to another room in the house. the old room has to be used for something else now ;)
[08:35] <didrocks> good morning o/
[08:35] <chrisccoulson> seb128 - i did the gnome-settings-daemon update last night. i dropped the gstreamer volume patch from the update, seeing as we're now using the pulseaudio volume control applet - i wasn't sure whether you wanted to do that though
[08:35] <chrisccoulson> i can re-add it again if not ;)
[08:35] <seb128> no that's good
[08:35] <chrisccoulson> cool. the notifications patch needed a bit of reworking to work with the new code too
[08:38]  * seb128 is catching up on weekend emails now and will do sponsoring after that
[08:43] <seb128> pitti, gdm 2.27.4 tarball available if you want to do the update
[08:43] <pitti> seb128: already done in bzr
[08:43] <pitti> seb128: currently fighting with bug 395103 again
[08:43] <seb128> pitti, you wake up way earlier than me apparently ;-)
[08:43] <pitti> seb128: usually I start around 8
[08:44] <didrocks> seb128: when you have some time, can you please just give a look at my gobject-introspection merge? I didn't upload it (http://www.didrocks.fr/temp/gobject-introspection_0.6.3-1ubuntu1.dsc). I mostly wondered by the DM didn't add replaces/conflicts against python-girscanner in gobject-introspection (to remove the python-girscanner package from system, even if now shipped files changed their path)
[08:45] <seb128> didrocks, replaces is only required when overwriting content
[08:45] <seb128> didrocks, not using conflicts is probably an oversight if the new version is an update of the old naming
[08:46] <didrocks> seb128: yes, but conflicts alone won't remove the package and just forbide to upgrade
[08:46] <seb128> that would be an apt bug
[08:47] <seb128> or not bug but upgrade calculation issue
[08:47] <seb128> do you have anything depending on the old naming and the new one?
[08:47] <didrocks> it doesn't prevent from upgrading and will remove the conflicting package?
[08:47] <seb128> well that's what dist-upgrade is supposed to do
[08:48] <didrocks> no, I didn't try to just put conflicts alone (and there is no depend on the old naming), it was more a theorical thought
[08:48] <seb128> it puts things on hold when using Breaks
[08:48] <seb128> but when using Conflicts it should install the new one
[08:48] <didrocks> ok, so I can only put Conflicts
[08:48] <seb128> yes, as said Replaces is only if you overwritte content
[08:49] <didrocks> I knew that, but I previously (and wrongly ) thought that's the couple Replaces/Conflicts was needed to remove the conflicting package. My bad so ;)
[08:50] <didrocks> I will change that this evening, test it and upload the package, so. Thanks :)
[08:51] <seb128> didrocks, you're welcome
[09:13] <geser> pitti: I'm not sure that't the same bug, but the result is the same: I have now again a USA layout till it reset it back to german
[09:14] <seb128> pitti, bug #589024, did you ship the new binary in some .install?
[09:14] <seb128> pitti, could explain all the bugs about nautilus not storing positions, etc
[09:14] <seb128> bug #401367
[09:31] <davmor2> pitti: How are the iso's looking?
[09:43] <rodrigo_> dh: --with quilt not supported or failed to load module Debian::Debhelper::Sequence::quilt
[09:44] <rodrigo_> getting ^^ on jaunty, any idea what's missing?
[09:44] <rodrigo_> on karmic it builds ok
[09:45] <didrocks> rodrigo_: debhelper jaunty version is not new enough
[09:45] <rodrigo_> hmm
[09:49]  * seb128 managed to clean weekend emails backlog before lunch this week
[09:50] <seb128> short break and sponsoring coming next
[09:52] <didrocks> seb128: congrats! I really don't want to imagine the number of bug mails you can receive within a weekend :)
[09:52] <seb128> didrocks, july is quiet
[09:53] <seb128> I had some 300 bug emails since saturday when I did read my emails
[09:53] <seb128> and maybe 80 other emails
[09:53] <seb128> it's sometime over 800 emails after weekend on busy weeks
[09:53] <didrocks> that's still a high volume of bug emails, even 300 in july
[09:53] <chrisccoulson> seb128 - you need a secretary to read your mail ;)
[09:54] <seb128> ah ah
[09:54] <maxb> rodrigo_, didrocks: It's the quilt version in jaunty that isn't new enough, as far as that particular error is concerned
[09:54] <pitti> re (sorry, was on VTs, debugging gdm)
[09:55]  * pitti radiates hate towards gdm, it keeps breaking
[09:55] <pitti> 2.27.4 is an absolute desaster
[09:55] <rodrigo_> maxb: ok, trying to build it without the --with-quilt version
[09:55] <rodrigo_> pitti: yes, switch user crashes my desktop :(
[09:56] <pitti> no, the greeter crashes instantly
[09:56] <pitti> seb128: you mean it's missing a file? could be, haven't checked
[09:56] <maxb> rodrigo_: If it has quilt patches, simply not applying them isn't going to be a good option
[09:56] <seb128> pitti, yes, the new backend which does all the properties handling for nautilus
[09:56] <rodrigo_> maxb: yeah
[09:56] <pitti> seb128: thanks for spotting
[09:57] <seb128> pitti, I'm about to do a 15 minutes break and then will do sponsoring and will have a look at gvfs after lunch if nobody is faster
[09:57] <pitti> seb128: cool, thanks; I hope I can unbreak gdm today (&#($*#$ keyboard layout)
[09:57] <seb128> pitti, you're welcome, that's just upstream comment asking if that new backend was running which made me think about that
[09:57] <pitti> do other people have US layout in gdm itself now, too?
[09:58] <maxb> rodrigo_: So basically the options are to backport quilt as well, or to modify the rules file of the other package to build in the logic that --with quilt would invoke
[09:58] <seb128> I'm not using your git snapshot but I can if you want
[09:58] <seb128> pitti, ^
[09:58] <pitti> seb128: oh, what do you use?
[09:59] <seb128> pitti, 2.26.1-0ubuntu7, I just didn't dist-upgrade since friday
[09:59] <pitti> ah, ok
[09:59] <seb128> will do that now
[09:59] <seb128> brb testing new gdm
[10:00]  * pitti -> off again for gdm debugging
[10:05] <seb128> re
[10:05] <seb128> pitti, yes, keymap is USA by default now
[10:15] <pitti> seb128: where exactly?
[10:15] <pitti> I just tried it, and for entering passwords I get the system layout (correctly)
[10:15] <seb128> pitti, when I click on my user name the combo box for keyboard
[10:15] <pitti> but if I go to "other", it defaults to USA
[10:16] <pitti> or any other user name, yes
[10:16] <pitti> seb128: but for entering your password it's correct, right?
[10:16] <seb128> let me try, I did pick french before entering the password
[10:16] <seb128> but I think the combo is for the user session
[10:16] <seb128> not the login screen itself
[10:16] <pitti> right
[10:17] <pitti> well, if I select "other", and type the user name, I get US
[10:17] <seb128> ditto
[10:17] <seb128> that's the bug
[10:17] <seb128> it should use the system default
[10:17] <pitti> seb128: did it really get that right with 2.26.1?
[10:17] <geser> pitti: if it matters, I've auto-login enabled and get a us layout
[10:18] <pitti> geser: ah, so you never picked the layout
[10:18] <seb128> pitti, I'm not sure now
[10:18] <pitti> geser: can you show me your ~/.dmrc?
[10:18] <geser> no
[10:18] <pitti> if I pick the layout once, it's fine
[10:18] <pitti> ok, then I think I know what to do
[10:18] <geser> [Desktop]
[10:18] <geser> Session=gnome
[10:18] <pitti> no Layout= then
[10:18] <seb128> pitti, btw your xsession script change made seahorse-agent not be run
[10:18] <pitti> ok, that explains it then
[10:18] <pitti> seb128: I know, already fixed in bzr
[10:19]  * seb128 hugs pitti
[10:19] <seb128> you rock ;-)
[10:19] <pitti> seb128: but I need to back out 2.27.4, it makes the greeter crash
[10:19] <seb128> fixing bugs faster than we notice those ;-)
[10:19] <seb128> do you have a stacktrace?
[10:19] <pitti> yes
[10:19] <seb128> can I see it? ;-)
[10:20] <pitti> was overwritten by my last gdm restart, but I'll get it again
[10:20] <seb128> ok
[10:20] <pitti> lots of gobject stuff and a failed assertion
[10:21] <seb128> don't bother too much I can have a look with a local build later
[10:21] <seb128> there is not too many commits between your snapshot and the tarball should be easy to find the buggy one
[10:23] <pitti> I already tried to revert the two major ones
[10:23] <pitti> gdm-check-worker-state.patch and gdm-duplicate-usernames.patch
[10:23] <pitti> those weren't it
[10:24] <didrocks> pitti: (just as a notice, nothing really urgent there). I played this week-end in integrating distutils-extra auto to quickly. I have found some annoying things and some of them can be called bugs. I didn't opened them yet as I think you can want to have a look at them first: https://wiki.ubuntu.com/DidierRoche/distutils-extra.auto
[10:25] <didrocks> pitti: I tried to categorize them, but it can be wrong and only from my point of view :)
[10:25] <didrocks> feel free to edit the page to comment when you have some time
[10:26] <pitti> didrocks: clean> did you try ./setup.py clean -a ?
[10:26] <pitti> didrocks: good stuff ther
[10:28] <didrocks> pitti: hum, no. I will try it :)
[10:28] <didrocks> pitti: thanks
[10:33] <pitti> seb128: ok, got the keyboard thing nailed now; I'll bisect now to find the 2.27.4 breakage
[10:52] <seb128> chrisccoulson, gnome-session uplodaed, gnome-settings-daemon has a small .install issue
[10:52] <chrisccoulson> seb128 - thanks, i didn't notice that :-/
[10:53] <pitti> seb128: meh, I reverted all patches now, and it still breaks; will take some more time
[10:54] <seb128> pitti, do you want me to test build the bzr version to see if I get the issue too?
[10:55] <pitti> seb128: if you have time, but I don't think it's something local
[10:55] <pitti> if I re-build the karmic version on current karmic, it still works (i. e. it's not a build-time failure against newer gobject or so)
[10:55] <seb128> pitti, let me run a build it shouldn't take too long to test
[10:56] <pitti> seb128: ok, it wasn't "all" patches yet, I didn't include the NEWS and translations changes
[10:56]  * pitti dives into diff harder
[10:59] <vuntz> seb128: yop
[10:59] <seb128> lut vuntz
[10:59] <vuntz> seb128: I believe you guys are using the compiz-manager script, but install it as compiz (and rename compiz to compiz.real). Is this right?
[10:59]  * pitti hugs vuntz
[10:59] <seb128> vuntz, correct
[11:00] <vuntz> seb128: okay... Trying to figure out how to make compiz-manager usable from upstream gnome-wm
[11:01] <vuntz> seb128: was planning to do something like "if test "x`which compiz-manager`" != "x"; then use compiz-manager, else use compiz"
[11:01]  * vuntz hugs pitti 
[11:02] <seb128> vuntz, looks good to me
[11:02] <vuntz> seb128: ugh, the gnome-wm tweaks you do in a patch are weird
[11:02] <vuntz> seb128: do you really need /desktop/gnome/applications/window_manager/default?
[11:02] <seb128> why?
[11:03] <vuntz> seb128: (you'd probably need to add a link from compiz to compiz-manager to not have to patch out the gtk-window-decorator call, btw)
[11:03] <seb128> vuntz, the gconf key is there for compatibility reasons I think
[11:04] <mat_t> seb128: hi
[11:04] <seb128> hey mat_t
[11:04] <mat_t> seb128: do you know anything about the planned features for the new gdm?
[11:05] <seb128> mat_t, nothing planned over what we have now in karmic
[11:05] <seb128> mat_t, what sort of feature are you looking after?
[11:05] <mat_t> seb128: in particular, what the prefs menu will cover
[11:05] <seb128> mat_t, upstream doesn't want a preference menu or dialog
[11:06] <seb128> mat_t, they want autologin to be a checkbox in the user account tool
[11:06] <mat_t> seb128: cool, that sounds good!
[11:06] <mat_t> seb128: so what will the options be: autologin/no autologin, what about the face browser?
[11:07] <seb128> mat_t, there is no face browser yet and will not be one for karmic
[11:07] <seb128> mat_t, input from the design team on where a such option should go would be welcome though
[11:07] <mat_t> seb128: I meant user picker
[11:07] <seb128> ?
[11:07] <mat_t> seb128: atm I've got a user icon and user name next to it
[11:07] <seb128> right, those are the accounts on the system
[11:07] <mat_t> seb128: I click on the user name to access the password
[11:08] <seb128> ie the "about me" capplet let you set those
[11:08] <mat_t> I see
[11:09] <chrisccoulson> seb128 - fedora have a g-c-c patch for applying themes sytem-wide from gnome-appearance-properties (eg, to change the GDM theme) - do you think we should use this patch?
[11:10] <seb128> chrisccoulson, no opinion, it has been discussed upstream for a while now
[11:10] <seb128> I would welcome opinion from the design team about that too in fact
[11:10] <mat_t> chriscoulson: does that mean ability to apply any gtk theme to the gdm, regardless of the individual user settings?
[11:10] <seb128> does it make sense to split options in different dialogs or de we want a gdmsetup tool
[11:10] <chrisccoulson> ok, no problem. i noticed it when looking at their polkit-1 patch, as that patch touched code that only they have in their version
[11:11] <mat_t> chrisccoulson: sorry mistyped your nick ^
[11:11] <chrisccoulson> mat_t - it would allow you to change the default system theme, much in the same way that you can change the default keyboard layout already
[11:11] <seb128> chrisccoulson, it's bug #536531
[11:11] <seb128> gnome bug #536531
[11:12] <chrisccoulson> seb128 - yeah, thats the one
[11:12] <mat_t> chrisccoulson: that sounds like a good idea
[11:12] <chrisccoulson> mat_t - yeah, i thought so. i'll take a look at that patch
[11:12] <seb128> the thing is how do you change the login background then?
[11:12] <seb128> you change your, use the set system default
[11:12] <seb128> and then select back the one you want for your user?
[11:12] <mat_t> chrisccoulson: great!
[11:13] <chrisccoulson> seb128 - changing the system default will change the GDM background and that of new users and users who are stll using the default
[11:13] <seb128> brb
[11:14] <mat_t> seb128: chrisccoulson: can you explain what the background behaviour would be?
[11:15] <mat_t> chrisccoulson: would the user be able to set the gdm background?
[11:15] <chrisccoulson> yeah, the button would change the system default background. This would set the GDM background, and would also set the background adopted by new users created on the system in the future
[11:16] <chrisccoulson> GDM adopts the system defaults currently, just like any other user on the system
[11:16] <mat_t> I seer
[11:16] <mat_t> see ^
[11:16] <mat_t> :)
[11:17] <chrisccoulson> i don't think it's ideal, but it's better than nothing and seems to be the direction that upstream are going in anyway (ie, no separate login screen preferences)
[11:17] <seb128> re
[11:17] <mat_t> chrisccoulson: yes, I think it's a good direction
[11:17] <seb128> chrisccoulson, well I think we should get input from the design team if they think it's better to have a tools or not
[11:18] <chrisccoulson> seb128 - yeah, i don't mind either way
[11:18] <mat_t> chrisccoulson: where would that be set from? Gdm menu?
[11:18] <seb128> mat_t, well it makes easy to use your background for gdm too
[11:18] <seb128> mat_t, but is that something people want to do usually? I don't want to login screen to have a personal photo I'm using for example
[11:19] <mat_t> seb128: good point
[11:19] <seb128> so the button to set as system default means I've to unconfigure my background to set the gdm one and then configure it back
[11:19] <seb128> pitti, greater crash here too, seems to be keyboard thing
[11:20] <mat_t> seb128: hmm that sounds a bit confused
[11:20] <pitti> if I may throw in my 2 cent, the only logical place for me would be in the gdm screen itself
[11:20] <pitti> I would probably never suspect my personal background image config dialog to be able to set the gdm screen
[11:20] <pitti> seb128: just captured a log with debug info
[11:21] <pitti> seb128: http://people.ubuntu.com/~pitti/tmp/gdm-greeter.log
[11:21] <pitti> but I still don't understand it
[11:21] <mat_t> seb128: I think the gdm should remain unpersonalised. It's a bit like a public door to the house with many flats - some tenants may not like your choice of grafitti on it :)
[11:22] <pitti> well, we do need to be able to configure autologin
[11:22] <pitti> and that's so unrelated to "about me"
[11:22] <pitti> I'd much rather like to see it in gdm itsefl
[11:22] <seb128> pitti, we were speaking about background, autologin in user account was not controversial
[11:22] <mat_t> correct
[11:22] <seb128> pitti, yeah, same crash here
[11:24] <mat_t> seb128: pitti: the avatar in the user picker makes it personal I guess. The problem now is that it's very difficult to discover how to change it
[11:25] <mat_t> seb128: pitti: will that option be available while you set up your user account?
[11:25] <seb128> you mean the face for your user or the computer icon?
[11:25] <pitti> mat_t: ubiquity offers to configure autologin, yes
[11:25] <mat_t> pitti: inc. avatar?
[11:25] <pitti> mat_t: not right now
[11:26] <pitti> mat_t: and I guess the installer is a bad environment to set it, too, since you usually don't have access to your photos there
[11:26] <mat_t> pitti: I'm more interested in first run, although installer is the valid case, too
[11:26] <pitti> seb128: meh, it didn't change anything in gdm_get_layout_from_name() or related..
[11:26] <pitti> mat_t: we don't have a "first run" wizard
[11:26] <pitti> (by design)
[11:27] <mat_t> pitti: I'm referring to the set-up that you perform when you buy, e.g. Dell with Ubunu preinstalled
[11:27] <pitti> ah, oem-config
[11:27] <mat_t> yes
[11:27] <pitti> mat_t: that's pretty much the same as in ubiquity now
[11:27] <mat_t> I see
[11:28] <pitti> but again, at this time the computer is virgin, and doesn't have your files?
[11:28] <pitti> so you could only choose between a few default avatars
[11:28] <pitti> which is proably reasonable
[11:28] <mat_t> Sure, but we could offer a nice selection to start with, and info how to change it later
[11:28] <pitti> just mentioning that you probably won't have access to personal files
[11:28] <mat_t> yeah
[11:28] <pitti> right, avatar should be in "about me"
[11:29] <mat_t> atm it's in the "Account information..." in FUSA menu
[11:29] <mat_t> Is that "about me"?
[11:30] <pitti> yes
[11:30] <mat_t> cool
[11:30] <pitti> it's also in system->prefs
[11:31] <mat_t> ok, that makes a lot of sense then. So the conclusion would be that gdm background should not be editable
[11:31] <mat_t> atm we're working on theming for the boot, os switcher and the gdm
[11:32] <mat_t> so that it's a smooth experience
[11:32] <pitti> fine for me
[11:32] <pitti> but that still leaves the question where to put autologin settings
[11:32] <mat_t> should be ready before the Dublin sprint
[11:33] <mat_t> I think it should go into the "About me" section, as a tick box
[11:33] <didrocks> mat_t: but there can be an "autologin war" between users having sudoer privileges
[11:34] <mat_t> didrocks: good point, how has that been solved up until now?
[11:34] <didrocks> each user ticking the box in its own "About me" dialog in his/her session, without noticing that other user already uses autologin
[11:34] <didrocks> mat_t: as it is in a common dialog now, people see that another account is already using autologin
[11:35] <mat_t> didrocks: IMO if there's more that 1 sudo user that option could just be switched off
[11:35]  * mat_t looks
[11:36] <mat_t> didrocks: not sure which common dialog you have in mind
[11:36] <didrocks> don't know, it was just a tought. Someone can change a value touching other users experience without noticing that there were another user using it.
[11:36] <didrocks> mat_t: gdmsetup
[11:36] <seb128> didrocks, you can disable a "another user is already set, do you want to unset it now"
[11:36] <seb128> disable -> display
[11:36] <didrocks> seb128: good point
[11:37] <pitti> mat_t: also, which user is loggedin automatiacally is a property of gdm, not a property of that user IMHO
[11:37] <seb128> and maybe write a currently <somebody> next to the checkbox
[11:37] <pitti> it's a confusing place to configure it
[11:38] <didrocks> I agree that configuring autologin (and gdm background) which are "global gdm value" in a user property related dialog is less than ideal
[11:38] <pitti> it should be a combobox with all users, plus "disabled"
[11:38] <pitti> and look the same for all users
[11:39] <pitti> this would at least avoid the "multiple autologin" case
[11:39] <pitti> but it still needs policykit, a backend, etc. pp.
[11:39] <pitti> which both makes the about me patch very intrusive, as well as still being a bad place for it
[11:40] <pitti> what's so wrong about configuring that right in the gdm screen itself?
[11:40] <didrocks> pitti: without being logged and using polkit to say "I am acting as xxxx sudoer user to change that"?
[11:41] <pitti> yes, PK does allow that
[11:41] <pitti> of course it needs to be somewhere else as well
[11:41] <pitti> since if you use autologin, you need to be able to reset it
[11:42] <mat_t> I think a "sudo-autologin war" is potentially a source of great confusion
[11:43] <didrocks> yes, being able to reach in gdm itself seems local, appart from this autologin issue (we don't need dbus/gconf stuff?)
[11:43] <didrocks> s/local/logical
[11:44] <mat_t> pitti: didrocks: from the user perspective, in majority of cases there's probably only 1 sudo-user on the machine
[11:44] <mat_t> pitti: didrocks: and that user will expect to be able to set autologin on/off for himself
[11:45] <mat_t> pitti: didrocks: if there's more than 1 sudo user it probably means that we don't know which one is "more sudo" than the other :)
[11:45] <pitti> mat_t: both are equally "sudo"ish
[11:45] <pitti> i. e. both are allowed to change autologin settings
[11:46] <mat_t> yes
[11:46] <mat_t> both or none
[11:46] <didrocks> mat_t: that's for sure. But I really think we don't have to change global gdm value in a user property dialog. Conceptually, there is no sense to do that
[11:46] <mat_t> didrocks: explain
[11:47] <pitti> didrocks +1
[11:47] <didrocks> mat_t: the "About me" dialog is there to enable changing user related value (figure, name, password). autologin and gdm background are system-wide value, related to gdm, not binded to an user
[11:47] <asac> bryce: tjaalton: any hint when xserver 1.7 will hit the archive?
[11:47] <pitti> mat_t: which user gets autologged in gdm is not a property of the "martin" user (or anyone else's)
[11:48] <pitti> it's a property of gdm
[11:48] <mat_t> pitti: but it's a user's choice!
[11:48] <mat_t> pitti: didrocks: it is a user-related value from that perspective
[11:48] <pitti> mat_t: well, everything is an user's choice
[11:49] <pitti> mat_t: if I install a new package, that's my user choice as well
[11:49] <pitti> but it certainly shouldn't be done in "about me"
[11:49] <pitti> "about me" is my name, my ICQ number, password, and whatnot
[11:49] <pitti> but I wouldn't like it to be cluttered with system preferences
[11:49] <mat_t> yes, I agree
[11:50] <mat_t> where else then?
[11:50] <pitti> as I said, bring back the old gdmsetup, and/or allow configuring autologin directly in gdm
[11:50] <pitti> system -> admin -> login manager wasn't a bad place IMHO
[11:50] <pitti> do you think it was?
[11:50] <mat_t> pitti: I'd rather go for directly in gdm
[11:51] <mat_t> I think it was hard to discover and too complex
[11:51] <pitti> mat_t: *nod*
[11:51] <didrocks> I think that pitti's proposal is the most reasonable
[11:51] <mat_t> I agree
[11:51] <mat_t> Just wanted to test if there's anything better
[11:52] <mat_t> :)(
[11:52] <mat_t> OK, so what about the sudo-war
[11:52] <mat_t> how can we solve that?
[11:53] <pitti> we don't?
[11:53] <pitti> if it's not in about me, but in gdm itself, there's no conflict
[11:53] <didrocks> mat_t: if it's a separate dialog only runned as a sudoer, the existing drill, seing another account is already using autologin is enough
[11:53] <didrocks> seeing*
[11:53] <pitti> Log in this user autoamtically: [martin]
[11:53] <pitti> with the combobox offering all users, plus "nobody"
[11:54] <mat_t> hmmm, that sounds super-complex
[11:54] <pitti> how so?
[11:54] <mat_t> I thought about avoiding separate meny whatsoever
[11:54] <pitti> gdm already knows which users exist
[11:55] <mat_t> hold on
[11:55]  * mat_t checks his wireframes
[11:56] <didrocks> (bbl, away for half an hour)
[11:57] <mat_t> ok, so when you select your user in gdm and have a password field ready, there would be a checkbox below with "Log in automatically"
[11:58] <pitti> but that wouldn't work
[11:58] <pitti> you could never have a non-sudoer autologin then
[11:58] <pitti> and it would give the "autologin war" confusion
[11:58] <mat_t> hmmm
[11:59] <pitti> it's the very same problem as with "about me"
[11:59] <pitti> the autologin user simply isn't attached to any particular user, it's attached to gdm
[11:59] <mat_t> technically yes
[12:00] <mat_t> but it is a preference of a particular user
[12:00] <mat_t> "I want to autologin"
[12:00] <mat_t> Am I missing something?
[12:02] <pitti> no, it's not
[12:02] <pitti> it's a system-level setting, to be done by an admin
[12:02] <pitti> a non-admin can't ever configure autologin
[12:02] <mat_t> right
[12:03] <pitti> well, if you find a sensible workflow with just a checkbox, sure, but I don't see how this would work
[12:03] <pitti> we could bring up a Polkit dialog if a non-admin tries to autologin
[12:03] <pitti> and don't show the checkbox if you already set autologin for another user
[12:04] <pitti> but that makes it utterly nondiscoverable how to change it then
[12:04] <mat_t> ok, so my concept was: when you select your user, gdm knows if it's an admin, right?
[12:04] <pitti> yes
[12:04] <pitti> (brb)
[12:04] <mat_t> ok
[12:05] <mat_t> mat_t > lunch
[12:05] <pitti> mat_t: enjoy! (good idea!)
[12:05]  * mat_t will do some more thinking and come back to the problem :)
[12:06] <mat_t> thx!
[12:06] <mat_t> thx!
[12:06] <pitti> seb128_: ok, I give up; I'll upload the current git snapshot with two fixes for keyboard layout and Xsession.d, and file an upstream bug for now
[12:08] <seb128_> pitti, ok thanks
[12:13] <rodrigo_> seb128_: where can I get a LICENSE file for a LGPL lib? (to include in a package to be subvmitted to REVU)
[12:15] <Laney> is there a bug for alt-fX shortcuts not working?
[12:20] <seb128_> rodrigo_, any COPYING in a GPL tarball?
[12:21] <seb128_> rodrigo_, or /usr/share/common-licenses/GPL
[12:21] <rodrigo_> ah, I've been asked to submit with COPYING and LICENSE -> http://revu.ubuntuwire.com/p/couchdb-glib
[12:21] <seb128_> I read too quickly, replace GPL by LGPL there
[12:22] <seb128_> rodrigo_, "or"
[12:22] <rodrigo_> ah
[12:22]  * rodrigo_ misread it :)
[12:22] <seb128_> rodrigo_, ie you need to license text in the tarball
[12:22] <seb128_> rodrigo_, you can name it COPYING, LGPL, LICENSE, whatever you want
[12:24] <rodrigo_> ok
[12:29] <chrisccoulson> pitti - did you figure out your GDM crash?
[12:34] <chrisccoulson> pitti - if you haven't figured it out already, it looks like a xklavier bug. The way that the "fearures" flag type is registered in the new version has changed
[12:35] <chrisccoulson> it's registered with g_enum_register_static in the new version and i think that should be g_flags_register_static
[12:35] <seb128_> it crashes due to a gdm_layout_activate (NULL);
[12:35] <chrisccoulson> ah
[12:35] <seb128_> well that didn't change
[12:35] <seb128_> that's just what triggers the crash
[12:36] <seb128_> chrisccoulson, where is the register thing?
[12:36] <chrisccoulson> "GLib-GObject-CRITICAL: g_param_spec_flags: assertion `G_TYPE_IS_FLAGS (flags_type)' failed " is because of the problem i just mentioned
[12:36] <chrisccoulson> seb128 - it's in the xklavier source "libxklavier/xkl-enum-types.c"
[12:37] <chrisccoulson> the type is registered incorrectly in the new version
[12:37] <seb128_> chrisccoulson, it's weird that the gdm snapshot built using the same libxklavier doesn't break though
[12:37] <chrisccoulson> yeah, that is a bit wiered
[12:37] <chrisccoulson> right, i've got to go for lunch
[12:38] <seb128_> chrisccoulson, thanks for the pointer looking at that now
[12:45] <seb128_> chrisccoulson, indeed http://webcvs.freedesktop.org/xklavier/libxklavier/libxklavier/xkl_engine.h?r1=1.8&r2=1.9 fixes it
[12:45] <seb128_> pitti, ^
[12:45] <seb128_> chrisccoulson, want to backport the patch after lunch since you tracked the issue? I will do it otherwise
[12:46] <seb128_> pitti, I can verify that the change fixes gdm greeter crashing
[12:47] <seb128_> https://bugs.freedesktop.org/show_bug.cgi?id=21578 is the corresponding bug
[12:51] <mat_t> pitti: hey
[13:00] <chrisccoulson> seb128 - i don't mind doing that, but it would have to wait until i finished work. i will do it then if you havent already done it
[13:01] <seb128> chrisccoulson, when do you finish work? ;-)
[13:01] <chrisccoulson> 1630 usually;)
[13:01] <seb128> ok, I think I will backport the change and credit you in the changelog then
[13:01] <seb128> I'm sure you will find other tasks for after work ;-)
[13:02] <chrisccoulson> thanks:)
[13:02] <seb128> chrisccoulson, thank you for the good catch, how did you notice the issue was coming from there btw?
[13:03] <chrisccoulson> i was just looking at the trace that pitti got earlier (http://people.canonical.com/~pitti//tmp/gdm-greeter.log)
[13:03] <chrisccoulson> and saw it was crashing in g_param_spec_flags somewhere
[13:03] <seb128> I'm still a bit puzzle about why the previous version doesn't crash when built on the same libxklavier
[13:06] <chrisccoulson> yeah, i don't understand that either
[13:07] <chrisccoulson> does the previous version call xkl_engine_get_instance anywhere?
[13:10] <seb128> chrisccoulson, yes, they do the same libxklavier use apparently
[13:11] <seb128> chrisccoulson, don't bother, actually fixing the bug will do ;-)
[13:19] <Ampelbein> seb128: hey... I know it's not a high priority, but did you have a chance to look at gnome-nettool? I linked my branch to bug 400016 but as I said I did not get the launchpad integration to work, no menu items are loaded. I did a strace and the launchpad-integration library gets loaded, so it's not a problem with the build-process, I think.
[13:19] <seb128> Ampelbein, no, but I will do that today
[13:20] <Ampelbein> ok, thanks
[13:27] <pitti> chrisccoulson: no, I didn't (was off for lunch)
[13:28] <pitti> chrisccoulson: my next plan was to git pull, build a tarball from that, and build it, to ensure it's not something in upstream's orig.tar.gz
[13:28] <pitti> oh, you guys figured it out? thanks!
[13:29] <chrisccoulson> pitti - yeah, i think so:)
[13:29]  * pitti hugs chrisccoulson and seb128
[13:29]  * seb128 hugs pitti
[13:29] <pitti> see, it does make sense to go to dinner :-)
[13:29] <pitti> I'll close my filed upstream bug then
[13:29]  * chrisccoulson hugs seb128 and pitti
[13:29] <seb128> pitti, already done for the upstream bug
[13:29] <seb128> pitti, you can go for ice cream or something now and maybe your next bug will be fixed when you come back ;-)
[13:30] <pitti> seb128: ah, nice
[13:30] <pitti> heh
[13:30] <pitti> actually, I planned to work on my specs this morning, and then wasted 4.5 hours on gdm :/
[13:30] <pitti> well, "spent", half of it was for the other bugs
[13:31] <chrisccoulson> pitti loves GDM really ;)
[13:31] <pitti> do we track the libxklavier bug somewhere? or should we just upload it?
[13:31] <seb128> pitti, I will upload in a bit
[13:31] <seb128> pitti, I do the libxklavier fix and gdm update and you fix the gvfs missing file while I'm on that? ;-)
[13:32] <pitti> seb128: deal!
[13:32] <seb128> good ;-)
[13:34] <pitti> seb128: so you just need to revert r55 then
[13:35] <seb128> pitti, right, I will do that and add a Conflicts on libxklavier versioned
[13:35] <didrocks> if callable(item):
[13:35] <didrocks> ooooopsss
[13:35] <seb128> pitti, the conflict can be dropped in next upload, it's to avoid race upgrades
[13:35] <pitti> yep, makes sense
[13:44] <mat_t> pitti: the language selector in the gdm doesn't seem essential... what's the current rationale for including it?
[13:44] <pitti> well, selecting your language?
[13:44] <pitti> but you can do that in the desktop, too
[13:44] <pitti> I agree that it's sort of dispensable
[13:44] <seb128> mat_t, different users might use different languages
[13:45] <pitti> session could be hidden in a menu
[13:45] <pitti> well, actually all of keyboard/language/session could be hidden in a menu
[13:45] <mat_t> seb128: would they not have defined them in their desktop session?
[13:45] <pitti> these aren't common options, but they have to be available
[13:45] <mat_t> pitti: exactly my thoughts
[13:45] <seb128> mat_t, where? and that means they would have to log at least once in english to find their way to the option
[13:46] <pitti> I liked the menu in the old gdm actually, but I don't have a strong opinion about it
[13:46] <mat_t> seb128: would they not have their account created with a particular language pre-set?
[13:46] <seb128> pitti, it could, but would that be much better? there is plenty of space on the bottom bar
[13:47] <pitti> could get a little tight on 800 pixels, but I guess we don't care much about that
[13:47] <pitti> it's fine here on 1024
[13:47] <seb128> mat_t, well, they could if somebody was writting the code for that
[13:47] <mat_t> ah
[13:47] <mat_t> :)
[13:47] <seb128> mat_t, an university machine for example would have accounts for all student but the sysadmin would probably not spend days settings locales for each accounts, etc
[13:48] <mat_t> right
[13:49] <mat_t> it's a rare, but valid use case
[13:50] <seb128> what is the issue with that selector?
[13:50] <mat_t> I think it's rare enough for the language option to be hidden in the Options menu
[13:50] <seb128> it doesn't look good?
[13:50] <seb128> there is no options menu
[13:50] <mat_t> seb128: it's quite ugly and it's going to be used extremely rarely
[13:51] <pitti> likewise for the session selector, though
[13:51] <mat_t> There could be - if we go for pittis concept of autologin prefs in gdm
[13:51] <pitti> usually you seelect your session exactly once, or perhaps temporarily use the xterm one
[13:51] <seb128> we should settle on what we envision for that and discuss it with upstream then
[13:51] <mat_t> seb128: I agree
[13:52] <mat_t> seb128: I'm drawing up some wireframes atm
[13:52] <seb128> ok
[13:52] <mat_t> seb128: do we have a wiki page for login experience?
[13:52] <seb128> do you try to get ride of the whole bar or just from the combos boxes?
[13:52] <seb128> mat_t, not that I know
[13:54] <mat_t> seb128: the bar could go, we would only have buttons: {[Accessibility (icon only)] [Login options]                                             [Power (icon only)]}
[13:55] <mat_t> seb128: that would keep it nice and clean
[13:55] <pitti> seb128: hm, installing the metadata daemon and .service doesn't make a differnce, and the daemon doesn't even get started, hmm
[13:55] <seb128> mat_t, well the bar is a countain for the notification area icons too
[13:55] <seb128> pitti, did you restart your session and gvfs then nautilus?
[13:55] <pitti> seb128: I checked with list-missing now
[13:55] <pitti> seb128: yes
[13:55] <seb128> weird
[13:55] <seb128> can you run it by hand?
[13:55] <mat_t> seb128: what icons exactly?
[13:55] <pitti> well, I restarted gvfs and nautilus
[13:55] <seb128> does it crash
[13:55]  * pitti tries restarting session
[13:55] <seb128> ?
[13:55] <pitti> oh
[13:55] <seb128> pitti, it could be autospawned when required
[13:56] <pitti> hah
[13:56] <seb128> pitti, try moving icons on the desktop or something
[13:56] <pitti> $ /usr/lib/gvfs/gvfsd-metadata
[13:56] <pitti> process 18608: arguments to dbus_bus_request_name() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus-bus.c line 1114.
[13:56] <pitti> seb128: good intuition!
[13:56]  * pitti pokes, thanks
[13:56] <seb128> hehe
[13:57] <seb128> mat_t, the battery one for example
[13:57] <SteveA> I know suspend / hibernate is fragile generally... it was working find on this laptop running jauty.  Now, with karmic, suspend and hibernate don't work.  The screen goes dark for a while when I ask it to suspend then a minute or so later I get the "enter password to close the screensaver" screen.
[13:57] <SteveA> should I file a bug?  against what package?
[13:57] <mat_t> seb128: I don't think there's a benefit from having a battery there
[13:58] <seb128> mat_t, well, even those icons you mention, you can't get icons in the middle of nowhere
[13:59] <crevette> does anyone experience this problem http://bugzilla.gnome.org/show_bug.cgi?id=588895 ?
[13:59] <mat_t> seb128: yeah, that's more of a styling issue
[13:59] <seb128> SteveA, not sure, that doesn't seem really desktopish, try #ubuntu-devel maybe
[13:59] <seb128> crevette, libnautilus-ubuntuone.so
[13:59] <seb128> crevette, I closed the bug
[14:00] <mat_t> seb128: right now it's more important to decide what options we'll include
[14:00] <seb128> crevette, wait for an update ubuntuone-client-gnome
[14:00] <seb128> or uninstall it
[14:00] <seb128> mat_t, right
[14:00] <crevette> ah okay thanks
[14:03] <mat_t> seb128: I found this: https://wiki.ubuntu.com/Spec/GDMConfigureTool
[14:03] <mat_t> seb128: looks like Robert Ancell is working on it
[14:03] <seb128> mat_t, right, that's the one for the configuration tool
[14:04] <seb128> mat_t, that's not for the login screen look though, just for how we will configure options and which ones rather
[14:04] <pitti> seb128: hah, missing dbus_error_init, easy
[14:04] <mat_t> seb128: right
[14:04] <mat_t> seb128: so there is no blueprint or spec for it yet
[14:04] <seb128> pitti, ok
[14:04] <mat_t> :]
[14:05] <mpt> mvo_, ok for a call now?
[14:07] <crevette> seb128, whould it be possible to define the GTK also in the GDM configure tool?, should I modify the spec, or see that with robert ?
[14:07] <mat_t> seb128: pitti: is it a good idea to create a blueprint for the login experience on LP? And then link a spec to it?
[14:07] <pitti> sure, a wiki spec is always nice to get an agreement on, point upstraem to, etc.
[14:07] <seb128> mat_t, having a wiki page would be nice, not sure if that require a blueprint too
[14:08] <mvo_> mpt: yes
[14:08] <seb128> crevette, you can add a suggestion at the bottom of the spec
[14:08] <crevette> okay
[14:08] <mat_t> seb128: OK, should I create one under the Desktop team or DX team?
[14:09] <seb128> mat_t, as you prefer, I would say desktop team since I doubt dxteam will work on that soon but I've no strong opinion
[14:09] <mat_t> ok
[14:09] <mat_t> thx
[14:13] <mat_t> seb128: pitti: it'll be here: https://wiki.ubuntu.com/DesktopTeam/Specs/Karmic/LoginExperience
[14:13] <seb128> mat_t, thanks
[14:13] <mat_t> np
[14:20] <geser> pitti: where does the new gdm fetch the keyboard layout from? I got now a german layout ("Germany") but with dead keys (instead of the configured nodead keys variant)
[14:20] <pitti> geser: from hal
[14:20] <pitti> geser: which again gets it from /etc/default/console-setup
[14:21] <geser> pitti: the XKB* values?
[14:21] <pitti> yes
[14:22] <geser> I've there XKBVARIANT="nodeadkeys" but I still got dead keys at login
[14:24] <mpt> mvo_, how can I get the app-install-data counts myself? e.g. find out how many items there are in total, or how many are in the "Games" category
[14:24] <pitti> geser: right, the hal patch just gets layout, not variant :/
[14:25] <geser> I've also XKBOPTIONS="compose:menu" set but did check yet if it's used or not
[14:25] <mvo_> mpt: the total is easy, just count the desktop files in /usr/share/app-install/desktop/ - for the categories its a bit more tricky
[14:25] <mclasen> gdm doesn't do anything for complicated configurations with variants and options
[14:27] <geser> I'd be happy if my gnome desktop used the variants and options I configured
[14:27] <geser> I don't care if they are used during gdm login (I've autologin enabled anyway)
[14:27] <pitti> it always sets GDM_KEYBOARD_LAYOUT again, so gdm would have to know about the variants
[14:28] <pitti> or stop setting GDM_KEYBOARD_LAYOUT if the user didn't change it (probably safer)
[14:29] <mpt> mvo_, "cat /usr/share/app-install/desktop/* | grep Categories | grep Game | wc -l" returns 436. That seem right?
[14:29] <mvo_> mpt: yes
[14:29] <mpt> thanks
[14:30] <mvo_> mpt: in theory it may be more compicated (the applications.menu file in the desktop directory can have includes/excludes for certain categories). but in practise I think this is good enough
[14:30] <pitti> geser: followed up on upstream bug report
[14:38] <seb128> tedg, hey
[14:38] <seb128> tedg, how is the fusa update going?
[14:38] <tedg> seb128: Generally okay, adding features.  I hope to have it mostly working this week.
[14:39] <seb128> good
[14:39] <tedg> seb128: I finally upgraded to Karmic even ;)
[14:56] <pitti> didrocks: hmm
[14:56] <pitti> Searching packages which provide required Python modules:
[14:56] <pitti> launchpadlib.launchpad ... python-launchpadlib
[14:57] <pitti> didrocks: this works for me
[14:58] <didrocks> pitti: hum? strange. I had to add it manually saturday. I will check again tonight.
[15:02] <SteveA> darn... all the icons on my gnome desktop have been rearranged into neat columns
[15:02] <SteveA> on upgrading
[15:03] <seb128> SteveA, welcome to unstable distribution versions, should be fixed when you install the gvfs update pitti just uploaded
[15:04] <SteveA> seb128: cool :-)
[15:05] <hyperair> can someone run /usr/lib/notify-osd/notify-osd in a terminal and see if it complains about not being able to detect a panel?
[15:05] <seb128> hyperair, it complains about another instance running
[15:05] <hyperair> seb128: kill it first.
[15:05] <hyperair> killall notify-osd
[15:05] <hyperair> then run it in a terminal
[15:05] <hyperair> and run notify-send bla
[15:05] <seb128> well notify-osd works fine there
[15:05] <SteveA> my bluetooth keyboard now works on booting, and on turning it on and off, without my needing to reassociate it. FTW.
[15:06] <seb128> didn't you say that was multiscreen specific the other day?
[15:06]  * SteveA wonders which bug that is...
[15:06] <hyperair> seb128: yes it's multiscreen specific, but on both single and multi screens, it doesn't detect thep anel.
[15:06] <hyperair> ** (notify-osd:6860): DEBUG: no panel detetected; using workarea fallback
[15:07] <hyperair> something like this
[15:07] <seb128> works there
[15:07] <hyperair> hmm how strange.
[15:07] <hyperair> compiz?
[15:07] <seb128> yes
[15:07] <hyperair> hmmm how strange.
[15:07] <hyperair> poking notify-osd using gdb led me to nail it down to this:
[15:07] <hyperair> 2107     if (gdk_window_get_type_hint (win)
[15:07] <hyperair> 2108         != GDK_WINDOW_TYPE_HINT_DOCK)
[15:08] <hyperair> for some reason, gdk_window_get_type_hint (win) returns GDK_WINDOW_TYPE_HINT_NORMAL
[15:08] <hyperair> and win is definitely the panel.
[15:09] <crevette> SteveA, there is a lot of bugs complaining about not being able to connect its keyboard after reboot, pick the one you wish :)
[15:10] <hyperair> seb128: what's your gnome-panel version?
[15:10] <seb128> hyperair, in fact it does display the warning when sending a bubble, just not when running notify-osd
[15:10] <seb128> hyperair, but bubbles are correctly displayed
[15:11] <hyperair> ah so it does display the warning then?
[15:11] <seb128> just when displaying a bubble, not when stating
[15:11] <seb128> starting
[15:11] <hyperair> yes yes
[15:11] <hyperair> that's why i wanted you to send a bubble
[15:11] <hyperair> using notify-send
[15:11] <seb128> well I did read the can somebody rung and see if it complains
[15:12] <hyperair> ?
[15:12] <seb128> didn't read the details since I know how to stop and start it ;-)
[15:12] <hyperair> huh?
[15:12] <seb128> well your first question didn't mention "when getting a bubble displayed"
[15:12] <hyperair> oh. right X_x
[15:12] <seb128> "see if it complains about not being able to detect a panel?"
[15:12] <seb128> it doesn't ;-)
[15:12] <SteveA> crevette: there was one I either filed, or commented on a lot.  I'll find it...
[15:12] <hyperair> right right
[15:12] <hyperair> anyway
[15:12] <seb128> but right it does once I get a notification
[15:12] <hyperair> the next line after that says: ** (notify-osd:6860): DEBUG: top corner at: 2295, 23
[15:13] <hyperair> my panel is on the first monitor
[15:13] <hyperair> and my setup is 1280x1024 + 1280x800
[15:13] <seb128> so it displays on the second monotir?
[15:13] <hyperair> for some reason, the bubble isn't displaying, not even in the second monitor
[15:13] <seb128> weird
[15:13] <hyperair> it should, but doesn't.
[15:13] <hyperair> but the main thing is that it should be displaying on the first, where the panel is.
[15:13] <seb128> talk to MacSlow he's the notify-osd upstream hacker
[15:13] <hyperair> okay
[15:14] <hyperair> i kind of think it's more a gnome-panel issue though
[15:14] <seb128> yeah, seems the gnome-panel detection code is buggy
[15:14] <seb128> well, or notify-osd making wrong assumptions
[15:14] <hyperair> no what i meant to say is that.. is gnome-panel setting the type hint correctly?
[15:14] <seb128> vuntz, ^
[15:14] <hyperair> bbl (have to fetch my sister)
[15:15] <seb128> hyperair, it's TYPE_DOCK according to xprop log
[15:18] <pitti> didrocks: I updated https://wiki.ubuntu.com/DidierRoche/distutils-extra.auto ; all medium issues and 2/3 important issues fixed
[15:18] <pitti> (or explained)
[15:19] <pitti> debuild -i commented as well
[15:20] <didrocks> pitti: yes. I've just read them. I know about the .pyc not put in the bin .deb I just believed they were compiled in /usr/share/pyshared/quickly/. I will check for them in /usr/lib/python*/dist-packages/
[15:20] <didrocks> pitti: thanks for your reactivity :)
[15:20] <pitti> didrocks: you're welcome, I know that it blocks you guys
[15:20] <pitti> didrocks: poking at updating debian/control now
[15:21] <didrocks> pitti: I will try debuild -i again, but I still had the issue yesterday.
[15:21]  * didrocks hugs pitti
[15:21] <pitti> oh, hang on
[15:21] <pitti> didrocks: sorry, you need -I.bzr
[15:21] <didrocks> yes, updating debian/control is the major blocker for quickly
[15:21] <pitti> didrocks: -i is just for the diff.gz
[15:21] <pitti> but you are building native packages, I assume
[15:21] <didrocks> oh, ok. it handled differently for diff.gz and orig.tar.gz
[15:22] <didrocks> that explains this :)
[15:22] <pitti> didrocks: -I without arguemtns should ideally include .bzr nowadays
[15:22] <pitti> didrocks: wiki page updated
[15:22] <didrocks> pitti: I agree. But I can still use that as a workaround until it's fixed
[15:23] <didrocks> pitti: thanks a lot :)
[15:28] <pitti> meh, I want devhelp back
[15:29] <pitti> I got addicted to it
[15:29] <pitti> seb128: btw, is the breakage of that because we now use webkit, or because we don't? (and it's a xul breakage)?
[15:29] <didrocks> this is good drug :)
[15:30] <seb128> pitti, dunno I've not looking to that yet, I didn't notice it was broken in fact
[15:30] <pitti> ok, nevermind
[15:31] <seb128> looking -> looked
[15:31]  * pitti is just whining
[15:31] <pitti> Depends: libwebkit-1.0-2
[15:31] <pitti> seems so
[15:33]  * pitti retries build, hopes that it won't ftbfs again and magically fix everything
[15:34] <vuntz> seb128: what is wrong with the panel? :-)
[15:34] <seb128> vuntz,
[15:34] <seb128>  for some reason, gdk_window_get_type_hint (win) returns GDK_WINDOW_TYPE_HINT_NORMAL
[15:34] <seb128>  and win is definitely the panel.
[15:34] <seb128> vuntz, hyperair wrote that before
[15:34] <seb128> but here xprop shows it's a dock so dunno
[15:35] <vuntz> seb128: pretty sure this is working fine, but I could be wrong, of course
[15:39] <hyperair> is there some utility which can detect what type the said window is?
[15:39] <hyperair> like some xwininfo invocation?
[15:40] <seb128> hyperair, xprop
[15:40] <hyperair> ah xprop
[15:41] <hyperair> _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK
[15:41] <hyperair> hmmmm
[15:41] <hyperair> how strange. =\
[15:41] <seb128> hyperair, no, it's normal
[15:41] <seb128> what else would you expect?
[15:41] <mclasen> jcastro: hey, I just stole http://patches.ubuntu.com/libg/libgweather/extracted/01_gettext_not_xml.patch - one for your list of  'forgot to upstream' patches...
[15:42] <hyperair> seb128: a value that's off.
[15:42] <hyperair> i can be hopeful, right? =p
[15:42] <seb128> mclasen, no, vuntz said he was not interested to get this one
[15:42] <mclasen> well, I am
[15:42] <seb128> mclasen, he said that's no win over the current split and that he would not take the patch upstream for GNOME
[15:42] <seb128> mclasen, well you can't say it has not been upstream, maintainer refused the change rather
[15:42] <pitti> didrocks: ... and fixed :)
[15:44] <didrocks> pitti: thank you so much :) I will give a try to all of those fixes tonight (do you want to bump the revision number?)
[15:44] <hyperair> seb128: is there any reason why gdk_window_get_type_hint returns GDK_WINDOW_TYPE_HINT_NORMAL rather than GDK_WINDOW_TYPE_HINT_DOCK for that window?
[15:44] <mclasen> seb128: vuntz said to me "patch was never sent upstream iirc"
[15:45] <pitti> didrocks: uploaded 2.7 to sid/karmic, and 2.7~jaunty to PPA
[15:45] <pitti> didrocks: and wiki page updated; so could you try 2.7, and delete the stuff that's fixed now after confirming?
[15:46] <didrocks> pitti: perfect... and yes, I will do that :)
[15:46] <pitti> yay
[15:46] <seb128> mclasen, no, I asked vuntz on IRC if he would be interested by the change and he said that he was not, that he preferred to split the .xml by locale and that it was not worth sending the patch to bugzilla since he didn't intend to do a such change
[15:46] <seb128> vuntz, ^
[15:51] <seb128> bratsche, hey, gtk 2.17. =5 directfb still doesn't build, lack _gdk_window_impl_new, could you have a look?
[15:52] <jcastro> seb128, we should make sure vuntz answers on mailing lists instead of on irc so we can document his forgetfullness.
[15:52] <jcastro> vuntz, just kidding.
[15:52] <seb128> jcastro, ;-)
[15:52] <mat_t> pitti: do you know what happens when there's many user accounts on one machine? How long can the list get?
[15:53] <mat_t> pitti: does it scroll?
[15:55] <vuntz> mclasen: I think the point was "opening a small xml file + a mo file" vs "opening a small & compressed xml file" (trying to remember when this was discussed)
[15:55] <bratsche> seb128: Yeah, I missed that in my last commit for lack of time and then didn't get a chance to do it this weekend.  I'll take a look at it.
[15:55] <seb128> bratsche, thanks
[15:55] <mclasen> vuntz: the mo file is a win as soon as you have two users of the data
[15:56] <mclasen> even if you discount the space savings due to reduce xml clutter
[15:56] <vuntz> mclasen: how is it a win?
[15:56] <mclasen> because it gets mmapped and shared
[15:56] <mclasen> rather than parsed and stored in private memory for each users
[15:56] <vuntz> mclasen: but both users still have to open the xml file. So it's still more
[15:57] <vuntz> mclasen: (C xml file)
[15:57] <vuntz> mclasen: you have parse + gettext vs parse
[16:01] <mclasen> the untranslated xml ought to be noticeably smaller than the translated one; I wonder why it isn't
[16:04] <vuntz> mclasen: why would it be smaller?
[16:04] <mclasen> because the translations take up space
[16:05] <vuntz> mclasen: but they replace the C strings
[16:05] <mclasen> no
[16:11] <vuntz> mclasen: sure about that?
[16:11] <mclasen> well, it replaces the <name> element, but you gain an id attribute with the C string, no ?
[16:12] <mclasen> plus you have a bazillion xml:lang="foo"
[16:12] <vuntz> mclasen: no
[16:12] <vuntz> mclasen: I for sure can't find "Venice" in the fr xml file. It's Venise there
[16:13] <mclasen> yeah, I was wrong about the id
[16:14] <mclasen> vuntz: I guess it comes down to: you are happy with the split xml solution because you have langpacks...I don't
[16:18] <mat_t> pitti: ping
[16:18] <hyperair> eureka! it works! (using wnck to get the window type instead of gdk)
[16:20] <seb128> hyperair, I doubt they will make notify-osd depends on wnck though
[16:20] <hyperair> seb128: it already does.
[16:20] <hyperair> seb128: all i did was add one include (libwnck/window.h)
[16:20] <hyperair> there were other libwnck includes already
[16:20] <hyperair> in the same file
[16:20] <seb128> oh ok
[16:20] <seb128> weird
[16:21] <seb128> and do you know why the gdk call doesn't work?
[16:21] <hyperair> i have no idea.
[16:21] <seb128> could be a gtk bug then
[16:22] <hyperair> i'm thinking either a bug in gdk, or that gdk_window_get_whatever_it_was_i_was_using doesn't fully document what it's not supposed to do.
[16:22] <hyperair> are all gdk_window_whatever functions supposed to work with windows that don't belong to the app?
[16:23] <pitti> mat_t: it just shows the most popular users (in terms of how often they logged in)
[16:24] <seb128> hyperair, works when ldpreloading gdk 2.16
[16:24] <pitti> mat_t: I didn't try how long the list can get, I hope that it stops at 5 or so
[16:24] <seb128> hyperair, not sure, especially in the client side gdk world
[16:24] <hyperair> seb128: wait, you mean it detects your screen when you ldpreload gdk 2.16?
[16:24] <hyperair> i mean panel
[16:24] <pitti> mat_t: BTW, I'm happy if you want that ripped out, and replaced by two input lines (user/pwd)
[16:25] <seb128> hyperair, yes
[16:25] <hyperair> i see.
[16:25] <hyperair> hmm
[16:25] <seb128> hyperair, I got the jaunty deb, dpkg-deb -x it and LD_PRELOAD
[16:25] <hyperair> how strange, eh.
[16:25] <hyperair> oh
[16:25] <hyperair> jaunty deb eh.
[16:25] <seb128> well, 2.16
[16:25] <hyperair> that means it's a regression in gtk
[16:25] <seb128> karmic is 2.17
[16:25] <hyperair> yes yes
[16:25] <seb128> or a wrong assumption of what you can do from notify-osd which used to work by luck
[16:26] <hyperair> hmm
[16:30] <mat_t> pitti: I've just added 10 users and the list just scrolls endlessly
[16:30] <mat_t> pitti: I think we should keep the user picker, but replace it with user/pwd if there's more than 6 users
[16:31] <mat_t> pitti: also, user/pwd should be default if there's a network
[16:31] <mat_t> setup
[16:32] <seb128> mat_t, why not displaying the n most frequent users and the other entry?
[16:33] <mat_t> seb128: I don't like the list being dynamic depending on whether someone logged in more often
[16:34] <mat_t> seb128: imagine that situation in the family, when mum suddenly can't log in
[16:34] <mat_t> and she's baffled
[16:34] <mat_t> :)
[16:34] <seb128> mat_t, it means that if you have 15 accounts and only 3 people using the machine you prefer to not list those just because the system has unused accounts?
[16:34] <mat_t> yes, I think that's better than unpredictable behaviour
[16:35] <seb128> well, sorting by commonly used is not unpredictable
[16:35] <mat_t> "Where's my user gone?!" "I don't know mum..."
[16:35] <mat_t> it is
[16:35] <seb128> well, make an account for somebody and next login your user list has vanished for no obvious reason
[16:36] <seb128> want to bet we will get bugs about that too? ;-)
[16:36] <mat_t> :)
[16:37] <mat_t> it's a tricky one
[16:38] <mat_t> but in 99% of the cases when there is +6 users on one computer it is not a normal "family" setup
[16:39] <mat_t> seb128: but you are right, it is a potentially disruptive situation
[16:50] <hyperair> seb128: poking libgtk with gdb revealed that the said function earlier stops at this point:
[16:50] <hyperair> 2028   if (GDK_WINDOW_DESTROYED (window) ||
[16:50] <hyperair> 2029       !WINDOW_IS_TOPLEVEL (window))
[16:50] <hyperair> 2030     return GDK_WINDOW_TYPE_HINT_NORMAL;
[17:07] <hyperair> seb128: i know why the notifications don't appear for me now!
[17:07] <hyperair> seb128: the coordinates specified earlier aren't displayed due to my secondary monitor being shorter, and their bases aligned
[17:36] <mat_t> pitti: seb128: Ok, I've changed my mind. I've just imagined a class with 20 kids somewhere in Africa, where every child has his own avatar... having a usr/pwd just because it's more than 6 of them seems inhumane
[17:36] <mat_t> :)
[17:37] <seb128> lol
[17:38] <mat_t> So I think the list can adapt to display most often logged users, but should always display all users
[17:41] <seb128> mat_t, ok, having a scrollbar then?
[17:41] <mat_t> yeah
[17:41] <tedg> seb128: Are we supporting people using the old GDM?
[17:41] <tedg> (on Karmic)
[17:41] <seb128> tedg, no, there is no old gdm, they are not different packages
[17:41] <seb128> t's a new version of the same gdm software
[17:41] <seb128> it's
[17:42] <tedg> seb128: Okay.  Cool.
[17:43]  * seb128 does a break bbl
[17:45] <mat_t> seb128: could we populate random avatars for newly created users from the usr/share/pixmaps/faces ?
[17:45] <mpt> A computer screen could easily show 20 icons, it's just the 1-D scrolling layout that doesn't
[17:45] <mat_t> mpt: true
[17:47] <pitti> mat_t: ok; personally I'd value an easier method to access "other", without having to use the mouse
[17:48] <mat_t> pitti: you can filter with keyboard, can't you?
[17:48] <pitti> hm, I don't know
[17:48] <mat_t> you can :)
[17:49]  * mat_t just tried that
[17:51] <mat_t> pitti: could we populate random avatars for newly created users from the usr/share/pixmaps/faces ?
[17:52] <pitti> mat_t: I guess we can
[17:52] <mat_t> cool, that would bring this thing to life
[17:59] <pitti> hm, apparently I lost gnoem-keyring ssh agent with one of the recent updates
[18:02] <pitti> dobey: could you please add Vcs-Bzr: https://code.launchpad.net/~ubuntuone-control-tower/ubuntu/karmic/ubuntuone-storage-protocol/karmic to debian/control? (likewise for ubuntuone-client)? It needs to go into the first record (for the source package)
[18:03] <pitti> dobey: this will point out that the package is managed in bzr, and enable tools like debcheckout to work
[18:03] <Ampelbein> pitti: regarding gnome-keyring, does echo $SSH_AUTH_SOCK give an empty reply?
[18:04] <pitti> no
[18:04] <Ampelbein> pitti: and it points to /tmp/keyring-bla/socket.ssh
[18:04] <Ampelbein> ?
[18:04] <pitti> srwxr-xr-x 1 martin martin 0 2009-07-20 15:33 /tmp/keyring-tYQTmS/socket.ssh
[18:04] <pitti> it exists, but the variable doesn't exist
[18:05] <pitti> hah, indeed SSH_AUTH_SOCK=/tmp/keyring-tYQTmS/socket.ssh ssh .. works
[18:07] <Ampelbein> pitti: I don't know where that get's sourced. for the seahorse-agent (gpg stuff) it's in /etc/X11/Xsession.d
[18:07] <pitti> right, and that works again with latest gdm
[18:09] <mac__v> pitti: silly ques , when can we expect FUSA back ?
[18:09] <pitti> tedg said he's working on it, in a week or so
[18:09] <mac__v> \o/
[18:09] <mpt> mat_t, ^^
[18:10] <mac__v> mpt: why do you insist in keeping the name rather than the icon for FUSA? just trying to get your perspective
[18:12] <mpt> mac__v, do you mean for the menu title?
[18:13] <mpt> or for each item?
[18:13] <mpt> mac__v, either way, I'm not "insisting" on anything, I haven't had time to do any design work on Fusa
[18:13] <mac__v> bug 400383
[18:13] <mac__v> mpt^
[18:15] <mpt> mac__v, that's about the gap before the title, it's not about whether the title should include an icon.
[18:16] <mac__v> mpt: oh ... ok, seperator surely looks odd , but removing the separator makes the date flow into the name, seemed awkward , either a smaller separator or if the separator was to be removed we could use just the icon instead
[18:17] <mac__v> btw the david's screenshot is *not* FUSA
[18:17] <mpt> mac__v, then maybe the gap's too narrow.
[18:18] <mat_t> mac__v, try spreading the two menus on your panel a bit and remove the separator - works just fine
[18:18] <djsiegel> rickspencer3_: http://davidsiegel.org/100papercuts-round-3-progress-report/ (fyi)
[18:19] <mac__v> mpt: yeah, you are right, just have a look in the end, when FUSA is done. it doesnt seem nice without the separator and no space atm
[18:19] <mac__v> mat_t: you are right about adding the space
[18:21] <mac__v> mpt: djsiegel: bug 400047 , another simple one for papercuts
[18:21]  * djsiegel looks
[18:21] <djsiegel> mac__v: ah, not really a paper cut
[18:21] <mac__v> djsiegel: when the install icon in Live CD is discussed , why not this?
[18:22] <mac__v> label  that is
[18:22] <djsiegel> it's more trivial
[18:23] <djsiegel> the install icon is so much simpler to improve
[18:23] <djsiegel> also, it appears in your normal boot environment
[18:23] <mac__v> djsiegel: this is also just rewording
[18:23] <djsiegel> when you upgrade
[18:23] <djsiegel> mac__v: is there a mockup?
[18:23] <mac__v> ok
[18:23] <djsiegel> ask the OP to do one
[18:24] <djsiegel> "partitioner is unclear" make the bug seem non-trivial :)
[18:25] <mac__v> djsiegel: not sure what mockup , could you just add the comment
[18:25] <mac__v> the first option is just poorly worded
[18:27] <mat_t> bratsche: hi
[18:27] <bratsche> Hi mat_t
[18:28] <mat_t> bratsche: any news from the world of morphing? Just thought the new gdm would find a perfect use for it...
[18:29] <bratsche> mat_t: I actually am finally starting on this.  But I'm limiting the scope of it to the message dialogs that are in the notify wiki page that mpt made, and once this is done I figured we could make it more generic.
[18:29] <mat_t> cool
[18:29] <bratsche> https://wiki.ubuntu.com/NotificationDesignGuidelines#Morphing%20alert%20box
[18:30] <bratsche> I'm starting with just what's on this page.
[18:30] <mat_t> but the generic stuff is post-Karmic, right?
[18:30] <bratsche> mat_t: Probably, but maybe doable sooner.
[18:30] <mac__v> djsiegel: http://2.bp.blogspot.com/_W1ueYt1O3xs/SdX6SkcEabI/AAAAAAAAQNc/RD4b7Ivsbqo/s400/dual+boot+windows+7+and+ubuntu-4+764x670.jpg the shot of the installer
[18:31] <mat_t> bratsche: what do you think about the user list in the new gdm?
[18:31] <bratsche> mat_t: Do you know kind of what you want to do with it in gdm?
[18:32] <bratsche> mat_t: Do you have a link for it?
[18:32] <mat_t> bratsche: yeah, morph from user list to usr/pwd
[18:32] <mat_t> bratsche: it's just a simple scrollable list
[18:33] <bratsche> mat_t: So that's kind of like the stuff in the videos you and Mark were showing in UDS right?
[18:33] <mat_t> much like https://wiki.ubuntu.com/NotificationDesignGuidelines?action=AttachFile&do=get&target=morphing-window.png
[18:33] <bratsche> Oh right.
[18:33] <djsiegel> bratsche: mpt and I discussed a pretty sweet paper cut you might be interested in: don't show accelerator underlines unless Alt is pressed
[18:33] <mat_t> bratsche: not sure which videos you're referring to
[18:34] <bratsche> mat_t: I'm not sure about this one yet.. the treeview stuff might be tricky, and I need to think about how it should work.
[18:35] <bratsche> djsiegel: Hmm.. that sounds kind of nice.
[18:35] <mat_t> bratsche: treeview?
[18:36] <bratsche> mat_t: Yeah, in this screenshot you linked.. it's Firefox, but the gtk equivalent is GtkTreeView.
[18:36] <dobey> pitti: sure. will do
[18:37] <pitti> dobey: thanks
[18:37] <pitti> dobey: both uploaded, btw
[18:37] <bratsche> mat_t: I think I should get the new message dialog stuff done fairly quickly, and I'll try to figure out how to do this one next.
[18:37] <dobey> pitti: great, thanks
[18:38] <seb128> does the new ubuntuone-client fixes the zillion nautilus crashes?
[18:39] <seb128> (if that's the case you could have mentioned it in the changelog)
[18:39] <bratsche> djsiegel: I think that would be a fun one to hack on.  But I think we'll need you guys to come up with a good explanation of why it's a good idea in order to convince gtk+ maintainers.
[18:39] <seb128> dobey, pitti: ^
[18:39] <djsiegel> bratsche: ok
[18:39] <pitti> seb128: I played around with it a little, no immediate crashes
[18:39] <dobey> seb128: yes
[18:40] <bratsche> djsiegel: But I think I could hack on that and talk to mclasen about getting it in sometime.
[18:40] <djsiegel> bratsche: awesome
[18:40] <djsiegel> bratsche: any news with the dim-on-cut work?
[18:40] <djsiegel> (sorry to inundate you)
[18:41] <bratsche> djsiegel: I have most of the patch updated against Nautilus master sitting on my laptop.. I need to finish that up and test it.
[18:43] <mac__v> mpt: now i'm not sure if the wording really needs a change ! anyway screenshot> http://launchpadlibrarian.net/29292485/Ubiquity.png
[18:43] <mac__v> changed^
[18:43] <bratsche> djsiegel: I'll try to get it in a better state tonight.  If you guys are serious about the gtk+ thing, I think that should be higher priority because that's something we probably can't ship a patch against.  So we would need to get it into gtk master sooner rather than later, otherwise put it off until Karmic+1
[18:43] <pitti> Taekwondo time, cu tomorrow!
[18:43] <djsiegel> bratsche: ok, I will write an argument today, file a launchpad bug, and ping you
[18:43] <bratsche> djsiegel: The dim-cut-files thing could probably be shipped as a patch if we can't get it into Nautilus on time.
[18:44] <bratsche> djsiegel: Cool, sounds good.
[18:44] <djsiegel> but now I have to file round-4 papercuts upstream and get the wheel turning...
[18:54] <mat_t> seb128: pitti: https://wiki.ubuntu.com/DesktopTeam/Specs/Karmic/LoginExperience#Standard%20login%20screen%20with%20user%20picker
[18:55] <seb128> mat_t, looks good, thanks for working on that!
[18:56] <mat_t> seb128: np!
[18:56] <mat_t> seb128: we'll discuss tomorrow
[18:56] <mat_t> seb128: have a good evening
[18:56] <seb128> mat_t, thanks, you too
[18:58] <mat_t> rickspencer3_: https://wiki.ubuntu.com/DesktopTeam/Specs/Karmic/LoginExperience fyi, kicked this off today
[18:59] <rickspencer3_> mat_t: great!
[18:59] <rickspencer3_> thanks so much
[18:59] <mat_t> np, pleasure!
[18:59]  * mat_t > home
[19:00] <seb128> lool, any clue about bug #401787?
[19:00] <seb128> lool, not sure what gstreamer-install-codec is but the user says it comes with unr
[19:03] <crevette> does someone experienced http://bugzilla.gnome.org/show_bug.cgi?id=588933?
[19:05] <lool> seb128: update-alternatives --display gstreamer-codec-install
[19:05] <seb128> lool, thanks ;-)
[19:05] <lool> np
[19:06] <seb128> crevette, another duplicate of yours yes
[19:06] <crevette> ah didn't find in lp
[19:07] <crevette> ah I didn't look in gtk+
[19:08] <seb128> crevette, look to the recently open gtk+ on bugzilla.gnome.org
[19:08] <seb128> crevette, it's a csw issue, I've opened it there
[19:08] <crevette> yeah, I'm looking to dup it
[19:08] <crevette> thx a lot
[21:03] <seb128> bratsche, there?
[21:03] <bratsche> seb128: Hey, yeah.
[21:04] <seb128> bratsche, hello
[21:04] <seb128> bratsche, gtk question for you
[21:04]  * bratsche hides :)
[21:04] <seb128> we have a gtk application using gtkbuilder which does that
[21:04] <seb128> 	builder = gtk_builder_new ();
[21:04] <seb128> 	ui = GTK_UI_MANAGER (gtk_builder_get_object (builder, "uimanager1"));
[21:04] <seb128> 	launchpad_integration_add_ui (ui, "/ui/menubar1/help1/LaunchpadItems");
[21:05] <seb128> 	g_object_unref (G_OBJECT (builder));
[21:05] <seb128> 	gtk_main ();
[21:05] <seb128> basically
[21:05] <seb128> is the g_object_unref correct there?
[21:06] <seb128> bratsche, the launchpad function is basically a wrapper around gtk_ui_manager_add_ui()
[21:06] <bratsche> seb128: I'm not sure.. but seems like it's probably fine.
[21:06] <seb128> bratsche, the menu items are not displayed but they are displayed if the g_object_unref call is commented
[21:06] <seb128> which sort of puzzle me now ;-)
[21:07] <seb128> so I'm trying to figure what's going on
[21:07] <bratsche> Oh, well then I guess I'm wrong. :)   I actually have not used gtkbuilder for anything yet personally, so I'd just go with what works.
[21:07] <seb128> well I'm wondering what's going on
[21:07] <bratsche> It does seem kind of unintuitive.
[21:07] <seb128> gtk_builder_get_object() doesn't increment the ref count
[21:08]  * bratsche takes a peek in the code
[21:08] <seb128> but I would expect I can free the object after the gtk_ui_manager_add_ui() call
[21:08] <seb128> bratsche, if you don't know don't bother, I figured you might have a clue, thanks anyway
[21:09] <bratsche> seb128: Oh okay.. interesting.  So if you look at gtk_builder_get_object() it's doing: return g_hash_table_lookup (builder->priv->objects, name);
[21:10] <bratsche> seb128: Try refing the UIManager after you get it, before you unref the builder.
[21:10] <bratsche> Just a thought.
[21:11] <bratsche> seb128: gtk_builder_get_object () docs say it doesn't ref the returned object.. and then the next thing you're doing is unrefing the builder, so that probably unrefs your UIManager.
[21:11] <seb128> bratsche, that works, which is somewhat what I guessed but I don't understand why
[21:11] <seb128> bratsche, right, <seb128> gtk_builder_get_object() doesn't increment the ref count
[21:12] <bratsche> Yeah.. when you said that it hadn't yet occurred to me that when you're unreffing the builder that it's probably unrefing the UIManager.
[21:12] <seb128> bratsche, but the uimanager is on screen as part of the gtkbuilder ui, should it be still refed somewhat?
[21:12] <bratsche> Since the UIManager is contained in the builder.
[21:12] <seb128> or those a different memory spaces?
[21:12] <seb128> a -> are
[21:13] <seb128> I mean the program is running, the UI is on screen as are the menus
[21:13] <seb128> so the object are referenced somehow
[21:13] <bratsche> What does launchpad_integration_add_ui() do?
[21:13] <seb128> but not in this sourcefile
[21:13] <seb128> bratsche, gtk_ui_manager_add_ui() basically
[21:13] <seb128>     gtk_ui_manager_insert_action_group (ui, action_group, -1);
[21:13] <seb128> 	gtk_ui_manager_add_ui (ui,
[21:13] <seb128> ...
[21:14] <seb128> I guess I will just refcount it and not try to understand
[21:14] <seb128> I though that would add the items to the existing object
[21:14] <seb128> and that we would not need to keep the reference in the source but that might not be the case
[21:15] <bratsche> I'd have to dig into it further.. but my guess is that UIManager is being unref'd before the menus get merged in somehow.
[21:15] <bratsche> seb128: Oh oh oh..
[21:16] <seb128> bratsche, that would explain it, is there a way to force the uimanager update or something?
[21:16] <bratsche> seb128: Probably because when you unref the builder, it unrefs the UIManager immediately.  But when you gtk_ui_manager_add_ui() some of the fu in there may not happen until the next GMainContext iteration.
[21:16] <seb128> not that I care referencing the uimanager once, I'm rather curious there
[21:17] <bratsche> seb128: s/Probably/Possibly anyway :)
[21:18] <seb128> bratsche, that's it! thanks!
[21:18] <seb128> bratsche, adding while (gtk_events_pending ()) gtk_main_iteration (); before the unref makes it work
[21:18] <seb128> bratsche, any other better way to do that? ;-)
[21:19] <bratsche> I've thought of this idea before that g_object_unref() should not immediately free the object if it hits 0, until the next context iteration.
[21:19] <bratsche> seb128: Yeah, maybe putting it in an idle callback?
[21:19] <seb128> what, the unref?
[21:20] <seb128> I think I will just go with the "g_object_ref (ui);"
[21:20] <seb128> as said I doubt referencing ui once in the program run will make any difference
[21:20] <bratsche> k
[21:20] <seb128> and that's by far the easiest way suggested there ;-)
[21:20] <seb128> bratsche, but thanks for the explanation, now it makes sense
[21:20] <seb128> I didn't though that the unref could act before the menu merging
[21:21] <seb128> Ampelbein, ^ the issue with your update explained
[21:21] <seb128> ups wrong focus
[21:21] <bratsche> heh
[21:22] <Ampelbein> seb128, bratsche: thanks, will read it
[21:23] <seb128> Ampelbein, I'm doing the tweak and upload
[21:28] <chrisccoulson> seb128 / bratsche - that's interesting. i was also quite confused by Ampelbein's issue too
[21:29] <bratsche> Yeah, I've run into similar issues a few times in the past.  This is why I wish the actual memory freeing happened on the next context iteration.
[21:29] <bratsche> But I'm afraid of trying to propose a change like that because it seems like something that may potentially cause problems.  I don't know, I should ask other gtk people what they think.
[21:30] <bratsche> It seems like it should work correctly.
[21:30] <seb128_> bratsche, sorry got disconnected and probably missed what you wrote just before, but yeah behaviour changes are always tricky
[21:30] <seb128_> though in this case it should just make work things which are sort of racy now
 Yeah, I've run into similar issues a few times in the past.  This is why I wish the actual memory freeing happened on the next context iteration.
[21:31] <seb128_> that would be nice indeed
[21:31] <seb128_> chrisccoulson, yes
[21:32] <seb128_> chrisccoulson, "yeah" I mean ;-)
[21:32] <chrisccoulson> heh ;)
[21:32] <seb128_> or "hey"
[21:32] <seb128_> doh, I'm sleepy already!
[21:32] <Ampelbein> at least i'm glad it was not a "ohh, how could he not see that" issue ;-)
[21:32] <seb128_> Ampelbein, ;-)
[21:32] <chrisccoulson> seb128 - yeah, i'm quite sleepy too
[21:32] <chrisccoulson> and i'm up at 430am tomorrow:(
[21:32] <bratsche> Yeah, you're up pretty late.
[21:32] <bratsche> eek
[21:32] <seb128_> chrisccoulson, will you fix the g-s-d .install tonight?
[21:33] <chrisccoulson> seb128 - yeah, just doing that now
[21:33] <seb128_> chrisccoulson, urg, you should go to bed now
[21:33] <chrisccoulson> then i should probably go to bed
[21:33]  * chrisccoulson hates early mornings
[21:33] <seb128_> chrisccoulson, I was going to say that you can include your disk space change too if you want
[21:33] <bratsche> After getting back from GC, I'm trying to get in the habit of being up a bit earlier since most people on my team are in Europe.
[21:33] <seb128_> chrisccoulson, but you probably want to sleep rather ;-) and next tarball are due in a week
[21:33] <bratsche> So I've been pretty good about getting up around 7-7:30am now.
[21:33] <chrisccoulson> seb128 - yeah, i don't mind. it's been committed to git now
[21:33] <chrisccoulson> it wouldn't take long to include it now
[21:34] <seb128_> bratsche, 7am is really the basis line for me, before that it's way too early
[21:34] <seb128_> I like waking up between 8am and 9am
[21:34] <seb128_> and start working around 9-9:30
[21:34] <chrisccoulson> those are my sort of hours too ;)
[21:35] <seb128_> but I'm lucky to be in Europe where most of my team is ;-)
[21:35] <chrisccoulson> but the people i'm working with tomorrow are all early starters
[21:35] <chrisccoulson> i shall finish at 2pm on-the-dot though when they stop paying me
[21:35] <bratsche> seb128_: Well, in school I got into the habit of studying and practicing very late.. and I'd usually get to sleep around 4:30-5:00am.  And my last job was 9 hours behind me, so I was still on this "get up at 11am" schedule and it was just fine with them. :)
[21:35] <seb128_> chrisccoulson, you work with people in other countries or just start really early?
[21:36] <bratsche> Of course, I also worked until 8pm or later there. :)
[21:36] <seb128_> hehe, I know this school schedule ;-)
[21:36] <chrisccoulson> seb128 - i'm working away tomorrow, and the people i'm working with start much earlier than me
[21:36] <seb128_> I was doing 3am to 11am at school too
[21:36] <seb128_> chrisccoulson, oh ok, good luck then!
[21:36] <seb128_> I will not make you stay away from your upgrade and sleep then ;-)
[21:37] <bratsche> I went to music school, and it was hard to find space to practice in during the day.. but it was easier to find practice rooms at midnight and later. :)
[21:37] <chrisccoulson> i've set the timer on the coffee machine, so i will have fresh coffee as soon as i roll out of bed;)
[21:37] <seb128_> chrisccoulson, if you can drink it that's good ;-) my stomach is not happy to digest anything before 6am usually
[21:37] <seb128_> ie when I have to wake up early I just go and get coffee later
[21:38] <chrisccoulson> me neither, but i can usually manage some coffee. i just cant eat any food at that time
[21:38]  * bratsche doesn't drink coffee at all so this is one less thing to worry about in the morning :)
[21:38] <chrisccoulson> i couldn't survive without it ;)
[21:39] <bratsche> I'm unfortunately addicted to diet soda now in the afternoons.  I'd like to quit that stuff.
[21:39] <chrisccoulson> yeah, i tend to stay away from carbonated drinks
[21:40] <bratsche> I'm sure it's very unhealthy, although I don't know exactly how.  Maybe if I knew then I'd have an easier time quitting though.
[21:40] <seb128_> better diet soda than soda though ;-)
[21:40] <chrisccoulson> yeah, less sugar
[21:40] <seb128_> I don't like the fake sugar taste
[21:41] <bratsche> I kind of got used to it, and now I don't like the non-diet soda.  Which is kind of weird.
[21:41] <chrisccoulson> i'm not a big fan of sugar or sweet things anyway
[22:27] <dobey> bratsche: i guess you'll know when you get cancer or diabetes :)
[22:28] <bratsche> dobey, Yeah. :(
[22:28] <bratsche> dobey, I should have stayed in Baltimore where I have a higher probability of dying quickly by a violent crime.
[22:30] <bratsche> Although here I have a higher chance of dying quickly in a horrible car crash.  Hmm.. hard to measure which is better.
[22:32] <dobey> in dallas? it's the book depositories you really have to watch out for
[22:36] <bratsche> dobey, Oh yeah.. good point.
[22:38] <lool> seb128: nautilus recommends ncb/brasero which we don't want in UNR; is it ok if I downgrade that to suggests?  desktop seed pulls brasero
[22:39] <seb128> lool, hum
[22:39] <lool> Yeah that's what I was thinking as well  :)
[22:39] <seb128> it's sort of wrong
[22:39] <seb128> but I've no better suggestion
[22:39] <lool> I feel the same
[22:39] <seb128> go for it if that's really an issue for unr
[22:40] <seb128> the other way would be to add "| unr" to the recommends but I don't like that either
[22:40] <lool> First I need to hit Robert for pushing to the bzr branch   :-P
[22:40] <seb128> ;-)
[22:42] <seb128> jcastro, I don't like much this install things on one click for random emails
[22:43] <seb128> jcastro, it really makes easy to trick users in installing a trojan or something
[22:44] <jcastro> seb128, ok fair enough.
[22:46] <seb128> jcastro, I'm not a security guy and I don't like it in webbrowsers either but it didn't stop other people doing that
[22:46] <seb128> jcastro, so basically I will not stay in the way of asac if he wants to do the change but I will not to do
[22:46] <jcastro> ok
[22:47] <jcastro> I am not too passionate about it one way or another
[22:47] <lool> seb128: Would it make sense to hide brasero if you don't have a burner
[22:48] <seb128> lool, not sure, you can use it to build cd images for example
[22:49] <lool> seb128: I think we don't mind having the files and plugins in the UNR image, but the icon in the UNR menus kind of reminds users they don't have a CD drive and is mostly useless on netbooks without a CD burner
[22:49] <lool> So it might turn out useful and we could show it by default for people with burners but we wouldn't that on netbooks without a cd drive
[22:50] <seb128> lool, we don't have way to dynamic list menu entries right now though
[22:50] <lool> Ok; let's forget about that
[22:52]  * lool defers that whole thing
[22:52] <seb128> lool, we could have a NotShowIn=UNR though if you need that
[22:53] <seb128> lool, and you could teach UNR to respect the NotShowIn
[22:57] <lool> Hmm that would probably work
[22:57] <lool> seb128: I'll defer to StevenK who's leading the UNR integration
[22:57] <seb128> lool, ok
[22:58] <seb128> lool, otherwise feel free to lower the recommends to a suggests for now
[23:02] <lool> seb128: Nah I know you'll get me in 5 years asking why we had lowered that recommends to a suggests and I wont have any log of this   ;-P
[23:02] <seb128> lool, lol
[23:03] <seb128> so I can't use that trick twice against you ;-)
[23:08] <vuntz> pitti: ping?
[23:08] <seb128> vuntz, he just went to bed I think
[23:09] <seb128> vuntz, better to let your question there
[23:09] <vuntz> seb128: ah, lazy him ;-)
[23:09] <vuntz> just wondering about the gdm guest session stuff
[23:09] <vuntz> pitti: just wondering about the gdm guest session stuff, if you have some time to discuss this tomorrow...
[23:10] <seb128> vuntz, you can look to gdm-guest-session in jaunty
[23:10] <vuntz> seb128: yeah, I'm looking at it :-)
[23:10] <seb128> vuntz, the scripts should be pretty easy to understand, it's basically adding an user, login in using it and clean after logout
[23:13] <lool> seb128: I wonder whether it would help to move the libgdk-pixbuf definition before the pixbuf loaders in Makefile.am, otherwise no idea about the gtk+ build bug, it's ugly
[23:13] <seb128> lool, I was going to upload a non change update to see how it goes
[23:14] <seb128> lool, the makefiles didn't change between versions that somewhat puzzle me
[23:14] <lool> seb128: libtool changed in april, that seems far away
[23:15] <seb128> lool, indeed
[23:15] <lool> seb128: Otherwise perhaps all the loaders need proper _DEPENDENCIES on the lib
[23:15]  * lool has no idea and would need to try it out
[23:15]  * lool bed &
[23:15] <seb128> lool, thanks for the suggestions, I will try the non change upload and go to bed too
[23:18] <asac> seb128: what did jcastro ask about single click install?
[23:19] <asac> seb128: let me guess: apturl in evolution ;)
[23:19] <seb128> asac, right
[23:19] <asac> seb128: did you know that me and mvo are the ones that stay hard on keeping high barriers for getting whitelisted in apturl?
[23:19] <asac> seb128: so you cannot really easily get a trojan installed by that
[23:20] <asac> seb128: we wont allow automatic install of random repositories
[23:20] <seb128> asac, I've no clue about what apturl is doing, I just don't like the idea of one click in an email installing random debs from the internet
[23:20] <asac> seb128: its not that
[23:20] <asac> seb128: think about it as installing packages from the ubuntu archive
[23:21] <asac> seb128: anyway, this reminds me: do you disable running gdebi from evolution?
[23:21] <asac> we should certainly do that
[23:21] <seb128> the default action is to store the file but gdebi is in the list I think
[23:21] <asac> e.g. just allow debs to be safed to desktop instead of being opened in gdebi
[23:21] <asac> right. we will remove that for firefox ... similar to what they do on windows with .exe
[23:22] <seb128> the firefox open with dialog is not really nice
[23:22] <seb128> that's one of the things I've issue with since I switched
[23:22] <asac> still ... .debs and executables linked from potentially insecure sources should only be allowed to be saved
[23:22] <seb128> the other one is the lack of easy quick bookmarks entries
[23:22] <seb128> ack
[23:23]  * asac  adds a note to file a bug on all relevant bugs
[23:23] <asac> packages
[23:23] <asac> ;)
[23:23] <asac> seb128: do you know if the gnome mime database has a flag like "unsecure content" or something?
[23:23] <asac> insecure
[23:23] <asac> i think i saw mozilla code checking that somehow
[23:24] <seb128> asac, I don't think it has no (the database is a xdg one)
[23:24] <asac> but could be that it was just meta data they make up on their own on top
[23:24] <seb128> vuntz, ^
[23:28] <vuntz> no idea
[23:36] <seb128> asac, btw is there a way to open new tabs when you middle click in a page just after the tab you are using?
[23:54] <asac_> seb128: reconnected ... i always add new tabs to the end - what key combo does ephy use?
[23:55] <seb128> asac_, none, you can just set it to open tabs next to where you are or at the end
[23:56] <seb128> asac_, I often open the upstream task for a bug by middle clicking on it
[23:56] <seb128> asac_, it's sort of suboptimal to have to go 15 tabs further to have a look and come back
[23:56] <asac_> i agree
[23:58] <seb128> asac_, and I guess there is no option to add text entries for quick bookmarks the way epiphany does?
[23:58] <seb128> I find having to type keyboard slow and complicated compared to entries ;-)
[23:58] <seb128> otherwise no complain about firefox it works correctly
[23:58] <asac_> you mean like live bookmark? but in the search box?
[23:58] <seb128> I've "launchpad/bugs/%s" = lp keyword
[23:59] <asac_> https://addons.mozilla.org/en-US/firefox/addon/1956 ... or https://addons.mozilla.org/en-US/firefox/addon/1122
[23:59] <seb128> so I do "lp 678"
[23:59] <asac_> for advanced tab stuff
[23:59] <seb128> or "lp 123"
[23:59] <asac_> but personally i would agree that it would be beter to have an option
[23:59] <seb128> but you have to type text and remember the keyword to use
[23:59] <asac_> however, mozilla always tries to keep amount of available options low to keep UI easy