[04:49] <Ultimoore> Hey all
[07:16] <DarwinSurvivor> hey
[16:04] <BobJonkman> Ubuntu Hour in Kitchener tonight, 7:00pm EST at Misty Mountain Cafe
[16:04] <genii-around> Wish I could make it :(
[16:06] <BobJonkman> genii-around!  You haven't been around
[16:07] <BobJonkman> I have to go to Toronto on Sunday -- care to have an impromptu Ubuntu Hour there?
[16:07] <genii-around> BobJonkman: I have a huge construction project on the go in the building next door, will be busy until April or so, except for Fridays.
[16:08] <genii-around> BobJonkman: Sunday is actually a really good day for that, because we have usually some people hanging out in the FreeNet office all day and tinkering
[16:08] <BobJonkman> That
[16:09] <BobJonkman> That sounds like it's good for you.  Work is better than no work
[16:10] <genii-around> BobJonkman: Yeah but these 70-100 hour work weeks are grinding me down. Hopefully I'll have enough cash stashed after for a decent new computer though
[16:11] <BobJonkman> So, will you have an hour-long break sometime on Sunday?  Maybe an Ubuntu Lunch Hour?
[16:12] <genii-around> Sounds like a possible plan. Let me see who is going to be hanging around this Sunday in the office and get back to you
[16:13] <BobJonkman> OK, let me know a place and a time and I'll put something in the LoCo calendar, post to the mailing list(s), and I'll show up with a small handful of 11.10 and 11.04 CDs
[16:13] <BobJonkman> Got to find a place to hand those out by April
[16:17] <genii-around> I've distributed most of the Oneiric CDs, I think I have some server ones and maybe 2-3 regular
[16:40] <mimcpher> How does the shiny ubuntu branded CD distribution work, anyways?  mysterious people (I've never seen who) tends to drop a box of them off at the Waterloo Computer Science Club where we hand 'em out
[16:40] <mimcpher> canonical used to mail them to us but that doesn't happen anymore
[16:40] <genii-around> mimcpher: They will ship them now out only toLoCos
[16:41] <mimcpher> Ah, I see.  We were ca.archive.ubuntu.com; they'd ship 'em to us. Now we're just a "regular" old mirror
[16:42] <genii-around> mimcpher: In your case probably dscassel is slipping in and dropping them off :)
[16:42] <mimcpher> genii-around: hmm, I have seen him around :P
[16:42] <mimcpher> Never correllated it with CD dropoffs :P
[16:43] <mimcpher> but then, I use Debian <ducks>
[16:43] <genii-around> It's all good.
[16:45] <BobJonkman> I think the UofW is still the Canadian mirror...
[16:45]  * BobJonkman checks his software repositories
[16:47] <genii-around> There was one in sherbrooke
[16:49] <mimcpher> sherbrooke's one is gone
[16:49] <mimcpher> (our reign as the supreme canadian free software mirror continues!)
[16:50] <genii-around> Heh
[16:51] <genii-around> Being in Toronto I occasionally will use yorku.ca Ubuntu repository, when the regular ones are having issues
[16:51] <BobJonkman> Hmm... ca.archive.ubuntu.com resolves to a range from <IP_ADDRESS> to <IP_ADDRESS>, all of which reverse-resolve to somename.canonical.com
[16:52] <mimcpher> Waterloo throttled our bandwidth to 100mbit over a year ago, so ca.archive got pointed to canonical machines instead
[16:52] <mimcpher> (We kept saturating the university's links...)
[16:52] <mimcpher> We are ca.releases.ubuntu.com still
[16:53] <BobJonkman> Hmm.  The current ca repositories are still the fastest from Waterloo.
[16:54] <BobJonkman> Wonder where the canonical.com  servers are located?
[16:54] <mimcpher> USA somewhere
[16:54] <BobJonkman> Canonical has offices in Canada; Montreal I think..
[16:55] <mimcpher> BobJonkman: we're fast if you transit to the university via ORION, the Ontario Research Innovation Optical Network.
[16:55] <mimcpher> That'll be some canadian home ISPs, all universities/hospitals/gov't/stuff
[16:57] <mimcpher> zaurac.canonical.com is connected via Sprint; afaik they don't have operations outside the US
[16:58] <mimcpher> oh, missed a hop. They're in a european data center owned by datahop
[17:00] <BobJonkman> Nope.  On a regular consumer connection here.  "Rogers Business", but I dispute the "Business" part (in services rendered, not in revenue extracted)
[17:05] <mimcpher> Rogers peers with ORION, so yes it'll be fast
[17:12] <BobJonkman> Well, that's good to know.  Doesn't make me like Rogers any better, tho.
[17:12] <mimcpher> Bell is basically the only ISP I've tried that doesn't
[20:24] <johanbr> Hmm... Videotron appears to reach the University of Waterloo through Chicago, via Sprint and Shaw
[20:33] <mimcpher> Through chicago? Seems a bit roundabout.
[20:33] <mimcpher> I'd expect there to be Quebec -> Toronto fibre
[20:38] <johanbr>  Oh, no doubt, but I've heard Videotron is picky about their peering
[20:39] <johanbr> somewhat like Bell, but maybe not quite as bad


[00:54] <ArneGoetje> asac: that should be only hinting-slight. The hinting-medium link is a leftover from Hardy which hasn't been removed properly.
[01:02] <asac> ArneGoetje: hmm. so another left over ;)
[01:02] <asac> ok
[01:03] <asac> ArneGoetje: please upgrade to my packages in ppa
[01:03] <asac> ArneGoetje: you can set the values to "auto" in font_rendering
[01:43] <ArneGoetje> asac: will do later.
[03:34] <calc> does Ubuntu have the fprintd support that the Gnome 2.26 release notes mentions?
[03:34]  * calc has a fingerprint reader in his laptop
[03:37] <johanbr> The necessary packages seem to be in Universe.
[03:37] <johanbr> libpam-fprint etc...
[03:38] <calc> ah ok
[03:38] <calc> i didn't know if the fingerprint stuff shows up automatically in about me when that is installed or not
[03:38] <johanbr> nor do I
[08:13] <crevette> hello gentlemen and ladies
[08:17] <seb128> hello there
[08:49] <crevette> seb128, hello
[08:49] <seb128> lut crevette
[08:50] <crevette> there is a problem with the plugin empathy of nautilus-sendto-universe
[08:51] <crevette> https://bugs.edge.launchpad.net/ubuntu/+source/nautilus-sendto-universe/+bug/344765
[08:51] <crevette> how can I ask a rebuild ?
[08:52] <seb128> crevette: you can't you need to reupload
[08:58] <crevette> :/
[08:58] <tseliot> seb128: I have written a fix for bug 339228 (which really is bug 307306)
[08:59] <seb128> tseliot: that's not a g-s-d bug then?
[09:00] <tseliot> seb128: it's a bug in gnome-desktop as it does hardware probing even for trivial events
[09:00] <seb128> did you discuss that upstream?
[09:00] <tseliot> and g-s-d relies on gnome-desktop
[09:00] <seb128> where is the patch?
[09:00] <tseliot> yes, but they don't seem extremely interested
[09:01] <tseliot> here are my patches:
[09:01] <tseliot> https://code.launchpad.net/~albertomilone/gnome-desktop/tseliot-fixes
[09:01] <tseliot> https://code.launchpad.net/~albertomilone/gnome-control-center/tseliot-fixes
[09:01] <tseliot> have a look at the latest revision
[09:01] <tseliot> revisions
[09:01] <seb128> what is the upstream bug number?
[09:01] <tseliot> there are two of them:
[09:01] <tseliot> http://bugzilla.gnome.org/show_bug.cgi?id=574931
[09:02] <tseliot> http://bugzilla.gnome.org/show_bug.cgi?id=568160
[09:03] <tseliot> my change involves a small change in the API (i.e. calling gnome-screen-refresh() with an additional argument) therefore I doubt that it will be accepted by upstream in this version of Gnome
[09:03] <seb128> tseliot: ok, that is no go for jaunty
[09:03] <seb128> that's an ABI breakage, not an addition
[09:03] <seb128> it would require a soname change and to transition everything built against libgnome-desktop in jaunty
[09:04] <tseliot> seb128: is there anything else that relies on gnome-desktop?
[09:04] <seb128> better to add a new function doing what you want and make gnome-control-center use it
[09:04] <seb128> tseliot: apt-cache rdepends libgnome-desktop-11
[09:04] <seb128> tseliot: probably not on the gnome-rr api but still that's an abi breakage
[09:08] <tseliot> seb128: ok, would it be ok if I modified only the static functions and add another non-static function?
[09:09] <seb128> tseliot: you can modify anything which is not part of the public api
[09:10] <seb128> you can add a new function doing the non expensive calls and change the code to call that one
[09:10] <seb128> if you do please prefix it ubuntu_ though so we avoid having trouble with upstream because we modify their api in a non obvious way
[09:11] <tseliot> seb128: yes, this is exactly what I was thinking of doing. And yes I'll use the ubuntu_ prefix as I did in some other patches of mine
[09:11] <seb128> excellent, thanks for your work
[09:11] <seb128> I will try to ping federico about that when he's online
[09:11] <tseliot> ok
[09:12] <tseliot> I'll give you my new patches soon
[09:13] <seb128> could you also attach your suggested patches to bugzilla when you done with those?
[09:13] <seb128> thanks
[09:14] <pitti> Good moring
[09:15] <seb128> hey pitti
[09:15] <seb128> pitti: how do you feel today? better?
[09:16] <pitti> seb128: yeah, much better
[09:16] <pitti> unfortunately I had to fiddle with my internet for an entire hour
[09:16] <pitti> my main network is broken, and then it took me another 20 minutes to get my 3G card workoing
[09:17] <pitti> bah
[09:17] <pitti> want DSL
[09:19] <seb128> dsl is coming ;-)
[09:20] <tseliot>  seb128: shall I attach my patches that break the API in the gnome bugzilla?
[09:20] <seb128> tseliot: yes please
[09:21] <davmor2> pitti: :(
[09:22] <tseliot> seb128: ok, I'll tell them that if the patches that I attach look good to them and they are interested, I'll add the checks for RandR's version both at runtime and at compilation time.
[09:30] <asac> seb128: in interface editor there are only 3 fonts, while we have 5 in the appearence dialog ... any clue where the others are configured?
[09:30] <seb128> asac: say that again?
[09:31] <asac> seb128: ;). sorry. i mean in /desktop/gnome/interface there are 3 font names
[09:31] <asac> seb128: but in appearence dialog there are five ;)
[09:32] <seb128> asac: ah, the title font is a wm thing and the monospace a g-t one I think
[09:32] <seb128> asac: search for Sans in the gconf key names ;-)
[09:32] <seb128> it should list those
[09:32] <asac> seb128: monospace is in /desktop/gnome/interface
[09:32] <asac> but let me search for sans and serif
[09:33] <seb128> well, search in gconf-editor
[09:33] <seb128> check to include the value
[09:33] <seb128> and type the font name
[09:33] <asac> yeah so its nautilus desktop font
[09:34] <seb128> that one is the one used for the desktop icons only right
[09:34] <asac> and metacity/general/title_bar_font
[09:34] <asac> great
[09:34] <asac> metacity/general/titlebar_font
[09:42] <asac> tbird is indeed an ugly beast. have to figure why it is such a wrong font there. in thunderbird 3 all seems fine.
[09:43] <asac> let me first finish this security update round for tbird ... after lunch i can hopefully deal with this
[10:20] <tseliot> seb128: I managed to achieve the same effect without breaking the API. This way we don't even have to update gnome-control-center: https://code.launchpad.net/~albertomilone/gnome-desktop/tseliot-fixes
[10:21] <seb128> tseliot: excellent ;-)
[10:22] <asac> tseliot: set your email in your launchpad account ;)
[10:22] <asac> tseliot: to match what you use in bzr ;)
[10:22] <cassidy> crevette: seb128: https://bugs.edge.launchpad.net/ubuntu/+source/nautilus-sendto-universe/+bug/344765 would be good to rebuild it now Empathy 2.26 reached Jaunty
[10:22] <asac> @canonical.it ?
[10:22] <asac> whats that?
[10:23] <tseliot> asac: I thought I set it to @canonical.com already
[10:23] <asac> tseliot: seems you changed from @alice.it ... to @canonical.it ;)
[10:23] <asac> both are not associated with your launchpad account
[10:23] <asac> so i cannot click on your name (like i can do for Michael Vogt for instance ";))
[10:23] <seb128> cassidy: yes
[10:24] <tseliot> asac: @canonical.com is the default email address on launchpad. Or am I missing something?
[10:24] <seb128> cassidy: somebody screwed the packaging apparently
[10:24] <asac> tseliot: i dont know. only thing i know is that the emails you used for commit are not associated
[10:24] <asac> with your LP account
[10:24] <seb128> cassidy: the issue you shows suggest than a soname changes and the library has not be renamed
[10:25] <asac> if thats transitional its ok. otherwise you can just add multiple emails
[10:25] <cassidy> seb128: empathy renames his libs each time soname are changed
[10:25] <tseliot> asac: no, it's a typo. It looks like I replaces @alice.it with @canonical.it instead of @canonical.com. Thanks for making me notice ;)
[10:26] <seb128> cassidy: there is something weird there
[10:26] <seb128> cassidy:  libempathy-gtk.so.17 => not found
[10:26] <asac> tseliot: no problem.
[10:26] <seb128> cassidy: that should never happen
[10:27] <tseliot> asac: news on the hardy branch of n-m 0.7.1?
[10:27] <seb128> cassidy: ok, nautilus-sendto-universe has no shlib depends apparently and you removed the old soname
[10:27] <cassidy> so problem is in nautilus-sendto-universe pkg?
[10:27] <seb128> yes
[10:28] <seb128> it should depends on libempathy-gtk17
[10:28] <seb128> which would assure this version stay installed even if there is a new one
[10:28] <asac> tseliot: that kind of got bumped from low to medium prio for me.
[10:28] <seb128> cassidy: I will fix that today
[10:28] <asac> because we need it else where now
[10:28] <Zdra> seb128: we can have multiple version of libempathy installed on the same time?
[10:29] <asac> tseliot: so it will happen really soon
[10:29] <cassidy> seb128: cool
[10:29] <tseliot> asac: ah, very well :-)
[10:32] <seb128> Zdra: well, if the soname change they don't conflict so yes, that's the reason we change binary names
[10:33] <seb128> Zdra: do libsomething7 and libsomething8 can be installed together
[10:33] <seb128> which makes easy transitions, you can keep libsomething7 installed while you rebuild things with the new version
[10:34] <Zdra> seb128: ok
[10:34] <asac> anyone else noticed that "paste" with middle mouse became unreliable in jaunty gnome-terminal?
[10:34] <seb128> no
[10:34] <asac> not really a recent regression. i always thought it was X loosing events. but currently i am thinking its gnome-terminal eating mouse events if its not yet focussed
[10:35] <asac> interesting. i regularly need to press middle mouse twice or sometimes even three times to get the paste
[10:35] <seb128> I don't copy things there often though
[10:35] <asac> fta: ^^ do you see this?
[10:35] <asac> ah right. you use xterm
[10:35] <asac> too bad
[10:40] <tseliot> seb128: patch submitted (just FYI): http://bugzilla.gnome.org/show_bug.cgi?id=568160
[10:41] <seb128> tseliot: thanks
[10:41] <tseliot> np
[10:54] <davidbarth> pitti: ping? MacSlow is building notify-osd latest tarball as I speak
[10:55] <asac> seb128: apt-get source ubiquity -> ./gui/glade/stepLanguage.glade
[10:55] <asac> seb128: the title is in "single line mode" ... this seems to have a bug making the label not scaling vertically at all
[10:56] <davidbarth> asac: ping? do you have new build of network-manager-gnome with the last title fixes? the last one i see (0.7.1~rc3-0ubuntu1) dates back to the 5th of March
[10:56] <asac> http://ubuntu-pics.de/bild/11246/bildschirmfoto_1_o1tzqH.png
[10:56] <asac> seb128: ^^
[10:58] <asac> davidbarth: yes. i need to put some love into this asap. sorry for the delay.
[10:58] <asac> today or tomorrow morning i will try to get this through RMs.
[11:01] <pitti> davidbarth: he just told me
[11:01] <pitti> davidbarth: standing by :)
[11:05] <asac> so for single line mode we have:
[11:05] <asac> height += PANGO_PIXELS (ascent + descent);
[11:05] <asac> otherwise its height += PANGO_PIXELS (logical_rect.height);
[11:14] <seb128> doh, GNOME switching to git officially for 2.27
[11:15] <pitti> ugh, more pain
[11:15] <pitti> seb128: and you are complaining about bzr..
[11:16] <seb128> I like svn ...
[11:16] <cassidy> really?? O_o
[11:16] <seb128> cassidy: svn? yes
[11:17] <Laney> does sending notifications work over dbus? i.e. could I monitor notification requests with dbus-monitor?
[11:17] <cassidy> i can't work with it any more
[11:17] <Laney> looking at bug 343261 for Banshee
[11:17] <cassidy> git changed my life (in better ;)
[11:18] <seb128> cassidy: over complication for no real benefit for what I do
[11:18] <cassidy> I guess that depends of your uses cases
[11:19] <seb128> cassidy: get a checkout, do some easy changes, push back
[11:19] <cassidy> but for lot of developers that's a real benefit
[11:19] <cassidy> yeah for that svn is definitely easier
[11:20] <cassidy> but for us, for example, we have a branches oriented dev workflow.  git is a must have in that case
[11:20] <seb128> Laney: dbus-monitor --session
[11:20] <Laney> seb128: Yeah, I was just wondering if that would actually work (not on an Ubuntu box atm to test)
[11:20] <seb128> cassidy: git makes that difficult for no good reason compared to bzr in such cases, but *shrug*, the git fanboys didn't bother trying to see if other dcvs work better usually
[11:22] <cassidy> seb128: I'm not considering myself as a git fan boy and I'm still using bzr (for my Elisa plugin for example). I recognized that git was scaring me first but now I know how to use it, it wouldn't change it for anything else
[11:22] <seb128> cassidy: but that has been trolled enough, I guess I will just use git the way I used svn
[11:23] <cassidy> yeah if you do the same thing as you did with svn that's not so harder
[11:23] <seb128> cassidy: you think bzr is not good enough for what you have to do? what do you miss there? just curious
[11:24] <pitti> seb128: well, frankly, svn is a pain in the neck
[11:24] <cassidy> seb128: I think it's generally less flexible and powerfull than git. What I miss most is the fast cloning/branching, the ability to store branches in the same repo, the remote repo, git rebase, etc
[11:25] <cassidy> bzr can probably do most of these stuffs with plugins though, I didn't really investigate this area
[11:25] <seb128> I guess I'm not enough of a code writer to need all those things
[11:25] <pitti> svn's lack of branches, and together with that, this hideous websvn is a really major issue
[11:25] <cassidy> yep, as said, that's just a matter of uses cases
[11:26] <seb128> I like the viewsvn of GNOME
[11:26] <seb128> but *shrug* ;-)
[11:26] <pitti> cassidy: yeah, bzr has those as well (all built in, except for rebase, which is a plugin for good reason, since it's not a good idea to use it in public development)
[11:27] <cassidy> that's similar than vim vs gedit. Both a good editors but one is a lot more complete and require more training
[11:27] <pitti> seb128: really? I always bite into my table if I have to cherrypick a patch from svn; but maybe I just don't know some dirty tricks
[11:27] <cassidy> and not everyone needs to use vim :)
[11:27] <seb128> pitti: it lacks a "give the diff for this revision", you have to do it file by file which is no fun but otherwise it's nice
[11:27] <pitti> the simple question "show me the diff of r1234" requires black magic with webcvs/websvn
[11:27] <pitti> seb128: right, that's the thing I'm usually interested in
[11:28] <seb128> yeah, agree with you it lacks this one
[11:28] <seb128> anyway no point to debate on that, it's settled for GNOME
[11:28] <pitti> so for popular projects I just keep a checkout and svn diff it from there (which is slightly easier, although still much harder than in bzr)
[11:28] <pitti> right
[11:28] <seb128> good that they stop discussing tools for ages
[11:28]  * pitti shuts up
[11:29] <pitti> I just don't quite understand how people can actually like git
[11:29] <cassidy> actually my prefered bzr feature is the launchpad integration. So if you could convince your co-workers to support git as well that would be great :D
[11:29] <cassidy> but I guess there is so political issues here :)
[11:29] <pitti> cassidy: that's in fact a long-standing wishlist item
[11:29] <seb128> cassidy: lp will be opensource soon so you will perhaps be able to write a patch for it ;-)
[11:29] <pitti> cassidy: no, it's just a manpower thing
[11:30] <pitti> cassidy: writing a bzr interface for git which is really robust is far from trivial
[11:30] <pitti> seb128: bzr is open source..
[11:30] <pitti> it's got nothing to do with lp
[11:30] <pitti> there's tailor, but it's not robust
[11:31] <pitti> i. e. if you do two git imports with tailor, the resulting branches aren't related to each other
[11:31] <seb128> pitti: I think they want launchpad to do git hosting the way it does with bzr
[11:31] <cassidy> I'd like real git integration, not one going through bzr
[11:31] <pitti> ah, I see
[11:31] <cassidy> seb128: yep
[11:31] <pitti> cassidy: well, I for my part want a bzr interface for git, so that I can actually *use* it without constantly having to RTFM and think about the git complexities :)
[11:32] <pitti> but I don't mind much either way
[11:32] <cassidy> yeah that would be good and useful for lot of people
[11:34] <pitti> seb128: would you mind pinging me on jabber? need to test the new indicator-messages
[11:35] <seb128> pitti: done
[11:54] <mdeslaur> asac: I've noticed Shift-Insert being unreliable in gnome-terminal since jaunty
[12:03] <kenvandine_wk> pitti: want to test ekiga?
[12:04] <pitti> hey kenvandine_wk
[12:05] <pitti> kenvandine_wk: good day for that today, since I'm on 3G, and not on my weird ISP
[12:05] <pitti> kenvandine_wk: in your PPA?
[12:05] <pitti> kenvandine_wk: give me 30 mins to sponsor two more packages, then we can do that?
[12:07] <pitti> kenvandine_wk: how did the config migration work for you? I think I'll dump my ekiga gconf settings before the upgrade :)
[12:09] <kenvandine_wk> pitti: sure
[12:10] <kenvandine_wk> pitti: it  just worked :)
[12:10] <pitti> nice
[12:20] <pitti> seb128: ted's two merge requests done; doing notify-osd now
[12:21] <pitti> . o O { with a bzr merge and a bzr bd -S this is all too easy! }
[12:23] <pitti> MacSlow: does the trunk bzr log contain all LP # references? I see two references, is that corect?
[12:24] <MacSlow> pitti, yeah... right now I cannot think of a bugfix between 0.9.5 and 0.9.6 I might have overlooked
[12:24] <pitti> MacSlow: ok, thanks
[12:30] <seb128> pitti: thanks
[12:38] <pitti> MacSlow: is it expected that tests/test-modules segfaults?
[12:38] <pitti> the actual package works fine for me
[12:39] <kenvandine_wk> pitti: that upgrade this morning was painful... killed my box, but i blame compiz
[12:40] <asac> mdeslaur: interesting
[12:40] <asac> mdeslaur: but for me its also middle click in firefox
[12:40] <pitti> kenvandine_wk: killed how?
[12:40] <asac> that sometimes doesnt work to close tabs
[12:40] <kenvandine_wk> memory
[12:40] <asac> somehow i think its at-spi ... let me disable assistive technolgoies
[12:40] <kenvandine_wk> compiz was using more than 700M RSS
[12:40] <kenvandine_wk> while update manager was doing a massive update
[12:40] <kenvandine_wk> 3G of ram and 2G swap all pegged
[12:40] <asac> i need a good wikipage about libindicate and the idea about that
[12:40] <asac> mpt: ?
[12:40] <kenvandine_wk> and apps started crashing
[12:41]  * kenvandine_wk wonders why compiz was sucking so much memory
[12:41] <mdeslaur> asac: oh, something else then
[12:41] <kenvandine_wk> the fonts look great now though :)
[12:43] <asac> anyone knows when the beta lock will happen?
[12:43] <seb128> asac: today when slangasek wake up and find an IS person to turn the button
[12:44] <seb128> asac: ie in the next hours
[12:44] <kenvandine_wk> asac: the fonts look great!
[12:44] <asac> kenvandine_wk: ;)
[12:44] <kenvandine_wk> but pidgin's fonts look huge :)
[12:44] <asac> kenvandine_wk: except in thunderbird
[12:44]  * kenvandine_wk is a evo guy :)
[12:45] <asac> kenvandine_wk: so ... there are a few more tweakages
[12:45] <asac> kenvandine_wk: monospace fonts in terminal need to be changed
[12:45] <asac> let me check pidgin
[12:45] <asac> maybe we need to use a smaller document_font
[12:45] <kenvandine_wk> pidgin defaults to the document font
[12:45] <kenvandine_wk> oh yeah... terminal is huge too
[12:46] <kenvandine_wk> but they are sharp looking :-D
[12:46] <asac> kenvandine_wk: terminal font is even in a bug in gnome terminal i think
[12:46] <asac> kenvandine_wk: but i will know more in a few
[12:47] <MacSlow> pitti, oh no ... that should not happen
[12:48] <asac> kenvandine_wk: hehe. for now set document_font to 10.666px
[12:48] <Ampelbein> seb128: bug #345168 ready for review, builds fine with the svn-patch included.
[12:49] <kenvandine_wk> asac: nah... i will wait so i can test the defaults
[12:49] <seb128> Ampelbein: thanks!
[12:50] <pitti> kenvandine_wk: hm, diamondcard seems to work for me, but @ekiga.net not
[12:50] <pitti> kenvandine_wk: I can't get the echo test (immediately disconnects)
[12:50] <pitti> kenvandine_wk: and if I try to ring you, it says "user not available"
[12:51] <seb128> I don't use ekiga but it seems to be buggy every time pitti tries a new version
[12:51] <pitti> heh
[12:51] <pitti> seb128: interestingly enough, using @diamondcard.us has never failed me
[12:52] <pitti> just @ekiga.net
[12:52] <MacSlow> pitti, I'm looking into the notify-osd test-suite atm
[12:52] <pitti> kenvandine_wk: try to ring me?
[12:52] <MacSlow> pitti, I'll get back to you once I know more ... btw... which part segfaults for you?
[12:52] <kenvandine_wk> one sec
[12:53] <pitti> MacSlow: http://paste.ubuntu.com/133617/
[12:53] <pitti> MacSlow: hang on, trying to get a stack trace
[12:54] <MacSlow> pitti, wtf ... I fixed that
[12:54] <MacSlow> that can't be
[12:54]  * MacSlow tears out his hair
[12:57] <pitti> MacSlow: http://paste.ubuntu.com/133619/
[13:03] <mpt> asac, I'm sorry, tedg and I haven't had time to write up anything about it yet
[13:03] <mpt> the Empathy developers need it too
[13:07] <MacSlow> pitti, do you run it on the build-server or locally?
[13:08] <MacSlow> pitti, question is ... does it have a proper display or not ... the test-suite currently needs that
[13:08] <MacSlow> hey mvo
[13:08] <mvo> hey MacSlow
[13:12] <asac> mpt: hmm ... i need to explain to moz the difference of libindicate and why supporting that in the "general" toolkit makes sense ... for background i had http://paste.ubuntu.com/133628/
[13:13] <pitti> MacSlow: locally
[13:13] <pitti> MacSlow: yes, it's my normal workstation, just debian/rules build and tests/test-modules
[13:13] <pitti> jaunty du jour
[13:15] <MacSlow> pitti, while it does not crash here it covers only 54% of the tests ... that's unacceptable and I suggest to defer notify-osd for today
[13:15] <MacSlow> 's beta
[13:15] <pitti> MacSlow: well, the previous versions's test crashed as well; I uploaded it already, too
[13:16] <pitti> since my tests in the real system (volume control, IRC bubbles, etc.) work just fine
[13:16] <MacSlow> pitti, I just cannot chase everything so fast
[13:16] <pitti> MacSlow: joining dx
[13:16] <MacSlow> it's such a mess
[13:17] <huats> hello everyone !
[13:17] <seb128> lut huats
[13:17] <seb128> hey rickspencer3
[13:17] <huats> hello seb128 !
[13:17] <huats> ho are you ?
[13:17] <seb128> huats: good, you?
[13:19] <huats> seb128: good too !
[13:19] <huats> it is summer here :)
[13:20] <seb128> ;-)
[13:20] <seb128> it's sunny here too
[13:20] <Laney> Lucky! We just have grey skies
[13:23] <seb128> pitti: having the configure.in diffing and the symbol diff, etc as part of a standard testsuite in bzr-buildpackage would be nice
[13:24] <pitti> yeah
[13:24] <seb128> I always do that by hand
[13:24] <seb128> diff the configure.in between version
[13:24] <seb128> run my diff-symbols.py after build
[13:24] <pitti> ok, time for lunch
[13:24] <pitti> bbl
[13:24] <seb128> and then by debdiff between installed version and new debs
[13:24] <seb128> pitti: enjoy!
[13:37] <seb128> tseliot: still around? was your gnome-desktop change something ready for sponsoring?
[13:42] <tseliot> seb128: yep
[13:42] <tseliot> seb128: I updated the bzr branch to the latest version that you uploaded
[13:43] <tseliot> since the version in the ~ubuntu-core-dev wasn't up-to-date
[13:43] <seb128> tseliot: can you give the bzr url again?
[13:43] <tseliot> https://code.launchpad.net/~albertomilone/gnome-desktop/tseliot-fixes
[13:43] <tseliot> the branch is: lp:~albertomilone/gnome-desktop/tseliot-fixes
[13:43] <seb128> tseliot: thanks
[13:44] <tseliot> seb128: thanks in advance for the upload :-)
[13:56] <seb128> you're welcome
[13:56] <seb128> tedg: hi, got a minute to discuss your pidgin changes?
[13:57] <tedg> seb128: Sure.
[13:57] <seb128> tedg: ok, so 2 questions
[13:57] <tedg> seb128: Heh, there's only two patches ;)
[13:57] <seb128> 1- wouldn't it make sense to use the prefs.xml to change the default option to show the icon? or that's not working?
[13:58] <seb128> 2- did you send your other change upstream, cf patch tagging and lower delta etc discussions
[13:59] <tedg> seb128: I don't see a prefs.xml in the source tree.  I think it gets built by that code.  That is what sets the defaults for that.
[13:59] <seb128> tedg: cd debian/prefs.xml in the deb source
[13:59] <tedg> seb128: Yes, I will, I just finished it at 2am last night.  That's a today thing :)
[13:59] <seb128> cd -> cf rather
[14:00] <seb128> tedg: ok, no hurry I'm just making sure we don't carry diffs for ever for no good reason ;-)
[14:01] <tedg> seb128: Ah, I didn't look in the debian packaging.  Sure, that works for me, I was just only looking in the upstream codebase.
[14:01] <tedg> It seems a little weird that the debian packaging does things differently than the upstream project though...
[14:02] <seb128> tedg: ok, let's upload your version for now maybe and figure that later?
[14:02] <tedg> seb128: Sounds good.
[14:02] <seb128> tedg: how differently? we ship a config rather than patching the code
[14:02] <seb128> that seems a better way to me
[14:02] <seb128> redhat does that too in them rpm iirc
[14:02] <tedg> seb128: They don't ship a config at all and build it on the fly.  I'm not saying it's bad, I'm just saying it's odd.
[14:03] <seb128> ok
[14:03] <dandre> hello,
[14:03] <dandre> I am looking for a fax frontend to send faxes from my ubuntu to a hylafax server
[14:03] <seb128> I've no strong opinion either way ;-)
[14:03] <seb128> dandre: -> #ubuntu
[14:03] <tedg> For instance if they change the defaults, or the type of a value, that's going to show up as a bug instead of something that just "goes with the flow."
[14:03] <dandre> sorry
[14:04] <pedro_> seb128: salut, may you please give your opinion on bug 344431?
[14:04] <seb128> pedro_: holla!
[14:04]  * tedg is learning things he shouldn't in Pidgin's debian/lintian-override directory :)
[14:04] <seb128> one minute
[14:05] <seb128> tedg: ah ah
[14:11] <seb128> tseliot: uploaded and pushed to the ubuntu-desktop vcs (it's stored there now, I've updated the control)
[14:11] <tseliot> seb128: thanks :-)
[14:12] <seb128> tedg: http://launchpadlibrarian.net/24088024/0.14-1ubuntu6.debdiff
[14:13] <seb128> tedg: why did you remove the VERSION file there?
[14:13] <tedg> seb128: Sorry, that was a bzr-ism.  The file got deleted and then the commit caught it.
[14:13] <tedg> I forgot to clean it up.
[14:13] <seb128> tedg: ok, I drop that change then
[14:14] <tedg> seb128: Great, thanks.  Sorry about that.
[14:14] <seb128> no problem!
[14:14] <tedg> I think it's a problem in the upstream build system.  They also delete some HTML files.
[14:20] <seb128_> could piding be less intuitive as an IRC client?
[14:20] <seb128_> it opens a nickserv dialog saying the nickname is already registered
[14:20] <seb128_> no channel list, nothing obvious on what to do or showing that IRC is connected
[14:21] <seb128> seb128_: hello
[14:21] <seb128> seb128_: hello
[14:21] <seb128> hum
[14:21] <seb128> tedg: it displays 3:23 for the message time when it's 15:23?!
[14:22] <tedg> seb128: Yes, it is a translateable string.  You're just seeing it in American ;)
[14:23] <seb128> why does the time need to be translated I will never understand
[14:23] <seb128> it's easy french doesn't use am and pm we use 24 hours
[14:23] <seb128> that should be a locale thing and just work
[14:23] <tedg> seb128: Because Americans can't read 24 hour time.
[14:24] <seb128> well the american locale should say you use am and pm then
[14:24] <dobey> it does
[14:24] <seb128> well so why do we need to translate the time string?
[14:24] <tedg> Well, that seemed like extra information that doesn't seem useful.  Are you really looking at IM messages that are over 12 hours old?
[14:24] <dobey> that's what LC_TIME is for
[14:24] <seb128> I though there was a glibc api for that
[14:24] <tedg> dobey: How do you get it from locale then?
[14:25] <dobey> but there are other issues
[14:26] <tedg> Please comment with ideas on bug 334036
[14:26] <dobey> like, i don't think there is a glibc api to actually give you a string for the time that is properly formatted for the locale
[14:26] <dobey> or something
[14:26] <tedg> The idea was to pull the GConf key from the clock.  But that required pulling in GConf.
[14:26] <dobey> which is why there are a billion time strings in the evo translations for example
[14:26] <tedg> And lots of logic to find the clock.
[14:34] <seb128> that is just ridiculous, there is none of those strftime() function or something to display an hour formatted for your locale?
[14:35] <dobey> strftime is like sprintf but takes time formatting options
[14:36] <dobey> so strftime("%h:%m") or something (though those are definitely not the right ones
[14:39] <seb128> tedg: strftime %X
[14:40] <seb128> displays 15:41:23 with a french locale
[14:40] <tjaalton> seb128: whoa, I already got a fix for the nfs bug :)
[14:40] <tjaalton> a _proposed_ fix
[14:40] <seb128> "03:41:56 PM" with an en_US one
[14:40] <seb128> tjaalton: nfs or gnome fix?
[14:40] <tjaalton> seb128: nfs/kernel
[14:41] <dobey>        %X     Equivalent to %T .
[14:41] <dobey> and %T is not in the man page...
[14:41] <tedg> seb128: Is there a way to kill the seconds though?
[14:41] <dobey>        %T     time; same as %H:%M:%S
[14:41] <dobey> from man date
[14:41] <dobey> huh
[14:42] <seb128> tedg: man strftime?
[14:42] <seb128>        %T     The time in 24-hour notation (%H:%M:%S). (SU)
[14:43] <seb128>        %X     The preferred time representation for the current locale without
[14:43] <seb128>               the date.
[14:43] <seb128> on jaunty
[14:44] <dobey> man stftime doesn't say that on intrepid. hrmm
[14:45] <seb128> GNU                               2008-10-29                       STRFTIME(3)
[14:45] <seb128> it has been updated recently
[14:45] <tedg> I still don't see how to do without seconds.
[14:45] <seb128> right, me neither but there must be a way ;-)
[14:46] <tedg> I guess I could do %X and then compare it to one of the other cases using strcmp.
[14:46] <seb128> you can use %H:%M but that will be 24 hours format
[14:46] <seb128> and there is a way to query the 24h or amp,pm from libc for sure
[14:46] <seb128> you could query and call with the right parameter for am,pm or 24 hours
[14:48] <dobey> you could do a regex of s/:[0-9][0-9] // on the sring :)
[14:48] <dobey> err
[14:48] <dobey> s/foo / / rather
[14:56] <tedg> Does devhelp work for anyone else?  It's not worked on Jaunty for me.
[14:59] <mvo> works for me
[14:59] <mvo> (devhelp)
[14:59] <seb128> mvo: want to sponsor #345168? ;-)
[15:00] <mvo> bug #345168
[15:00]  * seb128 is trying to tackle the sponsoring queue before beta
[15:00] <mvo> seb128: can do
[15:00] <seb128> I think it's an easy one
[15:00] <seb128> thanks
[15:00] <mvo> kendo!
[15:00] <seb128> I'm just busy with some other change and slangasek will probably trigger the freeze button soon ;-)
[15:01] <asac>  \o/ ... i think i am done wiht the pre-beta-freeze rush
[15:01] <asac> great that the archive was still open toda
[15:01] <asac> y
[15:01] <asac> now looking at gnome-terminal and thunderbird font issue to see what we can do for beta still
[15:02] <fta> grr, why ooo keeps starting in fullscreen mode? it has no decoration, and i can't make it smaller (metacity)
[15:02] <mvo> seb128: geh, its not in bzr
[15:03] <mvo> crisis!
[15:07] <seb128> mvo: you can put it there if you want ;-)
[15:13] <Ampelbein> mvo: i did not know that nautilus-cd-burner was to be packaged in bzr, the debian/control file did not say so.
[15:19] <seb128> Ampelbein: it's not which is what mvo complain about ;-)
[15:20] <seb128> or not yet
[15:20] <seb128> rather
[15:25] <mvo> seb128: hm, nautilus-c-b looks ok, but I don't see it in the place menu anymore
[15:25] <mvo> seb128: but right click on a iso works - is that a known issue?
[15:26] <Ampelbein> mvo: yes
[15:26] <seb128> mvo: yes, pedro_ pinged me about a similar bug before, forgot to look
[15:26] <seb128> pedro_: ^
[15:26] <seb128> mvo: we don't use n-c-b by default anyway in jaunty so
[15:26] <pedro_> is on the system tools menu now bug 344431
[15:27] <Ampelbein> mvo: gnome bug 573790
[15:29] <seb128> ok I think that's a confusing choice
[15:29] <seb128> vuntz: ^ what do you think about this one?
[15:32] <mvo> seb128: sorry, disconnected. did you say something in between?
 ok I think that's a confusing choice
