[07:44] <duflu> Trevinho: How are you feeling now?
[07:59] <willcooke> night all
[07:59] <willcooke> err
[07:59] <willcooke> morning all
[08:01] <seb128> hey willcooke, how is australia? ;-)
[08:01] <willcooke> :DD
[08:01] <Laney> morning
[08:02]  * willcooke wishes he was still asleep 
[08:03] <duflu> Morning willcooke, Laney, seb128.... Australia is fine, until North Korea gets an ICBM
[08:04] <willcooke> duflu, you should be able to deploy the "giant tennis racket" defences
[08:05] <duflu> If that's a popular culture reference you should know I am neither cultured nor popular
[08:05]  * duflu shrugs
[08:06] <willcooke> I imagine that North Korea's missiles could be repelled by with an ACME style system
[08:06] <duflu> Ooh
[08:06] <duflu> ACME-style, not ACME Style System (copyright some fashionista)
[08:07] <TheMuso> The concern with tennis racket defences is whether the Au eastern and western states end up playing tennis with sed ICBM. :p
[08:07] <willcooke> http://weknowmemes.com/wp-content/uploads/2013/03/kim-jong-un-acme-meme.jpg
[08:07] <willcooke> etc
[08:08] <davmor2> Morning all
[08:09] <duflu> Morning davmor2
[08:09] <willcooke> Very exciting to see traffic on the desktop mailing list again :)
[08:10] <duflu> And a strange observation: I think #ubuntu-touch is now more populated than ever
[08:10] <TheMuso> lol
[08:11] <TheMuso> Interesting indeed.
[08:50] <Laney> welp
[08:50] <Laney> that's pagerduty satisfied again
[08:50] <Laney> a harsh master
[08:59] <chrisccoulson> good morning desktop team
[08:59] <willcooke> hey chrisccoulson
[09:00] <chrisccoulson> hi willcooke :)
[09:22] <Trevinho> duflu: oh, very well now thanks for asking
[09:23] <Trevinho> duflu: the infection was fixed in couple of days of antibiotics
[09:23] <Trevinho> btw, hi europe :-)
[09:45] <seb128> hey Trevinho
[09:46] <Trevinho> hey seb128
[09:46] <seb128> had a good day?
[10:10] <chrisccoulson> does gnome-shell have a way to alt-tab between windows only on the current workspace?
[10:12] <ogra_> i think there is an extension :)
[10:13] <chrisccoulson> multi-monitor/workspaces is quite sucky compared to unity tbh. In the activities view, the workspace switcher only shows previews for the primary monitor
[10:14] <chrisccoulson> unity showed previews for both monitors
[10:15] <chrisccoulson> And I do most of my work on my external panel, which has to be the secondary screen in gnome shell
[10:16] <chrisccoulson> I can't make my external panel the primary screen, as it's positioned physically to the right of my laptop panel which means I can't reveal the dock on it (i'm using the dashtodock extension) and the activities button is hard to hit (unity had a barrier between screens for this reason)
[10:18] <chrisccoulson> And the out-of-the-box setting of only having workspaces on the primary monitor isn't great
[10:19] <chrisccoulson> I'm glad that can be turned off
[10:19] <chrisccoulson> Sorry, I'll quit moaning now ;)
[10:34] <seb128> chrisccoulson, that's good feedback don't be sorry :-)
[10:34] <chrisccoulson> seb128, I don't know if the theme was discussed yet? Please tell me we're going to fix Ambiance to work nicely? ;)
[10:36] <seb128> it was discussed during the meeting yesterday
[10:36] <seb128> it's a known problem and needs to be sorted out
[10:36] <seb128> unsure who&when though
[10:48] <ogra_> chrisccoulson, the workspace grid extension might help
[10:49] <ogra_> (to get the workspaces elsewhere and also not in one vertical column)
[10:55] <chrisccoulson> ogra_, thanks, I might give that a try
[11:18] <jbicha> good morning
[11:30] <willcooke> hey jbicha
[11:34] <flocculant> willcooke: re all the changes - you planning to have some meeting with flavours - for bits that affect them (of the top of my head from Xubuntu pov, lightdm and indicators do (but no dev so don't ask me more ...))
[11:35] <flocculant> obviously waiting for the chaff to settle out :)
[11:38] <jbicha> flocculant: it's on our to-do list to discuss lightdm on the ubuntu-desktop list
[11:39] <flocculant> jbicha: ack seen all that :)
[11:39] <willcooke> flocculant, yeah for sure.  Like you say, once things are settled and we know what's changing.  We certainly dont want to make things hard for you guys.
[11:39] <willcooke> flocculant, but feel free to ping in here with any questions any time
[11:39] <willcooke> the answer might be "dunno" but dont let that stop you :)_
[11:39] <flocculant> willcooke: yea will do - I'm not shy :p
[11:39] <willcooke> :)
[11:40] <flocculant> 2 of our dev's are in channel too - though timezones for one and work for the other ;)
[11:40] <flocculant> I did relay pad url etc to us
[11:41] <jbicha> willcooke: I'm surprised you brought up Nylas; the more email clients people suggest, the stronger the no-email-client argument becomes if there isn't concensus on which email client to include
[11:41] <flocculant> willcooke: I'm not sure how other flavours would be affected of course and no idea of they're idling - just thought I'd mention flavours :)
[11:45]  * acheronUK 'idles'
[11:52] <jbicha> willcooke: do you use Nylas?
[11:52] <willcooke> jbicha, I use web mail.  But it seems to be one of the more active clients right now.
[11:53] <jbicha> I just installed it but I don't feel like setting up a Nylas account just so I can run the app
[11:55] <willcooke> fair criticism
[12:53] <jdstrand> seb128: hey, are you using any sort of tagging for gnome/wayland issues? I've collected a few and wanted to make sure they showed up on your radar
[12:58] <jbicha> I suggest just using the tag 'wayland'
[13:01]  * jdstrand nods
[13:01] <seb128> jdstrand, hey, no sorry I've not been switching focus on playing with new things yet, busy with 17.04 and planning still, you seem quite eager to start on the next cycle though :-) ... I was going to suggest asking jbicha but he just replied ;-)
[13:01] <jdstrand> seb128: well, I'm assigned some snappy work wrt wayland, so yes, I'm using it :)
[13:02] <willcooke> jdstrand, are you working on Wayland interfaces already?  That was something I want to get kicked off and was just ponder who could work on that
[13:02] <Trevinho> willcooke:  I can have a look to those too, if needed.
[13:02] <willcooke> jdstrand, as in.. if you are, do you need some help?
[13:03] <jdstrand> willcooke: I am working on waland and basic gnome3, yes. not portals
[13:03] <jdstrand> (like how we have x11 and unity7, I'd like wayland and gnome)
[13:03] <jdstrand> going to put plasma in there too
[13:04] <jdstrand> Trevinho: I can ping you on the PR
[13:04] <willcooke> jdstrand, yeah, I was thinking the same re: unity7 etc.  So, you want some help?
[13:05] <jdstrand> willcooke: the thing I could use help with is XDG_RUNTIME_DIR and this forum topic: https://forum.snapcraft.io/t/wayland-dconf-and-xdg-runtime-dir/186
[13:05] <jdstrand> basically, for dconf, it was decided to set XDG_RUNTIME_DIR to /run/user/<uid>/snap.$SNAP_NAME
[13:05] <willcooke> Trevinho, thanks for offering, you want to pitch in on that then? ^
[13:07] <Trevinho> willcooke: I can... I'm currently workking in the snap preload to remove some of the desktop-qt* stuff... So that there's path redirection instead of using env variables for everything... And that should be eventually be part of the desktop parts.
[13:07] <jdstrand> that works for dconf because it was coded that way, but allison[m] decided that wasn't the best course after all, and looking at wayland, I agree. wayland puts a socket in /run/user/<uid> so snaps can't find it. even with desktop part shenanigans to find it, then the client code puts another socket in /run/user/<uid>/snap.$SNAP_NAME
[13:07] <Trevinho> so, this is different, but related
[13:08] <jdstrand> so then wayland the server can't find it
[13:08] <jdstrand> so really, XDG_RUNTIME_DIR needs to be /run/user/<uid> and we should use per-snap bind mounts
[13:08] <jdstrand> similar to what flatpak does
[13:08] <Trevinho> jdstrand: using snapcraft-preload, couldn't be a better solution?
[13:09] <Trevinho> jdstrand: so, that we redirect what we need to the proper path in that case
[13:10] <Trevinho> or.... Well, not sure... as I guess we won't have access to that anyway... But, if we grant access to /run/user/<uid>/wayland-soket only, then we can just allow accessing to that
[13:10] <jdstrand> Trevinho: well, maybe. I mean we already do a per-snap /tmp, we could do a per-snap XDG_RUNTIME_DIR. the thing with the preload plugin is it will mean every desktop snap to be used on gnome/wayland needs to use it
[13:10] <jdstrand> I figured that preload was a 'only if you need it' type of thing
[13:11] <jdstrand> actually, that won't work anyway
[13:11] <jdstrand> well, it depends
[13:11] <jdstrand> there is finding the wayland socket in /run/user/uid
[13:11] <Trevinho> jdstrand: well... as desktop-<part> are "optional", but withouth them things won't work....
[13:11] <jdstrand> but there is also putting the client side in the same dir as the server socket
[13:11] <Trevinho> I was thinking to use the preload by default in desktop parts soon... But need to finish some stuff on them
[13:12] <jdstrand> otherwise wayland can't find it
[13:12] <Trevinho> anyway... Sure, this is just partially related.
[13:12] <jdstrand> that's a lot of conditional logic
[13:13] <jdstrand> cause some sockets should go in SNAP_DATA, but these must be in XDG_RUNTIME_DIR
[13:14] <jdstrand> also, recent versions of preload broke a python snap of mine (I haven't looked into it-- I'm fetching a particular git commit now)
[13:14] <jdstrand> so I'm somewhat concerned about that
[13:14] <jdstrand> let me add my wayland findings to that forum post, then the conversation can be brought up there
[13:15] <Trevinho> jdstrand: oh, what broke your script? Let me know, as I could be the cause too :-)
[13:15] <Trevinho> jdstrand: and I've a rewrite in c++ in progress of it... And some other changes.
[13:16] <jdstrand> Trevinho: all of a sudden things were racy and the tool would sometimes segfault. https://code.launchpad.net/~myapps-reviewers/review-tools/+git/review-tools
[13:17] <jdstrand> Trevinho: this is the workaround: https://git.launchpad.net/review-tools/commit/?id=5446aecf89902f70e62acd72197313c303066b65
[13:17] <Trevinho> jdstrand: did you try to go back in revision?
[13:17] <Trevinho> ah i see
[13:17] <jdstrand> Trevinho: (don't worry about the build-packages part, that is a separate thing)
[13:18] <jdstrand> Trevinho: if you build with master, then install the snap and then do 'snap-review ./review-tools*.snap' (or any other snap) you can see what I mean
[13:18] <Trevinho> ok, I'll check that tomorrow
[13:18] <Trevinho> jdstrand: any way to reproduce?
[13:18] <Trevinho> ok
[13:18] <jdstrand> do it over and over again. it usually segfaults. it sometimes doesn't
[13:19] <jdstrand> Trevinho: if you are building on amd64, make sure the build-packages is uncommented like in that commit
[13:19] <Trevinho> jdstrand: fun that probably one of the commits causing issues, is the one that allows it to run X11 apps...
[13:20] <Trevinho> ouch, debugging under snap isn't the funniest things to setup :-)
[13:20] <jdstrand> Trevinho: for context, it is using preload for python3-magic and finding various magic files
[13:21] <Trevinho> ack
[13:28] <Trevinho> jdstrand: related and urelated... But do you have any clue, why if I "access" or "stat" a .dotted file/folder in my home that is indeed not readable under snap, these don't return -1?
[13:29] <Trevinho> jdstrand: it's something I'm doing in still in preload, at a certain point my app tries to access to ~/.ssh (that for some missing features points to my /home/user/.ssh) and... at that point if I access that path, it won't return -1. Although it's not readable, of course
[13:30] <Trevinho> in fact in the very same scenario, C++'s std::ifstream (pathname).good () returns false.
[13:30] <seb128> Trevinho, the preload thing is a hack and feels wrong to me, big -1 on using that for desktop part imho
[13:31] <jdstrand> Trevinho: yes. let me get the bug number
[13:31] <Trevinho> seb128: it's really the only way we have to ensure we access to the proper paths...
[13:31] <Trevinho> seb128: env vars don't cover all the things
[13:31] <jdstrand> Trevinho: https://bugs.launchpad.net/apparmor/+bug/1655435
[13:31] <Trevinho> seb128: and if we're not going to proper bind mounts, ever... there's no other ways to cover many cases
[13:31] <seb128> Trevinho, you can make code rellocatable as well
[13:32] <Trevinho> seb128: what you mean?
[13:32] <seb128> Trevinho, it's a big hammer, might be needed in some cases but shouldn't be default imho
[13:32] <seb128> Trevinho, code can be made to look at proper env variable or such if needed
[13:33] <Trevinho> seb128: well, the way preloads work is that... If the path the apps tries to point exists, and it's readable... then it uses it. Otherwise it looks under $SNAP... This is not wrong imho
[13:33] <Trevinho> seb128: sure, but so many tools won't do that
[13:33] <Trevinho> seb128: so... basically it's conservative in the way it does...
[13:33] <seb128> still it's hacking and creates lot of un-necessary syscalls
[13:34] <seb128> hackish
[13:34] <Trevinho> this is true...
[13:34] <Trevinho> but... That's where we are
[13:34] <Trevinho> seb128: the hack of using a /snap/<name>/current prefix for building is even worse imho...
[13:35] <seb128> it's not an hack
[13:35] <seb128> it has no side effect
[13:35] <Trevinho> seb128: as for example, it doesn't work in sub-libs...
[13:35] <Trevinho> seb128: and it doesn't work in non-ubuntu env
[13:35] <seb128> why not?
[13:35] <Trevinho> as /snap is not there in non-ubuntu
[13:35] <seb128> right, I pointed that on the list several time
[13:35] <Trevinho> it might be in /var/snapd/...
[13:35] <seb128> we should have a /run stable entry point
[13:36] <seb128> so we could use that one as prefix
[13:36] <seb128> that symlink to the real dir
[13:36] <Trevinho> seb128: anyway the main issue of it, is that... if you include a lib that has plugins... you need to rebuild all with that prefix. And it's not nice.
[13:36] <seb128> building on hacks is not nice either...
[13:37] <pitti> xnox: "gnome-terminal -x mutt" :)
[13:37] <Trevinho> seb128: there was some discussion in https://github.com/nextcloud/client_theming/pull/77#issuecomment-284541717 too
[13:38] <Trevinho> seb128: well, it depends.. If in future we'll going to have proper bind mounts, then it would make the transition easier..
[13:39] <Trevinho> in general I noticed more reliability on preload than using the desktop launchers... Considering that it has not the problem of the first-slow-startup
[13:39] <Trevinho> anyway... I can just add dependent parts that uses it optionally... It's not that I want to push it, but in general I find it to be more reliable than other things
[13:39] <Trevinho> Well, since when I made it working with X :-)
[13:40] <Trevinho> Anyway, time to go for me...
[13:40] <Trevinho> See you tomorow.
[13:43] <jdstrand> willcooke, seb128, Trevinho: fyi, https://forum.snapcraft.io/t/wayland-dconf-and-xdg-runtime-dir/186/4
[13:43] <jdstrand> bye Trevinho :)
[13:44] <seb128> Trevinho, night
[13:45] <xnox> pitti, what is mutt?
[13:46] <ogra_> xnox, evolution without toolkit ;)
[13:48] <pitti> xnox: vim's best friend :)
[13:49] <pitti> (actually it says the other way round, but I consider a friendship relation as symmetric)
[14:16] <jdstrand> willcooke, Trevinho, seb128, allison[m]: ah, https://forum.snapcraft.io/t/wayland-dconf-and-xdg-runtime-dir/186/5
[14:45] <seb128> jbicha, kenvandine, I changed the "approved" column on the MIR_List wiki to "-" for things that were in main before, like as "not applicable"
[14:45] <seb128> those just need to be moved back
[14:46] <kenvandine> seb128, thx
[14:46] <jbicha> seb128: cool, I asked earlier in #ubuntu-hardened about that but didn't get a response yet how those would be handled
[14:48] <seb128> k
[14:48] <seb128> in the past we just re-promoted things
[14:48] <seb128> but doesn't hurt to ask
[14:49] <seb128> jbicha, some of the packages names in that table start with a "-", does it mean something or just formatting inconsistency?
[14:49] <seb128> like "- gnome-settings-daemon "
[14:49] <kenvandine> no
[14:50] <kenvandine> i think that's is nesting it under something else that depends on it
[14:50] <seb128> vs "gnome-control-center "
[14:50] <kenvandine> at least i suspect
[14:50] <seb128> oh
[14:50] <jbicha> it's undocumented nesting
[14:50] <kenvandine> like mozjs is under gjs
[14:50] <seb128> g-s-d depends on g-c-c?
[14:50] <seb128> the other way around sorry
[14:50] <kenvandine> yeah
[14:50] <seb128> k
[14:50] <seb128> thanks :-)
[14:50] <seb128> that makes sense
[14:51] <seb128> there is probably more of that to add then
[14:51] <jbicha> gnome-shell depends on everything else in group 1 though
[14:51] <kenvandine> jbicha, what exactly is Old MIR?
[14:51] <seb128> like gnome-characters uses js stuff
[14:51] <kenvandine> just it had a MIR that was never approved?
[14:51] <kenvandine> oh, at least a couple were
[14:51] <jbicha> kenvandine: it was previously in main with an approved MIR
[14:52] <kenvandine> so then approved should be a "-"
[14:52] <jbicha> some stuff has always been in Ubuntu so it never had a MIR
[14:52] <kenvandine> yeah
[14:53] <jbicha> kenvandine: yes
[14:54] <alexarnaud> Hello all :) !
[14:54]  * kenvandine edits
[14:55] <alexarnaud> https://code.launchpad.net/~ksamak/compiz/ezoom_focus_tracking/+merge/321643
[14:55] <alexarnaud> andyrock: Do you wait something more for the this MR ?
[14:56] <andyrock> andyrock: I need to take another look but not sure I can't right now
[14:57] <alexarnaud> andyrock: OK, when you think you could take a look to that? We wait the merge of this to paid ksamak and we are going to improve focus tracking often so we wouldn't increase the size of the MR each month.
[14:58] <alexarnaud> :)
[15:06] <andyrock> alexarnaud: I'll try to review today/tomorro
[15:06] <andyrock> *it
[15:07] <andyrock> I guess Trevinho can take a look too
[15:07] <alexarnaud> Great,
[15:07] <andyrock> but merging will require time
[15:08] <alexarnaud> andyrock: I know that, we have take time to develop and test this code also. I'm using this code everyday to use my computer.
[15:08] <alexarnaud> It will make Ubuntu more accessible for low-vision persons.
[15:09] <andyrock> I know but we also need to make sure that this does not conflict with unity
[15:10] <willcooke> kenvandine, installing Ubuntu GNOME here, I just saw Brasero whizz past.  That's one for the "should we / shouldn't we" list. :)
[15:11] <willcooke> cc: seb128 jbicha ^
[15:12] <jbicha> willcooke: what version are you installing?
[15:12] <willcooke> jbicha, installing ubuntu-gnome-desktop on a 17.04 machine
[15:12] <kenvandine> willcooke, we should be looking at zesty
[15:12] <kenvandine> could be quite a delta
[15:12] <willcooke> is it dropped from there already?
[15:13] <kenvandine> haven't checked yet
[15:13] <jbicha> in 17.04 I split Brasero's Nautilus extension out of Brasero and only the Nautilus extension is installed by default in new installs
[15:13] <willcooke> ahh
[15:13] <willcooke> yeah, looking more closely its not installed
[15:13] <willcooke> sorry
[15:14] <jbicha> it has some nice integration but you don't have to deal with brasero's outdated and poorly maintained main UI
[15:14] <jbicha> you can right click on an ISO to use it to burn a CD/DVD
[15:14] <willcooke> ooh, nice
[15:15] <seb128> kenvandine, 17.04 is zesty no?
[15:15] <kenvandine> oh whoops :)
[15:15] <kenvandine> confused with 16.05 :)
[15:15] <seb128> also I don't think we want to start from Ubuntu GNOME
[15:15] <kenvandine> 04
[15:15] <seb128> we probably want to start by switching the desktop and keeping our apps selection
[15:15] <kenvandine> yeah, i'm installing zesty in a VM now
[15:15] <kenvandine> and will start by installing gnome-shell
[15:16] <seb128> then we can review the diffs and see what we want to bring in
[15:16] <kenvandine> and build from there
[15:16] <seb128> good plan
[15:16] <seb128> did you read the meeting log yesterday?
[15:16] <seb128> La_ney set up a ppa
[15:16] <kenvandine> seb128, i was quieting listening :)
[15:16] <jbicha> I have a wishlist bug for that to be integrated into Nautilus directly https://bugzilla.gnome.org/772495
[15:22] <ogra_> seb128, do you think someone from the desktop team might be able to give a statement on https://forum.snapcraft.io/t/integrate-snapd-xdg-open-into-snapd-repository/100/55 ? (robert did already but i dont think he researched what is there already and has not seen the hack around logind to work around it in the new proposal)
[16:01] <seb128> ogra_, robert_ancell already commented, maybe asking him to update according to the new content?
[16:03] <ogra_> seb128, well, any comment would be fine so snapd doesnt hack around logind/polkit
[16:03] <ogra_> i simple am not heard by the decision maker
[16:03] <seb128> I don't understand what those have to do with url handling
[16:03] <ogra_> (and i think morphis gave up too)
[16:03] <seb128> well it's typical discussion
[16:04] <seb128> everybody agrees but Gustavo doesn't and he's not going to move
[16:04] <seb128> so people just give up and go do something else
[16:04] <ogra_> seb128, snaps run inside the core snap ... to hand out the url request to xdg-open on the running desktop we have a dbus service sitting in the session currently that the snap can hand the url to
[16:05] <seb128> yeah, I'm pretty well aware of how the current implementation works
[16:05] <seb128> and it's the logical thing to do
[16:05] <ogra_> what gistavo wants is to not use dbus, instead fish the session address out of logind via some env inspection of processes in proc and then force call xdg-open directly
[16:05] <seb128> the service should just be shipped with snapd to avoid the depends issue
[16:05] <seb128> that seems hackish and likely to bite back
[16:06] <ogra_> what i'm trying to do is to convince him to keep the (rather sane in that light) current implementation
[16:06] <seb128> +1
[16:06] <ogra_> but i'm unheard or turned down ... so i'd like to have someone comment that he considers more compenent than me ;)
[16:06] <ogra_> and yes, robert commented but pretty high up in the thread
[16:07] <ogra_> it evolved since
[16:08] <seb128> we can do that I guess
[16:08] <ogra_> thanks :)
[16:08] <seb128> yw
[17:41] <willcooke> night all
[18:25] <chrisccoulson> Heh, I found something I like in gnome shell that isn't in unity
[18:25] <chrisccoulson> night mode is pretty cool
[22:37] <ryanleesipes> chrisccoulson: right?