[00:01] <james_w> at the moment I can only see an error in timeout accounting causing this error
[00:06] <james_w> I doubt that is the case though
[00:27] <Amaranth> w00t, cleaning up the Incomplete list (marking as dupes, closing as Invalid, closing as fixed based on update, etc) has brought compiz back below 350 bugs
[00:27] <Amaranth> and now that's all bugs for all compiz source packages
[00:29] <james_w> https://bugs.edge.launchpad.net/gvfs/+bug/376145/comments/73 <- summary of my findings, now for bed
[00:43] <chrisccoulson> thanks james_w
[00:44] <james_w> there are no threads involved are there?
[00:44] <james_w> I can't find any
[00:44] <chrisccoulson> i don't think so
[06:09] <TheMuso> robert_ancell_: Just subscribed you to that bug I planned on filing against gdm.
[06:09] <robert_ancell_> TheMuso, thanks
[06:38] <al-maisan> Good morning!
[07:20] <pitti> Good morning
[07:26] <didrocks> hey pitti
[08:37] <robert_ancell> hey pitti, there are a number of packages that depend on policykit-gnome, should these be updated to policykit-1-gnome?
[08:37] <pitti> robert_ancell: you mean apart from checkbox and screen-resolution-extras? (these two still need to be ported)
[08:39] <robert_ancell> there is gnome-mount and gnome-volume-manager
[08:40] <pitti> ah
[08:40] <pitti> they weren't ported to pk-1, though, and are obsolete, too
[08:40] <robert_ancell> ok, I wasn't sure if they're obsolete
[08:40] <robert_ancell> apt-get removed!
[08:41] <pitti> robert_ancell: both still use hal, too, so they don't really use pk-1
[08:41] <seb128> hello robert_ancell
[08:41] <pitti> robert_ancell: hal doesn't use any PK at the moment, so if you touch the packages, just drop the pk-gnome depends entirely, I'd say
[08:42] <robert_ancell> seb128, hey
[08:42] <seb128> robert_ancell, good work on gdm and g-c-c ;-)
[08:42] <robert_ancell> thanks!
[08:43] <robert_ancell> I have to go, one last question - there are some UI changes to PolicyKit GNOME - are these out of scope for Karmic?
[08:43] <robert_ancell> one is changing the "authentication failure" message to "incorrect password, please re-enter"
[08:44] <robert_ancell> the other is selecting your user by default
[08:44] <pitti> from upstream?
[08:44] <robert_ancell> seb128, pitti ^^^
[08:44] <robert_ancell> from me, as requested by design team and others
[08:44] <pitti> I wouldn't like to introduce an ubuntu specific string now, it breaks all translations again
[08:45] <seb128> same here
[08:45] <robert_ancell> sure, I have no desire to push them through so I'll leave the patches in LP and let someone else fight for them if they think they're important
[08:45] <pitti> no objection to getting it upstream, of course
[08:45] <robert_ancell> I'm pushing them upstream
[08:45] <seb128> selecting your user by default++
[08:45] <pitti> selecting user by defualt sounds harmless
[08:46] <pitti> it's not really an UI change, more like a bug fix
[08:46] <robert_ancell> ok, I'll try and get that one done (it is a subset of other changes). I think that will annoy people
[08:46] <pitti> I don't actually have that, though
[08:46] <pitti> I guess it only happens if you have more than one admin?
[08:46] <robert_ancell> currently no user is selected by default
[08:46] <robert_ancell> sorry, you must be right
[08:46] <pitti> ah, I see
[08:47] <pitti> I added my test user to admin, can reproduce now
[08:47] <pitti> that's annoying, yes
[08:47] <robert_ancell> annoying huh?
[08:48] <robert_ancell> gtg, see you all tomorrow
[08:48] <seb128> robert_ancell, see you
[08:48]  * pitti votes for changing the "auth fail" string to "This operation requires beta-three clearance"
[08:49] <pitti> or using sudo insults :)
[08:49] <seb128> pitti, do you know where the strings comes from there?
[08:49] <seb128> the auth failure one
[08:49] <chrisccoulson> hello everyone
[08:49] <pitti> it's not in pk-1-gnome? It really should
[08:49] <pitti> hey chrisccoulson
[08:50] <chrisccoulson> hey pitti
[08:50] <seb128> pitti, I was looking in polkit-1
[08:50] <seb128> not -gnome
[08:50] <chrisccoulson> how are you today?
[08:50] <seb128> hey chrisccoulson
[08:50] <pitti> chrisccoulson: pretty good, although still a bit tired; hunting gdm/g-s-d bugs now
[08:50] <chrisccoulson> hey seb128
[08:51] <chrisccoulson> whats wrong with g-s-d?
[08:51] <chrisccoulson> ah, keyboard issues
[08:51] <pitti> bug 421212
[08:51] <chrisccoulson> yeah, i just saw that in my inbox
[08:51] <seb128> chrisccoulson, did you manage to solve this timeout not being at the correct value?
[08:51] <pitti> thanks for hunting the d-bus activation thing
[08:52] <pitti> seems there's no final understanding yet, but you are closing in?
[08:52] <chrisccoulson> seb128 - not yet. james_w did more work on that than me. all we know is it isn't timing out with the correct value
[08:52] <chrisccoulson> it times out much sooner than 25 seconds, which should be the default
[08:52] <chrisccoulson> about 3.5 seconds on my box
[08:53] <seb128> pitti, where is polkit-1-gnome being worked? fd.o?
[08:54] <pitti> chrisccoulson: is that a constant ratio? I. e. does it time out after 7 seconds when you request 50?
[08:54] <seb128> pitti, how are translators organized there, it seems poorly translated at least in french on karmic
[08:55] <pitti> seb128: http://git.gnome.org/cgit/PolicyKit-gnome/
[08:55] <pitti> seb128: policykit-1 itself is on fdo
[08:55] <chrisccoulson> pitti - i think james_w discovered that it wasn't completely linear
[08:56] <pitti> seb128: there's a whole bunch of recent translation commits there
[08:56] <seb128> pitti, oh, lot of translations updates there, do you think you could snapshot git or just the .po after beta?
[08:56] <seb128> pitti, yes, GNOME translators are usually active ;-)
[08:56] <pitti> seb128: sure
[09:06] <seb128> pitti, you want me to do it?
[09:07] <pitti> seb128: oh, if you wish
[09:07] <seb128> pitti, ok, will do
[09:07] <pitti> merci
[09:07] <pitti> a-haaa
[09:07] <seb128> de-nada
[09:08] <pitti> so, I found the bug for one case of wrong keyboard variant handling, just to discover yet another one *sigh*
[09:08] <seb128> urg
[09:08] <seb128> the indicator message applet seems screwed there, brb
[09:12] <chrisccoulson> pitti - another bug in g-s-d?
[09:13] <pitti> more like a conceptual flaw
[09:14] <chrisccoulson> whats the issue now?
[09:14] <pitti> so, g-s-d tries to be clever
[09:14] <pitti> if /desktop/gnome/peripherals/keyboard/kbd/layouts is empty, it adds $GDM_KEYBOARD_LAYOUT to the gconf list
[09:15] <pitti> if it's nonempty, it tries to match $GDM_KEYBOARD_LAYOUT to one of the existing lists
[09:15] <pitti> neither actually works, since gdm and g-s-d have a different interpretation of the value, but that's trivial to fix (doing now)
[09:15] <chrisccoulson> ah, ok. thanks:)
[09:15] <pitti> but if you already have a gconf setting, like [us], and then select German keyboard, neither of those two cases matches, and the keyboard isn't set
[09:16] <pitti> so we need a third case to add the new layout to existing entries
[09:16] <pitti> and finally, gdm doesn't read the variant value from hal
[09:18]  * pitti can't believe that there isn't a g_string_replace()
[09:19] <pitti> or _subst() or whatever
[09:40] <DuckGod> when i install my jaunty on my pc it installs all the way then when i reboot to the new system it gives me the message "existing intel boot agent" how do i bypass that
[09:42] <DuckGod> when i install my jaunty on my pc it installs all the way then when i reboot to the new system it gives me the message "existing intel boot agent" how do i bypass that
[09:43] <Ng> DuckGod: that's a message from your network card when it's being initialised by the BIOS. Does it not say anything after that?
[09:43] <DuckGod> no it just stalls at that message
[09:49] <DuckGod> have any advice?
[09:51] <chrisccoulson> seb128 - i reverted the gnome-python-extras change which removed python-gnome2-extras last night, but i just realised that i forgot to push to bzr
[09:51] <chrisccoulson> and seb128 isn't here ;)
[09:53] <Ng> DuckGod: maybe check the boot settings in the BIOS, make sure it's actually going to try and boot from the hard disk
[09:54] <DuckGod> i took my ethernet card out and now it says reboot and select proper boot device
[09:55] <DuckGod> after that i went into bios and set it to bood from the hard drive and got the same message
[09:55] <DuckGod> so then i tried to boot from cd rom and got the same message
[09:55] <rodrigo_> how is brainstorm.u.c used? that is, do the blueprints for discussion at UDS get created from the most popular ideas at brainstorm.u.c?
[09:58] <DuckGod> any advice?
[10:00] <chrisccoulson> DuckGod - you might have more luck in #ubuntu, which is for support
[10:01] <DuckGod> this is the only room that anyone awnsered me
[10:12] <tseliot> mat_t: can you tr
[10:13] <tseliot> mat_t: can you try my new package, please? https://launchpad.net/~albertomilone/+archive/x-testing/+packages
[10:14] <mat_t> tseliot: sure, will try it in a sec :)
[10:14] <tseliot> thanks
[10:15] <tseliot> i386 is https://launchpad.net/~albertomilone/+archive/x-testing/+build/1269831
[10:20]  * tseliot can't see the cursor flicker any longer \o/
[10:21] <seb128> tseliot, do you know about any upstream fix for dpms issues?
[10:21] <seb128> hey btw ;-)
[10:21] <tseliot> seb128: for what card?
[10:22] <seb128> tseliot, intel there but I'm not sure it's specific to it
[10:22] <tseliot> seb128: is there a bug report about it?
[10:22]  * tseliot needs more details
[10:24] <seb128> tseliot, see https://bugzilla.gnome.org/show_bug.cgi?id=596609
[10:24] <seb128> tseliot, upstream says there is 3 xserver changes
[10:26] <tseliot> seb128: ok, let me try to reproduce the problem here. I might have a patch for that already
[10:26] <seb128> tseliot, ok, thanks
[10:27]  * tseliot can't lock the screen...
[10:27]  * seb128 hugs pitti for tackling xkb issues
[10:28] <seb128> tseliot, there is no need to lock anything
[10:28] <seb128> tseliot, set the dpms timeout to 1 minute and don't touch the box
[10:28] <seb128> the screen will flicker and come back
[10:28] <tseliot> ok
[10:28] <seb128> you just have to wait one minute
[10:29] <tseliot> I can do it ;)
[10:29] <seb128> I've confirmed the bug there without gnome-screensaver running
[10:29] <seb128> ;-)
[10:29]  * pitti hugs back seb128
[10:32]  * tseliot can't reproduce the problem with the screensaver on and will try without it
[10:33] <seb128> tseliot, you have the screen cutting?
[10:33] <seb128> ie dpms kicks in and stay after 1 minute?
[10:33] <tseliot> ok, I reproduced the problem
[10:33] <tseliot> let me try a new patch
[10:34] <seb128> thanks
[10:36] <seb128> grrr, focus issues and closing wrong dialogs
[10:52] <mat_t> tseliot: looks like this might have worked! :D
[10:52] <tseliot> mat_t: great and thanks for testing :-)
[10:54] <mat_t> tseliot: thank you. I'll keep you posted if anything pops up
[10:54] <tseliot> mat_t: ok, good
[10:55] <mat_t> tseliot: would you mind just marking the bug as fixed?
[10:56] <tseliot> mat_t: sure, when I upload the new package
[10:56] <seb128> pitti, did you restart the retracers?
[10:56] <mat_t> tseliot: of course. Thanks again
[11:04] <pitti> seb128: yesterday; are they broken again? I didn't get new mail
[11:05] <pitti> mat_t: please don't, it will be auto-closed by the upload
[11:05] <pitti> "fix committed" would be appropriate, though
[11:06] <seb128> pitti, the log didn't get updated for a day
[11:06] <seb128> pitti, but they are running
[11:06] <seb128> pitti, ie they seem stucked
[11:06] <seb128> I was not sure if you just restarted those
[11:06] <seb128> ie the log didn't get an update yet
[11:06] <seb128> or if they are stucked
[11:06] <pitti> hm; still in VTs debugging gdm, I can have a look later
[11:06] <pitti> do they have any lock files?
[11:06] <seb128> ok thanks
[11:07] <seb128> yes, lock file, apport processes running
[11:07] <seb128> yes, lock file, apport processes running and no log update
[11:11] <pitti> seb128: and it's not just updating chroots and the log is behind? (due to file buffering)
[11:12] <seb128> pitti, the log didn't change for 19 hours now
[11:12] <pitti> that sounds wrong then
[11:12] <seb128> 2009-09-30 15:42 log
[11:13] <pitti> ronne went down yesterday, and was rebooted
[11:13] <pitti> but I'm not sure how this could cause this
[11:13] <pitti> perhaps just kill them and remove locks?
[11:13] <seb128> ok, will try that
[11:15] <seb128> pitti, done, let's see what happens next
[11:17] <mat_t> pitti: yes, that's exactly what I meant :)
[11:30] <chrisccoulson> aargh, stupid unreliable 3g connection!
[11:38] <tseliot> seb128: ok, problem solved. We were missing on patch
[11:39] <seb128> tseliot, oh, good, thanks
[11:39] <tseliot> seb128: it's really an xserver bug
[11:39] <seb128> can you reassign the launchpad bug and comment?
[11:39] <seb128> I will close the GNOME one
[11:42] <tseliot> seb128: I've just added a comment in the gnome bug report (without closing it). I'll do the same for LP and assign it to xserver
[11:42] <seb128> tseliot, thanks
[11:42] <tseliot> seb128: thanks for bringing the problem to my attention
[12:50] <seb128> dpm, hye
[12:50] <seb128> hey
[12:51] <dpm> hey seb128
[12:51] <seb128> dpm, there is quite some updated policykit-gnome-1 .po in GNOME git compared to karmic, do you think you could get those imported directly in rosetta by some way or is it easier if we do source changes in karmic?
[12:58] <james_w> is there a reason that something would behave differently when you run the libtool wrapper script vs the executable in .libs?
[12:58] <seb128> using libs from the same build or system ones
[12:59] <seb128> ie if your build has a binary and libraries the wrapper will use the libraries from the local build
[12:59] <seb128> where just running the binary in .libs will not
[12:59] <james_w> ah
[13:00] <james_w> thanks
[13:00] <seb128> you're welcome
[13:00] <james_w> do you know of some magic to get gdb to "run" the wrapper script?
[13:00] <seb128> no
[13:00] <seb128> but you can LD_LIBRARY_PATH=.libs gdb ...
[13:00] <james_w> libtool --mode=execute gdb hell
[13:00] <james_w> documentation to the rescue :-)
[13:01] <seb128> hehe
[13:01] <seb128> I usually use the LD_LIBRARY_PATH trick which works fine too
[13:05] <dpm> seb128, for source packages, I think it's best to do the changes in them and import them through the normal process. If you provide me a tarball with the POT template and all the PO files I think I can upload that as well, but they should match the template in the package
[13:05] <chrisccoulson> hey james_w
[13:05] <chrisccoulson> you had any more thoughts on this timeout issue?@
[13:05] <james_w> hey chrisccoulson
[13:05] <james_w> I'm looking at it now
[13:06] <chrisccoulson> cool:)
[13:06] <seb128> dpm, well the package doesn't change any po
[13:06] <james_w> trying to track down which code path causes the timeout error to actually be returned
[13:06] <james_w> it's proving rather tricky :-)
[13:06] <chrisccoulson> yeah, i'm not too sure either
[13:06] <james_w> I might need a DBus built with -O0
[13:06] <chrisccoulson> i tried following the code in libdbus last night
[13:07] <james_w> there are two functions that cause a timeout error to be sent, and breaking on either of them doesn't trigger
[13:07] <chrisccoulson> but i got tired and went to bed ;)
[13:07] <seb128> dpm, so it's basically importing the po from the git source, I can also copy those in the package and upload but that will be after beta
[13:08] <seb128> chrisccoulson, so you do sleep sometimes? ;-)
[13:08] <chrisccoulson> seb128 - i slept for 4 hours last night ;)
[13:08] <seb128> urg
[13:08] <chrisccoulson> that's more than usual!
[13:08] <seb128> you don't need much sleep or you are just counting on weekends to catch up on the extra hours?
[13:09] <chrisccoulson> i tend to just catch up at the weekend
[13:09] <chrisccoulson> i sleep a lot at the weekend!
[13:11] <james_w> hmm
[13:12] <james_w> could it be the timeout error isn't the client-side one?
[13:12] <james_w> the server is sending a timeout error to the client?
[13:12] <james_w> that would explain the symptoms a bit better
[13:12] <james_w> not why the call timeout changes it though
[13:15] <chrisccoulson> james_w - i'm not sure where the timrout message delivery is dispatched from. i know the message is a client-side one, but i don't know if it is triggered off the client's main loop, or whether it is triggered from the daemon
[13:15] <chrisccoulson> that's the bit i didn't understand yet
[13:16] <james_w> the message is pre-allocated client side
[13:16] <james_w> (I think)
[13:16] <james_w> I can find only two functions that access it
[13:16] <james_w> neither seems to be called here
[13:16] <james_w> building with -O0 now to help
[13:17] <james_w> I'm pretty sure the timeout counting is purely client-side
[13:17] <james_w> hmm, maybe not
[13:17] <chrisccoulson> yeah, the actual message itself is purely client-side
[13:17] <chrisccoulson> but i'm not so sure about the timing
[13:17] <chrisccoulson> i couldn't find any main loop interaction when i followed the code last night
[13:18] <dpm> seb128, where's the upstream git repo? http://git.gnome.org/cgit/PolicyKit-gnome/ is still the old policykit, isn't it?
[13:19] <chrisccoulson> dpm - 0.94 is polkit-1
[13:19] <james_w> ok, -O0 helps a lot
[13:22] <james_w> I can now break on the error return
[13:22] <dpm> chrisccoulson, ah, thanks. I'm guessing that the master branch is also polkit-1. Should I fetch the po files from 'master', seb128, or which one is used in the src package?
[13:23] <chrisccoulson> james_w - you'll have the issue solved by the time i finish work at this rate ;)
[13:23] <james_w> chrisccoulson: you loosened the lid :-)
[13:23] <james_w> not sure I'll fix it, but hopefully we can get beyond "wtf?"
[13:24] <seb128> dpm, http://git.gnome.org/cgit/PolicyKit-gnome/ is still the old policykit, isn't it? <- no
[13:24] <seb128> dpm, it's the new one
[13:24] <james_w> ok, so it really does think it has timed out
[13:25] <seb128> dpm, yes master is the one to use
[13:25] <dpm> seb128, ok, I'll have a look into it, see if I can upload those and I'll let you know about the outcome
[13:26] <seb128> dpm, there has been a few string additions since our version but not string change to existent strings
[13:26] <seb128> dpm, thanks
[13:26] <dpm> ok
[13:27] <seb128> dpm, otherwise maybe you can drop an email to translator to say they might want to review and upload their locale one?
[13:27] <seb128> ie that git has lot of updates and could be a good idea to review and upload the updated upstream po to rosetta for karmic
[13:30] <mat_t> seb128: pitti: I'm still getting a system beep on battery low on my Mini 9 - is this a known issue?
[13:31] <pitti> mat_t: hm, no; do you have "pcspkr" in /etc/modprobe.d/blacklist.conf?
[13:31]  * mat_t checks
[13:33] <chrisccoulson> james_w - can you work out where the timeout message is dispatched from in GDB then?
[13:33] <chrisccoulson> (i can't do much from here at the moment)
[13:34] <mat_t> pitti: I've got blacklist pcspkr
[13:34] <james_w> chrisccoulson: dbus/dbus-connection.c
[13:34] <james_w> calls to complete_pending_call_and_unlock
[13:35] <james_w> in _dbus_connection_block_pending_call
[13:35] <james_w> the failure is the one at the end
[13:37] <james_w> I'm not quite sure what the success hits though
[13:37] <james_w> it's either something to do with the goto
[13:37] <james_w> or   /* check to see if we already got the data off the socket */
[13:37] <james_w>   /* from another blocked pending call */
[13:38] <james_w> or DBUS_DISPATCH_DATA_REMAINS
[13:39] <seb128> pitti, retracing are happily retracing now
[13:39] <pitti> mat_t: does it actually sound like the pc speaker, or is it more like a real system sound?
[13:39] <pitti> seb128: \o/
[13:39] <seb128> pitti, thanks for the suggestion of just restart everything ;-)
[13:39] <mat_t> pitti: sys speaker
[13:40] <Amaranth> hmm, I'm thinking maybe compiz should just not ship the gconf plugin at all
[13:40] <chrisccoulson> james_w - how do you get _dbus_verbose() to print the debug messages?
[13:40] <chrisccoulson> might be useful
[13:40] <Amaranth> or kconfig
[13:40] <james_w> I just did that :-)
[13:40] <Amaranth> too easy to screw things up
[13:40] <mat_t> pitti: really loud and awful :)
[13:40] <james_w> s/_dbus_verbose/_dbus_warn/ for the easy way
[13:40] <Amaranth> Compiz doesn't support that fancy new sound because it doesn't use libcanberra
[13:40] <Amaranth> so you get system beep
[13:42] <pitti> arrrgh
[13:42] <pitti> I wasted two hours to track down a single-character fix
[13:42] <pitti> hrmpf gdm
[13:42] <pitti> but keyboard variants are finally working
[13:42] <seb128> pitti, it's better than two hours to not track down the issue ;-)
[13:43]  * seb128 hugs pitti
[13:43] <seb128> you rock dude
[13:43]  * pitti hugs back seb128
[13:43] <seb128> do you upload g-s-d and gdm now?
[13:43] <pitti> seb128: I'll commit it
[13:43] <pitti> I can still upload after beta freeze
[13:43] <seb128> ok, feel free to upload
[13:43] <pitti> just in case we get another fix in between
[13:43] <pitti> there's already a gdm in the queeu
[13:43] <seb128> right
[13:43]  * pitti leaves the VTs and starts a real X session again
[13:44] <seb128> pitti, there is a gdm sponsoring request pending too if you want to look at that while you are at it
[13:52] <pitti> seb128: I'll have a look
[13:52] <seb128> thanks
[13:55] <james_w> dbus_connection_send_with_reply_and_block(): Waited 5057 milliseconds and got no reply
[13:56] <james_w> that's a lot less than the timeout, so why do you think it is a timeout?
[13:58] <pitti> mat_t: can you please check "lsmod | grep pc" whether you have pcspkr or snd_pcsp loaded?
[13:59] <mat_t> pitti: ok
[14:01] <james_w> got it
[14:01] <james_w> how did this ever work?
[14:06] <Ng> mac_v: I was just pestering asac about the new karmic artwork for network manager's notification area applet not showing a little sub-icon for VPNs and he redirected me to you :)
[14:07] <Ng> mac_v: please shout if you want a bug filing or somethign testing :)
[14:08] <mac_v> Ng: are you using the distro version of humanity or from bzr?
[14:08] <Ng> mac_v: distro
[14:08] <mac_v> Ng: yeah , it had problems... it is fixed in lp:humanity
[14:08] <Ng> ok cool :)
[14:09] <mac_v> Ng: it will be immediately updated after beta
[14:09] <Ng> \o/
[14:09] <mac_v> Ng: could you test the bzr and see it you still have problems? if still having a problem , a screenshot would be nice
[14:13] <seb128> james_w, nice, what was it?
[14:13] <seb128> chrisccoulson, vuntz managed to track the keyring timeout issue or figure what is wrong rather
[14:13] <seb128> should be fixed for karmic too ;-)
[14:14] <Ng> mac_v: yep that puts a little padlock on fine :)
[14:14] <mac_v> :)
[14:15] <Amaranth> mac_v: bluetooth?
[14:15] <mac_v> Amaranth: done ;)
[14:15] <pitti> seb128: there was just one gdm sponsoring bug left, I cleaned up the other ones; committed now
[14:15] <Amaranth> mac_v: after beta? :)
[14:15] <mac_v> yup
[14:15] <mac_v> Amaranth: its been updated in the bzr since nearly a week, but we are in freeze :(
[14:16] <james_w> seb128: http://paste.ubuntu.com/282982/
[14:16] <mat_t> pitti: nope, seems like I don't
[14:16] <vuntz> seb128: I didn't figure it out
[14:16] <vuntz> seb128: I actually don't get it at all :-)
[14:16] <pitti> mat_t: hm, then I'm really puzzled what produces it on your machine..
[14:17]  * mat_t is puzzled, too
[14:17] <Ng> mac_v: hey yeah, the bluetooth icon looks great :)
[14:17] <mat_t> pitti: I'm going to run a fresh install and see what happens
[14:17] <Ng> mac_v: what's the little /!\ on the network manager icons?
[14:17] <pitti> mat_t: or just try a live system
[14:18] <mac_v> Ng: screenshot pls ?
[14:18] <mat_t> mac_v: yes, that should be gone
[14:18] <mat_t> mac_v: a little warning you added
[14:18] <seb128> pitti, thanks!
[14:18] <kwwii> pitti: hey, the notify-osd icons are not being used (nor are they intalled by default)
[14:19] <mac_v> mat_t: what should be gone... ? i dont know what to remove without a screenshot ;)
[14:19] <pitti> kwwii: hm, works here..
[14:19] <kwwii> pitti: you see the icons with the gradients in the notify bubbles?
[14:19] <mat_t> mac_v: a little red /!\ emblem you added to the ad-hoc icon
[14:19] <kwwii> or do you see simple grey icons?
[14:19] <Ng> mac_v: http://mairukipa.tenshu.net/screenshots/2009-10-01-icons.png (I have wired and wireless and VPN active atm)
[14:19] <pitti> kwwii: notify-osd-icons is also in http://cdimage.ubuntu.com/daily-live/20090929.2/karmic-desktop-i386.manifest
[14:19] <mac_v> mat_t: that is need for the ad-hoc
[14:20] <asac> mac_v: can you make that yellow?
[14:20] <mac_v> Ng:  argh! nm-applet is totally mesed up
[14:20] <Ng> mac_v: could that be because I didn't restart it maybe?
[14:20] <mac_v> Ng: blame asac ;0
[14:20] <pitti> kwwii: it's some light gray; not the gray/blue loudspeaker from hicolor, but the gray-only abstract loudspeaker symbol
[14:20] <asac> mac_v: as discussed, security is not the only property this is supposed to communicate ;)
[14:20] <mac_v> asac: so should i remove it?
[14:20] <mac_v> i thought you wanted it
[14:21] <asac> mac_v: the exclamation mark?
[14:21] <mac_v> yeah
[14:21] <asac> mac_v: i didnt push for any change
[14:21] <seb128> james_w, oh, it's a dbus bug then
[14:21] <mac_v> oh ... ok.. removing
[14:21] <james_w> yeah
[14:21] <asac> mac_v: i thought what you did initially was ok
[14:21] <seb128> james_w, good work!
[14:21] <kwwii> pitti: right, those are the wrong ones as well :(
[14:21] <mat_t> a
[14:21] <mac_v> asac: me too!... mat_t confused me ;p
[14:21] <asac> mac_v: though not optimal ... but we discussed that the optimal way would be to make a separate ad-hoc sectrion
[14:21] <kwwii> pitti:  those are the panel icons from Humanity
[14:21] <asac> we will keep this in mind for the applet rewrite next (nm) cycle
[14:21] <mat_t> asac: yes, that we can do for Lucid
[14:21] <mclasen> pitti: I'm confused about your comment in bug  596897
[14:22] <mat_t> asac: mpt will be leading that
[14:22] <mac_v> asac: wwan and ad-hoc are also using device icons in the panel! :/
[14:22] <mclasen> pitti: you say 'gdm separates layout and
[14:22] <mclasen> variant with a space'
[14:22] <kwwii> pitti: I think part of the problem is that they are being installed into /usr/share/notify-ods/icons/gnome/
[14:22] <pitti> kwwii: I have this one: http://people.canonical.com/~pitti/tmp/notify.png
[14:22] <asac> mat_t: i think whatever mpt is leading isnt upstream ;)
[14:22] <mclasen> pitti: but the gdm patch in the other bug actually uses a tab as separator
[14:22] <seb128> gnome bug #596897
[14:22] <asac> mat_t: but better discuss that somewhere else
[14:22] <asac> ;)
[14:22] <kwwii> pitti: hrm, that is the right icon
[14:22] <pitti> mclasen: after the last two hours of reading gdm code I actually found out that gdm seems to use a wild mix of tabs and spaces :-(
[14:23] <pitti> mclasen: gconf etc. uses spaces, xklavier uses tabs
[14:23] <asac> mac_v: i will check if the fallback mechanism would work.
[14:23] <pitti> kwwii: it's the one from notify-osd-icons..
[14:23] <mat_t> asac: we often ship stuff that has modifications vs. the upstream version - n-m-applet is unlikely to be an exception here :)
[14:23] <kwwii> pitti: yeah, the brightness works for me here too, but the battery icons show the panel versions
[14:23] <chrisccoulson> seb128 - what was the issue with gnome-keyring-daemon then? i looked at the bug report, but the comment from vuntz is what i already thought was happening
[14:23] <kwwii> pitti: just noticed that some do work...very strange
[14:24] <seb128> chrisccoulson, I though vuntz figured it after starting to read the comment but in fact not
[14:24] <kwwii> pitti: maybe it is a problem with the lookup from power manager
[14:24] <mat_t> asac: what I'm saying is, any modifications to the upstream n-m menu should go via mpt first :)
[14:24] <pitti> kwwii: hm, then I guess for battery notify-osd and -icons don't agree on the name?
[14:24] <chrisccoulson> ah, thanks
[14:24] <seb128> chrisccoulson, so ignore me, but james_w fixed the timeout thing ;-)
[14:24] <mac_v> mat_t: i keep telling asac to have modifications... but he is just not willing or maybe lazy ;p
[14:24] <chrisccoulson> really?
[14:24] <chrisccoulson> yay \o/
[14:24] <seb128> chrisccoulson, iz dbus bog
[14:24] <kwwii> pitti: right...it should *not* be using the normal names for the notification, or else the normal theme will over-ride them
[14:24] <vuntz> chrisccoulson, seb128: what would be interesting is to know if g-k-d is still running during the 10s timeout
[14:25] <kwwii> pitti: at least it makes sense now ;) Humanity inherits gnome, so if humanity has these icons, they are being used before the notify-osd versions
[14:25] <asac> lets defer the applet discussion to uds. its a bit confusion here i think
[14:25] <mac_v> asac: are there going to be signal strengths for ad-hoc and wwan ... when will the naming be mentioned
[14:26] <asac> mac_v: i will ping you right away when i know that
[14:26] <chrisccoulson> vuntz - i'll take a look again when i finish work
[14:26] <kwwii> pitti: do you know who I can talk to about power-manager?
[14:26] <mac_v> ;)
[14:26]  * chrisccoulson hugs james_w for fixing dbus bug :)
[14:26] <mat_t> asac: sure. I really like the new applet, the as-hoc icon is the only major itch for me atm
[14:26] <pitti> kwwii: why power-manager? isn't the icon requested by notify-osd?
[14:27] <pitti> kwwii: anyway, you can ask me
[14:27] <Amaranth> Does freenode host servers the same place freedesktop does? :P
[14:27] <pitti> james_w: you rock!
[14:27] <mat_t> asac: but you're right, uds will be a good place for that
[14:27] <Amaranth> holy crap, they're restarting the freenode servers 1 by 1
[14:27] <seb128> vuntz, yes it's running
[14:28] <kwwii> pitti: well, I assumed it was getting the lookup from power-manager, but you might be right
[14:28] <mac_v> pitti: kwwii: notify-osd needs the name modification , but MacSlow just recently marked the bug invalid in notify-osd... so gpm need to change the icon labels
[14:28] <kwwii> pitti: well, none of the battery icons I have seen are correct in notify-osd, it is using small panel icons from humanity
[14:28] <vuntz> seb128: if it's running all the time, then, yeah, definitely a g-k-d bug
[14:28] <mat_t> pitti: will it help if I copy the whole output?
[14:28] <seb128> vuntz, it's running while it's hanging yes
[14:29] <mac_v> kwwii: pitti: Bug #399492
[14:29] <kwwii> pitti: which tells me that *something* is looking/using gpm-battery-*.png before notification-battery-*.png
[14:30] <mac_v> pitti: kwwii: notify-osd has the naming change for nm-applet , but doesn have the switch for gpm
[14:30] <kwwii> pitti, mac_v: right
[14:31] <vuntz> seb128: hrm. I guess what we really need is some cool printf debugging :/
[14:31] <pitti> kwwii: let me look what g-p-m does
[14:31] <vuntz> seb128: (to know where it's handing)
[14:31] <kwwii> pitti, mac_v: it is using the new -plugged names instead of -charging as is currently done in the notify icons
[14:31] <seb128> vuntz, stacktrace wouldn't be useful?
[14:31] <mac_v> pitti: nm-applet send a different icon label but notify-osd does the switch  , IMO , it would be better if MacSlow patches notify-osd to do the same
[14:31] <mac_v> fro gpm
[14:31] <mac_v> for*
[14:31] <vuntz> seb128: if you manage to get one, sure. But you have to be fast
[14:32] <seb128> yeah, would be nice to not carry GNOME code changes for that
[14:32] <pitti> kwwii: so, g-p-m has a patch for notify-osd support; in that, it uses notification-display-brightness-{off,low,medium...} when notify-osd is detected
[14:32] <chrisccoulson> i've tried getting a trace of g-k-d, but i'm not fast enough
[14:32] <seb128> vuntz, for some value of fast, it's hanging for some 6 seconds there
[14:32] <james_w> chrisccoulson: https://bugs.freedesktop.org/show_bug.cgi?id=24254 if you are interested in the full story
[14:32]  * seb128 tries that
[14:32] <chrisccoulson> the issue is that GDB needs to be running from a different console, so you have to factor in a VT switch there
[14:33] <chrisccoulson> james_w - you rock!
[14:33] <seb128> chrisccoulson, I've intel and kms there
[14:33] <seb128> is switch between guest session and my user is 1 second
[14:33] <Amaranth> that long? :/
[14:33] <chrisccoulson> seb128 - nvidia here, so VT switching is super slow ;)
[14:33] <kwwii> pitti: first, I will try renaming them here locally form *-charging to *-plugged and see what effect that has on my system
[14:34] <pitti> kwwii: yes, gpm itself uses gpm-battery-* icons
[14:34] <pitti> kwwii: gpm doesn't use notification-battery*
[14:34] <kwwii> pitti: funny thing is, I already changed this (I still have the script I used to do it)
[14:35] <pitti> kwwii: however, those are just icons for the tray applet, not for notifications
[14:35] <kwwii> pitti: no worries, let me test this out and get back to you
[14:35] <pitti> kwwii: ok
[14:35] <kwwii> pitti: I think this is a case of us two having different bzr repos for these icons...I think some of my changes got lost
[14:35] <pitti> kwwii: for notify-osd? hm, we just have one branch now, no?
[14:36] <pitti> kwwii: I'm using ~ubuntu-art-pkg/notify-osd/notify-osd-icons-ubuntu, and you?
[14:36] <kwwii> pitti: yes, bu before I think we used differnt ones shortly
[14:37] <pitti> mac_v: I don't want to change the icon names in gpm; gpm-battery-* are private icons for gpm, and it'd be a pointless and huge patch to rename them all
[14:37] <pitti> mat_t: "will it help if I copy the whole output?" for what?
[14:38] <pitti> kwwii: if you still have your's, merge it into the official one
[14:38] <seb128> chrisccoulson, hum, you are right, I'm not quick enough ... it seems quite long while waiting for session to close usually though
[14:39] <mac_v> pitti: exactly , gpm doesnt have to change the names , notify-osd must be able to recognize the labels and do the icon switch appropriately
[14:39] <mat_t> pitti: lsmod grep pc
[14:40] <pitti> mat_t: ah; well, I trust you to recognize "pcspkr" :)
[14:40] <mat_t> pitti: lol
[14:41] <mac_v> pitti: that is how it works for nm-applet [applet just send the label nm-wireless but notify-osd uses the icon notification-wireless-full instead]...
[14:41] <mac_v> for notifications^
[14:42] <seb128> MacSlow, ^
[14:43] <MacSlow> mac_v, seb128: notify-osd does not alter the passed icon-file-name in any way
[14:44] <kwwii> MacSlow: erm, I think it does ;)
[14:44] <kwwii> it looks for notification-* first, or it wouldn't work
[14:44] <mac_v> MacSlow: is does , for nm-applet
[14:45] <mac_v> just a sec
[14:45] <MacSlow> kwwii, mac_v: notify-osd itself does not... if at all gtk+'s icon-load functions, used by notify-osd, may
[14:46] <kwwii> MacSlow: hrm, ok
[14:46] <kwwii> pitti: in any case, renaming the icons does not help
[14:47] <mac_v> MacSlow: https://bugs.launchpad.net/hundredpapercuts/+bug/387626/comments/5
[14:47] <mac_v> has that been changed ? src/applet-device-wifi.c. There is a patch to that called lp33796_dxteam_notification_icon_names.diff that changes the icon from nm-device-wireless to notification-network-wireless-full.
[14:47] <kwwii> mac_v: why are there still gpm-primary-* icons in humanity?
[14:48] <mac_v> kwwii: huh?
[14:48] <mac_v> you mean the greyscale icons?
[14:49] <mac_v> MacSlow: you told me back then you did not write that applet
[14:49] <kwwii> mac_v: status/22/gpm-primary-000.svg for instance
[14:49] <mac_v> kwwii: what should be the label?
[14:49] <mac_v> that is for the panel
[14:49] <kwwii> mac_v: as I understood it, all the -primary- names were changed to -battery-
[14:50] <tgpraveen> mac_v: in beta will humanity have notifyosd icons?
[14:50] <kwwii> mac_v: it is intersting because you also have the -battery- names
[14:50] <mac_v> kwwii: oh! yeah! so no need the -[rimary?
[14:50] <mac_v> primary(
[14:51] <mac_v> tgpraveen: what?
[14:51] <mac_v> kwwii: do you want me to remove the primary-* labels?
[14:51] <kwwii> mac_v: no, iirc, you need to simply remove the *-primary-* icons because they are no longer used
[14:51] <MacSlow> mac_v, I don't currently recall us talking about this topic atm.
[14:52] <kwwii> mac_v: let me look into it some more
[14:52] <pitti> seb128: do you know anything in the gdm session which requires/benefits from a polkit agent? I don't, and I'd just remove the autostart .desktop (it has never worked anyway due to wrong path)
[14:53] <mac_v> MacSlow: you told me that more that , when i should you that comment.. on #ayatana ;)  you must have forgotten... you said that you didnt write the applet-device-wifi
[14:53] <kwwii> mac_v: wait, they were links to the other names
[14:53] <rickspencer3> Amaranth, is the latest compiz uploaded?
[14:53] <mac_v> kwwii: yeah
[14:53] <seb128> pitti, the idea was to have gdmsetup there iirc
[14:53] <kwwii> MacSlow: I remember talking to someone about getting this done last release
[14:53] <Amaranth> rickspencer3: not yet, no
[14:53] <rickspencer3> ok
[14:53] <tgpraveen> mac_v: in ubuntu beta to be released today, was the notify-osd cons merged with humanity icon theme?
[14:53] <seb128> pitti, but I don't think it will happen for karmic now
[14:53] <rickspencer3> thanks
[14:53] <pitti> seb128: right, but we don't?
[14:54] <pitti> seb128: ok; so I'll fix the path in it to not forget about it, but disable it
[14:54] <mac_v> tgpraveen: notify-osd-icons will be a separate package ;)
[14:54] <Amaranth> rickspencer3: upstream is working on a fix for windows disappearing when you change your resolution (like to hook up a projector) so hopefully we can wait for that
[14:54] <seb128> pitti, ok thanks
[14:54] <Amaranth> after that I'll get on his case about a release again :)
[14:54] <MacSlow> mac_v, I certainly can remember not working on the wifi-applet (or nm-applet)
[14:54] <rickspencer3> Amaranth, is their an eta on that? asking so I can prepare a smooth landing strip for it :)
[14:55] <MacSlow> kwwii, mac_v: maybe if briefly talked with asac about this last cycle... but really not sure atm.
[14:55] <Amaranth> rickspencer3: hopefully later today
[14:55] <rickspencer3> Amaranth, kewl
[14:55] <rickspencer3> thanks for the info
[14:55] <rickspencer3> not to mention, thanks for compiz ;)
[14:56] <Amaranth> Would have to get mvo to make the snapshots and upload though
[14:56] <rickspencer3> hmm
[14:56] <rickspencer3> ok
[14:56] <seb128> no mvo today apparently though
[14:56] <mac_v> MacSlow: yeah , thats what you said... that is the place where the applet-device-wifi.c is where notify-osd does the icon switch for nm-applet , similar needs to be done for gpm
[14:56] <rickspencer3> anything else we can do to help it go smoothly?
[14:56] <seb128> hey rickspencer3
[14:56] <Amaranth> I have no upload rights and no one else has done it before
[14:56] <rickspencer3> hi seb128
[14:56] <asac> MacSlow: whats that about?
[14:57] <asac> nevermind
[14:57] <Amaranth> rickspencer3: I don't think so
[14:57] <MacSlow> asac, icon-names passed to notify-osd from nm-applet
[14:58] <rickspencer3> pitti, seb128 kenvandine anytonewhowouldknow - are we still expecting new icons from design team?
[14:58] <MacSlow> mac_v, again... there's no line of code in notify-osd that explicitly alters passed icon-names (be it filenames or symbolic names)
[14:58] <seb128> rickspencer3, I don't know
[14:58] <mac_v> MacSlow: oh... ok :)
[14:58] <pitti> kwwii, mac_v: are there new/fixed icons planed?
[14:58] <kwwii> MacSlow: something somewhere is making it look up notification-* for the notify-osd bubbles before the otehr names
[14:59] <mac_v> pitti: fixed icons? for which app
[14:59] <kenvandine> rickspencer3, i hope at least something better for draw-attention in the indicator
[14:59] <kwwii> pitti: the icons are already in the notify-osd set, we updated them a long time ago
[14:59] <pitti> mac_v: any; rickspencer3 just asked about the plan
[14:59] <MacSlow> kwwii, mac_v: such things have to happen in the app tossing out notifications via libnotify (thus reaching notify-osd) but not notify-osd itself
[15:00] <kwwii> pitti, mac_v, MacSlow, asac: the problem now is that the battery icons are not using notification-* for notify-osd, but using the normal panel (gpm-*) icons instead
[15:00] <mac_v> pitti: kwwii: then gpm needs to be patched to send the right label for  notifications
[15:00] <mac_v> rickspencer3: new icons in the sense?
[15:02] <seb128> we do have a patch to use notification-display-brightness-* for notify-osd
[15:04] <pitti> kwwii: to be precise, gpm-* are private names for g-p-m, they aren't/sholdn't be in a theme
[15:04] <kwwii> pitti: they are in all themes, for a long time :p
[15:04] <mac_v> kwwii: pitti: the reason those labels werent patched until now  or  for jaunty  , was because the notifications themselves were blocked[since they were considered redundant] , but now the notifications have improved and are not blocked...
[15:04] <seb128> what is the issue there?
[15:05] <kwwii> and links are created from them as well often
[15:05] <pitti> kwwii: oh, so themes in /usr/share/icons/ can override ones in /usr/share/appname/icons?
[15:05] <kwwii> seb128: the brightness stuff works perfect
[15:05] <seb128> the gpm code seems to be right
[15:05] <kwwii> pitti: yes
[15:05] <pitti> kwwii: well, as I said, I'm an icon n00b, sorry
[15:05] <kwwii> pitti: hehe, worries :)
[15:06] <tgpraveen> does anyone know if the notifications for media eject/unmount all the times was don e or not?it was a papercut
[15:06] <tgpraveen> iirc
[15:06] <kwwii> pitti: I am a n00b at everything else :D
[15:06] <mac_v> tgpraveen: no
[15:06] <seb128> the brightness icons don't seem right
[15:06] <seb128> there is only one monitor one used and not changing
[15:06] <kwwii> seb128: on my karmic, when I change brightness the notification uses the correct icons
[15:07] <seb128> weird
[15:07] <seb128> the code uses notification-display-brightness-*
[15:07] <kwwii> volume as well
[15:07] <kwwii> seb128: yes, it should
[15:07] <seb128> and there is no such icons in the humanity theme in karmic
[15:07] <mac_v> seb128: those or notify-osd labels
[15:07] <kwwii> seb128: no, they were moved to /usr/share/notify-osd/icons/gnome/
[15:07] <mac_v> s/orare
[15:07] <mac_v> sor/are
[15:07] <seb128> $ find /usr/share/notify-osd/icons -name notification-display-brightness*
[15:07] <seb128> /usr/share/notify-osd/icons/hicolor/scalable/status/notification-display-brightness.svg
[15:07] <seb128> $
[15:08] <seb128> there is one
[15:08] <seb128> ie no variants as human had
[15:08] <seb128> notify-osd-icons didn't get installed there
[15:09] <seb128> weird
[15:09] <mac_v> seb128: do you have notify-osd-icons package installed?
[15:09] <seb128> should something install it on upgrade?
[15:09] <mac_v> ah! ;)
[15:10] <mac_v> seb128: it should , but didnt install for me either, but pitti said that the dependencies were correct....  shouldnt they be part of the ubuntu-desktop?
[15:11] <seb128> well the dependency has a | human-icon-theme
[15:11] <pitti> ah
[15:11] <seb128> and this one doesn't get remove on upgrade
[15:11] <seb128> removed
[15:11] <pitti> so it's because human-icon-theme wasn't cleaned on upgrade
[15:11] <seb128> yes
[15:11] <pitti> so, if we want to officially bury human-icon-theme, I'm fine with dropping the |
[15:12] <pitti> but actually h-i-t should work as well?
[15:12] <seb128> it does work
[15:12] <pitti> anyway, it's cleaner to drop the alternative
[15:12] <seb128> wrong clicking there
[15:12] <pitti> but at least it now explains why you guys didn't get it automatically
[15:13] <seb128> it's just a recommends so yes
[15:13]  * pitti fixes
[15:13] <seb128> the people who want to keep using human can clean the recommends if they want
[15:13] <pitti> pushed
[15:14] <pitti> $ head -n1 */debian/changelog|grep UNRELEASED|wc -l
[15:14] <pitti> 12
[15:14] <pitti> hmm, lots of stuff to upload after beta freeze :)
[15:14] <kwwii> pitti: erm, what about upgrades? will they also get humanity and not human?
[15:15] <pitti> kwwii: yes, the human-theme dependency was switched from human to humanity
[15:15] <asac> MacSlow: kwwii: http://pastebin.com/f1c1c4ba7 those are the notification icon changes we currently carry
[15:15] <kwwii> pitti: and even when notify-osd is installed it does not show the correct notification-battery-* icons
[15:15] <seb128> what notifications are those?
[15:16] <kwwii> asac: right, those are the network icons
[15:17] <asac> kwwii: so those are ok still?
[15:17] <mac_v> asac: why does it send the *-full for all signal strengths? cant it send the right signal?
[15:17] <kwwii> asac: yes, they should be...I cannot test them because network manager, although it works, does not appear at all :p
[15:17] <MacSlow> asac, thanks for the pointer
[15:18] <kwwii> so someone needs to add that same kind of thing to the battery icons
[15:18] <kwwii> s/to/for
[15:19] <mac_v> MacSlow: lol! ,oops that was the patch in nm-applet ... i was mislead by the comment on lp..sorry :)
[15:20] <MacSlow> kwwii, I'm still in bug-fixing mode for notify-osd and I also have a regression for g-p-m to do
[15:20] <MacSlow> mac_v, at least my memory isn't failing me
[15:20] <mac_v> ;)
[15:21] <asac> ŝo ... is any help needed on the gpm thing (feels like there are quite a few hands on that now)?
[15:21] <kwwii> MacSlow: cool, thanks
[15:21] <seb128> so
[15:22] <seb128> what gpm bubbles have wrong icons?
[15:22] <seb128> and do you know which ones are being used?
[15:22] <asac> ok ... unless someone asks me specifically to look at gpm i assume that seb128 or someone else is on that ;)
[15:23] <seb128> I would if somebody could explain what is wrong
[15:24] <mac_v> seb128: gpm-battery-* should be relabeled to notification-battery-*
[15:24] <mac_v> in gom
[15:24] <mac_v> gpm*
[15:24] <seb128> why?
[15:25] <seb128> why do you don't use the right naming in your theme?
[15:25] <seb128> rather than asking to change the code which will breaks other themes
[15:25] <asac> i think our best practice is to ship a link in theme
[15:25] <mac_v> seb128: because the notifications need to use the notify-osd specific names... these icons will then be used else where in the apps ... and they wont be visible
[15:26] <asac> unless we need something to be completely different
[15:26] <seb128> mac_v, why?
[15:26] <seb128> mac_v, what about people who don't use notify-osd?
[15:27] <mac_v> seb128: for those who dont use notify-osd , the patch wont apply... i'm not sure how nm-applrt does it.. asac must know
[15:27] <asac> seb128: i think its not notify-osd specific. its really about being able to have different icons in the notifications than the ones used in the app
[15:27] <seb128> icons which are implemented by no theme out of the ubuntu one though
[15:27] <asac> mac_v: we are shipping the same icons in hicolor/scalable now
[15:27] <asac> but thats a messy situation for sure
[15:27] <seb128> since the naming is not a standard one
[15:28] <asac> its the same problem as the try greyscale thing
[15:28] <mac_v> asac: no..that is differne
[15:28] <seb128> the notification area icons you mean?
[15:28] <asac> you need some standard that says that notification icons should be different than the one used in apps and the one in tray
[15:28] <seb128> no, those use icon theme fallback to work
[15:28] <asac> otherwise upstream will say: "yes, thats ubuntu specific"
[15:28] <seb128> ie the specific icons should be name
[15:28] <seb128> "upstream-name-osd"
[15:28] <seb128> so the fallback works for theme which just have the upstream naming
[15:29] <asac> seb128: i dont think he asks for osd specific naming. he wants just upstream-name-notification
[15:29] <asac> so they can use different icons
[15:29] <seb128> right
[15:29] <seb128> though they don't have that naming now
 seb128: gpm-battery-* should be relabeled to notification-battery-*