[15:32] <seb128>  vuntz: ^ what do you think about this one?
[15:32] <mvo> so its a choice from upstream?
[15:32] <seb128> mvo: I think we should discuss adding back the item to the place menu
[15:32] <seb128> mvo: <Ampelbein> mvo: gnome bug 573790
[15:33] <mvo> thanks, I will sponsor the upload then, I was not certain if it was deliberate or a error in the package
[15:34] <seb128> cool
[15:34] <seb128> bah, hate gnome-screensaver
[15:34] <Ampelbein> mvo: thanks. gotta go now, be back later. cu.
[15:34] <davmor2> pitti: did you upload/fix jockey in kubuntu to stop using sudo?
[15:35] <davmor2> pitti: it's alright jockey started up before the update :)
[15:36] <pitti> davmor2: yes, yesterday
[15:36] <davmor2> pitti: yes jockey started up, then the updates ran, So it worked as expected after reboot
[15:37] <mdeslaur> asac: openoffice also probably
[15:38] <seb128> Laney: hey, are you interested by doing some desktop work today? ;-)
[15:39] <pitti> davmor2: I'm glad to hear that :)
[15:39] <asac> mdeslaur: me?
[15:39] <asac> mdeslaur: font issues in ooo?
[15:39] <Laney> seb128: Aye, what needs doing?
[15:39] <mdeslaur> asac: probably the same issue as gnome-terminal and thunderbird
[15:40] <asac> mdeslaur: gnome terminal has a bug in the font code
[15:40] <seb128> Laney: http://download.gnome.org/sources/evolution-mapi/0.26/evolution-mapi-<IP_ADDRESS>.tar.gz is an easy update but current version is totally broken
[15:40] <asac> mdeslaur: they always reset stuff to point
[15:40] <asac> mdeslaur: i found that already and have to fix it
[15:40] <Laney> seb128: OK I will be home in 90 mins to have a look
[15:40] <seb128> Laney: and nautilus-sendto-universe uses no shlibs apparently and has been broken by some soname changes, needs a rebuild and to fix the shlibs issue
[15:40] <Laney> uh, weird
[15:40] <seb128> indeed
[15:40] <asac> mdeslaur: tbird hopefully goes away when building with cairo and not with xft2  .. but i have to verify that. also i have to find out why (if its the case) xft behaves bad for some apps
[15:41] <asac> mdeslaur: most likely its really just bad app code overwriting stuff
[15:41] <asac> mdeslaur: tbird 3 is good
[15:41] <mdeslaur> asac: fun fun fun :P
[15:41] <seb128> Laney: that might be because there is only plugins there and the path need to be added to the shlibs option
[15:41] <seb128> Laney: it shlibs are usually for bin and lib
[15:41] <mdeslaur> asac: sorry for the can of worms :P
[15:42] <seb128> Laney: in fact it uses DEB_DH_SHLIBDEPS_ARGS_ALL += --exclude=/usr/lib/nautilus-sendto/plugins explicitly
[15:43] <seb128> Laney: that's to not have strong depends ... anyway it needs a rebuild then ;-)
[15:43] <mpt> asac, I suggest not taking up the topic with Mozilla until we have API documents ready. (We tried doing that with the Empathy developers, which predictably led to a confused response.) And if asked, say that we'll have API documents ready soon.
[15:48] <asac> mpt: its not my decision
[15:48] <asac> mpt: the topic was opened by others
[15:48] <seb128> mvo: did we have case in previous cycle where gnome-screensaver upgrade where problematic for unlocking?
[15:48] <asac> mpt: and they started to implement stuff
[15:48] <asac> mpt: so we _now_ need to provide input to prevent more resources getting wasted ;)
[15:48] <seb128> mvo: ie 2.24 running and upgrade to 2.26 the unlock dialog will not be showed correctly ... not sure what to do about that
[15:50] <mvo> seb128: we had this in the past, but I'm not sure for what versions
[15:50] <mvo> seb128: we disable the screensaver during upgrades
[15:50] <seb128> mvo: what do you mean?
[15:51] <mvo> hm, I thought we did
[15:51] <seb128> mvo: well, I did lock my screen manually after upgrade
[15:51] <seb128> and had to go back to a vt stop gnome-screensaver to get back to my session
[15:52] <mpt_> asac, what kind of "stuff"? libnotify stuff?
[15:53] <asac> mpt_: yes. i have to tell them that libnotify alone isnt good for messaging.
[15:53] <asac> mpt_: anyway. i can lead the discussion if you dont want to provide input
[15:53] <asac> ;)
[15:53] <asac> i will just give my ideas then. all i will achieve is tell them that we will give more info soon
[15:53] <mpt_> Oh, I want to, it's just a matter of finding time :-P
[15:53] <mpt_> Is there a bug report or somewhere I could post easily?
[15:53] <asac> mpt_: right. i showed you my paste and you didnt saw if its completely wrong or not ;)
[15:54] <mvo> seb128: do we have issues with that?
[15:54] <asac> mpt_: we should channel the input through one channel. its just confusing if multiple folks post different stuff ;)
[15:54] <asac> mpt_: thats why i asked and i will proxy ;)
[15:54] <mpt_> fair enough
[15:54] <asac> but well ... lets wait till beta freeze
[15:55] <seb128> mvo: wb
[15:55] <vuntz> seb128: last ping still valid?
[15:55] <mvo> hrm
[15:55] <mvo> network
[15:55] <mvo> sucks
[15:55] <seb128> vuntz: yes
[15:56] <seb128> vuntz: not sure what I asked but I don't think that was an outdating question ;-)
[15:56] <vuntz> seb128: the item was removed from Places, following a bug report
[15:56] <seb128> vuntz: right, but do you think it's a good decision?
[15:56] <vuntz> seb128: it's mentioned somewhere in the ChangeLog
[15:56] <seb128> just your personnal opinion
[15:56] <vuntz> seb128: I honestly don't care :-)
[15:56] <seb128> I know what happened
[15:56] <seb128> ok
[15:56] <vuntz> I'm fine either way
[15:56] <seb128> vuntz: next question, did you run into the gnome-screensaver issue I described?
[15:57] <vuntz> I don't read everything
[15:57] <vuntz> so I don't know the issue :-)
[15:57] <seb128> vuntz: well now you have 2 items in the menu, one opening the gui and one opening the nautilus location, not very obvious
[15:57] <seb128> vuntz: <seb128> mvo: did we have case in previous cycle where gnome-screensaver upgrade where problematic for unlocking?
 mvo: ie 2.24 running and upgrade to 2.26 the unlock dialog will not be showed correctly ... not sure what to do about that
