[00:05] <TheMuso> Is anybody either planning to update, or working on an update to vte?
[00:08] <seb128> mvo did in bzr today to 0.21.1
[00:09] <seb128> but he didn't upload because he wanted to look at why gdebi is broken
[00:09] <seb128> it's already broken in karmic though so feel free to upload if you want to get the fix for reset crashing vte or similar
[00:09] <seb128> there is also a 0.21.2 if you want to do that update
[00:10] <TheMuso> Ok I may look into it. Having my terminal randomly crash due to using a11y tools is a little frustrating.
[00:17] <seb128> TheMuso, thanks
[00:27] <Laney> new f-spot in sid
[00:28] <seb128> Laney, cool, it will be after beta for karmic
[00:28] <Laney> sure
[00:28] <Laney> i'll requestsync it tomorrow
[00:28] <seb128> don't bother
[00:28] <seb128> I will do GNOME syncs after the freeze using versions
[00:29] <Laney> oh ok
[00:32] <seb128> 'night
[00:32] <Laney> sleep well
[05:11] <ccheney> grr my computer is apparently too new to run jaunty, having to burn a karmic daily to see if it works
[05:26] <ccheney> karmic looks pretty :) except for the black console screen for a few secs on cd boot
[05:26] <ccheney> i thought x had died
[05:37] <ccheney> only took 7m to install after clicking install button off cd, not too bad
[05:39] <ccheney> 41s to the desktop with an old hd (~ 6 years old hd)
[05:45] <user321>  http://master.dl.sourceforge.net/project/dooble/Dooble-Web-Browser_0.07_svn874_Ubuntu-Karmic-9.10-1i386.deb
[05:46] <user321>  http://master.dl.sourceforge.net/project/dooble/Dooble-Web-Browser_0.07_svn874_Ubuntu-Karmic-9.10-1i386.deb
[05:46] <user321>  http://master.dl.sourceforge.net/project/dooble/Dooble-Web-Browser_0.07_svn874_Ubuntu-Karmic-9.10-1i386.deb
[05:46] <user321>  New Web Browser for Ubuntu Karmic and higher released: http://dooble.sourceforge.net/
[06:30] <Amaranth> ccheney: OOo build going yet? :)
[06:36] <al-maisan> Good morning!
[06:40] <Amaranth> ccheney: also, what speed did it end up running stable at?
[06:40] <Amaranth> Or are you using OOo builds to test that? :)
[06:41] <Amaranth> morning al-maisan
[06:41] <al-maisan> hello Amaranth :)
[06:42] <Amaranth> just barely morning here, 00:42 :P
[06:44] <al-maisan> Amaranth: ah, bed time for you :)
[06:45] <Amaranth> nah, I sleep funny hours :)
[06:45]  * al-maisan used to do the same
[06:46] <al-maisan> .. but as my wife says: "..the best sleep is in the hours before midnight.."
[06:46] <al-maisan> sorry for the awkward English, I was translating from German :P
[06:47] <Amaranth> I'm used to it :)
[06:48] <al-maisan> sure, no problem :)
[07:29] <pitti> Good morning
[07:38] <didrocks> morning pitti
[07:51] <pitti> hey didrocks
[08:27] <robert_ancell_> Hey pitti, how do you find how who did a package upload?  I'm looking at bug 435562 - it appears seahorse-plugins was accidentally uploaded to universe instead of main
[08:28] <pitti> hey robert_ancell
[08:29] <pitti> robert_ancell: you can't upload "to universe" actually
[08:29] <pitti> someone demoted it to universe, I guess because it does not have any reverse dependencies any more
[08:30] <robert_ancell> where is that information stored? how do you know what is in universe/main?
[08:30] <pitti> robert_ancell: but in case you need to know the "who", you can see it on the source version page: https://edge.launchpad.net/ubuntu/+source/seahorse-plugins/2.28.0-0ubuntu1
[08:31] <robert_ancell> aha, dholbach...
[08:31] <pitti> robert_ancell: soyuz maintains the component lists; you can find it out on the source page (https://edge.launchpad.net/ubuntu/+source/seahorse-plugins) for all releases, or look at "apt-cache showsrc seahorse-plugins" (says universe), or look at "rmadison seahorse-plugins"
[08:31] <pitti> but as I said, an uploader cannot influence the component
[08:31] <pitti> that's an archive admin task to watch over them
[08:32] <pitti> and seeding/dependencies determine what is in main
[08:33] <robert_ancell> so there is a main list somewhere? Like a seed?
[08:34] <pitti> robert_ancell: in this particular case, in jaunty seahorse recommended -plugins, but that recommends was dropped in karmic
[08:34] <pitti> and thus there's nothing which keeps it in main
[08:34] <pitti> we need to seed it and re-promote
[08:34] <pitti> https://wiki.ubuntu.com/SeedManagement FYI
[08:35] <robert_ancell> thanks
[08:35] <pitti> you think we officially want to suport s-p?
[08:36] <robert_ancell> I don't see why not
[08:36] <robert_ancell> (so main is the union of all the seeds)
[08:37] <pitti> robert_ancell: right, main is "all seeds" in all derivatives, plus all their transitive binary depends/recommends and build depends
[08:37] <pitti> oops, not all derivatives
[08:37] <pitti> ubuntu and kubuntu
[08:37] <pitti> xubuntu and mythbuntu aren't actually required to consist of only main
[08:38] <pitti> that's going to become more flexible with the archive reorganization
[08:38] <pitti> i. e. main/universe will be dropped, and replaced with a more fine-grained structure like "ubuntu desktop", "xubuntu desktop", "langpacks", "core packages"
[08:39]  * pitti puts back seahorse-plugins to dvd
[08:39] <robert_ancell> thanks, the complaint was it had removed the encrypt menu from nautilus
[08:39] <pitti> and re-promoted
[08:44] <robert_ancell> pitti, should it be on the CD? Without it there is no encrypt option in nautilus (I just tested here to confirm that)
[08:44] <pitti> right, that's known; most developers probably use it for the GPG agent wrapper
[08:45] <pitti> but few normal users need that, and it costs quite a lot of startup time
[08:45] <pitti> gpg uses a pretty braindead way of integrating an agent, unfortunately
[08:45] <robert_ancell> ah, ok
[08:48] <didrocks> lut seb128
[08:51] <pitti>  bonjour seb128
[08:55] <seb128> hey didrocks pitti
[08:55] <seb128> hey chrisccoulson
[08:55] <chrisccoulson> hey seb128, how are you?
[08:55] <seb128> tired but good
[08:55] <seb128> you?
[08:56] <seb128> pitti, did you install the night updates yet?
[08:56] <seb128> is the gdm artwork change working for you?
[08:56] <pitti> seb128: I did, but not restarted yet
[08:56] <pitti> seb128: will try in a bit
[08:56] <chrisccoulson> yeah, i'm not too bad, but i've ran out of coffee this morning
[08:56] <seb128> pitti, you don't need to restart, just try switching user
[08:56] <chrisccoulson> disaster ;)
[08:56] <seb128> chrisccoulson, indeed!
[08:56] <seb128> good reason to go early to work to use work's coffee? ;-)
[08:57] <chrisccoulson> it would be, if work provided nice coffee;)
[08:57] <seb128> no luck for you today then ;-)
[08:58] <chrisccoulson> i'll have to go to the supermarket shortly;)
[08:58] <seb128> hey mvo_
[08:58] <chrisccoulson> perhaps i can sneak out without being noticed!
[08:58] <chrisccoulson> i rebased gnome-python-extras on debian last night btw
[08:58] <chrisccoulson> pushed to ubuntu-desktop
[08:58] <seb128> thanks
[08:59] <seb128> I will review all pending uploads and sync after beta
[08:59] <chrisccoulson> yeah, no problem
[09:00] <chrisccoulson> are there any other bugs that need working on at the moment? i'll be running out of things to do once i've uploaded glom ;)
[09:00] <mvo_> hey seb128
[09:00] <seb128> chrisccoulson, still all the desktop-bugs milestoned for karmic
[09:00] <seb128> I've been added things there, there should be enough to keep everybody busy
[09:00] <chrisccoulson> i'll try and take a look at some of them. i already tried to look at totem and gnome-keyring-daemon, but i'm stuck with both of those
[09:02] <pitti> seb128: new background works here; I can't say about the theme, what's a good indication of that?
[09:02] <pitti> it's not sufficiently different to be immediately obvious
[09:02] <seb128> pitti, dunno but background is the most important and both keys are written using the same way
[09:02] <seb128> so it one works the other should be ok too
[09:02] <pitti> seb128: right, I guess it works
[09:02] <seb128> cool, thanks for testing
[09:02]  * pitti hugs seb128, thanks for sorting this out
[09:02]  * seb128 hugs pitti
[09:03] <seb128> pitti, btw dobey wanted a ubuntuone-client sponsoring upload yesterday night
[09:03] <seb128> I didn't do it because it was after 1am already and launchpad had issues
[09:04] <seb128> and I'm not sure if that's something on the beta scope too ... if you want to look at it
[09:06] <chrisccoulson> seb128 - have you seen bug 438561 yet?
[09:06] <chrisccoulson> seems to be related to the recent change
[09:06] <seb128> chrisccoulson, I was just looking at it
[09:06] <seb128> it's weird, I don't think the changes should affect the maintainer scripts
[09:06] <seb128> and dbus should be always available
[09:07] <seb128> only one user got it so far I think
[09:07] <chrisccoulson> yeah, i didn't see any issue either
[09:08] <seb128> lol bug #438523
[09:08] <mvo_> seb128: *grumpf* it seems that vte is eating the "env" that is passed to fork_command again, it does that every version thtat is released
[09:10] <seb128> mvo_, :-(
[09:10] <chrisccoulson> seb128 - lol, some people are shameless;)
[09:11] <mvo_> seb128: and I reported it in july with a patch(!) and a example program
[09:11] <pitti> chrisccoulson: thanks for having figured out the d-bus startup problem
[09:11] <mvo_> seb128: bug 587894
[09:11] <mvo_> gnome  bug 587894
[09:11] <seb128> mvo_, tring pinging behdad on #gnome-hackers
[09:11] <pitti> chrisccoulson: I saw a new indicator-applet uploaded with an async service startup
[09:11] <seb128> what was the issue?
[09:12] <chrisccoulson> hey pitti, i'm not sure how relevant it is though. the issue i found only seems to be applicable to things which daemonize before claiming the service name
[09:12] <seb128> pitti, about this totem bug, we discussed it with robert and neither of us has a clue how to debug that one
[09:12] <chrisccoulson> so, in the case of system-tools-backends, dbus thinks that activation failed, which is why users-admin fails for the first time
[09:12] <pitti> chrisccoulson: AFAIUI you said that a d-bus service has to claim its name before forking?
[09:12] <seb128> pitti, so not sure reassigned to robert is efficient
[09:12] <seb128> pitti, if you have hints on how to debug python that's welcome though
[09:13] <seb128> pitti, valgrind lists tons of invalid read and write error on a simple import
[09:13] <pitti> seb128: ah, ok; please reassign it back to desktop-bugs then
[09:13] <chrisccoulson> pitti - i think so, but that's not possible is it? (ie, it has to claim it's name after forking)
[09:13] <seb128> pitti, it needs to be fixed by karmic I would prefer to have a real assignee
[09:13] <pitti> chrisccoulson: I don't know; I thought that's what you said over night
[09:14] <chrisccoulson> pitti - possibly ;) i'm not sure how that would work though
[09:14] <mvo_> seb128: you mean I should try to ping him? good idea I think
[09:14] <seb128> mvo_, yes
[09:14] <chrisccoulson> i think that dbus activation just doesn't work well with processes which fork after starting
[09:14] <mvo_> seb128: let me quickly try if my patch still works and if it does I will ask him :)
[09:14] <seb128> mvo_, he's usually responsive on IRC
[09:14] <pitti>  seb128: right, me too
[09:14] <pitti> chrisccoulson: but why would a d-bus backend fork in the first place?
[09:15] <pitti> chrisccoulson: for debugging it's better to not fork, and for normal acivation it matters even less..
[09:15] <chrisccoulson> pitti - i'm not sure, but system-tools-backends does
[09:15] <chrisccoulson> perhaps we should make system-tools-backends not fork
[09:15] <chrisccoulson> then we don't need an upstart job to start it on boot
[09:16] <pitti> chrisccoulson: *nod*
[09:16] <pitti> chrisccoulson: indeed, I seem to be able to reproduce that every time
[09:17] <chrisccoulson> that's an easy change, because you can just pass --no-daemon to it. it seems like a worthwhile change then
[09:17] <pitti> chrisccoulson: is there a bug report for this already?
[09:17] <pitti> absolutely
[09:17] <chrisccoulson> pitti - not that i'm aware of. i saw this issue last cycle when i thought it would be a good idea to remove the init script, but never had much chance to look at it
[09:18] <chrisccoulson> i'll open a bug report for it anyway
[09:19] <pitti> chrisccoulson: hang on
[09:19] <pitti> chrisccoulson: it seems like bug 411533 describes both the bug and the solution pretty accurately
[09:21] <pitti> chrisccoulson: do you want to work on this? or shall I assign it to me?
[09:21] <seb128> pitti, did you see my comment about ubuntuone-client before?
[09:22] <seb128> pitti, not sure if that's something you want to try to get in beta it seems dobey wanted it
[09:22] <chrisccoulson> pitti - i can work on that one
[09:22] <pitti> seb128: I saw, but it's really really late now, and only RC bug fixes now
[09:23] <seb128> ok, what I though, I just wanted to make sure you knew about it if dobey asks later ;-)
[09:27] <pitti> seb128: I can sponsor it, so that people can get it through upgrades asap
[09:27] <seb128> pitti, ok thanks!
[09:38] <asac> so we need a decision for epiphany for beta ... demote or promote ;)
[09:38] <seb128> asac, demote
[09:39] <asac> doing that now
[09:39] <seb128> it's not useful in main, it's not in the default install, it just makes harder to work on it
[09:39] <pitti> asac: oh, you can?
[09:40] <seb128> pitti, any reason we couldn't?
[09:40] <pitti> I mean, asac is an archive admin now?
[09:40] <seb128> pitti, are seed changes only limited to archive admins?
[09:40] <pitti> ah, seed change
[09:40] <pitti> no, of course not
[09:40] <seb128> ok
[09:42] <asac> done
[09:42] <asac> i dont want to be archive admin ;)
[09:46] <asac> hmm gwibber-daemon seems not get any updates anymore ... only sends out new tweets
[09:46] <asac> kenvandine: ?
[09:49] <chrisccoulson> i'm not sure gwibber even does that for me. It just crashes constantly for me at the moment
[09:49] <asac> hmm
[09:49] <asac> doesnt crash here
[09:49] <asac> just does not give me any new stuff ;)
[09:50] <asac> chrisccoulson: UI crashes? or daemon?
[09:50] <chrisccoulson> asac - daemon crashes
[09:51] <chrisccoulson> repeatedly too. if i close the gwibber window using the close button, it appears to minimize to the indicator applet. if i then try to relaunch it, the window never reappears and the daemon continuously crashes for the remainder of the session
[09:51] <chrisccoulson> or unless i manually kill both the UI and daemon
[09:54] <Amaranth> gwibber seems to fail to load links in chromium
[09:54] <Amaranth> it just opens a new chromium window on my home page
[09:57] <mat_t> pitti: hey
[10:00] <pitti> hey mat_t, how are you?
[10:01] <mat_t> hey pitti, great, you?
[10:01] <pitti> I'm fine, thanks
[10:01] <mat_t> pitti: just want to check if gdm theme changes are on your radar
[10:02] <pitti> mat_t: they were, until seb128 uploaded them last night :)
[10:02] <pitti> they are in karmic now
[10:02] <mat_t> ah :)
[10:02] <mat_t> yes, so there's still couple of things we need to change
[10:02] <mat_t> which should be simple
[10:03] <mat_t> basically removing battery and date, and updating the theme itself
[10:04] <pitti> oh, why battery?
[10:04] <pitti> (that's gnome-power-manager)
[10:08] <asac> pitti: ENV{ACL_MANAGE} in udev rules does what?
[10:09] <seb128> pitti, the information is judged as not useful and cluttering the screen or not looking nice there
[10:09] <asac> grand access to all users?
[10:09] <pitti> asac: it's an internal implementation detail in udev
[10:09] <pitti> asac: yes, devices with that are accessible to the current local foreground console
[10:10] <mat_t> pitti: you don't really need battery during login. By definition you only see this screen for couple of seconds. Let's keep it clean
[10:10] <asac> pitti: interesting. is that going through consolekit for that?
[10:10] <pitti> asac: yes, it does
[10:11] <pitti> mat_t: it might stay around for a while after you log out; but admittedly that's unlikely for a laptop
[10:11] <asac> thx
[10:11] <pitti> mat_t: yes, we can set a g-p-m gconf key to hide the applet
[10:12] <seb128> I will do that after beta if you want
[10:12] <mat_t> pitti: that would be great. The thinking is that the functionality on the login screen should only be restricted to what you actually need to know/do, when logging in. Things like battery and date will be constantly visible during your session.
[10:13] <seb128> you don't take in consideration university boxes staying on login screen though, clock can be handy sometime
[10:14] <mat_t> hm, many things can be handy "sometime". That usually leads to overcluttering the UI
[10:16] <seb128> let's just display a background image
[10:16] <seb128> who needs useful things when you can get shiny things
[10:16] <seb128> ;-)
[10:16] <mac_v> ;)
[10:17] <Amaranth> We're getting more shiny things?
[10:17] <seb128> I don't really agree on this "let's drop all the feature just to make things cleaner"
[10:17] <mac_v> Amaranth: yup , mat_t has done some nice icons for the gdm :)
[10:17] <Amaranth> wow, nautilus has more bugs open than compiz
[10:17] <Amaranth> I thought only update-manager did
[10:17] <seb128> you use a computer to get work done, not to watch something shiny
[10:18] <mat_t> seb128: we're not dropping all features. Just battery and date :)
[10:18] <seb128> well I don't see what is the issue with displaying time on a computer
[10:18] <mat_t> seb128: but do you really need to see it when logging in?
[10:18] <Amaranth> hmm, seems there is no bug open for nautilus not doing transitions between wallpaper anymore
[10:18] <seb128> I might be too much on the technical side of things but you guys seem sometime too much on the cleaning everything from screen
[10:18]  * Amaranth opens one
[10:19] <pitti> do I really need to see xsplash?
[10:19] <seb128> mat_t, as said i've been sitting in front of locked computer at university, etc where I found it useful
[10:19] <mat_t> pitti: yes :)
[10:19] <pitti> we have xsplash because it looks nice and comfy
[10:20] <pitti> so I demand a Westminster analog clock image, instead of our boring digital clock; with tick-tock noises, plz
[10:20] <seb128> mat_t, let's not discuss it for hours I've no strong opinion, I just don't think we need to drop everything on screen to make a computer nice to use
[10:20] <mat_t> pitti: exactly
[10:20] <mat_t> seb128: again, we're not even close from dropping "everything"
[10:20] <seb128> pitti, xsplash doesn't take anything useful away though ;-)
[10:20]  * Amaranth updates to latest nautilus first
[10:22] <seb128> Amaranth, works here
[10:22]  * mac_v wishes seb128 and pitti felt the same way while dropping the multiple autologin feature ;)
[10:23] <Amaranth> seb128: yeah, when you change your wallpaper is fades but the space backgrounds aren't doing their fade anymore
[10:23] <seb128> mat_t, yeah, as said no point to argue over such details
[10:23] <seb128> mat_t, the thing is that you designers think as the computer as something that should be nice to look at, and I think it as something which should be useful
[10:23] <seb128> mat_t, ie I will be in favor of a bit extra clutter and that makes my work easier
[10:24] <seb128> that doesn't mean any of us has the perfect balance ;-)
[10:24] <seb128> there is probably sensibility and users leaning toward both edges
[10:24] <mat_t> seb128: hm, I don't agree really. I would never ask to remove any useful and needed functionality.
[10:24] <mac_v> mat_t: how about using the date and time , and display them in the same style as your icons?
[10:24] <seb128> or rather at different values on the scale
[10:24] <seb128> mat_t, well, you find things "no useful" when they are for some users
[10:25] <seb128> mat_t, ie the button to close dialog in the corner
[10:25] <seb128> mat_t, or the clock on the login screen
[10:25] <pitti> mac_v: oh, I was just bitching :) I don't have a strong opinion about the clock
[10:25] <seb128> mat_t, or somebody tried to get the date dropped from the clock on default config
[10:25] <seb128> I think that was djsiegel
[10:25] <Amaranth> I thought it was mpt that wanted to remove the close button on dialogs :)
[10:25] <seb128> right, designers
[10:26] <seb128> I don't pick on one of them especially ;-)
[10:26] <seb128> I just say those are things I find useful they are making us drop on the way ;-)
[10:26] <Amaranth> seb128: that would be terrible, OS X just finally added the option to show the date on the clock which I thought was the single most important new feature
[10:26] <mat_t> seb128: taking away is sometimes necessary.
[10:27] <seb128> mat_t, it's just making my computer less efficient in benefit of visual improvements but I don't use a computer because it looks nice but because it gets work done ;-)
[10:27] <mat_t> seb128: but as you say, not worth having a fight :) I'm not super-opposed to having a clock there. I feel very strongly about battery though.
[10:27] <seb128> yeah, I don't think there is an usecase for the battery
[10:27] <Amaranth> laptop users aren't going to sit at the login screen and desktop users don't need it
[10:27] <pitti> *nod*
[10:27] <seb128> though I fail to see the small icon has a visual issue but I'm not enough of an designer for that I think ;-)
[10:27] <seb128> has -> as
[10:28] <mat_t> seb128: there's just a general rule that the UI that tries to do everything for everybody usually does nothing for most ;)
[10:28] <seb128> I'm not most :-p
[10:28] <Amaranth> mat_t: I think you can just sum that up as "emacs syndrome"
[10:28] <seb128> on that word, going back to get work done now ;-)
[10:28] <mat_t> :)
[10:28] <mat_t> thanks seb128
[10:29] <seb128> mat_t, np, sorry for the discussion, especially that I've no strong feeling about those in fact ;-)
[10:29] <seb128> I'm rather annoying by the "no icon", I like visual hint to spot items
[10:29] <seb128> annoyed
[10:29] <mat_t> no icon?
[10:29] <seb128> but I will not discuss this one
[10:30] <seb128> well, like the session indicator applet
[10:30] <seb128> it has some 11 items listed
[10:30] <seb128> I need to read half of it to spot logout every time
[10:30] <Amaranth> indeed
[10:30] <mat_t> ah, that :)
[10:30] <mac_v> seb128: we have mpt to blame for that!
[10:30] <seb128> where I used to spot what I want by looking the icon
[10:30] <Amaranth> although I think the problem is there are too many things in that menu
[10:30] <mat_t> yes, that something to discuss with sabdfl :)
[10:31] <mac_v> why does *every* user user have to be listed and also a new session option , guest session , and the current user too!
[10:31] <Amaranth> I should either show userpics so I know to skip those or show logout and etc icons so I know to look for them
[10:31] <seb128> I've the feeling I better no start discussing it, I will not convince him anyway ;-)
[10:31] <Amaranth> s/I should/It should/
[10:34] <andreasn> just out of curiosity I looked what the gdm screen looked like in a vm, it seems the gdm screen have too many items to fit on 800x600
[10:35] <andreasn> I don't have any battery in there though
[10:35] <andreasn> (but that's because of the vm)
[10:37] <andreasn> http://dl.getdropbox.com/u/184285/gdm-800x600.png
[10:39]  * Amaranth waves goodbye to the clock :(
[10:45] <mpt> The GDM panel is a basketcase
[10:46] <mpt> Someone should patch Glade so that whenever you use italics in an interface it puts up an error alert that says "NO, YOU'RE WRONG"
[10:47] <mac_v> andreasn: mat_t have planned for all the accessibility options to be moved to a menu , it dint yet happen :(
[10:47] <mac_v> s/have/had
[10:47] <andreasn> mpt, haha
[10:47] <pitti> mac_v: instead of a separate dialog you mean?
[10:49] <mac_v> pitti: i meant the panel > https://wiki.ubuntu.com/Artwork/Incoming/Karmic/Boot/Demo?action=AttachFile&do=get&target=gdm-menus-2.png
[10:49] <kwwii> andreasn: do you think we really need all those applets in the panel?
[10:51] <andreasn> kwwii, not if they don't fit :)
[10:53] <mat_t> mac_v: not accessibility options, but rather session options
[10:54] <mat_t> mac_v: https://wiki.ubuntu.com/DesktopTeam/Specs/Karmic/LoginExperience#Login%20screen%20with%20user%20picker%20and%20more%20than%20one%20user%20account
[10:55] <mac_v> mat_t: are we still gonna have that for karmic? or is something blocking it?
[10:56] <mat_t> mac_v: probably not for karmic, unless you can find someone who can do it :)
[10:57] <mac_v> mat_t: i think we are past the point of no return for karmic , even if we find someone ;)
[10:59] <mpt> mac_v, I've been trying to simplify the Lucid session menu over the past week
[11:03] <mac_v> mpt: sneak peak ? :)
[11:03] <mac_v> or let me guess you havent scanned it yet ;p
[11:04] <mpt> mac_v, sorry, no, there's about 9 different options and nothing even semi-final, let alone scanned
[11:04]  * Amaranth wonders if anyone realized Assistive isn't a word
[11:05] <andreasn> mpt, should I forward your e-mail about -symbolic to mcann and see if he's interested hacking on it?
[11:06] <mpt> andreasn, sure
[11:08] <mac_v> andreasn: hm.. the icons which are used in the notification area are not consistently named , for example bluetooth uses the app icon labeled "bluetooth" , icons for device are used in the area too... shouldnt the labels be devicename-status ? can some consistency be done for that?
[11:08] <mac_v> i mean devicename-active or devicename-disabled .. or so
[11:09] <andreasn> mac_v, I have no idea really, the notification area in general is a bit of a mess
[11:09] <mac_v> yeah.. it needs some clean up
[11:11] <andreasn> others have stronger and better opinions about icon-names, I try to stay as far away from that as possible
[11:11] <andreasn> :)
[11:23] <lool> seb128: telepathy-glib 0.9.0 has been released and is in unstable
[11:23] <lool> seb128: We'd love to get this into karmic after beta if that's doable
[11:23] <seb128> why?
[11:23] <lool> It adds the API/ABI relevant for moblin to do the stuff it was doing before TMC 5
[11:23] <lool> Currently, we're copying it into the moblin telepathy rdeps which is kind of ugly
[11:23] <seb128> I don't know they versioning scheme but that seems a major version bump and an unstable serie
[11:24] <lool> seb128: I don't know either
[11:24] <lool> seb128: we're at 0.7 though, so perhaps not an unstable series
[11:24] <seb128> ok, so my first reply would be "no, until you provide good rational and the debdiff looks reasonable"
[11:25] <lool> seb128: Is the rationale for moblin stuff good enough?
[11:25] <seb128> lool, right, but .37 in that serie
[11:25] <seb128> ie it had time to stabilize
[11:26] <seb128> lool, yes, but we need to make sure it doesn't impact the default im client in ubuntu
[11:26] <seb128> I don't think destabilizing our im for moblin benefit is a good deal
[11:27] <lool> http://paste.ubuntu.com/281174/
[11:27] <seb128> cassidy, ^ do you know if telepathy-glib 0.9 is a stable serie?
[11:27] <seb128>  b/telepathy-glib/account-manager.c                        | 1382 +++++++
[11:27] <seb128>  b/telepathy-glib/account.c                                | 2626 +++++++++++++
[11:27] <seb128> not trivial changes
[11:27] <cassidy> seb128, it's not. But that's just new API; so shouldn't destablize the desktop
[11:27] <cassidy> and Moblin needs it
[11:28] <lool> http://paste.ubuntu.com/281175/
[11:28] <lool> seb128: Reading the NEWS it looks mostly like API/ABI additions
[11:28] <seb128> reading that I would think 0.8 is what we want
[11:29] <lool> seb128: I would understand it if you fear it could break the IM client; are you usually the one testing empathy after such updates?
[11:29] <lool> seb128: the 0.8.0 -> 0.9.0 is really small thougj
[11:29] <lool> +diff
[11:29] <seb128> not really, we don't have formal testing right now, I've been following debian and what cassidy suggested
[11:29] <seb128> right, but it lands us on an unstable serie
[11:29] <seb128> where they might be 0.8.n bug fixes version later
[11:29] <lool> cassidy: What do you think?
[11:29] <seb128> and 0.9 might go wirld
[11:30] <seb128> wild
[11:30] <seb128> ie we will be stucked on a 0.9 and miss 0.8 bug fixes
[11:30] <lool> cassidy: We're discussing inclusion of 0.9.0 versus 0.8.0 versus 0.7.37 in karmic?
[11:30] <lool> cassidy: Will there be more 0.8 releases?
[11:32] <cassidy> lool, as you need 0.9 for Moblin, I'd say to go for it. Empathy won't use the new code anyway
[11:32] <seb128> cassidy, what about 0.8?
[11:32] <cassidy> (in 2.28)
[11:32] <seb128> will it get bug fix versions?
[11:32] <lool> cassidy: Well, we're trying to understand the risks for the desktop side of things
[11:32] <cassidy> 0.9 = 0.8 + new API for Moblin
[11:32] <seb128> ie if 0.8 get stable update and 0.9 extra changes we might be stucked on a line where we can't update and can't get bug fix updates too
[11:33] <cassidy> let me ask to the maintainer what's his policy about bug fixes releases :)
[11:33] <seb128> cassidy, well, now, but what is one month? what if 0.8 get bug fixes and 0.9 extra changes not fit for stable updates?
[11:33] <lool> cassidy: What seb128 fears is a) not being able to pick up bug fixes from 0.8.x b) destabilizing empathy with t-g 0.9.0
[11:33] <seb128> b) seems to not be an issue
[11:33] <lool> Right
[11:33] <seb128> but I don't want to make use screwed because 0.8 get ton of fixes but 0.9n get unstable changes
[11:34] <seb128> ie we have 0.9.0 but 0.9.1 has too many changes and there is no bug fix version we can get
[11:34] <cassidy> I see, let me ask :)
[11:34] <seb128> which would force us to stay on a raw 0.9.0
[11:36] <Zdra> for tp-glib?
[11:36] <cassidy> yep
[11:37] <Zdra> I would got with 0.9
[11:38] <Zdra> *go
[11:38] <Zdra> we branched only to depend on GIO IIRC
[11:38] <seb128> Zdra, you seem to be always in favor of getting next versions and feature though ;-)
[11:38] <seb128> upstream to not wait enough stability issues and how it's hard to have a distro staying stable
[11:39] <cassidy> isn't 0.9 required for Moblin ?
[11:39] <cassidy> afaik, we basically released it for Moblin :)
[11:39] <Zdra> cassidy, it will at least
[11:39] <Zdra> not sure it already depend on it
[11:40] <Zdra> seb128, indeed I like having things uptodate :p
[11:40] <Zdra> seb128, more seriously, I think keeping 0.8.x is fine for karmic is nothing is asking for 0.9.x, but moblin is very likely to depend on it...
[11:41] <seb128> lool, do you take responsability to backport important fixes to our 0.9 if required? ;-)
 seb128: smcv takes ABI very very seriously ideed     *VERY* seriously :)
