[00:02]  * Chipzz feels a very strong urge to break the CoC wrt fargiolas
[00:02] <Chipzz> *bleep* *bleep* *bleeeeeeeeep*
[00:03] <cjwatson> Chipzz: I would appreciate it if you put an end to your comments on the subject here
[00:03] <Chipzz> cjwatson: ^^^ I censored myself :)
[00:03] <cjwatson> I responded because I was addressed. You were not
[01:02] <Aquina> hy
[01:49] <ScottK> I wish if someone were going to do a complete giveback of all the build failures in the archive (I think that's what's happened) they'd have given some warning.  I certainly wouldn't have spent all the time over the last 3 week carefully picking through for retries worth doing.
[01:54] <ScottK> If LP is at all right this'll take two weeks to build out.
[01:55] <wgrant> ScottK: Keep in mind that lots of stuff will likely fail early.
[01:55] <ScottK> True.
[01:55] <ScottK> I realize it'll likely be much less.
[01:55] <wgrant> And hppa and sparc are special.
[01:56] <ScottK> Actually I think most of what's there will fail.  I wasn't kidding about spending the last 3 weeks going through failures looking for stuff to retry.
[01:56] <ScottK> Just finished today.
[01:56] <wgrant> Oh wow. That's a lot of queued builds...
[01:57] <ScottK> Yes.  It's a retry on every single FTBFS for Jaunty.
[01:57] <directhex> any way to abort the attempted rebuilds?
[01:57] <wgrant> Not without SQL access.
[01:58] <bluefoxicy> is it possible to package VirtualBox OSE on Ubuntu CDs such that they run from INSIDE WINDOWS when you pop them in?
[01:58] <ScottK> https://launchpad.net/ubuntu/jaunty/+builds?build_text=&build_state=failed doesn't know about a FTBFS more than ~1 hour old.
[01:58] <bluefoxicy> seeing as QT is GPL now
[01:58] <directhex> bluefoxicy, not sensibly. need drivers & reboots to install virtualbox on windows
[01:59] <ScottK> bluefoxicy: Qt has been GPL for year.
[01:59] <ScottK> years even.
[01:59] <bluefoxicy> scottK:  It's always had a restrictive Windows license
[01:59] <ScottK> bluefoxicy: How is that even possible.
[01:59] <bluefoxicy> Well, a commercial entity controlled Qt
[01:59] <ScottK> It can't be GPL unless you run Windows.
[02:00] <ScottK> That's not GPL.
[02:00] <bluefoxicy> so they published the Linux version as GPL, and patched it to run on Windows but only distributed binaries of that, under a restrictive license
[02:00] <ScottK> I suspect what you're thinking of is it's now LGPL.
[02:00] <bluefoxicy> possibly
[02:00] <ScottK> I don't think so.
[02:00] <bluefoxicy> my brain may be busted.
[02:00] <ScottK> You can run KDE on Windows with no problem.
[02:00] <bluefoxicy> I know the Linux version had a different license
[02:00] <directhex> ScottK, the qt3 license certainly used to be gpl-or-proprietary, with the windows port only available as proprietary. there were efforts to port the gpl version, but they, erm, sucked
[02:01] <ScottK> OK.  Qt3 is not been developed in a long time.
[02:01] <directhex> didn't say it was. just sayin'...
[02:01] <ScottK> For Qt3 I think you're correct.
[02:01] <bluefoxicy> directhex:  also there's lots of install-and-run software (openoffice) on the Ubuntu CDs
[02:01] <bluefoxicy> wouldn't installing a driver fall under install-and-run?
[02:02] <ScottK> Licensing for Qt3 hasn't changed.
[02:02] <bluefoxicy> and preconfigure the installed VBox to have a "boot LiveCD with 384M RAM" option
[02:02] <ScottK> Licensing for Qt4.4 hasn't changed either.  LGPL is only Qt4.5.
[02:04]  * ScottK isn't kidding about being disheartened about a couple of dozen hours of work over the last several weeks turning out to be totally unnecessary.
[02:05] <directhex> the blanket rebuild must've been queued y someone who doesn't pay their server power bills
[02:08] <ScottK> This does cause some actual problems for how we'd planned on doing the KDE 4.2.1 upload next week.
[02:08] <ScottK> Urgh.
[02:12] <ScottK> So far 2 successes, 252 failures.
[02:13] <directhex> ScottK, totally worthwhile!
[02:15] <wgrant> ScottK: How do you calculate that?
[02:15] <wgrant> There's no way to sort builds lists, AFAICT.
[02:16] <wgrant> Ah, through +history?
[02:16] <ScottK> https://launchpad.net/ubuntu/jaunty/+builds?build_text=&build_state=built and python-cjson was a fresh upload.
[02:16] <ScottK> Any success after that is the retries
[02:16] <Aquina> Short westion: Where are these outputs on system startup generated? I wanna modify them.
[02:17] <ScottK> And then all of https://launchpad.net/ubuntu/jaunty/+builds?build_text=&build_state=failed are from the retries
[02:17] <wgrant> There's nothing after that.
[02:17] <wgrant> Oh. WTF.
[02:17] <wgrant> Why does it sort differently depending on the filter?
[02:18] <Aquina> (posted in #ubuntu before): Someone knows where the usplash messages come from? I removed the parameter "quiet" from defoptions ind menu.lst. I searched through all the /etc/init.d/ scripts but couldnt find these messages printed. Search engines didn't help. Please do you...
[02:18] <wgrant> Compare state=built and state=all.
[02:18] <ScottK> It's interesting that the time sort isn't correct.
[02:18] <wgrant> Which time sort?
[02:19] <wgrant> AFAICT for state != all, the key is start time.
[02:19] <wgrant> For state == all, the key is queue time.
[02:19] <wgrant> (I think)(
[02:19] <ScottK> The failed ones were not entirely in time sequence
[02:20] <ScottK> All doesn't seem to show failures.
[02:20] <ScottK> Ah.  That'd make sort of sense.
[02:21] <wgrant> I think it does.
[02:21] <wgrant> But nothing queued recently has failed.
[02:21] <ScottK> BTW, every one of the build failures will land in one or two inboxes too.
[02:21] <wgrant> Oh yes, I know this well.
[02:21] <ScottK> I wonder if this is revenge for me filing a bug about notification of translations success spamming my inbox.
[02:22] <StevenK> I seriously doubt that
[02:22]  * ScottK was kidding
[02:22] <wgrant> Even I have to doubt that :P
[02:22] <ScottK> StevenK: Do you know why this was done?
[02:23] <wgrant> Mass-givebacks happen.
[02:23] <StevenK> What wgrant said
[02:23] <wgrant> Frequently.
[02:23] <ScottK> BTW, I was looking at the failures wrong.  They are sorted by fail time.
[02:23] <StevenK> Mass-givebacks are done at points throughout the cycle
[02:28]  * wgrant likes how the distribution build failure list is preceded by empty build records created by the unembargoing process.
[02:34] <mluser-home> Anyone know how I can disable pulseaudio system wide?
[02:34] <wgrant> mluser-home: This is not the correct channel.
[02:35] <mluser-home> wgrant: sorry
[02:35] <wgrant> You want #ubuntu, or to realise that you don't want to disable PulseAudio system wide.
[02:35] <mluser-home> I'm having this problem in Jaunty, and I thought #ubuntu was just for hardy and intrepid
[02:35] <wgrant> #ubuntu+1, then.
[02:36] <mluser-home> wgrant: thanks again
[02:36] <wgrant> np
[03:33] <calc> bryce: i don't think bug 322202 is UXA specifc
[03:48] <jdong_> installer gods: We should have a brown-and-orange color scheme for the alt installer :)
[03:54] <LaserJock> heck yeah
[03:55] <jdong_> dear virtualbox: Please stop turning green when I resize you.
[04:00] <jdong_> whee relabel ahoy
[05:37] <Codd> I just installed jaunty Alpha 5 on my machine (clean install) and I'm noticing that every once in a while cpu usage spikes for just a second and everything locks up (GUI, background tasks,mp3 playing, video, downloads) and then it all returns to normal.  If I load a complex ajax page in firefox the cpu still goes upto 99% but I don't get a lock up,   Right now it seems to occur when I play media files (xvid, mp3) I formatted usin
[05:40] <dtchen_> Codd: if the symptom is persistent when playing/recording audio, there's a known issue in the current jaunty pulseaudio package causing the daemon to spin in a tight loop due to bogus data being passed from the sound driver. it has been fixed in a bzr branch and will land in the next upload.
[05:47] <Codd> dtchen_: sweet it does look like pulseaudio is bouncing around alot in top, I guess since the system was freezing up I didn't see it peak :)  I'm loving the new release though, keep up the amazing work!
[06:14] <calc> anyone know of an easy way to determine how much space on a disk a certain file type is taking up?
[06:15] <calc> eg all jpg's, etc
[06:41] <Hobbsee> calc: du?
[06:43] <Hobbsee> calc: looks like you want du, -c, and probably a few other switches
[06:43] <calc> i found a script that does it with find and awk
[06:43] <calc> just have to determine how to make it work with spaces in filenames :\
[06:44] <calc> resetting IFS seems to break it too much
[06:48] <calc> cool -print0 and xargs -0 is your friend :)
[07:00] <maco> calc: for dealing with odd characters in filenames: http://calypso.tux.org/pipermail/novalug/2009-February/017524.html
[07:01]  * jdong_ thinks one should not be scripting in such ambiguous languages anyway :)
[07:01] <maco> also, anyone using the sidebar for firefox?
[07:01] <jdong_> anything accepting user input that doesn't take explicit typed-list style arguments is broken for today's environment.
[07:01] <maco> the all-in-one sidebar?
[07:03] <TheMuso> c
[07:04] <jdong_> Open Mailbox ('?' for list):
[07:34] <maco> ah sorry thought i was in #ubuntu+1 before
[08:06] <fargiolas> cjwatson: I usually don't ask for support here. it was a particular case where I needed to know a thing that only the involved ubuntu developer could know so I asked here. I could have probably found the answer myself but I was tired after hours fighting with a broken windows installation and not able to concentrate anymore, this could also explain why I may have seemed unpolite.
[08:15] <fargiolas> cjwatson: also I still believe it was not a support question. It was more a question about an ubuntu-specific implementation detail. I'm really sorry I was OT here.. I did it in good faith.
[08:17] <cjwatson> let's call an end to it :)
[08:18]  * cjwatson doesn't really want to continue the argument
[08:18] <fargiolas> cjwatson: me neither :)
[10:03] <savvas> hi, which is the default administration group? adm?
[10:31] <ogra> savvas, adm is used for access to logfiles only
[10:32] <savvas> ah thanks
[10:32] <ogra> if you mean the group that has sudo access by default, thats "admin"
[10:32] <savvas> that's it :)
[11:09] <RainCT> doko: Thanks for the tip. I tried to fix that yesterday but didn't get it to work (each build takes half an hour..)
[11:35] <Hobbsee> kirkland: found you a bug.  it's your lucky day!
[11:45] <StevenK> doko: Want to commit/push your changes to launchpad-integration into bzr?
[13:04] <RainCT> Why does notify-osd leave space for an image when there isn't one?
[13:05] <RainCT> the bubble is already small enough as to waste more space like this
[16:22] <kirkland> Hobbsee: ping
[16:22] <kirkland> Hobbsee: Could you try editing /usr/share/screen-profiles/profiles/ubuntu-black
[16:22] <kirkland> and changing "~" to "$HOME", and see if that works?
[16:23] <kirkland> Hobbsee: If so, this is a very easy fix...
[16:34] <ion_> dpkg dependencies don’t allow one to depend on (ruby1.8, libjson-ruby1.8) OR ruby1.9, do they?
[16:35] <directhex> you could work around that with a metapackage
[16:36] <directhex> i.e. myapp-ruby1.8 | ruby1.9, where myapp-ruby1.8 has no contents & only a dep on ruby1.8, libjson-ruby1.8
[16:36] <directhex> or wouldn't a dep on libjson-ruby1.8 pull in ruby1.8?
[16:36] <ion_> Nope, only libruby1.8, which doesn’t include the binary.
[17:25] <ilowe> Do Ubuntu devs prefer to receive new packages into Ubuntu or should they go upstream to the Debian repos first?
[17:25] <directhex> ilowe, generally, the latter
[17:26] <ilowe> directhex: thanks; so I should follow the procedure to get the package accepted into Debian and it will just get pulled down into Ubuntu (in theory at some point in the future)?
[17:27] <directhex> ilowe, that's the best way for everyone - so debian & debian-based dists also gain from your work
[17:27] <directhex> ilowe, but delays can sometimes make it a sucky route
[17:28] <ilowe> Cool, thanks. I'll start with that and see how the delays go :)
[17:29] <directhex> ilowe, given where we are now, you have about 5 months for automatic syncing into ubuntu 9.10
[17:30] <ilowe> yikes....it's more an issue of having the package available on my own systems; I guess I'll keep it in my local repos while it makes it's way into Ubuntu
[17:30] <directhex> ilowe, yes, that can work - the ubuntu PPA system allows you to build a personal repo available to everyone
[17:31] <ilowe> hmmm... then, would I propose to Debian *and* upload to a PPA? In which case would I just abandon the package in the PPA once it reaches Ubuntu?
[17:31] <ScottK> Since we're past feature freeze for 9.04 working through Debian now won't actually make it take longer.
[17:32] <ilowe> ScottK: I'm more trying to get a handle on how the repos get updated; not to worried about official releases
[17:32] <directhex> ScottK, right now, i don't know whether i'd agree. NEW is... taking its time. assuming no delays getting as far as NEW
[17:33] <ScottK> directhex: It's also just after a release in Debian, so no suprise.
[17:33] <ScottK> ilowe: If you get your package into Debian it will automatically come into Ubuntu in the next release.
[17:38] <slytherin> are daily iso builds for ports architectures turned off?
[17:40] <Nafallo> I believe so yes.
[17:46] <slytherin> Nafallo: any particular reason?
[17:46] <ScottK> Yes.
[17:46] <Nafallo> slytherin: ports.ubuntu.com have been struggling a bit.
[17:47] <slytherin> oh
[17:47] <ScottK> There was a locking problem that caused all CD builds to fail.
[17:47] <ScottK> So they had to turn off ports.
[17:53] <slytherin> ScottK: thanks for info
[18:24] <ilowe> http://tinyurl.com/dkrvw7 states that the original package name should be <pkg>-<ver> but the resulting name should be <pkg>_<ver>; if I maintain the upstream as well, should I be naming my package <pkg>-<ver> and updating it in the .deb or can I name it <pkg>_<ver>? dh_make chokes on the "_" version when doing the initial debianization
[18:28] <geser> ilowe: the upstream tarball should unpack to <pkgname>-<upstreamversion>
[18:28] <ilowe> geser: thanks
[18:28] <geser> and the tarball itself has to be named <pkgname>_<upstreamversion>.orig.tar.gz
[18:29] <ilowe> OK, but that will get generated by dh_make? I have a proper <pkg>-<ver>.tar.gz file.
[18:29] <geser> the _ is used as separator in package files
[18:29] <geser> ilowe: dh_make will make then a symlink to your <pkg>-<ver>.tar.gz
[18:30] <ilowe> cool, thanks
[19:41] <Notch-1> hi, since i made a loop/raid root filesystem the hibernation stopped working, any idea on where to put loop/raid information to properly restore the system?
[20:53] <NCommander> hey all
[20:54] <jpds> Hey NCommander.
[20:54] <NCommander> hey jpds
[20:54]  * NCommander has just upgraded his VAIO :-)
[20:56] <RainCT> NCommander: upgraded = to Jaunty?
[20:56] <NCommander> RainCT, no, hardware
[20:56] <RainCT> ah
[20:56] <NCommander> Total of 4GB, and a half a TB of disk space :-)
[20:56]  * NCommander is waiting for Xubuntu 9.04 A5 to download
[20:57] <RainCT> nice :)
[20:58] <NCommander> Yup
[21:07] <hunger> Is there a trick to get fglrx running in jaunty?
[21:08] <stgraber> hunger: no trick, you just need to wait.
[21:08] <hunger> stgraber: Would have been nice to mention that in the release notes of alpha5.
[21:09] <stgraber> "A new XServer, version 1.6, is included in Alpha 4. The binary proprietary fglrx driver is not yet supported for this server and will exhibit various serious issues if run against it. Users of this driver are encouraged to wait or to switch to the open source -ati driver in the meantime. 313027"
[21:09] <stgraber> from the release notes for alpha-5
[21:09] <stgraber> http://www.ubuntu.com/testing/jaunty/alpha5#Known%20issues
[21:11] <hunger> stgraber: Hmmm... you are right. I read the kubuntu release notes. They do not mention this little fact.
[21:14] <DetlefvomBahnhof> hallo
[21:47] <ia> hello. Have someone (from developers) clashed with this bug - https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/335953 ? I asking about it, because would like, that someone from developers check this bug; I think, that problems in interfaces of apps - one of valuable and primary issues, that should be fixed (cause interface - it's a face of distro)
[21:57] <cjwatson> ion_: apply boolean logic. (ruby1.8, libjson-ruby1.8) | ruby1.9 -> ruby1.8 | ruby1.9, libjson-ruby1.8 | ruby1.9


[10:20]  * Chipaca takes a break
[11:05] <facubatista> ¡Muy buenos días a todos!
[11:08] <bthomas> नमस्ते facubatista
[11:08] <facubatista> hola bthomas
[11:27]  * facubatista begs a 2nd review one https://github.com/canonical/operator/pull/425
[11:27] <mup> PR #425: Fixed several small details in lot of docstrings <Created by facundobatista> <https://github.com/canonical/operator/pull/425>
[11:29] <bthomas> done reviewing 425
[11:35] <facubatista> bthomas, thanks!
[11:35]  * facubatista begs a review on https://github.com/canonical/charmcraft/pull/171
[11:35] <mup> PR charmcraft#171: Improvements per ux review <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/171>
[12:39] <mup> PR operator#425 closed: Fixed several small details in lot of docstrings <Created by facundobatista> <Merged by facundobatista> <https://github.com/canonical/operator/pull/425>
[12:42] <facubatista> Chipaca, how are you running the OF tests these days? I get failures in the test.test_infra.ImportersTestCase.test_imports tests
[12:43] <Chipaca> facubatista: ./run_tests works, as does python3 -m unittest, as does pytest
[12:43] <facubatista> Chipaca, it doesn't here
[12:43] <Chipaca> facubatista: you're holding it wrong
[12:44] <Chipaca> facubatista: how are you trying to run them?
[12:44] <facubatista> Chipaca, `./run_tests` inside the venv
[12:44] <Chipaca> facubatista: how do you create the venv?
[12:45] <facubatista> Chipaca, following exactly the instructions in the README
[12:45] <Chipaca> facubatista: what's the output of printenv | grep ^PY | sort ?
[12:45] <facubatista> PYTHONPATH=/home/facundo/.bin/pymods
[12:45] <facubatista> PYTHONSTARTUP=/home/facundo/.pythonrc
[12:46] <Chipaca> facubatista: what happens if you «PYTHONPATH="" ./run_tests» ?
[12:47] <facubatista> same, fail
[12:47] <Chipaca> facubatista: can you pastebin the failure please
[12:47] <facubatista>     self.assertEqual(proc.returncode, 0)
[12:47] <facubatista> AssertionError: 1 != 0
[12:48] <facubatista> I'm suspecting what it can be, though
[12:49] <facubatista>             env={'PYTHONPATH': os.getcwd(), **os.environ})
[12:49] <facubatista> Chipaca, ^, if PYTHONPATH in environ, it's not getting what is set
[12:50] <Chipaca> facubatista: ah, so if you «unset PYTHONPATH» it works? ?
[12:51] <facubatista> yeap
[12:53] <Chipaca> facubatista: easy to fix
[12:53] <facubatista> right, removing those tests!
[12:53]  * facubatista hides
[12:53] <Chipaca> facubatista: i'll push a pr in a bit
[12:53] <facubatista> Chipaca, https://github.com/canonical/operator/pull/426
[12:53] <mup> PR #426: Fixed environment in the import tests <Created by facundobatista> <https://github.com/canonical/operator/pull/426>
[12:53] <Chipaca> or that
[12:54] <mup> PR operator#426 opened: Fixed environment in the import tests <Created by facundobatista> <https://github.com/canonical/operator/pull/426>
[12:54] <Chipaca> facubatista: prepend, not append, plz?
[12:54] <Chipaca> facubatista: and use os.pathsep, not ':'
[12:54] <facubatista> ack
[12:57] <facubatista> this will be shorter and more expressive in py3.9
[12:59] <facubatista> Chipaca, pushed
[13:31] <Chipaca> facubatista: how does it look in 3.9?
[13:33] <facubatista> Chipaca, you can "merge" dicts with '|'
[13:34] <Chipaca> facubatista: but we'd still need to join rather than replace PYTHONPATH
[13:34] <facubatista> yeap, but it will be something like
[13:35] <facubatista> ppath = os.getcwd() + os.pathsep + os.environ('PYTHONPATH', '')
[13:35] <facubatista> subprocess(..., env=os.environ | {'PYTHONPATH': ppath})
[13:35] <facubatista> anyway
[14:34] <mup> PR operator#426 closed: Fixed environment in the import tests <Created by facundobatista> <Merged by facundobatista> <https://github.com/canonical/operator/pull/426>
[14:49] <mup> PR operator#427 opened: A bunch of module level docstrings <Created by facundobatista> <https://github.com/canonical/operator/pull/427>
[14:59] <facubatista> Chipaca, bthomas, justinclark, review appreciated, thanks! https://github.com/canonical/charmcraft/pull/173
[14:59] <mup> PR charmcraft#173: Load only the indicated command (if any), not everything in advance <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/173>
[15:00] <Chipaca> i need to run off to the boys' school
[15:00] <Chipaca> aren't i lucky
[15:03] <facubatista> ages since I haven't read that
[15:05] <Chipaca> facubatista: which that?
[15:05] <Chipaca> facubatista: <3 that pr, so many things fixed
[15:05] <facubatista> Chipaca, people going to kid's school
[15:06] <Chipaca> hehe
[15:06] <Chipaca> facubatista: it's weird and slightly terrifying, but it is
[15:06] <Chipaca> anyway, i need to go
[15:06] <Chipaca> ttfn! ttyl
[22:03]  * facubatista eods
[22:03] <facubatista> and eows! see you all on monday