[15:57] <seb128> vuntz: ie if you lock the screen without having restarted the session you can't unlock
[15:58] <seb128> vuntz: I get it every time, tried several downgrade and upgrades now
[15:58] <vuntz> ah
[15:58] <vuntz> err
[15:58] <vuntz> 2.24 to 2.26 or 2.25.2 to 2.26.0?
[15:59] <seb128> 2.24 to 2.26
[15:59] <seb128> distro upgrade
[15:59] <seb128> I didn't try 2.25 ;-)
[15:59] <vuntz> so I don't know :-)
[15:59] <seb128> ie intrepid to jaunty
[15:59] <seb128> ok
[16:10] <mvo> seb128: we had this in the past, but I'm not sure for what versions
[16:11] <mvo> seb128: I thought we disable the screensaver during upgrades, but I can not find the code for that right now, maybe it got dropped again?
[16:11] <asac> good that slangasek sleeps so long ;)
[16:11] <asac> archive was still open ;)
[16:14] <calc> seb128: i think the screensaver issue happens on 2.25.2 -> 2.26.0 also
[16:15] <calc> seb128: or something caused me to not be able to unlock, i ended up killing the running screensaver and then it let me log back in
[16:15] <seb128> ^ vuntz
[16:16] <seb128> I though jaunty didn't have 2.25.2
[16:16] <calc> er well whatever we had directly prior to 2.26.0
[16:16]  * calc looks in his log
[16:16] <vuntz> seb128: well, blame gnome-screensaver people, I'd say :-)
[16:16] <seb128> calc: https://edge.launchpad.net/ubuntu/+source/gnome-screensaver
[16:16] <vuntz> but I didn't remember seeing this
[16:16] <calc> i upgraded jaunty today in any case and that is when it happened
[16:16] <seb128> vuntz: yeah, I'm doing that next
[16:16] <vuntz> although... I'm not using a screensaver
[16:16] <seb128> vuntz: maybe you restarted your session before locking screen
[16:16] <vuntz> seb128: I don't lock my screen, except when travelling
[16:17] <seb128> me neither
[16:17] <calc> ah ok i am wrong, i think it must have happened between 2.24.0-0ubuntu4 and 5
[16:17] <seb128> I noticed because I did switch to my test user and it locked screen
[16:17] <mvo> poor vuntz, bombarded with questions :)
[16:17]  * calc had just assumed it upgraded to 2.26 along with everything else today
[16:17] <calc> hmm that is really odd the 5 is from last week?
[16:17] <seb128> no I didn't upload 2.26 because of the issue
[16:17] <vuntz> mvo: I'll make seb128 pay, don't worry
[16:18] <seb128> heh!
[16:18] <calc> ok whatever happened when i upgraded today i noticed the issue i hadn't noticed it before today
[16:18] <calc> maybe something screensaver uses library-wise is the culprit?
[16:18] <seb128> vuntz: I will pay, GNOME switching to git, that's like paying every day for things you didn't do
[16:18] <vuntz> mvo: and he's from Alsace, so that's fine...
[16:19] <mvo> haha
[16:19] <mvo> git :(
[16:19]  * mvo weeps
[16:20] <seb128> calc: so you are saying that's an issue in the current jaunty gnome-screensaver version already?
[16:21] <seb128> brb testing
[16:29]  * hyperair likes git
[16:34] <calc> seb128: yea
[16:34] <calc> seb128: after restarting it seems to be ok though
[16:34] <calc> seb128: i did not notice it happening before my upgrade today
[16:35] <calc> seb128: for whatever reason i also had trouble ssh'ing at the time so i thought it might have been some sort of weird pam issue
[16:35] <calc> seb128: i could login to the console (ctl-alt-f1) and also after killing the running screensaver process for the dialog (there were two processes) i could log in via screensaver
[16:38]  * hyperair wonders if anyone here has debian upload privileges and is willing to sponsor my nautilus-share upload to debian (and then sync to ubuntu). this fixes bug #209136
[17:08] <dobey> hyperair: i don't understand that bug
[17:10] <hyperair> dobey: basically nautilus-share uses very dated looking icons
[17:10] <hyperair> like stock GNOME kind of thing
[17:10] <hyperair> something like if you kill gnome-settings-daemon.. that kind of effect
[17:11] <hyperair> dobey: the screenshots show what it _should_ be, not what it _is_
[17:11] <dobey> all the gtk+ stock icons are in the tango style now
[17:11] <hyperair> which is why i didn't understand it at first eitehr
[17:12] <dobey> well, i don't think that the icon /should/ be what that bug report says it should be, but eh
[17:12] <hyperair> dobey: okay, take a look at /usr/share/nautilus-share/pixmaps/something.png (there's only one file and i can't remember the name)
[17:12] <dobey> i don't have it installed
[17:12] <hyperair> dobey: what it _should_ be is gnome-fs-share
[17:12] <hyperair> wait.. lemme upload it somewhere then.
[17:12] <dobey> gnome-fs-share doesn't exist :)
[17:13] <dobey> wel, it's a symlink to folder-remote
[17:13] <dobey> i don't need to see the old icon
[17:13] <dobey> if it was an old ugly icon, that's fine, it obviously needs to be changed
[17:13] <dobey> i'm just saying that i don't think folder-remote is what it should be changed to, as it's not really the right metaphor
[17:15] <dobey> but i don't really have a better suggestion at the moment either
[17:16] <dobey> probably a folder with emblem-shared overlaid would be better
[17:16] <hyperair> dobey: it originally was... stock_shared-by-me for the menu..
[17:16] <hyperair> and a bigger one which is shipped in the tarball
[17:16] <hyperair> for the actual properties dialog
[17:18] <dobey> i don't think that's what stock_shared-by-me was
[17:18] <hyperair> it is
[17:18] <hyperair> the patch says so
[17:18] <mpt_> eeejay, hi, is there common terminology for exposing text for accessibility purposes that isn't visible otherwise?
[17:18] <hyperair> -                                "stock_shared-by-me");
[17:18] <hyperair> +                                "gnome-fs-share");
[17:18] <mpt_> eeejay, i.e. is it called "expose to assistive devices", or something like that?
[17:18] <hyperair> that.
[17:19] <dobey> oh i guess it was, but it's old style
[17:19] <hyperair> originally the patch only had that, so i made a similar change to the .glade file
[17:19] <dobey> hyperair: i'm not saying it didn't use that
[17:19] <dobey> hyperair: if you're going to change it though, you should change it to a correct name
[17:19] <dobey> not gnome-fs-share
[17:19] <hyperair> what's the correct name?
[17:19] <dobey> well, gnome-fs-share is a symlink to folder-remote, which is the name in the icon naming spec
[17:20] <hyperair> hmm seriously?
[17:20] <dobey> but it is the opposite metaphor of 'shared by me'
[17:20] <hyperair> hmm yeah =\
[17:20] <hyperair> but that's what the patch in 0ubuntu7 had.
[17:21] <dobey> sure. sometimes people make incorrect patches, or don't research or ask people who know, what it should be :)
[17:25] <hyperair> alright alright point taken
[17:25] <hyperair> i should go upload -3 to mentors.debian.net now =\
[17:26] <hyperair> and then send out yet another email
[17:26] <hyperair> RFS email
[17:26] <dobey> heh. i need to just say the hell with it, and go rip out all the 'stock' icons from gnome-icon-theme
[17:27] <dobey> and force people to update stuff
[17:27] <hyperair> hmm that won't do =\
[17:27] <hyperair> you'll break every damn thing
[17:28] <hyperair> dobey: actually there are differences between gnome-fs-share and folder-remote
[17:28] <chrisccoulson> tedg - if i get a new message in pidgin, but immediately close the message window without reading it, would you expect the message to disappear from the indicator applet too?
[17:28] <hyperair> it just happens that gnome-icon-theme defaults to using folder-remote
[17:28] <dobey> hyperair: huh?
[17:28] <dobey> differences where?
[17:28] <hyperair> some icon themes make them different =\
[17:28] <hyperair> i just dug though soem of my icon themes
[17:28] <dobey> some icon themes are broken
[17:29] <hyperair> well how sure are you that gnome-fs-share is _supposed_ to be _exactly_ the same as folder-remote?
[17:29] <hyperair> is it documented anywhere?
[17:30] <tedg> chrisccoulson: Hmm, yes.  Does it not?
[17:30] <dobey> gnome-* icons don't exist (unless they are application icons for gnome-foo named applications)
[17:30] <tedg> chrisccoulson: I don't think we're attaching anything to the conversation being destroyed.
[17:30] <chrisccoulson> it doesn't. the message remains in the applet, and then it crashes pidgin when i try to read the already deleted message
[17:30] <dobey> hyperair: i maintain gnome-icon-theme, tango-icon-theme, and the icon naming spec :)
[17:30] <seb128> hey chrisccoulson
[17:30] <chrisccoulson> hi seb128
[17:30] <seb128> chrisccoulson: don't worry about the tracker build issue
[17:30] <chrisccoulson> i was going to ask about that
[17:31] <tedg> chrisccoulson: Okay, have you filed a bug?  I'll fix it :)
[17:31] <seb128> chrisccoulson: it's a soyuz bug they will fix it, new section not available yet
[17:31] <chrisccoulson> thanks seb128:)
[17:31] <seb128> you're welcome
[17:31] <seb128> thanks for the update ;-)
[17:31] <chrisccoulson> tedg - i think i used apport to report it a little while back, but i'll check the latest crash to make sure it's the same trace
[17:31] <chrisccoulson> it's against pidgin
[17:31] <chrisccoulson> seb128 - no problem ;)
[17:33] <chrisccoulson> tedg - bug 340717. i don't think the trace looks that useful though
[17:33] <hyperair> dobey: ah. that adds a whole lot of weight to your words ;)
[17:33] <dobey> hyperair: see the 'Author' part of the icon naming spec ;)
[17:33] <hyperair> um which package?
[17:34] <dobey> http://standards.freedesktop.org/icon-naming-spec/latest.html
[17:34] <hyperair> dobey: so if you're maintainer of gnome-icon-theme.. what's the point of making gnome-fs-share a symlink of folder-remote?
[17:34] <dobey> hyperair: compatibility for older apps that aren't updated to the new names yet
[17:35] <dobey> which is why there are so many symlinks in gnome-icon-theme
[17:35] <hyperair> i see
[17:35] <dobey> development releases default to not enabling the symlinks though
[17:36] <hyperair> hm
[17:36] <dobey> but i don't think anyone ever really sees the results of that
[17:36] <dobey> otherwise there'd probably be a lot more open bugs about icons
[17:36] <hyperair> i see
[17:48] <mpt_> eeejay, I went ahead and did <https://wiki.ubuntu.com/NotifyOSD?action=diff&rev1=105&rev2=103>. You're welcome to correct my terminology if I have it wrong.
[20:18] <hyperair> Laney: the notify-osd problem is caused by gsd not notifying notify-osd upon state-change.
[20:19] <Laney> how come it works for some people?
[20:19] <hyperair> it does?
[20:19] <hyperair> that's surprising.
[20:19] <Laney> yes
[20:19] <Laney> popey has them, for example
[20:19] <Laney> that's how I found out they existed in the first place
[20:19] <hyperair> hmmmm
[20:20] <hyperair> the problem is that the bug encompasses two i should think
[20:20] <hyperair> wait
[20:20] <hyperair> i'm not sure
[20:20] <hyperair> =\
[20:20] <hyperair> we're talking about notify-osd showing the icon of the media key you just pressed right?
[20:21] <hyperair> time to take a peek at gsd patches
[20:25] <crevette> hey
[20:26] <crevette> I remember there is some agreement on the header to set for patch to track what they do, do you have a linkn,
[20:35] <Laney> hyperair: yeah
[20:38] <hyperair> Laney: you're right. it should be in already
[20:38] <hyperair> Laney: either way the buggy code is in notify-osd
[20:38] <hyperair> sorry i meant gsd
[20:39] <Laney> gsd listens for those dbus events?
[20:40] <hyperair> wrong. gsd _generates_ those dbus events
[20:40] <Laney> right
[20:40] <hyperair> gsd is what sits between your xorg's media keys stuff and dbus
[20:40] <Laney> I know
[20:40] <hyperair> banshee and gang connect to gsd via dbus
[20:40] <Laney> and it also is supposed to push a notification?
[20:40] <hyperair> yes
[20:40] <Laney> k
[20:40] <hyperair> if you dget the dsc, you can look at 16_whatever.patch
[20:41] <hyperair> it looks like it pushes the notification...
[20:41] <hyperair> +        NULL, /* "notification-audio-play", */ /* PLAY_KEY */
[20:41] <hyperair> +        NULL, /* "notification-audio-pause",*/ /* PAUSE_KEY */
[20:41] <hyperair> +        "notification-audio-stop", /* STOP_KEY */
[20:41] <hyperair> +        "notification-audio-previous", /* PREVIOUS_KEY */
[20:41] <hyperair> +        "notification-audio-next", /* NEXT_KEY */
[20:41] <hyperair> for the media keys except play/pause
[20:44] <hyperair> but it doesn't handle stop/prev/next for me
[20:44] <hyperair> and the thing is, if it was an icon theme issue, then you should be noticing a blank popup
[20:45] <hyperair> Laney: ^
[20:45] <Laney> well I just get nothing
[20:45] <Laney> why don't you put some debugging traces in to see what gets called and returned?
[20:46] <hyperair> hmm i could try
[20:46] <hyperair> but actually i'm on intrepid
[20:46] <hyperair> with gsd 2.24-x
[20:46] <hyperair> with a backported patch of cuorse
[20:47] <Laney> heh
[20:47] <Laney> you should upgrade :(
[20:47] <hyperair> but intel T_T
[20:47] <Laney> is it that bad?
[20:47] <hyperair> everything 3d except compiz flies out of the window
[20:47] <hyperair> yes it's bad
[20:47] <hyperair> and it only affects some people
[20:47] <hyperair> it might hit only those with agp + intel
[20:47] <hyperair> i'm one of those badly hit
[20:49] <Laney> :(
[20:52]  * Laney cuts Evolution
[20:52] <Laney> it looks nice, but why does everything have to take so long?
[20:52] <hyperair> ?
[20:52] <hyperair> what's long?
[20:52] <chrisccoulson> evolution runs like a dog on my machine
[20:53] <hyperair> evolution frequently hangs on mine
[20:53] <chrisccoulson> when i open it and it loads the mailbox, my machine grinds to a halt for 5 minutes
[20:53] <chrisccoulson> anything that involves any sort of disk activity on my desktop basically stops it from working
[20:53] <Laney> oh, mine's not that bad
[20:53] <Laney> just the application itself
[20:54] <chrisccoulson> mines terrible. the mouse cursor stutters and pauses for several seconds at a time and all the windows fade to gray
[20:54] <Laney> 1 minute+ delay from clicking "Reply" to actually getting a window, message text takes ages to download and so on
[20:54] <Laney> it seems that it queues up a load of network IO and your requests just get shoved at the end
[20:55] <chrisccoulson> my desktop takes nearly a full minute to open a gnome-terminal after i launched evolution
[20:55] <chrisccoulson> ah
[20:55] <chrisccoulson> i have no issues with network IO - mines all disk IO related
[20:55] <hyperair> Laney: gsd is not firing off the required notification stuff
[20:55] <Laney> any idea why?
[20:56] <chrisccoulson> yop shows i get about ~70% iowait on my dual core when doing anything that involves any sort of disk activity
[20:56] <chrisccoulson> and that corresponds to my machine grinding to a halt
[20:56] <Laney> :(
[20:56] <chrisccoulson> yop -> top
[20:56] <chrisccoulson> lol
[20:56] <Laney> Thunderbird may look like arse, but at least it performs well
[20:57] <hyperair> Laney: dunno. i need to figure out my own package first @_@
[20:57] <Laney> hah
[20:57] <hyperair> Laney: i don't know why, but the patch doesn't seem to be in my gsd, yet i'm getting the pretty volume notifications
[20:57] <hyperair> damn weird.
[20:57] <Laney> volume started working with a recent update for me
[20:57] <seb128> chrisccoulson: run sqlite3 .db vacuum to fix that
[20:58] <hyperair> Laney: it's worked for me on my ppa since the day i backported the patch.
[20:58] <hyperair> aha! that's why
[20:58] <hyperair> i was looking in the wrong gnome-settings-daemon directory
[20:58] <hyperair> damn i feel stupid
[20:58] <seb128> chrisccoulson: upstream knows about the issue, that should be fixed for 2.26.1 before jaunty
[20:58] <hyperair> i should git-ify everything
[20:58] <chrisccoulson> seb128 - i'll try that, but i think it might be a short-term fix. i have a general issue with anything disk intensive on this machine, so i can't entirely blame evolution ;)
[20:59] <seb128> chrisccoulson: right but evo tend to do a lot of io after time right now, that helps a lot
[20:59] <chrisccoulson> thanks, i'll give it a go
[20:59] <seb128> chrisccoulson: ie my evolution was hitting disk for 1 minutes on bugmails box before doing that, after it's some seconds
[20:59] <chrisccoulson> probably doesn't help that i have ~60000 unread messages;)
[21:01] <seb128> right, same for my bugmail box
[21:01] <seb128> they are read though
[21:01] <hyperair> hmm
[21:01] <hyperair> the patch is different
[21:01] <seb128> but that should not make a difference ;-)
[21:01] <hyperair> i'll need to backport this patch then
[21:01] <seb128> what are you looking at changing?
[21:02] <Laney> looking into why gsd doesn't send media key notifications
[21:03] <hyperair> Laney: can you do dbus-monitor 'interface=org.freedesktop.Notifications' and then start hitting your prev/next keys
[21:03] <Laney> it only has the ones for track change from Banshee
[21:04] <hyperair> only huh
[21:04] <hyperair> that means it's gsd'd fault
[21:04] <hyperair> how about your eject key
[21:04] <Laney> don't have one
[21:04] <seb128> Laney: ctrl-f9
[21:04] <hyperair> set it to an arbitrary shortcut
[21:04] <Laney> k
[21:05] <Laney> yeah that works
[21:06] <Laney> seb128: Do you have any idea how I can repro this mapi crash without a server available?
[21:06] <Laney> can I install something to set one up easily?
[21:06] <seb128> Laney: no, just do the version update ;-)
[21:06] <Laney> or should I just update and ask the reporters to test
[21:06] <seb128> do that
[21:06] <seb128> that's how we do for exchange bugs
[21:06] <seb128> nobody around has an exchange server
[21:07] <Laney> fair enough
[21:07] <didrocks> hey o/ I am updating evolution-mapi FYI
[21:07] <Laney> oh
[21:07] <Laney> ok!
[21:08] <didrocks> gnome planet is a great ressource ;)
[21:08] <Laney> seb asked me earlier ;)
[21:08] <Laney> but nm
[21:08] <didrocks> ok, sorry, didn't see it
[21:08] <didrocks> you can do it if you wish :)
[21:08] <seb128> didrocks: I though you were in Lyon for the day
[21:08] <Laney> nah, I only got as far as uscan
[21:08] <seb128> lut didrocks
[21:08] <didrocks> (it's already done by my side)
[21:08] <Laney> go for it
[21:09] <didrocks> hello seb128 : yes, but it's just 1h30 from Annecy :)
[21:09] <Laney> I see you french guys have a national strike today
[21:09] <Laney> lazy sods ;)
[21:09] <didrocks> Laney: yes, I saw a lot of people on strike in Lyon :)
[21:11] <didrocks> it builds and installs sucessfully. As last time, I think that nobody have an exchange server around… :/
[21:11] <Laney> yeah, just ask reporter to test it
[21:11] <didrocks> Laney: I wasn't able to test it last time because of that and just uploaded it :/
[21:11] <Laney> or jelmer/andrewsomething
[21:11] <Laney> they did the initial packaging; guess they tested it the
[21:11] <Laney> n
[21:12] <chrisccoulson> seb128 - after vacuuming, evolution opens in a few seconds ;)
[21:12] <chrisccoulson> thanks!
[21:12] <Laney> \o
[21:12]  * hyperair has an exchange account
[21:12] <seb128> chrisccoulson: you're welcome
[21:12] <didrocks> Laney: jelmer asked to a friend IIRC, I asked him to do this before I sponsored it ;)
[21:12] <hyperair> what's this mapi crashabout?
[21:12] <Laney> I'm letting it filter and process all new mail
[21:12] <Laney> to see if it gets faster after this
[21:13] <Laney> hyperair: it crashes after you authenticate
[21:13] <hyperair> without fail?
[21:13] <Laney> sounds like it
[21:13] <Laney> at least for the reporter
[21:13] <Laney> nobody files bugs when it works ;)
[21:13] <seb128> does gnome-sound-properties start for everybody there?
[21:13] <Laney> yep
[21:14] <didrocks> hyperair: I can make it available to my ppa if you wish. It fixes http://bugzilla.gnome.org/show_bug.cgi?id=574784
[21:14] <didrocks> seb128: for me, it's ok
[21:14] <seb128> for me too
[21:14] <hyperair> didrocks: i'm on intrepid =\
[21:14] <seb128> we just got some bugs about the mixer and that one not opening now
[21:15] <hyperair> Laney: what happens when you do the eject key test thing again?
[21:15] <Laney> hyperair: It ejects and I see the notification
[21:15] <didrocks> strange, does he use virtualbox? (no sound in it)
[21:15] <hyperair> Laney: strange, you actually see that notification?
[21:15] <hyperair> mine shows a big eject logo
[21:15] <Laney> sure
[21:15] <hyperair> traditional style
[21:15] <hyperair> =\
[21:15] <Laney> heh
[21:15] <Laney> you crazy backporting foo'
[21:15] <hyperair> looks like i've got additional problems
[21:15]  * hyperair sighs
[21:16] <hyperair> i have to check my notify-osd package again
[21:16] <chrisccoulson> seb128 - what are your thoughts on the nautilus auto-restarting issue? upstream seem to be fairly quiet about this. i had a look at it this evening and it looks fairly difficult to fix
[21:16] <hyperair> hey somebody had to do it
[21:16] <seb128> chrisccoulson: I think we should set the autorestart to false if they don't fix it and let user who have a crash restartit
[21:16] <seb128> it's easy enough to open a place for example
[21:17] <chrisccoulson> that might be a safe compromise for now
[21:18] <chrisccoulson> intrepid didn't have the Autorestart key. it relied on setting the restartstyle hint with GnomeClient to a state dependant on whether it was drawing the desktop or not
[21:18] <hyperair> #$%^ why do they change the damn capabilities strings EVERY SINGLE RELEASE?!
[21:18] <hyperair> damn fickle pricks
[21:18] <chrisccoulson> i looked at the possibility of doing the same with eggsmclient, but it doesn't appear to have the features for this
[21:18] <hyperair> every single patch has to be updated everytime there's a new release
[21:19] <chrisccoulson> it seems that eggsmclient only lets you set the restartstyle hint before connecting to the session manager
[21:22] <seb128> chrisccoulson: right
[21:23] <seb128> that's a known limitation, the bug fix would be to add the api to allow changing dynamically that value
[21:23] <chrisccoulson> yeah, that would be nice
[21:23] <chrisccoulson> probably a bit too late for this cycle though?
[21:23] <seb128> not sure, better to ask to vuntz
[21:23] <seb128> I would not bother for jaunty and just unset the autostart I think
[21:23] <vuntz> vuntz is in a meeting :-)
[21:24] <seb128> vuntz: ;-)
[21:24] <seb128> what notify-osd capability changed this time?
[21:24] <seb128> they were supposed to have support for old and new naming in this version to make updates easier
[21:24] <seb128> "    - Add compatibility checks to ease transition period for applications to
[21:24] <seb128>       pick up the capability  and hint name changes. (LP: #343553)"
[21:32] <hyperair> Laney: this is seriously weird. i'm getting the next icon when  ipress prev.
[21:32] <hyperair> and nothing when i press next
[21:32] <Laney> haha
[21:32] <Laney> well that's a start, right? ¬_¬
[21:33] <hyperair>    uint32 0
[21:33] <hyperair>    string "notification-audio-next"
[21:33] <hyperair>    string "Previous"
[21:33] <hyperair>    string ""
[21:33] <hyperair> very interesting
[21:34] <hyperair> we're probably seeing some skewed enum or something
[21:37] <hyperair> aha
[21:37] <hyperair> that's right
[21:37] <hyperair> pressing stop gives me.... previous
[21:38] <hyperair> okay, what do enums start with?
[21:38] <hyperair> 0 or 1?
[21:38] <hyperair> oh wait a sec
[21:38] <hyperair> i've an idea
[21:38] <dobey> does everyone else get some type of useful notification that updates are available in jaunty?
[21:39] <seb128> dobey: define useful notification?
[21:40] <dobey> seb128: i ran apt-get update, and there are a crapload of updates available, but there's no tray icon or anything. i'm having to run apt-get upgrade, or update-manager by hand to install them
[21:40] <seb128> yes, that's the expected behaviour
[21:40] <seb128> update-manager auto-opens once a week for normal updates now
[21:40] <dobey> how am i supposed to know when updates are available?
[21:40] <seb128> and once a day for security updates
[21:41] <dobey> ugh
[21:41] <Laney> when it auto-opens :(
[21:41] <seb128> dsign team decided that user are not upgrade maniacs
[21:41] <dobey> not all of them, sure
[21:41] <seb128> and that once a week for standard updates will do
[21:41] <seb128> you can turn the gconf key to have the old behaviour back if you want
[21:41] <dobey> what gconf key?
[21:42] <seb128> I think it's /apps/update-notifier/auto_launch
[21:42] <hyperair> Laney: do you seriously get a notify-osd popup for eject?
[21:43] <Laney> rofl
[21:43] <Laney> I'm not lying to you :(
[21:43] <dobey> yay
[21:43] <dobey> seb128: thanks, that is much better
[21:43] <hyperair> very strange..
[21:43] <seb128> Laney: maybe you didn't restart something recently
[21:43] <seb128> I don't
[21:43] <seb128> that was working some days ago though
[21:43] <Laney> well I didn't restart after today's updates
[21:43] <seb128> you might still be running the old g-s-d or something
[21:43] <Laney> I'll do that though now
[21:44] <Laney> brb
[21:47] <hyperair> Laney: could you do the dbus-monitor thing with eject?
[21:48] <seb128> nothing is sent
[21:49] <Laney> hyperair: It's broken now since I rebooted :)
[21:49] <hyperair> loool
[21:49] <hyperair> i knew it
[21:49] <Laney> hahaha
[21:49] <hyperair> staring down the patch showed that eject was unhandled
[21:49] <hyperair> so i just couldn't imagine why you had it working
[21:50] <hyperair> now the very strange thing is that the enums seem to magically start from 1.
[21:56] <seb128> eject was working 2 days ago when I sponsored 2.25.92-0ubuntu2
[22:01] <seb128> the previous and next actions are working fine here
[22:01] <seb128> only eject is not
[22:04] <chrisccoulson> seb128 - just looking at the g-s-d patch. in gsd_media_keys_notification(), there is this line:
[22:04] <chrisccoulson>  if (media_key_icon[key] == NULL) return FALSE
[22:04] <chrisccoulson> EJECT_KEY is false
[22:04] <chrisccoulson> **NULL even
[22:04] <chrisccoulson> d-oh
[22:04] <seb128> right, I could swear I've seen it working though
[22:04] <chrisccoulson> it did used to work
[22:05] <Laney> why was it disabled?
[22:05] <seb128> it was not
[22:05] <seb128> they just don't have an icon for it apparently or something
[22:06]  * Laney wonders what he saw earlier
[22:06] <seb128> well it was working
[22:06] <seb128> the code changed though
[22:06] <chrisccoulson> that's right - media_key_icon[EJECT_KEY] is definately NULL
[22:06] <chrisccoulson> and the function just returns because of that
[22:06] <chrisccoulson> the code did change quite a bit since the last release
[22:07] <seb128> chrisccoulson: well
[22:07] <seb128> +static const char *media_key_icon[] = {
[22:07] <Laney> woah
[22:07] <seb128> NULL
[22:07] <seb128> NULL
[22:07] <seb128> NULL
[22:07] <seb128> etc
[22:07] <chrisccoulson> yep;)
[22:07] <seb128> I think they used the standard icon before
[22:07] <chrisccoulson> only stop, forward and back are populated
[22:07] <Laney> hyperair: I, er, have next/prev notifications now
[22:07] <seb128> but they changed notify-osd to use better defined icons
[22:07] <seb128> and they don't have one for eject
[22:07] <hyperair> Laney: makes sense. i just figured out where i missed out
[22:07] <hyperair> XRANDR_KEY was taken out between 2.24 -> 2.26
[22:07] <Laney> that magical restart fixed it all
[22:08] <hyperair> you should havek illed gnome-settings-daemon =\
[22:08] <Laney> didn't know it got an update
[22:08] <Laney> know or check tbh
[22:08] <seb128> they have notification-device-eject.svg
[22:08]  * seb128 tries to use that in the enum now
[22:10]  * Laney misses play/pause too
[22:10] <seb128> right it's not in the enum either
[22:10] <Laney> yeah
[22:10] <chrisccoulson> there's no icon for pause
[22:10] <chrisccoulson> probably why both play/pause are disabled
[22:11] <chrisccoulson> would look odd seeing a notification for play but not for pause
[22:11] <hyperair> chrisccoulson: actually i noticed my play/pause button triggering PLAY_KEY
[22:11] <hyperair> or something
[22:11] <hyperair> chrisccoulson: which means that should be a play/pause icon instead of just play
[22:11] <chrisccoulson> possibly
[22:12] <seb128> right
[22:13] <hyperair> but yeah you should fix eject
[22:13] <hyperair> it was working before the update
[22:13] <hyperair> the previous patch worked with eject
[22:14] <seb128> right, it's just a matter to add the icon name in the enum, easy enough
[22:14] <chrisccoulson> that's good:)
[22:17] <Laney> hm
[22:17] <Laney> having looked at the Human icons, I feel like I'm missing out now :(
[22:17] <seb128> Laney: dpkg -L notify-osd?
[22:17] <Laney> seb128: There seems to be more in /usr/share/icons/Human/scalable/status/
[22:18] <seb128> we don't want theme specific icons though
[22:18] <chrisccoulson> Laney - i'm not using human icons, but i created symlinks in the icon theme I use so i get all the notifications in my preferred theme
[22:18] <chrisccoulson> it looks really neat
[22:18] <Laney> so you get the "human" icons in your regular theme?
[22:18] <seb128> chrisccoulson: the notify-osd icons are in hicolor, should be used in any theme
[22:19] <chrisccoulson> i get all the notifications in my regular theme rather than the ones in hicolor
[22:19] <Laney> seb128: "This is a set of fallback icons for Gnome. Canonical icons are in the Human icon theme."
[22:19] <Laney> from the README
[22:20] <seb128> oh ok
[22:20] <seb128> didn't know ;-)
[22:20] <hyperair> ?
[22:20] <seb128> eject is working now
[22:20] <hyperair> Laney: are you sure that's right?
[22:20] <Laney> sure what's right?
[22:20] <hyperair> i remember i was making noise about icons being in human
[22:20] <hyperair> and then they shifted it all to notify-osd instead
[22:20] <Laney> there are different icons in Human
[22:20] <hyperair> so now it's sitting in notify-osd =\
[22:20] <hyperair> there are?
[22:20] <Laney> and then some fallback ones there
[22:21] <chrisccoulson> the nice ones are in Human, and the fallback ones ship with notify-osd for those of us not using Human, or a theme that ships its own icons
[22:21] <hyperair> either way, you should just make your icon theme depend on human instead of symlinking =p
[22:21] <hyperair> there's a Depends line somewhre at the top of the index.theme file
[22:22] <hyperair> i think i'm seeing the human ones
[22:22] <chrisccoulson> hyperair - i didn't symlink to human. i symlinked within the theme i use so i get the icons in my native theme;)
[22:23] <chrisccoulson> http://ubuntuforums.org/attachment.php?attachmentid=105750&d=1236531402
[22:23] <hyperair> aah
[22:23] <hyperair> cool =p
[22:23] <hyperair> chrisccoulson: what are the original icon names?
[22:24] <chrisccoulson> it depends what theme you use. i just searched in the theme until i found ones that looked correct;)
[22:24] <hyperair> lol
[22:25] <chrisccoulson> i also did it for the indicator-applet icons too
[22:25] <chrisccoulson> although the indicator applet still doesn't do very much for me :/
[22:26]  * Laney installs Jaunty on his Macbook
[22:34] <seb128> gnome-settings-daemon with eject action icon uploaded
[22:34] <seb128> I didn't add the play one because of the lack of pause icon for now
[22:35] <Laney> \o/
[22:35] <Laney> erk, Jaunty live CD counts down to autologin now
[22:36] <seb128> you are the second user to report that this week
[22:36] <Laney> is there a bug?
[22:36] <seb128> I was assuming that xorg or gdm or gnome-session was crashing for mpt and bringing it back to gdm
[22:36] <seb128> ask on #ubuntu-devel maybe, I don't know
[22:36] <Laney> ok
[22:44] <hyperair> woo the sun is rising
[22:44] <hyperair> time for me to go to bed
[22:45] <seb128> 'night
[22:46] <asac> seb128: what kind of abi guarantees do exist for _gtk symbols? no guarantee at all?
[22:46] <hyperair> night
[22:47] <asac> sleep well hyperair
[22:47] <seb128> asac: what _gtk symbols?
[22:47] <dobey> asac: the private _gtk symbols that are listed in some headers?
[22:47] <dobey> asac: they will have to always be there for gtk+ 2.x if they are publically exposed
[22:47] <hyperair> asac: thanks. by the way, what about bug #248705 ? =p
[22:48] <seb128> asac:
[22:48] <seb128> $ nm -D /usr/lib/libgtk-x11-2.0.so | grep _gtk
[22:48] <seb128> 000e5130 T hildon_gtk_file_chooser_install_properties
[22:48] <asac> seb128: those exported in headers
[22:48] <seb128> asac: any example?
[22:48] <asac> seb128: but for internal use:
[22:48] <asac> seb128: look in gtkmodules.h
[22:48] <seb128> oh, those, no guaranty
[22:48] <asac> seb128: good ;)
[22:48] <seb128> ie they rewrote the fileselector and that broke hildonfm which was using that for example
[22:48] <asac> seb128: except the callbacks of course
[22:49] <asac> i reawlly just ment tose  _gtk symbols
[22:49] <asac> also wonder why we export those in headers at all
[22:49] <asac> seb128: as you showed they are even not exported ;)
[22:49] <seb128> in the fileselector case that was to write backends
[22:49] <seb128> only libgnomeui was using that for the gnomevfs backend
[22:49] <asac> seb128: so what libs are using those now?
[22:49] <seb128> not sure in your case
[22:49] <NetSkay> ello
[22:49] <asac> seb128: i mean they are not even exported anymore in the lib
[22:50] <asac> seb128: so they shouldnt be used anywhere except in gtk
[22:50] <NetSkay> someone willing to help poor fellow lnx user with openVPN :D
[22:50] <seb128> asac: the fileselector ones? none, they dropped all that since they have gio in glib and don't need backends now
[22:50] <asac> seb128: no ... i mean those gtkmodules things
[22:50] <seb128> NetSkay: -> #ubuntu
[22:50] <asac> but well
[22:50] <asac> i guess the answer is: they are not exported ;)
[22:50] <seb128> asac: I don't know about those sorry
[22:50] <seb128> or not sorry, I just don't know ;-)
[22:51] <seb128> but yeah, don't use private thigns
[22:51] <seb128> that's going to bite you
[22:51] <asac> seb128: thats ok. i was just hacking around and thought about changing one of those, when i discovered that they are in a exported header
[22:51] <asac> in code those "_gtk" things really looked like: not exported, nowhere used outside of gtk ;)
[22:51] <seb128> could be used for theme engines
[22:52] <asac> seb128: but even if those symbols are not even exported. sounds unlikely
[22:52] <asac> only static linking could allow access to them i guess
[22:52] <asac> but anyway
[22:53] <asac> i will see if i can find someone in #gtk+ or sommething
[22:53] <asac> maybe tim knows ;)
[22:53] <seb128> asac: ask bratsche maybe
[22:54] <asac> bratsche: ^^ _gtk symbols in gtkmodules.h ... why are they exported in a public header, but then not even visible in .so ?
[22:54] <asac> bratsche: is it a bug that they are in a public header at all?
[22:54] <asac> or is that best practice for gtk?
[23:01] <bratsche> asac: Hang on, let me take a look.  Not sure if I know the answer but let me look really quick..
[23:02] <asac> bratsche: just look in the header ... the _gtk symbols really look private and even are commented as such. then they are not in nm -D /...gtk-x11...
[23:02] <asac> thanks
[23:03] <asac> seb128: so what damage about font sizes was reported on top of terminal, thunderbird ... ?
[23:03] <asac> did you get anything else?
[23:03] <bratsche> asac: That does seem like it should be a bug to me as well.
[23:03] <asac> bratsche: ok great.
[23:04] <asac> bratsche: i just was confused when i saw the header getting exported
[23:04] <bratsche> Then again, I didn't realize gtkprivate.h was an installed .h file either.  I was about to say maybe these should go there.
[23:04] <seb128> asac: some users complained about pidgin I think
[23:05] <asac> seb128: ok. a bit change is ok and expected. if they claim huge differences i would like to know
[23:06]  * asac starts pidgin
[23:06] <seb128> asac: not that I know but I will keep an eye on such reports and let you know
[23:06] <asac> so widgets look good here
[23:06] <asac> seb128: great.
[23:06] <bratsche> asac: I'll ask Matthias or someone about this tomorrow.  Now I'm curious.
[23:06] <asac> seb128: terminal turned out to be a code bug. they always converted to point base without even properly recalcuating leading to a size boost
[23:10] <calc> why can't i turn on use burnproof in brasero?
[23:10] <calc> its greyed out
[23:10] <calc> my drive supports it
[23:19] <asac_> what does evolution use to display mail body content? is that a gtk widget? or something custom?
[23:20] <bratsche> gtkhtml2 or gtkhtml3 or something like that.
[23:20] <bratsche> I forget the version.
[23:20] <asac_> does that live outside of gtk tree?
[23:20] <bratsche> Yes.
[23:20] <asac_> e.g. independent project?
[23:20] <asac_> ah
[23:20] <asac_> lets see if there is a bzr-mirror.gnome.org thing for it
[23:21] <seb128> asac_: gtkhtml3
[23:21] <bratsche> If you saw srag's blog post yesterday of the new Evolution-based mail client aimed at netbooks, they're using GtkWebkit for that.
[23:21] <seb128> asac_: source is gtkhtml3.14
[23:21] <bratsche> But Evolution itself has been stuck on gtkhtml3 for awhile
[23:21] <asac_> seb128: hmm. there is gtkhtml2 and gtkhtml
[23:21] <seb128> asac_: they plan to allow webkit for rendering in the next cycle but probably not for the editor
[23:21] <seb128> asac_: it's gtkhtml then
[23:22] <seb128> gtkhtml2 is libgtkhtml in ubuntu
[23:22] <bratsche> seb128: Not for editing?  I thought webkit supported that finally?
[23:22] <seb128> asac_: speaking about webkit did you ask about webkit 1.1?
[23:22] <asac_> seb128: gwibber folks dont know how to fix it
[23:22] <asac_> seb128: i asked them to investigate
[23:22] <asac_> so lets give them a few more day
[23:23] <asac_> seems webkit would break it completely
[23:23] <asac_> not sure whats the problem. maybe will try on my own if there is no progress
[23:23] <seb128> bratsche: well srag said he has webkit rendering code (he did it for the the netbook software) but not for editing
[23:23] <bratsche> Oh, bummer.
[23:23] <bratsche> I missed that part I guess.
[23:25] <asac> too bad that bzr-playground.gnome.org will probably go away when there is git
[23:25] <asac> thats working so nice ;)
[23:29] <seb128> bratsche:
	is that just for email display or you think you can get a working composer by then too?
	mbarnes, only for display :-)
	dont even think of it for composer for Evo.. its early
