[05:40] <oSoMoN> good morning desktoppers
[05:43] <seb128> hey oSoMoN, how are you?
[06:02] <oSoMoN> hey seb128, good and you?
[06:59] <didrocks> good morning
[07:20] <seb128> oSoMoN, I'm good thanks
[08:02] <Laney> hey hey HEY!
[08:07] <ricotz> ochosi, hi :), make sure to enable debug-symbols build/publishing of a ppa where you build libreoffice
[08:07] <ricotz> oSoMoN, ^
[08:07] <ricotz> ochosi, sorry
[08:09] <seb128> hey Laney,how are you?
[08:10] <oSoMoN> ricotz, ack
[08:11] <oSoMoN> hey hey HEY Laney
[08:13] <willcooke> morning all
[08:13] <seb128> I'm stepping out for a an hour or so (probably less)
[08:13] <seb128> hey willcooke
[08:14] <oSoMoN> good morning willcooke
[08:15] <seb128> willcooke, how is london and the snappy discussions?
[08:15] <Laney> hey seb128
[08:15] <Laney> good thanks, tired for some reason though
[08:15] <Laney> you?
[08:15] <seb128> good
[08:15] <willcooke> seb128, we're making progress!
[08:15] <Laney> hey oSoMoN
[08:15] <seb128> though was up from 5 to 8
[08:15] <seb128> at least I worked some hours already
[08:15] <seb128> need to go for an appointement now, back in a bit
[08:15] <oSoMoN> wow, that's an early start
[08:42] <jamesh> seb128: I noticed your post about accessing themes from snapped applications.  If we only care about working on classic Ubuntu and only care about themes installed on the base system, I don't think this would be too difficult to implement
[08:46] <didrocks> jamesh: doesn't work, nothing will ensure you have a gtk theme corresponding to the app / platform snap you get
[08:47] <jamesh> didrocks: but the user's selected theme will be on the base system, no?
[08:47] <didrocks> well
[08:47] <didrocks> it means you need to have it for gtk 3.xx, 3.x+1, 3.x+2…
[08:47] <jamesh> yep.
[08:48] <jamesh> the base system would need to provide versions of the theme compatible with what's used by the confined app
[08:48] <didrocks> but that prevents people to deliver/port their themes
[08:48] <didrocks> as they will need to provide any version available to any gtk version some apps may be shipped as a snap
[08:49] <didrocks> nothing will enforce/ensure that, and it could then be a lottery, removing the "snap would work anywhere"
[08:49] <didrocks> also, other distros won't be supported
[08:49] <jamesh> didrocks: that's going to be the case anyway though, right?
[08:49] <didrocks> not really, if you have selected slots/plugs for this, that makes it predictable and portable accross distros
[08:52] <jamesh> didrocks: if the user's selected theme doesn't provide a version compatible with the app's GTK, would this look any worse than what currently happens?
[08:54] <didrocks> jamesh: what currently happens is that people embeed some themes in the snap. It's working for 90%+ of use case (if not more)
[08:54] <didrocks> the suggested solution is a step over that
[08:54] <didrocks> but at least, developers/users will only be able to select themes that are coming from snap themes
[08:54] <didrocks> so, giving us way more control
[08:54] <didrocks> accross distro
[08:55] <didrocks> which is the goal, right? To have desktop snaps everywhere and not restricted to ubuntu
[08:55] <didrocks> (or the new goal is only to have desktop classic snaps, so working on ubuntu, no portal/confinement?)
[08:55] <jamesh> didrocks: presumably they can still do that though, right?
[08:55] <didrocks> jamesh: only if we provide that feature, correct
[08:55] <Laney> interesting
[08:56] <jamesh> if XDG_DATA_DIRS causes them to find themes inside the snap and the base system's themes, they've got the same fallback.
[08:56] <didrocks> which is why there is this thread, to layout what's needed
[08:56] <Laney> with the proposal, will the system's themes be hidden from the snap?
[08:56] <didrocks> jamesh: no, classic is ubuntu only
[08:56] <Laney> or is it an overlay?
[08:56] <didrocks> Laney: that's a good question, right now (with the current arch) it would be hidden
[08:56] <jamesh> didrocks: really?  I thought classic was any system where the root file system wasn't managed by snapd.
[08:56] <didrocks> but we can extend it
[08:57] <didrocks> jamesh: from what I know, classic is ubuntu classic only
[08:57] <didrocks> I may be wrong though
[08:57] <didrocks> but I don't think we should offer a different experience for classic snaps than the confined ones
[08:57] <jamesh> didrocks: I think "classic mode" in snapd is distinct from "Ubuntu Classic"
[08:57] <didrocks> jamesh: I know it's different, but I'm pretty sure it's only running on ubuntu classic though
[08:58] <didrocks> (was disabled in fedora at least in the past for instance)
[08:58] <jamesh> didrocks: I'm not sure how graphical snaps would even work on Arch, Fedora, etc if they weren't running in classic mode.
[08:59] <didrocks> jamesh: why are we developping portals thus?
[08:59] <jamesh> that would require a snapped X server for instance
[08:59] <didrocks> as this won't work in classic?
[08:59] <jamesh> there's too many things called "classic"
[08:59] <jamesh> snapd's "classic confinement" is also different
[08:59] <didrocks> snap in classic mode
[08:59] <didrocks> which is what you are talking about, correct?
[09:00] <jamesh> didrocks: "classic confinement" == no AppArmor confinement, and direct access to the host's root file system
[09:00] <didrocks> yeah
[09:00] <didrocks> which is what we mean by "classic snaps"
[09:01] <jamesh> didrocks: "classic mode" == host system's root file system isn't the core snap, and a bunch of extra slots are automatically added to core
[09:01] <jamesh> such as "x11", "unity7", "network-manager", etc
[09:01] <didrocks> thanks, I know that for at least a year or so :p
[09:01] <didrocks> remember I worked on snapd? :p
[09:02] <jamesh> a strict confined snap may still be relying on features that are generally only available in classic mode
[09:02] <jamesh> so I'm wondering if access to system themes could be the same.
[09:03] <didrocks> that could be, but it means that distros will have to ship all themes again for all possible gtk version
[09:03] <didrocks> which they won't, as flatpak is going another way
[09:03] <didrocks> so, it will be mostly broken on non ubuntu distro
[09:04] <didrocks> (also, it means everytime a new gtk version is out, we need to upload any existings themes, even the 3rd parties, to include that gtk version)
[09:04] <didrocks> and all ditros will have to do that, as a SRU
[09:04] <didrocks> doesn't sound really scalable
[09:06] <jamesh> okay, so if we step back a bit, would "single snap providing all themes people care about, ever" be acceptable?
[09:07] <jamesh> that's not perfect either, but it gets around the SRU issue
[09:08] <jamesh> once you go to "multiple theme snaps talking to multiple app snaps", we're outside of what snapd's interfaces can currently handle
[09:08] <didrocks> jamesh: it's not single snap
[09:08] <didrocks> jamesh: it's one snap per theme
[09:09] <didrocks> yeah
[09:09] <zyga> https://github.com/snapcore/snapd/pull/3542
[09:09] <didrocks> but the idea is to have snapd support our use-case
[09:09] <jamesh> didrocks: and that's not going to work with the current plug/slot model
[09:09] <didrocks> jamesh: I know, the goal is to fix the software to work with it
[09:09] <didrocks> that's why we spent time on a gdoc and examples to illustrates that
[09:10] <didrocks> we are not going to be able to have one snap exposing any themes that could be community-contributed ever
[09:10] <didrocks> I guess there are good reasons it's not the approach (using system or one big snap) that flatpak went with either
[09:12] <willcooke> robert_ancell, see zyga's comment ^
[09:24] <andyrock> mooorning
[09:53] <seb128> jamesh, I don't know if we care only about classic
[09:54] <seb128> ideally you can build a device with a gtk frontend and a theme installed from a snap
[09:54] <seb128> I though we were designing things to work in an snap-only stack context in any case
[09:55] <seb128> but I see you already had a good discussion on the channel and Didier already made that point
[10:05] <didrocks> jamesh: also, you probably know it, but /usr/share/themes isn't suffcieitn
[10:05] <didrocks> sufficient*
[10:05] <didrocks> there are gtk engines like gtk2, used by Qt, which are in /usr/lib/<triplet>
[10:06] <didrocks> (and so, we need those dynamic name support)
[10:12] <popey> robert_ancell: heya, remember I set a cron job to open gnome software, having updated to the one you recommended. Still getting the issue http://imgur.com/a/K6chl
[10:12] <popey> robert_ancell: you mentioned there might be a log somewhere I can look at?
[10:13] <robert_ancell> popey, you can run gnome-software with --verbose
[10:14] <popey> robert_ancell: oh, so I am not in a position to provide info now, but need to run with --verbose for some days until it happens again?
[10:14] <robert_ancell> popey, yeah, that would give us something to see. I hope it doesn't cause it to not occur...
[10:14] <popey> ok
[10:16] <popey> thanks
[11:06] <ricotz> willcooke, hi, I guess I dare to ask one more time about admin-rights for https://launchpad.net/~libreoffice
[11:49] <seb128> ricotz, hey, what do you need the admin rights for there? I don't know if Will ever got back to you on the topic but we discussed it but Bjoern was the only one familiar with that ppa and your libreoffice work so we don't feel like we know enough about the topic to understand the consequences of the change or why you need admin rights
[11:49] <seb128> ricotz, it might help if you could email will/osomon/me with the rational or the changes you want to work on/do
[11:54] <ricotz> seb128, I explained it to Will some weeks ago with the promise to follow up on it, although nothing happened
[12:00] <seb128> ricotz, I can't speak for him, but he's busy and as said we discussed it and we feel like we lack knowledge, maybe you can email us 3 as suggested?
[12:07] <ricotz> seb128, alright, I won't pursue this further
[12:07] <seb128> as you wish
[12:07] <seb128> but as said I'm not speaking for Will, maybe he's going to get back to you about what you asked
[12:08] <seb128> I just know that I personally don't know enough libreoffice and that ppa to add an admin without understand why
[12:08] <seb128> understanding
[13:45] <seb128> cyphermox_, hey, still not around?
[13:46] <seb128> I should check hr, he might be off this week?
[13:47] <seb128> oh yeah, he's off until july 10th
[13:47] <seb128> great
[14:16] <seb128> jibel, did you figure out the livecd input issue? is that what is blocking the iso promotion to current?
[15:01] <GunnarHj> seb128: Thanks for spotting that i-d MP! So there has been a solution for months, and then there is that jenkins guy who blocks it. :( Who can move it forward?
[15:16] <seb128> GunnarHj, yw! what jenkins guy?
[15:17] <GunnarHj> seb128: jenkins.canonical.com. (Suppose it's some kind of bot...)
[15:20] <seb128> GunnarHj, what the bot is saying is that the change are making some tests fail, see https://jenkins.canonical.com/unity-api-1/job/build-2-binpkg/arch=amd64,release=xenial+overlay/1580/console
[15:20] <seb128> and what blocked it is mostly that the people who were working on it got fired and the project they worked on discontinued
[15:20] <seb128> so somebody needs to pick it up and make it working
[15:22] <GunnarHj> seb128: And Unity is being dropped anyway... Sounds as a "won't fix" to me. :(
[15:23] <GunnarHj> seb128: Especially since it's fine in the latest LTS.
[15:25] <seb128> GunnarHj, unity is not being dropped yet, it's moving in universe for now, and indicators are used in other desktops
[15:25] <seb128> shouldn't be too difficult to fix
[15:25] <seb128> also zesty is currently supported and ships with unity
[15:25] <seb128> though I'm unsure we are going to see a langpack update in zesty
[15:25] <seb128> so fixing it there might be useless
[15:27] <GunnarHj> seb128: Yeah... Charles Kerr stated on the MP that the bot failure is "false alarm".
[15:28] <GunnarHj> seb128: Which desktops besides Unity use the indicators?
[15:29] <seb128> GunnarHj, xubuntu has support for them, mate uses some
[15:30] <GunnarHj> seb128: I see. Thanks.
[15:30] <seb128> yw
[17:28] <Laney> ok, night!
[17:48] <oSoMoN> good night all!