[11:41] <Zdra> and tp-glib has good history of stability
[11:41] <cassidy> don't be worry about that
[11:42] <seb128> cassidy, Zdra: thanks
[11:42] <cassidy> np
[11:47] <mat_t> pitti: I'm not getting correct (notify-osd) icons for power notifications. Is that a known issue?
[11:47] <pitti> not to me
[11:48] <mat_t> pitti: would that be a g-p-m bug?
[11:49] <pitti> mat_t: my guess is that it's a notify-osd-icons bug
[11:49] <pitti> or notify-osd itself, but it doesn't matter much
[11:49] <mac_v> pitti: you moved the notify-osd icons to usr/share/notify-osd ,... right?
[11:49] <pitti> mac_v: right
[11:49] <pitti> which worked fine for e. g. the volume icons
[11:50] <mac_v> but it doesnt install the icons for upgrade users
[11:50] <pitti> so perhaps notify-osd-icons just ships a wrong name
[11:50] <pitti> mvo_: notify-osd pulls it in
[11:50] <pitti> erm, mac_v ^
[11:50] <mat_t> pitti: I can't file bugs, sends me to the wiki page :(
[11:50] <pitti> ubuntu-bug :)
[11:50] <mac_v> pitti: right now my notify/osd icons only has the old hi-color icons
[11:51] <pitti> mac_v: do you have notify-osd-icons installed?
[11:52] <mac_v> yes ;) the notify-osd folder ,  seem to not have the stylized human icons , and it does work but with the hi-color icons
[11:52] <mac_v> oh just a sec!
[11:53] <mac_v> pitti: ah ha! nope
[11:53] <mat_t> mac_v: bt icon looks great :)
[11:53] <mac_v> installing
[11:53] <mac_v> mat_t: thanks :)
[11:54] <mac_v> mat_t: seems , ,you need to install the  notify-osd-icons package , it works after installing it
[11:55] <mac_v> pitti: why didnt isnt this package in the ubuntu-desktop meta?
[11:56] <mat_t> mac_v: pitti: I've got it
[11:56] <pitti> mac_v: it's already a dependency of notify-osd
[11:57] <mac_v> hm , for some reason it didnt install or ask for install while updating
[11:58] <mac_v> kwwii: 2 wrong icon in the notify-osd package... then battery-empty and the battery-low are horizontal
[11:58] <mac_v> while the rest are vertical
[11:59] <mac_v> s/then bat.../the batter-empty
[12:09] <lool> seb128: If you like I can work on packaging the updates; the only issue is that I'm not organized to track them
[12:09] <lool> I mean, I don't follow releases and am not sub-ed to bug reports
[12:11] <lool> seb128: 12:24 <lool> Is this an unstable series?
[12:11] <lool> 12:45 <jonnylamb> It's a development cycle, with the odd number, but in  reality, it's no more dangerous than using a 0.7 release.
[12:11] <lool> 12:45 <jonnylamb> (this was discussed by hadess and smcv last night)
[12:16] <seb128> lool, we have been discussing that on #telepathy
[12:17] <seb128> lool, I'm fine with the update, they will probably try to arrange things to be easier for distributor
[12:17] <seb128> lool, I will ping you later if backporting is required for stable during the cycle ;-) but that should not be required, they expect it to be stable
[12:44] <lool> seb128: Ok; thanks a lot for discussion!  :-)
[13:16] <mac_v> pitti: hi... regarding the notifyosd icons >  kwwii said you have a bzr repo in ubuntu-desktop which he cannot change.. there needs to be a correction in the icons
[13:18] <mac_v> pitti: the notification-battery-empty.svg needs to be a symlink to notification-battery-000.svg
[13:18] <mac_v> the notification-battery-low.svg needs to be a symlink to notification-battery-020.svg
[13:18] <mac_v> right now they are using old icons , which can be removed and replaced with symlinks
[13:27] <seb128> launchpad is sloooow
[13:27] <kenvandine> asac, can you run both the daemon and client from a terminal and capture the output?
[13:28] <kenvandine> gwibber that is
[13:32] <chrisccoulson> seb128 - launchpad is not even working at all here
[13:36] <mac_v> kl;'
[13:54] <asac> kenvandine: doesnt the daemon log somewhere?
[13:57] <kenvandine> asac, no it doesn't... which sucks!
[13:57] <kenvandine> although
[13:58] <kenvandine> last night i created a branch that does
[13:58] <kenvandine> because it has been driving me nuts
[13:58] <kenvandine> and i want to make filing bugs more useful
[13:59] <asac> kenvandine: shouldnt the daemon put stderr into .xsessions-errors or something?
[14:00] <kenvandine> it doesn't, and i wouldn't like that
[14:01] <asac> well. thats the single place were things would go
[14:01] <kenvandine> full of noise though
[14:01] <asac> adding another log for user session stuff doesnt sound right
[14:01] <kenvandine> lots of things do
[14:01] <asac> kenvandine: you can filter for gwibber-* in the apport hook
[14:01] <kenvandine> true
[14:02] <kenvandine> my branch isn't ready for merging, for sure
[14:02] <asac> i dont mind. i just dont like the idea to put logs somewhere in user HOME
[14:02] <kenvandine> well, kind of a standard place xdg_cache_home
[14:02] <kenvandine> u1, desktopcouch, etc
[14:02] <kenvandine> all log there
[14:03] <kenvandine> i don't have strong opinions either way though
[14:03] <kenvandine> i just want logs somewhere!
[14:03] <seb128> logs should not go to xsession-errors
[14:03] <seb128> only errors should got there
[14:04] <kwwii> lool: hey, did you see the humanitydark theme
[14:04] <kenvandine> seb128, how do you feel about xdg_cache_home?
[14:04] <kenvandine> ~/.cache/gwibber/gwibber.log
[14:04] <kenvandine> something like that?
[14:04] <kwwii> seb128: for the desktop we need to get the latest icons from humanity
[14:04] <seb128> kwwii, it's too late for beta, ask pitti in case but I doubt he will be ok
[14:04] <seb128> he refused other things earlier today
[14:04] <seb128> kenvandine, .cache seems correct
[14:05] <kenvandine> ok, that's what i did
[14:05] <kenvandine> but it isn't ready yet... i just did it last night out of frustration from telling people to kill gwibber and run it in a terminal
[14:06] <kenvandine> that and adding timestamps... even running it in the terminal didn't help for long running hangs without times
[14:07] <pitti> kwwii: right, we can upload stuff to the queue, so that upgraders will get it  soon
[14:07] <pitti> (we flush the queue after beta release)
[14:08] <seb128> hey rickspencer3
[14:08] <seb128> rickspencer3, how are you?
[14:08] <rickspencer3> hi seb128
[14:08] <rickspencer3> I've been better
[14:08] <seb128> the night was not enough to get over your start of cold?
[14:09] <rickspencer3> sadly, no
[14:09] <rickspencer3> kenvandine, did you sneak those last couch bits into the beta
[14:10] <kenvandine> nope
[14:10] <kenvandine> but pitti is uploading (i hope)
[14:10] <kenvandine> so it is ready
[14:10] <kenvandine> rickspencer3, still not feeling well?  bummer
[14:10] <kwwii> pitti: cool, the only changes from my side is a) uploading the new humanity icons (bug fixes), b) the notification icons (bug fix) and c) human-theme (bug fixes and freeing up 2.4MB of space)
[14:10] <seb128> rickspencer3, the gdm artwork changes and the indicator-session crash fix landed in time for beta btw
[14:11] <rickspencer3> seb128, great
[14:11] <kenvandine> kwwii, is the green dot for the indicator icon fixed?
[14:11] <rickspencer3> I guess we can take stock of our remaining changes at the team meeting
[14:11] <seb128> speaking about the meeting ENOWIKIPAGE
[14:11] <kwwii> kenvandine: first I have heard about it...probably better to ping the people who made the theme... mac_v ?
[14:12] <kwwii> mac_v: have you or Dan heard about this?
[14:13] <kenvandine> pitti, was it you that filed that bug?
[14:13]  * mac_v reading backlog
[14:14] <kenvandine> mac_v, the green dot for the indicator
[14:14] <mac_v> kenvandine: in the indicator session?
[14:14] <kenvandine> yeah
[14:14] <kenvandine> applet
[14:14] <mac_v> yes thats fixed :)
[14:14] <kenvandine> woot!
[14:14] <kenvandine> thx
[14:15] <kenvandine> that has been driving me nuts :-p
[14:15] <mac_v> lol ;)
[14:15] <kwwii> another good reason to get the latest humanity icons in :)
[14:15] <kenvandine> i was ignoring IMs all day :)
[14:15] <seb128> so some people got used to the indicator behaviour, good to see ;-)
[14:16] <mac_v> kenvandine: if empathy is not running ... why does empathy launch from the indicator-session-applet , when selecting the status?
[14:16] <mac_v> is that the design
[14:16] <pitti> kenvandine: "that" bug?
[14:17] <seb128> hey tedg
[14:17] <kenvandine> well... side affect of a feature maybe
[14:17] <seb128> tedg, run away, people are talking about indicator bugs ;-)
[14:17] <mac_v> ah.. tedg is here ;)
[14:17] <kenvandine> so empathy is started when it needs to be by dbus
[14:17] <kenvandine> although
[14:17] <kenvandine> for me it has only been for new messages
[14:17] <tedg> seb128: All I hear is *features* anyway.
[14:17] <kenvandine> i tested that, i could set my status from the session applet and others could IM me
[14:18] <kenvandine> which would spawn empathy
[14:18] <kenvandine> i haven't seen empathy start before that
[14:18] <mac_v> kenvandine: the weird thing is now there are 2 locations to launch empathy
[14:18] <mac_v> tedg: what you missed>  if empathy is not running ... why does empathy launch from the indicator-session-applet , when selecting the status? is that the design ?
[14:18] <seb128> to get messages empathy is probably running
[14:18] <seb128> you just don't have the buddy list on screen
[14:18] <tedg> mac_v: No, it queries telepathy which decides to start itself.
[14:19] <tedg> mac_v: It's kinda the design of telepathy.
[14:19] <mac_v> tedg: argh! then why is there a need for another launcher in indicator-messages?
[14:19] <tedg> mac_v: We had worked around it before by querying MC4 of it's status, which didn't start the other clients, but now we don't have that feature in MissionControl.
[14:19] <mac_v> :(
[14:20] <kenvandine> mac_v, hopefully in the future it will be removed from the main menu
[14:20] <seb128> no no no
[14:20] <tedg> seb128: ?
[14:20] <seb128> not everybody is using the indicators you can't drop things from menus like that
[14:20] <tedg> I mean you don't have a "Start Pulseaudio" in the menu, because it's a system service...  why can't IM be the same?
[14:21] <seb128> because what if people don't use the indicator applet?
[14:21] <seb128> or don't use gnome
[14:21] <tedg> Then they won't have the GNOME application menu now will they ;)
[14:21] <seb128> the menus are a xdg standard
[14:21] <seb128> xfce use those
[14:21] <seb128> kde use those
[14:21] <seb128> etc
[14:21] <tedg> Yes, but we could put in the desktop file, don't show in blah.
[14:22] <seb128> well, what about GNOME users using awn
[14:22] <tedg> It would still show in the others.
[14:22] <seb128> or gnome-shell
[14:22]  * mac_v launches apps from messaging menu ;p
[14:22] <seb128> anyway it's not a discussion for now
[14:22] <tedg> seb128: Theres someone working on a messaging applet for AWN :)
[14:22] <seb128> but you will have a hard time to make me drop menu items
[14:23]  * tedg looks up seb128's vacation schedule ;)
[14:23] <seb128> you will still need somebody to upload ;-)
[14:23] <kenvandine> seb128, nobody has done it yet
[14:23] <kenvandine> there needs to be a good plan
[14:23] <seb128> I've time before you run for motu and main upload ;-)
[14:23] <kenvandine> problems not solved yet... etc
[14:24] <kenvandine> seb128, i wouldn't upload something that was that inflexible :)
[14:24] <seb128> good
[14:24] <seb128> I will let you guys sort that though
[14:24] <seb128> I think it will be not trivial though ;-)
[14:24] <kenvandine> it is something we need to figure out
[14:24] <kenvandine> yeah
[14:24] <kenvandine> i don't like have the dupes
[14:24] <seb128> and I think we have better things to spend our efforts on
[14:25] <tedg> Yes, of course.  But we're just preparing you for the future seb128 ;)
[14:25] <tedg> It's kinda like talking about flying cars.
[14:25] <seb128> though flying cars are sort of cool
[14:25] <seb128> where dropping a menu item is sort of boring
[14:25] <seb128> ;-)
[14:26] <tedg> Oh, if they're boring, you won't mind if we drop a couple ;)
[14:27] <tedg> I'm not sure about the starting from session.
[14:27] <tedg> It's not great, but it really doesn't do anything if you don't have any accounts configured.
[14:27] <tedg> So, I kinda feel that it's okay.
[14:27] <tedg> It's definitely unexpected behavior for most users, whether it's unexpected good or unexpected bad.
[14:28] <seb128> if you want remove duplication start by making launchers not listed for softwares not used
[14:28] <seb128> ie not listing pidgin for empathy users and other way around
[14:28] <seb128> which is a not trivial one too ;-)
[14:29] <tedg> Yeah, who came up with the crazy "leave Pidgin in main" strategy?!?!
[14:29]  * tedg looks at rickspencer3
[14:29] <tedg> If it just uninstalled...
[14:31] <seb128> tedg, you are in a troll mood apparently ;-)
[14:31] <seb128> joke aside we can't uninstall a software which can be registered in user session, etc especially if we don't migrate logs and some datas
[14:32] <tedg> seb128: You caught me before my first cup of coffee.
[14:32] <seb128> tedg, rocky mistake, don't start IRC before coffee ;-)
[14:32] <MenZa> aaargh
[14:32] <lool> kwwii: in a meeting right now
[14:32] <MenZa> all that mention of coffee is making me beep.
[14:32] <rickspencer3> kenvandine, Riddell - I got the team meeting wiki page started, so you can add in  your status reports for partner / Kubuntu stuff:
[14:32] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-09-29
[14:32] <kenvandine> thx
[14:33] <seb128> tedg, btw when you have time after coffee we should talk about what we can do about the duplicate im entries
[14:33] <tedg> seb128: Interesting idea I heard the other day.  Make both Pidgin and Empathy put logs in Couch, then you could access them anywhere from any client and we're all good!
[14:33] <seb128> I've the feeling that it will be "stay with those"
[14:33] <tedg> seb128: Yeah, I can't see anyway around that.
[14:34] <tedg> seb128: The problem is that people in many cases have accounts configured in both, even if they aren't using them.
[14:34] <seb128> right
[14:34] <seb128> basically everybody who has pidgin installed, ie all upgraders
[14:35] <tedg> Yup, I haven't written it up, but I think promoting the instructions on black listing is the best we can do.
[14:35] <seb128> there is no plan to have an ui to edit launchers listed there?
[14:36] <seb128> grrr, launchpad is too slow to work today
[14:36] <tedg> seb128: Yes and no.  It's been around the table more than once.  Currently if you disable the plugins in Evo and Pidgin they will blacklist themselves.  The current philosophy is that it should be in the same place you configure the behavior in the application.
[14:37] <seb128> so you have to start the application to opt it out
[14:37] <seb128> ie configure an email account in evolution if you don't use it...
[14:37] <tedg> seb128: Yes, you've identified the downside.  There's a bug on it.
[14:38] <tedg> BTW, there was a bug files about the launchers still not being translated. That's working for you, right?
[14:39] <Zdra> tedg, we have plans to move empathy logs to a DB ;)
[14:39] <Zdra> actually we already made the refactoring necessary
[14:39] <Zdra> just need someone to write the db code
[14:40] <tedg> Zdra: Hmmm.  Cool.  It would be cool if it was something like Couch so that I could get the same logs on say my desktop and my N900
[14:40] <tedg> Zdra: You might be able to convince rodrigo_ to help :)
[14:41] <kenvandine> there is couchdb-glib :)
[14:42] <seb128> tedg, they were a week ago and it's broken again now
[14:42] <tedg> seb128: Oh, no!  Hmm, okay.
[14:42] <seb128> tedg, and I'm wondering if that's due to the new tarballs from some days ago
[14:43] <tedg> seb128: Yes, I took your patch and tried to put in all the translation stuff.  I must have screwed something up :(
[14:43] <seb128> tedg, it was in indicator-messages?
[14:43] <tedg> seb128: Yes.
[14:43] <seb128> let me have a look since launchpad is too slow to work on bugs anyway
[14:44] <tedg> Heh, thank you Launchpad! :)
[14:45] <kenvandine> LP is hit or miss for me today... one page load takes 3 minutes, the next is 10s
[14:45] <kenvandine> very frustrating... but oh well
[14:45] <kwwii> kenvandine: it is timing out here, can't push to it :(
[14:45] <kenvandine> :/
[14:45] <kenvandine> feels like release day or something :)
[14:46] <kenvandine> although... the wiki is taking forever for me too
[14:46] <kenvandine> oh
[14:46] <kenvandine> auth
[14:46] <kenvandine> damn!
[14:46] <Zdra> tedg, our code is now able to handle many log sources, we have an interface we can implement on couch/sql/xml/anything
[14:46] <kenvandine> Zdra, excellent
[14:52] <mac_v> lool: hi... any update on the humanity theme?
[14:52] <mac_v> pitti: ping ;) notify-osd icons?
[14:55] <seb128> tedg, it's the "	textdomain (GETTEXT_PACKAGE);" which breaks it
[14:55] <pitti> mac_v: sorry, -EBUSY
[14:55] <pitti> mac_v: I thought you just didn't have the package installed?
[14:55] <kwwii> pitti: can you at least point me to where they are in lp?
[14:55] <pitti> ah, the ping earlier
[14:56] <pitti> kwwii: "they"?
[14:56] <kwwii> pitti: searching for them seems to lead to crack-smoking designers
[14:56] <kwwii> pitti: the notification icons
[14:56] <tedg> seb128: Hmm, what should it be.  That was from the gettext documentation.
[14:56] <rodrigo_> tedg: you already have a n900?
[14:56] <tedg> rodrigo_: No, I wish.
[14:56] <kwwii> lp used to be somewhat usefull, now it is killing me
[14:56] <seb128> tedg, I'm not sure, it doesn't seem wrong but it seems to break your glib gettext patch
[14:57] <pitti> kwwii: I based that on lp:~ubuntu-art-pkg/%2Bjunk/notify-osd-icons/ and pushed to lp:~ubuntu-desktop/notify-osd/notify-osd-icons-ubuntu/
[14:57] <rodrigo_> tedg: ah, ok :)
[14:57] <seb128> tedg, ie I guess it makes try to use the indicator-messages domain and not the desktop one for some reason
[14:57] <kwwii> pitti: killer, thanks
[14:57] <pitti> kwwii: perhaps we should settle for ~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu ?
[14:57] <pitti> kwwii: and drop the +junk and ~ubuntu-desktop branch
[14:57] <seb128> tedg, easy workaround is to remove the line for now, I don't think it's required
[14:57] <tedg> rodrigo_: Maybe we should see if Zdra knows someone who can help us with our N900... problem ;)  It's for development or something, not just because I really want one :)
[14:58] <pitti> kwwii: hang on..
[14:58] <kwwii> pitti: yes, that would probably be best...I couldn't figure out how to drop the +junk :p
[14:58] <seb128> tedg, I will try to look at the glib issue but it might not be before karmic
[14:58] <rodrigo_> tedg: yeah, same case here :D
[14:58] <tedg> seb128: Okay, I didn't know if it was required for using the local translations.
[14:58] <seb128> tedg, what is required?
[14:58] <tedg> seb128: The only thing translated in the service is the time "%d h" and "%d m" for the times.
[14:58] <seb128> tedg, I'm saying your code looks ok but breaks the glib gettext thing
[14:58] <seb128> oh, "if"
[14:59] <seb128> no, it should be fine with the bindtextdomain() call
[14:59] <Zdra> tedg, you want an N900 for what?
[14:59] <tedg> Zdra: Uhm... important stuff.  Like looking really cool. :)
[15:00] <Zdra> :p
[15:00] <tedg> seb128: Ah, okay.
[15:00] <Zdra> tedg, I guess if you need some, Canonical should ask Nokia
[15:00] <pitti> kwwii: done; I deleted the junk branch and changed owner of the packaging branch; please bzr pull --remember lp:~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu
[15:02] <ccheney> Amaranth: took 54m to build fresh (no ccache)
[15:02] <tedg> Zdra: Yeah, the problem is my boss has met me, so he already knows that not even a N900 would make me look cool. ;)
[15:02] <Amaranth> ccheney: holy crap
[15:03] <Amaranth> ccheney: now you just need a better upspeed :)
[15:03] <kwwii> pitti: killer, I am going to add a .links file to fix a bug...thanks for the help
[15:03] <ccheney> Amaranth: thats for my nogsi build though
[15:03] <pitti> kwwii: thanks muchly
[15:03] <ccheney> Amaranth: iirc it still took ~ 4 hours for that on my old system
[15:03] <pitti> kwwii: bug> the missing icons for battery? (as mat_t reported)
[15:04] <ccheney> Amaranth: i always build with nogsi on my home machine to speed up the builds though
[15:04] <ccheney> Amaranth: final stable speed was 3.6ghz
[15:04] <Amaranth> nice
[15:04] <kwwii> pitti: it is missing two vertical icons, if that is the bug, yes
[15:05] <kwwii> pitti: I am just going to link -000.png and 020.png to them and remove the current versions
[15:05] <ccheney> Amaranth: lynnfield chips have a low max voltage for Vtt which limited me, i didn't want to use higher than the max voltage on mine so it won't have a chance of burning out
[15:05] <mat_t> pitti: kwwii: I had no correct icons at all
[15:05] <ccheney> Amaranth: the i7 9xx series has a much higher max voltage for Vtt
[15:05] <kwwii> mat_t: that sounds like a different bug :p
[15:05] <mat_t> very possibly
[15:06] <kwwii> on another note, it was noticed that OOo still has human icons
[15:06] <ccheney> Amaranth: oh and 54m was with using a 6 year old slow hd
[15:07] <Amaranth> ccheney: Now you just need an SSD for / and a fast 1TB drive for /home and you'll have super-rig :)
[15:07] <ccheney> kwwii: what are we supposed to be using instead? :)
[15:07] <kwwii> ccheney: no idea, that is part of the problem :p
[15:07] <ccheney> kwwii: ok :)
[15:08] <ccheney> Amaranth: i have a 1tb drive already that is pretty fast, i just didn't put it in yet until the system is totally stable so it won't get corrupted
[15:09]  * ccheney bbl, gotta get ready for closing, moving people, etc
[15:09] <lool> mac_v: What update do you want?
[15:09] <lool> kwwii: I finished my meeting
[15:09] <lool> kwwii: Was it it you wanted to chat about?
[15:11] <kwwii> lool: about getting the humanitydark theme in UNR
[15:11] <kwwii> lool: mac_v knows all about it
[15:13] <lool> kwwii: Yeah and mac_v tells me you know about it
[15:13] <mac_v> lool: i also mentioned on the bug
[15:13] <lool> kwwii: So I know about it too actually
[15:13] <lool> I proposed this technical implementation in the eventuality we would like different notification area icons in unr and desktop
[15:13] <mac_v> lool: the bug report has the link for the dark theme too , i said kwwii has tested it
[15:14] <lool> But after chatting with Ivanka, yesterday, it was clear that we did not want to do any more changes
[15:14] <lool> She told me she would be testing it
[15:14] <kwwii> hrm, that would have been good to know
[15:14] <lool> kwwii: She was supposed to comment on the bug but didn't
[15:14] <mac_v> lool: but she doesnt know that kwwii and mat_t have tested it
[15:14] <lool> Which is why I did this morning
[15:14] <lool> mac_v: So don't tell me, tell her
[15:15] <kwwii> ouch, I am on a call with her atm, will ask
[15:15] <mac_v> lool: where is she , i cant find her ;)
[15:15] <lool> I personally wont change anything anymore unless I hear it from Ivanka or Mark
[15:16] <mac_v> lool: its fine by me to leave this as in both Ubuntu and UNR...  folks raised concern over the contrast ... hence i redid the icons... if you prefer as is now.. no probs then ;)
[15:17] <lool> mac_v: It was nice to prepare for an eventual switch
[15:17] <lool> I'm happy Ivanka took the decision we could live with what we have now as it's really too late for any change
[15:18] <mat_t> lool, sorry what is the discussion about?
[15:18] <lool> humanity
[15:19] <mat_t> anything in particular?
[15:19] <mac_v> lool: when you were considering new updates for telepathy-glib and stuff ,whats wrong with updating the icons ;)
[15:19] <mac_v> there is no breakage here , only stuff will be better :)
[15:20] <mat_t> lool: Current icons are fine, there's few small issues still, but the contrast is fine now
[15:22] <mat_t> lool: we need new Ubuntu One icon for example :)
[15:22] <mac_v> mat_t: that wont be for karmic ;) .. pls see the bug
[15:24] <mat_t> lool: spoke to ivanka now, she's happy to go ahead
[15:24] <mat_t> kwwii: ^
[15:26] <kwwii> ;)
[15:30] <kwwii> mac_v: just added a .links file to the notify-osd-icons-ubuntu to link the files correctly and removed the existing -empty and -low, check it out and let me know if you think that is correct
[15:31] <ccheney> Amaranth: ccache build only takes 28m, would probably be quite a bit faster with my newer hard drive
[15:32] <Amaranth> *drool*
[15:33] <ccheney> iirc ccache on my old machine was ~ 100m
[15:33] <Amaranth> ccheney: You can build several times in the time it takes you to upload
[15:33] <ccheney> yea a cached build now takes less time than it takes me to upload, heh
[15:34] <Amaranth> I thought uploading took you like 90 minutes
[15:34] <ccheney> takes about an hour to upload both ooo and ooo-l10n
[15:34] <Amaranth> ah, not that bad then
[15:34] <ccheney> since i don't upload the orig.tar.gz from my house
[15:35] <Amaranth> wait, it's an hour to upload the diff?
[15:35] <ccheney> at my new house moving to on thursday i should be able to upload in ~ 30m instead
[15:35] <ccheney> Amaranth: yea the two diffs are ~ 200MB total
[15:35] <Amaranth> *headdesk*
[15:35] <Amaranth> ccheney: Did you replace half the code or something? :)
[15:35] <Amaranth> Or is that all ooo-build stuff?
[15:35] <ccheney> Amaranth: go-oo did something like that ;-)
[15:36] <ccheney> yea ooo-build stuff
[15:36] <Amaranth> So it has a different solver or whatever in calc at least
[15:37] <ccheney> i think they dropped that part of the patch with OOo 3.x
[15:38] <ccheney> oh yea another part of the speedup was using ext4
[15:38] <ccheney> i was using ext3 with jaunty
[15:38]  * ccheney will have to do a rebuild on his old machine to get better comparable numbers
[15:39] <rodrigo_1> hmm, how do I update a package branch that has the source code?
[15:39] <rodrigo_1> that is, not just the debian dir
[15:41] <james_w> rodrigo_: update how?
[15:41] <rodrigo_> james_w: I've done a new upstream release, so how do I get the source from that upstream release into the package branch?
[15:42] <james_w> rodrigo_: bzr merge-upstream <URL of tarball>
[15:42] <rodrigo_> ah, cool!
[15:44] <pitti> rodrigo_: and the packaging branch is not a proper branch of the upsptream one?
[15:44] <pitti> (because then it should just be bzr merge?)
[15:44] <rodrigo_> hmm, not sure, it's the evolution-couchdb branch you created, I think
[15:44] <pitti> james_w: nice!
[15:45] <james_w> if the branch is based on the upstream branch as well then add that to the command
[15:45] <james_w> bzr merge-upstream <URL of tarball> <branch>
[15:45] <rodrigo_> pitti: how do I know?
[15:45] <james_w> with an optional "-r" to specify the revision if it is not the tip
[15:45] <pitti> rodrigo_: lp:~ubuntu-desktop/evolution-couchdb/ubuntu/ ? that's debian/ only and uses bzr-builddeb
[15:45] <rodrigo_> hmm, then I've got the wrong branch, it seems
[15:46] <pitti> above is the evo-couchdb package as it is in ubuntu (karmic)
[15:46] <rodrigo_> bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/evolution-couchdb/karmic/
[15:46] <pitti> oh, those
[15:46] <rodrigo_> so, yeah, wrong one it seems
[15:46] <pitti> please do not use them
[15:46] <rodrigo_> ok
[15:46] <pitti> rodrigo_: unfortunately we have auto-imports of all packages now, even those which are already in bzr
[15:46] <ivanka> lool: hi, are you here?
[15:46] <pitti> it's horribly confusing
[15:47] <pitti> rodrigo_: in general, you should use debcheckout -a packagename, or at least use apt-cache showsrc packagename and look for the Vcs-Bzr: field; that's the authoritative branch
[15:47] <rodrigo_> ok
[15:47] <rodrigo_> bzr+ssh://bazaar.launchpad.net/~ubuntu-desktop/couchdb-glib/ubuntu/ for couchdb-glib is ok, right?
[15:47] <rodrigo_> because I submitted a fix for that branch also
[15:47] <kwwii> pitti: in the human icon theme, we have a human-icon-theme.links file in /debian which creates symlinks, I added it to notify-osd-icons-ubuntu ...any idea how to make it work?
[15:48] <pitti> rodrigo_: correct
[15:48] <seb128> rename it to match the binary?
[15:48] <rodrigo_> ok, cool :)
[15:48] <slomo> seb128: oh, did you test the new changes to the non-ac3 dvd audio codecs bug?
[15:49] <pitti> kwwii: it just needs to be packagename.links, so notify-osd-icons.links
[15:49] <seb128> slomo, yes, I told you on IRC but I'm not sure you read it, it's not working
[15:49] <rodrigo_> pitti: the evo-couchdb one is missing a patch I submitted recently
[15:49]  * rodrigo_ looks for the patch
[15:49] <seb128> slomo, btw since you touch totem in debian, should the totem.desktop be in totem binary?
[15:49] <slomo> seb128: i mean the new one :)
[15:49] <kwwii> pitti: ahhh, I mistook that for the name of the dir...thanks
[15:50] <slomo> seb128: well, there already is a common package so it could as well be there :)
[15:50] <seb128> slomo, we got some bugs about people not cleaning -common and having the broken entry
[15:50] <slomo> oh
[15:50] <seb128> slomo, there is also a lintian warning saying that desktop should be with the binaries
[15:50] <slomo> i'll move it then ;)
[15:50] <seb128> to avoid those sort of issues
[15:50] <seb128> thanks ;-)
[15:50] <rodrigo_> pitti: right, apt-get source has the patch, but the branch doesn't
[15:50] <slomo> seb128: let me give you the relevant git changesets for the dvd stuff...
[15:50] <rodrigo_> pitti: should I just include the patch with my new submission?
[15:51] <seb128> slomo, sorry I'm not subscribed to the other bug and nobody commented on the one I filed
[15:51] <seb128> slomo, ie I didn't know about the updated version
[15:51] <pitti> rodrigo_: hm, the changelog doesn't mention a patch?
[15:51] <seb128> slomo, I will try it
[15:51] <slomo> seb128: it's marked as duplicate iirc
[15:51] <seb128> slomo, no it's not
[15:51] <seb128> slomo, #575568
[15:51] <pitti> rodrigo_: oh, I see
[15:52] <pitti> rodrigo_: someone uploaded the package without committing to bzr
[15:52] <pitti> there's a newer version in karmic
[15:52] <pitti> rodrigo_: hang on
[15:52] <rodrigo_> yes
[15:52] <rodrigo_> ok
[15:52] <slomo> seb128: oh well, there are many changes... shall i upload you an all-in-one diff somewhere? :)
[15:53] <seb128> slomo, either upload the diff or copy a i386 .so somewhere ;-)
[15:53] <seb128> I guess there is only on .so to overwrite? or does it need an update?
[15:53] <slomo> seb128: diff is easier (i love git) :)
[15:53] <slomo> two .so files
[15:53] <seb128> ok
[15:53] <pitti> rodrigo_: ok, pushed the recent upload, please pull again
[15:54] <seb128> could you add the diff on bgo #575568?
[15:54] <seb128> so I will get email and I don't forget to try later
[15:54] <rodrigo_> pitti: ok, there it is now, thanks!
[15:54] <seb128> slomo, ^
[15:54] <slomo> ok
[15:54] <seb128> thanks!
[15:55] <slomo> seb128: patch is attached :)
[15:56] <seb128> slomo, cool, thank you, I will try that a bit later (busy with other things now) and let you know
[15:56] <slomo> seb128: thanks, just write your results to the bugreport (i.e. close it as dup of #582779 if it works) :)
[15:56] <seb128> ok will do
[16:01] <kwwii> pitti: ok, I added a .link file to the notify-osd-icons (and removed two svg's, saving again, a few kb's of space). It installs correctly and works fine
[16:03] <pitti> \o/ thanks kwwii
[16:04] <kwwii> now I wonder what I can do with that extra 2.4MB from the human-theme update :p
[16:05] <mpt> mvo_, good news, the software-store bug reports are now all moved to software-center
[16:05] <pitti> kwwii: sounds like human-theme is empty now? it's 2.48 MB right now..
[16:06] <pitti> kwwii: can you please pull notify-osd-icons again? I fixed the changelog
[16:12] <Amaranth> mpt: that's terrible news :P
[16:12] <mpt> Amaranth, depends on your point of view, but it's good news for development purposes to have one list of bug reports rather than two
[16:13] <kwwii> pitti: yes, I will pull it, thanks
[16:14] <pitti> kwwii: I uploaded it now, please pull again
[16:14] <kwwii> pitti: will do
[16:15] <kwwii> pitti:  the gdm_background.png is now gone in human theme...it is/was 2.3MB
[16:15] <kwwii> other than that, the package is just text files and some really small bitmaps for buttons
[16:16] <pitti> after beta we need to reorganize the gdm background
[16:16] <pitti> right now, gdm sets the bg from xsplash theme, I think, which might be a bit hard to re-brand for derivatives
[16:16] <kwwii> pitti: ok, that pic is not being used anyway...gdm's gconf key uses one from the xsplash
[16:17] <pitti> kwwii: is it actually the same? it looks very similar
[16:17] <Amaranth> software-center has quite possibly the longest spec I've ever seen, very detailed
[16:17] <Amaranth> Usually it's just "we want this with these features for this reason"
[16:17] <kwwii> pitti: yes, it is a copy of the same image
[16:18] <kwwii> pitti: so removing it is a no-brainer
[16:19] <pitti> kwwii: ah, but not bitwise; the xsplash ones are much much smalller
[16:19] <kwwii> pitti: yeah
[16:19] <pitti> oh, .png
[16:19] <kwwii> *exactly*
[16:19] <pitti> right, so it's indeed a real space-saver \o/
[16:19] <kwwii> I could put another 6 photo wallpapers in!
[16:19] <kwwii> or more, probably
[16:19] <kwwii> but it's too late for that :)
[16:20]  * pitti sets human-theme changelog to "UNRELEASED" and fixes version number
[16:21] <pitti> kwwii: ^ can you please pull human-theme? is this good to upload, or are you working on more changes?
[16:21] <pitti> kwwii: (note that it won't actually get accepted until Friday, so if you have more changes, we can just as well wait)
[16:22] <kwwii> pitti: the current bzr is final, unless someone changes their mind ;)
[16:22] <kwwii> pitti: I commited changes today...I'll look at lp to make sure I did it correctly
[16:23] <pitti> kwwii: right, I  just pulled them; I just set the changelog from "karmic" to "UNRELEASED", since it's not uploaded yet
[16:23] <kwwii> pitti: excellent, thanks
[16:23] <pitti> kwwii: we use that as an indicator whether for a further change you just keep appending to the current changelog record, or start a new record/version number
[16:24] <pitti> it also shows that there are changes which need uploading
[16:24] <kwwii> pitti: yeah, I could use a course on changelogs...until now I have always bumped a number (for every change)
[16:25] <pitti> so with that I can do tricks like "head -n1 */debian/changelog|grep UNRELEASED" to see which of the ten million desktop branches have changes which need to be uploaded :)
[16:26] <mvo_> mpt: great, thanks!
[16:27] <kwwii> pitti: hehe, and i thought you just used lp for that :p
[16:28] <pitti> kwwii: I have local checkouts of all the desktop branches I usually touch/sponsor/upload
[16:29] <kwwii> pitti: wow, that is probably a lot of stuff...I get lost with the 10 branches I have now :p
[16:29] <pitti> it's not so bad, one for each package, named after the package
[16:29] <pitti> but it's quite a big forest of branches indeed :)
[16:33] <mpt> Amaranth, I expect it will be 2~3 times as long for v2 :-]
[16:34] <mpt> Amaranth, but possibly some of it can be factored out into stuff that's shared with Update Manager (e.g. the package list view)
[16:34] <Amaranth> mpt: I thought update manager was going away too
[16:35] <mpt> Amaranth, that was the original plan, but at the moment I don't see how we get from something light enough to appear automatically, to the full Center interface
[16:36] <Amaranth> mpt: could always revert back to showing update-notifier :)
[16:36] <mpt> And while "I want to install new application X, and why yes, I'll install pending updates at the same time" is moderately realistic, "oh, updates are available? why, now's the perfect time to install that application I've been meaning to" isn't really
[16:37] <rugby471> mpt: maybe we should have a lightweight update notifier (maybe based on existing code) but then have the opportunity to update in software-store itself as well
[16:37] <seb128> chrisccoulson, I did update the milestoned bugs list with some new ones
[16:38] <seb128> https://launchpad.net/~desktop-bugs/+bugs?field.milestone%3Alist=12698
[16:40] <chrisccoulson> seb128 - thanks, i'll take a look
[16:40] <chrisccoulson> i see one of the g-s-d crashers is there too. i tried looking at that but xrandr isn't very will documented
[16:40] <mpt> hi rugby471, how's hacking
[16:40] <seb128> chrisccoulson, right, those are quite common issues
[16:40] <rugby471> mpt: okay :-)
[16:41] <rugby471> mpontillo: one thing I wanted to ask you
[16:41] <rugby471> mpontillo: sorry wrong person
[16:41] <davmor2> tseliot: Ati Catalyst Control Center (administrative) fails to start saying Failed to execute child process axdxdg-su (no such file or directory)
[16:41] <rugby471> mpt: one thing I wanted to ask you about the status bar
[16:41] <rugby471> mpt: we cannot have both centered and resize grippy (at the moment), which do we want?
[16:41] <rugby471> *centered text
[16:41] <mpt> rugby471, just centered for now then I think
[16:42] <rugby471> mpt: no resize grippy?
[16:42] <mpt> rugby471, is it not possible to have a grippy without having a status bar?
[16:42] <rugby471> mpt: unfornately not, that would solve our problem :-)
[16:42] <mpt> extraordinary
[16:43] <mpt> rugby471, ok, centered with no grippy then please. Are you familiar with b.g.o to report the grippy bug in GTK+?
[16:43] <rugby471> mpt: seeing as I don't know what bgo is, probably not :-)
[16:43] <mpt> bugzilla.gnome.org
[16:43] <rugby471> mpt: ah yes I am :-)
[16:44] <mpt> bratsche_, do you happen to know if this is reported yet?
[16:44] <mclasen> mpt: there are bugs for that; feel free to attach your patch to an existing one...
[16:45] <mpt> mclasen, multiple bug reports? :-)
[16:45] <mclasen> maybe one or two
[16:45]  * bratsche_ reads
[16:46] <mpt> https://bugzilla.gnome.org/show_bug.cgi?id=591721
[16:47] <bratsche_> mpt: This is something I was thinking a little about when I was hacking on client-side-decorations.  Since I'm hopefully starting that again (and hopefully finishing this time!) then maybe I can look into this as well.
[16:48] <bratsche_> Gah
[16:48] <bratsche_> Something is so wrong with compiz focusing.
[16:48] <mpt> bratsche_, ok, you can race nzmm_ to implement it :-)
[16:48] <bratsche_> mpt: I lost the bug url, can you add me to CC on it?
[16:49] <mpt> bratsche, done
[16:49] <Amaranth> bratsche: eh?
[16:49] <bratsche> Thanks.
[16:50] <bratsche> Amaranth: I had my Chromium window focused, but somehow keyboard focus was on xchat.. and I was sitting there hitting Ctrl-L to try to focus the location bar on Chromium but it wasn't working, so I thought something was messed up in Chromium so I hit Ctrl-W to close it and it ended up closing #ubuntu-desktop instead.
[16:50] <Amaranth> hmm
[16:51] <bratsche> I've been noticing this a lot recently on my laptop.
[16:51] <bratsche> But this is the first time it kind of bit me like this.
[16:51] <Amaranth> iirc the only thing to change with focus handling is the fix to make policykit windows show on top
[16:51] <bratsche> Sometimes, but not always, the keyboard focus gets lost from a window when my mouse moves out of that window.
[16:51] <Amaranth> and iirc that change was to allow StateAbove windows (Always On Top) to steal focus
[16:52] <bratsche> So this time it seemed like the Chromium window was on top and had focus, but the mouse pointer was in xchat and xchat had the keyboard focus.
[16:52] <mpt> Amaranth, do you know the status of that PolicyKit window fix?
[16:52] <Amaranth> mpt: we got that fix in the first 0.8.3 packages
[16:53] <mpt> wonderful
[16:57] <rickspencer3> tseliot, hey, what's up with X, are you seriously considering updates?
[16:59] <tseliot> rickspencer3: not without bryce's opinion. But yes, I think that we should consider upgrading those components as they should fix a lot of bugs. We should make them available in a PPA for testing first
[17:00] <rickspencer3> tseliot, this would be good to discuss in the team meeting in 30 minutes
[17:00] <tseliot> not that I like the fact of upgrading the X stack at this point
[17:00] <tseliot> rickspencer3: ok
[17:00] <rickspencer3> tseliot, yes, it's always a trade-off, fixing bugs versus regressions
[17:00]  * tseliot nods
[17:00] <rickspencer3> tseliot, is there a list of bugs that would be fixed?
[17:01] <tseliot> rickspencer3: only a list of upstream bugs (some of which we filed). It would take me some time to find their equivalents on launchpad
[17:05] <rickspencer3> tseliot, well, is there anyway you could organize that list? I think it would be important for deciding what to do. We can look at upstream bug tracker it that's easier for you.
[17:06] <tseliot> rickspencer3: sure, let me finish packaging the synaptics driver for Pat
[17:06] <tseliot> and I'll make that list
[17:06] <rickspencer3> tseliot, great
[17:06] <rickspencer3> thanks
[17:07] <tseliot> np
[17:12] <rugby471> Amaranth: just had a load of old posts on the planet form you :-)
[17:13] <Amaranth> yeah, changed my blog software :/
[17:14] <rugby471> Amaranth: hehe np
[17:15] <rugby471> Amaranth: funny thing is I saw the post about the speed test meme and the title of your post was 'a Bit late'
[17:15] <rugby471> Amaranth: I was thinking 'yeah about 6 months late' :-)
[17:15] <Amaranth> heh
[17:27] <rickspencer3> Desktop team meeting in 3 minutes
[17:28] <asac> hi
[17:28] <seb128> hey
[17:28]  * pedro_ waves
[17:28] <ArneGoetje> hi
[17:29] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-09-29
[17:29] <rickspencer3> hi pedro_
[17:30] <tseliot> rickspencer3: I'm afraid this is all I can come up with atm: http://pastebin.ubuntu.com/281454/
[17:30] <rickspencer3> tseliot, ok, thanks
[17:30]  * kenvandine waves
[17:30] <rickspencer3> meeting time, ready?
[17:30] <tseliot> yep
[17:31] <awe_> ack
[17:31] <rickspencer3> ArneGoetje, asac, awe_ ccheney, KenEdwards , pedro_ pitti seb128 tkamppeter
[17:31] <pitti> o/
[17:31]  * rickspencer3 taps gavel
[17:31] <rickspencer3> oops
[17:31] <asac> 18:28 < asac> hi
[17:32] <rickspencer3> first on the agenda is how I totally forgot to track the action items from last week on this weeks team meeting
[17:32]  * rickspencer3 thanks asac for being a smart alec
[17:32] <rickspencer3> so, let's hop to partner update while I go look at last week's meeting
[17:32] <rickspencer3> kenvandine, ?
[17:33] <kenvandine> sure
[17:33] <kenvandine> so busy week last week
[17:33] <kenvandine> online services managed to get some cool stuff, but didn't make it for the beta
[17:33] <kenvandine> desktopcouch with syncing primarily
[17:34] <kenvandine> but will be in the queue of updates right after beta
[17:34] <kenvandine> by then the production server for syncing couch to u1 will also be up and ready for use
[17:34] <kenvandine> so we should be syncing our stuff :)
[17:34] <seb128> kenvandine, will any of the ols change be user visible in karmic?
[17:34] <kenvandine> in the mean time, if folks want to test desktop-to-desktop they can grab it from my ppa
[17:35] <kenvandine> seb128, not obviously
[17:35] <kenvandine> but
[17:35] <rickspencer3> seb128, aside from file-syncing, the changes will be available to application developers
[17:35] <rickspencer3> which will in turn be visible to users as features in their apps
[17:35] <kenvandine> if you have u1 setup, it will start syncing couch to the cloud for you
[17:35] <seb128> ok, I was just wondering if there anything to play with during beta testing from an user perspective
[17:35] <kenvandine> seb128, you can install bindwood from universe
[17:35] <kenvandine> and sync bookmarks
[17:35] <rickspencer3> seb128, yes, syncing desktop couch databases between desktops
[17:36] <kenvandine> also if you use the couch backend for evolution
[17:36] <kenvandine> contacts will sync
[17:36] <seb128> there is many words I don't understand there ;-)
[17:36] <rickspencer3> lol
[17:36] <seb128> but ok
[17:36] <rickspencer3> ACTION: rickspencer3 to create a wiki page about how to play with CouchDB and DesktopCouch
[17:36] <kenvandine> you should be able to pair/sync two desktops now if you get couchdb-bin and desktopcouch from my desktopcouch ppa
[17:36] <seb128> it seems there is nothing that will automagically work from an user perspective without tweaking
[17:36] <kenvandine> so please test
[17:36] <seb128> rickspencer3, thanks
[17:36]  * awe_ wishes bookmarking syncing worked before my fs died last week. ;(
[17:36] <rickspencer3> seb128, not quite true
[17:37] <rickspencer3> you can create a CouchDB address book in evolution, and it will sync across your computers
[17:37] <tkamppeter> hi
[17:37] <kenvandine> seb128, if you are subscribed to u1, it will just start syncing
[17:37] <kenvandine> you just need to tell evo to use the couch backend for addresses (already installed)
[17:37] <seb128> rickspencer3, can I get things like bookmark sharing active from the standard install with one click?
[17:37] <kenvandine> or install bindwood
[17:37] <kenvandine> at some point there will be more stuff
[17:37]  * tseliot will have to leave at 17:00 UTC
[17:37] <seb128> ok, I will discuss that after meeting I think or wait for the wiki page
[17:37] <kenvandine> seb128, no click yet... but using the software center sure
[17:37] <rickspencer3> ok
[17:38] <kenvandine> we need an apturl way too... but nothing is in place yet
[17:38] <seb128> I don't understand how it can sync things without me giving it a list of box and credentials
[17:38] <kenvandine> should end up on one.ubuntu.com though
[17:38] <rickspencer3> let's move on, but there is clearly some documentation that has to happen this week
[17:38] <kenvandine> sure
[17:38] <kenvandine> on to DX
[17:38] <kenvandine> a bunch of releases last week, including the user list added to the session applet
[17:38] <kenvandine> so please report bugs there
[17:39] <asac> oh
[17:39] <kenvandine> the menu ordering bug in the messaging menu is not fixed yet, but should be fixed in this weeks release
[17:39] <asac> is there a max number visible there?
[17:39] <kenvandine> not sure
[17:39] <kenvandine> good question though
[17:39] <asac> (lets talk later)
[17:39] <kenvandine> that could get ugly
[17:39] <kenvandine> pelase
[17:39] <kenvandine> please
[17:39] <pitti> I think 5 or 8; at least that's what the bug said
[17:39] <kenvandine> i think that is it for the partner update
[17:39] <rickspencer3> kenvandine, there is s spec that should cover that, correct?
[17:39] <kenvandine> i have six in mine
[17:40] <kenvandine> yeah
[17:40] <kenvandine> i will find it
[17:40] <kenvandine> asac, we can chat after the meeting
[17:40] <kenvandine> moving on
[17:40] <kenvandine> rickspencer3?
[17:41] <rickspencer3> thanks kenvandine
[17:41] <rickspencer3> Riddell, may we hop around a little? I'd like to discuss X stack why tseliot is still here
[17:41] <bratsche> kenvandine: It should be > 1 && < 7
[17:41] <kenvandine> ok
[17:42]  * nixternal doesn't see Riddell in here
[17:42] <bratsche> If it's not that's a bug, assign it to me.
[17:42] <rickspencer3> tseliot, wots the deal with the x updates?
[17:42] <tseliot> Intel contacted us and suggested that we upgrade some components of the X stack
[17:43] <tseliot> i.e. libdrm, -intel, mesa
[17:43] <rickspencer3> this was -intel and mesa 7.6 final?
[17:43] <tseliot> yep
[17:43] <tseliot> according to them
[17:43] <tseliot> they should fix a great deal of bugs
[17:44] <asac> what is our current version?
[17:44] <tseliot> here's a list of the things they should fix:
[17:44] <asac> a pre 7.6 snapshot or 7.5?
[17:44] <tseliot> http://pastebin.ubuntu.com/281454/
[17:44] <pitti> asac: 7.6 git
[17:44] <tseliot> asac: mesa is a snapshot of 7.6
[17:44] <asac> "Multiple fixes (need 2.6.32-rc1+ kernel) to make the driver stable for 8xx chipsets "
[17:44] <tseliot> so it would make sense for us to upgrade it to the final release
[17:44] <asac> need 2.6.32 ;)
[17:45] <rickspencer3> uh ... that sounds like a non-starter
[17:45] <tseliot> asac: we can backport that if needed. And I'm not sure as to whether those fixes are in 2.6.31.1 already
[17:45] <Amaranth> tseliot: If you update I'll be able to use KMS again (the backlight stuff) :)
[17:45] <asac> tseliot: how many of those bugs are release blockers for us?
[17:45] <rickspencer3> tseliot, are these fixed in our mesa:
[17:45] <rickspencer3> Fix various GPU freeze/hang on 965+: freedesktop-bugs #23688,freedesktop-bugs #23638,freedesktop-bugs #23594.
[17:46]  * rickspencer3 obviously has 965 chip ;)
[17:46] <pitti> (go ubottu)
[17:46] <rickspencer3> tseliot, sorry, answer asac first
[17:46] <tseliot> some gpu lockups should be already fixed (I put in some patches)
[17:47] <pitti> will they fix suspend/resume? :-)
[17:47] <pitti> (j/k, not expecting an answer)
[17:47] <Amaranth> Without the backlight stuff there are probably quite a few laptops with intel graphics that will be stuck on 100% brightness
[17:47] <tseliot> asac: good question, I don't have a list atm but the fixes for old intel cards i8xx should be worth the upgrade
[17:47] <tseliot> pitti: :-)
[17:48] <rickspencer3> ok, I feel that this is risky
[17:48] <asac> i have no insight how much regression potential we get
[17:48] <rickspencer3> the last time we took one of their "low risk" updates ... it was a bit of a mess
[17:48] <asac> because i dont know how far away our git snapshot is
[17:48] <tseliot> rickspencer3: it is risky
[17:48] <asac> but after beta the time is usually none-existent to do anything
[17:48] <rickspencer3> I think we should say "no", karmic is done
[17:48] <pitti> tseliot: how many changes are in betweek karmic and final mesa?
[17:48] <tseliot> and this is why I think they should live in a PPA at first
[17:49] <pitti> asac: August 17
[17:49] <asac> yeah. i would think if we are not that far away we might also be able to cherry-pick the most important ones
[17:49] <seb128> pitti, time is not really revelant
[17:49] <pitti> I know
[17:49] <seb128> that could be one commit or on thousand
[17:49] <asac> if thats not possible because they refactored too much it definitly feels like too risky to upgrade
[17:49] <pitti> but that's easy to check
[17:49] <tseliot> pitti: I haven't had the time to check that (I received Intel's email today) but I'll let you know
[17:49] <rickspencer3> pitti, I will defer to you, but I think our default answer is "no"
[17:49] <rickspencer3> however ...
[17:49] <pitti> *nod*
[17:49] <pitti> cherrypicking freeze fixes seems most appropriate to me right now
[17:49] <seb128> can we cherrypick fixes there?
[17:49] <asac> my opinion is: if cherry-picking does not work, we dont want to upgrade
[17:50] <asac> if cherry-picking works, we want to cherry-pick
[17:50] <pitti> asac: right, because then the changes since our snapshot were too intrusive
[17:50] <asac> exactly
[17:50] <seb128> +1
[17:50] <rickspencer3> I think tseliot should get a list of bugs that will be fixed, any version changes required, and the changes in the code
[17:50] <tseliot> Intel made it clear that it would be too much to backport all their fixes
[17:50] <tseliot> rickspencer3: +1
[17:50] <asac> that definitly means that upgrading is too risky imo
[17:50] <tseliot> I will
[17:51] <rickspencer3> so we are agreed, the karmic X stack today is the Karmic X stack we will ship with, modulo any blockers found by users in the beta?
[17:51] <pitti> tseliot: are these in the x-testers PPA? I'd love to try them and see whether they fix suspend/resume
[17:51] <rickspencer3> pitti, asac, seb128 , tseliot ^ ?
[17:51]  * rickspencer3 sorry I keep stomping on people :(
[17:51] <pitti> rickspencer3: well, save and pinpointed cherrypicks should really be considered
[17:52] <tseliot> pitti: not yet, sorry, I think I'll work on it (I've been busy with oem stuff)
[17:52] <asac> i think we should also fix blockers found before beta
[17:52] <asac> but cherry-pick
[17:52] <seb128> pitti++
[17:52] <pitti> tseliot: no prob, just curious
[17:52] <rickspencer3> pitti, ack, but are there blockers today?
[17:52] <pitti> rickspencer3: well, "blocker" is a rather fuzzy term
[17:52] <seb128> well freezes and suspend being broken seems candidate for blockers
[17:52] <pitti> we definitively have a bunch of regressions
[17:52] <asac> yeah
[17:53] <tseliot> seb128: +1
[17:53] <pitti> broken backlight, freezes, etc.
[17:53] <pitti> regressions are always worth fixing, if we can be reasonably sure that the fixes don't regress something else
[17:53] <rickspencer3> ok, we need a prioritized list of existant High or Critical x bugs
[17:53] <pitti> I wouldn't go as far as not touching any X package at all in the next three weeks
[17:53] <rickspencer3> see if there is code to cherry pick for those
[17:53] <tseliot> oh and there's a new xserver too
[17:54] <tseliot> (a bugfix release i.e. 1.6.4)
[17:54] <rickspencer3> pitti, agreed, I think we should fix bugs where we can *safely*
[17:54] <rickspencer3> ug
[17:54] <tseliot> BTW I think we have an ack on a FFE for mesa already
[17:55] <rickspencer3> tseliot, can we line up known bugs with a list of changes in these new version, and simply identify potential cherry picks?
[17:55] <tseliot> rickspencer3: sure, I can do that and I can also see what can't be cherrypicked and/or backported
[17:55] <tseliot> so as to see what we're missing
[17:55] <seb128> tseliot, when did you get the ack?
[17:55] <tseliot> if we don't upgrade
[17:56] <tseliot> seb128: it wasn't me
[17:56] <rickspencer3> ok, I think we need to do some more analysis here
[17:56] <seb128> "you" being whoever asked for it
[17:56] <tseliot> we had that when we upgraded to 7.6
[17:56] <asac> what kind of mesa ack? thought we just said we dont want to upgrade ot latest
[17:56] <rickspencer3> tseliot, pitti asac seb128 how about I send tseliot an email that he can pick up tomorrow, and he can structure some thoughts and data
[17:57] <rickspencer3> and then we can discuss in channel tomorrow afternoon or the next day?
[17:57] <asac> thats good
[17:57] <asac> i am here
[17:57] <tseliot> sure
[17:57]  * rickspencer3 notes tseliot needs to leave in 3 minutes
[17:57] <asac> (afternoon my time)
[17:57] <tseliot> right
[17:57] <seb128> ok
[17:57] <pitti> I think we are pretty much in agreement here, thuogh
[17:57]  * tseliot nods
[17:58] <rickspencer3> pitti, right, in terms of broad approach, but if there are specific changes that we want to make, we should do them asap, and in an organized manner
[17:58] <pitti> right
[17:58] <rickspencer3> ACTION: rickspencer3 to start email thread regarding X cherry picks
[17:59] <rickspencer3> so, moving on
[17:59] <rickspencer3> last thing from me, I'd like to generate a list of changes to the desktop that we know are coming after beta
[17:59]  * rickspencer3 hopes this does not take too long
[17:59]  * pitti eyes #ubuntu-devel and sees more gdm work coming
[17:59]  * tseliot is leaving. Bye bye
[17:59] <pitti> thanks tseliot
[17:59] <rickspencer3> shall we just blurt them out?
[17:59] <asac> tseliot: bye!
[18:00] <rickspencer3> bye tseliot - thanks much
[18:00] <pitti> I told them that we won't have time to work on that ourselves
[18:00] <seb128> tseliot, see you
[18:00] <rickspencer3> pitti, what is it exactly?
[18:01] <pitti> some behavioural change of the user picker in gdm
[18:03] <seb128> shrug
[18:04] <seb128> I wish the design team would ask for changes now and we could focus on fixing bugs in what we have
[18:04] <pitti> seb128: "not"?
[18:05] <rickspencer3> sorry, I got pulled into this discussion on #ubuntu-devel
[18:05]  * asac lurks on -devel too 
[18:05] <seb128> pitti, right
[18:08] <rickspencer3> sorry all
[18:08] <rickspencer3> can we carry on?
[18:09] <seb128> yes please
[18:09] <rickspencer3> besides obviously impending low priority changes to GDM