[23:30] <seb128> bratsche: that was the after meeting from this week
[23:30] <bratsche> Ah, okay.
[23:32] <calc> http://people.ubuntu.com/~brian/complete-graphs/openoffice.org/plots/openoffice.org-1day-new.png
[23:33] <calc> just fell off the cliff :)
[23:34] <rickspencer3> check that OUT!!!!
[23:34] <rickspencer3> calc: you rocked the OO bug list down to zero!
[23:35] <rickspencer3> unheard of
[23:35] <calc> currently my upstream bug report numbers are 88.79% 86.21% 89.16% (working on the upstream linkage tomorrow)
[23:35] <seb128> how responsive is upstream to bugs for openoffice?
[23:36] <seb128> got alex to fix the ctrl-l ssh... mount error in gvfs today btw
[23:36] <calc> seb128: sometimes very fast other times just ignores them
[23:36] <calc> seb128: cool! :)
[23:36] <calc> seb128: i have to test every bug though because they get upset if i send them unverified bugs, esp since we use ooo-build
[23:37] <rickspencer3> way to calc!
[23:37] <rickspencer3> congrats
[23:39] <calc> rickspencer3: thanks :)


[00:39] <valorie> http://pastebin.kde.org/pdtbrlrdb
[00:43] <valorie> gotta go, but i'll look for hints for what I did wrong/forgot
[01:04] <claydoh> Mamarok: sorry for the delay, just finishing a vacation. I can't find the email in question, but a note to him might be advisable.
[01:04]  * claydoh catches up on the list
[01:09]  * claydoh needs to get back into the swing of things
[01:13]  * jalcine wants to get into the swing of things
[01:35] <ahoneybun> hey valorie
[01:35] <ahoneybun> oh
[04:11] <manchicken> apachelogger: Thanks for the help
[04:18] <manchicken> apachelogger: I've got a working build again, now I'm just chasing down a series of crashes. The scenario you found a while back when you cancel immediately after starting the program is still happening, and I'm having all sorts of fun chasing it around.
[04:20] <ScottK> debfx: Just import the latest.
[05:16] <claydoh> Mamarok: perhaps the basil situation has cleared itself ? I don't think that we should worry about chatter of other distros, for example they do discuss us in  the english opensuse list, not necessarily in a negative fashion.
[05:20] <claydoh> That thread was far too confusing, I think I could have summed it up in a short, clear paragraph lol
[06:54] <Mamarok> claydoh: well, it did not, as this idiot now makes a mess about it
[06:56] <claydoh> Mamarok: "Bas, I can see that Felix has offered his expertise to help you out with
[06:56] <claydoh> your requirements so I will let him do just that if that's all right
[06:56] <claydoh> with you."
[06:56] <Mamarok> read all the mails, including those to -owner...
[06:56] <claydoh> bas = bas roufs, not basil chupin, that part confused me for  a sec
[06:57] <Mamarok> I did send him a private mail with copy to -owner, which only we moderators receive, but he managed to think this was a public mail and sent a copy of it to the list
[06:57] <Mamarok> *headdesk*
[06:58] <claydoh> Oh, well it's done for the time being.
[06:59] <claydoh> and to think I may in the future move to Australia and be in clser proximity to him
[07:00] <Mamarok> you may? Interesting :)
[07:01] <claydoh> a redhead is involved :D
[07:03] <claydoh> she just went back from a visit here, now to save for a trip there
[07:07] <Mamarok> congratulations in order?
[07:26] <claydoh> Mamarok: not yet, still have to scrape money up to finally get the divorce. The Ex left, but doesn't want to foot any bills lol
[08:06] <lordievader> Good morning.
[08:44] <benvantende> morning people
[08:56] <Peace-> guys i have a very big problem with usb
[08:56] <Peace-> they work for some time then they are dead
[08:56] <Peace-> #kernel ?
[09:04] <Peace-> reboot
[10:21] <apachelogger> oh right
[10:21] <apachelogger> Riddell, shadeslayer, ScottK: so ... yay or nay to the mail?
[10:22] <apachelogger> also I remembered that we shoudl slap a thread on kubuntuforums
[10:35] <Riddell> apachelogger: yay
[12:20] <BluesKaj> 'Morning all
[13:59] <shadeslayer> apachelogger: looks good to me
[14:02] <shadeslayer> Riddell: and it's fine for GPL code to depend on a package that is LGPL and links to openssl?
[14:02] <shadeslayer> ( GPL code doesn't link to openssl code )
[14:03] <Riddell> shadeslayer: hmm, maybe not
[14:03] <Riddell> what's the case?
[14:03] <shadeslayer> see ktp mailing list
[14:04] <shadeslayer> auth handler needs qca2 + ssl plugin
[14:04] <apachelogger> *plugin*
[14:05] <apachelogger> if $thing works without $plugin then there is no license tie between $thing and $plugin
[14:07] <apachelogger> $thing *linking* against $plugin *linking* against openssl, $thing would not work without openssl thus there is a license tie
[14:07] <shadeslayer> https://mail.kde.org/pipermail/kde-telepathy/2013-November/010409.html
[14:07] <Riddell> yes (as long as you can argue it's not a derived work)
[14:08] <apachelogger> ^ it's definitely not derived as long as A works without B, B is however a derived work of A when B is a plugin for A
[14:10] <apachelogger> if B is not a plugin for A there's also not tie there (e.g. when A would dlopen B and manually resolve symbols - as long as A still works without B)
[14:10] <apachelogger> really the question you have to ask is "does A work without B"
[14:17] <shadeslayer> As documented by the thread, A does not work without B
[14:17] <shadeslayer> causes crashes
[14:18] <apachelogger> claydoh: http://www.kubuntuforums.net/showthread.php?64098-Installing-Kubuntu-13-10-on-UEFI-SecureBoot-Systems you may want to sticky that or something
[14:20] <apachelogger> shadeslayer: well, depends on why it crashes
[14:20] <apachelogger> but if it crashes because it tries to load the plugin and can't find it then one could very likely argue for dervied work
[14:21] <d_ed> hey, I was summoned?
[14:21] <shadeslayer> yep
[14:21] <apachelogger> if it however crashes because there simply is no plugin then it's rather hard to argue for dervied work
[14:22] <apachelogger> d_ed: why does qca make apps crash without the openssl plugin?
[14:22] <apachelogger> is it because it must find it or because there is no plugin in general
[14:22] <d_ed> if you ever call QCA::fromDER() it explodes.
[14:22] <shadeslayer> d_ed: I wish I had detachable ears
[14:22] <d_ed> we have a runtime guard from 0.6.3 onwards
[14:23] <d_ed> but then it will just not work instead of crashing
[14:23] <d_ed> which isn't exactly better
[14:24] <apachelogger> d_ed: what's the bt though
[14:26] <d_ed> https://bugs.kde.org/show_bug.cgi?id=326948
[14:29] <apachelogger> creepy codez
[14:30] <apachelogger> d_ed: that seems like a bug in qca though ;)
[14:30] <d_ed> well... part of the code it's using is missing.
[14:30] <apachelogger> shadeslayer: no derived work ... it crashes because it has no keycontext provider, not specifically because it has no openssl plugin
[14:32] <shadeslayer> 'keycontext provider" ?
[14:32] <apachelogger> plugin interface type it appears
[14:33] <apachelogger> if I write a plugin that implements a keycontext it would not crash
[14:33] <apachelogger> so it is not derived work of openssl
[14:34] <apachelogger> it is however badly written code because it crashes :P
[14:35] <d_ed> well, I want it to stop crashing.
[14:37] <shadeslayer> and it seems like a run time dependency to me, so I'm curious as to whether or not we can add it to Recommends
[14:37] <d_ed> or the depends.
[14:37] <d_ed> because it depends on it to run
[14:39] <apachelogger> d_ed: that's a bug IMO
[14:39] <apachelogger> shadeslayer: recommends probably is an option
[14:39] <apachelogger> OTOH
[14:40] <apachelogger> there are more pluing interfaces than that one so recommends may be excessive from a QCA pov
[14:40] <apachelogger> i.e. if you don't need the key interface rubbish you don't need openssl specifically
[14:41] <apachelogger> it's as if libphonon recommended libphononqml
[14:41] <apachelogger> well not really, but equally excessive :P
[14:41] <apachelogger> shadeslayer: IMHO the recommends ought to be on auth-handler
[14:41] <apachelogger> in fact there it can be a depends
[14:41] <shadeslayer> that's what I'm proposing
[14:41] <apachelogger> ah, I thought for QCA
[14:41] <shadeslayer> but I was unsure of the legalese
[14:42] <shadeslayer> no, see my original question
[14:42] <shadeslayer> GPL code depends on LGPL package that depends on openssl
[14:42] <apachelogger> packaging has no implications on legal here :P
[14:42] <apachelogger> shadeslayer: no it doesn't
[14:42] <shadeslayer> okay
[14:42] <Riddell> Mamarok: anything I need to do with this pesky Basil chap?
[14:43] <apachelogger> if there wasn't a bug in QCA it would not crash, so ktp would not crash so there is no argument for dervied work
[14:43] <apachelogger> ktp doesn't specifically require openssl
[14:43] <shadeslayer> right
[14:43] <apachelogger> it requires a QCA plugin that implements the keycontext plugin such that fromDER does something useful
[14:44] <d_ed> and is there anything apart from openssl that actually does that?
[14:44] <apachelogger> whether that plugin is openssl or mylittlepony doesn't matter to KTP
[14:44] <apachelogger> d_ed: dunno, from a legal pov it doesn't matter though
[14:44] <d_ed> as I understand it, it's like us depending on phonon - but only phonon-gstreamer existing..with no-one pulling it in.
[14:44] <apachelogger> d_ed: if you had no phonon backend you would still work
[14:45] <apachelogger> you would not produce sound or whatever
[14:45] <apachelogger> but you would not crash
[14:45] <apachelogger> so not a derived work
[14:45] <Mamarok> Riddell: no, I hope he understood the problem by now...
[14:46] <apachelogger> d_ed: but as I said, ktp-auth depending/recommending openssl is fine because of the status quo that you *want* it so that the user is happy
[14:46] <apachelogger> you don't actually *need* it to work
[14:51] <Riddell> Mamarok: thanks for handling it
[14:51] <Mamarok> Riddell: that's the least I can do :)
[14:52] <shadeslayer> apachelogger: which is why I was saying a recommends will be fine as well?
[14:53] <apachelogger> yeah well
[14:53] <apachelogger> I'd go depends TBH
[14:53] <shadeslayer> fine with me either way
[14:54] <apachelogger> supposedly there is no GUI message explaining why a feature does not behave as expected by the user, so I'd simply avoid that alltogether
[14:55] <gnumdk> Is there any reason kubuntu ship an older version of phonon?
[14:55] <shadeslayer> d_ed: Canon Rock
[14:59] <Riddell> gnumdk: it ships 4.6.0 which was the newest version when we released
[15:00] <gnumdk> ok
[15:01] <gnumdk> Cool :)
[15:01] <gnumdk> Because 4.7 is broken with pulseaudio :)
[15:01] <gnumdk> Backporting to 4.6 on arch fix my issue, going to report bug
[15:04] <apachelogger> gnumdk: what be the issue?
[15:05] <gnumdk> volume isn't changed
[15:05] <gnumdk> from amarok or dragonplayer
[15:05] <apachelogger> you have to update phonon-gstreamer/phonon-vlc as well
[15:06] <gnumdk> https://bugs.kde.org/show_bug.cgi?id=327279
[15:07] <gnumdk> apachelogger: using ArchLinux so up to date ;) As i was sure Kubuntu was not broken, i tried to downgrade phonon
[15:31] <lordievader> Good afternoon.
[16:46] <shadeslayer> Riddell: ScottK ktp-auth-handler awaiting approval in the SRU queue
[16:49] <shadeslayer> bug 1249014
[17:39] <Riddell> shadeslayer: Test Case TBD?
[17:41] <shadeslayer> Riddell: yes, waiting on d_ed
[17:42] <shadeslayer> ktp contactlist still connects without the ssl plugin
[17:42] <shadeslayer> though it should throw a warning dialog
[17:57]  * Riddell wanders off to barcelona
[18:01] <shadeslayer> Riddell: :D
[18:26] <ovidiu-florin> how does the kubuntu packaging take place?
[18:44] <shadeslayer> magically?
[18:45] <shadeslayer> yofel: should I run the script for 4.12
[18:45] <shadeslayer> or do we want to merge thingums from debian first
[18:46] <yofel> shadeslayer: well, apachelogger and me talked about it yesterday and pretty much decided not to *merge*
[18:46] <yofel> we can look for packaging fixes later
[18:46] <shadeslayer> cool
[18:46] <shadeslayer> running scripty then
[18:46] <yofel> so go ahead
[18:47] <shadeslayer> it's not funny how muon has very obvious bugs
[18:47] <shadeslayer> for eg. the package states are flags everywhere except in muonstrings.cpp where it's treated as a enum causing weird issues in the ui
[18:48] <shadeslayer> then someone forgot to document the Package::Held enum as a string
[18:48] <shadeslayer> causing empty strings in the dialog that shows you what's going to be committed
[18:51] <shadeslayer> yofel: which files does one usually copy for a new release?
[18:52] <shadeslayer> kdesc-packages-foo and kdesc-dev-latest-foo ?
[18:52] <yofel> kde-sc-dev-latest-saucy.txt, you generate kdesc-packages-trusty.txt with kdesc-package-names
[18:53] <shadeslayer> cool
[19:05] <shadeslayer> :S
[19:05] <shadeslayer> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/libkomparediff2/".
[19:06] <shadeslayer> we should make kubuntu-initial-upload gracefully fail for new packages
[19:27] <shadeslayer> yofel: fwiw I see alot of debcommit: unable to determine commit message using bzr
[19:27] <shadeslayer> Try using the -m flag.
[19:28] <shadeslayer> okay, I have to leave
[19:29] <shadeslayer> yofel: plz be running the script :)
[20:29] <ahoneybun> hello
[21:53] <kubotu> ::qt-bugs:: [1249094] qt4-designer segfaults in QMetaObject::indexOfSignal @ https://bugs.launchpad.net/bugs/1249094 (by SimonW)


