[04:46] <pitti> Good morning
[05:07] <RAOF> Good morning!
[05:10] <RAOF> pitti: Do you regularly run umockdev tests under valgrind? It seems to generate a *lot* of ‘possibly lost’
[05:10] <pitti> RAOF: I haven't so far; I guess I should start to do so
[05:11] <pitti> RAOF: yesterday I fixed a bug about leaking an udev_device in uevent synthesis
[05:11] <pitti> (pointed out by alf)
[05:11] <RAOF> It might not be your fault; g_type_register_fundamental shows up a lot.
[05:11] <pitti> RAOF: otherwise I'm aware of leaking the fdmaps in the preload, as there is no obvious way when to clean them up
[05:12] <pitti> RAOF: do you get leaks in the "client" application (running under the preload lib), or from the test suite (using the umockdev API)?
[05:12] <pitti> presumably the latter, but the former probably also has some leaks
[05:12] <RAOF> Actually, I'm doing both in the same process.
[05:12] <pitti> the preload doesn't use glib, though
[05:13] <pitti> RAOF: anyway, using valgrind sounds like a good idea
[05:34] <didrocks> hey Mirv! today, I'll let you for the stacks that needs manual publication? I need to catch up on other work today :)
[05:38] <pitti> RAOF: btw, did you run with G_DEBUG=gc-friendly ? in standard mode, glib's slice allocator will confuse the hell out of valgrind
[05:39] <pitti> RAOF: actually, I think it's G_SLICE=always-malloc
[05:39]  * RAOF tries
[05:42] <pitti> hm, why don't I get a valgrind report
[05:45] <pitti> ah, it uses LD_PRELOAD itself, so I need to swap this around
[05:46] <pitti> I don't see alf's reported udev_device leak, though
[05:47] <pitti> "valgrind --leak-check=full make check" gives me a leak in make, but nothing else
[05:48] <RAOF> pitti: Whereas I still get a whole bunch of possibly-lost even with G_SLICE=always-malloc
[05:49] <pitti> RAOF: right, I think I know what's wrong; umockdev-run sests LD_PRELOAD instead of extending it, fixing now
[05:49] <pitti> I'm trying to run the test suite through valgrind, which ought to report at least one known leak (I reverted the fix)
[05:49] <RAOF> Heh. And I'm seeing that because I don't actually use umockdev-run
[05:55] <pitti> RAOF: ok, I see those as well now
[05:55] <RAOF> Excellent.
[05:56] <pitti> vala_main(), some g_param_type bits in gobject_init_ctor, etc.
[05:56] <pitti> they go away with G_SLICE=debug-blocks G_DEBUG=gc-friendly
[05:56] <Mirv> didrocks: ok, will check
[05:56] <pitti> RAOF: ^
[05:58] <pitti> RAOF: hm, umockdev_testbed_clear() was added in 0.2.6 already and is in saucy
[05:58] <pitti> RAOF: but I indeed don't get that in devhelp, I'll investiage
[06:00] <pitti> RAOF: argh, forgot to add those to the doc index, sorry
[06:00] <RAOF> Heh.
[06:00] <pitti> something to add to the test suite, too
[06:01] <pitti> it's a shame that gtk-doc doesn't play along well with automake 1.13 any more
[06:17] <pitti> RAOF: do the above help?
[06:18] <RAOF> pitti: They didn't seem to.
[06:18] <pitti> RAOF: I added a "make check-valgrind" target now, and I don't get the gobject-y leaks with those
[06:18] <pitti> I do get leaks from ioctl_tree*
[06:18] <RAOF> ‘LD_PRELOAD=libumockdev-preload.so.0 G_SLICE=debug-blocks G_DEBUG=gc-friendly valgrind --leak-check=full bin/unit-tests --gtest_filter=UdevWrapper\*’ is what I'm running.
[06:19] <pitti> that looks fairly similar to mine
[06:19] <pitti> G_SLICE=debug-blocks G_DEBUG=gc-friendly LD_LIBRARY_PATH=.libs/ LD_PRELOAD=libumockdev-preload.so valgrind --leak-check=full --show-possibly-lost=no -q tests/test-umockdev-vala
[06:19] <RAOF> Ah, you're not showing possibly lost.
[06:20] <pitti> ah, no
[06:20] <RAOF> That's what I've been seeing.
[06:20] <pitti> I get tons of possibly lost in glib's slab allocator
[06:21] <pitti> RAOF: https://wiki.gnome.org/Valgrind might help, there are some suppression files there
[06:22] <pitti> hm, all pretty old, though
[07:07] <jibel> good morning
[07:11] <didrocks> salut jibel!
[07:11] <jibel> Bonjour didrocks !
[08:00] <Laney> g'morning
[08:01] <seb128> Laney, howdy
[08:01] <didrocks> hey Laney, seb128!
[08:01] <seb128> good morning everyone ;-)
[08:01] <seb128> didrocks, lut
[08:01] <seb128> how are you guys?
[08:01] <Laney> I've been looking for holiday apartments in lyon/grenoble ;-)
[08:01] <didrocks> trying to use tricks to recover some emails
[08:02] <seb128> didrocks, still fighting with lost emails? are they still on the server?
[08:02] <didrocks> seb128: they are only locally
[08:02] <didrocks> seb128: spent until 11PM yesterday for that :(
[08:02] <seb128> :-(
[08:02] <seb128> going to push you over gmail?
[08:03] <didrocks> seb128: I just hate thunderbird a little bit more, yeah :)
[08:03] <seb128> weird bug though
[08:03] <didrocks> seb128: I would use gmail if they enable filtering over X- headers
[08:03] <didrocks> maybe with google apps script, this would be possible
[08:03] <seb128> you can probably do without it, at least for bugmails
[08:04] <seb128> since the reason is stated in full text at the bottom for the email as well
[08:04] <didrocks> well, I tried first at filtering on other things for bugmails
[08:04] <seb128> you can probably filter on that
[08:04] <didrocks> but the sentence is changing so much…
[08:04] <seb128> ok...
[08:04] <didrocks> if you are the direct assignee
[08:04] <didrocks> or assignee because of the team is
[08:04] <didrocks> and other stuff…
[08:04] <didrocks> it's a mess filtering on this
[08:05] <didrocks> at least, I have an idea to recover inbox, sent mails and ML
[08:06] <Laney> I'm suddenly glad I leave mine on the server ...
[08:06] <seb128> it's still really weird that a bug went to delete emails like that
[08:06] <seb128> Laney, well, that's imap, is there any other way?
[08:06] <didrocks> yep, like if the settings "remove all emails > 30 days" was set
[08:07] <didrocks> (but at least, it didn't compact the folders automatically)
[08:07] <seb128> didrocks, you use imap?
[08:08] <didrocks> yep
[08:08] <seb128> yeah, really weird :/
[08:09] <seb128> didrocks, did you try asking #is if they have backups they can restore?
[08:09] <didrocks> seb128: well, I guess this will loose my recent emails in that case
[08:09] <seb128> right
[08:09] <seb128> but you could try to copy those locally
[08:09] <seb128> then ask #is if they can restore the backups
[08:10] <didrocks> I'm doing something similar, but the other way around with a fake pop account
[08:27] <mlankhorst> seb128: looks like RAOF is ok with flipping the switch on x1.14 now
[08:28] <seb128> mlankhorst, great!
[08:28] <mlankhorst> so do itt
[08:28] <seb128> RAOF, confirming?
[08:28] <RAOF> Yup, should be ok.
[08:28] <seb128> mlankhorst, well, check with didrocks' team since that needs to synchronize with unity
[08:28] <seb128> RAOF, mlankhorst: thanks
[08:28] <didrocks> mlankhorst: did you fix the issue of the transition?
[08:29] <didrocks> like not being able upgrade xorg 1.14 without taking the new unity?
[08:29] <mlankhorst> didrocks: I still feel it's a bad to have an interdependency between the 2
[08:29] <mlankhorst> idea*
[08:30] <didrocks> mlankhorst: it's not an interdependency, the new xorg breaks old unity, we should avoid people having half an update
[08:30] <didrocks> breaking them silently is worse
[08:31] <mlankhorst> didrocks: I feel if anything it should be a conflicts in unity then for xserver-xorg-core < 1.14
[08:32] <seb128> you can retro-actively change old unity versions
[08:32] <seb128> can't*
[08:32] <didrocks> yeah, if people don't take the latest upgrade, they would be broken in a bad transitions
[08:32] <seb128> what's the issue have the new xorg using a Breaks on old unity?
[08:32] <Laney> Breaks seems ok to me
[08:32] <didrocks> I told you, the only correct way is the Breaks
[08:32] <Laney> you can drop it after saucy
[08:32] <mlankhorst> ok
[08:32] <didrocks> mlankhorst: on the other hand, unity will dep on a new library, right?
[08:33] <didrocks> so we can't force newer unity with old xorg?
[08:33] <mlankhorst> yeah I added an explicit depends for that
[08:34] <didrocks> excellent, so both ways are handled
[08:34] <didrocks> I saw that Mirv just published unity
[08:34] <didrocks> so then once xorg is in proposed, we can get brandon's branch merged
[08:34] <didrocks> running the tests
[08:34] <didrocks> and publish
[08:34] <mlankhorst> I'll add a breaks in xserver for old libxi/libxfixes too then
[08:34] <didrocks> Mirv: mind taking care of that ^ (sil2100 did try last week, but the timing was bad)
[08:34] <didrocks> mlankhorst: I think it makes sense, yeah
[08:37] <chrisccoulson> good morning everyone
[08:37] <seb128> chrisccoulson, hey, how are you?
[08:38] <chrisccoulson> hi seb128, i'm good thanks. and you?
[08:38] <didrocks> hey chrisccoulson!
[08:38] <chrisccoulson> hi didrocks
[08:38] <seb128> chrisccoulson, I'm good thanks
[08:39]  * didrocks almost finished to hate thunderbird :p
[08:39] <didrocks> ah, or maybe no…
[08:40] <didrocks> "a folder with this name already exists, please choose another one"
[08:40] <didrocks> but I just clicked on "delete"!
[08:42] <chrisccoulson> didrocks, it still exists in the mailbox unless you've removed it from the trash as well (assuming you haven't done that yet)
[08:43] <didrocks> chrisccoulson: no, the trash was automatically emptied on exit, so it's removed
[08:43] <didrocks> chrisccoulson: but the mails were still on the files, I had to recover them by faking a pop account
[08:44] <didrocks> and now copying from one to the other one
[08:45] <Mirv> didrocks: ok, but which brandon's branch exactly?
[08:46] <didrocks> Mirv: bschaefer (without typos \o/)
[08:46] <Mirv> I only saw lp:~brandontschaefer/unity/show-desktop-fix as being proposed for unity
[08:46] <seb128> Laney, just for info I looked at your background's panel MR, I'm going to add some comments but not approve it since Ive questions similars to yours ... I would like Ken or some of the UITK guys to comment as well (especially if we use that one as an example on how to do things for other plugins)
[08:46] <didrocks> ah, branch
[08:47] <didrocks> hum, not that one
[08:47] <Mirv> not which brandon, yes, but branch :)
[08:47] <Laney> seb128: yeah good, I thought I'd put it up for discussion
[08:47] <didrocks> Mirv: I would say https://code.launchpad.net/~brandontschaefer/unity/move-pointer-barrier-to-xi-1.6.99.1
[08:48] <Mirv> yeah, just saw that, on hold currently. ok..
[08:50] <didrocks> Mirv: it's on hold due to new xorg needed I guess :)
[08:50] <didrocks> chrisccoulson: ok, done by the file system directly, much more effective :)
[08:51] <didrocks> I think I finally recovered my most important emails and ML \o/
[08:51] <mlankhorst> didrocks: I'm testing if I can grab libxi/xfixes from debian unstable atm
[08:52] <Mirv> I'll monitor when the xorg gets in
[08:52] <seb128> mlankhorst, do you have everything ready for upload otherwise?
[08:53] <mlankhorst> seb128: I was doing some final checks, and noticed that the libxi/fixes were missing the security updates, instead of doing another manual merge I'm looking if the versions from debian unstable work
[08:53] <mlankhorst> in which case we'd be in sync with debian again too
[08:53] <seb128> mlankhorst, ok
[08:54] <seb128> mlankhorst, let me know if you need help for uploads
[08:55] <mlankhorst> seems they build.. testing
[08:57] <mlankhorst> seb128: is there a tool to pull debian packages completely unmodified and stuff them in a ppa?
[08:57] <seb128> mlankhorst, not that I know of, maybe Laney knows a trick though
[08:59] <Laney> mlankhorst: seb128: yes, backportpackage should let you do this
[08:59] <Laney> IIRC anyway
[09:01] <Laney> mlankhorst: try: backportpackage -s unstable -d saucy -u ppa:mlankhorst/ppa mycoolpackage
[09:01] <Laney> you can put -b -B sbuild/pbuilder in there too to test-build locally before uploading
[09:03] <mlankhorst> Laney: that adds a string to version number :(
[09:05] <Laney> what's wrong with that?
[09:05] <Laney> that's what you want for PPA uploads isn't it?
[09:05] <mlankhorst> it's meant to be copied to -proposed
[09:05] <Laney> if it's a sync you can easily re-copy it
[09:06] <Laney> infact if it's a sync you can use copy-package instead of backportpackage to put it in your PPA
[09:06] <Laney> sorry, forgot about that one
[09:06] <Laney> that's from bzr branch lp:ubuntu-archive-tools
[09:26] <mlankhorst> Laney: thanks, copy package works
[09:26] <Laney> np
[09:26] <Laney> I didn't give you the invocation because it's pretty hard to remember :P
[09:26] <mlankhorst> that's why it took so long to respond
[09:26] <mlankhorst>  ./copy-package -d debian -s sid --to-distribution=ubuntu --to-suit=saucy --to-ppa=canonical-x --to-ppa-name=x-staging libxfixes
[09:27] <Laney> that's probably the tool to use to copy it from the ppa to proposed too
[09:27] <mlankhorst> seems to have ignored the thing --tos-uit due to typo, meh :p
[09:27] <mlankhorst> at least it builds in saucy so I don't care
[09:28] <Laney> yeah you probably want --to-suite=saucy-proposed ...
[09:30] <seb128> mlankhorst, so, what is missing at this point to be able to start uploading?
[09:31] <mlankhorst> seb128: I need to know the final version number of the first unity that will support the pointer barriers, so I can add the breaks to xorg-server
[09:31] <Laney> you can do <= current-one?
[09:31] <seb128> mlankhorst, didrocks said they would bump the changelog, so << 7.0.2
[09:31] <mlankhorst> ok
[09:31] <seb128> Laney, that doesn't work fine with daily releases
[09:32] <seb128> didrocks, ^ can you confirm << 7.0.2?
[09:32] <Laney> why?
[09:32] <didrocks> yep 7.0.2
[09:32] <Laney> oh the hard lock got me applications back in the home lens
[09:32] <seb128> Laney, well, I guess it works if you make sure you coordinate unity patch landing
[09:33] <seb128> Laney, but it's easier to bump changelog that to play "guess the daily that will land with the patch"
[09:33] <mlankhorst> ok, final breaks will be
[09:33] <mlankhorst>  unity (<< 7.0.2),
[09:33] <mlankhorst>  libxfixes3 (<< 1:5.1),
[09:33] <mlankhorst>  libxi6 (<< 2:1.7.1.901),
[09:33] <seb128> +1
[09:34] <mlankhorst> waiting on the builds to xi/xfixes builds to finish, then I'll upload the final xorg-server
[09:34] <seb128> great
[09:35] <seb128> mlankhorst, let me know when the xorg side is ready, I will try the ppa with a custom unity build locally and then we can upload xorg
[09:35] <mlankhorst> ok
[09:35] <seb128> thanks
[09:39] <mlankhorst> you should be able to test the unity build already, just make sure it has a break on xserver-xorg-core << 2:1.14, and a hard depends on the libxi/libxfixes in the x-staging ppa (and corresponding -dev packages)
[09:40] <seb128> mlankhorst, well, I want to test the ppa once it's in "ready for upload" state, but it will have a break on unity << 7.0.2  so I will need that version of unity
[09:52] <mlankhorst> seb128: server build incoming, then
[10:02] <mlankhorst> seb128: it should be ok to test as soon as it's uploaded
[10:02] <seb128> mlankhorst, "uploaded"? you mean it's done building, it needs to be published?
[10:02] <mlankhorst> oh, that's fast
[10:02]  * mlankhorst was getting a drink
[10:03] <mlankhorst> oops I messed up the dep
[10:03] <seb128> :-(
[10:04] <mlankhorst> retry
[10:24] <Laney> seb128: up for a little bit of NEWing (gnome-desktop-testing)?
[10:24] <seb128> Laney, can do
[10:24] <Laney> sweet
[10:24]  * Laney goes to upload
[10:30] <davmor2> chrisccoulson: Wow I knew firefox were creating an os I didn't realise it would be landing in Ubuntu.  Firefox== your friendly event based init daemon :)  http://ubuntuone.com/7F7dydbxHaYWMOO0L6TKPI
[10:36] <czajkowski> have spent the day playing with the FF phone, nice to hold it, nice size phone, very clunky OS .
[10:37] <ogra_> have you tried ubuntu touch before so you can compare ?
[10:50] <Mirv> would comparing to other $70 phones would show that it's not that clunky after all?
[10:51] <Mirv> I haven't tried any FF OS phone yet, althouh saw one live
[10:53] <mlankhorst> seb128: the xorg side should be correct now
[10:55] <czajkowski> ogra_: I have and it's a lot more intuitive.
[10:55] <ogra_> cool
[10:55] <czajkowski> but that was also on the same phone I use daily
[10:55] <mlankhorst> ugh, out of space
[10:55] <czajkowski> but having hardware dedicated to it is a nice thing
[10:56] <ogra_> definitely
[10:56]  * ogra_ is sure we'll get there too
[10:56] <czajkowski> but I kept wanting to swipe and do stuff and it's not what I'd expect
[10:56] <czajkowski> h indeed
[10:56] <ogra_> heh
[10:56] <czajkowski> good few folks have them here
[10:56] <czajkowski> here being Florence at europython
[10:57] <Laney> seb128: ok, it should be there now (gnome-desktop-testing in NEW)
[10:57]  * Laney just built glib including testsuite and forgot to actually include the patch ...
[11:00] <ricotz> Laney, hi :)
[11:00] <ricotz> Laney, i noticed you touch gnome-bluetooth, were there reports like that yet http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712774
[11:01] <ubot2`> Debian bug 712774 in gnome-bluetooth "gnome-bluetooth - abort() on unknown values" [Grave,Fixed]
[11:02] <Laney> ricotz: didn't hear of any
[11:02] <Laney> check LP bugs?
[11:03] <ricotz> Laney, havent found a LP bug yet
[11:04] <Laney> Found in version gnome-bluetooth/3.8.0-1
[11:04] <Laney> we don't have that yet
[11:04] <ricotz> Laney, i am hitting it with the current saucy version
[11:05] <Laney> ok, well it has a fixed version there
[11:05] <ricotz> triggered by the kernel update to 3.10, 3.8.x worked fine
[11:05] <Laney> maybe you could see if we can take that
[11:05] <Laney> or find the fix and cherry-pick it
[11:06] <ricotz> or maybe even updating gnome-bluetooth to 3.8.x?
[11:07] <ricotz> yeah, i am currently building it while dropping the consolekit dep
[11:07] <seb128> ricotz, https://blueprints.launchpad.net/ubuntu/+spec/desktop-gnome-3-8 states
[11:07] <seb128> " * gnome-bluetooth
[11:07] <seb128>  - Drops fallback applet
[11:07] <seb128>  - Drops nautilus-sendto plugin
[11:07] <seb128>  - Soname bump
[11:07] <seb128>  - Not really needed yet"
[11:07] <seb128>  
[11:07] <seb128> so updating seems it's not on the current roadmap
[11:07] <ricotz> seb128, right
[11:08] <ricotz> finding the change which suppose to fix it then
[11:09] <Laney> don't really have an opinion on those issues
[11:09] <Laney> the transition isn't big
[11:14] <seb128> Laney, the issue is not so much the transition that the fact it's another update that "features" drop of functionnalities some users use, with no benefit behind
[11:14] <ricotz> there is no soname bump
[11:15] <Laney> sure - I don't know what features are in the new version
[11:15] <seb128> new gnome-bluetooths will also likely start pulling bluez5 soon when we want to stay on 4
[11:15] <Laney> and I'd be happy to receive advice on the other things from ubuntu gnome
[11:15] <seb128> well, it's the Ubuntu GNOME guys who wrote the comments I copied before
[11:15] <seb128> anyway I've no strong opinion on the update, it just seems work for getting nothing but complains back
[11:16] <seb128> so I'm not going to spend time on it, but I'm not going to block others if somebody wants to do it ;-)
[11:16] <ricotz> seb128, bluz5 isnt needed for 3.8, but for 3.9.x
[11:16] <Laney> same, but you know the drill when we start missing bug fixes
[11:16] <seb128> ricotz, right, that's why I used futur tense :p
[11:16] <ricotz> but yeah the feature drop is enough reason if you care about those
[11:16] <seb128> we sort of care about sendto I think
[11:17] <seb128> we didn't update that one either for similar reasons
[11:17] <Laney> does gnome just not have that feature any more?
[11:17] <ricotz> ok
[11:18] <ricotz> just to confirm, using the newer gnome-bluetooth fixes this (fatal) error here
[11:20] <ricotz> Laney, i presume something like https://git.gnome.org/browse/gnome-bluetooth/commit/?h=gnome-3-8&id=a6ecb2b31f7298041d13a4dd57635a5e40c852bb would fix it
[11:20] <Laney> biab, lunch
[11:20] <seb128> Laney, enjoy ;-)
[11:20] <Laney> ricotz: give it a go
[11:28] <mlankhorst> seb128: can you give the xorg ppa a go?
[11:28] <seb128> Laney, shrug, you could make new packages dh9 instead of cdbs :p (or is pkg-gnome still set on cdbs?)
[11:28] <seb128> mlankhorst, yep
[11:47] <ricotz> seb128, Laney, http://paste.debian.net/plain/14122
[11:48] <seb128> ricotz, thanks
[11:49] <seb128> mlankhorst, where do I find unity with the barrier patch updated?
[11:51] <ricotz> seb128, yw
[11:52] <mlankhorst> seb128: oh i thought you were creating one
[11:52] <mlankhorst> hold on
[11:53] <seb128> mlankhorst, I tried, I applied the diff from https://code.launchpad.net/~brandontschaefer/unity/move-pointer-barrier-to-xi-1.6.99.1/+merge/150175 to the current saucy version but that fails to build :/
[11:53] <mlankhorst> seb128: it should build correctly with the versions in the xorg ppa
[11:54] <seb128> is that rebased on current trunk?
[11:54] <seb128> brb needs to reboot, my laptop is swapping
[11:54] <ricotz> mlankhorst, hi
[11:54] <mlankhorst> g'day mate
[11:55] <ricotz> mlankhorst, will the xserver package officially gain the xwayland module besides xmir
[11:55] <mlankhorst> I'm not aware of any plans to do so at the moment
[11:56] <ricotz> mlankhorst, i see, would be a nice step though
[11:56] <ricotz> mlankhorst, i think i saw a rebased version for 1.14 somewhere
[11:57] <mlankhorst> more importantly I do not think the x team is willing to support it at this point :-)
[11:58] <ricotz> it would make some people happier ;)
[11:59] <ricotz> but of course finally landing 1.14 with the new barriers would be nice
[11:59] <mlankhorst> ricotz: of course, because then it's not their problem
[11:59] <mlankhorst> :P
[11:59] <ricotz> while this unity part is blocking updates for edgers in this regard
[12:00] <ricotz> mlankhorst, i am counting me in here ;)
[12:01] <ricotz> (ah it was a rebase for 1.15)
[12:02] <seb128> back
[12:02] <mlankhorst> If it's upstream I don't see any issues with enabling it, but accepting the xwayland patches means having to support it separately now, I don't see that happening..
[12:03] <seb128> mlankhorst, so, is there an unity branch with the barrier work on top of trunk somewhere?
[12:03] <ricotz> mlankhorst, absolutely, i am hoping it will get merged
[12:04] <mlankhorst> seb128: I tested the patch from debian/patches in https://launchpad.net/~canonical-x/+archive/x-staging/+files/unity_7.0.0daily13.06.24-0ubuntu2.diff.gz
[12:04] <seb128> mlankhorst, thanks
[12:04] <mlankhorst> but only against the 7.0.1 in saucy atm
[12:05] <seb128> the current saucy version is a daily from trunk made yesterday
[12:05] <seb128> so it should be current
[12:47] <seb128> mlankhorst, ok, I found my problem with the unity build
[12:47] <seb128> "/usr/include/X11/extensions/XInput2.h:173:22: error: conflicting declaration ‘typedef unsigned int BarrierEventID’
[12:47] <seb128>  typedef unsigned int BarrierEventID;
[12:47] <seb128> "
[12:47] <seb128> mlankhorst, you need to update the b-d on libfixes as well, not only libxi
[12:48] <mlankhorst> seb128: yeah, but that's for unity
[12:49] <mlankhorst> seb128: besides if you had xorg-server from the ppa installed the wrong versions shouldn't be installing
[12:49] <mlankhorst> installed*
[12:49] <seb128> mlankhorst, I don't, I can't install it without removing unity because of the breaks :p
[12:50] <seb128> which is why I want to rebuild in the first place
[12:50] <mlankhorst> seb128: but yeah the build-deepends for unity need fixing
[12:55] <Laney> seb128: yeah that packaging style is to fit in with pkg-gnome :(
[12:56] <desrt> good morning!
[12:58] <mlankhorst> seb128: but hey if you didn't upgrade out of fear of breaking unity, I would say the thing did its job :P
[13:00] <seb128> Laney, did they say they want to keep this style or did you just assume they want (NEWed in any case)
[13:00] <seb128> mlankhorst, right, but now I would like to test both so we can upload xorg if things work :p
[13:00] <seb128> desrt, good morning to you!
[13:01] <Laney> seb128: the former - it's one of those arguments that I didn't really want to have
[13:01] <Laney> and thanks
[13:01] <seb128> yw
[13:01] <Laney> s/former/latter/
[13:01] <seb128> let me ask on #debian-gnome
[13:05] <desrt> seb128: happy wednesday
[13:06] <seb128> desrt, thanks ;-)
[13:07] <desrt> larsu: are you following the thread about OnlyShowIn?  I'd like your opinion on it.
[13:07] <desrt> the KDE guys seem to be lining up in the 'remove it' column
[13:11] <seb128> desrt, so much hate
[13:11] <desrt> seb128: hm?
[13:11] <larsu> desrt: I'm for removing it as well. Currently compiling a list of apps who use OnlyShowIn=MessagingMenu (that's the only argument *for* it at the moment)
[13:11] <larsu> seb128: actually I think the debate is very productive
[13:12]  * larsu wishes we had a searchable web service with all .desktop files from the archive
[13:13] <seb128> desrt, people cheering about dropping harmless use of desktop fields...
[13:13] <seb128> larsu, I couldn't care less either way, seems like arguing on details nobody cares about
[13:13] <larsu> seb128: well, their point is that these fields are not harmless
[13:13] <seb128> larsu, sure, GNOME hates customisation and consider anything that let distro change the behaviour as an issue...
[13:14] <seb128> same storing as allowing panels in g-c-c
[13:14] <desrt> seb128: this is only about additional desktop actions
[13:14] <desrt> not about desktop files themselves
[13:14] <seb128> desrt, same story...
[13:14] <larsu> damit, packages.ubuntu.com errors out on contents search :'(
[13:15] <desrt> seb128: not really... nobody is proposing removing OnlyShowIn on desktop files
[13:15] <desrt> seb128: if you have an opinion about this you should state it on the list
[13:15] <seb128> desrt, I've the opinion that it's there, doesn't hurt and can be useful
[13:15] <seb128> I don't care enough to enter into an argument though
[13:15] <desrt> seb128: it's currently hurting, though
[13:15] <seb128> it's not
[13:16] <desrt> it is.  transmission is a good example.
[13:16] <seb128> it's hurting GNOME because they are late and they are not in OnlyShowIn
[13:16] <seb128> yeah, it's fine when GNOME screw us
[13:16] <seb128> but they are late on something and need some patches it's not fine...
[13:16] <desrt> seb128: so people should make webpages that OnlyShowIn=IE;Firefox;Chrome;Opera;
[13:16] <desrt> and if someone else is 'late' to the browser game, too bad for them?
[13:16] <seb128> why do we have OnlyShowIn= to start with?
[13:16] <desrt> seb128: i'm sorry -- but this has nothing to do with GNOME
[13:16] <seb128> if that's such a crappy idea?
[13:17] <desrt> seb128: that's exactly what people are asking....
[13:17] <seb128> desrt, well, your complain is "transmission didn't add GNOME to their OnlyShowIn"
[13:17] <desrt> seb128: didn't add anyone except Unity, really
[13:17] <seb128> desrt, you just said it was not about dropping OnlyShowIn drom .desktop, but then you say it's of no use...
[13:17] <desrt> the KDE people seem to be against this more strongly than jasper is...
[13:18] <desrt> seb128: OnlyShowIn for desktop files as a whole is useful for when those desktop files are desktop components
[13:18] <seb128> I don't see how that's different from .desktop files
[13:18] <desrt> ie: they come as part of GNOME
[13:18] <seb128> you have the same issue for ql
[13:18] <desrt> it's difficult to imagine _part_ of a desktop file being shipped as part of a project
[13:18] <seb128> you can't have features that are desktop specific
[13:18] <seb128> like "open in the dash"
[13:18] <seb128> that wouldn't make sense in gnome-shell
[13:18] <desrt> seb128: if you have arguments, _please_ put them on the list
[13:18] <desrt> not in a side conversation on IRC
[13:19] <desrt> otherwise you don't get to complain when the decision is made against you
[13:19] <seb128> well, the decision will be made against me whatever I think or argue about
[13:20] <larsu> seb128: why do you think that?
[13:20] <desrt> pathetic prophecy
[13:20] <seb128> larsu, because that's how things have been going for over a year
[13:21] <larsu> seb128: desrt and I are trying to fix that...
[13:25] <desrt> seb128: please write to the list.  in the amount of time you've spent discussing this on IRC you could have had an email
[13:26] <seb128> larsu, desrt: sorry, I will just trust you guys to do what's right there, I just don't feel like going into another (stupid) argument on lists on why it should be able to told apart a GNOME and an Unity session, seems GNOME guys disagree and I had too many of this discussion recently
[13:26] <desrt> seb128: if you read the list, so far it's one gnome guy saying "why do we have this?" and three KDE guys saying "ya... let's get rid of it"
[13:27] <seb128> desrt, the discussion started off list with "let's drop that", which you argued again, which is why we have the email
[13:27] <seb128> if it wasn't for you they would just have went "screw that field
[13:27] <desrt> seb128: well, it happens to be the case that i'm the one implementing it
[13:27] <desrt> and i said that i'll do whatever the _list that is the central point of contact between the desktops_ decides
[13:28] <desrt> i can't really do a lot if one desktop chooses not to be represented there
[13:28] <seb128> alright, let me reply on the list just to state what I think
[13:28] <desrt> please do
[13:28] <desrt> and please give good real-world examples where this might be useful
[13:28] <desrt> i don't have a strong opinion here and i'm happy to see the argument go either way
[13:28] <desrt> i hope you manage to convince people
[13:29] <larsu> desrt: because you already implemented it?
[13:30] <seb128> I'm not convinced if will be very useful, but it doesn't cost a lot (especially if it's not used) and it gives a tool that can reply to specific needs
[13:30] <mdeslaur> I'm just curious, how do you hide shell-specific icons from another shell if you don't have OnlyShowIn?
[13:30] <seb128> so having the option in case somebody needs it seems like it wouldn't hurt anyone
[13:31] <desrt> seb128: on the list, please
[13:31] <seb128> mdeslaur, they want to keep it for icons, they are discussing e.g lists you get when right clicking on the launcher
[13:31] <mdeslaur> oh, I see, ok
[13:35] <kenvandine> tedg, so the version check fixed the upstart-app-launch failure?
[13:35] <tedg> kenvandine, Basically yes.  It is basically "right version" and "can't figure out version" -- but we can call that a check :-)
[13:36] <kenvandine> :)
[13:48] <Laney> seb128: can you look at g-d-t's binaries please?
[13:48] <seb128> Laney, ok
[13:48] <Laney> yay
[13:48] <Laney> ooh, flipped images by default
[13:48]  * Laney finds a usb cable
[13:49] <seb128> desrt, larsu: replied, but I really don't feel like going into an argument, reality is that if we don't have the OnlyShowIn and need it we will likely end up having a gedit-gnome.desktop and a gedit-unity.desktop which one using a OnlyShowIn, which works as well but I'm not convinced it's any better (especially that it adds to the available .desktop and create noise is some UIs that list everything)
[13:50] <seb128> which one->each on
[13:50] <desrt> seb128: why would we have separate gedits?
[13:50] <seb128> desrt, larsu: the example I came with is that you might want e.g having your IDE doing "create ubuntu touch project" under Unity but "create GNOME project" under GNOME
[13:51] <seb128> as a ql item
[13:51] <larsu> good point
[13:51] <desrt> seb128: you know that there are people who work on ubuntu while using gnome....
[13:51] <seb128> and you can't say "create <desktop> project", because XFCE wouldn't want XFCE project
[13:51] <seb128> but GTK project
[13:51] <seb128> desrt, the point of the ql is to list the most useful items, not 150 items for every possible user choice
[13:52] <desrt> fair point, i suppose
[13:52] <seb128> desrt, I would like Unity to default to Unity project
[13:52] <seb128> rather than having a ql with GNOME project, XFCE project, Unity project, etc
[13:52]  * desrt waits to see your reply
[13:52] <seb128> bah
[13:53] <seb128> moderation ... /me resend from other email
[13:53] <seb128> I forgot I was subscribed with my debian email to that list :p
[13:56]  * mlankhorst pokes seb128 
[13:56] <seb128> mlankhorst, hey
[13:57] <seb128> mlankhorst, sorry, I got sidetracked into that, I'm ready to upgrade ... let me 5 minutes
[13:57] <seb128> Laney, I would take Joss' comment on #debian-gnome as "feel free to use dh9"
[13:58] <Laney> yeah, looks like it
[13:58]  * Laney yays quietly
[14:02] <seb128> Laney, I guess you will update your system settings's merge request with Kaleo's comments from IRC? (would be good to maybe make a summary of that on the MR for reference so others who take it as an example can benefit from that as well)
[14:02] <Laney> seb128: I am doing it already, yeah
[14:02] <seb128> Laney, thanks
[14:02] <Laney> infact I was just typing bzr push :P
[14:02] <seb128> ;-)
[14:03] <Laney> sounds like the answer to my questions was "yes that's fine" though
[14:04] <seb128> Laney, I'm not picky, as long as it works ... and we can still refactor/change things later if there is a better way
[14:05] <Laney> yeah
[14:48] <seb128> mlankhorst, ok, new xorg/unity works fine for me, +1 for upload
[14:48] <seb128> didrocks, ^
[14:48] <didrocks> thanks seb128, not sure if Mirv is still around though
[14:48] <seb128> didrocks, tomorrow morning should do, or do we need to sync upload?
[14:49] <seb128> I'm not sure if britney stop stuff to migrate if they have Breaks
[14:49] <seb128> we maybe better upload everything together
[14:49] <didrocks> seb128: just to avoid having it laying in -proposed for hours
[14:49] <didrocks> ah yeah about the Breaks: and block
[14:49] <seb128> well, we have stuff in proposed for weeks
[14:49] <seb128> so one day doesn't concerns me
[14:50] <seb128> it's rather that it moves out from proposed and Breaks unity
[14:50] <seb128> that would be an issue
[14:50] <didrocks> yeah, I think britney won't block
[14:51] <seb128> didrocks, Mirv, mlankhorst: ok, let's aim for upload tomorrow, we can start early on that
[14:51] <seb128> it will let time in the day to get through
[14:51] <mlankhorst> seb128: sounds good to me
[14:52] <seb128> didrocks, do you think we should get bregma's team to merge the barrier patch and bump the version to 7.0.2 today in preparation?
[14:52] <didrocks> seb128: that's what I wanted Mirv to coordinate, not sure how they will do that without proposed
[14:53] <didrocks> and this will break tonight's dailies if we do so
[14:53] <seb128> ok, let's talk tomorrow morning
[14:56] <bregma> just give us the word and we'll merge that baby in
[14:56] <seb128> bregma, hey
[14:56] <seb128> bregma, xorg in ready for upload, we just need synchronization
[14:56] <bregma> yes
[14:57] <bregma> also, I want to move to compiz trunk and bump unity to 7.1, all at exactly the same time
[14:57] <bregma> :)
[14:57] <seb128> bregma, I would say it would be good to get a MR up ready to merge, and bump the unity version from 7.0.1 to 7.0.2 in the same merge (we made xorg breaks unity << 7.0.2)
[14:57] <seb128> bregma, so we can ack that mr land both unity and xorg tomorrow
[14:58] <bregma> OK
[14:58] <seb128> bregma, you can do compiz trunk and 7.1 next week then :p
[14:58] <seb128> bregma, thanks
[14:58] <seb128> on that note, time for some exercice
[14:58] <seb128> be back in ~45min
[14:58] <bregma> may as well do 7.1 this week instead of 7.0.2, because of breakage
[14:58] <bregma> it's just a number
[15:01] <mlankhorst> no, it's 7.0.2 now, I don't want another upload :P
[15:07] <czajkowski> Have t say folks, Saucy is really really polished and not having any major issues running it. Very nicely done
[15:37] <bigtoe376> Hi all.  Just wondering if there is any movement on fixing the issues with gvfs-fuse.  Although this is, IMO, a major bug it also comes under this topic.  Mounting SMB shares/devices and copying files is not trivial and should be rock solid.
[15:43] <xclaesse> seb128, kenvandine: (not sure to ask the right person): do you know where is ubuntu's code to move libreoffice's menubar into unity's panel ?
[15:56] <seb128> xclaesse, try asking Sweetshark, it's in libreoffice's upstream codebase but not sure where, it just uses gmenu I thin
[15:57] <seb128> k
[15:57] <xclaesse> seb128, ok, I'm cloning upstream code atm, will grep :)
[16:18] <bschaefer> seb128, ping
[16:18] <seb128> tedg, hey, how are things working without your gnome-session patch to drop compiz/gsd from required components? do you get them randomly started by g-s or upstart depending who is first?
[16:18] <seb128> bschaefer, hey
[16:19] <bschaefer> seb128, hello! I've bumped my edge barriers branch up to 7.0.2, and merged it with trunk
[16:19] <tedg> seb128, The compiz job detects the case and aborts
[16:19] <bschaefer> soo its ready for the 1.14 xservers change :)
[16:20] <bschaefer> https://code.launchpad.net/~brandontschaefer/unity/move-pointer-barrier-to-xi-1.6.99.1/+merge/150175
[16:21] <seb128> tedg, what about gsd? it's listed by initctl list here
[16:21] <seb128> bschaefer, great, thanks
[16:21] <tedg> seb128, Not sure on that one, I'm guessing it detects itself and only starts once.
[16:21] <bschaefer> seb128, np! have fun getting the new xserver in main :)
[16:22] <seb128> bschaefer, you should probably bump your libxfixes requirement, I tried to build with that patch and the libxfixes earlier and I hit that
[16:22] <seb128> "/usr/include/X11/extensions/XInput2.h:173:22: error: conflicting declaration ‘typedef unsigned int BarrierEventID’
[16:22] <seb128>   typedef unsigned int BarrierEventID;
[16:23] <bschaefer> hmm I just built the branch here
[16:23] <seb128> bschaefer, dpkg -l | grep libxfixes
[16:25] <seb128> bschaefer, ?
[16:25] <bschaefer> ii  libxfixes-dev                                1:5.0-4ubuntu6                                         i386         X11 miscellaneous 'fixes' extension library (development headers)
[16:25] <bschaefer> ii  libxfixes3:i386                              1:5.0-4ubuntu6                                         i386         X11 miscellaneous 'fixes' extension library
[16:25] <bschaefer> seb128, are the 2 i have
[16:25] <bschaefer> umm, but unity is set to any xfixes version
[16:25] <bschaefer> at lease in the cmake...
[16:27] <seb128> bschaefer, ok, dunno what I hit the build error here, anyway once the new xorg is available that will not be an issue
[16:27] <bschaefer> seb128, alright, let me try to rebuild again!
[16:27] <bschaefer> it would be nice to make sure theres no problems :)
[16:40] <seb128> tedg, hum, things don't look nice on login without the required component
[16:41] <seb128> tedg, I get a white screen then some weird/slow fading in frame
[16:41] <seb128> tedg, I think we need to run stuff in order like gnome-session does, at least the compiz and the theme need to be set first
[17:26]  * didrocks waves good evening
[18:36] <walters> desrt: got a second?
[18:37] <walters> or anyone: in the current debian package of dbus, is "make check" run?  I assume via debhelper?  Does debhelper do anything like e.g. use Xvfb to set up $DISPLAY ?
[18:47] <tedg> walters, I don't think debhelper does that automatically.  I don't see anything in the dbus package to disable tests though.
[18:47] <tedg> So I'd assume they are run.
[18:49] <walters> the dbus test-autolaunch wants an X session presently
[18:51] <tedg> Hmm, I don't see anything to handle that.  It probably works by magic :-)
[18:52] <Laney> the tests aren't run
[18:52] <Laney> there's an empty override_dh_auto_test in rules to disable them
[18:53]  * tedg was an idiot and searched for autotest :-/
[18:53] <tedg> Ah, and there's a --disable-tests added to configure later on.
[18:54] <walters> ah i see.  Thanks
[18:54] <walters> i had expected it to be set up in Debian since smcv did so much work upstream on the tests
[18:54] <Laney> might be different there
[18:55] <Laney> nope :/
[19:03] <Laney> kenvandine: try that MP! Thanks for the feedback :-)
[19:08] <kenvandine> Laney, rock on!
[19:08] <kenvandine> thanks
[19:09] <kenvandine> Laney, we need to do this with a bunch of the apps, we have lots of these public components that weren't really meant to be publich
[19:09] <kenvandine> public even
[19:09] <Laney> oh really?
[19:09] <kenvandine> yeah
[19:09] <Laney> well it turned out not to be too difficult
[19:09] <kenvandine> it's a bit of a mess :)
[19:09] <kenvandine> cool
[19:09] <kenvandine> share-app does
[19:09] <Laney> and /usr/lib/myapplication/ is already a standard place for private libs
[19:09] <kenvandine> i think gallery and phone-app does too
[19:10] <kenvandine> i've complained about it before and was just told this was the way it was
[19:10] <kenvandine> which i never bought :)
[19:10] <Laney> desrt: check this https://jenkins.qa.ubuntu.com/job/saucy-adt-glib2.0/ARCH=amd64,label=adt/19/console
[19:10] <Laney> the installed-tests all pass
[19:11] <Laney> (also, uploaded that patch for attente)
[19:12] <attente> Laney, thanks!
[19:13] <Laney> np
[19:15] <walters> ah you guys are using installed tests now?
[19:16] <Laney> well, case-by-case but yeah
[19:16] <walters> well this goes to my above question; you are setting up an X/dbus session right?
[19:16] <Laney> for those, indeed
[19:16] <walters> what's the script/program used to do that?
[19:16] <Laney> I just wrote a little shell script to launch the test runner under dbus-launch xvfb-run -a
[19:16] <walters> ok
[19:17] <walters> cool
[19:17] <Laney> but yeah, cool to see them all pass first time
[19:17] <Laney> and those are automatically re-triggered whenever dependencies change
[19:17] <Laney> so in theory we notice if the kernel or libc breaks glib
[19:17] <Laney> which is nice
[19:18] <walters> definitely, enabling that sort of thing was one of the primary goals of installed tests
[19:18] <jbicha> ricotz: it looks like reverting the drop-sendto commit from gnome-bluetooth works so we should be able to do the update
[19:18] <jbicha> I wonder where seb128 went...
[19:18] <Laney> probably to have an evening :P
[19:18] <Laney> update the BP
[19:19] <ricotz> jbicha, nice
[19:19] <Laney> did shell replace that functionality somewhere else?
[19:19] <ricotz> Laney, could you sponsor the small update anyway?
[19:19] <Laney> sure, I assumed someone else did
[19:20] <Laney> can you give me the link again?
[19:20] <ricotz> yeah, i thought seb would do it ;)
[19:20] <ricotz> hmm, dont have it here, could you scroll up?
[19:21] <jbicha> ricotz: you mean for gnome-bluetooth? I'm almost done with 3.8
[19:22] <ricotz> jbicha, yes, it solves a fatal problem with the current kernel
[19:23] <Laney> If you're doing 3.8 then that's fine
[19:23] <ricotz> alright
[19:24] <ricotz> jfyi this was it http://paste.debian.net/plain/14122
[19:30] <jbicha> Laney: your patch for https://bugzilla.gnome.org/show_bug.cgi?id=702244 won't apply since that file isn't in the tarball
[19:31] <ubot2`> Gnome bug 702244 in general "Fix format string warning" [Normal,Resolved: fixed]
[19:31] <jbicha> https://git.gnome.org/browse/gnome-bluetooth/commit/?id=2e320f6
[19:53] <jbicha> sending files w/ g-bluetooth 3.8 works in gnome shell but in Unity I get "GDBus.Error:org.openobex.Error.Failed: Unable to request session"
[19:54] <jbicha> and if I google that I find bug 1148033
[19:54] <ubot2`> Launchpad bug 1148033 in gnome-bluetooth (Ubuntu) "GDBus.Error:org.openobex:Error.Failed: Unable to request session" [Undecided,Confirmed] https://launchpad.net/bugs/1148033
[19:54] <jbicha> does indicator-bluetooth work for you guys to send files?
[19:56] <seb128> jbicha, no, but gnome-control-center's bluetooth panel has the same issue
[19:57] <jbicha> seb128: ok so I can assume this has nothing to do with g-bluetooth 3.8
[19:57] <jbicha> seb128: I think everything else is fine for the update; I reverted the drop-nautilus-sendto plugin commit
[20:00] <seb128_> bah, unstable internet here
[20:00] <seb128_> jbicha, not sure that went through but I was saying that g-c-c's capplet has the same issue
[20:00] <jbicha> seb128: ok so I can assume this has nothing to do with g-bluetooth 3.8
[20:00] <jbicha> seb128: I think everything else is fine for the update; I reverted the drop-nautilus-sendto plugin commit
[20:01] <seb128> what's the interest of the update?
[20:01] <seb128> well, your call, as long as you guys deal with the breakages
[20:02] <jbicha> https://git.gnome.org/browse/gnome-bluetooth/tree/NEWS?h=gnome-3-8
[20:02] <seb128> right, I don't see anything worth an update in there
[20:02] <seb128> it's likely the bug fixes got backport for some part in 3.6 and every else is remove_feature*n
[20:03] <jbicha> nah, there's only one feature removed and I reverted that
[20:03] <seb128> - Remove fallback applet as GNOME fallback is obsolete.
[20:03] <seb128> - Remove ObexFTP browsing support
[20:03] <seb128> - Remove nautilus-sendto plugin.
[20:03] <seb128> ?
[20:04] <seb128> that's from the url you just gave me
[20:04] <jbicha> right, ok we don't use the fallback applet as gnome-panel uses indicators by default
[20:04] <seb128> what about obextftp?
[20:05] <jbicha> that points to http://www.hadess.net/2011/11/obexftp-in-gnome-non-update.html
[20:10] <seb128> jbicha, sorry, I'm on an unstable wifi
[20:25] <Laney> jbicha: won't apply to 3.8?
[20:26] <Laney> Oh well, I'm sure you can backport it :P
[20:27] <jbicha> Laney: it's not in the tarball https://git.gnome.org/browse/gnome-bluetooth/commit/?id=2e320f6
[20:27] <jbicha> that means it's "fixed"
[20:28] <Laney> oh, I didn't actually check what they did
[20:28] <Laney> awesome fix
[20:31] <seb128> Laney, can you push your gsd -0ubuntu15 update to the vcs?
[20:33] <Laney> seb128: oh yeah, sorry, do you want it now or is tomorrow ok?
[20:33] <seb128> Laney, tomorrow is ok
[20:33] <Laney> cool
[20:33] <Laney> saves me having to get up :-)
[20:33] <seb128> Laney, I just ran into the missing patch trying to debug the "rb hang on start" :p
[20:33] <seb128> I applied it locally, so no hurry ;-)
[20:52] <seb128> desrt, Laney: do you have a !Ubuntu GNOME in a install/vm/jhbuild/... to test something?
[20:52] <seb128> ups
[20:52] <seb128> desrt, larsu I meant
[20:52] <seb128> Laney, sorry ;-)
[20:53] <desrt> seb128: larsu has ubuntugnome i think
[20:53] <desrt> oh.. you want non-ubuntu gnome
[20:53] <seb128> desrt, not good enough ;-)
[20:53] <desrt> i can help with that, ya
[20:54] <larsu> desrt: seb128: nope, real ubuntu here
[20:54] <desrt> larsu, fortunately, is back on unity
[20:54]  * larsu is dogfooding indicators
[20:54] <desrt> gives a bit more credibility to you acting as the represenitive of the unity project in xdg affairs, as well :)
[20:55] <larsu> ya, I guess so :)
[20:55] <desrt> seb128: what do you need to know?
[20:55] <seb128> desrt, does calling /org/gnome/SettingsDaemon/MediaKeys org.gnome.SettingsDaemon.MediaKeys GrabMediaPlayerKeys ("test", 0) in dbus hang as well there?
[20:55] <seb128> calling that makes a GetAll() call it seems
[20:55]  * thumper waves to desrt and seb128
[20:55] <desrt> seb128: refer all GetAll bugs to Laney :)
[20:55] <desrt> thumper: hey!
[20:56] <seb128> desrt, oh, is that your glib bug?
[20:56] <desrt> may be
[20:56] <desrt> the issue is as follows:
[20:56] <desrt> the logic of my patch is that if 'property_get' in your DBus vtable is NULL then we dispatch all valid property calls via the method call handler
[20:57] <Laney> that patch isn't in saucy yet
[20:57] <desrt> we still check that Get and Set are for valid properties
[20:57] <desrt> but if GetAll comes, it is accepted even if there are no properties
[20:57] <desrt> so if your intention was to export a methods-only interface (which is quite common) then you're gonna have a bad time
[20:57] <desrt> what makes it really deadly is that GDBusProxy issues a GetAll on initialisation
[20:58] <seb128> desrt, the bug I'm looking at is that GrabMediaPlayerKeys end up calling https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/media-keys/gsd-media-keys-manager.c#n1546
[20:58] <seb128> which returns nothing
[20:58] <seb128> so it hits timeout
[20:58] <seb128> well that function is called with method_name = GetAll
[20:58] <seb128> which is not handled by the function
[20:59] <desrt> seb128: ya.... sounds like my problem
[20:59] <seb128> right
[20:59] <seb128> which makes sense
[20:59] <seb128> that code didn't change since raring
[20:59] <desrt>  because nobody is generating the reply now
[20:59] <Laney> try glib from proposed then
[20:59] <seb128> I was wondering why rb is hanging on start
[20:59] <desrt> so the call hangs
[20:59] <seb128> right
[20:59] <desrt> https://git.gnome.org/browse/glib/commit/?id=cb4469600c5146a48501a31e9a3fb9bfc261477d
[20:59] <seb128> desrt, Laney: thanks
[20:59] <seb128> desrt, Laney uploaded, I will grab the deb
[21:05] <seb128> Laney, desrt: yeah, that glib update fixes it
[21:05] <seb128> one less issue to debug \o/
[21:06] <Laney> woo
[21:06] <desrt> happy to help :)
[21:08]  * desrt has a "bugs seb will hit tomororow" predictor
[21:16] <seb128> thumper, hey ;-)