[00:46] <user|90> Kubuntu 20.04.4 5.13.0-40-generic after update
[00:46] <user|90> could not restart kubuntu, stuck on logo with pulsating blue
[00:46] <user|90> what can you do to repair?
[06:34] <lordievader> Good morning
 Maybe with live environment restore your grub (re @IrcsomeBot: <user|90> what can you do to repair?)
 And how should be on youtube or google (re @TechSavvy: Maybe with live environment restore your grub)
 @<user|90> Have you tried booting from previous kernel version ?
[08:18] <v4mp> is there any way to get gtk2 icon environment variable to properly set in a *.desktop file?  been scratching my head over this for a while.  I've set my exec like:  Exec=env gtk-icon-theme-name="breeze-dark" /opt/myapps/bin/myapp    but the icon theme is still set to global theme
[09:58] <user|81> I can't find option for reinstallation in kubuntu 20.04 Lts via live usb. I won't format my disk.
 On same page as global theme you'll find icons. Install different icon set if you want. You can mix theme icon and windows decoration. (re @IrcsomeBot: <v4mp> is there any way to get gtk2 icon environment variable to properly set in a *.desktop file?  been scratching my head over this for a while.  I've set my exec like:  Exec=env gtk-icon-theme-name="breeze-dark" /opt/myapps/bin/myapp    but the icon theme is still set to global theme)
[12:06] <BluesKaj> Hi all
 msdsn
 o1um
 01um
 01UM
 oxkt
 hey guys! I am on the newest Kubuntu LTS version and cant get torbrowser-launcher to start.
 user@T430:~$ torbrowser-launcher
 Tor Browser Launcher
 Von Micah Lee, lizensiert unter MIT
 Version 0.3.3
 https://github.com/micahflee/torbrowser-launcher
 The script likely needs fixing for the changes in python 3.10. There were similar errors in the Kubuntu installer until they were fixed
[19:31] <user|57> Hi which usb making tool is best for kubuntu?
[19:32] <Dragnslcr> For making what exactly?
[19:34] <user|57> to put the image on a usb to can boot from the stick
[21:33] <mparillo> dd if you are careful


[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-<IP_ADDRESS>
[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:<IP_ADDRESS>1),
[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-<IP_ADDRESS>/+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-<IP_ADDRESS>/+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.    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 ;-)