[02:39] <mup> PR operator#501 opened: Make get_services() return mapping; add ServiceInfo.is_running <Created by benhoyt> <https://github.com/canonical/operator/pull/501>
[15:44] <mup> PR operator#502 opened: A pair of Provider and Consumer utility objects <Created by balbirthomas> <https://github.com/canonical/operator/pull/502>
[23:36] <mup> Issue operator#494 closed: is_running() method for services <Created by martinrusev> <Closed by benhoyt> <https://github.com/canonical/operator/issues/494>
[23:36] <mup> PR operator#501 closed: Make get_services() return mapping; add ServiceInfo.is_running <Created by benhoyt> <Merged by benhoyt> <https://github.com/canonical/operator/pull/501>


[02:05] <uRock> Good night, sleep tight, dream of fixed bugs tonight!
[06:44] <anek> tell me keyboard tray icon app that just works and can into per-window or per-application layout
[06:46] <guiverc> anek, I'm not sure what you're asking for
[06:46] <anek> something like xxkb
[06:47] <anek> fcitx doesn't work with Telegram
[06:47] <anek> 19.04
[06:50] <guiverc> i just tested `onboard` and it works with telegram on my 19.10 system
[06:51] <anek> keyboard layout indicator
[06:51] <anek> will test gxkb now
[06:52] <guiverc> okay i misunderstood, I was thinking virtual keyboard
[06:54] <guiverc> kbindicator works on my system (19.10, no 19.04 up to test on sorry) as a keyboard indicator
[10:45] <Guest_0234> Hi. every distro  i tried gives me 3-6 min boot and loginn time. The only exception is lubuntu 16.04 which im currently running. I tried upgrading it and clean install but without any success. What could be the problem?
[12:14] <The_LoudSpeaker> is there a qt5 camera app?
 @The_LoudSpeaker [<The_LoudSpeaker> is there a qt5 camera app?], for webcam?
