[00:07] <bryceh> git 4b42448a2388d40f257774fbffdccaea87bd0347 in xserver dropped it
[00:07] <bryceh>    xserver: remove RAC/resource handling code.
[00:07] <bryceh>     
[00:07] <bryceh>     This changes the ABI, but since the video ABI is at 6 already
[00:07] <bryceh>     it should be fine.
[00:07] <bryceh>     
[00:08] <bryceh>     driver changes are in the pipeline after this.
[00:08] <bryceh>     
[00:08] <bryceh>     Signed-off-by: Dave Airlie <airlied@redhat.com>
[00:09] <bryceh> there isn't an explanation why... maybe redhat is doing it just to make your life harder asac ;-)
[00:11] <asac> bryceh: have a link to that commit?
[00:11] <asac> want to check the driver changes landed afterwards
[00:11] <asac> so i might figure how to port this ;)
[00:11] <asac> e.g. would like to see "driver changes are in the pipeline after this."
[00:13] <bryceh> asac, I'm just looking in the git tree on my hd, but you should be able to locate the commit via cgit.freedesktop.org
[00:14] <bryceh> asac, http://lists.freedesktop.org/archives/xorg-announce/2009-September/001008.html
[00:14] <asac> ok checking
[00:14] <asac> thanks
[00:14] <bryceh> some adjacent commti messages:
[00:14] <bryceh>       dix/resource: fix use after free in resource code with DRI
[00:14] <bryceh>       pci: add support for pci is boot vga call.
[00:14] <bryceh>       xserver: remove RAC/resource handling code.
[00:14] <bryceh>       sbus: fixup for rac removal
[00:14] <bryceh>       ddx: fix xf86Config.a generation
[00:14] <bryceh>       parser: make libxf86config_internal.la not installed.
[00:16] <bryceh> asac, http://lists.freedesktop.org/archives/xorg-devel/2009-July/001527.html
[00:18] <bryceh> asac, rationale appears that the pci rework stuff had broken this anyway a few releases back, and since there were no complaints about that they decided to remove the code entirely
[00:21] <asac> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=21a621c297ac71c65c239ea960c38706e718b91c
[00:21] <asac> one example ;)
[00:21] <asac> that doesnt do much ;)
[00:21] <asac> +#ifndef XSERVER_LIBPCIACCESS
[00:21]  * asac needs to find some driver that made more extensive ues of it
[00:22] <asac> what version are we at?
[00:24] <asac> ok i think i got the idea
[00:30] <asac> bryceh: is there a good template package to use to package up a driver?
[00:30] <asac> video
[00:33] <bryceh> asac, I usually start from the -intel driver.  It tends to be the best maintained
[00:34] <bryceh> it's got a lot of extraneous stuff that might not be necessary for an arbitrary driver
[00:34] <bryceh> the -vesa driver is useful for comparison there, as it is more minimalist
[00:37] <asac> kk
[00:37] <asac> will check those out
[00:37] <asac> just want to ensure stuff gets installed in right place for now ;)
[00:37] <asac> and then pray :-P
[00:37]  * bryceh nods
[00:44] <maxb> Hi. Where do I register my vote for PLEASE PLEASE PUT THE WINDOW BUTTONS BACK ?  Thanks :-)
[00:45] <lifeless> gconf-schema ? :P
[00:45] <bryceh> maxb, not here
[00:46] <maxb> Well yes, I realise moaning about it on IRC is unproductive, but this seems about the right place to know where, if anywhere, a useful tally is being kept
[00:49] <rickspencer3> maxb, this channel is for the developers who are putting together the distro
[00:49] <rickspencer3> try #ayatana maybe
[00:49] <maxb> ok
[00:50] <rickspencer3> maxb, you are welcome to hang out here, but we just trust the design team to do their job, and we do ours ;)
[04:15] <kenvandine> RAOF, the libu1 mono bindings are staying in universe for now
[04:15] <kenvandine> but he plans to finish the banshee store plugin for lucid
[04:15] <RAOF> kenvandine: Sweet.  Given banshee itself is in universe, I wouldn't expect anything more.
[04:17] <kenvandine> he tested the bindings by writing a store in 10 lines of C# :)
[04:19] <RAOF> Hurray for good bindings and powerful languages :)
[04:20] <RAOF> I wonder if I should spend a week doing development on this netbook.  I'd be much, much more likely to care about performance.
[06:20] <pitti> Good morning
[06:23] <pitti> didrocks: you rock! http://people.canonical.com/~scott/daily-bootcharts/20100310-max-netbook.png
[06:23] <pitti> didrocks: the bg cache finally works \o/
[06:28] <desrt> you cats gonna make your 10s goal?
[07:04] <pitti> desrt: getting there
[07:04] <desrt> pretty sweet
[07:04] <desrt> 15s is already a very huge improvement
[07:04] <desrt> won't go unnoticed by the press :p
[07:05] <pitti> desrt: regular desktop is at 16.5, mostly because of compiz
[07:05] <pitti> desrt: if you enable metacity, it's probably more like 14
[07:05] <desrt> either way, a marked improvement from the days of 40
[07:05] <pitti> desrt: but that's only on this atom processor; ogra's laptop boots in 8 :)
[07:05] <pitti> absolutely, yes
[07:08] <desrt> pretty cool stuff
[07:08] <desrt> btw: i hope you come to my 3 security-related sessions :)
[07:08] <pitti> desrt: I will! the umask thing, and such, right?
[07:08] <desrt> ya
[07:08] <desrt> they just got marked for uds-m the other day
[07:09] <desrt> which i think is all that's needed to get into the schedule?
[07:09] <pitti> for now, yes
[07:19] <tjaalton> "ureadahead terminated with status 5"
[07:20] <tjaalton> that happens on the uni computers I'm working on, and it slows down the boot considerably :/
[07:32] <tjaalton> well, running fsck every time probably kills it..
[07:32] <tjaalton> happens on my laptop as well
[07:36] <tjaalton> or does ureadahead rely on having /var on the same fs as root?
[07:38] <didrocks> good morning
[07:38]  * didrocks hugs pitti
[07:38] <pitti> bonjour didrocks
[08:50] <seb128> good morning there
[08:50]  * seb128 wonders what this guy is doing tagging and untagging tons of bugs
[08:52] <didrocks> good morning seb128
[08:52] <didrocks> seb128: I'm working on file-roller and gnome-screensaver
[08:52] <seb128> didrocks, ok thanks
[08:53] <seb128> I'm trying to not touch packages out of the pitivi update I did this morning
[08:53] <didrocks> ok :)
[08:53] <seb128> I need to review and milestone bugs
[08:53] <seb128> so we know what to work on next
[08:53] <didrocks> seb128: good luck on triaging those :)
[08:53] <seb128> thanks
[08:54] <pitti> bonjour seb128
[08:54] <seb128> hey pitti
[08:54] <pitti> seb128: looks like a buggy auto-triaging script from the kernel team
[08:54] <seb128> how are you today?
[08:55] <pitti> I'm great, thanks!
[08:55] <seb128> pitti, yeah, that was my though too now after reading some of those ;-)
[08:55] <pitti> a little stressed, since there's still so much to do for beta-1, but that's fairly normal
[08:55] <seb128> I feel less stressed this week
[08:55] <seb128> now that dx delivered features on time and the artwork landed
[08:56] <seb128> but still pretty busy indeed ;-)
[08:56] <seb128> pitti, can we chat for a few seconds about gdmsetup and login sound?
[08:56] <seb128> pitti, our issue there is to set settings for an another user
[08:57] <seb128> pitti, do you think it would be acceptable to have a small binary setuid gdm write this only gconf key installed?
[08:57] <seb128> pitti, then we wouldn't have to deal with priviledges changes in gdmsetup
[08:57] <pitti> seb128: why couldn't this be set through d-bus by the gdm-binary server, like all the other settings?
[08:57] <seb128> because it's not a server setting
[08:58] <seb128> gdm.conf is written by the server and in etc
[08:58] <seb128> but greeters settings are gdm's gconf database
[08:58] <seb128> the greeter is a graphical ui running as gdm user
[08:58] <pitti> right
[08:59] <pitti> seb128: but gdm still has a session dbus running, etc.
[08:59] <pitti> so couldn't the server just do the gconf call as "gdm"?
[08:59] <pitti> seb128: with a suid gdm binary, everyone could change server settings without any authentication
[09:00] <seb128> hum, maybe for the server writting in gconf
[09:00] <seb128> > everyone could change server settings without any authentication
[09:00] <seb128> no
[09:00] <seb128> the binary would only be writting this 1 gconf key
[09:00] <seb128> and server settings are not in gconf
[09:00] <seb128> they are in gdm.conf in etc
[09:00] <seb128> the only settings in gconf are the gui ones
[09:00] <seb128> ie theme, sound effects
[09:01] <seb128> nothing concerning security or the server
[09:01] <pitti> seb128: so you think it wouldn't be feasible to call gconftool (perhaps with --direct) from gdm-binary for that?
[09:01] <seb128> we really have 2 different components there
[09:01] <seb128> pitti, I didn't think about that before, but it should
[09:02] <seb128> pitti, I bounced you an email from robert_ancell
[09:02] <pitti> seb128: obviously we should avoid linking gdm-binary against libgconf, but a mere g_spawn_async seems rather harmless?
[09:03] <seb128> pitti, we were discussing about that small hackish way
[09:03]  * pitti reads
[09:03] <seb128> but we though about putting it in a small wrapper
[09:03] <seb128> not in gdm server itself
[09:04] <seb128> but I don't see any reason why it could be done in the server
[09:04] <pitti> setuid for scripts doesn't work, right (by their nature)
[09:05] <pitti> seb128: with that, the gdm-binary d-bus interface could just grow a new SetGconfOption() method, then we can reuse that for other settings in the future?
[09:05] <seb128> well I really wanted to do that in an elegant way
[09:06] <seb128> rather than calling g_spaw sudo -u <user> gconftool
[09:06] <seb128> but right
[09:06] <pitti> seteuid(gdm); g_spawn_async(); seteuid(0), but yes
[09:06] <pitti> seb128: another alternative: just add LoginSound to custom.conf, and if it's not there, use gconf? would that work?
[09:07] <pitti> I'm not sure whether the simple-greeter reads custom.conf
[09:07] <pitti> or just the gdm-binary
[09:07] <seb128> I don't think the greater does no
[09:07] <pitti> ok
[09:07] <seb128> thanks for the suggestion
[09:07] <seb128> I will have a look to add the method in the server rather than a wrapper
[09:08] <pitti> seb128: could the server just write the updated gconf file directly?
[09:08] <pitti> we already ship gconf xml files in packages, after all (which isn't any better architecture wise)
[09:08] <seb128> would be a bit tricky to get right
[09:08] <pitti> /var/lib/gdm/.gconf.defaults/%gconf-tree.xml
[09:08] <seb128> the config can contain any tweak
[09:09] <seb128> we have to detect if this key is already set
[09:09] <pitti> yes, true
[09:09] <seb128> and change the right part of the xml
[09:09] <pitti> gconftool --direct sounds like the least evil method to me so far, I think
[09:11] <seb128> pitti, well, we write to an user config, not to the system one, I'm not even sure we need --direct
[09:11] <pitti> seb128: usually there's no gconfd running for gdm
[09:11] <pitti> seb128: I guess it wouldn't terribly hurt to launch one (dbus-daemon is running, after all)
[09:12] <pitti> seb128: --direct would break if you have a running session (with gdmsetup) and a running greeter in another X, of course
[09:13] <seb128> I hate the current gdm gconf use
[09:13] <seb128> it's se annoying
[09:14] <seb128> we also have a bug about user changes being overwritten on upgrade
[09:14] <pitti> ah, because we ship the verbatim .xml file, indeed
[09:15] <pitti> seb128: that's actually an issue -- it would revert the gdmsetup login sound change as well
[09:15] <seb128> but we use a different directory
[09:15] <pitti> so perhaps we do need a new gconf search path after all
[09:15] <pitti> oh, we do?
[09:15] <seb128> /var/lib/gdm/.gconf.defaults
[09:15] <seb128> we write there
[09:15] <seb128> not in .gconf
[09:16] <seb128> and we have a /var/lib/gdm/.gconf.path
[09:16] <seb128> "# distribution default values
[09:16] <seb128> xml:readwrite:$(HOME)/.gconf.defaults
[09:16] <seb128> "
[09:16] <seb128> I bet it needs to be readonly
[09:16] <pitti> ah, good
[09:16] <seb128> I will check on that
[09:16] <seb128> the readwrite might make user wants to land there too
[09:16] <seb128> rather than in .gconf
[09:16] <pitti> yes, rw sounds dangerous for files shipped in .debs
[09:17] <seb128> wants -> changes
[09:19] <czajkowski> aloha
[09:20] <seb128> hey czajkowski
[09:20] <chrisccoulson> good morning everyone
[09:21] <seb128> hey chrisccoulson!
[09:21] <seb128> how are you?
[09:21] <chrisccoulson> seb128 - yeah, good thanks. how are you?
[09:21] <czajkowski> seb128: do you sleep or what timezone are you in!
[09:22] <seb128> czajkowski, I do sleep and I'm in Europe
[09:22] <seb128> chrisccoulson, good, thanks!
[09:22] <seb128> czajkowski, I don't sleep enough some days though ;-)
[09:22] <didrocks> hey chrisccoulson, czajkowski
[09:22] <chrisccoulson> hey didrocks
[09:22] <czajkowski> seb128: oh I'm the same!
[09:22] <czajkowski> didrocks: morning
[09:23] <czajkowski> today I'm on implementation and someone has added new code to the system and broken a lot of stuff on me >:(
[09:23] <seb128> chrisccoulson, I still get g-s-d crashing on boot :-(
[09:24] <seb128> chrisccoulson, it's a different bug than the libgnomekbd one
[09:24] <chrisccoulson> seb128 - oh, that's not good. only with the keyboard indicator?
[09:24] <seb128> the crash I get seems similar to bug #522639
[09:25] <chrisccoulson> oh, you're not using nautilus to draw the desktop?
[09:25] <seb128> I do I think
[09:25] <seb128> at least it's running and I get the nautilus context menu and icons there
[09:26] <chrisccoulson> that's strange :-/
[09:26] <seb128> #2  0x00f8d515 in draw_color_area (bg=<value optimized out>, dest=0x658,
[09:26] <seb128>     rect=0x2d1) at gnome-bg.c:759
[09:26] <seb128> No locals.
[09:26] <seb128> #3  0x00f91044 in draw_color_each_monitor (bg=0x821e800, dest=0x81b8b98,
[09:27] <seb128> ......
[09:27] <seb128> #6  0x07af2209 in ?? ()
[09:27] <seb128>    from /usr/lib/gnome-settings-daemon-2.0/libbackground.so
[09:27] <seb128> indeed
[09:27] <seb128> could it be a race on autologin?
[09:27] <pitti> hey chrisccoulson
[09:27] <chrisccoulson> hey pitti
[09:27] <seb128> it sucks that g-s-d crash on any of its .so crash
[09:27] <chrisccoulson> seb128 - yeah, possibly. i don't normally use autologin. that might be why i've not seen it
[09:27] <seb128> it means it's not very robust with bugs in random libs
[09:28] <seb128> like libgnomekbd
[09:28] <seb128> or libxklavier
[09:28] <seb128> or whatever you don't always care about but takes themes, etc down
[09:28] <chrisccoulson> yeah, it's a bit of a pain sometimes
[09:28] <seb128> pitti, oh, thanks for fixing that glib unit bug
[09:29] <didrocks> chrisccoulson: IIRC, the check of nautilus is done at the beginning of gnome_bg_draw() function in g-s-d plugin. Weird that it continues…
[09:30] <didrocks> (draw_background() function in g-s-d)
[09:31] <chrisccoulson> yeah, i'm a bit confused by that
[09:37] <chrisccoulson> pitti - do you know how gnome-power-manager is meant to deal with brightness keys that control the brightness in hardware?
[09:37] <chrisccoulson> i notice that my brightness keys change the brightness in multiple steps
[09:37] <pitti> chrisccoulson: it should just read the current brightness and do the notification bubble, but not actually change the brightness
[09:37] <chrisccoulson> and if i stop gnome-power-manager, i can still control the brightness, but just in lesser increments
[09:38] <chrisccoulson> ah, it's actually changing the brightness here too
[09:38] <chrisccoulson> i wasn't sure how that was all meant to work though, but it sounds like gnome-power-manager is doing the wrong thing then
[09:39] <pitti> chrisccoulson: is your's using hal?
[09:39] <chrisccoulson> pitti - no, mines using xrandr
[09:40] <pitti> chrisccoulson: hm, I don't actually know whether there's a brightness_in_hardware counterpart for this
[09:41] <chrisccoulson> ah, ok. so that could be a limitation of the xrandr interface then
[09:41] <pitti> chrisccoulson: it might be related to /sys/module/video/parameters/brightness_switch_enabled
[09:42] <pitti> but I'm not sure whether that's actually relevant for xrandr
[09:42] <chrisccoulson> ah, if i set that to "N", then it stops the hardware control
[09:42] <bryceh> only a small subset of hardware supports doing brightness via xrandr at the moment afaik
[09:43] <chrisccoulson> and gnome-power-manager is doing small increments now
[09:43] <pitti> if that's the file which indicates that, then perhaps g-p-m should check that one
[09:43] <pitti> bryceh: right
[09:43] <chrisccoulson> yeah, i'll chat with hughsie and see what he thinks too
[10:14] <chrisccoulson> what does rhythmbox build-depend on xulrunner-dev for?
[10:14] <chrisccoulson> there doesn't seem to be any binary dependencies
[10:19] <pitti> chrisccoulson: perhaps in the past one of the music stores used that to display web sites?
[10:19] <chrisccoulson> pitti - yeah, i'm not sure. i'm trying a build now without the dependency
[10:19] <chrisccoulson> i can't see any check for it in configure.ac either
[10:20] <chrisccoulson> so, that might be an easy transition ;)
[10:23] <milanbv> chrisccoulson, pitti: mind talking about services-admin once again? ;-)
[10:29] <chrisccoulson> milanbv, i might struggle to find the time to talk about it this morning ;)
[10:29] <milanbv> chrisccoulson: depends on what you plan to do
[10:30] <seb128> chrisccoulson, pitti: rhythmbox, it is,was for the some firefox plugins for i<somthing>
[10:30] <milanbv> if you just want to reenable services-admin, it should take only a few minutes
[10:30] <milanbv> no need to make a release specially for that
[10:31] <milanbv> else it might be worth discussing longer :-)
[10:32] <pitti> milanbv: what do you currently do with init.d scripts? what with upstart scripts?
[10:32] <pitti> and how do we make sure that the user can't disable vital system services?
[10:32] <milanbv> pitti: we support init.d scripts just as before, and ignore upstart jobs
[10:32] <chrisccoulson> seb128 - librhythmbox-itms-detection-plugin.so?
[10:32] <seb128> chrisccoulson, I guess so
[10:32] <milanbv> the only change is that we hide dummy init.d scripts that link to upstart jobs
[10:33] <pitti> milanbv: does that filter out init.d scripts which symlinks ot /lib/init/upstart-job?
[10:33] <milanbv> and we hide vital services using a list that I've just updated
[10:33] <pitti> ah, good
[10:33] <milanbv> pitti: yes
[10:34] <seb128> chrisccoulson, it seems to not be required for a while though
[10:34] <seb128> chrisccoulson, it's probably a leftover
[10:34] <seb128> chrisccoulson, reading git log
[10:34] <chrisccoulson> seb128 - it's still being built
[10:34] <seb128> well but it doesn't require xul apparently
[10:35] <chrisccoulson> yeah, that makes sense. it built fine without it anyway ;)
[10:35] <seb128> the build-depends is a leftover
[10:35] <chrisccoulson> cool, i will remove that then
[10:35] <seb128> thanks
[10:35] <seb128> brb
[10:37] <seb128> re
[10:37] <seb128> rodrigo__, tomboy 1.1.4 is in lucid already since yesterday
[10:38] <seb128> chrisccoulson, let me know if you need sponsoring for something btw
[10:38] <seb128> chrisccoulson, you should really apply for main uploads ;-)
[10:38] <chrisccoulson> seb128 - thanks
[10:38] <chrisccoulson> yeah, i will apply soon :)
[10:39] <rodrigo__> seb128, ah, cool!
[11:02] <asac> mvo on vacation?
[11:02] <asac> hmm
[11:04] <dpm> hi seb128, I've noticed that the Evolution desktop entry does not load translations, even if they are present in the .mo files and the X-Ubuntu-Gettext-Domain field is correct on the .desktop file. Any idea what this could be?
[11:04] <dpm> Also, I notice on http://pastebin.ubuntu.com/392424/ that there are now [Compose Shortcut Group] and [Contacts Shortcut Group] sections with Name fields. It's the 10_desktop_shortcuts.patch. Can these be made translatable?
[11:05] <seb128> dpm, what entry?
[11:05] <seb128> the indicator one or the menu one?
[11:05] <seb128> dunno about 10_desktop_shortcuts.patch check with kenvandine and ted
[11:07] <dpm> seb128, the menu one. ok, for the rest I'll check with them
[11:07] <seb128> dpm, is the title translation in your langpack?
[11:08] <dpm> yes
[11:08] <dpm> the domain is correct in the .desktop file, and the translations are in the .mo file
[11:09] <dpm> I've just noticed this recently, it used to be translated some days ago
[11:09] <seb128> is it correct in /usr/share/applications/desktop*cache?
[11:09] <dpm> let me check...
[11:10] <seb128> I guess it's again a gnome-menus cache issue
[11:10] <seb128> it might not like the recent dx addtions to the desktop entry
[11:11] <dpm> in /usr/share/applications/desktop*cache the entry is in English
[11:11] <seb128> can you open a bug on gnome-menus?
[11:11] <dpm> sure
[11:12] <pitti> dpm: assign it to me, please
[11:12] <dpm> ok, thanks seb128 and pitti :)
[11:21] <dpm> ok, it's bug 535650
[11:21] <seb128> dpm, pitti: it's probably a desktop-file-utils issue rather
[11:21]  * pitti -> lunch
[11:21] <seb128> pitti, enjoy
[11:22] <seb128> dpm, thanks
[11:22] <dpm> no worries, I'll open a new task, then
[11:22] <seb128> dpm, don't
[11:23] <seb128> dpm, one task is enough, pitti will reassign if required
[11:23] <dpm> ah, oops
[11:23] <seb128> dpm, when the task is wrong the way is to change it, not to add a new one
[11:23] <seb128> dpm, otherwise you keep mail spamming people subscribing the the wrong task which is still there
[11:23] <dpm> I see, sorry about that.
[11:23] <seb128> np
[11:23] <seb128> it's only a detail
[11:23] <seb128> let the bug as it is now
[11:24] <seb128> we will pick it from there
[11:24] <dpm> thanks seb128, it's good to know that for the future
[11:44] <tseliot> pitti: do you know why the keyboard layout goes back to en-us when I vt switch?
[11:44] <seb128> tseliot, is that a new issue?
[11:44] <tseliot> seb128: no, I don't think so. It's been there for a while
[11:44] <seb128> ok good
[11:45] <seb128> just checking is what not due to the patch I uploaded yesterday
[11:45] <tseliot> no, definitely it wasn't caused by anything uploaded today
[11:46] <seb128> ok thanks
[11:46]  * seb128 lunch
[11:49] <asac> seb128: whats the status of the last upload gnome batch?
[11:49] <asac> something is out of sync for ur for > 24h ;)
[11:49] <asac> wonder if you had some build failures or something in your inbox
[11:50] <asac> ok ogra said it should be fine in 1h
[11:50] <asac> ;)
[11:51] <ogra> it built
[11:51] <ogra> its just the publisher being behind on arch: any
[12:04] <seb128> asac, we are pretty much done with updates
[12:04] <seb128> asac, well there is still a new gtk coming today most likely though
[12:05] <asac> ok
[12:05] <asac> can you upload that EOD=
[12:06] <asac> ?
[12:06] <asac> ogra needs to fix somthing he can only test ;)
[12:06] <asac> with consistent archive
[12:07] <seb128> asac, ok
[12:07] <seb128> I will upload tomorrow rather if you want
[12:07] <seb128> we are not in an hurry
[12:07] <seb128> let me know when you are done with your testing
[12:07] <asac> seb128: its better to have it built over night than over da
[12:07] <ogra> seb128, well, i only need the ubuntu-netbook task installable to debug an apt hang
[12:07] <asac> y
[12:08] <asac> so tonight would be great ;)
[12:08] <ogra> yeah, EOD would help
[12:08] <seb128> ok, works for me
[12:08] <ogra> i wont work tonight :)
[12:08] <asac> cool ;)
[12:34] <chrisccoulson> right, me -> lunch
[12:37] <chrisccoulson> pitti - you didn't update bzr when you uploaded gnome-python-extras ;)
[12:41] <pitti> chrisccoulson: is there a bzr?
[12:41] <pitti> oh, argh
[12:42] <chrisccoulson> there is
[12:42] <pitti> chrisccoulson: I'll fix it, sorry
[12:42] <chrisccoulson> pitti - no worries, i'm fixing it now
[12:42] <pitti> chrisccoulson: ok, thanks
[12:42] <chrisccoulson> i'd already pushed some new changes, and tried to upload
[12:42] <chrisccoulson> and i got a rejection ;)
[12:42] <pitti> tseliot: oh, it does? in X you mean?
[12:42] <pitti> tseliot: or on the VTs?
[12:43] <tseliot> pitti: using the VTs
[12:43] <tseliot> it works well in X
[12:44] <tseliot> Ctrl+Alt+F1 gets me to tty1 with a US layout
[12:44]  * tseliot -> lunch
[12:45] <pitti> tseliot: that sounds related to the plymouth code which replaced loadkeys.sh
[12:46] <pitti> tseliot: do you get it when you purge plymouth?
[12:54] <vish> WOW , first time _ever_ i'v seen seb128 comment on a blog :)
[12:55] <vish> or maybe its because i dont read blog comments often ;p
[12:58] <seb128> vish, it's because I've been asked to put my comment there :p
[12:58] <vish> hehe  ;)
[13:06] <SEJeff_work> What was the technical decision to stick with the old xf86-video-intel driver in a LTS?
[13:07] <SEJeff_work> vs the one where they've fixed a lot of bugs and done a lot of work on which was recently released? Lack of testing bandwidth?
[13:07] <pitti> SEJeff_work: is there a newer version than 2.9.1?
[13:08] <SEJeff_work> Yes, 2.10
[13:09] <SEJeff_work> 2.10 removes userspace modesetting and the giant bunch of code that goes with it.
[13:09] <pitti> SEJeff_work: ah, bryceh just reenabled UMS in the last upload, since apparently KMS still causes problems in some setups
[13:10] <SEJeff_work> pitti, But that means we get the driver from last September which is 6 months old already. Thats a decade in oss development :/
[13:11] <pitti> I don't know more about the plans, sorry
[13:11] <SEJeff_work> thanks
[13:11] <pitti> SEJeff_work: tjaalton and bryceh might have an opinion/existing plan, though
[13:13] <tjaalton> SEJeff_work: https://lists.ubuntu.com/archives/ubuntu-x/2010-March/000822.html
[13:14] <SEJeff_work> tjaalton, Right, but it seems like you'll be rebasing any fixes. Not so great from a LTS perspective even with 25 kernel devs on the 2 kernel teams: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=8ae0e44e42db645abe6d385f561260d2ae4a1960
[13:14] <SEJeff_work> thanks tjaalton
[13:15] <tjaalton> most of the fixes will be to the drm code anyway
[13:15] <SEJeff_work> Hopefully so. Lucid is looking great so far
[13:18] <kklimonda> seb128: should I tag somehow bugs related to the change of tooltip background in new theme?
[13:18] <seb128> kklimonda, no, is there that many of those?
[13:18] <seb128> kklimonda, I only know about vino and rhythmbox so far
[13:19] <kklimonda> seb128: I don't know - I've just found about vino and I'm using this theme for less then 24 hours ;)
[13:19] <seb128> that's a known issue
[13:28] <tseliot> pitti: ah, so plymouth is overriding the layout?
[13:28] <pitti> tseliot: I'm not sure, I just know that when plymouth is on, loadkeys.sh doesn't run
[13:28] <pitti> or runs differently, or something
[13:29] <tseliot> pitti: I'll ask Keybuk about it, he should know what's happening
[13:29] <tseliot> pitti: BTW what is it that calls loadkeys.sh?
[13:30] <pitti> tseliot: I think /etc/init.d/keyboard-setup from console-setup package
[13:31] <pitti> through setupcon perhaps?
[13:33] <tseliot> ok, thanks
[13:34] <Riddell> what's the difference is between indicator-applet and indicator-messages?
[13:34] <seb128> Riddell, one is an applet, ie a widget, the other one is a service
[13:35] <seb128> Riddell, indicator-sound, indicator-me, indicator-session are services
[13:35] <seb128> they all dock into the applet to be rendered
[13:35] <seb128> Riddell, ls /usr/lib/indicators/3
[13:35] <seb128> Riddell, what are you trying to figure exactly?
[13:36] <Riddell> seb128: what kopete-message-indicator should recommend to users
[13:36] <Riddell> am thinking it's  Recommends: plasma-widget-message-indicator | indicator-applet
[13:36] <seb128> seems about right to me
[13:36] <Riddell> thanks
[13:36] <seb128> np
[13:39] <tseliot> Keybuk: do you know why when we use plymouth, loadkeys.sh doesn't run?
[13:39] <Keybuk> tseliot: yes, because you can't load keys while a splash screen is running
[13:39] <Keybuk> Colin is working on that whole issue
[13:40] <tseliot> pitti: ^^
[13:40] <tseliot> Keybuk: good to know. Thanks
[13:40] <pitti> tseliot: thanks
[13:40] <Keybuk> it's the whole issue where if the vt is in KD_GRAPHICS or K_RAW things don't work out
[13:41] <tseliot> ah
[13:47] <pitti> . o { GTG is awesome }
[13:48] <seb128> pitti, do you know if plan to test rebuild lucid and when?
[13:51] <pitti> seb128: that already happened several times
[13:51] <pitti> I don't know the schedule for the next ones, though
[13:53] <seb128> pitti, I expect quite some drawback due to gtksealing
[13:53] <pitti> seb128: oh, what's that?
[13:53] <seb128> pitti, http://live.gnome.org/GnomeGoals/UseGseal
[13:54] <seb128> pitti, things like http://git.gnome.org/browse/nautilus/commit/?id=8c8cf192d861a1a6c202624ee0b4c0ff43077080
[13:54] <seb128> will probably be required on quite some source
[13:55] <seb128> pitti, it only breaks for things which turn use of deprecated api as errors but by experience there is a bunch of those in the universe
[13:55] <pitti> ah, so all the GTK_FOO_BAR() macros are direct access
[13:56] <seb128> yes
[13:56] <pitti> I see
[13:56] <seb128> and they want to stop that for gtk
[13:56] <seb128> gtk3
[13:56] <seb128> so they add accessor functions instead
[13:56] <seb128> and deprecate the direct access on the way
[13:57] <seb128> usually fixing builds is trivial but we should aim at building at list of things broken early
[14:07] <seb128> pitti, do you think that's worth an ubuntu-devel email?
[14:07] <pitti> seb128: yes, I think so; might help people examining FTBFSes
[14:07] <seb128> ok, will do that
[14:23] <pitti> seb128: adding bug 536670 to lucid, FYI
[14:24] <seb128> pitti, thanks
[14:40] <pitti> pedro_: hey, how are you?
[14:40] <pitti> pedro_: if you have a minute, would you mind testing the -proposed tzdata binaries for bug 532924 ?
[14:40] <pedro_> hey pitti! good thanks, what about you?
[14:40] <pitti> pedro_: I'm great, thanks! hope your family is alright
[14:41] <pedro_> pitti, sure will do it and ask for testing in my loco community too
[14:41] <pitti> pedro_: I already gave them standard testing, but I'd rather have another person acking it before rushing it in
[14:41] <pedro_> roger that
[14:51] <LaserJock> didrocks: around?
[14:51] <didrocks> LaserJock: yes, how are you?
[14:52] <LaserJock> didrocks: doing OK, was just looking more at bug #2814
[14:52] <LaserJock> uhh
[14:52] <didrocks> error on copy and paste? :)
[14:53] <LaserJock> hmm, error in weechat not passing the "three" and "nine" key
[14:54] <LaserJock> bug #283914
[14:54] <LaserJock> weird, I must of messed up a keybinding
[14:54] <LaserJock> didrocks: anyway, there doesn't seem to be any info already cached that would let us know if the icon had changed
[14:55]  * kenvandine goes afk for a bit... parent/teacher conference
[14:55] <kenvandine> should be back in 1 to 1.5 hours
[14:55] <LaserJock> didrocks: would an OK strategy be to add say the size of the icon to the cache and check that?
[14:56] <didrocks> LaserJock: if it's too much work or too hackish, we just maybe postpone. It's not a so important fix to have in lucid
[14:56] <didrocks> LaserJock: we will still have the bug if the size of the icon with the replace one is the same
[14:58] <LaserJock> didrocks: how is it done for the actual .desktop files?
[14:58] <LaserJock> or is n-l lacking an update mechanism there too
[14:59] <didrocks> LaserJock: I think the easiest is to look at the code of the menu. there should be a notification with inotify (not sure about how it's done)
[14:59] <didrocks> LaserJock: I mean, the menu in the panel :)
[15:06] <LaserJock> didrocks: ok, so given approaching Beta1 would you rather I look at bug #455143 or maybe some of the crashers ?
[15:07] <didrocks> LaserJock: I had a look lately, the code to insert is obvious, but not the place where to put it :)
[15:07] <didrocks> (lately == this morning)
[15:08] <didrocks> LaserJock: I think it's a matter of an hour just to understand the difference between the applications places and the favorite one
[15:08] <didrocks> LaserJock: if you want to look at that, it'll rock!
[15:09] <didrocks> LaserJock: the code you want to add is at ../src/nl-favorite-view.c:356 and corresponds to http://paste.ubuntu.com/392589/
[15:09] <LaserJock> didrocks: you wanna give me the obvious code? I'll find where to stick it
[15:09] <LaserJock> ah, you read my mind
[15:09] <didrocks> LaserJock: heh, as I have already found it, you can gain 10 minutes with that :)
[15:10] <didrocks> so, it's just the matter of getting the right clutter actor
[15:10] <didrocks> and add the gtk signal for pressed
[15:11] <LaserJock> didrocks: k, I'll work on that then
[15:12] <didrocks> LaserJock: awesome :)
[15:14]  * LaserJock mumbles "I for one welcome our new didrocks overlord"
[15:16] <didrocks> There are lots of people more talented that I here, I'm afraid ;) but that's kind of you, thanks :)
[15:46] <seb128> chrisccoulson, bug #501252, do you know if that's still true and still an indicator issue?
[15:46] <seb128> chrisccoulson, or rather an upower one?
[15:47] <chrisccoulson> seb128 - both really. with our current architecture, things like gnome-session and indicator-session are all individually responsible for locking the screen, and all implement their own policy for doing that
[15:47] <chrisccoulson> but in an ideal world, gnome-screensaver would get a signal from upower
[15:47] <seb128> chrisccoulson, ok thanks
[15:47] <chrisccoulson> and it would be consistent then, and there would be a global way of disabling it
[15:48] <seb128> chrisccoulson, I'm just triaging bugs today so I was just wondering if that should be reassigned
[15:48] <chrisccoulson> it's ok where it is for now (if we were going to fix it, it would be done in indicator-session for now)
[15:50] <seb128> chrisccoulson, ok thanks
[15:50] <chrisccoulson> seb128 - i wrote a patch for gnome-session to honour that gconf value i think, and apply the same policy as gpm)
[15:54] <rickspencer3> seb128, how is your 100 bugs list going?
[15:55] <seb128> rickspencer3, hey, not done yet, I've added some but I'm helping dxteam right now to triage their list and pick bugs for lucid
[15:55] <rickspencer3> not done, you've had like 12 hours!
[15:55] <rickspencer3> j/k
[15:55] <seb128> ;-)
[15:56] <desrt> uh.
[15:57] <desrt> glib2.0-2.23.5/debian/patches/05_file_size_units.patch
[15:57] <desrt> guys.  seriously.
[15:57] <pitti> desrt: that one has been discussed in the upstream bug for quite a while
[15:58] <pitti> unfortunately still not with any decision
[15:58] <pitti> so we went ahead and patched it
[15:58] <mclasen> we don't plan to change it, how is that not a decision ?
[15:58] <pitti> I didn't see any definite answer there, and the bug is still open
[15:59] <pitti> mclasen: if there is a decision to keep it like that, it should perhaps be WONTFIXed?
[15:59] <mclasen> perhaps
[15:59] <pitti> (which would be sad, but better than leaving it like that, I guess)
[15:59] <mclasen> but you know what would happen...people would open new bugs
[15:59] <pitti> and it's not exactly a huge patch to carry anyway
[16:00] <desrt> pitti: it changes the API/ABI of a supposedly-API/ABI-stable library
[16:00] <desrt> pitti: it also changes the _documentation_ for said library
[16:00] <pitti> so if upstream decides for using KiB/MiB, that's fine as well, but the current units are just wrong
[16:00] <desrt> without maybe making a note about "by the way, this is different on ubuntu than everywhere else on earth"
[16:00] <pitti> desrt: how so? it just outputs wrong numbers, that's just a bug?
[16:00] <desrt> pitti: this is political.
[16:01] <pitti> desrt: everywhere else on earth MB == 10^6
[16:01] <desrt> your opinion of "wrong" is alex's opinion of "right"
[16:01] <pitti> erm, M = 10^6, I mean
[16:01] <desrt> pitti: so many people are _not_ doing that that you guys have a special exception on your wiki page for "things we won't break because it's too important that it continues working properly"
[16:03] <pitti> well, *shrug*, I didn't harass anyone to "plz apply upstream now or we'll hate you forever" or so
[16:03] <pitti> I just found it polite to send the patch to the upstream bug
[16:05] <desrt> pitti: do you not see the potential confusion caused to application developers?
[16:05] <pitti> desrt: I do
[16:06] <pitti> but that confusion is there either way
[16:06] <desrt> i'm less confused when an API in a library that i use for cross-platform compaibility gives the same results on all platform
[16:06] <pitti> gvfs uses correct GBs ("10 GB drive"), gnome-system-monitor uses correct MiB/GiB, etc.
[16:22] <chrisccoulson> pitti - could you please add a lucid task for bug 536737?
[16:23] <pitti> chrisccoulson: done
[16:23] <chrisccoulson> pitti - thanks
[16:37] <chrisccoulson> who is familiar with the couchdb packaging, and could review micahg's change on bug 536737?
[16:38] <seb128> kenvandine, ^
[16:39]  * kenvandine looks
[16:39] <kenvandine> we might want to get statik to look
[16:39] <chrisccoulson> kenvandine, thanks
[16:39] <chrisccoulson> we're just testing the change at the moment
[16:39] <kenvandine> chrisccoulson, i'll handle it
[16:39] <kenvandine> ah... ok
[16:39] <chrisccoulson> awesome, thanks :)
[16:40] <kenvandine> ok, it looks harmless but i will get confirmation
[16:40] <chrisccoulson> thanks
[16:41] <kenvandine> chrisccoulson, if he is happy with it, should he just upload it?
[16:41] <chrisccoulson> kenvandine - i don't mind. i'd like the opportunity to test it first (to make sure it loads the 1.9.2 GRE and works properly)
[16:42] <kenvandine> ok, i'll have him check with you first
[16:42] <kenvandine> thx
[16:42] <chrisccoulson> thanks
[16:49] <chrisccoulson> brb, session restart
[17:10] <mpt> rickspencer3, hi, have you tried Computer Janitor recently?
[17:10] <rickspencer3> mpt, no
[17:10] <rickspencer3> that's a foundationsy thing
[17:10] <rickspencer3> I don't track it
[17:10] <mpt> ok
[17:10] <rickspencer3> mpt, why do you ask?
[17:12] <mpt> rickspencer3, a bunch of us Design team peeps are a bit concerned it doesn't really meet Ubuntu standards, and we were wondering whether it's more realistic to (a) find someone to fix it and get a UI freeze exception or (b) get it taken off the seed for Lucid
[17:12] <mpt> On 2 out of 3 machines we've tried it on, it does nothing at all
[17:14] <seb128> you should check with mvo he's probably the one who knows the status
[17:16] <seb128> rickspencer3, pitti: do we have any way to get a list of bugs with a lucid task on packages that dxteam is responsive for?
[17:16] <seb128> kenvandine, ^
[17:16] <kenvandine> humm
[17:17] <seb128> I think the reply is "no" or at least not in launchpad
[17:17] <seb128> but maybe on some bughugger report or something
[17:17] <kenvandine> yeah, it is no
[17:17] <kenvandine> i just open the bugs page for each of the projects
[17:17] <kenvandine> which isn't very efficient
[17:18] <seb128> kenvandine, right, it's not ;-)
[17:18] <kenvandine> in fact it is down right painful :)
[17:18] <kenvandine> i would love a better way
[17:46] <pitti> seb128: not that I know of, sorry
[17:47] <didrocks> seb128: thanks for commenting, I was pretty sure the symptoms were the same but as I didn't deal with those bugs, I was unsure :)
[17:48] <seb128> didrocks, np
[17:48] <seb128> didrocks, bug #536801 btw if you want to confirm it
[17:49] <seb128> pitti, ok, thanks anyway
[17:50] <seb128> tedg, ^
[17:50] <seb128> tedg, I assigned it to you, let me know if you can't reproduce or need details
[17:51] <didrocks> seb128: done
[17:51] <tedg> seb128: Cool, thanks.
[17:51]  * tedg will have to install a couple more users :)
[17:51] <seb128> I've a testbox I can reboot for testing, ie the mini10
[17:51] <seb128> and I get the bug easily on it
[17:51] <seb128> didrocks, thanks
[17:59] <sanderqd> hi, I'm trying to publish a customized gnome-applets package but I'm not sure how to set up my bzr branches. specifically, I'm wondering how the patches in lp:~ubuntu-desktop/gnome-applets/ubuntu are developed - in a separate lp:gnome-applets fork?
[18:01] <seb128> hi sanderqd
[18:01] <seb128> the ubuntu-desktop one only has the debian dir
[18:01] <seb128> it's copy in the unpacked tarball
[18:01] <seb128> and we use that to build
[18:03] <sanderqd> seb128: ok, and you use that branch to version-control patches? there's also lp:ubuntu/gnome-applets which contains both the original source and debian/
[18:03] <seb128> right
[18:03] <seb128> lp:ubuntu/gnome-applets is an auto import of uploads
[18:04] <seb128> you can use that as well
[18:04] <sanderqd> ok, cool. thanks for clearing that up
[18:06] <seb128> cassidy, there?
[18:06] <seb128> sanderqd, you're welcome
[18:08] <vish> mpt: hi.. any idea what the icon name is for the software store categories icons?
[18:18] <mpt> vish, some of the icon names are directly in the "software-center.menu" file, others are called indirectly by <Directory> in that file
[18:19] <mpt> I don't remember where the <Directory> ones come from, but seb128 or mvo would know
[18:19] <seb128> gnome-menus
[18:20] <seb128> dpkg -L gnome-menus | grep directories
[18:20] <seb128> dpkg -L gnome-menus | grep directory
[18:20] <seb128> rather
[18:20] <mpt> thanks seb128
[18:20] <seb128> np
[18:20] <vish> thanks ..
[18:21] <vish> mpt: i think the first section in games is "arcade" seems to be mentioned as amusements > https://wiki.ubuntu.com/SoftwareCenter#Genre ,
[18:22]  * vish thought that all games were amusements :p
[18:23] <mpt> vish, that page mentions neither Arcade nor Amusements
[18:24] <vish> mpt: in genre , the first one i see is "Amusements" as a subsection of games..
[18:24] <mpt> vish, reload :-)
[18:24] <vish> hehe ;p
[18:31] <LaserJock> kenvandine: reading your changelog for latest empathy, do you know if there are any security implications for making a non-SSL protocol default?
[18:32] <kenvandine> not really... it isn't adding the account
[18:32] <kenvandine> the user still has to do that
[18:32] <kenvandine> it is just the first one in the list, based on popularity
[18:33] <kenvandine> and our theme of being social from the start
[18:33] <kenvandine> it isn't setting anything up that doesn't use SSL
[18:33] <LaserJock> how is that popularity assessed?
[18:34] <kenvandine> informal data from gtalk employees
[18:34] <kenvandine> they say facebook is the most popular means of chat now
[18:34] <kenvandine> informal though
[18:34] <LaserJock> I know it's not adding it, but it seems like encouraging people to use an insecure protocol, which doesn't sound all that great
[18:34] <LaserJock> ok
[18:34] <kenvandine> not really encouraging, it is something most people use already :)
[18:35] <LaserJock> but shouldn't ;-)
[18:35] <LaserJock> although I do so naughty me
[18:35] <kenvandine> we would just rather them do it in empathy than in a web browser
[18:35] <kenvandine> we all do :)
[18:35] <LaserJock> well
[18:35] <LaserJock> but a browser is potentially safer
[18:35] <kenvandine> potentially
[18:35] <LaserJock> exactly
[18:35] <kenvandine> but people shouldn't be sending sensitive data over chat anyway
[18:35] <LaserJock> it's not that
[18:35] <kenvandine> passwd and such though
[18:36] <LaserJock> it's the password is being sent unencripted
[18:36] <LaserJock> wow, I can't spell
[18:36] <LaserJock> but I guess if Facebook is doing that to millions every day what's another drop in the bucket?
[18:36] <kenvandine> hehe.. yeah
[18:36] <LaserJock> I just happened to be reading up on the Facebook SSL issue the other day
[18:36] <kenvandine> hopefully they will open it up with ssl
[18:37] <LaserJock> and it seemed slightly scary compared to most other services
[18:39] <pitti> good night everyone!
[18:40] <didrocks> have a good night pitti
[18:41] <chrisccoulson> good night pitti
[18:41] <seb128> 'night pitti
[18:43] <bryceh> pitti, regarding the earlier question about -intel; I went through the git changelog for 2.10 and found it's like 98% code deletion, with the other 2% being a handful of work on Xv and maybe one or two bug fixes which may or may not be relevant to us.
[18:48] <chrisccoulson> well, quiet evening for me tonight
[18:49] <chrisccoulson> no baby here!
[18:53] <seb128> chrisccoulson, oh, enjoy ;-)
[18:53] <seb128> chrisccoulson, did you find somebody to do babysitting so you can go out or something?
[18:54] <chrisccoulson> seb128 - my girlfriend has gone to stay with her sister for the evening
[18:54] <chrisccoulson> so, i've got the house to myself for a change!
[18:54] <seb128> I see ;-)
[18:54] <seb128> don't work too much!
[18:54] <kenvandine> ;-)
[18:54] <seb128> or if you do, hack on fun stuff ;-)
[18:55] <seb128> anyway time for dinner here
[18:55] <seb128> bbl
[18:55] <kenvandine> later seb128
[18:59] <sanderqd> is there a policy about attributing patch authors in packages like gnome-panel? i don't see many names in debian/changelog, neither in debian/patches/
[19:05]  * LaserJock needs to get more RAM for his netbook, chromium sucks it like a Dyson
[19:17] <seb128> sanderqd, we usually write "thank to ..." in the changelog entry
[19:20] <seb128> didrocks, btw, wanna do the gst-plugins-bad0.10 update tomorrow?
[19:20] <didrocks> seb128: sure :)
[19:20] <seb128> thanks
[19:20] <didrocks> you're welcome
[19:21] <seb128> enjoy your evening meanwhile
[19:21] <didrocks> thanks, you too :-)
[19:21] <seb128> I'm pinging in the evening because you are an earlier starter than me in the morning :p
[19:21] <seb128> see you later!
[19:22] <seb128> bbl
[19:57] <kenvandine> tedg, i just uploaded evolution with the fix that should get the Shortcut Group names translated
[20:01] <seb128> re
[20:02] <seb128> kenvandine, tedg: speaking of which you groups name are buggy, they should start by X-Canonical
[20:02] <seb128> or X-Ubuntu
[20:02] <kenvandine> tedg, ^^
[20:02] <kenvandine> tedg, was there reasoning for using Ayatana?
[20:02] <kenvandine> i would think X-Ubuntu
[20:04] <seb128> kenvandine, oh, ayatana is fine too
[20:04] <seb128> [Compose Shortcut Group]
[20:04] <seb128> that one has no X- though
[20:04] <seb128> neither does
[20:04] <seb128> [Contacts Shortcut Group]
[20:05] <kenvandine> neither does [Desktop Entry]
[20:05] <kenvandine> :)
[20:05] <seb128> Desktop Entry is speced
[20:05] <seb128> X- are for things which are not in specs
[20:05]  * kenvandine hopes this is proposed at least
[20:05] <seb128> ie Comment= is official
[20:05] <kenvandine> yeah
[20:07] <tedg> seb128: I figured that since the names of the groups were defined by the entries anyway, it seemed a little redundant to have a field that was X-Ayatana then refer to groups that were X-Ayatana...
[20:08] <seb128> tedg, desktop-file-validate complains about those not respecting the spec though
[20:08] <seb128> and I just read the spec it's clear than non official groups should use X-...
[20:08] <tedg> I have no issue changing it, just seemed wordy.
[20:13] <seb128> tedg, bug #452659 is weird
[20:14] <seb128> tedg, the combo boxes in pidgin and empathy and the indicator are in sync but the buddy list status is wrong in both pidgin and empathy
[20:14] <seb128> tedg, do you think it could be a bug in both softwares?
[20:14] <seb128> I'm not sure to understand the issue
[20:16] <tedg> seb128: I'm guessing what is happening is the telepathy status negotiation.
[20:16] <tedg> seb128: So basically every telepathy client has a set of statuses it can represent.
[20:16] <tedg> seb128: And when you try to set it, it figures out which one is "most available" if it can't set that one.
[20:17] <tedg> seb128: So if you set invisible, and it doesn't support that, it'll go to Away.
[20:17] <tedg> seb128: But, *only* on that protocol, not all.
[20:17] <tedg> seb128: You end up with this crazy indeterminate state.
[20:17] <seb128> tedg, that sort of makes sense, I've asked detail on the protocol being used
[20:18] <tedg> I'm really not certain what we should/could be doing there.
[20:19] <seb128> well to me it seems the indicator is not buggy
[20:19] <seb128> since the pidgin or empathy combo stays in the same state
[20:28] <baptistemm_> hey bfiller
[20:28] <baptistemm_> I was thinking about you
[20:28] <bfiller> baptistemm: hey
[20:29] <baptistemm_> bfiller, Could you comment on upstream bug in Bug #369522
[20:29] <baptistemm_> actually I never saw you here but today :)
[20:30] <bfiller> baptistemm: I will get to that today
[20:30] <bfiller> baptistemm: I'm usually on this channel :)
[20:30] <baptistemm_> so the upstream bug is https://bugzilla.gnome.org/show_bug.cgi?id=610316
[20:31] <baptistemm_> and I updated the patch to the latest git there
[20:31] <bfiller> ok
[20:32] <baptistemm_> actually I really happy you looked at this code, as I wrote it :)
[20:44] <sanderqd> mclasen: hi, i'm trying to apply http://cvs.fedoraproject.org/viewvc/devel/gnome-panel/icon-padding.patch?revision=1.1&view=markup in ubuntu, but after restarting gnome-panel the padding setting doesn't seem to have any effect. any idea about what i could do?
[20:59] <mclasen> sanderqd: first thing I would check is if the panel is actually looking for the gconf key you set
[20:59] <sanderqd> mclasen: sounds good, is there a nice way to check that?
[21:01] <mclasen> add some debug spew ?
[21:32] <TheMuso> Good morning.
[21:33] <RAOF> Good morning.
[21:36] <seb128> RAOF, hi, how are you?
[21:36] <RAOF> Hi seb128!  I'm all excited to see what fun new bugs my call for nouveau testing has russled up.
[21:37] <seb128> RAOF, nice ;-)
[21:37] <didrocks> hey RAOF
[21:37]  * seb128 has no nvidia hardware
[21:37] <rickspencer3> wow, quite the flood of Fix Released for pitivi
[21:37] <didrocks> time to go for me, I was telling to have an early evening :)
[21:38] <rickspencer3> bye bye didrocks
[21:38] <RAOF> didrocks: Hey!
[21:38] <rickspencer3> take it easy!
[21:38] <didrocks> bye rickspencer3 :)
[21:38] <seb128> didrocks, 'night
[21:38] <RAOF> didrocks: Have a good evening :)
[21:38] <seb128> rickspencer3, yeah, I got the new version in and cleaned the buglist a bit
[21:38] <rickspencer3> didrocks, you totally deserve a nice evening out!
[21:38] <didrocks> thanks everyone, have a good day/evening/night :)
[21:38] <RAOF> Also, virt-manager looks shiny and new and will hopefully build me an armel VM that I can run gdb in to fix the gjs FTBFS.
[21:41] <fagan> RAOF: hmmm I have nvidia hardware and im lucid how do I test it
[21:41] <fagan> Is it the default driver or is it still -nv
[21:41] <RAOF> It's the default driver.
[21:41] <fagan> Oh then im using it then :)
[21:41] <RAOF> :)
[21:41] <RAOF> And obviously haven't been having a bad time of it :)
[21:42] <fagan> RAOF: Well my laptop is running a lot hotter than with the nvidia driver
[21:43] <RAOF> Yeah, power management is not yet implemented :/
[21:43] <fagan> But at least it has kms
[21:43] <RAOF> Yup.
[21:43]  * fagan loves the boot graphic thingy 
[21:47] <RAOF> It's really nice.
[21:49]  * TheMuso is willing to not have KMS for better power management.
[21:50] <RAOF> Yeah, that's a worthwhile tradeoff.
[21:50]  * fagan is shallow then :)
[21:57] <chrisccoulson> bug 520589 is really bothering me
[22:01] <seb128> chrisccoulson, I doubt it's a nm-applet bug
[22:02] <seb128> chrisccoulson, I got it once some days ago
[22:02] <seb128> the notification area was not displayed at all until gnome-panel restart
[22:04] <rickspencer3> RAOF, I'm dist-upgrading so I can try out your f-spot patches!
[22:04] <RAOF> rickspencer3: :)
[22:04]  * rickspencer3 waits for new kernel to install
[22:10] <chrisccoulson> seb128 - yeah, i keep getting it occasionally too, but it's quite difficult to debug
[22:10] <chrisccoulson> i'm fairly sure it's probably the same as bug 439448
[22:14] <seb128> could be yes
[22:14] <seb128> that one is annoying too
[22:28] <rickspencer3> TheMuso, my issue was that I had removed the indicator applet from that user :)
[22:28] <TheMuso> rickspencer3: heh ok.
[22:28] <rickspencer3> Nafai hi
[22:39] <crimsun> seb128: the pulse volume/balance issue is not reproducible in current Mandriva dev but is reproducible in F13
[22:39] <crimsun> seb128: I have a couple other bugs to squash, but I'll dig into it
[22:42] <seb128> crimsun, thanks
[22:52] <LaserJock> man I hate it when websites give podcast URLs only in iTunes
[22:58] <nekohayo> seb128, oh f*ck me... http://ecchi.ca:8000/1.png :)
[22:58] <nekohayo> stealth launchpad bugs attack!
[22:59] <nekohayo> ah whew, they're not all "private bugs being made public", a bunch of them are fix released, thank you :)
[23:00] <seb128> nekohayo, lol
[23:00] <seb128> you're welcome
[23:00] <nekohayo> so I'm assuming 0.13.4 is packaged in lucid now
[23:01] <seb128> yes
[23:02] <nekohayo> \o/
[23:04] <nekohayo> any reason why 533062 and 533812 were made public but not also set to "check if it still happens with 0.13.4" ?
[23:10] <seb128> nekohayo, no, I probably overlooked some bugs while going through the list
[23:10] <seb128> nekohayo, doing several things at the same time
[23:39] <nekohayo> yeah I can imagine :) I wonder how you manage to keep your sanity with so much bugs