[05:17] <pitti> Good moring
[06:16] <darkxst> hey pitti
[06:19] <darkxst> pitti, could you take a look at https://code.launchpad.net/~darkxst/ubuntu/trusty/gnome-settings-daemon/lp1265127
[06:21] <pitti> darkxst: queueing for today
[06:21] <darkxst> pitti, thanks
[07:25] <mlankhorst> early morning hacking is best hacking :)
[07:32] <pitti> mlankhorst: +1
[08:33] <ritz> is it just me, or is gnome-shell staeel like unity ?
[08:33] <ritz> stating*
[08:33] <ritz> starting* to
[08:35] <hyperair> uh no, there were accusations of gnome-shell copying unity from some time back.
[08:37] <darkxst> hyperair, or the other way around!
[08:38] <hyperair> well, considering unity had its roots in the ubuntu network remix, i'm inclined to think that unity started first.
[08:38] <hyperair> er netbook
[08:39] <hyperair> what i particularly find funny are the comments that compiz is bloated and slow, and people should use mutter, when compiz sans unity used to run at 20MB RSZ.
[08:40] <hyperair> if anything, it was unity that slapped on all the bloat onto compiz.
[08:40] <hyperair> from RSZ went from 20MB to 100+MB
[08:42] <darkxst> hyperair, pretty sure the overall design concept of gnome-shell predates the netbook stuff
[08:43] <hyperair> bah
[08:43] <hyperair> this war never ends
[08:44] <darkxst> no war!
[08:45] <darkxst> I refuse to participate in the "I dislike feature X, so therefore nobody likes it" rubbish
[08:46] <hyperair> isn't that why we're getting a spanking new file manager?
[08:46] <hyperair> what comes next anyway? a new evince?
[08:46] <ali1234> hyperair: not compiz sans unity. compiz sans c++
[08:47] <hyperair> ali1234: nope.
[08:47] <ali1234> yes.
[08:47] <hyperair> ali1234: compiz with c++ was still at 20MB RSZ
[08:48] <hyperair> i was compiling daily compiz++ builds on my machine
[08:48] <hyperair> and using that before unity came along
[08:48] <hyperair> so i know this for a fact.
[08:48] <darkxst> hyperair, not real sure, I just cheer everytime a new component is announced, since that another we (ubuntu GNOME) can move to tracking upstream ;)
[08:48] <hyperair> lol
[08:49] <hyperair> the current situation between indicator and tray icon is a bit crappy
[08:49] <darkxst> with mir/unity8 the only remaining painpoint right now is gnome-desktop3
[08:49] <darkxst> hyperair, gnome-shell doesnt really have tray icons in the traditional sense
[08:49] <hyperair> pretty much all of the tray icon apps have been patched to use indicators, but the UX for indicators suck in gnome shell
[08:49] <hyperair> er well, the notification bar thing at the bottom right.
[08:50] <hyperair> they work much better as tray icons than as indicators
[08:50] <hyperair> indicators are menus, whereas those things in the gnome shell notification bar don't really fit in as menus
[08:51] <hyperair> which just makes the situation pretty damn crappy when attempting to use gnome-shell
[08:52] <darkxst> hyperair, each to their own, I would rather not have 100 icons in my tray
[08:52] <ali1234> notification icons also cannot support multimonitor
[08:52] <darkxst> and menus on tray icons seem kinda pointless
[08:52] <hyperair> darkxst: you could hardly fit 100 of them in the tray
[08:53]  * hyperair shrugs. i'm using unity happily despite my gripes
[08:53] <hyperair> my solution was to just bump my RAM up as high as i could go
[08:53] <hyperair> because apparently nobody working on desktop unity had low-ram constraints.
[08:54] <hyperair> which is why the indicators can take several hundred megabytes of memory at a time until they're killed
[08:54] <hyperair> and notify-osd leaks til today
[08:54] <darkxst> ^nobody full stop!
[08:54] <ali1234> i like to fix memory leaks - which ones are leaky?
[08:54] <darkxst> I running 32GB on desktop, 8GB on laptop
[08:54] <hyperair> darkxst: hey 4GB of RAM isn't what i call low-RAM, but it's painful to run unity on even that kind of spec.
[08:55] <darkxst> hyperair, gnome-shell runs well on 4GB :)
[08:55] <hyperair> darkxst: it's only when i hit 8GB that i stopped caring so much for the memleaks
[08:55] <hyperair> yeah well, it also sucks more
[08:55] <hyperair> i really like the super+1,2,3,4,5,6,7,8,9,0 for the first 10 windows in the launcher that you get in unity
[08:55] <hyperair> which gnome shell doesn't seem to be picking up for whatever reason
[08:56] <hyperair> so screw that, i'm sticking with unity
[08:56] <darkxst> hyperair, most of my VM's get 2GB, but they don't really run the extra RAM blood suckers like firefox, libreoffice
[08:56] <hyperair> darkxst: yeah then that doesn't count.
[08:56] <hyperair> ever tried running chromium and thunderbird together?
[08:56] <hyperair> i had 8GB of RAM, and i was so frustrated with the overall memory usage i went to mutt
[08:56] <mlankhorst> it does count..
[08:56] <hyperair> it was a good move though
[08:57] <darkxst> hyperair, sure, but that makes the whole leaky DE thing, null and void!
[08:57] <hyperair> pfft.
[08:57] <hyperair> when you can't run a browser and an email client concurrently on 4GB of RAM, the situation is fscked up.
[08:58] <ali1234> xubuntu discussed increasing the minimum requirement to 1GB this cycle, almost entirely because of firefox
[08:58] <hyperair> derp 1GB.
[08:58] <darkxst> firefox leaks like a sieve
[08:58] <hyperair> hyper derp.
[08:59] <hyperair> not as bad as thunderbird.
[08:59] <hyperair> no actually firefox didn't leak much for me
[08:59] <hyperair> it just had consistently high memory consumption
[08:59] <mlankhorst> try firefox without javascript
[08:59] <darkxst> sure its the 3rd party firefox that leaks!
[08:59] <hyperair> i hate you.
[09:00] <darkxst> and the rubbish GC, but that is getting fixed ;)
[09:00] <ali1234> "try not going on any websites, it will really reduce the memory use"
[09:00] <hyperair> lol
[09:00] <hyperair> thunderbird's awesome. you should see it trying to fetch lkml from gmane.
[09:00] <darkxst> ali1234, switching off computer elimates memory usage!
[09:00] <hyperair> it goes past 4GB of RAM usage, and grinds the CPU for over half a day
[09:01] <ali1234> that's exactly what happens when i try to connect it to my gmail account
[09:01] <hyperair> and oh yeah chromium actually takes more RAM than firefox
[09:01] <darkxst> I've never seen thunderbird get past 1GB
[09:01] <hyperair> but firefox operates a hell lot slower
[09:01] <hyperair> darkxst: you haven't opened big enough folders
[09:01] <hyperair> my gmail's all mail folder made claws-mail rise to 500+MB
[09:01] <darkxst> I only use it for IMAP accounts
[09:01] <hyperair> yeah so was i
[09:01] <hyperair> except for nntp
[09:02] <darkxst> probably 10GB all up
[09:02] <hyperair> anyway it was thunderbid that leaked like a sieve. firefox was mostly decent.
[09:11] <tjaalton> sigh, so which package trumps the user settings like focus-follows-mouse on upgrades?
[09:12] <tjaalton> it gets reset every now and then
[09:13] <pitti> tjaalton: bug 1063617
[09:13] <ubot2`> Launchpad bug 1063617 in Compiz 0.9.9 "1:0.9.8+bzr3319-0ubuntu1 regression: keeps setting gsettings keys to wrong values" [High,Fix committed] https://launchpad.net/bugs/1063617
[09:13] <pitti> it's ancient
[09:13] <tjaalton> ahh, thanks
[09:14] <tjaalton> yeah it is
[09:14] <pitti> I have a couple of "gsettings set" commands in my "start my session" script
[09:14] <tjaalton> huh, now I lost my desktop grid
[09:16] <tjaalton> marked fix released
[09:16] <tjaalton> but I'm on trusty
[09:21] <seb128> larsu, bug #1277370
[09:21] <ubot2`> Launchpad bug 1277370 in evince (Ubuntu) "Now used Aiatana design blocks Evince accessibility usage if the current session is not Unity" [Undecided,New] https://launchpad.net/bugs/1277370
[09:21] <Laney> HMM!
[09:21] <seb128> Laney, HMM?
[09:21] <Laney> getting a partial upgrade that I think is mir/xorg
[09:21] <larsu> Laney: morning!
[09:21] <Laney> did you see that?
[09:21] <Laney> o hai
[09:21] <seb128> yes
[09:23] <Laney> also
[09:23] <Laney> happyaron: E: Unable to locate package libreoffice-help-en-us
[09:23] <Laney> E: config/hooks/100-ubuntukylin.chroot failed (exit non-zero). You should check for errors.
[09:23] <seb128> it wants to uninstall the old soname version
[09:23] <Laney> aaaaaaand
[09:24] <Laney> The following packages have unmet dependencies: xserver-xorg-input-synaptics : Breaks: kde-config-touchpad (< 0.8.1-2~) but 0.8.1-1ubuntu6 is to be installed
[09:24] <Laney> kubuntu
[09:24] <Laney> today's image build failures
[09:24] <tjaalton> uh
[09:24] <seb128> ok, so all good
[09:24] <Laney> :P
[09:24] <seb128> ;-)
[09:24] <seb128> happy friday desktopers btw!
[09:24] <Laney> oh yeah!
[09:25] <tjaalton> tgif
[09:25] <pitti> bonjour seb128, ça va ?
[09:26] <pitti> seb128: you too!
[09:26] <seb128> pitti, hey, wie gehts?
[09:26] <pitti> seb128: gut, danke!
[09:26] <happyaron> Laney: got it, added to my list...
[09:26] <Laney> happyaron: I think they got renamed or removed or something?
[09:26] <pitti> much better than today's live CD, anyway -- compiz/unity are b0rked
[09:26] <Laney> hey pitti
[09:26] <pitti> no panel, no launcher, no window decorations
[09:26] <pitti> ctrl+alt+t (terminal) and nautilus work, though
[09:27] <Laney> sounds like the protobuf problem
[09:28] <happyaron> Laney: maybe, first day back from holiday and still catching up, :)
[09:28] <Laney> pitti: does it have the newest libprotobuf8?
[09:29] <pitti> ah no, -7ubuntu1
[09:30] <Laney> nod
[09:30] <pitti> http://cdimage.ubuntu.com/cdimage/daily-live/current/ is from today
[09:30] <pitti> and yet http://cdimage.ubuntu.com/cdimage/daily-live/current/trusty-desktop-amd64.manifest is old
[09:30] <Laney> the isos look old
[09:30] <pitti> oh right, amd64+mac is from today, but not the others
[09:31] <Laney> I wonder why this is
[09:32] <Laney> perhaps something was disabled for the point release
[09:32] <pitti> http://cdimage.ubuntu.com/cdimage/daily-live/pending/ are current
[09:32] <pitti> yep, failures on https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/
[09:32] <Laney> oh, I always forget about that
[09:33] <Laney> i don't understand the failure
[09:34] <pitti> I don't know exactly which tests are being looked at to promote an image to /current
[09:34] <pitti> but it seems the health-check ones didn't even run for the 06 and 07 build?
[09:34] <pitti> and they never succeeded anyway
[09:55] <seb128> xnox,         if (g_strcmp0 (g_getenv ("XDG_CURRENT_DESKTOP"), "GNOME") == 0
[09:56] <seb128> ... upstream code
[09:56] <seb128> else
[09:56] <seb128> ... ubuntu change
[09:58] <mpt> MacSlow, would it bother you at all if we switched to tracking Notify OSD bugs solely on the package <https://bugs.launchpad.net/ubuntu/+source/notify-osd>, no longer on the project? <https://bugs.launchpad.net/notify-osd>
[09:59] <seb128> robert_ancell, sudo apt-get -o Dpkg::Options::="--force-confmiss" install --reinstall gnome-settings-daemon
[09:59] <xnox> seb128: ack.
[09:59] <xnox> robert_ancell: where is the ubuntu-settings-daemon branch?
[09:59] <xnox> robert_ancell: such that i can use it.
[10:03] <robert_ancell> xnox, lp:~ubuntu-desktop/gnome-settings-daemon/unity and lp:~robert-ancell/gnome-settings-daemon/unity
[10:11] <darkxst> Hey Laney
[10:11] <Laney> hellllllllllllllloooooooooooooooooooooooooo
[10:11] <darkxst> hey seb128
[10:12] <seb128> hey darkxst
[10:13] <darkxst> seb128, can we land gnome-desktop transition next week? cant really wait on g-s-d fork, because we will just run out of time?
[10:17] <pitti> seb128: https://code.launchpad.net/~darkxst/ubuntu/trusty/gnome-settings-daemon/lp1265127/+merge/201995 sounds ok to me, any objection? darkxst replied to your question
[10:18] <seb128> darkxst, that involves that new dbus service for screen resolution handling?
[10:18] <seb128> pitti, looks fine to me, do you want to sponsor it?
[10:18] <pitti> seb128: yes
[10:19]  * pitti resolves conflicts as another versino got uploaded in between, but it's trivial
[10:19] <darkxst> seb128, yes, but its largely the same code moved to a different place
[10:19] <seb128> pitti, danke
[10:20] <darkxst> pitti, that MP is several weeks old now
[10:20] <seb128> darkxst, well, it's an infrastructure change, replacing a library by a dbus service
[10:20] <pitti> darkxst: yes, I didn't blame you :)
[10:20] <seb128> darkxst, did you sort out of the config migration question?
[10:21] <darkxst> seb128, I dont think that is worth the effort
[10:22] <darkxst> it would quite some work to make configs migrate and most people don't even use them
[10:23] <darkxst> the ones that do, have to reconfigure just once
[10:25] <seb128> I'm not convinced that transition is something we should do before the LTS...
[10:34] <darkxst> seb128, it has too happen on way or the other
[10:35] <seb128> "has to"
[10:35] <darkxst> obviously you guys don't need it but we do
[10:35] <seb128> not sure I agree with that, at least not this cycle
[10:37] <seb128> darkxst, what do you need in the new version?
[10:39] <pitti> I'm still baffled that upstream didn't provide a migration for configs -- how are distros  supposed to cope with that?
[10:41] <seb128> pitti, yeah, that's annoying
[10:42] <pitti> well, it's more than that
[10:44] <darkxst> seb128, well nothing specifically, but its more a case not spending the rest of the cycle backporting upstream fixes
[10:45] <seb128> the new version changes quite some apis, it's going to force us to update code in g-s-d u-s-d gnome-screensaver colord
[10:45] <seb128> there is the config migration issue
[10:45] <seb128> then it's a new architecture/dbus service, it's basically untested for us
[10:45] <seb128> that sounds like a risky change mid-cycle of a LTS
[10:46] <darkxst> seb128, right I can  deal with the api changes
[10:47] <seb128> thanks, but that doesn't resolve the other issues though
[10:47] <darkxst> seb128, and really, its seems to becoming, wait on this, wait on that, oh you have now run out of time!
[10:50] <darkxst> seb128, as much as I know you are trying to unblock these things for us, its just kinda frustrating at this point.
[10:51] <seb128> darkxst, there are conflicting needs, and we are working on solving that, that's why we are doing unity-control-center/unity-settings-center
[10:51] <seb128> but resources are what they are and it takes some time to get there
[10:51] <seb128> sorry about that, but I just don't see a way around
[10:52] <seb128> doing risky changes just before the LTS is not benefiting anyone I think
[10:52] <darkxst> seb128, I am well aware of all that, but really until gnome-desktop3 is in a state it can be forked we still have a big pain point right ther]
[10:53] <seb128> right, we have, I just don't see a way to resolve that in a non risky way before the LTS
[10:53] <seb128> risky or costy
[10:53] <pitti> well, if there is no migration path, how would you deal with the migration in ubuntu-gnome?
[10:54] <darkxst> hmm, is display config really that critical? 90% probably don't even use it
[10:55] <pitti> you mean the resoltion/monitor config? why would people not use that?
[10:55] <darkxst> the 10% that do, can spend ~3secs reconfiguring
[10:56] <MacSlow> mpt, that would be ok with me
[10:56] <darkxst> pitti, because it just works perhaps? how many go and mess with config in that case?
[10:56] <pitti> darkxst: I don't know numbers, I just know that on conferences pretty much everyone has to
[10:57] <MacSlow> mpt, would this change only for NotifyOSD or for all packages in general?
[10:57] <mpt> MacSlow, just NotifyOSD. It would match what the Touch-specific packages already do, for example.
[10:58] <seb128> darkxst, what "just works"? configuration is a custom thing, my docked config turns off my laptop screen when I dock it for example
[10:58] <pitti> darkxst: but yes, it certainly isn't an insurmountable pain, except that you have to re-configure with every device you already saw (monitors.xml is by device set, not a single configuration)
[10:58] <MacSlow> mpt, only funny is that NotifyOSD isn't really touch-specific at all :)
[10:58] <mpt> MacSlow, sure, that’s why I said “for example”. Ubiquity is another example.
[10:59] <mpt> MacSlow, anyway, thanks, I’ll do the refiling on Tuesday.
[10:59] <darkxst> seb128, that is a gsettings key atleast in shell, no reason that would change
[10:59] <MacSlow> mpt, ok
[10:59] <pitti> but really, why can't they leave in the old xml reading code for a cycle or two and do a live migration upstream?
[10:59] <seb128> darkxst, are you sure? the config is currently in ~/.config/monitors.xml
[11:00] <darkxst> seb128, was
[11:00] <seb128> well, currently in Ubuntu
[11:00] <seb128> we are talking about config migration
[11:00] <seb128> so what we have and how we keep those configs working on upgrade
[11:01] <darkxst> right, I get that
[11:06] <robert_ancell> fginther, I'm confused by the Jenkins failures for u-c-c (https://jenkins.qa.ubuntu.com/job/unity-control-center-trusty-amd64-ci/3/console). It's complaining about missing dependencies but I'm not sure if it's downloaded any of them
[11:09] <Laney> seb128: http://ci.ubuntu.com/smokeng/trusty/touch/mako/169:20140207:20140115.1/6492/ubuntu-system-settings-autopilot/746509/
[11:09] <Laney> :(((((((((((((
[11:10] <seb128> Laney, what did you do?!
[11:12] <Laney> bah!
[11:13] <darkxst> seb128, go ahead and feel free to fork gnome-desktop3 as well ;)
[11:13] <seb128> darkxst, it's less easy with a library...
[11:14] <seb128> darkxst, with what library would we build e.g colord
[11:14] <darkxst> seb128, I am working with upstream to move the important bits into gtk
[11:14] <seb128> great
[11:14] <darkxst> no idea what will happen with the bits that you guys are hanging on to though
[11:15] <darkxst> seb128, upstream wants gnome-desktop to only be used gnome-shell essentially
[11:17] <darkxst> which right now is really just the thumbnail module
[11:18] <darkxst> (excluding the others that are reverted in ubuntu like background etc)
[11:21] <seb128> darkxst, "only be used in" you mean?
[11:21] <darkxst> either way surely you can see why I get frustated? my g-c-c patches from last cycle are still waiting to land, although now half are unnecessary
[11:21] <seb128> yes, and as said I'm sorry about that
[11:21] <seb128> I just don't have a magical solution for you
[11:22] <darkxst> seb128, as in gnome-desktop should become a shared (private) library for gnome-shell, gdm, etc
[11:22] <darkxst> as in no apps should depend on it
[11:23] <darkxst> in which case it would be very easy for 'legacy' users to fork
[11:23] <darkxst> for their needs
[11:24] <robert_ancell> xnox, lp:~robert-ancell/indicator-network/network-manager
[11:27] <xnox> robert_ancell: thanks!
[11:34]  * darkxst is gone for the night ;)
[11:41] <robert_ancell> fginther, could you set up Jenkins for lp:unity-settings-daemon
[11:47] <robert_ancell> darkxst, bye
[11:57] <seb128> Laney, $ LANG= LANGUAGE= LC_ALL=bu_GY.UTF-8 autopilot run ubuntu_system_settings
[12:12] <qengho> didrocks: i think it's  https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1250174
[12:12] <ubot2`> Launchpad bug 1250174 in libdrm-2.4.23 (Ubuntu) "chromium-browser crashed with SIGSEGV in content::GpuWatchdogThread::DeliberatelyTerminateToRecoverFromHang()" [Undecided,Confirmed]
[12:19] <robert_ancell> seb128, Laney, darkxst, bug 1277485
[12:19] <ubot2`> Launchpad bug 1277485 in unity-settings-daemon (Ubuntu) " [MIR] unity-settings-daemon" [Wishlist,New] https://launchpad.net/bugs/1277485
[12:19] <seb128> \o/
[12:24] <Laney> neat
[12:37] <robert_ancell> seb128, Laney, please add any packages that need migration to bug 1277487
[12:37] <ubot2`> Launchpad bug 1277487 in unity-greeter (Ubuntu) "Create Unity Settings Daemon so can remain on old GNOME Settings Daemon version" [Undecided,New] https://launchpad.net/bugs/1277487
[13:54] <fginther> robert_ancell, I've added that to task list and should have it updated today. In the future, please contact the vanguard in #ubuntu-ci-eng as we are trying to share responsibility for these things among the team
[14:02] <Laney> desrt: http://people.canonical.com/~laney/0001-Fix-tests-for-builddir-srcdir-by-setting-G_TEST_-SRC.patch
[14:16] <Laney> seb128: just tried, it passed for me here
[14:16]  * seb128 shakes fist at Laney
[14:16] <Laney> :((((((
[14:16] <seb128> you want to make me debug that one, don't you!
[14:17] <desrt> Laney: pushed
[14:17] <desrt> but there are more distcheck issues now.... msvc stuff :(
[14:17] <Laney> messy buckets
[14:17] <Laney> :(
[14:17] <desrt> srsly.
[14:22] <Laney> larsu: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706065 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712208 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712628 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675008
[14:22] <ubot2`> Debian bug 706065 in libvte-2.90-common "libvte-2.90-common: /etc/profile.d/vte.sh is not sourced by interactive shells" [Normal,Open]
[14:22] <ubot2`> Debian bug 712208 in libvte-2.90-common "gnome-terminal: New tab is always opened in home directory (instead of working directory)" [Normal,Open]
[14:22] <ubot2`> Debian bug 712628 in libvte-2.90-common "gnome-terminal: ctrl-shift-n doesn't keep directory" [Normal,Open]
[14:22] <ubot2`> Debian bug 675008 in bash "bash: should handle /etc/bashrc.d (or similar) for non-login interactive shell" [Wishlist,Open]
[14:23] <mterry> jdstrand, if my app asks policykit about a certain permission, but apparmor denies the request, what does that look like to my app?  (would apparmor ever deny a policykit authentication check?)
[14:24] <jdstrand> mterry: hey. so, the app is either going to use pkexec or talk to the service over dbus which then prompts the user
[14:25] <mterry> jdstrand, in my case, my app is pkcheck itself
[14:25] <jdstrand> mterry: with pkexec, if the policy doesn't allow using it, you'll get the denial
[14:26] <jdstrand> mterry: with talking over dbus, if the policy doesn't allow the dbus communication, you'll get a denial (the server won't ever get the message)
[14:26] <jdstrand> mterry: in either case, you'll know if apparmor is blocking you by looking in /var/log/syslog (note, not *kern.log or dmesg-- dbus denial necessarily have to go to syslog)
[14:27] <mterry> jdstrand, so it will look like a normal polkit denial to my app?
[14:28] <jdstrand> mterry: when you say 'pkcheck itself', what are you talking about?
[14:29] <mterry> jdstrand, I have an autopilot test that uses pkcheck on a certain NetworkManager permission as an integration check (to make sure that the session is marked active by logind/lightdm).
[14:29] <mterry> jdstrand, on Touch it works fine
[14:29] <robert_ancell> fginther, will do, thansk
[14:29] <mterry> jdstrand, on Desktop, it says permission for that pkcheck is denied, but we can't figure out why
[14:29] <mterry> jdstrand, I was wondering if it could be some weird apparmor thing
[14:29] <jdstrand> mterry: ewll, with my example, in the former case, (pkexec), the app would get EPERM, in the latter (dbus denial), the app gets DBus AccessDenied
[14:30] <jdstrand> mterry: the dbus denial will mention AppArmor in the message (and you'll see the message in syslog)
[14:30] <mterry> jdstrand, hmm, so I'd have to dig into pkcheck and see how it handles those error cases, to see if that's likely.  But I could check the syslog..
[14:30] <mterry> fginther, ^
[14:30] <jdstrand> mterry: yes, check syslog
[14:30] <mterry> fginther, did we look at syslog for apparmor messages yet?
[14:31] <jdstrand> if there is no denial there, it isn't apparmor. plus, the app would have to be confined for it to be affected by apparmor any way
[14:31] <jdstrand> (well... technically that might not have to be the case, but in Ubuntu with how we confine things it is)
[14:34] <attente_> ChrisTownsend, was your most recent test under a fresh unity session after installing the g-s-d from the ppa?
[14:40] <ChrisTownsend> attente_: Yes
[14:42] <attente_> ChrisTownsend, does pressing alt+f work properly?
[14:43] <seb128> larsu, wget https://launchpad.net/ubuntu/+source/file-roller/3.4.1-0ubuntu1/+build/3410817/+files/file-roller_3.4.1-0ubuntu1_amd64.deb
[14:43] <ChrisTownsend> attente_: You mean it opens the first menu on the panel and not the decoration, right?
[14:44] <attente_> ChrisTownsend, yes
[14:44] <ChrisTownsend> attente_: Yes, that is working correctly.
[14:45] <seb128> larsu, https://launchpad.net/~ubuntu-security/+archive/ppa/+build/4789846/+files/file-roller_3.6.1.1-0ubuntu1.2_amd64.deb
[14:46] <attente_> ChrisTownsend, dbus-send --session --dest=org.gnome.Shell --print-reply /org/gnome/Shell org.gnome.Shell.GrabAccelerator string:'<Control>a' uint32:0
[14:46] <attente_> ChrisTownsend, then dbus-monitor member=AcceleratorActivated
[14:48] <attente_> then ctrl+a
[14:48] <mterry> jdstrand, thanks btw!  it probably isn't apparmor, just clutching at straws at this point
[14:50] <ChrisTownsend> attente_: http://pastebin.ubuntu.com/6891649
[14:50] <attente_> ChrisTownsend, have you run the tests in your current session?
[14:51] <ChrisTownsend> attente_: Not this exact same session.  I can try it now.
[14:51] <attente_> ChrisTownsend, thanks
[14:52] <ChrisTownsend> attente_: Same failure
[14:52] <jdstrand> np
[14:53] <ChrisTownsend> attente_: I need to step away for a little bit.
[14:53] <attente_> ChrisTownsend, ok, np
[14:56] <qengho> robru: https://launchpad.net/~canonical-chromium-builds/+archive/stage
[15:00] <qengho> robru: https://code.launchpad.net/~chromium-team/chromium-browser/trusty-working   debian/patches/\d-.*
[15:35] <ChrisTownsend> attente_: Hey, I'm back if you need me to do any more debugging.
[15:35] <attente_> ChrisTownsend, hi
[15:36] <attente_> ChrisTownsend, after running the AP tests, can you do 'dbus-monitor member=AcceleratorActivated' then try shift+ctrl+alt+a?
[15:36] <ChrisTownsend> attente_: Sure
[15:37] <ChrisTownsend> attente_: dbus-monitor has no output when I hit shift+ctrl+alt+a
[15:38] <attente_> dbus-send --session --dest=org.gnome.Shell --print-reply /org/gnome/Shell org.gnome.Shell.GrabAccelerator string:'<Shift><Control><Alt>a' uint32:0
[15:39] <ChrisTownsend> attente_: Ok, I did that
[15:39] <attente_> 'dbus-monitor member=AcceleratorActivated' again
[15:40] <ChrisTownsend> Ok
[15:40] <attente_> any output on shift+control+alt+a?
[15:40] <ChrisTownsend> attente_: No, nothing
[15:40] <attente_> ChrisTownsend, what was the output of the dbus-send call?
[15:41] <ChrisTownsend> attente_: http://pastebin.ubuntu.com/6891915
[15:43] <attente_> ChrisTownsend, your compiz is trunk, right?
[15:43] <attente_> ChrisTownsend, nvm i guess it must be if alt+f works for you
[15:44] <ChrisTownsend> attente_: It's compiz from the daily-build PPA that was published on 1/28.
[15:45] <ChrisTownsend> attente_: That definitely includes your Compiz changes.
[15:45] <attente_> ChrisTownsend, ok
[15:45] <attente_> ChrisTownsend, do you have any shortcuts set for switching keyboard layouts?
[15:45] <attente_> in the text entry panel of g-c-c?
[15:46] <ChrisTownsend> attente_: Not that I know of.  I'll look though.
[15:46] <ChrisTownsend> attente_: Just the Super+Space and Shift+Super+SPace.
[15:46] <attente_> ChrisTownsend, ok
[15:47] <attente_> ChrisTownsend, just to cover all bases: apt-cache policy gnome-settings-daemon
[15:48] <ChrisTownsend> attente_: Installed: 3.8.6.1-0ubuntu4ppa1
[15:51] <attente_> ChrisTownsend, sorry, let me think some more, i'm short on ideas for things we can try
[15:52] <ChrisTownsend> attente_: Ok, just ping me when you want me to try something.  It's a mystery to me as well since it works for you and Trevinho.
[15:53] <attente_> ChrisTownsend, you mentioned you had another application running called Terminator?
[15:54] <ChrisTownsend> attente_: It's a terminal emulator.  I also ran this with Terminator closed and just using gnome-terminal with the same results.
[15:54] <attente_> ChrisTownsend, ah, ok
[19:01] <mterry> dobey, so with ubuntu-purchase-service, any app that can talk to the service can buy stuff?  What's the process like?
[19:03] <dobey> mterry: it's a service that launches the UI to purchase something. it's only used on touch at the moment and you can only buy apps at the moment
[19:03] <mterry> dobey, so it's not an insta-buy?  Still requires user interaction before final purchase?
[19:04] <dobey> mterry: it opens a window/overlay with the web view for confirming the purchase. purchases are not automatable
[19:04] <mterry> cool