[12:27] <The_LoudSpeaker> yup!
 google tell me about qcam
 *actually ddg not google
 it is not in the repo
[13:15] <The_LoudSpeaker> !qcam
[13:16] <The_LoudSpeaker> I thought ubot will be helping me here. :/
[13:17] <RikMills> !info qcam
[13:18] <RikMills> :/
[13:18] <The_LoudSpeaker> oh wait. it did. ubot pmed me "Sorry, I don't know anything about qcam."
[13:18] <The_LoudSpeaker> gg!
[13:19] <RikMills> Deleted on 2013-06-05 by Colin Watson
[13:19] <RikMills> (From Debian) ROM; obsolete; Debian bug #710896
[13:19] <RikMills> ^^ source qcam
[13:25] <The_LoudSpeaker> qcam was removed?
 yep, to old
 but, sorry I meant qtcam
 with t
 https://github.com/econsysqtcam/qtcam
[14:27] <The_LoudSpeaker> !qtcam
[14:47] <kc2bez> !info qtcam disco | The_LoudSpeaker
[14:48] <kc2bez> The_LoudSpeaker: you have to ask the not like that ^
[14:48] <kc2bez> *bot
[16:58] <kiki788> hi. i tried to install many distros. The problem is that on any distro from version 14 to 19, i get 4-6min boot time. the only exception is lubuntu on version 16.04 which im currently running. I tried to upgrade it to newer version as well as do clean install, but the problem persists.   is there any solution?
[17:01] <wxl> kiki788: depends on what the issue is. there have been some hardware-specific problems i've seen mentioned before on the forum. in other words, it doesn't happen for most people.
[17:03] <kiki788> so is there any way i can inspect what the issue might be?
[17:03] <wxl> first i'd look at the forums as you'll get a lot of hints and probably find your specific issue in the process
[17:03] <wxl> forum.lubuntu.me
 open a terminal and `journalctl -b -p err` might show some errors
[17:08] <kiki788> i guess i should be on "not good working" version to try that command and see if there are some errors, or?
[17:09] <kiki788> but i keep thinking that it is not hardware related because only 16.04 version works without any issues. Not older not newer ones......
 @kiki788 [<kiki788> i guess i should be on "not good working" version to try that command …], Yes, to investigate an error, you must reproduce the error
[17:14] <kiki788> ok, thanks