[01:22] <robert_ancell> desrt, what is the correct way to register two gdbus objects on different bus names?
[01:22] <robert_ancell> desrt, the bus name seems to be implied
[07:59] <darkxst> seb128, !!!!
[08:00] <seb128> good morning desktopers
[08:00] <seb128> darkxst, hey
[08:00] <darkxst> seb128, bug 1301712, fixed now, but really we don;t want the u-c-c/uoa stack!!
[08:00] <ubot2> Launchpad bug 1301712 in shotwell (Ubuntu) "shotwell is pulling in unity-control-center and UOA on Ubuntu GNOME" [Low,Fix released] https://launchpad.net/bugs/1301712
[08:00] <seb128> you realize that without uoa shotwell has non working features, right?
[08:00] <seb128> I just commented on that
[08:00] <seb128> your call if you like to ship buggy softwares I guess
[08:00] <darkxst> seb128, we don't ship uoa by default
[08:00] <seb128> I added the recommends because without uoa if you do publish, add an account, you get a nice fail
[08:00] <seb128> right
[08:01] <seb128> so you ship a buggy shotwell
[08:01] <darkxst> seb128, wouldnt the right thing be to disable those features if uoa is not installed?
[08:01] <seb128> that's one other option, patches are welcome
[08:02] <seb128> but in the current state things are just buggy
[08:02] <seb128> well, we ship uoa by default so it's not so much an issue for us
[08:02] <darkxst> seb128, I would much prefer you discuss these things with me first!
[08:02] <seb128> I added the recommends because we received some bugs about publishing not working
[08:02] <seb128> I didn't even think a recommends would be an issue for you
[08:02] <seb128> sorry about that
[08:03] <darkxst> all recommends are seeded
[08:03] <seb128> yeah, I just didn't think that some flavors were using shotwell but not installing what it needs
[08:03] <Laney> morning
[08:03] <seb128> Laney, hey
[08:04] <Laney> hey, wie gehts?
[08:04] <seb128> good!
[08:04] <seb128> you?
[08:04] <Laney> not bad thanks!
[08:05] <darkxst> seb128, do you have bugs pointing to the actual issue/
[08:05] <darkxst> ?
[08:07] <seb128> darkxst, open a photo, do file->publish, pick "add more accounts" from the combo box
[08:07] <seb128> notice how the warnings about g_spawn_command failing
[08:08] <darkxst> seb128, and publish menu is provided by the uoa patch I presume?
[08:08] <seb128> yes
[08:08] <seb128> or rather modified
[08:08] <seb128> upstream have their own accounts handling (not using goa or uoa)
[08:09] <darkxst> yes I noticed there was no goa integration
[08:15] <darkxst> seb128, ok, I will get that sorted
[08:16] <darkxst> seb128, Laney any chance of getting tracker into main next cycle?
[08:16] <GunnarHj> Morning seb128!
[08:16] <darkxst> we really need nautilus built with tracker support
[08:17] <darkxst> nautilus is the 'search provider' for file searches
[08:17] <darkxst> all that is completely broke right now
[08:18] <GunnarHj> seb128:
[08:18] <GunnarHj> http://blog.canonical.com/2014/04/02/shutting-down-ubuntu-one-file-services/
[08:18] <GunnarHj> I missed the UIFe request.
[08:18] <Laney> ISTR we had problems with io load and indexing before
[08:19] <darkxst> has it ever been in main before?
[08:20] <darkxst> I though the MIR got rejected due to UBuntu using zeigeist, but that was before we became official flavour
[08:21] <seb128> GunnarHj, hey
[08:21] <seb128> GunnarHj, I'm unsure there was an UIFe request
[08:21] <seb128> darkxst, tracker, I doubt it
[08:22] <seb128> well, maybe, you can file a MIR etc for it I guess
[08:22] <seb128> but I'm unsure we want to build e.g nautilus with it
[08:22] <seb128> you need the indexer right?
[08:22] <darkxst> yeh
[08:23] <darkxst> the other idea would be to add search hooks for extensions, but havent checked with upstream yet if they would take that
[08:23] <darkxst> but its certainly not possible with current nautilus extension api
[08:23] <GunnarHj> seb128: Me too. ;-) Does it mean that the Ubuntu One client will be removed before final release? Should we remove the references to Ubuntu One from the docs (resulting in a few untranslated strings)?
[08:25] <Laney> It's gone, certainly remove it
[08:25] <seb128> GunnarHj, yes, the package/support for it has started been dropped yesterday
[08:25] <Laney> The release team were informed in advance but I guess nobody told the docs guys
[08:25] <Laney> sorry :/
[08:26] <seb128> xnox, "Drop account-plugin-aim and account-plugin-yahoo from recommends to suggests, thus removing 21.8MB of gstreamer0.10 from ubuntu desktop  CDs."
[08:26] <seb128> that statement seems weird to me
[08:26] <darkxst> I never heard nothing either! until xnox removed things from our seeds
[08:26] <GunnarHj> Laney, seb128: I think that a hint on ubuntu-devel-announce would have been appropriate.
[08:27] <seb128> GunnarHj, yeah, me too, I didn't even see the announcement!
[08:27] <seb128> xnox, did you drop bluez-gstreamer as well? that use gst0.10
[08:28] <seb128> xnox, also telepathy-haze pulls gstreamer0.10 in through libpurple
[08:30] <Laney> cyphermox: maybe you could comment with your recommendation
[08:32] <Laney> empathy> "Both services have declining userbase" I wouldn't have said that ...
[08:32] <Laney> Bit weird to make this decision unilaterally but hey
[08:32] <seb128> I might revert it
[08:33] <seb128> but after talking to xnox
[08:33] <seb128> I doubt he's going to achieve what he wanted
[08:33] <seb128> we need to keep haze on the CD and that keeps gst0.10
[08:33] <seb128> bluez-gstreamer as well (though I'm unsure what that does and what would we miss without it)
[08:34] <Laney> cyphermox said that one is ok
[08:35] <Laney> I think it lets you use a2dp
[08:35] <seb128> did he add details on what it doeS?
[08:35] <seb128> what is a2dp?
[08:35] <Laney> i.e. send audio over bluetooth
[08:35]  * seb128 clueless about bluetooth
[08:35] <seb128> shrug
[08:35] <seb128> that seems like an useful feature to me!
[08:36] <Laney> I think it's in mainline gstreamer with 1.0
[08:36] <Laney> so don't know how useful it is with 0.10
[08:36] <seb128> oh, nice
[08:36] <seb128> well, as said I would like to understand how those things are used
[08:36] <seb128> before we decide to drop stuff  a week before release
[08:36] <Laney> laney@iota> gst-inspect-1.0 | grep a2dp                                                                                                    ~
[08:36] <Laney> bluez:  a2dpsink: Bluetooth A2DP sink
[08:36] <seb128> to then notice after release that after all those stuff were needed and that we regressed usecases
[08:37] <seb128> $ gst-inspect-0.10 /usr/lib/i386-linux-gnu/gstreamer-0.10/libgstbluetooth.so
[08:37] <seb128> ...
[08:37] <seb128>   rtpsbcpay: RTP packet payloader
[08:37] <seb128>   a2dpsink: Bluetooth A2DP sink
[08:37] <seb128>   avdtpsink: Bluetooth AVDTP sink
[08:37] <seb128>   sbcparse: Bluetooth SBC parser
[08:37] <seb128>   sbcdec: Bluetooth SBC decoder
[08:37] <seb128>   sbcenc: Bluetooth SBC encoder
[08:37] <seb128>  
[08:38] <seb128> no "SBC decoder" in my gst-inspect-1.0
[08:38] <Laney> yeah that's in bad for 1.0 afaics
[08:38] <seb128> k, I don't have that installed
[08:41] <darkxst> I could never get a2dp working anyway, probably not a huge loss!
[08:42] <darkxst> ^maybe iphone related though, the iphone stack is an outdated mess right now
[08:44] <Laney> never tried it
[08:45] <Laney> not that I have an iphone, but I guess it should work with android too
[08:47] <darkxst> yeh, although a2dp is a standard! works fine in any modern car (maybe there are patent issues though?)
[08:48] <darkxst> so probably what I hit was just a bug
[08:48] <seb128> I don't even know how to test that
[08:48] <seb128> is that just "pair your phone as a bt device, play music through it as an output"?
[08:49] <darkxst> seb128, yes, so you pair phone with computer, and then the music play get routed through pulseaudio
[08:49] <darkxst> ^ the music you play on phone
[08:52] <Laney> computer doesn't even see my phone to pair with it
[08:52] <seb128> great, u-c-c segfaulted when I tried to enable the audio for media option on the phone
[08:52] <seb128> in libgnome-bluetooth
[08:54] <Laney> this is severely buggy :(
[08:54] <Laney> the enabled state isn't remembered or synced with the indicator
[08:54] <seb128> you likely have a bluez/kernel issue
[08:54] <Laney> never sees the phone, get operation in progress on stderr when doing things
[09:01] <darkxst> Laney, right, I just gave up on the idea :) and plugged some speakers into my phone!
[09:06] <sasa84> hello
[09:07] <sasa84> part of apport is not translated https://dl.dropboxusercontent.com/u/17510489/Apport.png
[09:08] <sasa84> actually there are no strings for translation either https://translations.launchpad.net/ubuntu/trusty/+source/apport/+pots/apport/sl/+translate
[09:09] <seb128> sasa84, hey, that's "normal", hooks are not translatable atm I think
[09:10] <xnox> seb128: why would you want telepathy-haze on the images?
[09:11] <seb128> xnox, because things like gadugadu (the most popular im in China) have no other support for it that through libpurple
[09:11] <xnox> seb128: poland, qq is in china =)
[09:11] <seb128> oh, sorry
[09:11] <seb128> but the argument still stands
[09:12] <seb128> some protocols are popular in countries and have no telepathy connectors
[09:12] <xnox> seb128: and those support/use audio/video via libpurple?
[09:12] <seb128> so they need to use libpurple through haze
[09:12] <seb128> not sure
[09:12] <seb128> they do use libpurple from texting/messages
[09:12] <xnox> seb128: why do i not see telepathy-haze in the seed sources?
[09:12] <seb128> but libpurple is one lib
[09:12] <seb128> the a/v part is not split out
[09:13] <seb128> xnox, because it's a recommends of empathy
[09:13] <seb128> we could seed all recommends of all softwares
[09:13] <seb128> not sure what's the point though
[09:13] <xnox> nah, no point. For ubuntu, we do choose to seed in recommends.
[09:13] <seb128> well, it's already a recommends from empathy
[09:14] <seb128> not sure why you want to duplicate that info?
[09:14] <xnox> no, i don't. Just wanted to know how it was seeded in, to make sure it's not just a dep.
[09:15] <xnox> so another way is to hunt down upstream patches which port purple to gstreamer0.10, and then the empathy change to downgrade two accounts can be reverted as well.
[09:15] <xnox> cause at this point libpurple is the last one holding up gstreamer0.10 on desktop images.
[09:15] <Laney> They did it on a different branch, for the 3.0 series.
[09:15] <xnox> is last correct statement?
[09:16] <seb128> I think it is
[09:16] <seb128> but pigdin is moving slowly
[09:16] <xnox> Laney: right, i'll look to see if it's self-contained to be cherry-picked.
[09:16] <seb128> they are still gtk2 and gst1.0
[09:16] <seb128> gst0.10 sorry
[09:16] <seb128> they are porting to gtk2/gst1.0 but when I looked at it there was no easy change we could backport to migrate to gst1.0
[09:16] <sasa84> ok, tnx seb128
[09:16] <seb128> xnox, thanks
[09:17] <Laney> I don't think it's going to be as easy as you think it might be
[09:17] <Laney> otherwise we would have done it back then
[09:17]  * darkxst would love to see gstreamer 0.10 be gone from our images ;) (not that I have been following the whole story)
[09:18] <Laney> Risky this close to release too
[09:19] <darkxst> hmm I was wasnt really talking about this release!
[09:19] <seb128> xnox is ;-)
[09:21] <xnox> seb128: i'm not buying this gadu-gadu & qq argument =) let me check the depends again.
[09:22]  * darkxst also wonders why I generally have no idea about what is happening until (almost) after the fact
[09:22] <seb128> xnox, well, also yahoo ... which you decided was not useful anymore, but I don't think we have data on that being true or false
[09:22] <xnox> seb128: so to get gadugadu support in empathy, i need account-plugin-gadugadu which is universe and that's not of my doing.
[09:22] <seb128> darkxst, is that comment about the u1 change? or do you have other examples?
[09:22] <darkxst> probably mostly, I find out after things break! :(
[09:22] <xnox> seb128: and that depends on telepathy-haze
[09:23] <seb128> darkxst, well, I could say the same, I woke up this morning to see that you dropped the recommends I added yesterday :p
[09:23] <xnox> seb128: and i don't see a qq accounts plugin.
[09:23] <seb128> xnox, empathy doesn't enforce ubuntu-online-account, you can go to empathy-preferences and add accounts
[09:24] <seb128> sorry, "empathy-accounts"
[09:24] <darkxst> seb128, you seeded the entire unity-control-center/UOA stack on our images!!!!
[09:24] <xnox> seb128: oh, the "old UI" ?!
[09:24] <darkxst> that is bad ;)
[09:24] <seb128> xnox, the only UI to add accounts that are not supported by uoa
[09:25] <xnox> seb128: how to open that? F4/empathy->accounts opens online-accounts.
[09:25] <seb128> darkxst, well, I'm just saying, you did a change during my night and I woke up to it, it's not only to you that those things happen
[09:25] <seb128> xnox, alt-f2 empathy-accounts
[09:27] <xnox> seb128: that does offer gadugadu. but... there is no desktop/UI way to get there?
[09:27] <seb128> xnox, not that I know offhand, which is a known issue, we force users into an incomplete account list :/
[09:27] <darkxst> seb128, sorry but +59 packages into a seed, is quite the emergency!
[09:28] <seb128> darkxst, I'm not criticizing the change, just saying that people do work and don't always stop to discuss every change
[09:31] <darkxst> seb128, sure, guess I am just pushing a bit more cross-flavour considerations, we do (try atleast) to test everything against ubuntu before upload
[09:31] <xnox> so we ship haze, and hidden ui to use it, but no anything discoverable =(
[09:31] <darkxst> just that doesnt happen in reverse
[09:31] <seb128> xnox, correct
[09:32] <darkxst> although when/if we can get gnome-shell autopkg tests running, I guess that can't happen anymore
[09:32] <seb128> xnox, I could see an argument to drop it from the default install saying it's not accessible to normal users anyway, but doing such change a week before the freeze makes me nervous
[09:32] <Laney> Would it break the accounts of people upgrading?
[09:33] <seb128> darkxst, it's not easy to test every flavor, image if we had to test kubuntu, xubuntu, lubuntu, GNOME Ubuntu, etc before every upload
[09:33] <seb128> Laney, we wouldn't remove those binaries on upgrade I guess?
[09:33] <seb128> Laney, or is update-manager agressive about those things?
[09:33] <seb128> which makes me thing I still need to talk to mvo_ about that
[09:33] <xnox> Laney: if they had online-accounts-gadugadu installed then no, cause that hard depends on haze and it would stay.
[09:33] <seb128> to see if we can remove gnome-control-center on precise->trusty updates
[09:34] <darkxst> seb128, its really only Ubuntu GNOME that has overlap ?
[09:34] <xnox> Laney: actually no, it will not break on upgrades, cause upon upgrade haze would stay.
[09:34] <mvo_> seb128: about what exactly? sorry missed parts of the conversation
[09:34] <darkxst> I supposed edubuntu uses gnome-flashback too
[09:34] <xnox> Laney: cause we are discussing dropping -haze from depends to recommends in empathy.
[09:34] <seb128> darkxst, not really, GTK is used in most flavors
[09:35] <Laney> Oh, I thought you wanted to get it off the image
[09:35] <Laney> Don't know what the point is then
[09:35] <seb128> mvo_, we transitioned Unity from gnome-control-center/gnome-settings-daemon to unity-control-center/unity-settings-daemon in trusty, I'm wondering if we can make the dist-upgrader clean g-c-c/g-s-d on upgrade if nothing depends on those
[09:35] <darkxst> gtk bugs are generally not fatal, just annoying
[09:35] <seb128> darkxst, well, adding uoa to your seed was not a runtime issue, just annoying :p
[09:35] <seb128> but yeah, we try to be good citizen
[09:35] <xnox> Laney: dropping -haze from recommends to suggests on empathy, will effectively unseed haze/purple/gstreamer0.10
[09:35] <xnox> Laney: we don't install suggests, do we?
[09:35] <Laney> what
[09:36] <darkxst> we have had gobject-introspection issues that break gdm...
[09:36] <Laney> 03/04 10:34:28 <xnox> Laney: cause we are discussing dropping -haze from depends to recommends in empathy.
[09:36] <Laney>  <xnox> Laney: dropping -haze from recommends to suggests on empathy
[09:36] <xnox> Laney: TYPO!
[09:36] <seb128> it's already a recommends
[09:36] <xnox> Laney: need more coffee =)))))))
[09:36] <seb128> it's recommends->suggests
[09:36] <xnox> that ^
[09:36] <darkxst> seb128, that and a 100 messages why is the unity world being pulled into ubuntu GNOME :(
[09:36] <seb128> darkxst, yeah, that's unfortunate :/
[09:36] <seb128> darkxst, anyway mistake happen, sorry about that
[09:36] <seb128> and +1 on autopkgtests for gnome-shell
[09:37] <seb128> xnox, I cleaned those u1 sources from trusty
[09:37] <darkxst> seb128, next cycle, its hard ;(
[09:37] <mvo_> seb128: yes, that should be possible
[09:37] <xnox> seb128: \o/
[09:37] <xnox> seb128: thanks. I think u1 is all done for trusty, but possibly unity (in-silo) and thunderbird.
[09:37] <darkxst> autopilot and maybe gnome-shell, need to be patched to play with clutter widgets
[09:38] <seb128> we don't have autopilot integrated with autopkgtest
[09:38] <seb128> and yeah, autopilot and clutter sounds like "fun"
[09:39] <darkxst> seb128, pitti mentioned it was possible (apart from the clutter bit)
[09:39] <seb128> cool
[09:41] <xnox> seb128: cjwatson did write a proof-of-concept running autopilot tests as autopkgtests =)
[09:41] <seb128> nice
[09:41] <darkxst> seb128, I actually have a couple of 'apprentices' now (CS students I guess) that at are good are code, but hopeless at packaging
[09:47] <darkxst> seb128, I doubt upstream will care much about in bugs in 3.8...
[09:48] <seb128> darkxst, that's what the new RHEL ships, I somewhat think that's going to help a bit
[09:48] <darkxst> seb128, getting source from RHEL is a pita
[09:49] <seb128> some of the fixes are flowing back in upstream git
[09:49] <darkxst> maybe some but not most!
[09:49] <seb128> but yeah, GNOME upstream doesn't do much stable serie work
[09:49] <seb128> it would be true for any serie
[09:50] <seb128> if we had 3.10 we would soon stop getting fixes for that as well
[09:50] <xnox> what component do we use for XMPP in telepathy? it's telepathy-native? cause libpurple uses gstreamer for XMPP only audio/video by the looks of things.
[09:50] <darkxst> seb128, watch this space, I will make sure all patches that affect us are cherry picked to the 3.10 branch; )
[09:50] <xnox> but recompiling pidgin without gstreamer, would piss off anybody to uses pidgin for audio/video xmpp
[09:51] <xnox> unless we compile that twice.....
[09:51] <xnox> sounds risky
[09:51] <seb128> darkxst, ;-)
[09:51] <darkxst> except for the stupid gnome-tweak-tool authors who refuse to take python3 pathes
[09:52] <seb128> xnox, telepathy-gabble
[09:52] <Laney> I'd really rather avoiding doing any risky gstreamer stuff now
[09:52] <Laney> if you wanted to try that it should have been a couple of months ago
[09:54] <seb128> +1
[09:55] <xnox> seb128: i'm confused, reading the buildlog empathy is compiled with --enable-gst1.0 option and it does link against gstreamer1.0 in the archive.
[09:56] <xnox> reading wrong project buildlog
[09:56] <darkxst> seb128, you would probably be amazed at what the the super secret RHEL teams backport, but its not generally available until it filters into CentOS
[09:57] <Laney> do they do the monolithic patches thing for all packages?
[09:57] <darkxst> I don't know, I have never been able to find a single patch to see!
[09:58] <seb128> darkxst, I've to admit I never tried to look much at what they do indeed
[09:59] <Laney> If not some kind of patch tracker for rhel would be interesting ;-)
[10:00] <Laney> seb128: Trevinho: want to try getting https://code.launchpad.net/~3v1n0/unity/forcequit-dialog/+merge/213832 in?
[10:01] <seb128> Laney, it's in silo 5 if you want to test the ppa
[10:01] <Laney> oh cool
[10:01] <seb128> https://launchpad.net/~ci-train-ppa-service/+archive/landing-005/+packages
[10:01] <Laney> how can you trigger a hung window?
[10:02] <seb128> gedit & gdb -p `pidof gedit`
[10:02] <seb128> N
[10:02] <seb128> ?
[10:02] <Laney> oh yes good point
[10:02] <Laney> I was thinking stuff like that would close the window for some reason
[10:02]  * Laney is broken
[10:06] <seb128> Trevinho, Laney, bregma: those changes to the close dialog seem buggy, I get 2 dialogs to show, the old and new ones
[10:07]  * seb128 restarts session in case alt-f2 -> unity was not a proper restart
[10:07] <Laney> urgh I broke everything
[10:07] <seb128> what did you do?
[10:08] <Laney> I logged out to start a new session with it
[10:08] <Laney> which took ages waiting for some timeout
[10:08] <Laney> so I tried to use loginctl session-status to see what it was
[10:08] <Laney> that was segfaulting
[10:08] <seb128> urg
[10:08] <Laney> and then it hung logging out the next time and restarting lightdm hasn't got it back up
[10:08] <Laney> weeeeeeeeee
[10:09] <Laney> oh there it is, in a messed up resolution, wtf
[10:09]  * Laney restarts
[10:11] <ochosi> Laney: what was in a messed up resolution? just asking cause we recently got a lightdm-gtk-greeter bug assigned from robert that complains about the greeter not being displayed in the correct resolution (could never reproduce that so it's a bit poking in the dark for me..)
[10:11] <Laney> lightdm
[10:11] <Laney> after I restarted it
[10:12] <Laney> it had ignored the settings I think because it was mirrored too
[10:13] <Laney> seb128: seems fine to me, I only got one dialog
[10:15] <seb128> Laney, I still get both after a restart :/
[10:15] <Laney> weird
[10:17] <ochosi> Laney: so unity-greeter was shown in the wrong resolution?
[10:17] <Laney> yes
[10:18] <Laney> hmm it's spotify holding the session open
[10:19] <seb128> greeter sessions are left open because of indicators here :/
[10:19] <ochosi> Laney: mind to add whether this should affect unity-greeter too then? https://bugs.launchpad.net/bugs/1300153
[10:19] <ubot2> Launchpad bug 1300153 in lightdm-gtk-greeter (Ubuntu) "login Screen is not showing correctly" [Undecided,New]
[10:20] <ochosi> seb128: well from what i've seen, they get quite brutally killed in unity-greeter (and gtk-greeter, cause we mostly ported unity-greeter's indicator behavior)
[10:21] <Laney> ochosi: It's unlikely to be the same problem
[10:21] <Laney> or at least I can't say if it is
[10:21] <seb128> ochosi, well, at least indicator bluetooth/sound are managed by upstart
[10:21] <seb128> so it looks like unity-greeter fails to send the signal that is used to stop the jobs
[10:21] <seb128> stop on desktop-end or indicator-services-end
[10:22] <seb128> so I guess the greeter should send indicator-services-end at login and doesn't
[10:27] <seb128> ok, time for some errands and getting lunch on the way, back in 45 minutes or so
[10:36] <ochosi> Laney: afaik unity-greeter and lightdm-gtk-greeter use the same logic to get the screen size/resolution
[10:47] <mlankhorst> afternoon
[10:47] <mlankhorst> not feeling well, running a fever. :(
[11:21] <seb128> ochosi, unity-greeter uses unity-settings-daemon xrandr plugin
[11:21] <seb128> so things might be different
[11:30] <Laney> jdstrand: can I add /usr/local/share/glib-*/schemas/ to telepathy's profile?
[11:30] <Laney> I get some denials for that when using empathy
[11:31] <seb128> Laney, /usr/local?
[11:31] <seb128> Laney, what did you do!
[11:31] <Laney> $ empathy
[11:31] <Laney> dmesg
[11:31] <seb128> ls /usr/local/share/glib-*/schemas/
[11:31] <seb128> /usr/local should be empty
[11:31] <seb128> did you sudo make install thingS?
[11:31] <Laney> yes I have some schemas there
[11:31] <Laney> it's a legal thing to do :-)
[11:31] <seb128> lol
[11:32] <seb128> well, if you can local install you can tweak your apparmor profiles ;-)
[11:32] <seb128> or do we usually include /usr/local paths to those?
[11:32]  * seb128 checks
[11:32] <Laney> other profiles handle /usr/local
[11:32] <seb128> k
[11:40] <bregma> seb128, I have removed the close dialog MP fro the current U7 silo because that needs to land for other reasons, we'll try it again in the next landing
[11:40]  * bregma takes the dog for a walk
[11:42] <GunnarHj> seb128: Is remote login affected by the Ubuntu One shutdown, or is it login.ubuntu.com that is part of the remote login feature?
[11:42] <GunnarHj> https://help.ubuntu.com/14.04/ubuntu-help/sharing-remote-login.html
[11:42] <GunnarHj> "The shutdown will not affect the Ubuntu One single sign on service, the Ubuntu One payment service, or the backend U1DB database service."
[11:43] <seb128> bregma, ok
[11:45] <seb128> GunnarHj, hum, I would have say it should not be affected but I'm unsure
[11:45] <seb128> dbarth, ^ can you reply to that?
[11:46] <GunnarHj> seb128, dbarth: I was about to remove that page, but then I started to hesitate...
[11:51] <seb128> GunnarHj, I think we stopped installing-by-default the remote login package earlier in the cycle, you can probably drop that page
[11:52] <dbarth> GunnarHj, seb128: confirmed, you can drop it
[11:53] <seb128> dbarth, k, it would still be useful if you replied to the question though ;-)
[11:53] <dbarth> seb128: eh, which question exactly?
[11:53] <dbarth> (just reading the backlog after lunch)
[11:54] <dbarth> so, the remote login feature is not affected by the change
[11:54] <seb128> dbarth, is lightdm-remote-session-uccsconfigure relying on u1? said differently, is it still a working package without the filesync service?
[11:54] <dbarth> not affected by the U1 shutdown to be more precise
[11:54] <seb128> dbarth, the documentation GunnarHj pointed states "The system is designed so that Ubuntu One securely stores your login information "
[11:55] <dbarth> the remote login feature is not enabled by default anymore
[11:55] <seb128> dbarth, ok, good, thanks ;-)
[11:55] <GunnarHj> seb128, dbarth: Thanks, then I know how to proceed.
[11:55] <Laney> If you want to document it then change it to tell people how to install the package instead
[11:55] <seb128> dbarth, right, still if he stopped working we should remove the package for Ubuntu as well
[11:55] <Laney> :-)
[11:55] <dbarth> and, now that we dive into this, i think we should also drop the uccsconfigure part
[11:55] <seb128> he->it
[11:55] <dbarth> i thought that was the case already
[11:55] <seb128> https://launchpad.net/ubuntu/+source/lightdm-remote-session-uccsconfigure
[11:55] <seb128> that is still in trusty
[11:56] <dbarth> but really we only want to keep the technical bit around, in case enterprises want to use that
[11:56] <seb128> if we want to stop supporting it, maybe we should delete it before release
[11:56] <seb128> k
[11:56] <dbarth> seb128: think i still have time to request a drop?
[11:56] <seb128> yes
[11:56] <dbarth> i will sync up with jason & robert as well
[11:56] <seb128> k
[11:59] <GunnarHj> Laney: Well, yes explaining how to install instead of how to remove would of course be an option...
[12:13] <ochosi> seb128: oh, indeed. i thought it was mainly using gdk to determine screen-size etc
[12:19] <seb128> ochosi, it could be, the xrandr plugin is handling some of the work, I don't think it does much on start though (the screen config is done by xorg afaik)
[12:19] <ochosi> yeah, i thought so too
[12:19] <ochosi> even moving the login-window to different monitors didn
[12:20] <ochosi> t seem to involve randr
[12:21] <seb128> no, xrandr basically set the screens config, e.g which one is primary, if it's mirror mode or xinerama, and their resolution
[12:21] <seb128> so it's "xorg server config" more than "greeter work"
[12:22] <ochosi> ah, that's what you meant
[12:23] <jdstrand> Laney: I guess it would be ok, but I have a feeling it wouldn't be enough in the general case. that said I would suggest adjusting /etc/apparmor.d/local/usr.lib.telepathy which is designed for site-specific additions
[12:31] <Sweetshark> seb128: I talked to Rene, he is not interested in the fix as LO42 is unlikely to end up in their stable. So please review http://people.canonical.com/~bjoern/trusty/accessodf_0.1-1.3ubuntu2_amd64.changes and upload. diff is here: http://people.canonical.com/~bjoern/trusty/accessodf_0.1-1.3ubuntu2.diff
[12:32] <seb128> Sweetshark, ok, thanks ... amd64.changes, we do source uploads here ;-)
[12:33] <Sweetshark> seb128: ahh, this open source stuff is a hype that will soon pass. ;)
[12:33]  * Sweetshark uploads the source changes quickly ...
[12:35] <Sweetshark> seb128: http://people.canonical.com/~bjoern/trusty/accessodf_0.1-1.3ubuntu2_source.changes
[12:35] <seb128> Sweetshark, thanks ;-)
[12:42]  * Sweetshark listens to 'While my guitar gently weeps' in the ukulele version. There might be some irony hidden in there.
[12:43] <brainwash> indicator-sound installs /usr/share/upstart/xdg/autostart/indicator-sound.desktop which contains the line "hidden=True", this file seems to override the normal one located in /etc/xdg/autostart/
[12:44] <brainwash> so, xfce4-session shows the indicator sound autostart launcher as unchecked
[12:44] <seb128> tedg, ^
[12:44] <brainwash> recent indicator-sound change in trusty
[12:45] <brainwash> I assume that it prefers the upstart launcher, because we are running an upstart user session
[13:12] <seb128> Laney, do you have an opinion on https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/1296334 ?
[13:12] <ubot2> Launchpad bug 1296334 in rhythmbox (Ubuntu) "Update to bug-fix release 3.0.2 in Trusty" [High,Confirmed]
[13:20] <seb128> dpm, Laney, tedg: https://code.launchpad.net/~attente/indicator-keyboard/1291962-2/+merge/213346 is changing a "..." to "…" which changes the string/invalidates the translations, do you think it's ok to do now or is that too close from release?
[13:20] <Laney> seb128: looks ok, what do you think?
[13:21] <seb128> +1, I would prefer have the items right/consistent for the lts, it's an easy translate update, I'm going to drop a note to the translation team
[13:21] <tedg> Yeah, I think that's best.
[13:21] <seb128> Laney, or are you speaking about rhythmbox? ;-)
[13:21] <seb128> which I think is ok as well
[13:21] <Laney> rb
[13:21] <seb128> k
[13:21] <Laney> breaking translations not so sure
[13:21] <seb128> I'm going to do that update now
[13:21] <seb128> rb
[13:22] <dpm> seb128, could we do it after release? I've had experience with exactly this change bringing lots of confusion and frustration because translations break
[13:22] <Laney> jdstrand: that's the only profile I have installed here which references the schemas
[13:23] <Laney> I'll upload that, cheers
[13:23] <seb128> dpm, doing after release, like in a SRU?
[13:23] <seb128> dpm, or next cycle?
[13:23] <Laney> yeah I can imagine how it'd be annoying to have to rush to re-translate something like that before release
[13:24] <dpm> seb128, I'd say next cycle
[13:24] <Laney> I guess there's no way to say 'copy the old translations for this new string'
[13:24] <seb128> not in launchpad
[13:25] <dpm> actually the developer could do that and reupload the package with the new English string and the old translations
[13:25] <seb128> we were able to do that when translations were in the source
[13:25] <dpm> LP would still import the translations uploaded in the .mo files
[13:25] <seb128> right
[13:25] <Laney> so import them and then hack the po files or something
[13:25] <dpm> so the developer would have to hack all the .po files
[13:26] <dpm> and the .pot file
[13:26] <seb128> that would mean doing a full export, adding those to the source, doing some seeding/intltool-merge, commit that, CI train, clean the source back
[13:26] <dpm> to replace the original English string
[13:26] <seb128> I can't be bothered for one string
[13:26] <Laney> haha
[13:26] <dpm> yes, it's quite a lot of work
[13:26] <Laney> yes indeed
[13:27] <seb128> it's easier for a launchpad admin to click through the locales in the webui and revalidate the translations :p
[13:44] <brainwash> tedg: any idea why the recent indicator-sound update broke it?
[13:44] <Laney> You might want to give a bit more detail than that
[13:44] <brainwash> backlog
[13:45] <tedg> brainwash, I probably don't have enough backlog :-)
[13:45] <brainwash> "indicator-sound installs /usr/share/upstart/xdg/autostart/indicator-sound.desktop which contains the line "hidden=True", this file seems to override the normal one located in /etc/xdg/autostart/"
[13:46] <brainwash> "so, xfce4-session shows the indicator sound autostart launcher as unchecked"
[13:46] <tedg> Yes, and that should only be in your XDG_DATA_DIRS if you're running an upstart user session, no?
[13:46] <brainwash> yes, it's an upstart user session
[13:46] <brainwash> used by default in xubuntu
[13:46] <tedg> K, so does it start?
[13:47] <lenny> tedg: no
[13:47] <brainwash> it only starts if you tell xfce4-session to override "hidden=True"
[13:47] <Laney> I bet nothing emits the event
[13:47] <tedg> I'm not sure how the xfce4-session works, but if it's only using desktop files that's not really going to work with Upstart user sessions.
[13:47] <Laney> what happens if you run initctl emit indicator-services-start
[13:47] <Laney> ?
[13:48] <lenny> Laney: Nothing
[13:49] <Laney> status indicator-sound
[13:49]  * tedg is upset that Laney is too fast
[13:49] <lenny> indicator-sound stop/waiting
[13:50] <Laney> Fishy
[13:50] <Laney> start indicator-sound
[13:50] <brainwash> Laney: the command starts all indicators
[13:50] <lenny> indicator-sound start/running, process 2437 (no audio indicator in tray though)
[13:50] <Laney> brainwash: it works for you?
[13:51] <brainwash> Laney: yes, but it did start the whole indicator stack (datetime, sound,..)
[13:51] <Laney> is that bad?
[13:51] <brainwash> it's a change
[13:52] <brainwash> we were used to enable/disable indicators via xdg/autostart
[13:52] <Laney> oh right, that's going to happen then
[13:52] <Laney> if you 'echo manual > ~/.config/upstart/indicator-foo.conf' it should override it
[13:53] <Laney> So you should make some part of your desktop emit this event
[13:54] <Laney> You could do it from an upstart job (unity7) or code (lightdm-gtk-greeter) or a .desktop file (gnome-panel)
[13:55] <tedg> Technically unity7 does it from code, it emits the event in unity-panel-service when it's ready for the indicators.
[13:55] <tedg> But yes, all of those work.
[13:55] <Laney> oh yeah, just read the summaries on http://162.213.35.4/search?weighted=1&q=indicator-services-start
[13:55] <brainwash> yes, but I'm not sure if the xubuntu team wants to change the way the indicator start
[13:55] <brainwash> starts
[13:56] <Laney> then change the override file to drop XFCE
[13:56] <Laney> Not sure what the point of having upstart sessions is if you don't want to use them though
[13:57] <brainwash> upstart user sessions were enabled by default
[13:57] <seb128> tedg, so, question for you
[13:57] <Laney> Someone listed it in /etc/upstart-xsessions
[13:57] <tedg> seb128, Heh, and I bet you're going to want an answer too! ;-)
[13:58] <seb128> tedg, loginctl lists some lightdm sessions for me, those keep running because of indicator processes
[13:58] <seb128> tedg, should we have unity-greeter emitting indicator-services-end at login so those get stopped?
[13:58] <tedg> seb128, It shouldn't have to, sending sigterm to Upstart should do it. Do you have upstart's running as well?
[13:59] <tedg> Upstarti?
[13:59] <seb128>           CGroup: systemd:/user/119.user/c10.session
[13:59] <seb128>                   ├─13876 init --user --startup-event indicator-services-star...
[13:59] <seb128>                   ├─13961 /usr/lib/i386-linux-gnu/indicator-bluetooth/indicat...
[13:59] <seb128>                   ├─13965 /usr/lib/i386-linux-gnu/indicator-sound/indicator-s...
[13:59] <brainwash> Laney: ok, I'll try to explain the situation to the xubuntu team. thanks :)
[13:59] <seb128> tedg, yes
[13:59] <Laney> brainwash: If you get removed from that file then you can stop using the user sessions
[13:59] <Laney> Those are all of the options that I know of :-)
[13:59] <seb128> tedg, doesn't happen for you? (try to start a guest session and log back to your user)
[14:00] <seb128> oh, urg, settings meeting time!
[14:00] <tedg> seb128, Hmm, let me see.
[14:00] <Laney> is that now?
[14:00] <seb128> tedg, Laney, charles, meeting :p
[14:00] <seb128> well, according to my google calendar
[14:00] <Laney> I got tz confused
[14:00] <Laney> what evs, now is fine
[14:00] <seb128> we never defined if that was utc constant
[14:00] <seb128> I'm fine shifting 1 hour if you guys prefer
[14:00] <Laney> 1 minute, refilling tea
[14:01] <tedg> I don't care either way.
[14:02] <seb128> let's do it now/keep that time then
[14:02] <tedg> But I do have 1 additional Upstart. Which is odd, seems to not be consistent :-/
[14:02] <xnox> seb128: Laney: cherrypicked/ported pidgin to gstreamer1.0 and that compiles, but fails at runtime. Uploaded into unapproved empathy that drops haze from recommends to suggests, since there is no default/discovarable UI to configure any of the accounts that haze/libpurple provide and upgrades are unaffected.
[14:03] <tedg> I guess there are two options, Upstart isn't getting the SIGTERM or it's ignoring it.
[14:03] <tedg> xnox, Is there anyway that Upstart could ignore a SIGTERM?
[14:03] <Laney> haze: whatever (maybe the docs team want to document this though)
[14:03] <Laney> aim/yahoo, not sure at all, might want to revert that
[14:04] <xnox> Laney: aim & yahoo hard depend on telepathy-haze...
[14:05] <xnox> i should boot an older image to see the net-difference of available options.
[14:06]  * Laney shrugs
[14:06] <mvo_> gar, I made the mistake to check the lkml systemd/debug cmdline thread :/
[14:06] <Laney> if that's the case then we get to keep it
[14:08] <xnox> Laney: how should i propose the change for discussion? ubuntu-devel post?
[14:08] <Laney> Can we just think about it after release?
[14:09] <xnox> Laney: imho we should be providing whatsapp & facebook chat login options as together they outnumber 10x-20x active users of aim&yahoo
[14:09] <Laney> I get the goal of dropping gstreamer but we've lived with it this far and I'd rather not rush it through now
[14:10] <xnox> Laney: dropping gstreamer is very technical/internal change, dropping IM networks is user-visible.
[14:10] <Laney> yes I know
[14:11] <Laney> you are trying to achieve the former by doing the latter
[14:11] <Laney> (facebook chat works already btw)
[14:11] <xnox> Laney: and if the goal is to drop gstreamer out of main, then pidgin pitivi qt-phonon all need porting, none of which will be done for trusty.
[14:11] <xnox> Laney: yeah, i guess reject proposed empathy and revert the previous upload.
[14:12] <Mirv> re: pitivi bug #1253009 still open though, pre-requirements were synced seemingly a few days ago
[14:12] <ubot2> Launchpad bug 1253009 in pitivi (Baltix) "[FFe] Please sync latest upstream release (0.9x) from Debian experimental - Pitivi developers recommends to use 0.92 or later" [Medium,Triaged] https://launchpad.net/bugs/1253009
[14:12]  * xnox ponders if new pitivi uses gst1.0 or not =)
[14:12] <Mirv> yes it does
[14:13] <xnox> good, one donw.
[14:14] <Mirv> s/experimental/unstable/ now, fixed
[14:14] <Laney> xnox: yeah that's what I thought, thanks
[14:15] <xnox> i'll give cherrypicking gst1.0 for pidgin another try, the patch was not that large and possible propose that if i'll get the darn thing do audio calls =)
[14:16] <Laney> I remember that previously I had it built but failing at runtime
[14:16] <xnox> same.
[14:16] <Laney> I remember using the test voice/video thingy in preferences
[14:16] <Laney> but even that didn't work
[14:16] <Laney> back then I didn't know pidgin 3.0 was going to take a lifetime :-)
[14:17] <seb128> xnox, speaking of pitivi, https://bugs.launchpad.net/bugs/1253009
[14:17] <ubot2> Launchpad bug 1253009 in pitivi (Baltix) "[FFe] Please sync latest upstream release (0.9x) from Debian unstable - Pitivi developers recommends to use 0.92 or later" [Medium,Triaged]
[14:17] <xnox> i should try out just pidgin 3.0 and see if that at all works first for audio/video =)
[14:25] <seb128> xnox, is pidgin3 a thing or is that the work in progress for the next/gtk3 version?
[14:26] <xnox> seb128: the hg tip of their mainline development repository has options to compile with gtk3/gst1.0 merged sometime between 2012 and 2013
[14:27] <ChrisTownsend> seb128: FYI, I have a fix for the Gtk scrolling issues in Compiz.
[14:30] <tedg> Laney, Can you pastebin your url-dispatcher* upstart logs to see if there's anything in those?
[14:31] <seb128> my dir is drw------- from april 2
[14:31] <Laney> ffs
[14:31] <Laney> I keep getting logind into a hung state
[14:31] <seb128> tedg, my logs have ** (process:29048): WARNING **: Unable to open URL database
[14:32] <seb128> that's url-dispatcher.log
[14:32] <Laney> makes SSHing to the desktop from this laptop take ages
[14:32] <Laney> http://paste.ubuntu.com/7198908/
[14:32] <Laney> tedg: ^
[14:33] <Laney> Some of those are from the <app>-dispatcher
[14:34] <tedg> Laney, That's the url-dispatcher.log or from the -refresh and -update jobs as well?
[14:36] <Laney> tedg: -update ones too, don't have any -refresh
[14:38] <tedg> Hmm, bother. Was hoping it was them :-)
[14:39] <Laney> seb128: do you have any files inside the directory?
[14:39] <seb128> no
[14:39] <seb128> it's empty
[14:40] <Laney> ok
[14:47] <tedg> Throw out an idea, perhaps it got created somehow previously?
[14:47] <tedg> i.e. it's not being created by the current code
[14:48] <Laney> That's what I'm guessing
[14:48] <Laney> Don't know this area well enough to suggest what
[14:52] <tedg> Thinking about putting a pre-start hook to detect the case and delete the dir.
[14:52] <tedg> It'd "solve" the problem for most.
[14:53] <tedg> Perhaps we could pull a recoverable error as well, get more data.
[14:53] <Laney> I was expecting you'd chmod it in code, but whatever works
[14:56] <tedg> Hoping it's a temporary fix.
[15:26] <tedg> Laney, Just to be curious, what's your umask set to? Anything funky?
[15:27] <seb128> tedg, stop looking for weird configs, that error tops e.u.c today, it's not a weird config one
[15:28] <seb128> tedg, and my umask is not tweaked
[15:28] <seb128> $ umask
[15:28] <seb128> 0002
[15:28] <tedg> seb128, Hmm, I just don't see anything standard doing that. Thought it was click, but it's calling g_mkdir_with_parents(777)
[15:29] <seb128> btw I can't reproduce, removing the dir and running the commands from the upstart job leads to correct permissions
[15:29] <Trevinho> seb128: hi, bregma told me that you had issue witht the force-quit dialog thing
[15:30] <seb128> Trevinho, hey, yes, I'm getting both the old and new dialogs
[15:30] <Trevinho> seb128: it looks weird to me btw... are you sure that for some reason your unity decor plugin is still active (and thus gtk-window-decorator)
[15:30] <Trevinho> seb128: it can't happen on new installs at all
[15:30] <Trevinho> unless someone don't run gtk-window-decorator
[15:30] <seb128> I don't know
[15:30] <seb128> how do I check?
[15:30] <Trevinho> seb128: check ccsm for active plugins or gsettings on unity profile
[15:31] <Trevinho> seb128: also ps aux |grep decorator
[15:31] <seb128> tedg, btw, the the .cache/url-dispatcher timestamp doesn't match any login, so it seems like that directory was not created at login... what else could create it?
[15:32] <tedg> seb128, That's kinda why I was thinking click. But looking through the click code, it seems pretty clean.
[15:32] <tedg> Nothing fancy there.
[15:33] <tedg> I thought perhaps I created the dir, but it seems to work fine on a clean install.
[15:33] <seb128> Trevinho, /usr/bin/gtk-window-decorator is running
[15:34] <Trevinho> seb128: yeah, that's why you get it, but it should not run
[15:34] <Trevinho> there's something that runs it
[15:34] <Trevinho> seb128: and it's not in default config
[15:34] <Trevinho> in theory I added migration scripts to prevent that
[15:34] <Trevinho> but....
[15:35] <Trevinho> seb128: I would actually drop compiz-gnome package from unity installations,  not know for what is needed
[15:36] <Trevinho> seb128: I mean, we should provide a compiz-unity instead, without that process, but not sure we can do it now
[15:37] <Trevinho> seb128: so gsettings get org.compiz.core:/org/compiz/profiles/unity/ active-plugins shows decor for you?
[15:37] <seb128> Trevinho, I mentioned it several times a month ago that you might want to drop the old decor plugin out of the default binary, to clean the gtk2 depends...
[15:37] <seb128> but you guys ignored me :p
[15:37] <Trevinho> seb128: oh, I actually didn't read any of your mentions.... maybe I wasn't directly pinged :)
[15:38] <seb128> Trevinho, yes it does
[15:38] <Trevinho> but, I thought we couldn't not to break flashback sessions
[15:39] <Trevinho> seb128: you also get the decor plugin mentioned on lsof -p $(pidof compiz)| grep decor ?
[15:39] <seb128> Trevinho, well, you could move the plugin to extra and have those session depends on that
[15:40] <Trevinho> seb128: is that something we're still in time to do?
[15:40] <seb128> yes, it's loaded
[15:40] <seb128> $ lsof -p $(pidof compiz)| grep decor
[15:40] <seb128> compiz  29394 seb128  mem    REG        8,1    174288  1978581 /usr/lib/compiz/libdecor.so
[15:40] <Trevinho> seb128: mh, weird as it should be discarded, but still...
[15:40] <Trevinho> now that's why you get that
[15:40] <Trevinho> wondering why the migration script didn't work for you
[15:41] <Trevinho> it's in /usr/share/session-migration/scripts/00_remove_decor_in_unity_session.py
[15:41] <Trevinho> seb128: if you run it now, (a part from a probabile crash), does it work?
[15:42] <seb128> Trevinho, I might have re-enabled it manually when didrocks was testing/having his decoration pixmap issues
[15:43] <Trevinho> seb128: ah, i see.
[15:43] <didrocks> hum, we do use as well upstart for session-migration on desktop?
[15:43] <seb128> yes
[15:43] <didrocks> ok
[15:43]  * didrocks gets out his theory for some failing cases
[15:44] <seb128> Trevinho, I just ran it, compiz segfaulted but the decor plugin is still in my gsettings config
[15:44] <Trevinho> didrocks, seb128: is the "gsettings values not being updated without using dconf" issue still there?
[15:45] <Trevinho> seb128: well... it shouldn't really... I mean if you call gsettings from that cmd you get it, but.... if you run the migration script again it should say it's not
[15:45] <Trevinho> seb128: so maybe the shell call is missing something and loading the default config instead
[15:45] <dbarth> charles: ping?
[15:45] <Trevinho> seb128: while your lsof of compiz should say none about decor
[15:45] <seb128> Trevinho, oh, indeed, lsof doesn't have it anymore now
[15:45] <seb128> weird
[15:46] <Trevinho> seb128: yeah, maybe the call is just wrong :)
[15:46] <Trevinho> while the python call is correct
[15:49] <Trevinho> seb128: aaaaaaaaaaaaah, the right path is gsettings get org.compiz.core:/org/compiz/profiles/unity/plugins/core/ active-plugins
[15:49] <didrocks> Trevinho: not sure what issue you are talking about :p
[15:49] <Trevinho> sorry :P
[15:49] <Trevinho> didrocks: there was an issue that using gsettings.set_blah_blah("...") on migration script, then the scripts where not actually saved
[15:50] <Trevinho> so most of migration scripts actually used dconf to write the settings value
[15:50] <didrocks> Trevinho: nothing changed AFAIK
[15:51] <Trevinho> seb128: can we retry a landing for the forcequit then?
[15:51] <seb128> Trevinho, sure, still the upgrade path seems flaky, we should ensure the decor plugin is unloaded, maybe make it conflicts with unity?
[15:52] <Trevinho> seb128: it's already conflicting with it and there are multiple migration scripts
[15:52] <Trevinho> seb128: the one you launched + the ones in ccsm
[15:52] <seb128> k, dunno how I ended up with both though
[15:53] <seb128> I still think we should move libdecor.so to another binary which we don't install by default
[15:53] <seb128> to clean out some of the binary depends it creates
[15:53] <Trevinho> seb128: yeah, I agree, if we can still do it, I can figure it out
[15:53] <seb128> Trevinho, seems it might be a bit late, which is a shame
[15:54] <Trevinho> in some spare time (in theory I'm in holiday now, but the weather is pretty bad here in Barcelona right now :°()
[15:54] <seb128> Trevinho, enjoy your holidays!
[15:54] <seb128> sorry I didn't know you were off work ;-)
[15:54] <Trevinho> seb128: yeah, I tried to, but I ended to be completely wet :D
[15:55] <Trevinho> seb128: so... since this is still a "quite busy" period I've still some time to fix things
[16:10] <l3on> Hi all !
[16:10] <l3on> I'm going to remove this patch in nautilus http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/nautilus/trusty/view/head:/debian/patches/ubuntu_titlebar_css.patch
[16:10] <l3on> and apply changes to themes. darkxst around ?
[16:11] <seb128> l3on, he's likely sleeping at this time, he's in .au
[16:11] <seb128> l3on, also I guess you want to say "you would like to suggest replacing it", right?
[16:12] <seb128> l3on, because you don't have commit access so I don't see how you are going to do it without asking us first...
[16:14] <l3on> seb128, yep. Right. That patch is wrong. You're are going to hardcode style properties in nautilus code. What's happen if someone use gnomeshell with Ambiance/Radiance themes ?
[16:15] <seb128> l3on, no idea, darkxst did it this way because it had issues doing it in the theme iirc
[16:15] <seb128> l3on, if you know how to do please open a bug with patches for review and subscribe ubuntu-sponsors
[16:15] <l3on> at same time patch has border-radius set to 0 that causes also on unity on 14.04
[16:16] <l3on> yep, seb128.. working on.
[16:16] <mhr3> didrocks, ping? quick question - when bumping soversion, do we have to change the pkg name too? ie soversion is going from 0->1, do we have to rename libunity-scopes0 to 1?
[16:16] <seb128> thanks
[16:16] <seb128> mhr3, yes
[16:18] <mhr3> seb128, and could we actually jump back at some point from 33 to 1?
[16:18] <seb128> mhr3, that would be backward ;-)
[16:18] <seb128> why would anyone do that?
[16:19] <mhr3> we're forced to release with pretty much every commit
[16:19] <seb128> mhr3, you could, at the risk of screwing things still using the real/previous "1" (assuming your new "1" has a different abi)
[16:19] <mhr3> and we haven't really reached official 1.0
[16:20] <seb128> mhr3, one days you guys are going to learn to stop changing the apis in incompatibles ways right?
[16:21] <mhr3> seb128, unlikely
[16:21] <mhr3> :P
[16:21] <seb128> k, so you just keep bumping the soname with every upload
[16:21] <seb128> and don't bother about going back to "1" one day ;-)
[16:21] <mhr3> just feels wrong to release a lib with soname 33 as the first real release
[16:22] <seb128> yeah, well go back to "1"
[16:22] <seb128> I doubt you are going to still have users of the previous abi you called "1" by then
[16:22] <seb128> mhr3, or just skip "1", go from "0" to "2"
[16:23] <seb128> mhr3, you can also rename the lib to "libunity-scopes-dont-learn-what-stable-abi-means-yet.so.<n>"
[16:23] <seb128> mhr3, and rename the lib the day you do learn ;-)
[16:23] <kenvandine> haha
[16:24] <mhr3> seb128, heh, but yes, exactly, at that point we're pretty sure noone is using anything <33
[16:24] <seb128> mhr3, you guys are writing a book on "how to not do thing" right?
[16:25] <mhr3> seb128, actually it's called "how ubuntu developers are forcing us to do the wrong things" :P
[16:25] <seb128> mhr3, you are the ones are not able to design a proper api and stick to it... ;-)
[16:26] <seb128> we just make sure you don't punch users in the face by doing incompatible changes without telling your users about those
[16:27] <happyaron> seb128: I reported that bug, :(
[16:27] <happyaron> seb128: for the firefox default search engine
[16:27] <happyaron> seems it's bug 800304, but I'm not very sure.
[16:27] <ubot2> Launchpad bug 800304 in firefox (Ubuntu) "browser.search.defaultenginename does not work from distribution.ini" [Low,Triaged] https://launchpad.net/bugs/800304
[16:34] <seb128> happyaron, right, I'm unsure it's a ubuntu-defaults-builder issue
[16:34] <seb128> seems rather a firefox one
[16:34] <seb128> chrisccoulson might be able to help you, at least to reply to questions
[16:35] <happyaron> ok
[16:53] <Laney> seb128: turned out to be an upstart bug ;-)
[16:53] <seb128> Laney, which one? the url-dispatcher permission thing?
[16:55] <Laney> seb128: yep
[16:56] <Laney> echo "manual\nexec sh -c umask" > ~/.config/upstart/test.conf; start test; sudo telinit u; start test; cat ~/.cache/upstart/test.log
[16:57] <Laney> or something like that, should show the difference before and after
[16:58] <seb128> no cookie for upstart!
[16:58] <seb128> Laney, where did you discuss/debug it?
[16:58] <Laney> #-touch
[16:58] <seb128> shrug, I close that one by error again ;-)
[16:58] <seb128> glad to see you figured it out though
[16:58] <Laney> touch hater
[16:59] <seb128> haha, you got me!
[16:59] <Laney> yeah, jod h got pinged so he should take a look
[16:59]  * seb128 wears his "desktop4ever" badge
[16:59] <ogra_> seb128, dude, its the future !
[16:59] <Laney> meanwhile ted ought to add some defensive code there ;-)
[16:59] <Laney> chmod it back and fix up the umask
[16:59] <seb128> ogra_, the desktop is the futur, I know!
[16:59] <ogra_> lol
[17:08]  * Laney → climbing
[17:08] <Laney> byesie bye
[17:09]  * Laney forgot to patch pilot today :(
[17:09]  * Laney moves it to tomorrow
[17:13] <seb128> Laney, have fun!
[17:29] <seb128> bregma, andyrock: what's the status of the screenlocking/screen dpms issue? did you guys talk with robert_ancell to figure out what to do next (adding interfaces to unity?) and who is doing it?
[17:29] <andyrock> i'm adding the interfaces
[17:29] <andyrock> and the fading effect
[17:29] <seb128> k
[17:30] <bregma> andyrock, is Trevinho there too?
[17:30] <seb128> did you/somebody let robert_ancell know?
[17:30] <bregma> andyrock, do you think you'll have something to propose today?
[17:30] <seb128> bregma, Trevinho said earlier that in theory is on vac day today?
[17:31] <bregma> seb128, yeah, but he's planning to visit andyrock at some point, with his laptop :)
[17:31] <seb128> ;-)
[17:32] <seb128> bregma, Trevinho, andyrock: anyway, please keep robert_ancell updated on what he happening, he started looking at those issues the other day, I would prefer avoiding duplication (e.g not having him continuing while you guys also work on the same thing)
[17:53] <andyrock> bregma, he was here before
[17:54] <andyrock> ok so to keep you guys updated, i've already implemented the fade effect
[17:54] <andyrock> the screen now turns off
[17:54] <andyrock> but sometimes stop working
[17:54] <andyrock> seb128, ^^^
[17:57] <seb128> andyrock, thanks
[17:57] <seb128> andyrock, stop working, like doesn't turn back on? or is unity not liking it?
[17:57] <andyrock> seb128, just unity emits the ActiveChanged signal
[17:58] <andyrock> but power-manager fails to turn off the screen
[17:59] <seb128> weird
[17:59] <seb128> well, working with some bug is better than not working ;-)
[17:59] <seb128> so maybe submit that for review so things keep moving
[18:04] <andyrock> well just need to finish it
[18:04] <andyrock> it's under unity-team
[18:04] <andyrock> so others can work on it
[18:05] <elfy> seb128: do you have a couple of minutes?
[18:31] <camako> I'm installing ubuntu on macbook pro.. Basically I got it running, but wifi drivers missing...
[18:31] <camako> MBP model-id=10,1
[18:31] <camako> ubuntu 12.04
[18:32] <camako> this mac has no wired interface, so I'll have to download to flash and install from there
[18:33] <camako> What packages do I need?
[18:33] <czajkowski> aloha
[18:35] <czajkowski> so today I keep getting https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1202754  but it's not adding any logs to it
[18:35] <ubot2> Launchpad bug 1202754 in update-manager (Ubuntu Saucy) "update-manager crashed with SystemExit in exit(): 0" [High,Confirmed]
[18:35] <czajkowski> am on Trusty
[18:35] <czajkowski> which does run very nicely
[18:35] <czajkowski> thank you :)
[18:49] <robert_ancell> larsu, do you have a link to the XDG_CURRENT_SESSION change?
[18:49] <robert_ancell> larsu, note we are currently using XDG_CURRENT_DESKTOP
[19:01] <seb128> robert_ancell, XDG_CURRENT_SESSION?
[19:02] <seb128> robert_ancell, hey btw ;-)
[19:02] <robert_ancell> seb128, hello
[19:02] <seb128> robert_ancell, I wonder if that's a typo, https://bugzilla.gnome.org/show_bug.cgi?id=727546 has XDG_CURRENT_DESKTOP
[19:02] <ubot2> Gnome bug 727546 in general "gdm-session: support XDG_CURRENT_DESKTOP" [Normal,Unconfirmed]
[19:03] <seb128> robert_ancell, yeah, seems like a typo in the commit message
[19:03] <robert_ancell> seb128, I thought as much
[19:03] <seb128> czajkowski, hey, how do you trigger it?
[19:04] <seb128> elfy, hey, I'm here now, better to leave some context when you have a question
[19:04] <elfy> seb128: yea - sorry - bug 1284635
[19:04] <ubot2> Launchpad bug 1284635 in ibus (Ubuntu Trusty) "Keyboard layout changes after login" [High,Confirmed] https://launchpad.net/bugs/1284635
[19:05] <elfy> we're getting really itchy and worried about that in Xubuntu land
[19:05] <elfy> I talked to happyaron - who said it's on his list, but he'd got higher priority things atm
[19:05] <seb128> robert_ancell, thanks for investigating the lockscreen/dpms issues btw, andyrocks said earlier that he's working on making unity emits the ActiveChanged signal
[19:06] <robert_ancell> seb128, cool
[19:06] <elfy> RC is next week and we're stuck with a system that loses keyboard layout for anyone not using a US layout ill they go and change it
[19:06] <seb128> elfy, I guess if I say 'patches are welcome' it doesn't help you?
[19:06] <elfy> lol
[19:07] <seb128> but reality is that we have our issues as well, and resources/hours in the day are what they are
[19:07] <seb128> so if xfce has issues they probably need to help getting those resolved
[19:07] <seb128> we help when we can but we are currently struggling with our lot of release issues and have no spare room to help you guys
[19:08] <elfy> mmm - our issue atm to be honest is that there was no problem till the update to the latest version
[19:09] <seb128> well, we are not upstream for ibus
[19:09] <elfy> I understand there's only 60 minutes in an hour - if you're really lucky
[19:09] <seb128> the update also resolved other issues
[19:10] <seb128> we also don't see the issue you describe on GNOME or Unity
[19:10] <elfy> I know
[19:10] <seb128> so it's not ibus being totally buggy, just an interaction issue with xfce
[19:10] <knome> seb128, it's not a long time ago that canonical wanted to set a policy that makes developers fix what they broke, even if it didn't affect them...
[19:11] <knome> seb128, if something is landed late in the cycle, even if it was "just" a new version from upstream, i expect the developer(s) in question to be responsible for at least looking at the issue
[19:11] <seb128> knome, what if the update came from Debian through a sync?
[19:12] <knome> i don't know
[19:12] <seb128> there we go
[19:12] <knome> does that prove it's our problem now either?
[19:13] <seb128> no, there is not blame/being "$flavor" problem there
[19:13] <seb128> it's just one of a long list of issues to be resolved for release with everybody being busy
[19:13] <knome> well, my point of view is:
[19:15] <knome> if it came from a non-automatical debian sync (i don't know if that's the case), the one who did the sync should be at least somewhat responsive to questions about the issue
[19:15] <knome> if it's an automatical sync... again, i don't know
[19:15] <elfy> and I don't know enough to make a comment
[19:16] <knome> i'm not a very technical person either, so i probably don't understand *all* the technical implications
[19:16] <knome> would it be completely out of question to revert back to the earlier version?
[19:16] <seb128> yes, it is
[19:16] <seb128> the update fixes as important issues on other flavors
[19:16] <knome> okay
[19:17] <seb128> so you would just trade a set of issues for a similar one
[19:17] <seb128> but living on an upstream-unmaintained version instead
[19:17] <knome> right, i acknowledge and agree the upstream version is better
[19:17] <seb128> the way forward is to fix the issue on the current one, not to dig ourself in staying on a version that is not maintained and has a bugs as well
[19:17] <knome> do you know if it's a manual or automatic sync?
[19:18] <seb128> it's a manual merge from happyaron
[19:18] <seb128> who is the who assigned to the bug
[19:18] <knome> right,
[19:18] <knome> in that case i would expect at least a quick look from him to our issue
[19:18] <elfy> seb128: aron xu
[19:18] <seb128> but he's having higher priority work assignments
[19:18] <elfy> sorry - catching up ...
[19:18] <knome> sure, i understand...
[19:18] <seb128> he had a look from what I know
[19:18] <seb128> it just needs work
[19:19] <knome> but it doesn't help us much, or fit to the "the one who breaks it, fixes it" policy
[19:19] <seb128> but he's busy with paid-work priorities and not having free slots to help there
[19:19] <seb128> not a lot we can do...
[19:19] <knome> and i do acknowledge he didn't necessarily "break" it...
[19:19] <knome> just to be clear,
[19:19] <seb128> right
[19:19] <seb128> that principle is right
[19:19] <seb128> but real world is what it is
[19:20] <knome> if a canonical employee breaks something, but has other more high priority work items, the policy doesn't apply?
[19:20] <seb128> lol
[19:20] <seb128> no, quite the contrary
[19:20] <knome> how so?
[19:20] <knome> he's working on the more high priority things now
[19:20] <seb128> if some community person do a sync and never show up again, what do you do?
[19:20] <seb128> hire people to find that person and force him into work?
[19:21] <knome> obviously there are different realities to volunteer people
[19:21] <seb128> you have probably more chance of Canonical employees to be hold responsible and help there
[19:21] <knome> yes, i acknowledge that
[19:21] <seb128> well, then your comment doesn't make sense
[19:21] <seb128> it's not because he's a Canoncial employee that he gets a free pass
[19:21] <knome> no,
[19:21] <knome> i'm not saying that
[19:22] <knome> let me rephrase
[19:22] <seb128> we all have priority lists
[19:22] <seb128> usually paid job comes first, because we need to pay for food and stuff
[19:22] <knome> sure...
[19:22] <seb128> then we help as free time allows
[19:22] <seb128> same apply here
[19:23] <knome> well, was the ibus sync paid work?
[19:23] <knome> or voluntary?
[19:23] <seb128> it ends up at "there are more things that need to be fixed than hours in a day"
[19:23] <knome> i understand
[19:23] <seb128> it was on work time (I guess)
[19:24] <knome> but i also see it as: things that are broken 'only' on flavors are always lower priority issues than issues with ubuntu desktop
[19:24] <seb128> but that work solved issues
[19:24] <seb128> where number-of-users-benefiting-from-the-change > users-having-issues probably
[19:24] <seb128> (that's assuming that Ubuntu has more users than Xubuntu)
[19:25] <seb128> well
[19:25] <knome> yes, so in reality it is as i said
[19:25] <knome> i'm not saying that's not how it shouldn't be, i completely empathise the canonical employees..
[19:25] <knome> but that's how it is
[19:25] <seb128> the priority is on doing what benefits most users?
[19:25] <seb128> sure it is
[19:25] <seb128> would you recommend on screwing most users for the benefit of a smaller part?
[19:25] <knome> and basically it means that for example, this issue will very unlikely be fixed
[19:26] <knome> no.
[19:26] <knome> i just said i understand why it is as it is
[19:26] <seb128> right, and I understand your frustration
[19:26] <knome> please understand that i'm just trying to assess what the situation for the xubuntu team here is
[19:26] <seb128> but the world being what it is I don't have an answer that would make you happy I think
[19:27] <knome> and it looks like: nobody has time and this fixed our issues so we will leave it as it
[19:27] <knome> *is
[19:27] <seb128> right, I understand that, and I'm on that side of the world as well quite often
[19:27] <seb128> reporting a bug on GTK that doesn't impact GNOME ends up the same way
[19:27] <knome> which leads us to the situation where we either try to find a ibus developer that understands the issue and is able to fix it in 2 weeks, or, drop ibus and make xubuntu unusable for many people
[19:28] <knome> of which the latter is, unfortunately, more realistic
[19:29] <seb128> yeah, I sadly don't have good alternative to suggest you
[19:29] <knome> i understand
[19:29] <seb128> happyaron can probably have a look, but I don't know if that's going to be before release
[19:29] <knome> is there anybody else that could possibly at least look at the issue ASAP?
[19:29] <knome> and if not...
[19:29] <seb128> so the issue should be at least fixable in a SRU/for LTS .1
[19:29] <knome> the other question is:
[19:30] <knome> does it make sense to sync things this late manually, if it's unrealistic to fix regressions the new versions introduce
[19:30] <seb128> the update was made because it fixes issues as said
[19:31] <knome> (more of a rhetorical question, yes i know it's a balance with fixing other issues as well)
[19:31] <seb128> there are probably more users happy about the update than ones unhappy
[19:31] <knome> too bad there isn't any way to measure that even after the release
[19:31] <seb128> you just happen to be in the unlucky minority
[19:31] <elfy> well for us - it seems to break for everyone not using a US layout
[19:31] <seb128> well, on xubuntu
[19:31] <seb128> we got no report on GNOME or Unity
[19:32] <seb128> which have a larger userbase than XFCE
[19:32] <brainwash> we don't use gnome-settings-daemon :(
[19:32] <seb128> (which is not an excuse for creating issues for XFCE, but if there is a call to be made)
[19:32] <brainwash> or the new fork
[19:32] <seb128> right
[19:32] <elfy> seb128: I checked during the time I was looking at it - it affects us, studio (obviously) lubuntu, mythbuntu
[19:33] <seb128> I'm just saying that reverting would hurt more users than it would help
[19:33] <seb128> so that's not a position I can defend
[19:33] <seb128> well, even without comparing userbases
[19:33] <elfy> I realise that :)
[19:33] <seb128> the way forward is not to live in the past, it's to fix the issues
[19:34] <elfy> and that ;)
[19:34] <brainwash> we basically just need someone who can analysis the situation and maybe explain why it fails to pick the system kb layout and falls back to en_US
[19:34] <seb128> and to reply to your questions, no it's not "unrealistic to fix regressions the new versions introduce"
[19:34] <seb128> it just happens it took a while for the issue to be flagged, and as we come close from release other important issues are raising priority as well
[19:34] <knome> so... it's realistic that somebody fixes the bug before release?
[19:35] <seb128> so we would probably have had cycles to fix it earlier
[19:35] <seb128> but it's getting late and everybody is on "we need to fix those for release" and swamped with work
[19:35] <knome> yep.
[19:36] <knome> which is why i was asking about syncing things late in the cycle
[19:36] <seb128> well, xubuntu doesn't have anybody wanting to do debugging?
[19:36] <knome> we don't have anybody who's able to
[19:36] <seb128> e.g you rely on the Ubuntu/Unity team or are screwed?
[19:36] <knome> we can do debugging, and we can run as much testing as needed
[19:36] <knome> but we are very short on developer resources this cycle
[19:36] <knome> so what we can do is limited
[19:36] <seb128> "that late"
[19:36] <seb128> the new ibus was synced a month ago
[19:36] <knome> we've even done most of our uploads via the sponsors queue
[19:37] <knome> yes, i'm not saying we are perfect either
[19:37] <seb128> the issue was not when the update happened
[19:37] <seb128> it's that it took you guys a while to flag it as an issue
[19:37] <elfy> it took a while to realise it was ibus tbh
[19:38] <seb128> you should have users running the devel release and telling you when thing go wrong
[19:38] <knome> seb128, we didn't want to tip the bug to the desktop team if we didn't know what was causing it, so we did our own debugging
[19:38] <seb128> so you have a few days of updates to look through
[19:38] <knome> the bug is filed in february
[19:38] <knome> we've been looking at it since
[19:39] <elfy> seb128: we do - I filed it a few days after the update I believe
[19:39] <knome> it was escalated to the desktop team when we knew it's likely to be ibus that's causing the bug
[19:39] <seb128> well, that's unfortunate that it didn't get raised up earlier
[19:39] <seb128> anyway, no point holding blames
[19:40] <seb128> not sure what to suggest doing next
[19:40] <knome> well the point is, we do try to do our best to make sure we don't point the desktop team to bugs that are caused by, say, xfce packages
[19:40] <seb128> do you have anyone that could test if the same issue is happening atm on Debian (which has the same ibus version)?
[19:40] <knome> we can make that happen
[19:41] <seb128> that would help
[19:41] <seb128> or maybe try installing the debian version on xubuntu and see if it has the same issue
[19:41] <seb128> that would rule in/out an Ubuntu specific issue
[19:41] <knome> i tried, but it's not that easy, you would need to downgrade a lot of dependencies
[19:41] <seb128> you can probably take the debian source and build it on Ubuntu
[19:42] <knome> hmm, sorry, that's not what i tried.
[19:42] <knome> i tried to use the version before the sync
[19:42] <seb128> oh
[19:42] <seb128> no, that's not useful, we know that this one works
[19:42] <seb128> what would be useful is to try the version from Debian to see if the issue comes from one of our patches
[19:42] <seb128> that would nail down the problem
[19:42] <knome> can you point me to it, and i'll get it tested now
[19:42] <seb128> http://packages.qa.debian.org/i/ibus.html
[19:43] <seb128> http://ftp.iut-bm.univ-fcomte.fr/debian/pool/main/i/ibus/
[19:43] <knome> thanks
[19:43] <seb128> I guess those should install fine on trusty, but I didn't try
[19:43] <knome> can i be in touch with you on this in the future?
[19:44] <seb128> sure, that's an open channel ;-)
[19:44] <seb128> you can find me (and others) pretty much any work day (less likely during the w.e)
[19:44] <elfy> thanks for the help seb128
[19:44] <seb128> yw!
[19:44] <knome> well i guess the real question is if you are willing to hear back on it
[19:44] <seb128> let me know how that goes
[19:45] <knome> or if you will just dismiss (which i'd also kind of understand...)
[19:45] <seb128> yes, I can't promise we can spend days on debugging
[19:45] <seb128> but I'm happing trying to help with the resources we have
[19:45] <knome> thanks
[19:45] <seb128> yw!
[19:45] <elfy> yep - thanks
[19:46] <seb128> if you find out that the issue is in one of our changes I can try to make we get to the bottom of the issue before release
[19:46] <seb128> if the issue is in Debian/upstream it might be more difficult
[19:47] <seb128> to make sure*
[19:47] <knome> yes, obviously
[21:48] <ochosi> hey Laney
[21:49] <ochosi> Laney: just in case you're still around, i wanted to quickly inquire about the recent change in the indicator-sound desktop file that brainwash asked about before
[21:50] <ochosi> it's not really clear to me why the "Hidden=True" setting is being added now (i mean: a bit late in the cycle). or, why it is added to some indicators only
[21:50] <ochosi> so i just wanted to know what's the plan with this
[22:03] <ochosi> Laney: if i should talk to someone else about this, that's also fine (just let me know who to bug :))
[22:04] <Laney> ochosi: hello
[22:04] <Laney> tedg did it, but I can explain
[22:04] <Laney> The desktop files in the /usr/share/.../xdg (whatever it is) directory turn off the ones in /etc/xdg/autostart/ when you're using upstart user sessions
[22:05] <Laney> they've been added for indicators that have been converted to upstart
[22:07] <ochosi> right
[22:08] <ochosi> but why the Hidden=True?
[22:08] <ochosi> i mean is it really necessary?
[22:09] <Laney> That's exactly how you turn off an autostart file
[22:09] <Laney> So yes
[22:09] <ochosi> humm, i see
[22:09] <ochosi> why hasnt that been done for all indicators then?
[22:09] <Laney> That directory is only relevant when you use upstart user sessions
[22:09] <ochosi> or has the change for the others simply not landed yet?
[22:09] <Laney> it has, but maybe they haven't all been uploaded yet
[22:09] <ochosi> ok
[22:10] <ochosi> well we've started seeing this so late now, it's quite meh to mess with our session so late in the cycle
[22:10] <ochosi> and while i was monitoring some of the pending changes to the indicators (for gtk-greeter) i didn't see this one coming
[22:11] <ochosi> i mean: it's quite meh for us to mess with our session...
[22:11] <ochosi> we don't even have uploaders around atm
[22:11] <Laney> I gave a few ways you can fix this earlier
[22:11] <ochosi> so changes have to go through the sponsors queue
[22:12] <ochosi> right, i guess we can launch all installed indicators in the session
[22:12] <ochosi> brainwash told me about that
[22:13] <ochosi> but then we'd need to have XFCE stripped from the OnlyShowIn= line
[22:13] <ochosi> cause otherwise the non-functional desktop-files show up in our session's autostart manager
[22:14] <ochosi> would that be a feasible change for you guys?
[22:14] <ochosi> (i.e. we use "loginctl emit indicator-services-start" and -end in our session and the desktop files don't show anymore in xubuntu)
[22:15] <Laney> That UI shouldn't be ignoring NoDisplay
[22:15] <ochosi> right, but we can't fix that right now
[22:15] <Laney> You can't drop OnlyShowIn if you want to use upstart otherwise it won't work
[22:16] <Laney> Well, that's what tells the XDG autostart files when to be considered
[22:16] <ochosi> hmkay
[22:16] <ochosi> last question, how would blacklisting work?
[22:16] <ochosi> (that's another option he mentioned)
[22:17] <Laney> dunno what you mean
[22:17] <Laney> If you mean not using upstart then that's /etc/upstart-xsessions
[22:17] <ochosi> "blacklist the upstart autostart launcher" is what he said
[22:17] <ochosi> right, but i have no idea what that will result in for us
[22:18] <ochosi> that seems like a rather drastic and inconvenient change
[22:18] <ochosi> not even sure whether indicators would still work for us then
[22:18] <Laney> they ought to
[22:18] <brainwash> blacklist might be the wrong term
[22:19] <brainwash> override the conf file
[22:19] <ochosi> what conf file?
[22:19] <brainwash> echo manual ...
[22:19] <Laney> That's for local overrides
[22:19] <brainwash> .config/upstart/indicator-xyz.conf
[22:20] <ochosi> brainwash: that doesn't sound like a very flexible solution though
[22:21] <brainwash> it's not
[22:21] <ochosi> so i'd rather rule that one out
[22:21] <brainwash> just a way to control the indicator started by upstart
[22:21] <ochosi> so we have two left:
[22:21] <brainwash> on the user side
[22:22] <ochosi> 1) don't use upstart user sessions anymore
[22:22] <ochosi> 2) start indicators in the session with the signal
[22:22] <ochosi> and i guess with 2) we also have to live with them showing in the session manager for now
[22:24] <brainwash> or patch xfce4-session?
[22:24] <brainwash> hack :)
[22:25] <ochosi> well we have to patch our session anyway...