[00:13] <chrisccoulson> good morning / evening everyone
[00:15] <bryceh> heya
[00:16] <chrisccoulson> hey bryceh, how are you?
[00:17] <bryceh> chrisccoulson, peachy
[00:17] <chrisccoulson> good :)
[00:17] <bryceh> chrisccoulson, hacking on gtg code this sunday afternoon :-)
[00:18] <chrisccoulson> cool! gtg looks quite interesting
[00:20] <bryceh> yeah, there is a major new refactoring which really speeds it up a lot for large numbers of tasks
[00:21] <bryceh> I've been testing and reporting bugs on it, sounds like it'll go in pretty soon
[00:22] <chrisccoulson> i've just installed it to try it out :)
[00:22] <chrisccoulson> ooh, it integrates with hamster
[00:23] <bryceh> chrisccoulson, there's a plugin I made to import our blueprint workitems ('import_json').  But by now you probably have no remaining wi's :-)
[00:23] <chrisccoulson> i don't think i had too many to start with ;)
[00:25] <RAOF> Has the couchdb backend for gtg gone in yet?
[00:26] <bryceh> RAOF, not yet, the aforementioned refactoring is a pre-requisite to that
[00:27] <RAOF> Ok.  I'll stay with lucid's packaged version for now then.
[00:27] <bryceh> the devs are going to start work on backend development once this is merged in, and I think couchdb is at the top of the list for backends
[00:31] <RAOF> Bah.  I incautiously hit enter in a terminal and triggered that annoying plymouth bug :/
[00:32] <chrisccoulson> i just ended up uninstalling plymouth
[00:32] <chrisccoulson> because of that ;)
[00:33] <RAOF> I like to keep a certain amount of friction installed, so it doesn't get lost.  Also, it's hard to test seamless plymouth->X transitions without having plymouth installed :)
[00:33] <chrisccoulson> yeah, that's true
[00:33] <chrisccoulson> unfortunately, it makes my laptop virtually unusable, and i still need to able to get some things done with it
[00:34] <RAOF> It only happens once per boot for me, which is not so annoying that I need to uninstall plymouth.
[00:34] <chrisccoulson> does anyone understand what causes it?
[00:35] <chrisccoulson> because i noticed that all my keyboard input is routed to the VT that X is running on when i have plymouth installed
[00:35] <RAOF> Sarvatt has a theory about plymouth fiddling with the VT flags and not unfiddling with them, so that the enter key ends up sending X SIGQUIT.
[00:43] <TheMuso> IMO we really shouldn't have switched to plymouth for lucid.
[00:44] <Sarvatt> +1 :)
[00:47] <Sarvatt> the quit signal is definitely getting sent from the tty layer - http://paste.ubuntu.com/382615/ other distros are getting around it by having plymouth running on another VT
[00:48] <Sarvatt> RAOF: that plymouth where I made it stop setting ISIG on the VT didn't work I take it?
[00:48] <RAOF> Sarvatt: No, that didn't fix it.
[00:57] <arand> Hmm, that wiki (https://wiki.ubuntu.com/DesktopTeam/Lucid/FeaturedApps) is becoming a bit cloggy, I did some categorising (&adding) but I don't know..
[01:12] <bryceh> hey, while I was eating a sandwich, gtg 0.2.2 was released
[01:12] <bryceh> do we need FFe's for packages in universe?
[01:12] <Tm_T> bryceh: you should eat sandwiches more often
[01:13] <RAOF> bryceh: Yes, but only if they're feature releases - if 0.2.2 is a bugfix only, you just need to document it in a bug and upload.
[01:13] <bryceh> it was a good sandwich
[01:14] <bryceh> RAOF, it's mostly bugfix but has several features added (including the import_json plugin)
[01:14] <bryceh> and libindicator
[01:14] <RAOF> Oh, sweet.
[01:15] <RAOF> Well that should have (and should get) an FFe.
[01:29] <bryceh> gtg ffe: https://bugs.edge.launchpad.net/ubuntu/+source/gtg/+bug/529789
[07:14] <didrocks> good morning
[07:14] <RAOF> didrocks: Good morning!
[07:14] <didrocks> hey RAOF ;)
[07:14] <RAOF> Well, late afternoon :)
[07:14] <didrocks> heh, sure for you :)
[07:14] <RAOF> I am from the future!
[07:51] <pitti> Good morning
[07:52] <pitti> dpm: jaunty/karmic cronjobs disabled
[07:52] <didrocks> hey pitti, enjoying your long week-end? :)
[07:53] <dpm> heya pitti, good morning, welcome back and thanks for coming back to me on that :)
[07:55] <pitti> didrocks: it was great, thanks! how are you?
[07:55] <pitti> dpm: you're welcome
[07:55] <pitti> RAOF: welcome! how was your first day?
[07:56] <didrocks> pitti: lots of wind and bad weather. Consequently, stayed at home and rest ;)
[07:57] <RAOF> pitti: Pretty good.  I've got a plan to make nouveau rock by first getting inundated by bugs and then fixing them all like a madman.
[07:57] <pitti> wind> I noticed, our train connection took two hours longer than planned
[07:57] <pitti> RAOF: that sounds like a hercules project
[07:57] <RAOF> And the IS team should be getting in to work soon, so I should have access to the wiki any time now ;)
[07:59] <didrocks> pitti: but you finally arrived, that's what matter :) In France, there are a lot of damages (1 million homes without electricity yesterday, still 500 000 today)
[07:59] <pitti> didrocks: ouch
[08:00] <RAOF> Woah.  That must suck, particularly in winter!
[08:01] <didrocks> yeah :/
[08:05] <pitti> fortunately it just became sprint
[08:05] <pitti> spring
[08:05] <pitti> (which is also the reason for the storms to begin)
[08:12] <RAOF> Mmm, the smell of lasagne says “dinner time until London gets in to the office”!
[08:13] <chrisccoulson> good morning everyone
[08:14] <pitti> hey chrisccoulson, good morning
[08:14] <chrisccoulson> hey pitti - did you have a good weekend?
[08:14] <didrocks> hey chrisccoulson!
[08:14] <chrisccoulson> hey didrocks!
[08:15] <pitti> chrisccoulson: yes, it was wonderful; good mix of sightseeing, sauna, massage, nice dinner, and Claude Shannon museum
[08:18] <chrisccoulson> good stuff
[08:18] <chrisccoulson> was anybody affected by the storms this weekend?
[08:20] <pitti> took us two hours and two train changes more to get home, but nothing serious
[08:21] <didrocks> chrisccoulson: not really affected in Paris apart from the bad weather and some sign board no more in their usual place :) but some parts of France are heavily damaged
[08:21] <chrisccoulson> didrocks - yeah, i saw on the news over the weekend. it looks quite bad towards the west :(
[08:23] <chrisccoulson> pitti - i'm not sure if you saw my message yesterday (about gnome-user-share)
[08:23] <pitti> chrisccoulson: I did; on my list
[08:23] <chrisccoulson> excellent, thanks :)
[08:23] <pitti> chrisccoulson: I'm going to reinstall the mini with the current daily first
[08:23] <pitti> usb-creator is grinding
[08:26] <dpm> pitti, I've got a couple of questions re bug 525726. Gwibber is not translatable in Launchpad (a template was never imported), although having built the package locally, it does seem to create a POT template on build. I'm not that familiar with the packaging, but could it be that it was promoted to main without having been rebuilt? If so, can I request anyone from the desktop team to re-upload the package? (I cannot currently upload a template manuall
[08:26] <dpm> y unless there hasn't been a template imported first)
[08:37] <pitti> dpm: that's plausible, let me check
[08:38] <pitti> dpm: https://edge.launchpad.net/ubuntu/+source/gwibber/+changelog confirms this
[08:38] <pitti> dpm: I'll do a no-change upload now
[08:39] <TheMuso> Good morning European folk. :)
[08:39] <pitti> TheMuso: good morning!
[08:40] <TheMuso> s/morning/evening/ :p
[08:40] <nigelb> TheMuso: you've been closing a rhythmbox bug or two?
[08:40] <dpm> pitti, many thanks. Just so I know for future cases, which is the entry in the changelog that confirms this?
[08:40] <pitti> dpm: done
[08:40] <chrisccoulson> good morning TheMuso
[08:40] <TheMuso> nigelb: Only stuff that also has a pulseaudio task.
[08:40] <chrisccoulson> hey seb128
[08:40] <pitti> dpm: oh, that's a bit "encoded"; the same version is both superseded and published in lucid
[08:40] <nigelb> TheMuso: ah :) I got a few mails.  Since they were closed, I left them alone :)
[08:40] <pitti> dpm: which means that its component was moved
[08:41] <pitti> dpm: and I just happen to know that it moved from universe to main
[08:41] <pitti> seb128: bonjour Monsieur!
[08:42] <seb128> hey chrisccoulson pitti
[08:43] <seb128> chrisccoulson, pitti: did you have a good weekend?
[08:43] <chrisccoulson> seb128 - yeah, not too bad thanks, although i have a bit of a cold
[08:43] <dpm> pitti, thanks a lot!
[08:43] <chrisccoulson> how was your weekend?
[08:43] <seb128> chrisccoulson, oh :-(
[08:43] <seb128> pretty good
[08:44] <seb128> we got quite some wind yesterday though
[08:44]  * TheMuso hopes everyone survived the storms unscathed.
[08:45] <seb128> we got some small power cuts but otherwise everybody and everything is ok there
[08:45] <seb128> did anybody got news from pedro btw?
[08:46] <pitti> seb128: yes, it was wonderful; we spent it in Paderborn, some sightseeing, wellness, massage, nice dinners, and Claude Shannon museum
[08:46] <pitti> seb128: just had some train delays getting back, but under the weather circumstances it was okay
[08:46] <pitti> seb128: didn't hear from Pedro in a while
[08:46] <seb128> just read my emails got on from dholbach
[08:47] <seb128> "Pedro and his family
[08:47] <seb128>         are perfectly fine, but currently without an internet connection"
[08:47] <seb128> pitti, seems a very nice weekend indeed ;-)
[08:48] <didrocks> hey seb128
[08:49] <seb128> lut didrocks
[08:51] <nigelb> hey aquarius, you pinged me on identi.ca I believe :)
[08:52] <aquarius> nigelb, I did! Mainly to say: if there's anything that you want to know about the Ubuntu One music store that would make your bug adoption of Rhythmbox easier, just say the word :)
[08:52] <nigelb> aquarius: so far, nothing has popped up related to store, but when it does I'd love to know how I can help you guys out
[08:53] <nigelb> I do remember that I can reassign the package when it has something to do with the store
[08:53] <nigelb> speaking of which, seb128: upstream has come up with a new rhythmbox release :)
[08:54] <didrocks> waow, the debian GNOME week-end has created a lot of email traffic
[08:54] <seb128> nigelb, thanks, we have a few days snapshot will update later
[08:54] <seb128> didrocks, they triaged lot of bugs?
[08:54] <nigelb> okay :)
[08:54] <seb128> didrocks, you are subscribed to debian bugs too?
[08:55] <didrocks> seb128: yes, I'm subscribed and yes, they planed to make some kind of "hug day" for GNOME in debian
[08:55] <chrisccoulson> did anyone here get involved with that at the weekend?
[08:55] <seb128> didrocks, I've read the blog post
[08:55] <seb128> I didn't
[08:55] <aquarius> nigelb, well, when it does (I'd love to say "if" it does, but I'll go with "when"), you know where I am!
[08:55] <seb128> I try to not work during weekends and I would do I would rather triager our bugs
[08:55] <chrisccoulson> i tried triaging some ubuntu bugs at the weekend ;)
[08:56] <nigelb> aquarius: yes :) Great to touch base with you :)
[08:57] <seb128> chrisccoulson, :-)
[08:59] <seb128> didrocks, how many emails did you get from their triaging?
[08:59] <didrocks> seb128: I didn't count, but more than 300 emails
[09:00] <chrisccoulson> i bet seb128 can beat that this morning ;)
[09:00] <seb128> that's something I guess
[09:00] <seb128> chrisccoulson, I got 500 ubuntu ones waiting there
[09:00] <seb128> which is a pretty normal weekend count
[09:32] <seb128> pitti, I'm working updating rhythmbox to 0.12.7 now btw, do you want me to batch any other change?
[09:32] <pitti> seb128: I just sponsored Jan's patch
[09:32] <seb128> oh ok
[09:32] <pitti> seb128: I don't have anything else
[09:32] <seb128> I will do another update
[09:32] <seb128> gnagnagna
[09:32] <seb128> I hate bzr
[09:32] <pitti> seb128: next time I'll ping you before
[09:32] <pitti> seb128: what's wrong?
[09:33] <seb128> pitti, no need to ping me sorry about that
[09:33] <seb128> pitti, format changed or something it refuses to pull
[09:33] <seb128> I keep running into those issues
[09:33] <pitti> seb128: "bzr info" -> which format does it show you?
[09:33] <seb128> too late I tried a bzr upgrade
[09:33] <seb128> which seemed to have worked
[09:33] <seb128> I just don't get why it was working a few days ago
[09:34] <seb128> and breaks out of the blue
[09:34] <seb128> let's see if I still manage to push later
[09:34] <didrocks> I saw that some new branches have been updated to the new format recently
[09:35] <seb128> didrocks, that happens in an automatic way?!
[09:35] <pitti> could have been me
[09:35] <pitti> but I don't remember any more
[09:35] <pitti> I upgraded one branch recently, to do a merge with a proposed 2.0 branch
[09:35] <seb128> bzr should be smarter about that and do what is needed
[09:36] <didrocks> seb128: when pushing you see "updating to new format", or some cron on LP side, I guess
[09:36] <RAOF> I think we should probably make it policy that all bzr branches are in 2a format.
[09:36] <seb128> rather than return weird errors
[09:36] <pitti> and over time, all those should eventuyally be 2.0
[09:36] <didrocks> seb128: +1
[09:36] <seb128> hey RAOF, how was your first day? ;-)
[09:36] <RAOF> Wet.
[09:36] <seb128> is that good? ;-)
[09:37] <TheMuso> seb128: We had an almost wintery day in Sydney.
[09:37] <seb128> oh
[09:37] <RAOF> It was marvelously cool and damp.  I fixed a bunch of nouveau-related stuff, got an action plan to make it awesome, and will shortly be getting access to the wiki!
[09:37] <seb128> ;-)
[09:38] <TheMuso> RAOF: Speaking of which, I'm working on lbm ppc packages so we can get nouveau. Hitting a snag however.
[09:38] <seb128> RAOF, do you fancy to update gjs or resync on debian when you have some time btw?
[09:39] <RAOF> Certainly.  The diff got applied to the Debian package; I think it might now be a sync.
[09:40] <seb128> excellent
[09:41] <seb128> RAOF, we probably still need some replaces or did they take that too?
[09:42] <RAOF> Ah, yeah.  We probably need them.
[09:43] <RAOF> Oh, and I see the bzr package importer hasn't get grabbed the latest source from debian.
[09:46] <seb128> chrisccoulson, do we have a reference bug for bug #527904? is that a libindicator issue?
[09:47] <chrisccoulson> seb128 - thats a libindicator issue. tedg pushed a fix for it initially, but it doesn't work (and I found another issue with the fallback too)
[09:47] <chrisccoulson> i'll find the master
[09:48] <seb128> chrisccoulson, thanks
[09:48] <chrisccoulson> seb128 - bug 529052
[09:49] <seb128> chrisccoulson, thanks
[09:50] <chrisccoulson> the fallback really doesn't work very well. every time an application calls app_indicator_set_menu, it sets up a new fallback timer, which flips the status of the icon when it times out
[09:50] <chrisccoulson> which is causing the blinking icon that people are reporting in gpm
[09:50] <chrisccoulson> i'll ping tedg about that later though
[09:50] <seb128> thanks
[09:51] <seb128> so those people have issues because they don't use the indicator
[09:51] <seb128> I expect many of them don't know
[09:51] <chrisccoulson> seb128 - yeah, they're not using the indicator
[09:51] <seb128> or removed it because they didn't like the messaging menu
[09:51] <seb128> but not it's used for other things too
[09:52] <chrisccoulson> i've seen at least one person confused about having the messaging menu in the same applet as the other icons
[09:52] <chrisccoulson> but, that's not really any different to the old notification area really
[09:53] <chrisccoulson> seb128 - i've done g-c-c this morning btw
[09:53] <seb128> oh nice
[09:53] <seb128> need sponsoring?
[09:53] <chrisccoulson> seb128 - when you get some time :)
[09:53] <seb128> will do that soon
[09:56] <RAOF> Hah.  My enable-the-testsuite diff to gjs broke the build for kfreebsd.
[10:00] <RAOF> TheMuso: What was the lbm on PPC snag?
[10:02] <TheMuso> RAOF: something to do with powerpc64 headers and not being able to find a macro... Stilldigging.
[10:02] <RAOF> Ok.  Sing out if you want some (not-able-to-actually-do-a-PPC-build) help ;)
[10:02] <TheMuso> heh ok thanks
[10:04] <TheMuso> RAOF: and its the alsa drivers that is hitting the error.
[10:04] <RAOF> Superb.
[10:06] <TheMuso> yep
[10:15] <RAOF> seb128: Is gjs a part of the GNOME standing FFe?
[10:19] <seb128> RAOF, not sure but I'm usually allowed to grant universe desktop ffe
[10:19] <seb128> RAOF, so I'm granting this one
[10:20] <RAOF> Ok :)
[10:24] <RAOF> Hm.  A lot less of that diff actually got applied than I thought. :/
[10:29] <RAOF> We really are going to have to ensure that gnome-shell works with libseed for lucid+1.
[10:34] <seb128> bug #525520
[10:34] <seb128> I didn't though users were running this capplet
[10:34] <seb128> but we got quite some duplicates now
[10:41] <chrisccoulson> yeah, it doesn't work at all now
[10:41] <chrisccoulson> not sure when that broke
[10:49] <nigelb> seb128: now that the new release is in, do you want a debdiff for the hook?
[10:49] <seb128> nigelb, no that's ok, let me review that one before
[10:49] <seb128> it's on my todolist
[10:50] <nigelb> seb128: ah, sorry.  thought you wanted me to get something done :)
[10:50] <seb128> well you did update it but I didn't have time to review that yet
[10:50] <chrisccoulson> hey MacSlow - when adding a new synchronous notification, what can I set the "x-canonical-private-synchronous" hint too (or can I set it to anything I like)?
[10:50] <chrisccoulson> gsd has a new notification for touchpad on/off
[10:51] <nigelb> ah :)
[11:01] <TeTeT> asac: any update on the modem manager blacklisting patch? Did it ever make it?
[11:11] <RAOF> Ok.  I'm going to finish that merge tomorrow morning.
[11:14] <seb128> RAOF, no hurry
[11:24] <MacSlow> chrisccoulson, e.g. 1
[11:46] <chrisccoulson> seb128 - gsd is done now
[11:49] <seb128> chrisccoulson, good, I'm away for lunch now
[11:49] <seb128> but will sponsor after lunch
[11:50] <chrisccoulson> thanks
[12:01] <chrisccoulson> tseliot, the newest version of gsd has support for disabling the touchpad now. did you do any work on adding a check-box to the mouse properties UI, or do you want me to do this?
[12:01] <chrisccoulson> (i can't remember if you said you were going to do that or not)
[12:02] <tseliot> chrisccoulson: I promised seb128 that, if no one had implemented that before alpha 3, I would have worked on it. But I really need to implement support for 16 colours in plymouth first :-/
[12:03] <seb128> well we have a gconf key now
[12:03] <seb128> and a hotkey
[12:03] <seb128> so it's less of an issue
[12:03] <seb128> easy to tweak
[12:03] <chrisccoulson> seb128 - yeah. my laptop doesn't seem to have a touchpad hotkey though
[12:03] <tseliot> chrisccoulson: I'd be glad if you could do this. I'm available to answer your questions on it if you have doubts
[12:03]  * tseliot is chocking with work
[12:04] <tseliot> choking
[12:23] <chrisccoulson> right, i'm going to grab some lunch
[12:24] <seb128> chrisccoulson, enjoy
[12:30] <rickspencer3> good morning chrisccoulson
[12:31] <chrisccoulson> hey rickspencer3, how are you?
[12:31] <rickspencer3> chrisccoulson, I am quite fine
[12:31] <rickspencer3> I am working from Florida this week, gets me a bit closer to your time zone
[12:31] <pitti> hey rickspencer3
[12:31] <rickspencer3> chrisccoulson, today is your first day, right?
[12:32] <chrisccoulson> rickspencer3, yeah, i started this morning :)
[12:32] <seb128> hey rickspencer3
[12:32] <rickspencer3> hi pitti and seb128!
[12:33] <didrocks> hey rickspencer3
[12:33] <rickspencer3> hi didrocks
[12:33] <rickspencer3> has everyone adjusted to our new "Chris" rich team already?
[12:34] <chrisccoulson> lol
[12:34] <chrisccoulson> i think everybody should change their names to chris ;)
[12:34] <chrisccoulson> just to make it more confusing
[12:35] <rickspencer3> :)
[12:35] <pitti> CC, CC, and CR? nice
[12:35] <chrisccoulson> heh
[12:35] <chrisccoulson> well, CCC for me ;)
[12:35] <chrisccoulson> C^3
[12:36] <bratsche> rickspencer3: What are you doing in FL?
[12:36] <rickspencer3> bratsche, I'm working from my parent's house for a week
[12:36] <bratsche> Cool
[12:36] <rickspencer3> need to make sure they are ok at least once per year :)
[12:51] <seb128> rickspencer3, not sure if you have seen but robert_ancell did great work on the feature apps selection
[12:52] <rickspencer3> seb128, I saw
[12:52] <rickspencer3> we talked a bit my yesterday evening, his this morning
[12:52] <rickspencer3> basically, it is "Robert's Featured Apps" now :)
[12:53] <rickspencer3> because he did all the work organizing the community input and reviewing the apps and such
[12:55] <seb128> rickspencer3, he didn't list quickly though
[12:57] <didrocks> even though quickly is in software center! that's a shame ;)
[12:58] <didrocks> mvo: thanks for putting it in s-c, I didn't notice before ;)
[12:59] <mvo> seb128: where/in what branch is his work
[12:59] <mvo> didrocks: got pulled in automatically :)
[12:59]  * mvo pats his update script(s)
[12:59] <didrocks> mvo: sweet, even if we don't have any .desktop file? How can we add the icon, btw?
[12:59] <seb128> mvo, none that I know, he emailed ubuntu-desktop-list
[13:00] <seb128> mvo, with the list of apps he reviewed and picked too
[13:00] <mvo> seb128: aha, I should read more mail
[13:00]  * mvo looks
[13:01] <mvo> didrocks: AFAICS its the package that s-c has. lucid does normal packages now as well
[13:01] <mvo> stellarium
[13:01]  * mvo likes the choice(s) of robert
[13:03]  * didrocks reforwards his email as the list isn't setup to reply to the ML automatically
[13:10] <rickspencer3> I just read robert_ancell's review in detail
[13:10] <rickspencer3> I don't see there is too much more to discuss :)
[13:10] <rickspencer3> though I think perhaps including an IDE is not necessary
[13:11] <rickspencer3> and maybe one or two more games if there are good ones
[13:11] <didrocks> yeah, his default list is great for the most part. I've just included some little discussion on some points, but nothing really important
[13:12] <rickspencer3> meh, looks like he looked at other game and rejected them for good reasons
[13:13]  * mvo adds the list to s-c
[13:16] <seb128> mvo, rock on!
[13:19] <seb128> didrocks, how bug #530024 is a gsd bug?
[13:19] <seb128> if gsd is not running...
[13:19] <didrocks> seb128: I'll had the script to gsd package (just pushed)
[13:19] <didrocks> as previously planned
[13:19] <seb128> hum no?
[13:20] <didrocks> I need to open the bug to casper as well, I'm testing the script
[13:20] <didrocks> no? we talk about adding gnome-update-wallpaper-cache to gsd, no?
[13:20] <seb128> when, where?
[13:21] <didrocks> I can show you the log, one week and half ago, when we discussed about the postinst stuff to cache on upgrade
[13:21] <seb128> I'm still not convinced it should be in gsd
[13:22] <didrocks> just tell me where to put it, I don't care, but not changing it once more :/
[13:22] <seb128> right and I though we dropped the postinst thing?
[13:22] <seb128> let me think
[13:22] <didrocks> seb128: right, but on ubiquity "install mode", we will still install it
[13:22] <seb128> I don't like much adding random binaries to g-s-d which have nothing to do with gsd
[13:23] <didrocks> I understand, just tell me where, I'm a little bored about this change already…
[13:23] <seb128> ubiquity?
[13:23] <seb128> since that's for ubiquity...
[13:24] <didrocks> seb128: the script that will call it is in casper btw
[13:24] <seb128> so casper?
[13:24] <didrocks> I don't care, just tell me so that I don't have to change it once more :)
[13:24] <didrocks> pitti: agree too ^
[13:24] <seb128> I don't know
[13:24] <seb128> I've no real opinion on it, I just would like it better if it was not in gsd
[13:25] <seb128> it has nothing to do there
[13:25]  * didrocks waits until their is an agreement on this, just spent too much time on this and testing all went ok…
[13:26] <didrocks> I still add the casper task for now
[13:28] <pitti> didrocks, seb128: hm, I don't see a big problem with shipping a new binary in /usr/lib/ in the g-s-d package, but if you prefer it to live in gnome-about (as a gnome-desktop binary), that's fine for me as well
[13:28] <seb128> pitti, I would prefer it to be in casper if that's what need that$
[13:28] <pitti> casper is arch:all
[13:29] <pitti> can't
[13:29] <seb128> could use python-gnomedesktop ;-)
[13:29] <pitti> WFM
[13:29] <seb128> gnome-about is arch all too
[13:29] <didrocks> so, I have to rewrite it in python? :/
[13:29] <seb128> bah, that change sucks
[13:30] <pitti> seb128: why? it's just a new 5-line .c file in debian/rules?
[13:30] <seb128> I guess having a casper depends on python-gnomedesktop will not be people happy easier
[13:30] <seb128> pitti, because we are arguing and working on that for weeks now
[13:30] <seb128> that seems lot of trouble for a detail
[13:31] <seb128> I'm near of thinking it should be a new source package
[13:36] <seb128> didrocks, don't bother rewritting the thing again
[13:37] <didrocks> which means? do I push my changes, do I move the .c file into another package? (It took me some hours again to test that today)
[13:37] <seb128> I'm pondering between the "screw it and use gsd we discussed that too much now" even if that's the wrong component for it and I don't like having delta there
[13:37] <seb128> and "do a new source package for it"
[13:38] <seb128> didrocks, not sure why it should take some hours to test, you just need the binary to be installed
[13:38] <seb128> whatever package install it should make no difference
[13:38] <seb128> as long as it's in the location you use
[13:38] <didrocks> seb128: because I tried with the package change to install ubiquity again in live mode, in install mode, etc.
[13:38] <didrocks> to ensure I don't break the install
[13:39] <seb128> if it moves source I don't see a reason to do that testing again
[13:39] <seb128> there is no reason it should break
[13:39] <seb128> anyway let me think a bit between the 2 options I just gave
[13:39] <didrocks> seb128: no sure, but if we screw it, it's just loss, that's why I just want to know what we do about it
[13:40] <pitti> seb128: I don't think we'll get rid of our Ubuntu delta in g-s-d soon, and once we do, we can still move it somewhere else, FWIW
[13:41] <seb128> pitti, yeah I don't think either, still it seems wrong to add that in gsd since that has nothing to do with gsb
[13:41] <seb128> gsd
[13:42] <seb128> seems we are just picking a random abitraty component and add stuff we don't where to put in
[13:42] <seb128> I can see cases where g-s-d is not installed or used but gnome-desktop used and the command could be useful
[13:46] <pitti> oh, hang on
[13:46] <pitti> casper is arch:any
[13:46] <pitti> and already has a .c file
[13:47] <pitti> so, we could actually put it there
[13:47] <pitti> seb128, didrocks: ^ sorry, seems I was misled
[13:47] <didrocks> no pb, moving it right now so :)
[13:47]  * pitti hugs didrocks
[13:47]  * didrocks hugs pitti
[13:48]  * seb128 hugs didrocks
[13:48] <didrocks> so, where should I put it on the FHS? somewhere away from /usr/bin (I was putting it in /usr/lib/gnome-settings-daemon/ before)?
[13:48]  * didrocks hugs seb128 back and hope we can finish one day with caching ;)
[13:49] <seb128> ;-)
[13:49] <pitti> didrocks: in casper it doesn't matter much
[13:49] <pitti> didrocks: casper-desktop-background-cache, or whatnot
[13:50] <didrocks> ok, as it's only installed on live, that makes sense :)
[13:55] <didrocks> hum, that will make casper build on gnome-desktop and glib btw, isn't it an issue for derivatives not using GNOME?
[13:56] <seb128> didrocks, check with cjwatson?
[13:57] <chrisccoulson> hmm, i've just noticed from the gpm changelog:
[13:57] <chrisccoulson> "Set the timeout for critical battery notification to never"
[13:57] <chrisccoulson> that's not going to work with notify-osd is it?
[13:58] <seb128> MacSlow|lunch, ^
[14:05] <seb128> hey tedg
[14:05] <tedg> Good morning seb128
[14:08] <MacSlow> seb128, correct... apps cannot directly control a notifications-timeout with notify-osd
[14:08] <seb128> MacSlow, what happens when they try?
[14:10] <chrisccoulson> seb128 - the fallback dialog appears
[14:10] <seb128> ah I see
[14:11] <chrisccoulson> so, i'm wondering whether to just revert the change, or if we need to discuss that first
[14:12] <seb128> when is that bubble displayed?
[14:12] <chrisccoulson> when the battery is critically low
[14:13] <MacSlow> seb128, the fallback-dialog should show up
[14:14] <seb128> chrisccoulson, will that trigger gpm suspend soon?
[14:14] <chrisccoulson> seb128 - yeah, it should do
[14:16] <seb128> I would say just revert the change
[14:16] <seb128> it's going to suspend anyway
[14:16] <chrisccoulson> yeah, it seems easiest
[14:41] <seb128> tedg, bug #506947
[14:41] <seb128> tedg, it might be an easy to fix bug you want to look at before string freeze
[14:42] <tedg> seb128: Yes, apparently we're changing the wording on all of those last minute :-/
[14:43] <seb128> when?
[14:44] <tedg> seb128: I think right now.  I need to confirm it.
[14:44] <tedg> seb128: I found out on Thursday, but with the UX thingy, I wasn't able to get a clean answer.
[14:45] <seb128> tedg, please get strings changes in this week tarballs if you can
[14:45] <seb128> thanks
[14:45] <tedg> seb128: Will do.
[14:45] <seb128> good ;-)
[14:59] <vish> tedg: i thought mpt wanted to rename it to "Switch Off"
[14:59] <tedg> vish: Yeah, I think that's it.  And I believe that suspend is changing to sleep.
[15:00] <vish> yeah..
[15:11] <vish> mat_t: djsiegel1  Bug #530041 is a dup of Bug #460144 , which MacSlow mentioned is not supposed to use the replace hint as done by the volume/brightness notifications
[15:26] <jcastro> pitti: do you think vino is going to be a problem wrt. app indicators?
[15:29] <pitti> jcastro: that 80 KB patch?
[15:29] <jcastro> yeah
[15:29] <pitti> well, such patches aren't something we take with much joy, to be honest
[15:29] <jcastro> can you join #ayatana?
[15:29] <pitti> we have a policy to always forward patches upstream first, and of course also get them accepted at some point
[15:29] <pitti> but of course we have to make some concessions here
[15:30] <pitti> jcastro: so I expect we'll test and apply it, but will probably have to drop it again in the next update, when it doesn't apply any more
[15:30] <jcastro> pitti: ok I think seb and jpetersen figured it out
[15:31] <jcastro> pitti: after this it's just brasero left to do!
[15:31] <jcastro> (and it should be ready for you guys today)
[15:32] <seb128> jcastro, hum, no, we have been discussed gsd
[15:32] <seb128> ie the keyboard layout thing
[15:32] <seb128> not vino
[15:33] <pitti> my real preference would be to have five patched apps, as a "proof of concept", and then get indicators blessed upstream, so that we can upstream the patches (and also make them much simpler by dropping the non-indicator portions)
[15:33] <pitti> but I realize we can't have that :)
[15:34] <mdeslaur> tedg: so, when a python application uses "insert" to add stuff to an application indicator gtkmenu, it doesn't get updated. I've been looking for a fix/workaround, but so far I've only found doing another "set_menu"...which is time intensive...any ideas?
[15:34] <pitti> so we need to carry them for a while; but I don't think we can take over responsibility for 20 of them
[15:34] <jcastro> seb128: ugh, of course, I got mixed up
[15:34] <pitti> we have enough to do with fixing up the ones that we already applied
[15:34] <pitti> and they are a huge time sink when doing package updates
[15:34] <pitti> since they keep breakign
[15:35] <seb128> pitti, we don't have so many and some already went upstream (not for GNOME though)
[15:35] <tedg> mdeslaur: No, no clue.  Are you using a 0.14 of indicator-application?  We fixed some bugs related to that.
[15:35] <mdeslaur> tedg: yes, 0.14
[15:36] <jcastro> pitti: jpetersen and nafai have been very responsive fixing the bugs as they came in
[15:36] <tedg> mdeslaur: Hmm.  I'm pretty sure it works in C... just port the whole app ;)
[15:36] <jcastro> pitti: and after the first few hard bugs fixed in indicator-application it's not so bad now
[15:36] <pitti> jcastro: agreed
[15:36] <mdeslaur> tedg: yeah, port from python to C, always a good idea :)
[15:36] <tedg> mdeslaur: Can you make a quick test case?
[15:37] <jcastro> pitti: g-s-d, vino, and brasero are the last three left for our goal for lucid.
[15:37] <mdeslaur> tedg: sure, I'll make one and open a bug. Just wanted to know if it was something that was already known or not.
[15:37] <jcastro> whoops, I left out hplip too, which is having some problems but smithj is working on it
[15:37] <pitti> jcastro: there's also a patch for policykit-gnome
[15:37] <pitti> and hplip
[15:38] <pitti> I saw quite a few of those fly by
[15:40] <jcastro> pitti: do you have any insight on how to get these in better shape for you? I'd be a shame to have all their work not shipped in lucid.
[15:40] <jcastro> I have the contractors prioritized on a) lucid bugs as they come in for the app indicators, and then b) Getting the patches in shape for upstream
[15:49] <pitti> jcastro: not touching .glade files, changing strings, and fewer hunks (if at all possible) :)
[15:49] <pitti> so that they port better to newer upstream versions
[15:58] <mat_t> vish: it is not a dupe
[15:58] <mat_t> vish: MacSlow is not correct in this case
[16:01] <vish> mat_t: hmm , it is the same bug both bugs are about the notifications showing up at the wrong time or showing up late.., the sync notifications [which have replace hint] was supposed to be reserved for hardware feedback..  maybe the async should also have a replace function..  well mpt might know more..
[16:03] <mat_t> vish: mpt has asked me to file this bug
[16:04] <mat_t> vish: it should definitely use the replace hint
[16:04] <vish> mat_t: yup , i meant mpt might know more than me :)
[16:04] <mat_t> ;)
[16:19] <tgpraveen12> i see from the mailing list that it is proposed to not include gnucash in the featured application list as it is considered complex. but i really think it should be included as a
[16:20] <tgpraveen12> decent accounting package is very much needed. and gnucash is a very reliable and popular application. it is indeed one of the best accounting applications even when
[16:20] <tgpraveen12> compared to its proprietary competitors and as for it being complex i installed gnucash on my dad's machine for his accounting
[16:20] <tgpraveen12> work and he learnt it in no time and now absolutely loves the program. he was using ms money earlier
[16:21] <tgpraveen12> though i must also say that my dad is a professional account, but he is by no means a computer expert
[16:21] <tgpraveen12> and even he got hang of gnucash in no time.
[16:21] <hyperair> tgpraveen12: it might be because he's a professional accountant, that's why he can figure out the software.
[16:22] <hyperair> anyway, who here is well-versed with the GNOME freeze exception conditions?
[16:23] <mdeslaur> tedg1: fyi: I've opened bug #530138
[16:23] <tgpraveen12> hyperair: well as i said he was using ms money earlier and he didnt find much differences. and found gnucash to be more flexible, and powerful albeit a weeb bit less friendly
[16:24] <tgpraveen12> but still i mean it totally deserves a featured app for being a star accounting package
[16:24] <hyperair> tgpraveen12: it's still a specialist application. most people have never even heard of ms money.
[16:24] <tgpraveen12> and for nothing else then for the fact that there are no other accounting packages in the featured app section
[16:25] <tgpraveen12> hyperair: inkscape is going to be there. isnt that a specialist app too?
[16:25] <tgpraveen12> and accounting apps are somewhat commonly used i thought
[16:25] <tgpraveen12> hyperair: i could give u more egs.
[16:25] <hyperair> tgpraveen12: the average desktop user is more likely to draw vector graphics than do accounting.
[16:26] <tgpraveen12> thats debateable. depends on the user. my dad would not ever draw. heck i might also never.
[16:26] <hyperair> tgpraveen12: almost all students who have to do reports will eventually need to draw some diagram or other and inkscape is splendid.
[16:26] <tgpraveen12> hyperair: gimp was removed from default install because it was considered a specialist app and it is there in featured app too.
[16:26] <hyperair> compare the number of students doing reports to the number of accountants who use ubuntu?
[16:26] <hyperair> =\
[16:26] <tgpraveen12> hyperair: the point is not only accounts would use gnucash
[16:27] <tgpraveen12> it is a personal accounting app. so anybody could use it.
[16:27] <hyperair> hmm maybe i should take a look at it sometime..
[16:27]  * hyperair has no power over this.
[16:28] <tgpraveen12> hyperair: if u do take a look at it i should mention that the documentation is awesome. do try it
[16:28] <hyperair> hmm okay
[16:28]  * kenvandine uses gnucash :)
[16:32] <vish> tgpraveen12: why dont you respond on the mailing list?
[16:32] <vish> would be a better place
[16:33] <tgpraveen12> just a little lazy as i am not subscribed to ml ;-)
[16:55] <chrisccoulson> taking gpm now
[16:56] <chrisccoulson> pitti - did you have a change to merge?
[16:56] <pitti> chrisccoulson: merge what?
[16:56] <pitti> chrisccoulson: I just saw an indicator bug fix and assigned it to me, but that was like 10 minutes ago
[16:56] <chrisccoulson> pitti - removing the icon from the indicator menu?>
[16:56] <pitti> chrisccoulson: if you are working on the package, please feel free to grab it, of course
[16:56] <chrisccoulson> yeah, no problem
[17:14] <mvo> seb128: when I try to use a git version of gtk I get gdk_keymap_add-virtual_modfiers undefined - is that a known issue? is there a way to workaround?
[17:15] <mvo> http://paste.ubuntu.com/386414/ (full error)
[17:15]  * mvo is away for lunch but will read backlog
[17:17] <chrisccoulson> hey pitti - did you manage to try the latest gnome-user-share today?
[17:17] <seb128> mvo, late lunch?
[17:17] <pitti> chrisccoulson: sorry, not yet; there was quite a large Friday/weekend backlog to catch up with
[17:17] <chrisccoulson> pitti - no worries
[17:17] <seb128> mvo, not a known issue by me no
[17:20] <seb128> mvo, $ nm -D /usr/lib/libgtk-x11-2.0.so | grep gdk_keymap_add_virtual_modifiers
[17:21] <seb128> mvo, we have a patch coming from debian touching that though
[17:21] <seb128> but it's supposed to be a directfb change
[17:32] <mpt> vish, the replace hint (like the append hint) is not reserved afaik, it's public. Empathy annoyed me in 9.10 because it was using replace when it should be using append.
[17:38] <chrisccoulson> trying to merge patches is not nice
[17:39] <seb128> chrisccoulson, in which sense?
[17:39] <seb128> I will do the gtkhtml + evo updates later tonight
[17:39] <seb128> didrocks, ^
[17:40] <seb128> (just mentionning it so we don't dup work)
[17:40] <chrisccoulson> seb128 - i just tried merging a branch from someone, which contains changes to an existing patch
[17:40] <seb128> ah
[17:40] <seb128> yeah, in such cases I just get each and apply changes
[17:40] <chrisccoulson> the merge did not go very well, as i'd just refreshed the patch to apply cleanly to a new upstream version
[17:40] <seb128> and diff the source with changes applied
[17:40] <seb128> but that's annoying to od
[17:40] <seb128> do
[17:40] <chrisccoulson> yeah, i think i'll just do that
[17:40] <didrocks> seb128: evo updates?
[17:41] <seb128> didrocks, evolution
[17:41] <seb128> 2.28.3
[17:41] <didrocks> oh, didn't see that yet
[17:41] <seb128> k
[17:41] <didrocks> sweet :)
[17:45] <Nafai> Holy upgrades Batman
[18:03] <Nafai> pitti: jcastro said you might have questions regarding my vino patch?
[18:07] <pitti> Nafai: ah, right; first, thanks for forwarding upstream
[18:07] <Nafai> Hrm, with the latest update, my multimedia keys on my keyboard stopped working
[18:08] <pitti> Nafai: I wondered if it's possible to do that without changing glade files (which keep changing, and it's a pain to merge with new upstream versions), or changes to/new translatable strings
[18:10] <Nafai> The changes to glade plus the new strings were suggested by mpt. :)  I'll have to look back if that is the only place with new strings.  I'm sure we could, though the current preferences application would be a little odd since it talks about the "Notification Area"
[18:11] <mpt> pitti, no, not really, because with the patch it would no longer be doing the thing that the upstream preferences talk about.
[18:11] <mpt> pitti, the only way to avoid changing a translatable string, I think, would be to make it no longer a preference at all, but that would still involve changing the glade file.
[18:11] <pitti> Nafai: ok, so asked the other way around, woudl the string changes be appropriate for vino without indicators as well? i. e. replacing "notification area" with a more general term?
[18:12] <pitti> then the patch could be split
[18:12] <pitti> into "string beautifications" (which could go upstream sooner), and the indicator bit (which we probably need to keep for a while)
[18:12] <mpt> ahh, that might work
[18:12] <Nafai> mpt would be the one to ask on that, but I'm inclined to say yes
[18:12] <mpt> hm
[18:13] <mpt> Nafai, does the upstream notification area item behave like a menu?
[18:13] <pitti> Nafai: I'm asking because string changes and glade file patches are usually the worst things to maintain
[18:13] <Nafai> pitti: I can imagine
[18:13] <Nafai> mpt: right click menu and left click to bring up prefs
[18:13] <dobey> another temporary alternative to editing the glade, if you just need to change a string, or hide the widget, is to do a simple _hide() or _set_label() or whatever, on the widget in question in the code
[18:14] <Nafai> mpt: which is lame, given there is a "Preferences" menu item in the right click menu
[18:14] <mpt> heh
[18:14] <Nafai> dobey: good point
[18:14] <mpt> Nafai, so "Show Remote Desktop menu:" could conceivably go upstream, though I could understand they might reject it
[18:14] <pitti> well, in case of the strings it's not really the patch itself that hurts, but that you break all translations
[18:14] <mpt> or dobey's idea works too
[18:14] <pitti> and that we have to maintain a parallel set of translations
[18:14] <Nafai> Right
[18:15] <pitti> Nafai: the other part was how much you could test this patch, since it's rather intrusive
[18:15] <mpt> I'm generally biased towards a string that's accurate in one language over a string that's translated in all languages but accurate in none of them
[18:15] <pitti> Nafai: and I know that the canonical desktop folks don't really use vino a lot, thus there's no testing there
[18:15] <mpt> but I know that's got me in trouble before
[18:15] <pitti> mpt: we don't know how accurate the translations are, though
[18:16] <mpt> yeah, I guess some of them could be vague enough
[18:16] <Nafai> pitti: Right, it was hard to test in a way I feel fully comfortable with, it was mainly, "okay, this is the behavior with the packaged version.  I get similar behavior with my version.  Plus, if I compile without app indicators, it still behaves like the currently packaged version"
[18:17] <Nafai> But there are wide corners I'm sure I didn't hit
[18:17] <Nafai> Like I didn't use it for an extended time, etc
[18:19] <Nafai> Great, X.org is suddenly taking 98% CPU
[18:20] <Nafai> brb
[18:22] <didrocks> pitti: when you have some spare cycle (maybe tomorrow), can you please sponsor casper on bug #530024? I guess I'll wait for cjwatson for ubiquity, or if you want to…
[18:24] <didrocks> pitti: I've rewritten the "hook" which call either the copy or the .c file to python in install.py. I've retested in all mode, hence the whole day used for that (+ bug triaging) :/
[18:25] <chrisccoulson> fantastic, gpm doesn't even build
[18:25] <dobey> I need to figure out how to do triggers/hooks with apt
[18:26] <Nafai> back
[18:26] <Nafai> So, what's the consensus on what I should do with vino?
[18:30] <chrisccoulson> pitti - hughsie is ok with us committing trivial fixes to gpm isn't he?
[18:31] <pitti> chrisccoulson: yes, as long as they don't change UI or general behaviour; bug fixes are fine
[18:31] <chrisccoulson> pitti - yeah, the latest version doesn't build, due to an undeclared variable
[18:33] <dobey> is anyone following eog at all?
[18:37] <pitti> didrocks: I saw that you discussed that with cjwatson; so you came to an agreement how to split this between casper and ubiquity?
[18:38] <pitti> didrocks: I'm happy to review/sponsor the casper patch, of course; tab opened, will do tomorrow
[18:38] <didrocks> pitti: right, remove everything from casper and reimplemented in python in ubiquity
[18:38] <didrocks> pitti: hence the time to retest/remake ;)
[18:38] <didrocks> but hopefully caching in install is finished \o/
[18:39] <didrocks> btw, is it normal that /usr/share/backgrounds/warty-final-ubuntu.png is a jpeg file?
[18:39] <pitti> merci beaucoup
[18:39] <didrocks> de rien ;)
[18:39] <pitti> oh, that casper change is easy, applying right away
[18:40] <didrocks> yes, it's just removing :)
[18:40] <pitti> chrisccoulson: so, the new g-u-s doesn't have a noticeable boot speed impact
[18:40] <didrocks> thanks pitti!
[18:40] <pitti> chrisccoulson: I didn't strace it to see how long the extension takes, but I see no apparent difference in the nautilus line
[18:40] <pitti> didrocks: de rien; thanks to you!
[18:45] <dobey> Keybuk: how much will you hate us if ubuntuone-syncdaemon gets started by nautilus at log-in?
[18:47] <chrisccoulson> pitti - thanks. am i ok to just go ahead and upload g-u-s then?
[18:47] <pitti> dobey: does it make a difference whether it's started by an autostart .desktop or nautilus?
[18:48] <pitti> dobey: it seems as a nautilus extension it's cheaper to check gconf etc. whether u1 is enabled, and you could also disable it more easily?
[18:48] <pitti> chrisccoulson: sure
[18:48] <dobey> pitti: well nautilus isn't going to start it directly. it just makes a dbus call
[18:48] <dobey> pitti: yes, we'll be doing that as well
[18:49] <chrisccoulson> pitti - thanks. will upload after dinner
[18:49] <pitti> dobey: I don't think there's a difference about launching it from a .desktop file vs. nautilus; Keybuk only cares about a default installation, where it wouldn't start either way
[18:49] <dobey> pitti: there are also some weird use cases where that can be problematic
[18:50] <pitti> dobey: the thing that I'd consider is non-GNOME desktop UIs, though
[18:50] <pitti> dobey: e. g. XFCE/KDE certainly implement autostart .desktop files, since that's an XDG spec; but nautilus is GNOME specific
[18:50] <pitti> so you'd need a different approach for those
[18:50] <pitti> dobey: what's the principal advantage of launching it from nautilus?
[18:51] <pitti> dobey: (if your intention is to defer the startup for a while, to not utterly slow down desktop startup when U1 is enabled, you can use the X-GNOME-Autostart-Delay: key)
[18:51] <dobey> we don't have put a desktop file and write a wrapper to do the launching
[18:51] <dobey> and nautilus is going to make dbus calls anyway
[18:51] <dobey> no my intention is to make the user experience not suck :)
[18:51] <dobey> i don't care about deferring startup
[18:51] <dobey> i care about presenting information to the user in a timely manner
[18:51] <pitti> dobey: oh, how is the user experience affected by this at all? it seems to me like a small technical implementation detail
[18:53] <dobey> pitti: we can sync arbitrary files, so if you sync ~/Documents for example, we'll need to show an emblem on it, and let the extension set up the UI for managing that folder
[18:54] <dobey> s/files/folders/
[18:54] <pitti> right, understood; that seems unrelated to moving an autostart .desktop to a dbus activation .service file, though?
[18:56] <dobey> pitti: there being an autostart file or not is irrelevant, because the nautilus extension still needs to make the dbus calls, which is going to cause syncdaemon to start regardless of whether the user disabled the autostart or not.
[18:57] <pitti> oh, there already is a com.ubuntuone.SyncDaemon.service
[18:57] <dobey> yes
[18:58] <pitti> dobey: so, as far as I can see, it shouldn't matter; my feeling is that it's easier to handle a .desktop file than to maintian code for XFCE/KDE to launch the sync daemon, but your call
[18:58] <dobey> it was easier to work around this before, when we only had one directory to deal with
[19:00] <dobey> pitti: you got stuck on how it's started. but i just want to know how much scott will want to kill me, so i can make objective decisions about how to make all this work right :)
[19:00] <pitti> heh
[19:01] <pitti> dobey: I don't think he'll care at all
[19:02] <dobey> well if syncdaemon causes an 8-second delay...
[19:02] <dobey> hmm
[19:03] <pitti> dobey: it does that with a .desktop file as well
[19:03] <pitti> it's not due to how it's started, it's doing tons of IO in python
[19:04] <dobey> pitti: i know that. my question wasn't about how to do the startup :)
[19:05] <pitti> dobey: well, if your question was about implying to _always_ starting syncdaemon, independently of whether the user enabled U1, then he'd crossburn you indeed :)
[19:05] <rickspencer3> seems like it would be good for you and I to talk *after* that
[19:05] <rickspencer3> as I may have some news
[19:05] <rickspencer3> (good or bad :/)
[19:05] <rickspencer3> sounds okay?
[19:05] <kenvandine> ?
[19:05] <pitti> rickspencer3: go ahead
[19:06] <pitti> (not sure whom you are addressing in particular)
[19:06] <rickspencer3> wtg
[19:06] <rickspencer3> sorry
[19:06] <dobey> heh
[19:06] <dobey> wrong chan? :)
[19:06] <rickspencer3> that was like half of a PM
[19:06] <rickspencer3> :)
[19:06] <pitti> darn, if you do that you could at least leak a secret :-P
[19:06] <rickspencer3> it makes more sense if you got the first half
[19:07] <rickspencer3> unfortunaly, it's not a secret, I was telling kenvandine that I have a call with statik in a few, and that we should talk after that
[19:07] <kenvandine> :)
[19:07] <didrocks> that's far less interesting and secret ;)
[19:08] <rickspencer3> yeah
[19:10] <chrisccoulson> right, dinner time
[19:10] <chrisccoulson> bbl
[19:11]  * didrocks follows chrisccoulson on dinner :)
[19:12] <hyperair> how does automounting of a volume take place?
[19:12]  * hyperair is trying to figure out how to change vfat's default options
[19:13] <pitti> hyperair: use /etc/fstab
[19:13] <rickspencer3> pitti, now that chrisccoulson has left for dinner, should we discuss who should be the next compiz maintainer?
[19:13] <hyperair> pitti: er. this is a thumbdrive.
[19:13] <rickspencer3> j/k
[19:13] <hyperair> pitti: i want to change the default vfat options for *all* thumbdrives.
[19:13] <pitti> hyperair: in short, it's udev -> event -> udisks -> event -> nautilus -> decides to automount -> dbus call to udisks -> calls mount
[19:14] <hyperair> and who decides which flags to pass?
[19:14] <pitti> hyperair: hm, I don't think that's possible right now
[19:14] <hyperair> in particular fmask/dmask
[19:14] <pitti> well
[19:14] <pitti> some are hardcoded (the security relevant ones)
[19:14] <pitti> some can be specified by the user session
[19:14] <hyperair> i see.
[19:14] <hyperair> i'd like to patch the fmask
[19:14] <hyperair> on whichever program is to blame.
[19:15] <hyperair> i'm annoyed by cp/rsync making all my source code files +x
[19:15] <hyperair> in fact, i don't even know why vfat defaults to having everything +x
[19:15] <hyperair> why is that?
[19:15] <pitti> but nautilus doesn't allow specifying the mount options right now
[19:15] <hyperair> i know it doesn't.
[19:15] <pitti> hyperair: so that you can actually have executable files on them
[19:15] <hyperair> it doesn't seem hardcoded in nautilus either
[19:15] <hyperair> grep doesn't say anything
[19:15] <pitti> no, it's not
[19:16] <pitti> it's just the defualt of "mount"
[19:16] <hyperair> it is?
[19:16] <pitti> static const char *vfat_defaults[] = { "uid=", "gid=", "shortname=mixed", "dmask=0077", "utf8=1", NULL };
[19:16] <pitti> static const char *vfat_allow[] = { "flush", "utf8=", "shortname=", "umask=", "dmask=", "fmask=", "codepage=", "iocharset=", NULL };
[19:16] <pitti> ^ from udisks
[19:16] <hyperair> hmm.
[19:16] <pitti> the second list is stuff that the caller can specify (like nautilus, or udisks --mount-options on the command line)
[19:17] <hyperair> i see.
[19:17] <hyperair> and since nautilus isn't passing that, it's in mount?
[19:17] <hyperair> there's a gconf key somewhere..
[19:17] <hyperair> /system/storage/defaultsomethingorother
[19:18] <hyperair> oh hey i think i'll just patch devkit-disks to change the default.
[19:19] <pitti> hyperair: udisks, but yes
[19:19] <pitti> (unless you are on karmic)
[19:19] <hyperair> i'm on karmic =)
[19:25]  * hyperair rubs hands in glee and builds a patched devkit-disks
[19:27] <hyperair> pitti: by the way, do you know where i can find out more about the freezeexception granted to GNOME?
[19:27] <pitti> uh, good question
[19:27] <hyperair> pitti: and whether taglib-sharp/banshee-community-extensions can be included under it
[19:27] <hyperair> heheh
[19:28] <pitti> taglib-sharp doesn't seem to use GNOME versioning; is it actually part of GNOME?
[19:28] <hyperair> taglib-sharp isn't.
[19:28] <pitti> hyperair: anyway, at this point we only have feature freeze
[19:28] <hyperair> banshee doesn't use GNOME versioning either, but they all sync their releases with GNOME.
[19:28] <pitti> so anything which just fixes bugs is okay
[19:29] <pitti> GNOME itself is pretty much in bug fix only mode as well
[19:29] <hyperair> in banshee's case, 1.5.3 up to 1.6.0 should be bugfix-only
[19:30] <hyperair> i think.
[19:30] <hyperair> 1.6.0 is the stable
[19:30] <hyperair> 1.5.3 up to 1.5.N (i forgot where it stops) is beta.
[19:30] <hyperair> taglib-sharp has api changes (some bitrate property or other being added. quite minor, and no abi breakage)
[19:31] <hyperair> banshee-community-extensions has not entered debian NEW yet.
[19:31] <hyperair> oh yeah banshee 1.5.4 which is sitting around in debian require taglib-sharp 2.0.3.6
[19:31] <hyperair> requires*
[19:32] <gabaug> hyperair: the taglib-sharp api change was accidental, and was reverted in 2.0.3.6
[19:32] <hyperair> gabaug: that's abi, not api.
[19:33] <gabaug> ah, yeah - the rest is all API additions - no harm there
[19:33] <chrisccoulson> rickspencer3, seb128 warned me i might end up being the next compiz maintainer :P
[19:33] <pitti> sounds fine at first sight
[19:33] <hyperair> gabaug: 2.0.3.4->2.0.3.5 broke abi, and 2.0.3.5->2.0.3.6 fixed abi, so we omitted 2.0.3.5 in debian to avoid any breakage.
[19:33] <hyperair> so 2.0.3.4->2.0.3.6 = no problems.
[19:35] <hyperair> pitti: so do i need to request a FFe, or can i just omit and pass it directly to the archive admins?
[19:35] <chrisccoulson> vuntz - is there any way to update my SSH key on my GNOME git account? I'm using a new machine since my account was created, with a new SSH key
[19:35] <pitti> hyperair: if it's a beta->final thing, no FFE necessary
[19:35] <hyperair> pitti: what about taglib-sharp?
[19:35] <chrisccoulson> i have to go back to my old machine to commit
[19:36] <pitti> hyperair: unsure with the current information; perhaps submit an FFE bug with a link to the changelog, and check if the changes include new features/structural changes/etc.?
[19:36] <pitti> (if it doesn't change API/ABI, just adds new API, that seems fine)
[19:37] <hyperair> already checked the ABI, after i went and pwned taglib-sharp's rdeps during the upload prior to this one
[19:37]  * hyperair has learnt his lesson
[19:38] <pitti> hyperair: ok, seems you already checked the sanity of the library then
[19:39] <hyperair> pitti: yep
[19:41] <hyperair> /dev/sdb1 /media/HyperUbu vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0133,dmask=0077,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,flush,errors=remount-ro 0 0
[19:41] <hyperair> \o/
[19:41] <hyperair> thanks pitti =D
[19:56] <didrocks> asac: any reason why build-depending on xulrunner-dev doesn't make the bin package depends on xulrunner?
[20:05] <chrisccoulson> didrocks, do you call dh_xulrunner in debian/rules?
[20:06] <chrisccoulson> it will add the depends to shlibs:Depends then
[20:06] <didrocks> chrisccoulson: hum, that's a classic cdbs file, so I guess not, is there a cdbs class for that, or add it manually?
[20:06] <chrisccoulson> hmmm, i'm not sure if there is a cdbs class for that
[20:07] <chrisccoulson> i think you have to do it manually
[20:07] <didrocks> hum, pitti is quicker :)
[20:08] <chrisccoulson> heh ;)
[20:09] <didrocks> I was thinking that we assigned the bug first, but apparently not :)
[20:09] <chrisccoulson> yeah, historically the xulrunner dependency is added manually to the binary, but you need to update that manually for each new xulrunner version
[20:09] <pitti> it seemed to be so simple to me that I JFDIed it instead of going through a lengthy discussion process
[20:09] <didrocks> hum, assign conflicts :)
[20:09] <didrocks> it overrided yours (thanks to ajax ;))
[20:09] <pitti> usually I pick up the team assignments and fan them out to individuals
[20:09] <pitti> didrocks: oops
[20:10] <pitti> nice race
[20:10] <didrocks> right :)
[20:10] <didrocks> I was looking at that before we were assigned in fact
[20:10] <pitti> but in fact I wondered why we don't use the webkit backend
[20:10] <didrocks> and was suprised but bzr pushed told me "hum hum, diverged ^^)
[20:10] <pitti> and have an ubuntu delta to use xul
[20:10] <pitti> but seb128 isn't around to ask, so *shrug* :)
[20:10] <didrocks> pitti: because it's a debian change and nobody is maintaining it
[20:11] <pitti> ah
[20:11] <didrocks> pitti: so, we took back gecko as upstream advised it and we don't have those weird mallard bugs
[20:11] <didrocks> (I've changed that last week)
[20:11] <chrisccoulson> yeah, the webkit port is quite out-of-date now
[20:12] <didrocks> pitti: so, my bad for having forgotten the dependencies, I was thinking it was pulled automatically. Thanks for fixing it :)
[20:13] <Nafai> pitti: Thanks for adding the comment to the bug for me
[20:14] <pitti> Nafai: heh -- that sounds like "thanks for making my life harder" (which is right, in a way..) :)
[20:16] <Nafai> :)
[20:16] <Nafai> not a big deal, really
[20:17] <chrisccoulson> the new gpm indicator menu is far too wide now it has the remaining time in there
[20:18] <chrisccoulson> it looks really weird
[20:20] <chrisccoulson> tedg - your indicator-application update to hide the fallback GtkStatusIcon before unreffing didn't work
[20:20] <chrisccoulson> would you like to merge lp:~chrisccoulson/indicator-application/fallback-fixes ?
[20:20] <chrisccoulson> (you can't call gtk_widget_hide on a GtkStatusIcon)
[20:23] <tedg> chrisccoulson: Sure, let me finish what I'm doing right now.  Can you propose a merge so I don't forget?
[20:25] <pitti> good night everyone
[20:27] <didrocks> have a good night pitti
[20:29] <seb128> re
[20:29] <seb128> 'night pitti
[20:54] <chrisccoulson> tedg - no problem
[20:54] <chrisccoulson> tedg - there is another issue with the fallback too, which i didn't have time to fix
[20:55] <chrisccoulson> each time an app calls app_indicator_set_menu, a new fallback timer is created, and when it times out, it seems to flip the visibility of the icon
[20:55] <chrisccoulson> which is causing a flashing icon in gpm
[20:55] <chrisccoulson> anyway, brb, i need to power down laptop to take it off the dock
[20:55] <didrocks> time to go to bed, good night everyone
[20:55] <LaserJock> night didrocks
[20:58] <chrisccoulson> hey seb128
[20:58] <chrisccoulson> how are you?
[21:12] <seb128> hey chrisccoulson
[21:12] <seb128> good!
[21:13] <seb128> just finished to dinner and wash dishes
[21:13] <chrisccoulson> heh, i hate washing dishes ;)
[21:13] <seb128> chrisccoulson, you? how was your first day?
[21:13] <seb128> me too!
[21:13] <seb128> that's why I try to do it before going back to the computer
[21:13] <chrisccoulson> yeah, i had a good first day thanks
[21:13] <seb128> otherwise I never come back to do that later :p
[21:14] <chrisccoulson> lol
[21:14] <seb128> chrisccoulson, now you learn to stop working in the evening ;-)
[21:14] <TheMuso> Good morning.
[21:14] <seb128> hey TheMuso
[21:14] <chrisccoulson> heh, yeah, i'll try to!
[21:14] <seb128> I had difficulties with that in my first years
[21:14] <seb128> well I still have in the evening
[21:15] <seb128> but I used to work during weekends too
[21:15] <chrisccoulson> yeah, you're always around quite late
[21:15] <seb128> hard to stop working when you don't think that work is really work ;-)
[21:15] <seb128> I often do a some hours break for sport and dinner
[21:15] <seb128> then I come back rather than watching tv
[21:16] <seb128> or I watch tv with the laptop around
[21:16] <chrisccoulson> yeah, i'm watching some TV at the moment
[21:16] <Nafai> working from home on something I like has definitely shifted the way I work
[21:17] <Nafai> And I definitely work more hours than I normally would have
[21:20]  * TheMuso has made sure he follows a strict routine
[21:20] <TheMuso> And its working.
[21:20] <Nafai> Yeah, I'm trying to get on one
[21:20] <seb128> you have to set limits
[21:21] <TheMuso> If I am on in the evening, its for strictly community work only, i.e stuff thats not Canonical related work, like powerpc/ubuntustudio work.
[21:21] <seb128> I decided I would not work over 24 hours a day!
[21:21] <Nafai> seb128: Great limit!
[21:21] <seb128> ;-)
[21:22] <seb128> joke aside I tend to be around in the evening more chatting and doing some hackings on thing I want to do
[21:28] <RAOF> Morning all!
[21:29] <bryceh> heya RAOF :-)
[21:32] <TheMuso> Hey RAOF.
[21:32] <RAOF> TheMuso: Howdie.  Any joy with lbm?
[21:32] <TheMuso> RAOF: Not yet, need to solve alsa drivers not building against ppc64 kernel headers.
[21:33] <TheMuso> Thats for tonight, or today if I get a spare minute to kick off a build of a 2.6.33 kernel to see if a newer kernel fixes it somehow.
[21:33] <RAOF> Cool.  I guess another option is to simply not build the alsa drivers.
[21:34] <TheMuso> RAOF: Yeah, that requires a lot of fiddling with the build system though.
[21:34] <seb128> hey RAOF
[21:34] <RAOF> seb128: Good moring.  Or evening. :)
[21:59] <chrisccoulson> bugs come faster than i can triage!
[22:00] <RAOF> That's new? :)
[22:01] <chrisccoulson> do i dare subscribe to firefox bugs?
[22:03] <TheMuso> chrisccoulson: Welcome to my world.
[22:05] <robert_ancell> hey, who looks after thunderbird?
[22:06] <seb128> robert_ancell, hey, thanks for asking... :-)
[22:06] <seb128> robert_ancell, you can try #ubuntu-mozilla or asac but I guess nobody really or busy people who do what they can
[22:07] <robert_ancell> seb128, I thought it might be like that.  I tried looking at patching the mozilla apps at one time but they seem quite complex codebases
[22:08] <chrisccoulson> heh
[22:08]  * chrisccoulson ducks
[22:08] <robert_ancell> (the -compose flag to thunderbird is broken in 3.0)
[22:08] <maxb> On a vaguely related note, is there some overall tracking for getting thunderbird extensions updated in time for lucid (ones that are currently uninstallable owing to 2->3) ?
[22:08] <seb128> chrisccoulson, don't worry that's not our default email client so I don't think you have to work on it ;-)
[22:08] <chrisccoulson> seb128 - that's ok then
[22:08] <chrisccoulson> ;)
[22:09] <seb128> chrisccoulson, firefox bug, we all pretty much agreed there is too many bugs to read those
[22:09] <seb128> not especially speaking about firefox there
[22:09] <seb128> so we try to be better at building efficient bug lists
[22:09] <seb128> or getting annoying bugs out of the noise
[22:10] <chrisccoulson> yeah, i had a look at subscribing to firefox bugs, but i already struggle to clear the bugmail from my inbox
[22:10] <seb128> you can still subscribe to firefox bugs I guess but don't try to fight the noise
[22:10] <seb128> just look to title for things you think might interest you
[22:10] <seb128> and trash everything else
[22:12] <rickspencer3> chrisccoulson, bryceh would be a good person to ask about how to get signal from the bug noise
[22:13] <chrisccoulson> yeah, i see bryceh is quite efficient at dealing with X bugs
[22:14] <bryceh> what's up?
[22:15] <seb128> bryceh, chrisccoulson is our new firefox maintainer and is looking for hint to deal with mountains of bugmails
[22:15] <seb128> or bugs reports I guess not especially emails
[22:17] <bryceh> chrisccoulson, welcome aboard!
[22:17] <chrisccoulson> thanks :)
[22:18] <bryceh> yeah with X the bug mail is so heavy I just procmail it to an LP folder and mostly ignore it
[22:18] <kklimonda> chrisccoulson: so that was the thing hggdh has talked about? congrats :)
[22:18] <chrisccoulson> hey kklimonda
[22:18] <chrisccoulson> yeah, thanks ;)
[22:18] <hggdh> who said anything? I?
[22:19] <bryceh> chrisccoulson, I've been making a bunch of scripts and tools to take care of bug triaging and bubbling good ones up to the top
[22:20] <chrisccoulson> bryceh - https://edge.launchpad.net/arsenal ?
[22:20] <bryceh> chrisccoulson, that's it
[22:21] <chrisccoulson> cool, i'll take a look at this
[22:21] <bryceh> chrisccoulson, I'm running a couple things for firefox you might be interested in right now, hang on
[22:21] <bryceh> chrisccoulson, http://www2.bryceharrington.org:8080/X/Reports/mozilla-bugs/
[22:22] <bryceh> oops, the first one's busted.  But I can fix it up if it sounds like something you'd use
[22:22] <bryceh> chrisccoulson, the second one is really handy - shows patches in your team's queue and how long they've been there.
[22:22] <chrisccoulson> yeah, i just noticed the first one has nothing in the list
[22:23] <bryceh> chrisccoulson, http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/high-karma-bugs.html
[22:23] <bryceh> the idea there is that bugs from people with high karma (5000+ I think) are more likely to be well-written bug reports than others
[22:24] <chrisccoulson> yeah, i think that could be quite useful
[22:24] <bryceh> chrisccoulson, another recent thing I've been playing with is tagging bugs by the release they were reported against (karmic, lucid), and then I'm making my reports only display bugs tagged lucid.  That cuts out all the reports made against the stable release that have to be re-tested against lucid
[22:27] <bryceh> chrisccoulson, do you know if with firefox old bugs set to Incomplete are automatically being closed?
[22:27] <bryceh> if not, is that something you'd be interested in having done?
[22:27] <chrisccoulson> bryceh, i'm not sure about that. that's probably something that asac would know
[22:27] <bryceh> ok
[22:29] <bryceh> well, I imagine you're probably inundated with new-hire tasks at the moment.  But when you get to a point where you'd like to work on automating some bug triaging stuff, grab me and I can show you what I do
[22:29] <chrisccoulson> thanks, that's appreciated
[23:26] <Keybuk> dobey: in summary, if you start syncdaemon by default on every login, and it's as slow as it is right now
[23:26] <Keybuk> I will get on a plane
[23:26] <Keybuk> and then I will go to a rescue centre and buy you a kitten
[23:27] <Keybuk> And then I will wait until you have fallen in love with that kitten
[23:27] <Keybuk> At whjch point I will break into your house and punch you in the face
[23:27] <Keybuk> ;-)