[18:09] <seb128> we will get GNOME 2.28.1 updates before karmic
[18:09] <rickspencer3> are there any other changes that we see?
[18:09] <rickspencer3> ok
[18:09] <pitti> (and the high-priority ones we have to tackle in gdm, like breaking keyboard layouts..)
[18:09] <rickspencer3> I think the user switching menu in session menu
[18:09] <seb128> we need to get the layout in the launchers menu fixed
[18:10] <pitti> there's some changes to human theme which were already committed by kwwii and ready to upload
[18:10] <seb128> dunno if that relies on new features or just on fixes though
[18:10] <seb128> probably bug fixing
[18:10] <rickspencer3> seb128, just blurt them out, I can filter later
[18:10] <pitti> and we (well, I) need to reintroduce some kind of "alive" indicator in usplash for long livefs boots
[18:10] <seb128> otherwise some of the empathy guys are trying to get msn videochat in
[18:10] <rickspencer3> pitti, is that strictly necessary?
[18:10] <seb128> it would mean updating telepathy-butterfly
[18:10] <rickspencer3> pitti, nm, we can discuss later
[18:10] <pitti> seb128: I saw the bug, but I'm not very convinced based on the feedback
[18:11] <pitti> we don't even have jabber video working well
[18:11] <Amaranth> I thought it was crashy
[18:11] <seb128> pitti, they did set up a ppa and asked for testing now I think
[18:11] <pitti> rickspencer3: well, it just sits there with doing nothing for a minute
[18:11] <rickspencer3> perhaps we should simply hide the video button in empathy until it's working well
[18:11] <pitti> seb128: right, and I read the first piece of feedback
[18:11] <seb128> ok
[18:11] <seb128> let's say it's "no" for karmic
[18:11] <seb128> users can get the update in a ppa
[18:11] <pitti> +1 ^
[18:11] <seb128> and we will get it in shape for ll
[18:11] <pitti> it's not a regression
[18:11] <rickspencer3> pitti, what did yo u+1?
[18:11] <asac> makes sense
[18:12] <pitti> rickspencer3: msn video chat
[18:12] <rickspencer3> so -1 for msn video chat, right?
[18:12] <asac> i acked "_no_ for msn video chat"
[18:12] <pitti> rickspencer3: bug 438762
[18:12] <seb128> rickspencer3, yes, too late, first feedback not good
[18:12] <rickspencer3> k
[18:13] <rickspencer3> any chance we will get Jabber video working well? kenvandine ?
[18:13] <seb128> the splash staying there is confusing
[18:13] <kenvandine> rickspencer3, on my short list of stuff to dig into
[18:13] <kenvandine> so this week
[18:14] <kenvandine> hopefully have a "we can do this" or not by end of week?
[18:14] <rickspencer3> kenvandine, is hiding the video button an option if we can't get *any* video working reliably?
[18:14] <pitti> kenvandine: short or "short"?
[18:14] <kenvandine> rickspencer3, i would think so, but i haven't looked at that yet
[18:14] <rickspencer3> I think having a "crash empathy" button that looks like a video chat button is not too good
[18:14] <kenvandine> "short"
[18:14] <kenvandine> rickspencer3, agreed
[18:14] <pitti> rickspencer3: well, it's more like a dice -- make a video call or crash
[18:14] <kenvandine> i would really think that should be simple
[18:14] <rickspencer3> lol
[18:14] <pitti> if it works, it's surprisingly good
[18:15] <kenvandine> yeah
[18:15] <rickspencer3> maybe the design team can make an icon for that
[18:15] <kenvandine> i am impressed
[18:15] <kenvandine> hehe
[18:15] <kenvandine> roll the dice :)
[18:15] <rickspencer3> seems like something that can be released in an update
[18:15] <rickspencer3> if we get it working
[18:15] <kenvandine> i actually think it is something related to things not getting cleaned up well
[18:15] <pitti> well, but better to fix it for final; three weeks to go..
[18:15] <rickspencer3> so Jabber chat either working, or video button hidden
[18:15] <kenvandine> if you get a clean seesion, restart everything it seems ok
[18:15] <kenvandine> rickspencer3, yes
[18:15] <pitti> it works well when you restart all telepathy stuff, so it's something that piles up bad state over time
[18:16] <rickspencer3> ok, moving on ...
[18:16] <asac> are there meaningfull backtraces?
[18:16] <kenvandine> i have that and some indicator bugs to digg into
[18:16] <rickspencer3> there's the x cherry picks
[18:16] <kenvandine> asac, not specifically, but i have sent logs to upstream
[18:16] <rickspencer3> asac, awe_ nice work on NM, btw ...
[18:16] <rickspencer3> and changes expected there?
[18:16] <asac> i hope not
[18:17] <rickspencer3> great
[18:17] <asac> just a a few refinements ...
[18:17] <awe_> me too
[18:17] <asac> but i have to sit together with upstream and make a roadmap for 0.8 final
[18:17] <awe_> I think just  bug fixes now...
[18:17] <rickspencer3> good news
[18:17] <awe_> asac, let me know when you do...
[18:17] <rickspencer3> asac, mozilla, all done?
[18:17] <asac> yeah
[18:18] <rickspencer3> ok
[18:18] <asac> rickspencer3: in general yes. i will probably add transitional packages for firefox-3.0 after beta so every user gets ffox 3.5 and we can remove 3.0
[18:18] <rickspencer3> good, that's good to know
[18:18] <rickspencer3> ccheney is not here, I think, but is OOo done?
[18:18] <asac> but thats nothing intrusive - and was planned
[18:18] <rickspencer3> asac, ack, thanks
[18:19] <pitti> rickspencer3: there's a workaround for the armel breakage now, thanks to doko
[18:19] <rickspencer3> doko is a hero indeed
[18:19] <pitti> the other RC bug is the broken file dialogs for KDE, no solution tehre yet
[18:19] <rickspencer3> lool must be a big fan now
[18:19] <rickspencer3> ug
[18:20] <rickspencer3> I guess they can role back to the default file dialogs
[18:21] <rickspencer3> good list
[18:21] <rickspencer3> moving on ...
[18:21] <rickspencer3> any other business?
[18:21] <seb128> no
[18:21] <pitti> actions from previous meeting?
[18:21] <rickspencer3> right
[18:21] <asac> not from my side
[18:22] <pitti> https://wiki.ubuntu.com/Bugs/FindRightPackage: TheMuso to update the page for audio
[18:22] <rickspencer3> I'll follow up with Robert and Luke directly for their items
[18:22] <pitti> ok, thanks
[18:22] <pitti> Riddell to clean up Kubuntu/Todo/Karmic
[18:22] <pitti> that needs to happen as well still
[18:23] <rickspencer3> k
[18:23] <pitti> work items aren't going down
[18:23] <rickspencer3> pitti, I haven't dived into those, what are the open items?
[18:23] <rickspencer3> is it still mostly mozilla and kubuntu?
[18:23] <pitti> rickspencer3: neither did I, Riddell just said that there are a lot which should be closed
[18:24] <pitti> rickspencer3: oh, generally? mostly kubuntu, and then some testing/qa/release notes stuff
[18:24] <rickspencer3> ok
[18:24] <asac> mozilla is cleanup only stuff left afaict
[18:24] <rickspencer3> I'll follow up up on those
[18:24] <asac> that was always planned for post beta
[18:24] <rickspencer3> could everyone please look over their work items and close or postpone as appropriate?
[18:24] <pitti> yeah, those are fine
[18:25] <rickspencer3> in general, there seem to be few enough open that I can follow them on an individual basis, but haven't had the time to dig in
[18:26] <rickspencer3> okay
[18:26] <rickspencer3> that's it then
[18:26]  * rickspencer3 taps gavel
[18:26] <pitti> thanks everyone
[18:26] <asac> can we put the link for release critical bugs on the wiki page
[18:26] <asac> maybe under "Remaining Work/Known Major bugs"?
[18:28] <asac> anyway. thx
[18:28] <pitti> we already have DesktopTeam/ReleaseStatus for that, though
[18:28] <Riddell> sorry folks, I entirely forgot the desktop meeting
[18:31] <asac> pitti: ok. i will check that page. but i dont see this milestone link on it
[18:31] <pitti> asac: oh, just the link? that's fine, I misread
[18:31] <asac> yeah. that magic link i never remember how to find/construct ;)
[18:34] <chrisccoulson> pitti - i just pushed the system-tools-backends change to bzr now
[18:34] <pitti> chrisccoulson: yay you
[18:40] <chrisccoulson> what is booting meant to look like in karmic now anyway? i'm not really sure if i'm meant to see before xsplash
[18:40] <chrisccoulson> i just see some lines of text at the moment
[18:42] <pitti> that's how it's supposed to look for fast boots
[18:42] <pitti> (without the text, though)
[18:42] <pitti> for slower boots you should get usplash, but that's not working yet
[18:42] <chrisccoulson> ah, that's what i was wondering
[18:43] <chrisccoulson> the text i see are just from fsck and some other services starting normally
[18:45] <pitti> seb128: btw, http://staging.launchpadlibrarian.net/32537683/XsessionErrors.txt
[18:45]  * seb128 hugs pitti
[18:45] <seb128> pitti, I noticed the bug activity ;-)
[18:46] <kenvandine> i am amazed how fast my boots are in kvm
[18:55] <asac> is codec search triggered randomly by rhythmbox supposed to be fixed?
[18:56]  * asac remembers some codec issuse being discussed
[18:57] <seb128> asac, some of the issues are fixed some not
[18:57] <asac> seb128: my issue is if i try to play a dead stream it triggers it
[18:57] <asac> like invalid songs on last.fm
[19:06] <seb128> asac, not known I think
[19:06] <asac> seb128: where the other bugs gstreamer or rhythmbox fixes?
[19:06] <asac> were
[19:07] <seb128> both but usually gstreamer
[19:07] <dobey> mac_v: ping :)
[19:07] <seb128> but other bugs are local files and broken mimetype detection
[19:08] <asac> hmm
[19:08] <asac> broken mimetype detection feels like it could also happen for bad streams
[19:08] <pitti> seb128, asac: epiphany-webkit wants to go to main since it's a b-dep of epiphany-extensions
[19:09] <pitti> should e-extensions be demoted as well?
[19:09] <asac> pitti: i unseeded both
[19:09] <asac> after discussion with slangasek
[19:09] <seb128> pitti, isn't that what asac fixed today?
[19:09] <asac> yes thats the consequence
[19:09] <pitti> ah, then I guess we just need to rebuild ubuntu-meta
[19:09] <pitti> hm, although, it shouldn't be in desktop, we don't install it by default
[19:09] <asac> pitti: i only found them in dvd seeds
[19:09] <mac_v> dobey: pong :)
[19:10] <pitti> asac: so I can demote e-extensions now?
[19:10] <asac> yes. ubuntu-desktop sounds wrong
[19:10] <asac> yes
[19:10] <dobey> mac_v: hey. djsiegel said i should bug you about getting some icons in humanity
[19:11] <mac_v> dobey: sure .. if something is wrong ;) which icons?
[19:11] <pitti> asac: done, thanks
[19:11] <dobey> mac_v: https://code.edge.launchpad.net/~dobey/humanity/ubuntuone-icons/+merge/12605 <- these :)
[19:11] <asac> great
[19:11] <asac> pitti: it was dep wait. will it automatically trigger rebuild?
[19:11] <pitti> asac: yes, once it's published in universe
[19:12] <asac> cool
[19:12]  * mac_v checks
[19:12] <dobey> mac_v: since they are humanity style and don't fit well with other themes, i think they belong in humanity rather than upstream. they need to be done for other sizes as well, and some of them also need to be ported over for the new humanity-dark i guess
[19:12] <seb128> asac, btw do you plan to sponsor 2.28 or did already?
[19:13] <asac> seb128: i am working with didrocks on it yes.
[19:13] <seb128> ok thanks
[19:14] <asac> now that everything is in universe we can just upload
[19:14] <asac> was a bit in the limbo if we would fall under beta freeze or not ;)
[19:23] <mac_v> dobey: only 2 icons?
[19:23] <dobey> mac_v: no, there are 5
[19:23] <dobey> mac_v: 2 in status/24, 3 in emblems/24
[19:23] <mac_v> i see two in emblems , ...
[19:23] <mac_v> ah!
[19:24] <dobey> bzr st should show them all :)
[19:24] <mac_v> dobey: this /24/emblem-ubuntuon-synchronized.svg can be a symlink
[19:25] <dobey> symlink to what?
[19:25] <mac_v> dobey: btw , did you make these?
[19:25] <dobey> hrmm
[19:25] <dobey> ah crap
[19:25] <mac_v> symlink to >/actions/24/dialog-apply.svg
[19:25] <dobey> i made a typo
[19:26] <dobey> mac_v: no, daniel made them i believe
[19:26] <mac_v> dobey:  ok
[19:26] <mac_v> dislog apply is the same icon
[19:26] <mac_v> dialog*
[19:27] <dobey> oh
[19:27] <dobey> it probably shouldn't be
[19:28] <mac_v> dobey: lol , why did djsiegel send  Dan's  icons to you to add them back in his own theme ;p ... or was it for a review
[19:28] <djsiegel> mac_v: I was told to get them to the u1 guys!
[19:29] <dobey> mac_v: i didn't know the icons were going to be humanity style until i got them :)
[19:29] <mac_v> hehe ;)
[19:29] <mac_v> djsiegel: dobey: the present color itself needs edit , since i have now increased the contrast
[19:30] <mac_v> for the greyscale icons^
[19:30] <dobey> mac_v: feel free to merge them in and then update that if you want :)
[19:31] <mac_v> dobey: ok , sure , thanks ...
[19:31] <mac_v> but what about the emblem-ubuntuon-synchronized.svg ? being similar to dialog apply?
[19:31] <dobey> mac_v: humanity style isn't my area of expertise... tango is :)
[19:31] <mac_v> :)
[19:31] <dobey> mac_v: it probably should be something other than what dialog-{apply,ok,whatever} is
[19:32] <mac_v> djsiegel: ^
[19:32] <djsiegel> mac_v: which icon?
[19:32] <mac_v> djsiegel: right now.. emblem-ubuntuon-synchronized.svg  and dialog-apply icons are similar
[19:32] <djsiegel> oh, the check mark
[19:32] <dobey> djsiegel: the green check
[19:32] <djsiegel> yes, and why is that a problem?
[19:32] <mac_v> no probs  , just checking ;)
[19:32] <djsiegel> will users think that that emblem is turning their files into apply buttons?
[19:32] <djsiegel> I don't see a problem
[19:33] <dobey> well it dilutes the metaphor. it's not "applying" anything to the file :)
[19:33] <seb128> who else there thinks that selected buttons seem to be pressed now?
[19:33] <seb128> who else there thinks that selected buttons seem to be pressed now in karmic?
[19:33] <dobey> but i'm not fussed about it
[19:33] <djsiegel> yes, maybe the metaphor is hurt but I don't think users will ber :)
[19:33] <mac_v> ;)
[19:33] <djsiegel> and Ubuntu is for human beings, not metaphors :)
[19:34] <dobey> there are much worse issues with the way emblems work anyway
[19:34] <djsiegel> for reals
[19:34] <seb128> Amaranth, wb
[19:34] <Amaranth> well this sucks
[19:34] <Amaranth> commented out the only line I could find that activated the row, luck
[19:35] <Amaranth> added a line that should deactivate the row after the user list loads, no luck
[19:35] <Amaranth> diving through layers of custom widgets, no fun
[19:35] <Amaranth> err, first one should be no luck :P
[19:36] <Amaranth> that was the hour beuno said it would take
[19:36] <Amaranth> maybe I'll look at it again later when my blood pressure goes down
[19:37] <seb128> Amaranth, I would advice adding a button rather
[19:37] <seb128> that should be much easier
[19:38] <seb128> just connect the button to the same signal than enter
[19:38] <Amaranth> seb128: we're past UI freeze and string freeze, no?
[19:38] <seb128> well you can discuss than having no selection or one is an ui change
[19:38] <seb128> and we did add the button for power actions some days ago
[19:39] <Amaranth> it's a UI change that doesn't affect documentation
[19:39] <seb128> so yes, but if it's worth it we will get approval
[19:39] <seb128> well it's up to you, but if knowing the gdm codebase you failed in one hour nobody in the team will look at it
[19:40] <seb128> so either you want to keep trying this way
[19:40] <seb128> or we suggest the button or next cycle
[19:40] <Amaranth> yeah, I know the daemon side :P
[19:40] <mac_v> dobey: hm... i wanted to ask , the icons which are used in the notification area are not consistently named , for example bluetooth uses the app icon labeled "bluetooth" , icons for device are used in the area too... shouldnt the labels be devicename-status ? can some consistency be done for that?
[19:40] <Amaranth> I'll look at it again in a bit, blowing things up in GTA4 now :P
[19:40] <rickspencer3> seb128> who else there thinks that selected buttons seem to be pressed now in karmic?
[19:40]  * rickspencer3 does
[19:41] <seb128> rickspencer3-afk, thanks ;-)
[19:41] <dobey> mac_v: hrmm?
[19:41] <rickspencer3> seb128, are changes expected to this in the theme update that is coming?
[19:42] <dobey> mac_v: i don't think that makes much sense. most of the icons on my panel have nothing to do with devices even.
[19:42] <seb128> rickspencer3-afk, I don't know I will check tomorrow
[19:42] <dobey> mac_v: though there should be consistency, i don't think it's specific enough to devices to say it has to be device-foo
[19:42] <mac_v> dobey: the bluetooth icon is from the app folder
[19:43] <mac_v> and is the same app icon
[19:43] <dobey> yes
[19:43] <dobey> i didn't say there aren't problems
[19:43] <mac_v> ;)
[19:44] <mac_v> alteast of the icons are placed in one location, it would be easier while making them :)
[19:44] <dobey> but i don't think your suggestion is going to solve them :)
[19:44] <mac_v> s/of/if
[19:44] <dobey> well
[19:44] <dobey> that's what single canvas workflow is for
[19:45] <mac_v> yeah , but apps dont follow :(
[19:45] <dobey> apps?
[19:45] <mac_v> nm applet , or the music apps
[19:45] <asac> what does "single canvas workflow" involved
[19:45] <asac> involve
[19:45] <asac> and where is that documented?
[19:46] <dobey> look at the one-canvas branch of gnome-icon-theme in git
[19:46] <dobey> or the ubuntuone icons in ubuntuone-client trunk
[19:46] <asac> you cant expect apps to follow something that is in git of gnome-icon-theme ;)
[19:47] <dobey> "humanity" isn't an app
[19:47] <dobey> it's an icon theme
[19:47] <dobey> which is what we were talking about, i thought
[19:47] <asac> 20:44 < dobey> that's what single canvas workflow is for
[19:47] <asac> 20:45 < mac_v> yeah , but apps dont follow :(
[19:47] <mac_v> dobey: no, i meant in general , fo apps
[19:47] <mac_v> for*
[19:47] <asac> i think all thi sstarted because nm-applet and bluetooth are supposed to have different icons for tray vs. app
[19:48] <mac_v> ;)
[19:48] <dobey> apps using the theme incorrectly is app-specific problem. specifying status icon names isn't going to fix that
[19:48] <asac> just wanted to understand what guideline those apps are breaching
[19:48] <mac_v> asac: but even other apps , rhythmbox also do stuff similar to nm applet
[19:48] <asac> otherwise its hard to argue upstream ... just saying: "ubuntu design team came up with this great idea of using different colored icons in tray than in apps" wont fly.
[19:48] <dobey> well nm-applet does some dumb things with how it installs the icons
[19:49] <dobey> nm-applet doesn't have an app icon anyway? it's not in my menus anywhere...
[19:49] <mac_v> dobey: it uses nm-device-wired :/
[19:49] <dobey> the problem is someone said "oh lets make tray icons be greyscale only"
[19:50] <asac> right
[19:50] <dobey> which of course is never going to work 100%
[19:50] <asac> thjats what i am seeing
[19:50] <asac> but i was told that it is arguably a bug that you cannot do that
[19:50] <dobey> it doesn't work in OSX either
[19:50] <asac> want to understand the rational so i can make a point upstream
[19:50] <dobey> yes, arguably it is :)
[19:50] <asac> what would be the argument ?
[19:50] <dobey> but nobody has ever really worked out all the issues with doing it
[19:51] <dobey> asac: well someone is arguing "we can't do that" obviously :)
[19:51] <asac> ok so given how much this road is blocked i wonder if we should still pursue the greyscale icons in tray
[19:52] <dobey> well since there's no way to guarantee what is and isn't there, i would say it's probably not really worth the trouble
[19:52] <asac> dobey: what i have wished for would be some gnome best practices or so that says: "use different icon names for stuff inside your app and stuff that is displayed outside (like tray etc.)
[19:52] <mac_v> asac: greyscale icons work now , there are no probs there ,  i figured out which icon is used where,and make the greyscale/color icon accordingly... but the naming is still messed up
[19:52] <mac_v> which size*
[19:52] <dobey> asac: we can work on getting something like that together, but it's a lot more work
[19:52] <asac> mac_v: well. now nm-applet uses the greyscale icons everywhere
[19:53] <asac> not just in tray
[19:53] <asac> or did you fix that?
[19:53] <dobey> mac_v: it works until you run something else
[19:53] <mac_v> asac: fixed :)
[19:53] <dobey> mac_v: like... skype
[19:53] <dobey> mac_v: or some app under wine
[19:53] <asac> mac_v: why didnt you tell me? i was about to do a big argument upstream to change icon names
[19:53] <mac_v> dobey: for this cycle we are restricting to only system icon and not doing app icons
[19:53] <asac> ok so there is no action needed?
[19:53] <asac> neither for gnome-bluetooth nor nm-applet?
[19:53] <mac_v> asac: action still needed
[19:54] <asac> i mean from code side
[19:54] <mac_v> the bluetooth icon is still messed up
[19:54] <asac> what does "messed up" mean?
[19:54] <mac_v> asac: it uses 24px icon in both panel and menu
[19:54] <mac_v> app icon*
[19:54] <asac> ok. but you can have different icon for tray and app?
[19:55] <dobey> well
[19:55] <dobey> you'd need to patch something
[19:55] <asac> what i dont understand is how you fixed the nm-applet having greyscale in editor
[19:55] <mac_v> asac: right now we cant , so the menu also uses the greysacel icon
[19:55] <asac> as you found out it uses the same icons. even the same memory
[19:55] <asac> from what i can see
[19:55] <mac_v> asac: the nm editor uses 16px icons while the panel uses 24px
[19:55] <asac> ok. feels like a hacky workaround
[19:55] <dobey> mac_v: change your panel height to 18px :)
[19:56] <asac> relying on different sizes ;)
[19:56] <mac_v> asac: exactly right now i have hacked ;)
[19:56] <asac> yes. so greyscale will not be great
[19:56] <mac_v> just working around the problem
[19:56] <asac> current situation for me is: half of the apps in tray have greyscale
[19:56] <asac> the rest is still colorful
[19:56] <asac> all apps would have needed to be fixed ;) ... now it looks less polished then before for me ;)
[19:57] <mac_v> dobey: i have given the icon sufficient padding so there are no problems untill 19px ;)
[19:57] <mac_v> dobey: asac: for lucid UX is planning on runtime desaturation of icons
[19:57] <dobey> mac_v: if you decrease the panel size, it should get the icon at the smaller size, so your "hack" would break
[19:58] <dobey> runtime desaturation is an even worse hack
[19:58] <dobey> then it looks like the icons are just disabled
[19:58] <mac_v> hehe ;)
[19:58] <asac> desaturation by whom?
[19:58] <asac> if its the panel thats ok imo
[19:58] <mac_v> by the notification area
[19:58] <asac> and much better than asking us to duplicate all icons upstream
[19:59] <dobey> eh, it's the same general downstream branding problem that always has been
[19:59] <mac_v> its already being done in UNR , for the inactive window list icons
[20:00] <mac_v> asac: but still a separate label would be ideal ;)
[20:00] <asac> yes. but unless there is an official gnome guideline it doesnt make sense to pursue that for individual apps
[20:01] <asac> once we have such a guidline, we need to do a mass bug filing
[20:01] <dobey> well nobody has ever enumerated all the issues
[20:01] <mac_v> yeah  , thats why someone must make them... *hint* dobey  ;)
[20:01] <asac> (not necessarily gnome ... freedesktop i guess)
[20:01] <dobey> until someone does, you're not going to get anywhere
[20:02] <dobey> asac: freedesktop probably won't do, because it gets into the area of specifying design, which would be conflicting across desktops
[20:02] <asac> for me the current issue is confined to: use different icon names for things that are displayed outside your app ;)
[20:02] <dobey> (though we definitely ONE single hig/design target for all the desktop world)
[20:02] <dobey> such a mess it is
[20:02] <asac> dobey: how is it design to ask for using different labels for things not displayed within the app?
[20:03] <dobey> some cases it really doesn't make sense to do that
[20:04] <dobey> like i said, it's a lot more complicated than it seems
[20:04] <dobey> and nobody has enumerated the issues
[20:04] <asac> good
[20:04] <asac> then i will reject any such request ;)
[20:04] <mac_v> asac: noooooooo :(
[20:05] <asac> i dont see why duplicating nm-applet icons is something worse the effort and arguments if its not going to be fixed anytime soon for all apps
[20:06] <mac_v> asac: lets fix what we can , other we'll [or i'll ] pester later ;p
[20:06] <mac_v> others*
[20:06] <asac> its not a fix if there is not a line/best practice
[20:07] <mac_v> hmm.. there needs to be a best practice somewhere... who can bring that ?
[20:07] <asac> project that you are some random upstream guy. think what would be needed to convince you that something makes sense.
[20:08] <asac> and be three time as picky and stubborn as you would be on your own
[20:08] <asac> then you have found what we need ;)
[20:08] <mac_v> hmm... ;)
[20:09] <asac> it probably needs to come from some independent authority
[20:09]  * dobey hides
[20:09] <asac> like freedesktop/gnome
[20:10] <mac_v> tries to drag dobey back in ;p
[20:10] <dobey> gnome is so not an independent authority
[20:11] <dobey> just ask the KDE guys :P
[20:11] <mac_v> dobey: pls give asac some convincing points to argue upstream
[20:11] <dobey> mac_v: make me a list of all the issues.
[20:11] <asac> gnome would be enough to convince folks with gtk/gnome apps
[20:11] <dobey> well
[20:12] <dobey> i am enough to convince gtk/gnoem people
[20:12] <asac> across the board you need freedesktop or something else toolkit agnostic
[20:12] <dobey> and i'm mostly enough to convince the kde people
[20:13] <dobey> but i don't know what all the issues are exactly
[20:13] <asac> yes, but you have idea what to do :)
[20:13] <dobey> i know it's a very hard problem
[20:13] <dobey> and nobody is telling me what all the issues are
[20:13] <asac> our current issue is tray/status vs. app icons ;)
[20:13] <dobey> yes, but like i said, there isn't one obvious solution that works for everyone
[20:14] <dobey> or i'm sure we'd have done it already :)
[20:14] <Amaranth> yay, failsafe patches got in
[20:14] <mac_v> :(
[20:14] <dobey> it doesn't make sense to have the exact same icon in 2 files, just because a few people want to make one instance of it be a different style
[20:15] <dobey> (and symlinks are not the answer to that)
[20:15] <asac> no. you need a hierarchy ;)
[20:15] <asac> rather fallback chain
[20:15] <dobey> we have that
[20:16] <asac> good. that means that the icon names are not the problem ;)
[20:16] <Amaranth> right, so the tray icon code can try to use gnome-bluetooth-tray and if that isn't found it should fall back to gnome-bluetooth
[20:16] <asac> how does the fallback chain work?
[20:16] <dobey> some of them are
[20:16] <dobey> like networkmanager icons
[20:16] <asac> lets say i want asac-supericon
[20:16] <dobey> asac: see the icon naming spec
[20:17] <asac> and want to just ship one icon, but will allow themeres to use different ones in place1 and 2
[20:17] <Amaranth> dobey: Is what I said correct?
[20:17] <dobey> Amaranth: somewhat
[20:17] <asac> dobey: i won't wade through a spec if you are the guy that could convince upstreams ;)
[20:17] <Amaranth> that's the only thing I remember from the discussions on xdg-list :P
[20:18] <asac> dobey: someone should tell me concrete issues with the networkmanager icons and give solutions
[20:18] <mac_v> dobey: there are apps which simply dump icons in the tray , just to indicate "I'm running" rather "I'm in active/inactive state" and such apps just use the app icon... this is wrong , if the icon is present in the notification area , it should be a representative of the state of the device
[20:18] <asac> if the problem is understood it must be easy to do that
[20:19] <dobey> mac_v: it's not wrong. why is it wrong?
[20:19] <mac_v> simply displaying an app icon is not a notification...
[20:19] <dobey> mac_v: everything in the tray isn't a device.
[20:19] <mac_v> right ,
[20:19] <dobey> mac_v: because someone decided to call it a "notification area" doesn't mean notifications show up there
[20:20] <dobey> mac_v: *notifications* show up about 3 feet from the tray on my monitor :)
[20:20] <mac_v> rhythmbox uses the app icons too m but rather it would be more informative , if it uses a Play or pause icon .... simply displaying the app icon conveys no meaning
[20:21] <dobey> well
[20:21] <dobey> what if i have rhythmbox, and something else that plays media, and they both have tray icons?
[20:21] <dobey> they both should have the same icon?
[20:21] <dobey> that doesn't make sense either
[20:21] <dobey> it needs more context
[20:21] <mac_v> dobey: each app has an icon overlay
[20:21] <mac_v> of the state
[20:21] <dobey> like, skype and pidgin shouldn't use the same icons
[20:22] <dobey> would look silly to have 2 of the same icon in the tray
[20:22] <mac_v> no i think you got me wrong
[20:22] <dobey> so it should have the app icon?
[20:22] <dobey> and then a tiny little emblem you can barely see?
[20:22] <mac_v> if rhythmbox is running , use rhythmbox icon with an overlay of play , if paused pause... similarly for other apps
[20:23] <dobey> i don't think that makes sense
[20:23] <mac_v> not tiny but visible
[20:23] <dobey> the main issue isn't even the icons
[20:23] <dobey> it's the interaction model
[20:23] <mac_v> it would make more sense than simply displaying the app icon ;)
[20:24] <dobey> it doesn't just display the app icon
[20:24] <dobey> it has state icons based around the app icon
[20:24] <dobey> granted, the app icon isn't particularly interesting
[20:25] <dobey> it could certainly use improvements
[20:25] <dobey> but i don't think overlays are the answer
[20:25] <mac_v> yes
[20:25] <mac_v> maybe not. ;)
[20:25] <dobey> just like body kits don't make honda civics look any cooler
[20:25] <dobey> :)
[20:25] <mac_v> but some improvement in the naming will allow better meaningful icons
[20:27] <dobey> well
[20:27] <dobey> not especially
[20:27] <dobey> this sort of thing works ok in OSX because they have a separation between application status, and system status
[20:28] <mac_v> why cant it be done here?
[20:28] <dobey> though some apps abuse that (like skype and dropbox)
[20:28] <dobey> mac_v: i didn't say it couldn't be. i said it's a lot harder than you keep expecting it to be
[20:28] <mac_v> or maybe  .. separate sys and app status?
[20:28] <dobey> because we shove everything in one place
[20:28] <mac_v> dobey: yea ;)
[20:29] <dobey> which isn't the case on osx, which is what you're trying to copy :)
[20:29] <mac_v> its hard , thats why we need you to convince others ;)
[20:29] <dobey> changing the names around isn't going to fix the real problem though
[20:30] <mac_v> surely not , but can reduce the nonsensical app icons
[20:30] <dobey> it's not going to get rid of the app icons
[20:30] <asac> ArneGoetje: did we have a bug for the broken country code langpacks?
[20:31] <dobey> it's just going to make developers do more work
[20:31] <asac> hmm guess he is asleep
[20:31] <dobey> for no special reason other than to accomodate a couple of icon themes that want to make other icons be greyscale :)
[20:31] <mac_v> dobey: its not only for an icon theme , but in general its a problem
[20:32] <dobey> how is it a problem in general?
[20:32] <dobey> it's only a problem for themes that want to deviate from the default icons
[20:32] <mac_v> not all icons in the notification area , really notify
[20:32] <dobey> huh?
[20:32] <mac_v> they simply exist as duds ;p
[20:33] <dobey> i don't understand what you're trying to say
[20:33] <mac_v> the icons dont convey *any* meaning by simplying displaying the app icon
[20:34] <mac_v> ah well... this is just the age old problem of notification area abuse :(
[20:35] <dobey> i don't understand what is *simply* displaying the app icon?
[20:35] <dobey> afaict, nothing is
[20:36] <mac_v> dobey: ex: bluetooth , it doesnt say connected or syncing or disconnected
[20:37] <mac_v> it just displays a static app icon
[20:38] <dobey> mac_v: and how would that be different if the icon name were different? your theme would show the exact same icon, only the panel would be greyscale, and the prefs menu item would be color, no?
[20:40] <dobey> mac_v: changing the icon name isn't going to change how the status is shown.
[20:40] <dobey> and i don't think the bluetooth tray thingy actually does anything with syncing does it?
[20:41] <dobey> generally speaking, bluetooth icon should probably just not be shown in the tray
[20:41] <mac_v> dobey: no , i'm not asking this for the greyscale icons , but in general for better indication of the notification area , if there are different labels, for ex: bluetooth-active  , bluetooth , syncing , bluetooth-disabled , it would be better to make icons which would convey the meaning and in the end make the tray icons more meaningful
[20:41] <dobey> but that's a design/code problem, and not an icon name issue, from what i can tell from your complaints
[20:42] <dobey> mac_v: it's only useful if the code actually displays that status, which it doesn't do
[20:42] <dobey> and i think 'bluetooth' is too general for that anyway
[20:42] <mac_v> if such icons are not able to convey , they should not use the notification area
[20:42] <dobey> there are more specific things that would deal with that better
[20:45] <mac_v> so there should be a guideline saying , if icon can convey adequate meaning , use the tray , or else the icon should not use the tray
[20:45] <dobey> i don't think guidelines should be that vague
[20:46] <dobey> guidelines should be objective. "adequate meaning" is very subjective
[20:46] <mac_v>  better guidelines , but you get the idea ;)
[20:46] <dobey> and it's hard to make that objective, because it's more something that needs to be determined on a per-app basis in the design of that app
[20:48] <Amaranth> it builds! ship it!
[20:48] <mac_v> dobey: dobey: it can be done , split the apps in categories > system icons ,  music players , chat clients , ...  and making a guideline for each category , should work
[20:49]  * Amaranth misses gdmflexiserver -n
[20:49] <dobey> mac_v: like i said, i don't think it's that simple :)
[20:49] <mac_v> surely not ;)
[20:50] <mac_v> dobey: but at some point *someone* has to try as hard as possible
[20:50] <mac_v> brainstorming it can lead to a solution
[20:51] <mac_v> its just no one cared for it , till now
[20:52]  * mac_v placing burden on dobey's shoulders
[20:52] <mac_v> ;)
[20:52] <dobey> rhythmbox shouldn't have a tray icon.
[20:53] <dobey> doh. and there's a pixel on my monitor that's gone wrong
[20:53] <mac_v> it could be used to minimize the icon , since it can be an app running for long hours and displaying a window might not be needed
[20:53] <mac_v> rhythmbox^
[20:54] <mac_v>  to minimize app to the icon*
[20:54] <dobey> that's a general desktop interaction problem
[20:54]  * kenvandine doesn't think you really need the icon to do that
[20:54] <mac_v> oh
[20:54] <kenvandine> just a myth :)
[20:54] <dobey> it should be minimized and be done with it
[20:54] <dobey> kenvandine: you don't
[20:54] <dobey> it would be much better in the OSX dock though
[20:55] <mac_v> kenvandine: how you you do otherwise?
[20:55] <dobey> because it'd designed for that
[20:55] <dobey> mac_v: just minimize the window and not worry about it
[20:55] <seb128> you need an another way to have it available but not in the taskslist
[20:55] <mac_v> dobey: lol ;)
[20:55] <kenvandine> i am biased though... i hate icons in the notification area
[20:55] <mac_v> +1 to seb128
[20:55] <kenvandine> i am also not a fan of the task list
[20:55] <dobey> seb128: the tray icon is the wrong answer to that
[20:55] <kenvandine> i am fine with the window close and still running... and no icon
[20:56] <seb128> I didn't say it was the right one
[20:56] <kenvandine> if you want it again, you restart it which just raises the window
[20:56] <seb128> I just said you need an another one
[20:56] <mac_v> kenvandine: then you cant access it :(
[20:56] <seb128> wb Amaranth
[20:56] <kenvandine> mac_v, why?
[20:56] <dobey> the osx dock is a much better answer to that
[20:56] <Amaranth> yay I've got a button that doesn't do anything
[20:56] <dobey> and i don't see why you need to not have it in the task list anyway
[20:56]  * Amaranth will try again tomorrow
[20:56] <mac_v> if there is no icon or window list displayed  , where can you bring back the app from?
[20:56] <dobey> it doesn't make any sense for it to not be there
[20:56] <dobey> it is in fact, a task
[20:57] <kenvandine> mac_v, the menu... or gnome-do
[20:57] <kenvandine> etc
[20:57] <dobey> if you don't want windows in your task list, get rid of the task list :)
[20:57] <seb128> kenvandine, because the menu is not quick to access
[20:57] <seb128> kenvandine, the same reason why the indicator messaging menu sucks
[20:57] <kenvandine> i use gnome-do :)
[20:57] <seb128> gnome-do is a geek tool
[20:57] <dobey> i still have yet to have someone tell me what gnome-do actually *does*
[20:57] <mac_v> kenvandine: menu or gnome do.. is also similar to window list
[20:58] <mac_v> lol
[20:58] <seb128> dobey, it allows geek to use the keyboard to do extra things
[20:58] <kenvandine> dobey, it launches applications
[20:58] <kenvandine> mac_v, my point is, if there is no window and the app is running
[20:58] <dobey> so it's redundancy, ok
[20:58] <kenvandine> running the app again should start a new instance, but raise the existing one
[20:58] <kenvandine> dobey, it's cooler :)
[20:59] <dobey> kenvandine: by cooler, you mean it has shiny effects?
[20:59] <kenvandine> although it has gotten kind of buggy and i use it less
[20:59] <mac_v> kenvandine: but that can be done for us , is that a good design , will new users want to type commands to bring up the apps?  users always want click and go ;)
[20:59] <dobey> but still, i'm sure it's not an ideal interaction model for the desktop
[20:59] <seb128> kenvandine, if there is no ui clue that a thing is running you fail
[21:00] <dobey> gnome-system-monitor is fail
[21:01] <dobey> as a user, how do i know what is what when i look at the "Processes" tab?
[21:01] <chrisccoulson> gnome-system-monitor is definately fail for me right now
[21:01] <chrisccoulson> because it doesn't even work ;)
[21:01] <dobey> it's also probably very useful for me to click "End Process" on "gconfd-2"
[21:02] <dobey> or "bonobo-activation-server"
[21:05] <Amaranth> gnome-do is the kind of thing you have to use for a bit to understand the point
[21:05] <seb128> still a geek tool
[21:05] <Amaranth> sure, unless you turn on docky mode
[21:06] <seb128> hum, compiz focus issues with polkit prompt are not really fixed yet
[21:06] <dobey> eh
[21:06] <dobey> i can't even run compiz
[21:06] <dobey> and metacity sucks at focusing new windows
[21:06] <Amaranth> I haven't been able to reproduce since the first git snapshots of 0.8.3
[21:06] <Amaranth> seb128: what app popped up the polkit window that failed?
[21:06] <dobey> of course, compiz still works ok on my old laptop with an i915
[21:06] <mac_v> dobey: why is this labelled without an 'e' /emblem-ubuntuon-synchronized.svg , is this supposed to be 'on' ?
[21:07] <seb128> Amaranth, when installing upgrades with update-manage 2 dialogs are displayed for some reason
[21:07] <mac_v> or one?
[21:07] <dobey> but my nvidia 9500GT desktop can't do it
[21:07] <dobey> mac_v: because it was a typo
[21:07] <Amaranth> seb128: and only one pops up?
[21:07] <seb128> the first one get first prompt with the decorator not colored
[21:07] <mac_v> ah ok
[21:07] <dobey> mac_v: i already fixed it and pushed a new revision
[21:07] <Amaranth> dobey: does it say whitelisted driver not found?
[21:07] <seb128> the second one doesn't get the focus
[21:07] <dobey> Amaranth: no it says "compiz.real crashed"
[21:07] <Amaranth> dobey: yay nvidia
[21:07] <seb128> decorator nor colored = no focused usually
[21:08] <dobey> Amaranth: or yay crappy code that crashes
[21:08] <Amaranth> dobey: unless of course your LANG is empty, then that's our bug
[21:08] <dobey> Amaranth: it worked fine until alpha6 or something
[21:08] <chrisccoulson> seb128 - did you have to authenticate for 2 different actions when you upgraded then?
[21:08] <Amaranth> right, echo $LANG
[21:08] <dobey> [dobey@lunatari:run-tree]: env|grep LANG
[21:08] <dobey> GDM_LANG=en_US.UTF-8
[21:08] <dobey> LANG=en_US.UTF-8
[21:08] <seb128> chrisccoulson, yes
[21:08] <Amaranth> dobey: did you click the little button to send a report? :)
[21:09] <dobey> although i don't know if that is from X or from my terminal login
[21:09] <seb128> the first one is install-package
[21:09] <seb128> the second one upgrade-package
[21:09] <dobey> Amaranth: no, i had to spend 10 minutes fixing all my windows back to how they were, since metacity decided to move them around and resize them :(
[21:09] <chrisccoulson> perhaps aptdaemon should let you do upgrade-package if you can authenticate for install-package
[21:09] <seb128> it should
[21:09] <seb128> but still there is a focus issue
[21:09] <Amaranth> So I need to make update-manager do something that needs to install something and upgrade something
[21:09] <seb128> the first dialog should at least have colored decorations
[21:10] <seb128> in fact it doesn't have get focus
[21:10] <diazamet> How can I automatically run a script after NetworkManager has setup a connection (after coming out of suspend for example)?
[21:10] <seb128> ie keyboard input doesn't go to it, it's just displayed in the first plan
[21:10] <Amaranth> hmm
[21:11] <Amaranth> Hard to debug
[21:11] <seb128> why?
[21:11] <seb128> just run update-manager and click on "upgrade"
[21:11] <Amaranth> works fine
[21:11] <Amaranth> but I don't have anything new to install
[21:12] <seb128> downgrade something
[21:12] <Amaranth> no, I meant new packages
[21:12] <Amaranth> although it just did the on top but no focus thing
[21:12] <seb128> well I've the focus and color issue on the normal dialog
[21:12] <Amaranth> so it's a race condition, goody
[21:12] <asac> diazamet: /etc/NetworkManager/dispatcher.d/
[21:13] <Amaranth> hmm, now it's always doing it
[21:13] <seb128> good ;-)
[21:13] <Amaranth> I have a feeling this is going to be another "can't reproduce when I do a local build" problem
[21:14] <Amaranth> I think my CPU has bug fixing powers
[21:14] <chrisccoulson> seb128 - is the focus issue really solveable? ie, there is no way for the window manager to know where the authentication dialog came from with the existing polkit API, or do i misunderstand the issue?
[21:14] <Amaranth> the mac goodness is trying to make things work better :P
[21:14] <seb128> chrisccoulson, I don't know enough about polkit to say
[21:14] <Amaranth> seb128: it's on top because it sets StateAbove
[21:15] <Amaranth> apparently cornelius never committed that patch, just showed it to me...
[21:15] <asac> chrisccoulson: what focus issue?
[21:15] <Amaranth> he had a patch to make above windows always steal focus
[21:15] <asac> not grabbing global focus=
[21:15] <asac> ?
[21:15] <chrisccoulson> asac - with the policykit authentication dialogs
[21:15] <seb128> chrisccoulson, run update-manager, click on install updates
[21:15] <seb128> the dialog is not focussed as it should
[21:15] <seb128> ups
[21:15] <seb128> asac, ^
[21:15] <chrisccoulson> seb128 - yeah, i've seen the focus issue a couple of times too
[21:15] <asac> chrisccoulson: i figured that. but whats the prob?
[21:16] <seb128> chrisccoulson, that was a reply to asac's question ;-)
[21:16] <Amaranth> "It seems that the daemon died."
[21:16] <Amaranth> neat
[21:16] <Amaranth> let's see if I can reproduce _that_
[21:16] <seb128> asac, the way it works is that the running application should give the event timestamp to the one called
[21:16] <Amaranth> update-manager is now just blanked out and spinning :/
[21:16] <seb128> dunno enough about polkit to know why that's not done there though
[21:17] <chrisccoulson> seb128 - that's the issue, but i don't think that's possible with the current API
[21:17] <Amaranth> metacity clearly has a workaround due to some other app doing buggy things like this
[21:17] <asac> so first i notice is that the install button is slected  somehow
[21:17] <asac> as if it was pressed ;)
[21:17] <seb128> right, that's the new theme
[21:17] <asac> thats focus bg color?
[21:17] <seb128> I need to ask design guys about that
[21:17] <Amaranth> asac: nah, that's just the new theme making default buttons look pressed :P
[21:17] <asac> not even that
[21:18] <seb128> asac, not sure if that's a bug or a design decision
[21:18] <asac> ah ;)
[21:18] <seb128> it's a theme thing
[21:18] <robbiew> bratsche: I think the fix for bug 435522 breaks xsplash behavior on UNR
[21:18] <asac> i think we should make a sliding green error guiding the user to the button rather than making it darker ;)
[21:18] <Amaranth> ok, when aptdaemon crashes update-manager goes bonkers
[21:18] <asac> s/error/arrow/
[21:18] <chrisccoulson> wow, this is the second time in as many weeks that i have to look at xorg code
[21:18] <mclasen> seb128: there is no direct communication between app and polkit-agent with polkit 1.0
[21:18] <mclasen> there is no way for the dialog to be associated with any specific window
[21:18] <bratsche> robbiew: Really?  That's happening in UNR now?
[21:18] <seb128> mclasen, how should the timestamp handle work then?
[21:18] <seb128> g$
[21:18] <chrisccoulson> mcalsen - thats what i thought
[21:18] <seb128> handling
[21:19] <bratsche> robbiew: I mean, *what's* happening in UNR? :)
[21:19] <chrisccoulson> s/mcalsen/mclasen
[21:19] <chrisccoulson> d'oh
[21:19] <robbiew> bratsche: xsplash is not getting the signal
[21:19] <robbiew> so it stays up
[21:19] <asac> seb128: and the problem is a not set timestamp?
[21:19] <asac> (for the auth dialog)
[21:19] <robbiew> I have to switch consoles and kill it
[21:19] <bratsche> Fuck all.
[21:19] <bratsche> Okay, let me try to setup UNR or something.
[21:19] <bratsche> :)
[21:19] <robbiew> works on desktop though :)
[21:19] <Amaranth> asac: if you click on something then a window with a timestamp of 0 appears focus stealing prevention kicks in because you're interacting with your app
[21:20] <seb128> asac, right, as just said there is no direct communication between the client and the polkit dialog
[21:20]  * Amaranth is too tired to explain correctly
[21:20] <seb128> asac, ie the dialog doesn't get the event timestamp set
[21:20] <robbiew> bratsche: let me know if you need me to provide some log files or run something
[21:20] <chrisccoulson> seb128 - there seems to be some code in the xrandr g-s-d plugin to work around a similar issue with the dialog which appears after applying display configuration
[21:20] <chrisccoulson> the dbus api allows you to specify the window ID of the parent window
[21:20] <seb128> asac, that's the "doesn't steal focus while I'm typing" kicking in there
[21:20] <chrisccoulson> (ie, gnome-display-properties)
[21:20] <asac> hmm ok.
[21:20] <asac> but does it at least have proper association with the parent window? or is that just global?
[21:21] <Amaranth> hmm, lagtastic
[21:21] <seb128> asac, well it's spawned over dbus so "no"
[21:21] <bratsche> robbiew: Do you think you can update your xsplash to what's in trunk?  It fixes some logging output.  Then if you could send me the contents of /var/log/gdm/xsplash.log that would help a lot.
[21:21] <Amaranth> asac: It's a completely independent state above (always on top) window
[21:21] <seb128> asac, but cf what chrisccoulson said, g-s-d has code for that which could maybe be copied
[21:21] <robbiew> bratche: sure
[21:21] <bratsche> robbiew: Awesome, thanks!
[21:22] <mclasen> seb128: thats a somewhat incongruent answer... you can pass xids over dbus; and the old policykit did that
[21:22] <mclasen> but the new one doesn't
[21:22] <asac> yeah
[21:23]  * Amaranth fixes
[21:23] <asac> err ... i am seeing a "Task cannot be monitored or controlled" dialog now
[21:23] <asac> "It seems that the daemon died."
[21:23] <Amaranth> asac: that means aptdaemon crashed
[21:23] <asac> thats what update-manager tells me
[21:23] <asac> ah ;)
[21:23]  * asac never saw that ;)
[21:23] <Amaranth> it does that apparently if you try to use some other window when it's waiting for polkit
[21:24] <asac> yeah. could be i didnt close the dialog
[21:24] <asac> or cancelled
[21:24] <asac> not so sure anymore
[21:24] <bratsche> robbiew: Oh, and I found what was causing that error you were seeing about how it couldn't find libtool.m4 or pkg.m4.  Fixed that this morning, so it should be easier to build now. :)
[21:24] <asac> at least was a timeout thing
[21:24] <robbiew> bratsche: thank gawd! :P
[21:24] <Amaranth> It probably waits a bit then aptdaemon falls over
[21:24] <bratsche> heh
[21:27] <asac> i assume there is a bug?
[21:27] <asac> no need to look up. just want to file ;)
[21:27] <asac> anyway have to get some food and then stop ;)
[21:28] <seb128> asac, have fun see you tomorrow
[21:28] <asac> see you
[21:30] <Amaranth>     if (w->clientLeader == active->clientLeader)
[21:30] <Amaranth>         return TRUE;
[21:31] <Amaranth> that's the code that used to make polkit windows work, wish we could still rely on that :P
[21:36] <chrisccoulson> Amaranth - indeed. i'm not sure what the answer to the current situation is really
[21:36] <Amaranth> building a possible fix right now
[21:36] <chrisccoulson> yeah?
[21:36] <chrisccoulson> how? :)
[21:37] <Amaranth>     if (w->state & CompWindowStateAboveMask)
[21:37] <Amaranth>         return TRUE;
[21:37] <Amaranth> If it's stupid but it works it's not stupid
[21:37] <chrisccoulson> does CompWindowStateAboveMask come from a property on the window?
[21:38] <chrisccoulson> (sorry, i'm not familiar with compiz code)
[21:38] <chrisccoulson> oh, hang on
[21:38] <chrisccoulson> i get it now
[21:38] <Amaranth> yeah, it's what gets set when you tell a window to be always on top
[21:38] <chrisccoulson> does compiz not honor that already?
[21:38] <Amaranth> we're showing these windows on top of everything anything, might as well give them focus
[21:39] <Amaranth> s/anything/already/
[21:39] <Amaranth> bleh
[21:39] <chrisccoulson> yay for xprop!
[21:39] <Amaranth> works :)
[21:44] <Amaranth> I'll give it a day to see what upstream thinks then just stick it in ubuntu
[21:48] <chrisccoulson> yeah, sounds good though!
[21:48]  * chrisccoulson is hating xlib
[21:50] <seb128> chrisccoulson, still fighting gsd?
[21:51] <chrisccoulson> seb128 - yeah
[21:51] <chrisccoulson> i think i know whats happening in bug 404924 though
[21:51] <chrisccoulson> it crashes because the window doesn't exist anymore, but i've been trying to figure out why it gets a BadDrawable rather than a BadWindow
[21:51] <chrisccoulson> and i think i know now
[21:52] <seb128> oh?
[21:52] <chrisccoulson> you can see from the trace that the actual protocol request is 14, which is GetGeometry (and not GetWindowAttributes) like I expected
[21:53] <chrisccoulson> GetGeometry returns BadDrawable if the window doesn't exist
[21:54] <chrisccoulson> so thats another xklavier bug
[21:54] <chrisccoulson> yay \o/
[21:58] <chrisccoulson> seb128 - i'll try and look at the xrandr crash too, but i might not be so successful with that one;)
[21:58] <chrisccoulson> i wish i had some hardware that i could trigger the issue on
[21:58] <seb128> chrisccoulson, is that happening every time on some hardware?
[21:59] <chrisccoulson> the xrandr issue?
[21:59] <seb128> yes
[21:59] <chrisccoulson> i'm not sure about that, but i've never seen it (and it's difficult for me to test with the nvidia binary drivers anyway)
[22:02] <chrisccoulson> i don't know how people trigger these crashes. the window that triggers the crash in xklavier code must have been on the display for a very short period of time
[22:02] <chrisccoulson> ive never been able to recreate it
[22:03] <chrisccoulson> but it seems other people seem to be able to quite easily
[22:03] <seb128> could it be that they close it by typing by mistake or something?
[22:03] <seb128> ie dialog stealing focus and closed before they notice
[22:04] <chrisccoulson> seb128 - possibly. but the sequence of events is that gnome-settings-daemon gets notified of a new window, and the window has disappeared again before calling XGetWindowAttributes
[22:04] <chrisccoulson> i suppose g-s-d could get pre-empted though
[22:04] <chrisccoulson> and the window could disappear in between
[22:04] <seb128> it's weird
[22:05] <chrisccoulson> it is
[22:06] <chrisccoulson> i wish xklavier would cache window properties rather than repeatedly doing X calls to fetch the same information
[22:19] <robbiew> bratsche: is there a special way to build the xsplash in trunk?  I can build it, but nothing happens when I run it..that is no graphic.  However, the logfile is created
[22:20] <robbiew> last message is a WRN: Unable to call to request name. You probably don't have sufficient privileges.
[22:23] <Amaranth> robbiew: sudo -u gdm xsplash
[22:24] <robbiew> thnx
[22:26] <bratsche> robbiew: If that doesn't work, you need to configure using --with-user=gdm
[22:27] <seb128> Laney, who moved the f-spot rules away from cdbs? ;-)
[22:27] <Laney> we did that ages ago
[22:27] <Laney> is there a problem?
[22:27] <seb128> well jaunty was still using it
[22:28] <Laney> fsvo ages
[22:28] <seb128> yes, broken translations because intltool-update --pot is not called
[22:28] <seb128> yes, broken translations because intltool-update --pot is not called
[22:28] <seb128> ups
[22:28] <seb128> gnome.mk used to do that for us
[22:30] <Laney> what do other packages do?
[22:30] <seb128> Laney, it depends on intltool already do you think you could add a cd po; intltool-update --pot
[22:30] <Laney> I don't know about translations to be honest, not sure why this is needed
[22:30] <seb128> Laney, the one not using cdbs? they get that change in debian it costs nothing or they have an ubuntu change
[22:31] <Laney> oh is this not needed in debian?
[22:31] <seb128> Laney, no, it's languagepack thing
[22:31] <Laney> ok
[22:31] <Laney> wouldn't it be appropriate for a debhelper change?
[22:31] <seb128> intltool-update generates the translation template
[22:31] <seb128> which is imported in rosetta at upload
[22:32] <seb128> we probably need a gnome class or some equivalent in dh7
[22:32] <seb128> but that's not going to happen for karmic now
[22:32] <Laney> sure
[22:32] <seb128> it's just adding a "cd po; intltool-update --pot"
[22:32] <seb128> in the rules
[22:33] <Laney> I'm just thinking of abstractions
[22:33] <Laney> I don't mind adding it if it doesn't do anything in debian
[22:33] <seb128> it will write the pot in the po directory
[22:33] <seb128> which is a text file
[22:33] <seb128> you might want to clean it in the clean target too not sure if make clean does it
[22:34] <seb128> that takes almost no time
[22:34] <seb128> so it's fine for a debian build
[22:34] <seb128> I can have a look and give you a debdiff if you want
[22:34] <Laney> sure
[22:34] <seb128> ok, will do
[22:35] <seb128> I'm not fluent with dh7 yet though
[22:35] <Laney> thanks
[22:35] <seb128> but it's a good opportunity to have a look ;-)
[22:36] <Laney> at which part of the build should it go?
[22:36] <seb128> whenever you want
[22:36] <seb128> it can be run before or after build
[22:36] <seb128> you want to run it after applying patches though in case they change strings
[22:36] <Laney> ok just put it in override_dh_install then
[22:37] <seb128> ok, I will test build that and give you a debdiff, thanks
[22:37] <Laney> cool thanks
[22:56]  * seb128 is playing with beta iso, seems to be working great
[23:19] <kwwii> https://bugs.launchpad.net/bugs/422511 <- w00t, patched ;)
[23:20] <kwwii> seb128: at the end of that bug there is a patch, any chance we could get that in karmic?
[23:21] <seb128> yes but not before beta though
[23:21] <seb128> just subscribe the sponsors
[23:21] <seb128> we will deal with it after the freeze end
[23:21] <kwwii> sweet, thanks
[23:21] <seb128> you're welcome
[23:22] <kwwii> I was really afraid you were going to hate me ;)
[23:22] <seb128> don't worry there is no hate around there ;-)
[23:22] <seb128> getting changes after beta is not really an issue as long they are fixing issues
[23:23] <seb128> getting all the changes the day before a freeze is what tends to stress us rather ;-)
[23:24] <kwwii> yeah, I can imagine...I do understand about having too much to do ;)
[23:24] <Amaranth> yay setting a wifi connection as system finally works
[23:24] <Amaranth> no more waiting to get online after I login
[23:26] <seb128> Laney, ok, it's just adding a "cd po; intltool-update --pot" after dh_install in rules
[23:26] <seb128> Laney, ok, it's just adding a "cd po; intltool-update --pot" after dh_install in rules
[23:26] <seb128> ups
[23:26] <seb128> do you want a bug and patch in the bts to track that or something?
[23:27] <Laney> works for me
[23:27] <Laney> or you can do a git merge request, whatever is easier
[23:31] <seb128> I will rather open a bug, I don't have git checkout there
[23:44] <rickspencer3-afk> TheMuso, are you online yet?
[23:51] <TheMuso> rickspencer3: have been for a while
[23:51] <rickspencer3> TheMuso, can you join a call in 9 minutes?
[23:52] <TheMuso> rickspencer3: If I knew what number to call, yes I could.
[23:52] <rickspencer3> TheMuso, it will be on my conference line
[23:52] <TheMuso> rickspencer3: Ok then, I'll look that up.
[23:53] <rickspencer3> TheMuso, I'll be sending a mail in 2 minutes with the info
[23:53] <TheMuso> rickspencer3: np I found it
[23:55] <rickspencer3> TheMuso, we'll do a quick Team Meeting Eastern Edition right after
[23:55] <TheMuso> rickspencer3: Sure.
[23:55] <rickspencer3> robert_ancell, are you online? team meeting will be a tad late ^
[23:55] <robert_ancell> rickspencer3, i am, np
[23:56] <kwwii> asac: any reason you removed the main-sponsors assignment on the gtk trough issue?
[23:56] <rickspencer3> TheMuso, oops
[23:56] <rickspencer3> did you see that Will is setting up the call on his line?
[23:57] <rickspencer3> he just sent a mail with details
[23:57]  * rickspencer3 is not trying to cause confusion
[23:57] <TheMuso> rickspencer3: yes
[23:57] <rickspencer3> TheMuso, thanks
[23:57] <TheMuso> Problem is, I don't know if there is an australian #, and I have had problems with international nubmers
[23:58] <rickspencer3> oh
[23:58] <rickspencer3> TheMuso, I'll hop on the call, and ask for an Australian #
[23:58] <rickspencer3> if we can't get one, we'll switch to my #
[23:59] <TheMuso> rickspencer3: Tis fine, seems to be working, will be with you soon
[23:59] <rickspencer3> oh