[00:00] <rickspencer3> ccheney, how could there be hundreds of files to modify to change one key binding?
[00:00] <robert_ancell> pitti, how do you turn lintian on to get the errors in the gnome-games slpit?
[00:00] <ccheney> rickspencer3: its in each module (eg draw) for each language
[00:00] <rickspencer3> that's insane
[00:00] <ccheney> rickspencer3: but its only in 75 files because it seems the keybindings are currently poorly localized
[00:01] <ccheney> rickspencer3: yep
[00:01] <rickspencer3> ccheney, so how do you know which languages should get changed?
[00:01] <ccheney> should be able to have it done by tomorrow though
[00:01] <ccheney> all of them, heh
[00:01] <ccheney> luckily its an xml file so is easy to understand what to change
[00:01] <rickspencer3> (also, I think it was writer, calc, and impress)
[00:02] <rickspencer3> ccheney, ok
[00:02] <rickspencer3> kewl
[00:02] <ccheney> eg   <accel:item accel:code="KEY_F11" accel:mod1="true" xlink:href=".uno:ActivateStyleApply"/>
[00:02] <TheMuso> eeejay: ok found out why the env variable is not being set.
[00:02] <rickspencer3> TheMuso, robert_ancell it's team meeting time
[00:02] <robert_ancell> ready
[00:02] <rickspencer3> shall we give TheMuso a couple of minutes to finish what he's working on?
[00:03]  * TheMuso is ready.
[00:04] <rickspencer3> I actually got the meeting page updated just now!
[00:04] <TheMuso> cool
[00:04] <rickspencer3> of course, there wasn't much to the meeting
[00:04] <rickspencer3> robert_ancell, ready?
[00:04] <robert_ancell> yes
[00:04] <rickspencer3> ok
[00:05] <rickspencer3> so no partner update, kubuntu update, or x update today
[00:05] <ccheney> rickspencer3: btw roughly around beta freeze i'll probably have to take a few days off, moving into a new house
[00:05] <TheMuso> ccheney: congrats.
[00:05] <ccheney> rickspencer3: ie ~ Sept 30
[00:05] <ccheney> TheMuso: thanks :)
[00:05] <rickspencer3> ccheney, ok, so long as F11 is for Full Screen by then
[00:05] <ccheney> moving to an area with much better schools, my soon will be starting pre-k next year
[00:05] <rickspencer3> (j/k) ;)
[00:05] <ccheney> rickspencer3: heh yea should work by tomorrow :)
[00:05] <rickspencer3> so we talked about two things:
[00:06] <rickspencer3> 1. Pidgin vs. Empathy
[00:06] <rickspencer3> you can read the discussion
[00:06] <rickspencer3> any thoughts?
[00:06]  * ccheney apologizes for interrupting the eastern meeting, shuts up now
[00:06] <TheMuso> Empathy is pretty much accessible out of the box, however on the orca side, no work has been done yet to make orca play nice with empathy, i.e read most recent messages you are sent, etc. Pidgin still works fine in that regard.
[00:07] <robert_ancell> haven't used either enough to comment
[00:07] <TheMuso> i.e orca has functionality to provide  users the ability to use pidgin well, being able to read last sent messages, etc.
[00:07] <rickspencer3> ccheney, no problems, you are welcome here :)
[00:07] <c_korn> chrisccoulson: thanks for your help about the gconf listeners thingy. I think my patch will make it into karmic :)
[00:07] <rickspencer3> TheMuso, do you consider Empathy sufficiently acccessible?
[00:08] <TheMuso> rickspencer3: Because orca doesn't yet help users make use of empathy, probably not, as users will not necessarily like the fact they have to do some manual work to read their messages.
[00:08] <rickspencer3> hmmm
[00:08]  * rickspencer3 adds to cons list
[00:08] <TheMuso> If they were all like me, I'd say yes, but I know they're not. )
[00:09] <rickspencer3> TheMuso, ok
[00:09] <rickspencer3> in general, I am very inclined to stick with the current Plan of Record
[00:09] <rickspencer3> we deliver Empathy on upgrade and new default installs
[00:09] <rickspencer3> on upgrade, we leave pidgin in place
[00:10] <rickspencer3> note that sabdfl was not at all happy with this last point, but I don't see a better way forward considering where we are in the release cycle
[00:10] <rickspencer3> ok, moving on
[00:10] <rickspencer3> bugs
[00:10] <rickspencer3> note that we have some release targetted bugs, including for alpha 6
[00:11] <rickspencer3> ok, neither of you do, but if you did, I would be using my ...
[00:11] <rickspencer3> amazing management ability to motivate you to fix them asap
[00:11] <TheMuso> haha
[00:11] <robert_ancell> :)
[00:11] <TheMuso> More fixes from pulseaudio upstrea will be uploaded today, thanks to Daniel Chen.
[00:12] <robert_ancell> TheMuso, yay.  My pulse is locking up my system all the time currently
[00:12] <rickspencer3> oh fudge, I stomped on robert_ancell's changes
[00:12] <rickspencer3> robert_ancell, really? it seems to be working well flately
[00:12] <robert_ancell> rickspencer3, it was working ok when it was bad for you.  But the last week it has been terrible for me
[00:12] <rickspencer3> robert_ancell, could you please test those pulse changes asap, and let TheMuso know if you still have issues?
[00:12] <robert_ancell> rickspencer3, sure
[00:13] <TheMuso> They will likely go up straight after the meeting.
[00:13] <rickspencer3> robbiew and jono both reported significant improvements
[00:13] <rickspencer3> ok
[00:13] <rickspencer3> any other business?
[00:13] <TheMuso> not from me.
[00:13] <robert_ancell> nope
[00:13] <TheMuso> rickspencer3: Oh do we know when hext UDS is likely to be?
[00:13] <TheMuso> next
[00:14] <rickspencer3> TheMuso, yes, the *when* has been settled for quite some time, and is published on the release calendar
[00:14] <rickspencer3> if you have trouble finding it, please let me know
[00:14] <TheMuso> ok
[00:14] <rickspencer3> the *where* is still up in the air so far as I can tell
[00:14] <rickspencer3> but they say "North America"
[00:15] <TheMuso> ok the when is all I needed to know.
[00:16] <rickspencer3> robert_ancell, I have some questions about a couple of your bugs
[00:16] <rickspencer3> 1. are you still doing that gdm api thing for ted?
[00:16] <rickspencer3> 2. I saw something about the "user list loads slowly" bug, but wasn't sure what the outcome was
[00:16] <rickspencer3>  
[00:16] <robert_ancell> rickspencer3, yes, working on finishing that today.  I expect it will be done by the end of the week
[00:16] <robert_ancell> 2. I made a cache patch for that so there is no delay now
[00:17] <rickspencer3> robert_ancell, sweeeet!
[00:17] <rickspencer3> do you have a bug # for #2?
[00:18] <robert_ancell> bug 400863
[00:18] <TheMuso> rickspencer3: ok nothing set in stone yet, but I'll likely take the first 2 weeks of November off, right before UDS, so I can move into my new place.
[00:19] <rickspencer3> TheMuso, uh
[00:19] <rickspencer3> well ..
[00:19] <rickspencer3> what if there are bugs and such?
[00:19] <rickspencer3> will you be at all available if it comes down to it?
[00:20] <rickspencer3> robert_ancell, it looks like sabdfl would also like to know what it would take to make GDM load faster
[00:20] <TheMuso> rickspencer3: As I said, nothing set in stone, but probably not, as I'll need to get the net up and running for one.
[00:20] <rickspencer3> looking at https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/400863/comments/11
[00:21] <rickspencer3> TheMuso, ok
[00:21] <rickspencer3> I'm sure we can work it out
[00:21] <rickspencer3> there's never and ideal time to take time off
[00:21] <TheMuso> No there isn't.
[00:21] <TheMuso> rickspencer3: If things work out well, I'll be online the second week and can check in once a day or so.
[00:21] <rickspencer3> TheMuso, ok
[00:22] <TheMuso> If not by the middle of the first week.
[00:22] <robert_ancell> rickspencer3, the patch means it now is running at the fastest possible.   I think he's asking (how fast could we start if we don't do the expensive user list lookup)
[00:22] <rickspencer3> robert_ancell, ok
[00:22] <rickspencer3> robert_ancell, is there a bug for more general GDM perf
[00:22] <rickspencer3> ?
[00:22] <robert_ancell> rickspencer3, I don't know of one
[00:22] <rickspencer3> robert_ancell, ok
[00:22] <rickspencer3> thanks for your work on the gdm user list loading, and the api
[00:23] <rickspencer3> this is great work, and very useful and user visible
[00:23] <robert_ancell> no prob
[00:23] <TheMuso> eeejay: Thanks, your first patch is redundant since i've just fixed that, but I'll certainly use the second, thanks again.
[00:23] <rickspencer3> robert_ancell, and I think you are probably right about what sabdfl was asking
[06:45] <pitti> Good morning
[06:45] <pitti> oh, Robert already gone..
[06:46] <hyperair> pitti: are power management keys supposed to work in karmic yet?
[06:47] <pitti> hyperair: "keys"?
[06:47] <hyperair> screen backlight keys, sleep key..
[06:47] <hyperair> my sleep key for some reason is shutting off my screen instead of suspending
[06:48] <pitti> ah; yes, they should absolutely work
[06:48] <hyperair> and my screen backlight keys don't work. backlight can be changed using the screen brightness applet
[06:48] <pitti> hyperair: can you please follow https://wiki.ubuntu.com/Hotkeys/Troubleshooting and then ubuntu-bug udev?
[06:49] <pitti> hyperair: please assign the bug to me
[06:49] <hyperair> pitti: will do
[06:53] <hyperair> pitti: i reached #3 and don't see anything for my brightness keys.
[06:54] <hyperair> pitti: also something interesting is that at usplash, prior to keying in my cryptsetup password, the brightness keys work. after that, they don't
[06:54] <pitti> hyperair: you need step 4 then
[06:55] <hyperair> hmm LENOVO LENOVO3000 Y410
[06:55] <didrocks> hi hyperair, guten Tag pitti
[06:55] <hyperair> hello
[07:00] <hyperair> pitti: i meant i reached #3 of /usr/share/doc/udev/README.keymap.txt
[07:01] <hyperair> pitti: /lib/udev/keymap -i input/event6 isn't seeing the brightness key events
[07:03] <pitti> hyperair: do you have other input devices which could be relevant? (check sudo lsinput)
[07:03] <pitti> many laptops have a "thinkpada extra keys" or "vaio extra keys" device
[07:03] <hyperair> which package?
[07:03] <hyperair> lsinput doesn't exist here =\
[07:03] <pitti> input-utils
[07:08] <hyperair> pitti: no other keyboards
[07:08] <pitti> hyperair: could you try all the other input devices except the obvious ones (like "lid" or "power button")?
[07:08] <hyperair> i also did /lib/udev/keymap -i input/eventX for every event* file in /dev/input.
[07:08] <pitti> ah, ok
[07:08] <hyperair> none of them showed any keycode
[07:09] <pitti> hyperair: could you try with acpi_listen?
[07:09] <hyperair> just did
[07:09] <hyperair> nothing either
[07:09] <pitti> ok, then it's a kernel bug
[07:11] <hyperair> pitti: but even then it's pretty strange that it works at initrd stage
[07:11] <hyperair> i mean at usplash
[07:16] <hyperair> pitti: orig-keymap doesn't show anything with brightness in it.
[07:16] <pitti> hyperair: indeed it is; I guess they keys are hardwired to control the brightness, but then it's strange that they are suppressed later on
[07:17] <pitti> hyperair: or it is a KMS problem; does it work in rescue mode?
[07:17] <pitti> or just on a VT?
[07:17] <pitti> they should still leave key events, though
[07:17] <pitti> (for the notifications)
[07:17] <hyperair> eh the kernels i compile have KMS compiled in
[07:17] <hyperair> not as a module
[07:17] <hyperair> but the stock kernels have the same problem
[07:18] <pitti> OIC; so it doesn't work on VTs either?
[07:18] <hyperair> also, like i mentioned before, at usplash, prior to the password prompt (before mounting root) it works.
[07:18] <hyperair> no it doesn't work on VTs
[07:19] <hyperair> also, previously, when i tested it on intrepid (i only had jaunty for a short time so i don't erally remember) the brightness dialog appeared
[07:19] <pitti> any chance to try the intrepid or jaunty kernel with karmic?
[07:19] <hyperair> hmm i could try
[07:20] <hyperair> i don't have them installed any more
[07:20] <hyperair> probably could get it by adding the old deb lines eh..
[07:23] <pitti> hyperair: just grab the .deb from archive.u.c.
[07:23] <pitti> gdebi FTW :)
[07:23] <hyperair> haha
[07:24] <hyperair> for now lemme test without modesetting..
[07:24] <hyperair> hmm how does one disable modesetting again?
[07:24] <hyperair> nevermind. i915.modeset=0
[07:32] <hyperair> pitti: without modesetting, acpi_listen shows events happening when i press my brightness keys, and they work both in the VT and the desktop
[07:32] <pitti> hah
[07:32] <hyperair> pitti: looks like modesetting screwed up my brightness keys eh?
[07:32] <pitti> apparently
[07:32] <pitti> hyperair: if you boot with "text", i. e. don't start X, do they work or not?
[07:33] <hyperair> as in with modesetting, without X?
[07:33] <pitti> this should tell us whether it's actually a KMS bug or X's XBACKLIGHT/xrandr stuff screws things up
[07:33] <pitti> right
[07:33] <hyperair> lemme try
[07:34] <pitti> brgb
[07:42] <hyperair> pitti: with modesetting, no matter where in the boot process, the keys don't work at all
[07:49] <pitti> ok, interesting
[07:49] <pitti> hyperair: I'm afraid this needs upstream's help now; I think the fastest way would be to report a bug at bugs.freedesktop.org against the -intel driver
[07:50] <hyperair> hmm okay
[07:50] <pitti> hyperair: you can also report it in Launchpad, then someone will forward it
[07:50] <hyperair> right
[07:50] <pitti> but Jesse Barnes is following the upstream bugs, and he's probably the best person to fix these kinds of problems
[07:51] <hyperair> ah
[07:52] <hyperair> jbarnes, right?
[07:56] <pitti> right
[07:57] <pitti> hyperair: please include the versions (linux 2.6.31-rc9, -intel 2.8.1, X.org 1.6.3)
[07:57] <pitti> and dmesg and X.org log
[07:58] <hyperair> right
[07:58] <hyperair> i'll get to it later
[08:13] <seb128> good morning there
[08:14] <didrocks> lut seb128
[08:14] <seb128> salut didrocks
[08:14] <seb128> ca va?
[08:15] <didrocks> c'est le feu au boulot, mais sinon, ça va :) et toi?
[08:17] <seb128> didrocks, c'est le feu au boulot mais sinon ca va ;-)
[08:17] <didrocks> :-)
[08:28] <pitti> bonjour seb128
[08:29] <seb128> hello pitti
[08:31] <mac_v> seb128: hi... :) hmm... regarding the txt extensions... why is nautilus not prompting when the video/image formats have exec priv? how is it simply opening the files ? exclusions?
[08:31] <seb128> mac_v, explain me how to run a video?
[08:32] <mac_v> ;)
[08:32] <seb128> mac_v, txt files can be scripts
[08:32] <seb128> ie things you can run
[08:32] <seb128> I fail to see how you want to run images or videos though
[08:33] <mac_v> sure it cant be run , no.. my question was ,  how was nautilus detecting these , isnt it by the file types?... also could you see my latest comment , i just wrongly assumed the OP was commenting about vfat and ntfs volumes!
[08:34] <seb128> mac_v, detecting what? text file?
[08:34] <mac_v> that the mpg/mp3/jpg cannot be run
[08:34] <seb128> the question makes no sense to me
[08:35] <seb128> those formats have no run concept
[08:35] <mac_v> hrm.. :(
[08:35] <seb128> they are meant to be played
[08:35] <seb128> nautilus know the file formats, it needs to to display icons
[08:35] <seb128> the question only happens on text files
[08:36] <seb128> texts are a special case since they can be edited or run when set +x
[08:36] <seb128> that's the only format in this case
[08:36] <mac_v> ah... so it detects them while assigning icons...
[08:36] <seb128> binaries can't be edited in a text editor
[08:36] <seb128> videos either
[08:36] <seb128> well, it look to the directory content to display it yes
[08:36] <seb128> otherwise it would not know what to display ...
[08:37] <mac_v> seb128: yeah... i thought that nautilus first looks for the exec priv and then executes the files
[08:37] <seb128> session restart brb
[08:39] <pitti> tseliot: I'm confused by bug 292606; is there something to upload? the latest attached patch looks weird
[08:39]  * tseliot has a log
[08:39] <tseliot> s/log/look/
[08:40] <tseliot> lol
[08:43] <tseliot> pitti: I thought that has been fixed by superm1 in DKMS already.
[08:43] <tseliot> let me find the bug report
[08:43] <pitti> tseliot: ah
[08:43] <pitti> tseliot: I just updated the bug and unsub'ed sponsors
[08:43] <pitti> just close it if it was fixed in dkms itself
[08:44] <pitti> seb128: do you have an idea why bug 204567 has as gnome-panel task?
[08:44] <pitti> seb128: I thought this was just an xdg-user-dirs problem?
[08:44] <tseliot> pitti: yes, there was nothing I could do from nvidia-common as DKMS had to flush stdout after printing
[08:45] <seb128> pitti, I guess that's for the discussion for the number of bookmarks before submenu
[08:46] <seb128> pitti, why do you look at this bug?
[08:48] <Laney> sponsors queue?
[08:49] <pitti> seb128: also, does it really break existing installations if you change the default?
[08:49] <pitti> seb128: yes, sponsoring
[08:49] <seb128> pitti, sorry I should have unsubscribed sponsors, I'm watching this bug
[08:50] <pitti> ah, ok, thanks
[08:50] <seb128> there is ongoing discussion, I'm against breaking consistency with all other linux for one char
[08:50] <pitti> I don't see anything to sponsor for panel anyway
[08:50] <seb128> I want the change to happen upstream or not basically ;-)
[08:50] <pitti> and it looks like the xdg-user-dirs change already was uploaded (task is closed)
[08:50] <pitti> seb128: right, makes sense
[08:50] <seb128> it was
[08:51] <seb128> but now they discuss changing Download to Downloads
[08:51]  * pitti updates bug
[08:51] <seb128> I unsubscribed sponsors
[08:54] <chrisccoulson> good morning everyone
[08:54] <seb128> hey chrisccoulson, thanks for the gdm investigation, I though it would be something like that
[08:54] <chrisccoulson> seb128 - you're welcome
[08:54] <pitti> hey chrisccoulson
[08:55] <chrisccoulson> hey pitti
[08:58] <pitti> OMG bug 385850 ..
[08:58] <seb128> pitti, what about it?
[08:58] <tseliot> pitti: I was wrong. The bug hasn't been fixed yet
[08:58] <pitti> long discussion, intrusive package reorg, etc., but I'll grind through it
[08:59] <pitti> tseliot: oh, ok; so 292606 should stay open then?
[08:59] <seb128> pitti, it seems pretty clear consensus from what robert_ancell said
[08:59] <seb128> just a small set of screensavers by default
[09:00] <tseliot> pitti: yes, but it's really a dkms bug
[09:02] <chrisccoulson> pitti - have you seen any gnome-session / g-p-m crashes recently that look dk-power related? i've seen a couple of people report simultaneous crashes of both when unplugging USB devices, and kklimonda got some good backtraces last night of the actual crash and also a critical message that occurs just before the crash too
[09:02] <chrisccoulson> bug 426501
[09:03] <pitti> chrisccoulson: I didn't get that one, no; I'll have a look at the bug after finishing with sponsoring
[09:03] <chrisccoulson> i'm trying to find the equivalent g-p-m bug too but i'm having issues with edge :-/
[09:03] <chrisccoulson> pitti - thanks. there is also an equivalent g-p-m bug that occurs at the exact same time, and they both look the same
[09:05] <pitti> chrisccoulson: hm, I don't see xsession-errors there?
[09:06] <pitti> chrisccoulson: ah, too bad that devkit-power-dbgsym wasn't installed for http://launchpadlibrarian.net/31510719/gnome-session.gdb.log
[09:06] <pitti> chrisccoulson: perhaps dkp_device_get_object_path() returns NULL because the device was just yanked out and doesn't exist any more?
[09:06] <chrisccoulson> pitti - yeah, i only saw xsession-errors in pastebin last night, but the error was why i asked him to run gnome-session with G_DEBUG=fatal_criticals for the second backtrace
[09:06] <chrisccoulson> but there still seems to be enough info there
[09:06] <chrisccoulson> pitti - yes, that's what it looks like
[09:07] <pitti> SegvReason: reading NULL VMA
[09:07] <chrisccoulson> the trace of the crash suggests that anyway, as it's passing NULL to g_hash_table_remove
[09:08] <chrisccoulson> and the critical message would cause dkp_device_get_object_path to return NULL too
[09:08] <pitti> hm, so if it's storing the object paths, it's hard to remove the correct one if it doesn't exist any more
[09:09] <pitti> udev does preserve the sysfs path and properties for a removal event, though
[09:09] <pitti> but if that's passed on as an asynchronous event through dk-p, then you'd get that race presumably
[09:10] <chrisccoulson> that's wierd actually. it looks up the DkpClient from a local hash table, using the object_path. so, there should be no race
[09:10] <chrisccoulson> it would suggest that the device was never added to the hash table perhaps?
[09:10] <chrisccoulson> d'oh
[09:10] <chrisccoulson> s/DkpClient/DkpDevice
[09:10] <pitti> ah, perhaps; it was said to be a mouse
[09:11] <pitti> perhaps they get filtered out when adding
[09:11] <chrisccoulson> possibly
[09:11] <pitti> anyway, this is just wild speculation
[09:11]  * pitti unplugs/replugs usb mouse a couple of times
[09:12] <chrisccoulson> dkp_device_removed_cb looks wrong actually. it looks like the g_hash_table_remove should happen conditionally based on the "if (device != NULL)"
[09:12] <chrisccoulson> almost like it's missing some curly braces;)
[09:12] <pitti> that's an obvious workaround, but we should check if that situation is actually legal
[09:12] <pitti> hm, 4 replugs, no crash
[09:13] <chrisccoulson> pitti - yeah. it would be interesting to see what happens when the device is added. if it is ignored and not added to the hash table, then that would probably be the fix;)
[09:13] <pitti> right
[09:13] <pitti> nothing in devkit-power --monitor-detail for me
[09:14] <chrisccoulson> strange. anyway, do you want me to reassign this to dk-power for now? (it doesn't look like anything gnome-session is responsible for)
[09:14] <pitti> right, please do
[09:14] <pitti> and the g-p-m bug as a dupe then?
[09:16] <chrisccoulson> pitti - yeah, if i can find it. i'm struggling with LP this morning - not sure if its my connection or not
[09:16] <pitti> works fine here
[09:16] <pitti> chrisccoulson: thanks for the investigatinos
[09:17] <chrisccoulson> you're welcome
[09:22] <chrisccoulson> kklimonda - i can't find the g-p-m bug you reported last night now. would you be able to mark it as a duplicate of bug 426501 please?
[09:34] <pitti> chrisccoulson: hm, I get timeouts on edge, too
[09:34] <chrisccoulson> pitti - yeah, i just disabled redirection for now and it works ok
[09:36] <chrisccoulson> pitti - does dk-power have a utility for monitoring what happens when you plug/unplug devices, or is it best just to use "dbus-monitor --system"
[09:37] <pitti> chrisccoulson: devkit-power --verbose --monitor-detail
[09:37] <pitti> chrisccoulson: but this will only show you relevant events, like power chords or batteries
[09:37] <pitti> it doesn't say anything about e. g. an usb mouse
[09:37] <pitti> (and it shouldn't really)
[09:37] <pitti> ideally it wouldn't even wake up on those events
[09:38] <chrisccoulson> pitti - thanks. the output of that might be useful for that bug report, just in case something wierd is happening. i had a look at the code for devkit-power-gobject, and every added device is added to the hash table
[09:39] <pitti> uh, why would it want to track all devices?
[09:39] <chrisccoulson> pitti - it only tracks the devices enumerated by the dk-power daemon
[09:40] <chrisccoulson> but i'm just confused that this device which causes the crash doesn't appear to be tracked at the point it is removed
[09:41] <pitti> chrisccoulson: I presume dk-power installs a gudev event handler?
[09:41] <chrisccoulson> pitti - i would think so. i've not looked at any code for the daemon just yet though
[09:47] <chrisccoulson> i'll have another look at it later if you haven't figured it out before me. i probably should get on with some work now ;)
[10:12] <didrocks> seb128: lionel has the infrastructure to test evolution-mapi. He will ping you to confirm a FFe once the new version will be built and tested before uploading
[10:12] <seb128> that's a GNOME component it has a standing exception
[10:13] <didrocks> seb128: ok, I paste this :)
[10:14] <didrocks> thanks
[10:14] <seb128> you're welcome
[10:14] <seb128> thanks to whoever is doing the update ;-)
[10:14] <didrocks> :-)
[10:30]  * seb128 grrrs at edge timeouting
[10:31] <chrisccoulson> seb128 - i just disabled redirection ;)
[10:31] <chrisccoulson> it was too annoying
[10:31] <seb128> me too
[10:31] <seb128> but it breaks scripts I'm running
[10:31] <seb128> like the versions update
[10:32] <chrisccoulson> ah, yeah, that's a pain
[10:35] <maxb> point the scripts at lpnet too :-)
[10:36] <seb128> I can't be bothered to change it twice only to workaround the issue, I will wait for them to fix launchpad
[10:42] <seb128> vuntz, alacarte still doesn't display the correct name for menu entries
[10:43] <vuntz> seb128: latest gnome-menus/gnome-panel/alacarte?
[10:43] <seb128> no, gnome-menus, alacarte
[10:43] <seb128> should be enough
[10:43] <seb128> it's not about edition
[10:43] <seb128> but gedit is still named gedit there
[10:43] <seb128> does it read the new key?
[10:44] <vuntz> seb128: does it have X-GNOME-FullName?
[10:44] <vuntz> it was working in my tests
[10:45] <seb128> vuntz,
[10:45] <seb128> $ grep Name /usr/share/applications/gedit.desktop
[10:45] <seb128> Name=gedit
[10:45] <seb128> GenericName=Text Editor
[10:45] <mac_v> seb128:  for the .txt bug ... the exec mounting is due to ntfs-3g , right? i'm thinking of assigning the also affect to ntfs-3g
[10:45] <seb128> vuntz, grr, I have an user copy
[10:45] <seb128> no that was not that
[10:46] <mac_v> or gvfs?
[10:46] <seb128> mac_v, ask pitti he might know
[10:46] <mac_v> pitti: hi... any idea why windows filesystems mount as exec? or why they shouldnt be mounted as noexecby default ?
[10:46] <seb128> mac_v, but vfat has the same issue, that's a rather a fs limition than a bug
[10:47] <mac_v> hm , yeah
[10:47] <pitti> mac_v: in some earlier releases we in fact did that
[10:47] <mac_v> why did we change?
[10:48] <pitti> but then you couldn't execute anything, including .exe files (wine/Mono) or .desktop files
[10:48] <pitti> mac_v: well, it's just the upstream default
[10:48] <mac_v> pitti: and which package is involved?
[10:48] <pitti> mac_v: but shouldn't it ask you whether to run or open it?
[10:48] <pitti> mac_v: gvfs and devicekit-disks (the latter mainly)
[10:48] <seb128> pitti, that's the issue, they don't like this dialog and want to get ride of it
[10:49] <pitti> but it's hard to do the right thing wrt. mounting with fat/ntfs
[10:49] <mac_v> yeah... it asks, but it is redundant for .txt files created in windows
[10:49] <pitti> so perhaps with .txt there should be a gvfs-layer workaround to not run it
[10:49] <pitti> i. e. always open .txt with an editor, and always run .sh
[10:50] <pitti> seb128: "they" -> upstream or an ubuntu bug?
[10:50] <seb128> pitti, what is there is no .txt but the file is purely text
[10:50] <seb128> pitti, hundredpapercut
[10:50] <seb128> ie mac_v
[10:50] <mac_v> pitti: could you pls comment on Bug #425166 ,
[10:50] <seb128> well is the issue purely for things named ".txt"?
[10:50] <seb128> or for any text file
[10:50] <seb128> because you will get the same issue with let's say README
[10:51] <pitti> seb128: can nautlus/gvfs look into the file, or just look at file metadata?
[10:51] <seb128> or TODO
[10:51] <seb128> or NOTES
[10:51] <seb128> or whatever
[10:51] <mac_v> seb128: windows only uses txt
[10:51] <seb128> mac_v, you say you will never have a README in a win disk?
[10:51] <seb128> I think you are overlooking the issue...
[10:51] <mac_v> hehe ;)
[10:51] <mac_v> yeah , forgot that
[10:52] <seb128> pitti, what do you want to look for?
[10:52] <seb128> the issue is to know if a text file +x is a script or not
[10:52] <pitti> seb128: it could perhaps run file on it, or check for ELF/ #! or so
[10:52] <seb128> we have some magic for it but it's not perfect
[10:52] <seb128> imho we should have specific buggy cases to look at those
[10:52] <mac_v> pitti: seb128: rather than simply working around that bug , it is better to fix it properly , even if it is not a papercut
[10:52] <seb128> because the current discussions are a bit fuzzy there
[10:52] <pitti> scripts always need to start with #!, but of course we also need to detect compiled binaries
[10:53] <pitti> mac_v: sure, we are just discussing this
[10:53] <mac_v> :)
[10:53] <pitti> from an Unixish POV, an executable bit means it's executable, even if it's broken
[10:53] <pitti> but we can't really enforce that for FSes which are incompatible with Unix, like vfat or ntfs
[10:54] <pitti> so the only other proper thing which comes to my mind is to look at the file
[10:54] <seb128> pitright
[10:54] <seb128> ups
[10:54] <seb128> pitti, right
[10:54] <seb128> then we list to build a descriptive list of mimetypes to run
[10:54] <seb128> ie no only sh scripts
[10:55] <seb128> but also perl, python, etc
[10:55] <seb128> those are text files that can be run too
[10:55] <pitti> seb128: right, but they all need to start with #!
[10:56] <seb128> that would need a new mimetype in shared-mime-info I guess
[10:56] <seb128> and change all the scripts format to subclass this one
[10:56] <seb128> the way it works now is that nautilus uses glib mimetype detection
[10:56] <pitti> application-x-executable ?
[10:57] <seb128> I wouldn't like to add nautilus api to read the file a second time only to see if it starts with !#
[10:57] <pitti> *nod*
[10:57] <pitti> there's also a text-x-script type
[10:57] <seb128> python does
[10:57] <seb128>     <sub-class-of type='application/x-executable'/>
[10:58] <seb128> the issue is that "start with #!" is not enough
[10:58] <seb128> looking to shared-mime-info there is quite some format doing that but which are not scripts
[10:58] <seb128> we need to filter things out if we do that
[10:58] <pitti> hm, but everything that is executable and starts with #! can be run
[10:58] <seb128> no
[10:59] <pitti> you are saying that there are non-scripts file formats which start with #!?
[10:59] <seb128>   <mime-type type="message/rfc822">
[10:59] <seb128>     <magic priority="50">
[10:59] <seb128>       <match value="#! rnews" type="string" offset="0"/>
[10:59] <seb128> that stored on a vfat disk would be +x
[10:59] <mac_v> pitti: what about  exec files which dont start with #! ,
[10:59] <seb128> and that's not an executable
[10:59] <mac_v> i use them as launchers and stuff
[10:59] <pitti> mac_v: see above
[11:00] <pitti> seb128: yay :-(
[11:00] <seb128>   <mime-type type="audio/AMR">
[11:00] <seb128>     <magic priority="50">
[11:00] <seb128>       <match value="#!AMR\n" type="string" offset="0"/>
[11:00] <seb128> too for example
[11:00] <pitti> '#!(.*)' && test -x $1
[11:00] <pitti> ?
[11:00] <seb128> I think we could use application/x-executable
[11:01] <pitti> i. e. check that the interpreter actually exists?
[11:01] <seb128> and make sure that all script mimetype subclass it correctly
[11:01] <pitti> seb128: right, that avoids false positives
[11:02] <pitti> safer approach
[11:02] <seb128> in any case the patch on this bug to change the default gconf key is not a good solution
[11:02] <mac_v> +1
[11:03] <pitti> *nod*, this shouldn't be configurable IMHO
[11:03] <pitti> that sounds like an "unbreak my desktop" switch
[11:03]  * mvo celebrates revno 200 in software-store by having lunch
[11:06]  * seb128 hugs mvo, good work!
[11:07] <pitti> mvo: yay
[11:07] <pitti> mvo: can you please have a look at bug 369198 later on? I reopened it
[11:59] <asac> hmm
[11:59] <asac> second time now that i rebooted my laptop
[11:59] <asac> superblock is 2 hours ahead
[12:00] <asac> exactly 2 hours -> aka UTC->CEST offset
[12:00] <asac> feels like a bug somewhere
[12:00] <asac> any clue where to look?
[12:01] <asac> what writes the superblock? and why is there non-UTC time?
[12:01] <asac> any clue pitti ?
[12:01] <asac> ;)
[12:02] <pitti> asac: hm, ISTR that this was talked about in the release meeting; cjwatson or Keybuk might know
[12:02] <asac> ok i will check in -devel
[12:15] <mvo> pitti: yes, I have a look at #369198
[12:16] <geser> didrocks: in case you didn't notice: gir-repository (main) is in DEPWAIT on libgoocanvas-dev (universe)
[12:25] <seb128> pitti, do you know you could mir review libgdata before the paper work is done? or do you want to dispatch that to somebody else?
[12:30] <seb128> chrisccoulson, hey, did you start on the libgdata mir bug?
[12:31] <chrisccoulson> seb128 - not yet. i planned to start last night but got distracted by other things
[12:31] <chrisccoulson> feel free to start it if you like. if not, then i'll try and set aside some time again later this evening
[12:38] <seb128> chrisccoulson, ok, ping me before starting in case I start before you
[12:39] <chrisccoulson> seb128 - ok, no problem
[12:39] <seb128> brb
[12:39] <seb128> thanks
[12:58] <didrocks> geser: I know, I ping StevenK about that (he put clutter from universe to main). What's strange is that I was able to send gir-repository (it was in universe) and in the meantime someone put it in main, apparently?
[13:22] <pitti> seb128: re
[13:23] <pitti> seb128: yes, I'll have a look
[13:23] <seb128> thanks
[13:23] <seb128> brb, trying fsck clock issues
[13:37] <mac_v> Keybuk: noticed the call for boot testing mail... any known issues with the ppa?
[13:38] <seb128> re
[13:45] <Keybuk> mac_v: only that network filesystems won't
[13:45] <Keybuk> mount
[13:46] <mac_v> hm.. ok will give it a whirl :)
[13:53] <mvo> mpt: could you please check trunk/ for the margins? It seems like the margins next to the scrollbar are something from the theme or webkit, I see them in e.g. devhelp as well. the top/bottom ones should be fixed now
[13:54] <mpt> mvo, trunk r206 doesn't start: glib.GError: Icon 'software-store-arrow-button' not present in theme
[13:55] <mvo> mpt: right, give me a sec, I add a workaround for you
[14:00] <mvo> mpt: please try r207
[14:00] <popey> Keybuk: trying ubuntu-boot ppa, setting up anacron is hanging apt..  want a bug filed?
[14:00] <mpt> not uploaded yet
[14:01] <mac_v> mvo: 7 revs in ~3 hrs \o/
[14:01] <mac_v> ;)
[14:01] <mvo> mpt: if you pull via http there is usually a small delay
[14:01] <mvo> mac_v: :)
[14:03] <mpt> mvo, yes, bottom margin is almost completely fixed now, except for the extra border
[14:03] <mpt> so now there's 2px border both at bottom and at left
[14:03] <mac_v> mpt: http://dl.getdropbox.com/u/123544/out.ogv , one user has done that ;) directed him to mvo
[14:03] <mpt> Is it possible to turn the border off completely for the Webkit view?
[14:03] <mvo> mpt: I think that is a webkit problem actually, I will do some code to test that theory
[14:04] <Keybuk> popey: not yet
[14:04] <Keybuk> popey: join #ubuntu-boot and repeat the problem there
[14:04] <mpt> mac_v, yes, mvo showed me, it's brilliant
[14:04] <popey> Keybuk: ok, it's moved on a bit, but the update feels real slow
[14:04] <mvo> mac_v: yeah, that looks pretty slick :)
[14:04] <seb128> vuntz, could the naming issue due to one of the langpack patches we have? ;-)
[14:04] <mvo> he said he is off to bed now but will send contribuor agreement tomorrow
[14:05] <mac_v> yup
[14:05] <mpt> mvo, for the right margin, epiphany-webkit appears to have exactly the same problem.
[14:05] <mpt> so, maybe not something you can do anything about.
[14:05] <vuntz> seb128: I don't think that would explain it, but well, hard to tell
[14:06] <mpt> These very-slightly-rounded corners for things in Human are awful (but then, Clearlooks etc has the same problem)
[14:07] <seb128> vuntz, should the new key be added to gkeyfile.h in glib?
[14:09] <vuntz> seb128: there are really two things there:
[14:09] <vuntz> a) gnome-menus will read X-GNOME-FullName. Your langpacks won't change the presence of the english version of the key
[14:09] <vuntz> b) to make it work with langpack, yes, you probably need to add X-GNOME-FullName there
[14:11] <seb128> vuntz, alacarte displays the correct name for you for gedit?
[14:12] <mpt> mvo, btw, now that the navigation button looks like a button, it doesn't need the pointing hand cursor any more
[14:13] <seb128> vuntz, gmenu-simple-editor has the wrong name too
[14:14] <vuntz> let me build the latest gedit in my jhbuild
[14:14] <davmor2> guys I want to find out if xsplash is causing the issue I'm having with ubuntu + ati card is there a way I can temporarily switch xsplash off?
[14:15] <seb128> vuntz, doh, sorry, the current gedit doesn't have the change
[14:15] <fredp> vuntz: oh, maybe gedit has X-GNOME-Fullname (wrong capitalisation -> fail)
[14:15] <fredp> (I think I spotted once, someday, but then I forgot)
[14:15] <vuntz> seb128: tss
[14:16] <seb128> gra, it has
[14:16] <seb128> vuntz, they used X-GNOME-Fullname=gedit Text Editor
[14:16] <mvo> mpt: I attached a small test app to #426741
[14:16] <seb128> vuntz, changing n to N fixes the issue
[14:17] <seb128> what fredp said
[14:17] <fredp> and too bad I spotted that and didn't fix it.
[14:17] <fredp> bad me.
[14:18] <seb128> and how come empathy keeps changing soname so late in the cycle?
[14:18] <seb128> they changed 2 libs soname in .92 again
[14:22] <seb128> cassidy, Zdra: ^
[14:23] <cassidy> libempathy shouldn't be a lib, that's a trap
[14:23] <seb128> cassidy, and the -gtk one?
[14:24] <cassidy> idem. Plan to is to move libempathy features to tp-glib and create a telepathy-gtk containing the useful bits of libempathy-gtk
[14:24] <seb128> ok good
[14:24] <seb128> thanks
[14:24] <seb128> hum, I should triage some of the crashers there
[14:24] <seb128> the empathy bug list has a lot of those
[14:27] <cassidy> please fw them upstream is you have usable trace
[14:27] <seb128> will do
[14:31] <asac> seb128: where can i find hadess?
[14:31] <seb128> asac, #gnome-hackers
[14:31] <asac> ah ;)
[14:31] <seb128> on irc.gnome.org
[14:31] <mvo> mpt: about bug #425810 - am I misreading that or is "what happens" and "what should happen" the same?
[14:32] <mpt> mvo, sorry, fixed.
[14:33] <seb128> pedro_, want to forward some empathy crashes upstream today? ;-)
[14:33] <mpt> ergh, Yelp crashes if you look at it too sternly
[14:33] <mvo> mpt: hm, I always thought that this is a nice feature, that the element is still around
[14:33] <mvo> mpt: that means you can browse around and late return to the app you selected
[14:33] <mpt> mvo, it's very confusing, please fix it
[14:34] <mpt> mvo, if it turns out we need a Back button, we can add that for 2.0
[14:34] <pedro_> seb128, sure I'll flood them ;-)
[14:34] <seb128> pedro_, thanks ;-)
[14:34] <mvo> mpt: *shrug* it is not confusing to me, but I can fix it
[14:35] <pedro_> seb128, btw just fyi reopened the ugly file-roller bug 399172
[14:35] <seb128> pedro_, ok
[14:35] <seb128> did you reopen the upstream bug too?
[14:35] <pedro_> seb128, yeah just did it
[14:35] <seb128> I'm focussing on updates and bug fixing atm so I don't track all bugs correctly
[14:35] <seb128> thanks
[14:35] <pedro_> will get a new valgrind log and stacktrace just in case
[14:35] <mpt> mvo, yeah, you and I have a strong mental model of where we really are, but other people will need a stronger indication
[14:36] <mvo> mpt: so the button being pressed is not enough as a indicator, this is why the last entry needs to vanish?
[14:38] <mpt> mvo, it's not necessarily immediately after the button being pressed. For example see the third test case in <https://wiki.ubuntu.com/SoftwareStore#Navigation%20pane>.
[14:40] <seb128> pedro_, I think those dispatch crashes are similar to bug #423470
[14:40] <mvo> mpt: the test case that starts with "Begin installing an application. ..." ? I don't see the connectoin to the navigation button (when clicking in progress, the navigation buttons are hidden, no?)
[14:40]  * pedro_ looking
[14:40] <seb128> the bug seems to have a lot of duplicates
[14:41] <seb128> #0  tp_connection_manager_idle_read_manager_file (data=0x1d22c28)
[14:41] <seb128>     at connection-manager.c:1158
[14:41] <seb128> 	self = (TpConnectionManager *) 0x19c5560
[14:41] <seb128> could be a telepathy-glib issue
[14:41] <asac> err. what was the command line thing to wrap a long text and indent it?
[14:41] <mpt> mvo, yes, and when you click on "Get Free Software", it returns you to "Get Free Software" > "Internet" + search, because that's exactly where you were before.
[14:41] <mpt> (Where "before" == "last time you were in the Get Free Software section".)
[14:42] <pedro_> seb128, yeah, will clean up those there
[14:43] <mvo> mpt: but this is working correctly now, right ?
[14:45] <mpt> mvo, no, in r207 I end up with "Get Free Software" > "Search in Internet" > "Gnumeric", which is obviously wrong.
[14:45] <mpt> (That's using Gnumeric as the application I'm installing as the first step.)
[14:46] <cassidy> seb128: this one should have been fixed in tp-glib
[14:46] <mpt> mvo, I should get just "Get Free Software" > "Internet".
[14:46] <cassidy> seb128: https://bugzilla.gnome.org/show_bug.cgi?id=593929
[14:47] <mac_v>  , how do i access kernel 31-3 ? i'm trying to download it
[14:47] <seb128> cassidy, I just synced 0.7.36, nobody asked for the update before
[14:47] <seb128> cassidy, let's see if that fixes those
[14:47] <seb128> cassidy, we still had 0.7.35
[14:48] <cassidy> seb128: I don't know the details, sorry
[14:48] <mvo> mpt: ok, I assume we mean the same, but just to be clear? if you have  [1][2][3]  and you click on [2] then [3] should disappear ? if you click on [1] then [2][3] should disappear ?
[14:48] <mpt> mvo, exactly
[14:48] <seb128> cassidy, that's ok, thanks
[14:48] <mac_v> nvm found it :)
[14:48] <mpt> mvo, the last item should always represent where you are (not counting any search)
[14:48] <seb128> pedro_, you can reassign to telepathy-glib and close as fixed is 0.7.36
[14:48] <pedro_> seb128, yes will do
[14:49] <seb128> pedro_, thanks!
[14:49] <pedro_> you're welcome ;-)
[14:51] <seb128> slomo, hey
[14:52] <slomo> hi seb128
[14:52] <seb128> slomo, do you think you could backport http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=058776bcf1ab218b509d19685a0b528d71c65f98 in debiajn?
[14:52] <seb128> debian
[14:53] <mvo> mpt: so https://wiki.ubuntu.com/SoftwareStore?action=AttachFile&do=get&target=1.0-department-search.jpg shows that when a search is done the category name is in the navigation bar (and should not be "search in $category" - isn't that helpful for people who do not have a good mental model of where they are ? especially when e.g. switching between available and installed so that they see after the switch that they are not actually looking at
[14:53] <mvo> everything in office (but only a subset by a given search)?
[14:53] <mvo> that is for bug #425809
[14:53] <slomo> seb128: not sure, if you want to ship gnome 2.28 you'll probably ship gstreamer/gst-plugins-base 0.10.25 anyway ;)   does this bug really affect ubuntu in an important way?
[14:54] <mvo> mpt: assuming that someone is e.g. search in office, then looks at installed for some time and forgot that he was actually doing a search he may wonder why office is so small
[14:54] <mvo> (has so few entries)
[14:54] <seb128> slomo, bug #426587
[14:54] <seb128> slomo, it's an issue for empathy for example
[14:55] <seb128> slomo, I would not say it's too important but would be nice to get fixed in karmic
[14:55] <seb128> slomo, when are new versions due?
[14:55] <slomo> seb128: oh, that's scary, yes :) oct 19th, first pre-releases will be oct 5th/6th
[14:58] <mpt> mvo, that's shown by (1) the presence of the text in the search field, and (2) the "___ matching items" in the status bar. If it turns out not to be enough, we can add something extra to the main pane for 2.0, e.g. a "Search results" treeview header.
[14:59] <mvo> mpt: I would be interessted to see user testing on this, I got confused myself for not paying attention to the search field (that it was still on). the "search in"  seems like a simple way to make it more obvious
[14:59] <seb128> slomo, that's late, I would like to get the change backported so we get the issue fixed in 2.28 and karmic beta
[14:59] <seb128> slomo, if you don't want to do it for debian that's fine I will do an ubuntu change
[15:01] <slomo> seb128: problem is, if i want to backport that change i should also backport many other changes that are of same importance or even more important... and that's too much work ;)
[15:01] <mpt> mvo, I think it would be unfair to judge that before bug 425810 was fixed, because the extra elements obscured a bit the relationship between the location and the search being done in that location.
[15:02] <mvo> mpt: ok, I work on fixing that now
[15:02] <mpt> thanks mvo
[15:02] <seb128> slomo, can you convince upstream to roll candidate tarballs earlier? ;-)
[15:03] <seb128> slomo, I would tend to say "backport issues users complained about and which affect default GNOME experience"
[15:03] <seb128> but as you want, as said if you don't backport it I might have a look before beta
[15:04] <slomo> seb128: do you have more issues that users complained about?
[15:04] <seb128> we get lot of gstreamer bugs and most don't get investigated
[15:05] <seb128> nothing where there is an obvious fix upstream or a backport required
[15:05] <slomo> seb128: ok, that's good ;) i guess all other issues i have in mind don't happen often enough
[15:05]  * seb128 hugs pitti for fixing the guest session
[15:06] <pitti> *beam*
[15:06] <pitti> yay, fading usplash
[15:06] <slomo> seb128: except the broken easy codec installation but if you want to backport the patch for that you might have a lot of fun... i'm currently rewriting decodebin2 (that thing that searches and connects the required plugins for decoding) for fixing this...
[15:07] <seb128> slomo, right, that one is one my list too but I figured I would wait since you were still fixing issues
[15:07] <seb128> slomo, what are the chance to get fixing in the next month?
[15:08] <slomo> seb128: good but i can't guarantee that there are no regressions, it'll be a large change
[15:08] <seb128> slomo, ok, thanks
[15:08] <seb128> we will see what we do
[15:08] <seb128> we will probably backport it as soon as it's ready to do early testing
[15:08] <seb128> brb, session restart
[15:08] <mvo> mpt: what should happen to any search if "get free software" is clicked? clear the search?
[15:08] <mvo> mpt: (same for installed software)
[15:09] <mpt> mvo, yes, clear the search
[15:25] <mvo> mpt: re https://wiki.ubuntu.com/SoftwareStore#Searching from the lobby - if the user starts from the lobby, searches firefox, clicks on firefox details and goes back to "Get Free Software" (in the [Get free software][firefix] navigation. should that clear the search as well? and if not, what is the way for the user to go back to all apps? by clicking on the clear icon in the search?
[15:27] <mpt> mvo, yes, clicking any item in the path button, other than the last one, should clear the search
[15:27]  * mpt wonders if clicking the last one should clear the search too
[15:28] <mpt> I guess that would make sense
[15:29] <mvo> mpt: just to be clear I get this right - the user searches fire and gets 5 results, he clicks on firefox and when he clicks on "Get Free Software" again he does not get his search results but instead is returned to the lobby screen with the search cleared?
[15:29] <mpt> mvo, hm, you're right
[15:29] <mpt> the search results should remain, then
[15:29] <mpt> So, the way to go back to all applications in a category is to clear the search field
[15:31] <mvo> this might be a useful case where the "search in button" is handy, I'm not sure clicking on clear search is obvious
[15:32] <seb128> cassidy, Zdra: is there any way to import an account after the first start?
[15:32] <cassidy> good question. Let me ask
[15:38] <mpt> ok, help is 5/9 complete
[15:44] <cassidy> seb128: apparently it's not possible
[15:45] <seb128> cassidy, ok, thanks
[15:45] <cassidy> seb128: if you think that should be possible, suggest an UI change to mpt :)
[15:46] <seb128> well usually I don't get the point, but 2.27.91 failed to import msn accounts
[15:46] <seb128> I will just remove all the accounts and do a new import
[15:59] <mvo> mpt: I commited the search changes as just discussed, I put the behaviour in the debian/changelog, please double check that I captured it correctly
[16:00] <mvo> mpt: as r210
[16:04] <mpt> mvo, that looks perfect, nice work
[16:05] <mpt> Help pages 6/9 complete
[16:06] <mvo> mpt: what is your branch name?
[16:07] <mvo> mpt: rugby471 seems to have done some doc work as well, but I noticed just now only, he did not send a merge request
[16:21] <seb128> hum, karmic is slooow to boot
[16:22] <seb128> it takes around 35 seconds to reach the gdm start there
[16:23] <seb128> Keybuk, do you have any workaround for this fsck bug?
[16:23] <Keybuk> use ext2
[16:23] <seb128> my laptop crashed while opening pitti's bootchart in firefox
[16:23] <Keybuk> or don't forcibly power off your machine ;)
[16:23] <seb128> no fun to have to run fsck every time
[16:26] <rugby471> hello
[16:27] <mpt> hi rugby471
[16:29] <rugby471> mvo: have you had time to look at my merge proposal?
[16:29] <rugby471> https://code.launchpad.net/~rugby471/update-manager/fix-423355/+merge/11246
[16:29] <mvo> rugby471: hi - hm, it did not send me a mailfor this
[16:30] <rugby471> oh, that is annoying :-)
[16:30] <mvo> rugby471: there are some conflicts, could you have a look? the parts without the conflicts looked good :)
[16:30] <rugby471> mvo: basically it fixes a papercut
[16:30] <mvo> rugby471: but there might be some overlap with mpt and his work on the help
[16:30] <rugby471> sorry what are we talking about?
[16:31] <mpt> mvo, rugby471: <https://code.launchpad.net/~mpt/software-store/help>
[16:31] <rugby471> I was referring to the update-manager branch
[16:31] <rugby471> https://code.launchpad.net/~rugby471/update-manager/fix-423355/+merge/11246
[16:31] <mvo> rugby471: oh, sorry
[16:31] <mvo> rugby471: I have a look
[16:31] <rugby471> mvo: np, I shall have a look at mpt's branch as well :-)
[16:31] <mpt> mvo, I haven't pushed so far today because I forgot to copy my SSH key over to Karmic, yay
[16:31] <rugby471> hehe
[16:32] <mvo> :)
[16:33]  * mpt is also working in half-darkness because the latest Karmic updates broke the Xorg brightness setting
[16:34] <rugby471> hehe
[16:38] <pitti> mpt: could you try to boot an older kernel in grub and see whether this was the reason for the brightness breakage?
[16:39] <mpt> pitti, ok
[16:39] <pitti> mpt: pressing shift during boot should give you the menu
[16:41] <rugby471> oops too late :-)
[16:42] <mpt> pitti, in 2.6.31-9 the display is much brighter, but the brightness is still unchangable.
[16:43] <mpt> (as in, the brightness applet reports "Cannot get laptop panel brightness" and the keyboard keys don't do anything.)
[16:45] <pitti> mpt: but it did work in Jaunty?
[16:46] <mpt> pitti, yes, it works in 9.04
[16:49] <mvo> mpt: could you please check if #425816 is still a problem with current bzr (r210) ?
[16:50] <pitti> mpt: I doubt it's a hotkey issue, since it worked in 9.04 and g-p-m complains about not being able to read the brightness, so it sounds like a kernel regression :-(
[16:52] <mpt> mvo, that's been fixed since the first revision you showed me this morning, I think :-)
[16:52] <mpt> looks much better now
[16:56] <mac_v> pitti: i tested the acer orbicam [gspca module] upto kernel 31-3 and also 30-3 but its not go , the module causes the same problems everywhere :(   i guess blacklisting it is the only option
[16:56] <pitti> mac_v: meh :-( but thanks for testing
[16:57] <mac_v> np :)
[16:58] <seb128> huats, hi, there is a new pessulus version for you
[17:00] <huats> seb128: yep
[17:00] <huats> I'll include that one
[17:00] <seb128> thanks
[17:01] <huats> My pleasure seb128
[17:04] <pitti> rickspencer3: FYI, just talked to liw about the janitor pidgin cleanup, and subscribed you, Seb, and a few other relevant folks
[17:07] <seb128> pitti, do you know about bug #426800?
[17:07] <seb128> pitti, what cleanup?
[17:07] <pitti> seb128: see bug 426905
[17:08] <pitti> seb128: gdm> looking
[17:08] <pitti> (sorry, LP is slow, just uploading postgresql)
[17:09] <pitti> seb128: could be related to the *-default-settings changes in bug 403291, looking
[17:10] <pitti> ah, indeed
[17:11] <pitti> seb128: will update the bug
[17:11] <seb128> pitti, what the janitor would do? clean datas too or just the package?
[17:11] <seb128> pitti, thanks
[17:12] <pitti> seb128: just the package, I presume?
[17:12] <seb128> isn't the janitor used by the dist-upgrader?
[17:12] <seb128> I'm a bit concerned that people might trust the janitor and uninstall pidgin without wanting to do that
[17:15] <pitti> seb128: juggled both bugs
[17:15] <pitti> seb128: I thought the janitor is deliberately decoupled from the dist-upgrader?
[17:15] <seb128> pitti, thanks
[17:15]  * pitti subscribes mvo and triple-checks
[17:16] <seb128> pitti,
[17:16] <seb128> update-manager (1:0.98) jaunty; urgency=low
[17:16] <seb128>   * merge the 'computer-janitor' core and quirks code into
[17:16] <seb128>     update-manager-core (part of the jaunty-cruftremover-improvements
[17:16] <seb128>     spec)
[17:16] <seb128> pitti, I don't know about specifics though, might be a good idea to take mvo's input ont hat
[17:16] <seb128> that
[17:16] <pitti> seb128: done
[17:16] <mvo> not every bit is used, I have a look if its a problem or not
[17:17] <mvo> (after dinner)
[17:17] <seb128> mvo, there is no bug don't worry
[17:17] <seb128> we are just discussing what to do with pidgin on upgrades
[17:18] <pitti> mvo: ah, it's just a question; enjoy dinner!
[17:18]  * pitti will have dinner, too
[17:19] <seb128> german are having diner early today!
[17:19]  * seb128 will wait another hour before diner
[17:19] <ccheney> how do i get vi to tell me the name of the file it is editing?
[17:19] <pitti> Taekwondo later this evening, don't want to go there with a full stomach
[17:19] <pitti> ccheney: ctrl-g ?
[17:20] <ccheney> pitti: thanks :)
[17:37] <mvo> mpt: r213 should make the progress less cramped now, please have a look and let me know if its enough or if the padding should be different
[17:38] <mpt> mvo, nice work
[17:38] <mpt> mvo, the columns don't yet stretch to the window width
[17:38] <rugby471> mvo: I have pushed to my branch the documentation with mpt's changes and some other bug fixes
[17:39] <mpt> mvo, to be precise, the column containing the text should stretch. All the other columns should stay exactly the same size.
[17:41] <mpt> mvo, I've finished the help pages, just copyediting now, then I'll push them and let you know
[17:44] <rugby471> software store is going to rock :-)
[17:47]  * ccheney already is hearing the screams from users about the F11 change after seeing what exactly it does
[17:47] <ccheney> er hearing in my mind ;-)
[17:50] <rugby471> ccheney: what is the F11 change?
[17:50] <mac_v> ccheney: lol
[17:51] <mac_v> ccheney: why not switch " Shift-F12 is ungroup and shift-F3 "
[17:51] <mac_v> ?
[17:53] <ccheney> mac_v: F-key mappings are sets eg F11 (regular, shift, alt, shift+alt) all do style related things
[17:53] <ccheney> F12 does group and shift-F12 does ungroup, just moving group to F3 doesn't work well because Shift-F3 is used so you can't move shift-f12 ungroup to it
[17:54] <mac_v> hrm...
[17:54] <ccheney> so by rearranging all the keybindings you aren't keeping related things on the same key
[17:54]  * mac_v ducks , this mess
[17:54] <mac_v> ;p
[17:54] <ccheney> rickspencer3: ping ^
[17:54] <rickspencer3> ccheney, right
[17:55] <ccheney> yea, upstream could potentially fix this, but they might not even want to try since it causes a huge reorg of all the mappings (most likely)
[17:55] <rickspencer3> this is why we should have started this long ago
[17:55] <ccheney> i can just free up F11 but if done it won't really work well from a user perspective
[17:55] <rickspencer3> ccheney, so what you suggest?
[17:56] <ccheney> i dunno
[17:56] <ccheney> we do have a upstream bug already for it and aiui its been forwarded to the ui team at OOo, but i don't know the status on the list
[17:56] <ccheney> also just changing the keybindings doesn't change all the documentation telling you which keys to use by default
[17:56] <cassidy> seb128: seems http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=058776bcf1ab218b509d19685a0b528d71c65f98 would be good to have. It improves audio conferencing
[17:57] <ccheney> so really we would need to change that too, makes it much larger in scope than just a papercut (i think)
[17:57] <cassidy> seb128: don't ask me more ;)
[17:57] <seb128> cassidy, cd discussion with slomo this afternoon ;-)
[17:57] <cassidy> seb128: oh you're already on it, great :)
[17:59] <slomo> seb128: you might want to come into #gstreamer and convince thaytan to make new core/base releases 2 weeks earlier because of gnome 2.28 and all that :)
[18:01] <slomo> seb128: i don't know if he's still there though, best time might be tomorrow
[18:01] <seb128> slomo, I did ping, will try again tomorrow if he doesn't reply
[18:05] <ccheney> rickspencer3: what do you think i should do for the keybinding issue?
[18:08] <rickspencer3> ccheney, let me think
[18:09] <rickspencer3> I think that group and ungroup by keybinind is probably less of common scenario than a netbook user trying to see the whole screen
[18:09] <slomo> seb128: of course that will mean that automatic codec installation will only be fixed in 0.10.26 ;)
[18:10] <ccheney> rickspencer3: david siegel thinks it probably doesn't qualify as a papercut anymore due to the extent of change
[18:10] <chrisccoulson> pitti - you still here?
[18:10] <chrisccoulson> just discussing this gnome-session crash with kklimonda at the moment
[18:11] <rickspencer3> ccheney, is it possible to ship a way to go back to stock OO keybdindings?
[18:11] <chrisccoulson> http://pastebin.com/f5dc691b3 is quite interesting
[18:11] <chrisccoulson> one DeviceAdded signal for the mouse, then there is a DeviceRemoved when it is connected, but no DeviceAdded signal when it is connected for the second time
[18:12] <chrisccoulson> then when it is removed the second time, the DeviceRemoved signal triggers the crash in both gnome-session and g-p-m
[18:12] <rickspencer3> ccheney, dang it
[18:12] <rickspencer3> :/
[18:12] <chrisccoulson> i meant to say "DeviceRemoved when it is disconnected". d'oh
[18:12] <ccheney> rickspencer3: probably not very easily, but i'm not certain
[18:16] <ccheney> reading the OOo ux list annoys me, they don't seem to care about system standard keybindings for apps at all :-\
[18:17] <ccheney> as far as i can tell F11 is supposedly the standard for Win/Gnome/KDE but they refuse to use it properly
[18:19] <rickspencer3> ccheney, it seems that when you modify your keybindings in OOo, it creates a new little file that you can move around
[18:20] <rickspencer3> could we not simply make such an extra little file, call it "ubuntu keyboard short cuts" and drop it in the right place?
[18:21] <ccheney> the right place being the users .openoffice.org dir ?
[18:21] <mpt_> mvo, not sure if you sure (I dropped off IRC): <https://code.launchpad.net/~mpt/software-store/help> is updated
[18:21] <mpt_> if you saw, rather
[18:22] <ccheney> or do you mean diverting all the default.xml files under /usr to be a different set?
[18:22] <rickspencer3> ccheney, I don't know
[18:26] <ccheney> for oem's (eg netbooks) we could do that without it changing for general ubuntu since there is a separate repo, it wouldn't change for regular unr though
[18:30] <pitti> Taekwondo o'clock, cu tomorrow!
[18:35] <davmor2> bryce: bug 423415 is getting weirder.  I've added a video clip and as much info as I can and I've run out of ideas on what else I can add.  This bug is still only effecting ubuntu's gnome desktop and nothing else which is the really weird bit :(
[19:12] <mvo> mpt: merging now + making the column text scretch
[19:12] <mpt> neat
[19:12] <mvo> (and merging the changes from rugby)
[19:24] <mvo> mpt: I looked at the branch from michael, but it gives me funny results, the games icon is ~96px, the sound & video 24px everything else 48px
[19:25] <mpt> mvo, is it using SVG icons? If so, maybe those have a suggested default size?
[19:52] <mvo> wb mpt
[20:32] <mpt> mvo, on the application screen, how can I tell from JS whether I'm in the "Get Free Software" section or the "Installed Software" section?
[20:36] <mpt> ewww
[20:36]  * mpt discovers the CSS that puts the "this is installed" emblem in place :-P
[20:38] <mvo> mpt: heh :) I will blame one of the contributors :P
[20:38] <mvo> mpt: you mean in the app-details - how to tell if its installed or not? I can give you anything you want there via the template system
[20:39] <mpt> mvo, I think what would be ideal would be <body class="section-get"> or <body class="section-installed"> depending on what section you're in
[20:40] <mvo> mpt: sure, that can be arranged
[20:41] <mvo> mpt: but only in ~1h or so :/
[20:41] <mpt> sure
[20:42] <mpt> oh boo, merely changing the background color of a button reverts it right back to non-GTK ugliness
[20:57] <asac> Riddell: do you still have this old UMTS card you had back in london at some point ;)?
[20:57] <asac> was that a "nozomi" driver thing?
[21:13] <mpt> mvo, when an application's icon is SVG, how is its rendered size decided for the application screen?
[21:16] <mpt> mvo, nm, I found it in appdetailsview.py
[21:18] <mpt> mvo, hm, actually, I don't see reference to SVG in that code at all
[21:20] <chrisccoulson> seb128 - did you start that MIR yet?
[21:20] <seb128> chrisccoulson, no
[21:20] <seb128> I've been tried to catch up on upgrade
[21:20] <seb128> upgrades
[21:21] <chrisccoulson> yeah, i've been trying to debug gnome-session crashing, but i'm done with that now. i'll take a look at this MIR
[21:21] <seb128> thanks
[21:22] <seb128> did you find a bug in gnome-session?
[21:22] <chrisccoulson> seb128 - there is a gnome-session crash, but it's actually a devicekit-power bug
[21:22] <chrisccoulson> https://bugs.freedesktop.org/show_bug.cgi?id=23820
[21:23] <chrisccoulson> it's also making g-p-m crash in the same way
[21:23] <seb128> k
[21:24] <seb128> launchpad seems to behave correctly again now
[21:24] <chrisccoulson> yeah, i've not had any issues with it this evening
[21:25] <chrisccoulson> i sometimes wonder whether some of the issues i have at work are down to our IT network
[21:25] <chrisccoulson> our internet connection is routed via a swedish proxy
[21:36] <mvo> mpt: the change for the css is commited, you have section-get and section-installed as body class in rev 217
[21:37] <mvo> mpt: I use the icon_theme loader function to get the right image, for the html there is a ${icon_width} and ${icon_height}
[21:38] <mvo> mpt: in the AppDetailsView.html
[21:38]  * mpt has the department icons lining up in a grid now
[21:39] <mvo> mpt: execllent! is it availabe somewhere yet :) I'm eager to learn more about this stuff
[21:39] <mpt> mvo, the only thing missing was "!important" after the width: :-)
[21:39] <mpt> (and then fixing vertical alignment)
[21:39] <mpt> but I don't have the ellipsis working yet
[21:40]  * mvo nods
[21:43] <statik> hi there kenvandine, i want to help out with a bug i heard of with couchdb being started by default during boot. jcastro had it in his boot chart, and he mentioned you knew there was a bug already filed on it, but I haven't found such a bug
[21:43] <mpt> mvo, can you switch to larger icons for the departments? Like, at least twice as large?
[21:43] <mvo> mpt: not easily, the sound and video icon is only available as 24px
[21:43] <kenvandine> statik, oh... i don't know of a bug to keep it from starting
[21:43] <mpt> ah
[21:43] <mvo> mpt: its trivial to change to a bigger size, but it just looks ugly then
[21:44] <kenvandine> but there is a bug for making it not call xulrunner right?
[21:44] <mvo> mpt: I can do you a commit for this (or send a patch) if you want to try it out
[21:44] <kenvandine> statik, although it probably shouldn't start at boot
[21:44] <mpt> mvo, ok, we'll make it ugly, and kwwii can fix it before ArtworkFreeze
[21:44] <mpt> mvo, I can fix it
[21:44] <mpt> ehhh
[21:44] <mvo> mpt: catview.py line 55
[21:45] <mpt> mvo, exactly, I changed it to 48 and Games gave me 96-ish
[21:45] <statik> kenvandine: the xulrunner thing might be a red herring. xulrunner is what has the spidermonkey javascript engine in it, so it's hard to say for sure without getting some more details. i'd like the couchdb to not start until the user starts evolution or firefox or somethign though
[21:45] <chrisccoulson> vuntz - did you discuss with hughsie about how screensaver locking on suspend should be implemented? (i can't remember if you said you were going to or not)
[21:46]  * ccheney should finally get the signed contract for his new home today :)
[21:47] <mvo> mpt: that seems to be caused by games only available as 24px or svg
[21:47] <mvo> mpt: I think I can fix that in the JS, give me a sec
[21:49] <kenvandine> statik, yeah... so only start on the desktop in the users session if needed
[21:49] <kenvandine> and no system couch
[21:49] <statik> yeah. so i'm thinking i might be able to change the package to disable the system couch, and get it completely off the bootchart
[21:51] <statik> i don't see a bug related to this on the couchdb sourcepackage, maybe it is on xulrunner...
[21:51] <mvo> mpt: commited as r218
[21:55] <kenvandine> statik, i don't recall where it was
[21:56]  * kenvandine looks
[21:57] <kenvandine> bug 421422
[21:57] <kenvandine> statik, ^^
[21:57] <mpt> mvo, merged, thanks
[21:57] <kenvandine> statik, not exactly the same thing
[21:57] <kenvandine> but the result should be not running xulrunner at boot
[21:58] <kenvandine> statik, so perhaps split /etc/init.d/couchdb into a separate binary package?
[22:01] <vuntz> chrisccoulson: no, didn't have time to discuss
[22:01] <chrisccoulson> ok, i might mention it to him then. you don't think the functionality belongs in gnome-session do you?
[22:02] <vuntz> chrisccoulson: imho, it shouldn't be in gnome-session
[22:02] <chrisccoulson> i think it would be nice if DkpClient emitted a signal on suspend that gnome-screensaver could hook on too and lock the screen with
[22:03] <mpt> mvo, so I just asked the editor of the W3C CSS3 Text module, :-P and the reason the ellipsis didn't work the way we want is that it's not implemented yet
[22:04] <vuntz> chrisccoulson: yep
[22:05] <vuntz> chrisccoulson: we should at least have a bug filed somewhere to track the issue
[22:06] <chrisccoulson> vuntz - yeah, i will do that. we probably need one on b.g.o (for gnome-screensaver) and b.fd.o (for dk-power)
[22:06] <mvo> mpt: heh :)
[22:06] <mvo> mpt: at least we have a authoritative answer now
[22:08] <statik> kenvandine, that sounds like the ideal fix. jcastro is filing a separate bug for that with the bootchart attached
[22:09] <vuntz> chrisccoulson: thanks!
[22:10] <mpt> mvo, the reason I was asking about the icon size for the applications is that applications that have only tiny icons (e.g. ACM Aerial Combat Simulator) are getting theirs blown up jaggily, whereas applications that have beautiful scalable icons (e.g. Inkscape) are looking scratchy
[22:13] <mvo> mpt: inkscape looks ok here - what should we do aobut the size? show them all bigger? or try to figure it out based on the icon size?
[22:15] <mpt> mvo, I thought it would be nice to show applications that have a scalable icon at 128*128, while those that don't end up with their largest icon centered in a 128*128 square
[22:15] <mpt> mvo, that would be a subtle nudge to application developers to get themselves scalable icons
[22:16] <mpt> mvo, I have the CSS sorted to do that except at 64*64, since even Inkscape's icon wasn't going any larger
[22:16] <mpt> so I'll push this up, and then you can double the numbers if you have time.
[22:17] <mvo> mpt: ok, please push (or commit directly to trunk)
[22:17] <mvo> mpt: I need to upload 0.3.0 before midnight...
[22:20] <mpt> mvo, ok, I'll let you know when push is complete
[22:29] <mpt> mvo, pushed to https://code.edge.launchpad.net/~mpt/software-store/css
[22:34] <mvo> mpt: merged, many thanks
[22:35] <mpt_> mvo, did you see the branch?
[22:37] <mvo> mpt_: the ~mpt/software-store/css branch? yes, I just merged it
[22:37] <mpt_> thanks mvo
[22:38] <mpt_> mvo, is there anything else I can help with today?
[22:39] <mvo> mpt_: I think we are done for now, I will look at a issue in the JS next, if that is fixed I upload 0.3.0
[22:39] <mvo> (and go to bed)
[22:39] <mvo> mpt_: thanks for the css, that was a very valuable help
[22:41] <seb128> mvo, bou
[22:42] <mvo> seb128: *wehh*
[22:42] <seb128> mvo, I got the "you should reboot" dialog again while update-manager was still running
[22:42] <mpt_> mvo, and thank you for working so hard on this and fixing so many of the bugs
[22:42] <mvo> seb128: I was able to reproduce that here too, happens on a partial upgrade, right?
[22:42] <seb128> it's asking me if I want to clean up now
[22:42] <seb128> mvo, it happens when I click on dist-upgrade sort of button it shows me on start
[22:43] <seb128> ie when things need to be installed and cleaned
[22:43] <seb128> I never know how you call that ;-)
[22:43] <mvo> seb128: yeah, I was able to reproduce that
[22:43] <seb128> dist-upgrader?
[22:43] <mvo> partial upgrader
[22:43] <seb128> or is the dist-upgrader only distro to new distro?
[22:43] <seb128> ok
[22:43] <seb128> so you don't need extra infos I guess, I can click on clean?
[22:44] <mvo> seb128: yeah, I know the problem, I just not got around to fix it yet :(
[22:45] <mpt_> mvo, what do you think are the odds of getting an exception tomorrow/Friday for the path button code? It doesn't affect any documentation. The only thing it would affect would be non-thumbnail-sized screenshots.
[22:45] <seb128> mvo, ok, cool
[22:47] <mvo> mpt_: well, the code is of unknown quality (also it looks nice) - and needs to get integrated
[23:02] <djsiegel___> seb128 mpt, do either of you know why the only nautilus toolbar icons with labels are Back and Forward -- probably the two toolbar buttons that need labels the least?
[23:03] <seb128> no idea
[23:03] <djsiegel___> hmmm
[23:04] <djsiegel___> seb128: think we should turn them off?
[23:04] <djsiegel___> remove the Back and Forward labels?
[23:04] <djsiegel___> I think that would be an improvement over the current situation
[23:04] <djsiegel___> besides, the margins are weird and the labels touch the icons
[23:04] <seb128> you mean change the flag which makes those being display when setting text beside icons
[23:04] <djsiegel___> yes
[23:05] <seb128> since we don't set that option by default that probably doesn't confuse many users
[23:05] <djsiegel___> we don't?
[23:05] <seb128> I'm fine changing it but I would rather see that done upstream to avoid having distro changes there
[23:05] <seb128> no we don't
[23:05] <djsiegel___> it's turned on in Karmic now
[23:05] <djsiegel___> are we going back?
[23:06] <djsiegel___> to text under icons?
[23:06] <seb128> oh, right, GNOME pushed that in the same time as the no icon in menus for testing
[23:06] <seb128> I've no strong opinion
[23:07] <djsiegel___> hmm
[23:07] <seb128> I though mpt was against text beside icons because apps don't behave correctly
[23:07] <djsiegel___> right
[23:07] <seb128> well I will let you guys decide on whether applications behave enough in karmic or not
[23:08] <seb128> I'm fine changing nautilus but as said that should go upstream, the change would be quick to do but every change we carry is extra work for every update we do
[23:08] <seb128> and has a non null cost over time
[23:09] <djsiegel___> of course
[23:09] <andreasn> djsiegel___, I think those are marked as "important", ie, the logic is bigger hit targets
[23:09] <djsiegel___> I see
[23:09] <djsiegel___> mpt_, any word on text beside vs below icons?
[23:11] <rickspencer3> if (cost != NULL) throw new PlanningException("Out of resources");
[23:12] <mpt_> djsiegel___, I think text beside icons looks ugly in toolbars. I have no idea whether "apps behave correctly"
[23:12] <djsiegel___> mpt_: I don't think they do behave correctly :)
[23:13] <mpt_> well, gosh darn it
[23:13] <rickspencer3-afk> looks like seb128 bot crashed when I threw that exception
[23:14] <rickspencer3-afk> looks like a sentry thread restarted seb128
[23:14] <rickspencer3-afk> ;)
[23:14] <mpt_> djsiegel___, I think (1) applications should choose text-under-icons or no-text-at-all based on what's most suitable for the individual application, (2) the global setting for toolbar text should be abolished, and (3) all themes should use a smaller font size for toolbar button labels than they do for other text.
[23:14] <seb128> hehe
[23:14] <djsiegel___> mpt_: yes
[23:15] <rickspencer3-afk> bbl
[23:32]  * mpt_ wonders what happened to the necessary gnome-panel changes for the Store
[23:33] <seb128> what gnome-panel changes?
[23:34] <seb128> adding it in the system menu?
[23:34] <seb128> is somebody supposed to work on that? I can have a look otherwise
[23:35] <seb128> I read the bug but since software-store is in universe atm I have that on the bottom of my todolist