[15:29] <asac> right
[15:29] <asac> its definitly wrong
[15:29] <seb128> it's backward
[15:30] <seb128> and it doesn't do fallbacking
[15:30] <kwwii> seb128: we added the notification-* name, and yes, we do want everyone to use it for things like notify-osd
[15:30] <mac_v> seb128: something like this is needed for gpm > http://pastebin.com/f1c1c4ba7
[15:30] <asac> so theme should use gpm-name-notify ... and upstream can just ship gpm-name
[15:30] <seb128> yes
[15:30] <kwwii> gpm-name if for the app, whereever it puts icons, notification-* is only for notify-osd (and perhaps other things like it)
[15:31] <asac> kwwii: you should just ship the icon name used by upstream and _append_ -notify rather than prepend it
[15:31] <popey> MacSlow: does notify-osd cache the picture? I am skipping tracks in rhythmbox and seeing the same image (album cover) for lots of different artists.. restarted rb and get the rb icon for something with no art, now i skip tracks it shows icons until i bring rb to the front then minimise, then notify shows no icons at all..
[15:31] <seb128> what is the difference between notify-osd and notification-daemon?
[15:31] <asac> there is no difference imo
[15:31] <seb128> why notify-osd needs icons specific to it?
[15:31] <asac> just that the innitial names didnt think about the fallback approach
[15:31] <mac_v> seb128: it was a design  ;)
[15:31] <MacSlow> seb128, styling
[15:31] <MacSlow> :)
[15:31] <kwwii> asac: but that would theoretically, allow the apps to fallback to the notify icons for other uses which is bad
[15:32] <seb128> that's getting confusing
[15:32] <MacSlow> popey, yes and no :)
[15:32] <popey> MacSlow: shall i file a bug sgainst this?
[15:32] <mac_v> seb128: https://wiki.ubuntu.com/NotifyOSD#Icon ,
[15:32] <kwwii> maybe I should add this to the icon naming spec and be done with it :D
[15:32] <mac_v> kwwii: hehe ;p
[15:32] <seb128> whoever want that change should open a bug
[15:32] <seb128> explaining the issue and giving a specific example
[15:32] <MacSlow> popey, well it's actually against rb
[15:32] <seb128> with icon name and screenshot
[15:32] <seb128> I can look at it from there
[15:32] <MacSlow> popey, notify-osd will display whatever icon it gets from rb
[15:33] <asac> i have the feeling that what they want is to ship icons that only notify-osd will use
[15:33] <seb128> but what you explain there doesn't seem something we want to do
[15:33] <asac> so for that the solution is simple
[15:33] <popey> MacSlow: ok, will do, thanks
[15:33] <asac> or not ;)
[15:33] <seb128> asac, it's breaking other usecases
[15:33] <kwwii> seb128: well, as maintainer of the spec, I guess I could just change it
[15:33] <asac> well if they send the name over the wire notify-osd should modify the name
[15:33] <seb128> kwwii, it's too late to changing a spec or an implementation in karmic
[15:33] <kwwii> but, of course we could start a discussion first
[15:33] <MacSlow> popey, if it gets a new icon it'll display that... if the next/new notification does not provide one (and isn't replacing an existing notification) it'll only be title- and body-text.
[15:33] <asac> like i say: show "gpm-name-notify" ... then notify-osd can try o nits side to look for "nofiy-osd-gpm-name-notify" first
[15:33] <seb128> I don't understand the issue
[15:34] <seb128> asac, I agree with that yes
[15:34] <mac_v> asac: exactly ,what is said ;) ,
[15:34] <asac> if that doesnt work the normal fallacdk woould start: "gpm-name-notify" -> "gpm-name" -> "gpm"
[15:34] <MacSlow> popey, there's a dedicated example of updating existing bubbles with different layouts in notify-osd trunk (notify-osd/examples/
[15:34] <seb128> it doesn't seem something we should change in upstream code now
[15:34] <asac> mac_v: no. we are asked to patch the apps atm
[15:34] <MacSlow> popey, there's a dedicated example of updating existing bubbles with different layouts in notify-osd trunk (notify-osd/examples/update-notifications.py)
[15:34] <seb128> notify-osd should do namin translations
[15:35] <asac> thats wrong ... if we want notify-osd specific icons the apps hsouldnt have to be patched
[15:35] <kwwii> seb128: sure, I realize that
[15:35] <seb128> since that's notify-osd specific
[15:35] <mac_v> asac:  i agree , you need to convince MacSlow
[15:35]  * MacSlow is deaf on the eyes atm
[15:35] <mac_v> asac: its is easier than patching every app on the planet!
[15:35] <seb128> let's convince davidbarth
[15:35] <kwwii> if everything followed the icon naming spec with the naming heirarchy things would just work
[15:35] <MacSlow> popey, you can add that hint to the bug-report you're filing
[15:36] <asac> kwwii: yes. but the name used by the apps wouldnt have to be prefixed with "notification-" ... thats notify-osd business only
[15:36] <asac> apps should use gpm-name-notify1 gpm-name-notifyreason2 etc.
[15:37] <kwwii> asac: hrm, I guess we could discuss that in the bug about the fdo icon naming spec
[15:37] <kwwii> :)
[15:38] <seb128> the naming is not revelent there
[15:38] <seb128> using notify-osd specific icon names for notification is wrong
[15:38] <seb128> the code needs to work on other notification systems too
[15:38] <mac_v> kwwii: seb128: asac: IMO , notify-osd needs to recognize the standard labels sent by the apps and convert it to the notification-* icons... i'v been saying this for very long... but MacSlow insists the apps need to be patched :(
[15:39] <MacSlow> mac_v, "labels" ?
[15:40] <mac_v> MacSlow: the network-* , or the gpm-* or the im-*
[15:40] <asac> icon_themeame
[15:40] <asac> icon-themename
[15:40] <kwwii> asac: ?
[15:42] <asac> nevermind. i will check notify-osd code later today t see whats going on.
[15:42] <asac> kwwii: where is that icon spec
[15:42] <asac> ?
[15:42] <popey> MacSlow: filed bug 440027, thanks :)
[15:43] <asac> got it http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
[15:43] <seb128> popey, it's a duplicate I think
[15:43] <mac_v> asac: kwwii: MacSlow: we cant expect every app to maintain patches just because Ubuntu has a new notification system! there will always be breakage in some app! , it is better to make notify-osd identify the standard icon names, and the make the icon switch in notify-osd rather than patching the apps to use notify-osd specific names
[15:43] <popey> seb128: i saw one from hardy, but not a current one
[15:43] <popey> seb128: you know best though :)
[15:44] <seb128> popey, bug #426256?
[15:44] <asac> mac_v: dont tell. me i am reading the spec atm. there is nothing about prefixing stuff
[15:44] <seb128> popey, it's the first result in google for rhythmbox notification launchpad...
[15:45] <asac> i think ... i think they tried to standardize that all notification stuff should use notification- prefix
[15:45] <asac> but its definitly not something that would be app specific
[15:45] <seb128> but why not simply using the fallback naming?
[15:45] <seb128> ie icon-notificication
[15:46] <seb128> it will fallback to icon if the notification variant is not there
[15:46] <asac> seb128: no. i think the notification- prefix is supposed to be something like "emblem-"
[15:46] <asac> seb128: i think there are two separate issues mixed up here.
[15:46] <seb128> well, it seems something that should be defined first
[15:46] <seb128> then applied upstream
[15:46] <seb128> then be applied in ubuntu
[15:46] <asac> a) standardize all notification to use notification- prefix
[15:46] <asac> b) notifiy-osd specific icons
[15:46] <asac> a) -> no way to do that in patches until its getting in that spe
[15:47] <asac> at least not without breaking stuff
[15:47] <seb128> well, a) seems upstream specifications changes
[15:47] <seb128> not a karmic post beta thing
[15:47] <asac> b) -> do someting about that on notify-osd
[15:47] <asac> seb128: yes
[15:47] <seb128> ok, we are in agreement
[15:47] <asac> i will check the notify-osd part
[15:48] <seb128> thanks
[15:48] <asac> until a) happened we can use notification- as a notify-osd specific prefix
[15:48] <asac> but thats notify-osd business afaict
[15:49] <pitti> seb128: do you happen to know how I can start the audio mixer dialog thingy from a command line?
[15:49] <pitti> i. e. what its name is?
[15:49] <seb128> pitti, gnome-volume-control
[15:49] <pitti> ah, thanks
[15:49] <seb128> pitti, if that's the one you want
[15:52] <pitti> seb128: right, worked; thanks!
[15:52] <popey> seb128: yup, you're right, thanks, image is 600x578px, I'll mark as dupe
[15:52] <seb128> popey, thanks
[15:53] <popey> side benefit, I now know where rb stores the covers :)
[15:55] <davidbarth> seb128: reading the log
[16:06] <asac> http://pastebin.com/f4c1c6714
[16:06] <asac> patch for notify-osd
[16:06] <asac> seb128: ^^
[16:06] <asac> tested with notify-send -i battery-low "test message"
[16:06] <asac> without that it displays the battery-low ... with that patch it goes to notification-battery-low
[16:09] <asac> pushed to lp:~asac/notify-osd/theme-icon-prefix
[16:10] <seb128> asac, excellent
[16:10] <asac> so basically this means that notify-osd specific icons should just use the same name used by the app, but prefix it with notification- (or whatever we decide the prefix to be)
[16:21]  * hyperair makes some noise about bug #439956
[16:22] <asac> hyperair: thast fixed in trunk ppa
[16:22] <asac> https://edge.launchpad.net/~network-manager/+archive/trunk
[16:22] <hyperair> ooh that is?
[16:22]  * hyperair adds the pap
[16:22] <hyperair> ppa*
[16:22] <asac> almost all editor bugs are fixed there
[16:22] <hyperair> i see. that's great.
[16:22] <hyperair> will it be entering ubuntu soon?
[16:23] <asac> only secrets are left for fix
[16:23] <asac> hyperair: right after beta
[16:23] <hyperair> ah.
[16:23] <hyperair> what secrets?
[16:23] <asac> secrets are not displayed in editor
[16:24] <asac> but that fix will maye land today
[16:24] <davmor2> hyperair: have to kill you if we tell you the secrets
[16:24] <asac> so it might be fixed tomorrow
[16:28] <hyperair> i see.
[16:28]  * hyperair sends an assassin for davmor2 
[16:29] <chrisccoulson> wow, i just got given something free from work
[16:29] <chrisccoulson> ....a pen!
[16:30] <davmor2> chrisccoulson: shhhh or everyone will won't one and they'll claim yours back to give to someone else
[16:30] <chrisccoulson> lol, that's ok - they can exchange it for a laptop instead;)
[16:32] <asac> yesterday my thinkpad started to make strange sounds (clicking)
[16:32] <asac> anyone else sees that?
[16:36] <Amaranth> asac: fan or HD?
[16:36] <asac> i dont know where that comes from. it sound a bit like its coming out of the speakers
[16:37] <asac> sounds a bit like the sound that i get when the system turns off
[16:37] <asac> completely
[16:37] <Amaranth> does it only do it after you leave the computer alone for a bit?
[16:37] <Amaranth> could be from the sound chip being turned off
[16:38] <asac> it feels it happens more frequently while typing.
[16:38] <Amaranth> ah, no then
[16:38] <asac> but i couldnt find any definite reason
[16:38] <Amaranth> make backups
[16:38] <asac> Amaranth: sound chip turning off sounds likely
[16:38] <asac> Amaranth: is there a way to do that manually so i can compare?
[16:38] <Amaranth> hmm
[16:38] <Amaranth> let me check
[16:38] <jmarsden> asac: Hard drive head unloading/parking?  If it is the HD... make backups *now*!
[16:39] <Amaranth> but this should only be happening at worst every 10 seconds (power down, sound event so power up, repeat)
[16:39] <asac> yes. its not more than every 10 seconds
[16:41] <asac> jmarsden: the sound doesnt feel like its coming from the HD. its not coming from the same area where the other harddrive stuff is coming from.
[16:41] <asac> but i will check what i need to back up anyway i aguess ;)
[16:42] <Amaranth> I have no idea how to turn it on/off
[16:42] <Amaranth> dtchen or TheMuso might
[16:42] <asac> kk
[16:42] <asac> dtchen: TheMuso: how can i power down/up my soundchip ;) (thinkpad X61 etc.)
[16:42] <asac> ?
[16:45] <asac> let me turn off sound in bios if thats possible
[16:45]  * asac reboots
[17:03]  * asac not happy about lenovo bios not allowing to turn off sound chip ... 
[17:03] <asac> anyway. out for now. will check later tonight whats going on ;)
[17:43] <pitti> asac, kenvandine: is either of you online tomorrow 1500 UTC? I'm away, and need someone to cover desktop in the release meeting (I'll prepare our report, of course, so it is just for questions)
[17:43] <kenvandine> i will be here, but i might have a meeting
[18:32] <SiDi> asac: hi there. do you still maintain the gnash PPA ?
[18:41] <rickspencer3-afk> SiDi, I think asac may be off for the night
[18:41] <SiDi> rickspencer3-afk: okey, thanks
[19:41] <GahocIT> Hello everybody
[19:41] <GahocIT> please help me
[19:41] <GahocIT> what is error
[19:42] <GahocIT> http://i81.servimg.com/u/f81/11/91/56/19/p1000610.jpg
[19:45] <Amaranth> dead HD :/
[20:50]  * Ng marvels at his notification area
[20:50] <Ng> it looks really good
[20:51] <rickspencer3> kenvandine, hellooooo
[20:51] <jono> kenvandine, around?
[20:51] <kenvandine> hey
[20:51] <kenvandine> yes?
[20:51] <jono> kenvandine, rick and I were testing Empathy
[20:52] <rickspencer3> so, jono and I aren't having much luck
[20:52] <jono> are there any fixes in the pipe
[20:52] <jono> ?
[20:52] <kenvandine> no
[20:52] <rickspencer3> jono, what is your account type?
[20:52] <kenvandine> it is upnp problems most likely
[20:52] <jono> rickspencer3, gchat
[20:52] <kenvandine> is it @gmail.com?
[20:52] <jono> my jabber isnt working there it seems
[20:52] <jono> gmail.com
[20:52] <kenvandine> ok
[20:52] <kenvandine> is upnp enabled in your router?
[20:52] <rickspencer3> so gchat to jabber.org ... it connects for like one frame, and then disconnects
[20:52] <jono> kenvandine, no idea, let me check
[20:53] <kenvandine> that sounds like upnp
[20:53] <rickspencer3> jeez
[20:53] <kenvandine> unfortunately for video or audio to really work you need upnp
[20:53] <rickspencer3> how does one explain this to users?
[20:53] <kenvandine> no idea
[20:53] <kenvandine> i think we need a way to tell them at run time
[20:53] <rickspencer3> ah, I see it is on for me
[20:53] <kenvandine> yeah
[20:54] <kenvandine> and from what i hear... it is commonly on by default in most routers now
[20:54] <rickspencer3> I don't recall configuring it myself
[20:54] <jono> on a side note, I am getting weird notify-osd problems where the volume control sticks to the screen
[20:54] <jono> and never fades away
[20:54] <kenvandine> but like my old one i have it wasn't until i prodded it a couple weeks ago
[20:54] <kenvandine> MacSlow, ^^
[20:55] <jono> kenvandine, it is enabled
[20:55] <kenvandine> jono, i found the problem i was having was upnp madness on my local network
[20:55] <kenvandine> humm
[20:55] <kenvandine> jono, let me call you
[20:56] <kenvandine> ring... ring
[20:57] <kenvandine> rickspencer3, what kind of symptoms did you guys see?
[20:57] <jono> kenvandine, it said connecting for quoite a while
[20:57] <jono> showed my video
[20:57] <rickspencer3> if jono called me, I could answer ...
[20:57] <MacSlow> jono, hm...
[20:57] <rickspencer3> then I could see if face and hear like 300 ms of soud
[20:57] <rickspencer3> and then it kind of disconnected
[20:57] <MacSlow> jono, since when do you experience this weird behaviour?
[20:58] <MacSlow> jono, does that happen all the time?
[20:58] <jono> MacSlow, oh, banshee had hung
[20:58] <jono> and it seemed to hang notify-osd too
[20:59] <kenvandine> jono, the log you had sent me last time showed empathy couldn't access your sound device
[20:59] <kenvandine> so like a pulse problem or something
[20:59] <MacSlow> jono, hm... odd... I wonder how that can happen.
[20:59] <kenvandine> but i hadn't seen that with anyone else
[20:59] <rickspencer3> jono, can you record yourself with sound recorder?
[20:59] <rickspencer3> (and play it back)?
[21:00] <MacSlow> jono, which version of notify-osd do you have installed? "dpkg --list notify-osd"
[21:05] <seb128> re
[21:09] <rickspencer3> jono, helloooo
[21:10] <jono> MacSlow, it does whenever banshee hangs
[21:10] <jono> kenvandine, want me to call you?
[21:10] <kenvandine> yeah
[21:11] <jono> hey
[21:11] <jono> sorry my IRC client went bonkers
[21:11] <jono> kenvandine, should we raise more public awareness of testing the A/V in Empathy?
[21:11] <kenvandine> hehe
[21:11] <kenvandine> we should... soon
[21:11] <kenvandine> let me figure out some stuff first
[21:11] <jono> kenvandine, np
[21:11] <kenvandine> like how we can test for upnp and alert the users, etc
[21:12] <kenvandine> jono, you calling me?
[21:12] <rickspencer3> KenEdwards, soon, is like now
[21:12] <kenvandine> haha
[21:12] <rickspencer3> damn xchat completion
[21:12] <rickspencer3> kenvandine, soon, is like now :)
[21:12] <kenvandine> working on it
[21:12] <MacSlow> jono, so when banshee hangs you're not able to trigger any other notification (e.g. press volume up or down, or do "notify-send test bla -i totem")?
[21:12] <rickspencer3> Nov 15th is Freeze for RC
[21:12] <jono> kenvandine, not at the mo
[21:13] <seb128> rickspencer3, Oct?
[21:13] <rickspencer3> seb128, October too, yes
[21:13] <jono> MacSlow, yep
[21:13] <rickspencer3> ;)
[21:13] <KenEdwards> rickspencer3, I think I should change my name  ;-)
[21:13] <rickspencer3> KenEdwards, sorry, I'm using a most unforgiving irc client ;)
[21:13] <jono> I was getting annoyed at that too
[21:13] <seb128> rickspencer3, just curious but was pidgin handling that better and how?
[21:13] <jono> two kens and the world blows up :P
[21:13] <MacSlow> jono, I've no idea how an app freezing can take notify-osd with it... there's just dbus between them
[21:14] <kenvandine> jono, are you getting my calls?
[21:14] <rickspencer3> seb128, with pidgin it writes a list of the ambiguous ones
[21:14] <jono> kenvandine, I answered one since I logged back on IRC
[21:14] <seb128> rickspencer3, ah, same in xchat-gnome
[21:14] <rickspencer3> so if I do "ken"<tab> it writes "kenvandine KenEdwards"
[21:14] <seb128> rickspencer3, I think it's a setting in xchat but not sure, that's what you get for using the non gnome version ;-)
[21:14] <rickspencer3> isn't that what I'm using?
[21:14] <kenvandine> rickspencer3, got a better idea?
[21:14] <rickspencer3> dang it
[21:14] <rickspencer3> I had no idea
[21:14] <jono> kenvandine, just got a call
[21:14] <seb128> rickspencer3, I guess you use xchat and not xchat-gnome?
[21:14] <kenvandine> jono, what happened?
[21:15]  * rickspencer3 checks
[21:15] <jono> kenvandine, it showed my video, tried to connect and then closed the window
[21:15] <kenvandine> humm
[21:15] <seb128> rickspencer3, easy to notice xchat-gnome has no user list on screen and channel on the left
[21:15] <kenvandine> you call me please
[21:15] <jono> one sec
[21:15] <rickspencer3> what a dope I am
[21:15]  * rickspencer3 tries xchat-gnome
[21:16] <jono> kenvandine, ooh, it showed a black window for your video for a second and then closed
[21:16] <kenvandine> humm
[21:16] <jono> thats what rickspencer3 and I were getting I think
[21:16] <rickspencer3> same thing
[21:16] <kenvandine> ok
[21:16] <seb128> rickspencer3, enable the osd option in the preference if you try it and want bubbles
[21:16] <rickspencer3> seb128, will do
[21:16] <jono> rickspencer3, fancy trying pidgen?
[21:16] <kenvandine> jono quit empathy
[21:16] <kenvandine> EMPATHY_LOGFILE=/tmp/empathy.log GST_DEBUG=\*fsrtp\*:5 EMPATHY_DEBUG=all empathy
[21:16] <rickspencer3> jono, no I don't have that installed atm
[21:16] <kenvandine> and run that
[21:16] <rickspencer3> jono, there is something about your configuration
[21:16]  * seb128 wonders when they will accept things waiting now that beta is there
[21:17] <rickspencer3> we should figure it out
[21:17] <jono> kenvandine, call you?
[21:17] <rickspencer3> seb128, good question, perhaps steve is asleep finally though
[21:17] <kenvandine> yeah
[21:17] <kenvandine> jono, go ahead
[21:17] <kenvandine> crash?
[21:17] <kenvandine> jono, now send me /tmp/empathy.log
[21:18] <jono> no crash, just disconnected
[21:18] <jono> ok, one sec
[21:18] <tgpraveen> if jono has config prob maybe rickspencer3 and kenvandine could try calling
[21:18] <kenvandine> works for us
[21:19]  * tgpraveen never gets audio working in empathy for last few releases
[21:19] <tgpraveen> last it worked in hardy I think
[21:20] <tgpraveen> well there are many people who are having problems with a/v chat in empathy , first blamed on pulse but fixed there now.
[21:20] <tgpraveen> maybe it does require more community testing
[21:20] <rickspencer3> tgpraveen, yes, I agree
[21:23] <jono> kenvandine, on its way
[21:25] <kenvandine> jono, had your sound-recorder test worked?
[21:25] <jono> let me test
[21:26] <jono> kenvandine, works fine
[21:26] <kenvandine> ok
[21:26]  * kenvandine waits for the email
[21:31] <bratsche> seb128: I was thinking of making some gtk+ packages with Company's filesystemmodel branch merged in and trying to get some Ubuntu community testing for it.  mclasen seems interested in trying to get this merged into master for 2.18.2 if there is some good testing and review.  Is there a better place to put such packages than my own PPA?
[21:32] <jono> kenvandine, email arrived?
[21:32] <seb128> bratsche, not really, we could use the ubuntu-desktop ppa but that's a small difference
[21:32] <seb128> bratsche, I really think that landing such changes in stable series is not a good idea though
[21:33] <seb128> bratsche, ie we will not do the 2.18.2 update in karmic with such changes
[21:33] <seb128> bratsche, ie we will not do the 2.18.2 update in karmic with such changes
[21:33] <seb128> bratsche, ups, sorry about the double line there ;-)
[21:34] <bratsche> seb128: That's fine, but I still think doing this could be a service to gtk+ upstream and that makes it worthwhile to me.
[21:34] <seb128> bratsche, not discussing that
[21:35] <mclasen_> seb128: to each his own...
[21:35] <seb128> I don't think many user run the ubuntu-desktop ppa and you want to make a call for testing for such changes anyway
[21:35] <kenvandine> jono, yeah
[21:35] <seb128> bratsche, so you can as well use your ppa and announce it
[21:35] <jono> kenvandine, cool
[21:36] <jono> kenvandine, ok let me know if you want me to make some noise about Empathy testing
[21:36] <kenvandine> tp-fs-Message: tf_stream_error: stream error errorno=7 error=Resource Unavailable
[21:36] <jono> I was planning a blog entry to identify key features for testing in Karmic
[21:36] <kenvandine> cool
[21:36] <kenvandine> jono, lets talk tomorrow morning ok?
[21:37] <jono> kenvandine, np
[21:37] <seb128> there was some upstream bug contact or triager who asked several time there recent about organizing a test day or something
[21:37] <seb128> he emailed the list too I think
[21:37] <jono> kenvandine, so hold back announcing anything?
[21:37] <seb128> but he didn't really get a replu
[21:37] <seb128> reply
[21:37] <kenvandine> jono, well go ahead
[21:37] <kenvandine> it's fine
[21:37] <seb128> jono, kenvandine: ^
[21:37] <kenvandine> i just want to figure out how we can programatically tell users upnp isn't working on their network
[21:38] <kenvandine> seb128, yeah we should find him
[21:38] <seb128> did you read his email about triaging empathy bugs?
[21:38] <jono> cool
[21:39] <jono> seb128, sounds like a good
[21:39] <jono> idea
[21:39] <jono> maybe we can ask people to test it as part of the global jam
[21:56] <jcastro> bratsche: holler at me when you get that gtk thing in a PPA, I am keen on helping upstream get testing on that
[21:56] <rickspencer3> seb128, any idea why bug 290471 is still open?
[21:57] <jcastro> bratsche: also, I think that having a crack GNOME-tech PPA stuff that you and ken can put stuff into would be great instead of random individual PPAs
[21:58] <seb128> rickspencer3, not really, maybe check with robert_ancell it seems from comments it should be closed, though I have it in the notification area still there
[21:58] <bratsche> jcastro: Yeah, that sounds awesome.  I need you or ken to post on Planet Ubuntu about this anyway once I build some packages, because I don't think I'm on that planet.
[21:59] <rickspencer3> seb128, k
[22:00] <jcastro> bratsche: ok
[22:00] <kenvandine> me either
[22:00] <kenvandine> :)
[22:00] <seb128> jcastro, not sure about that, you don't always want to mix cracks and you need to advertise things to get proper feedback anyway
[22:01] <kenvandine> i like to categorize stuff
[22:01] <chrisccoulson> seb128 - i've added python-gnome2-extras back to gnome-python-extras again
[22:01] <kenvandine> like i created my desktopcouch ppa
[22:01] <seb128> chrisccoulson, thanks, will not be for tonight for me though
[22:01] <kenvandine> so things you might need to get dc crack all all there
[22:01] <chrisccoulson> seb128 - no problem ;)
[22:03] <jcastro> seb128: ok I'll discuss the least crackful way with ken/cody
[22:25] <mac_v> lool: hi...
[22:25] <mac_v> i dint understand your mail  > "can you prepare a 0.3.1 + only the important fixes branch?"
[22:26] <mac_v> all the fixes are important... they have been done only due to the directions from the UX team... and separating them is not possible
[22:26] <mac_v> lool: also we have released 0.4 > https://launchpad.net/humanity/+download
[22:33] <lool> mac_v: 100+ fixes?
[22:33] <lool> mac_v: To me it's unreviewable
[22:33] <mac_v> lool: we have added *several* new icons
[22:33] <mac_v> that was done after the request of UX
[22:34] <lool> mac_v: At this stage of the cycle, I need to be in a position to understand the full changes I'm pushing
[22:34] <mac_v> and the changes were done after they requested it
[22:34] <lool> If I need to look at 100+ changes, it's unlikely
[22:34] <mac_v> lool: we pushed for a single icon change too.. so it now really 100 fixes
[22:34] <lool> mac_v: So how I can tell?
[22:35] <mac_v> the UX would say , not not it... and will request a new icon
[22:35] <lool> Pff that sucks big time
[22:35] <mac_v> lool: yeah.. ;)
[22:35] <lool> I mean 3 weeks ago I could possibly have said "Ok, I'll run it for a couple of days and upload it if nothing breaks"
[22:35] <lool> But we're post beta
[22:36] <lool> Things have to stay rock solid and I can't afford a mistake in artwork at this stage you see
[22:36] <lool> I'm really reserved in pushing this
[22:36] <mac_v> lool: the changes were guided by UX.
[22:36] <lool> I mean I had planned to put the time to push the Humanity-Dark/Humanity split, but now I also need to look at a completely new Humanity  :-(
[22:37] <lool> mac_v: Well whoever did the changes, the problem is the same in merging them
[22:38] <seb128> pitti, thanks for the sponsoring ;-) I was just start to look at those dx updates
[22:39] <seb128> pitti, now I can finish my totem udpate and go to bed, you rock ;-)
[22:42] <mac_v> lool: i dont understand the problem? merging problem?
[22:45] <mac_v> lool: also  , the common directory makes sense... doing it now :)
[22:48] <lool> mac_v: The problem is that I can't put my stamp on the changes in that branch
[22:49] <lool> mac_v: Because there are more than I can review in my (limited) time
[22:49] <lool> And this conflicts with our post-beta changes policy
[22:49] <kwwii> lool: problems with icon thems?
[22:49] <lool> seb128: I have a nautilus upload queued up
[22:50] <lool> Yes, but it's 10 before midnight and I'm trying to finish stuff before going to bed; need to go to an event tomorrow too
[22:50] <kwwii> lool: is this an issue of including the -dark theme
[22:50] <kwwii> lool: will you be around tomorrow?
[22:50] <seb128> lool, you know how it works, just update bzr and tag if you upload
[22:51] <kwwii> all I'd like to know is the status of the icon issue in UNR so I get a picture of were you are
[22:51] <kwwii> so that I can help to solve the issue
[22:52] <kwwii> s/were/where
[22:55] <mac_v> kwwii: i think lool wants to review what each rev was...
[22:56] <Amaranth> hmm, looks like someone found a fix for us losing the no backfill patch in xorg that doesn't cause screen corruption, security issues, or slow downs for fglrx users
[22:56] <mac_v> but we just edited single icons and did a push... so there are too many rev :/
[22:56] <kwwii> mac_v: what is the last thing you have submitted?
[22:57] <kwwii> anything new since the addition of -dark
[22:57] <kwwii> ?
[22:57] <mac_v> kwwii: nothing new done to the panel icons , we have only added icons to complete the set
[22:57] <mac_v> or symlinks
[22:57] <kwwii> at this point, anything beyond that should probably be handled with an update
[22:58] <mac_v> there were several symlinks missing.. that was the main issue which was solved
[22:59] <lool> kwwii: the issue is not with the concept of usng a -dark theme
[22:59] <lool> kwwii: It's with the 100+ changes in bzr in lp:humanity ... in 7 days
[23:00] <kwwii> well, it is up to lool if he can work this in somehow. He is responsible for getting this out the door
[23:00] <kwwii> lool: yeah, it should be done in stages, at the approriate times
[23:00] <kwwii> I understand that, but have no control over their submissions
[23:00] <kwwii> I
[23:01] <kwwii> oops
[23:01] <lool> Yes, so I was asking for a 0.3.1 plus selected fixes instead
[23:01] <lool> Can't take 0.3.1 + 100 random bzr commits which I can't review
[23:01] <kwwii> lool: yeah, that is why I said they should keep everything packaged in bzr
[23:02] <kwwii> I'll talk to mac_v and work it out
[23:02] <kwwii> tomorrow ;)
[23:02] <mac_v> :)
[23:02] <kwwii> I'm on the same time zone as you and have to take my son to school in the morning
[23:02] <kwwii> lool: do you have a packaged branch in bzr somewhere?
[23:03] <mac_v> kwwii: actually we just released a package. but lool wanted both the themes in the same package... so rearranging it
[23:04] <mac_v> > https://launchpad.net/humanity/+download
[23:04] <kwwii> mac_v: ok, then needs to be done asap with a really good changelog entry and very quick testing
[23:05]  * mac_v bad with changelogs... looking forward for kwwii's help :) ..... tomorrow ;p
[23:06] <kwwii> I've got to go...24*!, shower, bed, sleep, work, eat..that is my rhthym
[23:06] <kwwii> night
[23:07] <mac_v> nite
[23:19] <mac_v> lool: the revs were also for the bugs reported in lp...
[23:49] <chrisccoulson> TheMuso - i'm confused about bug 440253, or maybe i'm missing something (i'm not a heavy user of audio)
[23:49] <chrisccoulson> but i can enable analog 5.1 etc using gnome-volume-control already
[23:50] <chrisccoulson> (although i can't test if it works, as i only really use the stereo out)
[23:51] <chrisccoulson> in the Hardware tab, there is a "Profile" combo. if i select "Analog Surround 5.1 Output" in there, then I get extra surround options in the Output tab
[23:51] <TheMuso> chrisccoulson: Oh forgot about that.
[23:51] <TheMuso> I guess that says something about how unintuative the UI is.
[23:51] <chrisccoulson> TheMuso - yeah, I agree
[23:52] <chrisccoulson> but it seems that the features are there
[23:53] <lool> kwwii: No, packaging is in the archive
[23:54] <TheMuso> chrisccoulson: I'll update the bug then, thanks for reminding me of that.
[23:54] <chrisccoulson> you're welcome
[23:54] <chrisccoulson> i agree that the UI needs some improvement though
[23:55] <chrisccoulson> it seems to me that the hardware profiles stuff just got shoe-horned in to get the features there
[23:55] <TheMuso> Yeah