[02:22] <duflu> RAOF: Have you tried doing colour calibration in 17.10 using the tooling from archive? I'm wondering if it's become more flakey in recent releases
[02:22] <RAOF> duflu: I have, and it doesn't work.
[02:22] <RAOF> But I'm not sure whether it's the software or my somewhat old and dusty colorhug.
[02:23] <duflu> RAOF: Oh good. Confirmation at least. Yeah a brand new one has trouble too. What works is changing the machine to support Legacy OS boot and then using the live USB
[02:23] <RAOF> Oh, ok.
[02:24] <duflu> I also wonder if there's a kernel or power management issue
[02:24] <duflu> Haven't tried explicitly disabling that
[02:24]  * RAOF should probably update colord
[02:24] <jamesh> robert_ancell: hi.  I was trying to reactivate my GNOME git account, and they asked me for a maintainer to vouch for me.  Would you count for that?
[02:25] <robert_ancell> jamesh, sure
[02:27] <duflu> RAOF: Obviously it would be nice if the workaround didn't require changing your BIOS and booting an old Fedora core :)
[02:28] <jamesh> thanks
[02:30] <duflu> -and +or
[02:42] <random_numbers> So, I'm getting a corrupt download for ubuntu-make on `umake android android-studio' with a fresh and up-to-date 17.04 install.
[05:57] <jibel> morning
[06:10] <oSoMoN> good morning desktoppers!
[06:38] <didrocks> good morning!
[06:39] <duflu> Morning didrocks
[06:40] <oSoMoN> good morning didrocks, good afternoon duflu
[06:40] <seb128> good morning desktopers
[06:40] <seb128> lut didrocks, oSoMoN
[06:40] <seb128> hey again on another channel duflu :-)
[06:40] <oSoMoN> salut seb128
[06:42] <oSoMoN> hey didrocks, is gnome-shell-extension-ubuntu-dock supposed to be always visible?
[06:42]  * duflu would vote for auto-hide but doesn't really mind
[06:42] <jibel> oSoMoN, you can enable auto-hide in the display settings
[06:43] <oSoMoN> jibel, but by default it’s supposed to be always visible, right?
[06:43] <duflu> Settings > Displays
[06:43] <oSoMoN> cause I’m not seeing anything actually, not even when pushing the mouse cursor to the left edge
[06:43] <duflu> It does interfere a bit with Gnome's nice maximized mode
[06:44] <oSoMoN> I uninstalled dash-to-dock on Friday when gnome-shell-extension-ubuntu-dock got auto-installed, and since then I’m launcherless
[06:44] <jibel> oSoMoN, i don't know if the default setting has been decided.
[06:44] <duflu> oSoMoN, yes it should also return if you push the cursor to the left edge
[06:44] <oSoMoN> then something is broken with my setup
[06:46] <oSoMoN> also I recently switch to wayland, and it appears Ctrl+Alt+L doesn't lock the session, annoying
[06:46] <duflu> oSoMoN, Super+L ?
[06:46] <oSoMoN> ah that does it indeed
[06:47] <duflu> Welcome to Windows
[06:47] <oSoMoN> :/
[06:47] <duflu> Sounds like a bug though. I would have thought Ctrl+Alt+L should stay
[06:49] <didrocks> hey duflu, oSoMoN, seb128 ;)
[06:49] <didrocks> oSoMoN: by default, yes
[06:50] <didrocks> oSoMoN: you can read my blog posts :p
[06:50] <oSoMoN> duflu, yes, if nothing else is mapped to Ctrl+Alt+L, it should retain the old behaviour
[06:50] <didrocks> (sorry, still under enorme amount of comments and fallback handlings)
[06:50] <oSoMoN> didrocks, right, in was on my reading list for the week-end, but I managed to stay away from the computer during the whole week-end!
[06:50] <didrocks> :)
[06:51] <didrocks> oSoMoN: ensure you have latest Shell as well
[06:51] <didrocks> it's what enables it
[06:51] <didrocks> and that you current session is, ofc, "ubuntu"
[06:51] <didrocks> duflu: the idea is to support both Super+L and Ctrl+Alt+l
[06:52] <duflu> Cool
[06:52] <didrocks> but contrary to Unity where the settings was an array, in GNOME, it's a string
[06:52] <didrocks> so, we'll need to patch this
[06:52] <duflu> Now how about bug 1693609 :)
[06:52] <didrocks> which will be in the "bug bucket list"
[06:52] <oSoMoN> DESKTOP_SESSION=ubuntu-wayland
[06:52] <didrocks> duflu: volonteering? :)
[06:52] <didrocks> oSoMoN: should work as well
[06:53] <duflu> didrocks, it's on my own bug bucket list of sorts. No idea when I would get to it
[07:18] <seb128> didrocks, do osk interacts with IMs?
[07:19]  * seb128 doesn't knows much about the topic but I though the osk would only send keycodes the same way a real keyboard does so wouldn't have any ibus/fcitx integration
[07:19] <didrocks> seb128: I think for keyboard layout, there are some interactions
[07:19] <seb128> I just read you email on -desktop@ and the comment is interesting
[07:19] <didrocks> seb128: I might be wrong though
[07:19] <seb128> k, let's see if people who have more clue comment :-)
[07:19] <didrocks> yeah ;)
[07:19] <didrocks> just wanted to raise it
[07:20] <seb128> btw is onboard displaying in azerty for you?
[07:20] <seb128> I've a french install with azerty keyboard but the osk is qwerty
[07:20] <seb128> caribou seems quite buggy and limited :-/
[07:20] <didrocks> how do you enable it back btw?
[07:21] <seb128> settings -> accessiblity
[07:21] <didrocks> yeah, it's an azerty keyboard
[07:21] <seb128> k, I guess to debug here then
[07:21] <didrocks> time for YOUR locale issue this time :p
[07:21] <didrocks> it's an old upgraded install from 12.04
[07:21] <seb128> haha
[07:21] <didrocks> not a new one, note this
[07:22] <seb128> shrug
[07:22] <didrocks> we really have very very positive overall comments
[07:22] <didrocks> in my blog posts
[07:22] <seb128> the osk goes over my hexchat windows
[07:22] <didrocks> (and a 100 of them)
[07:22] <seb128> and mask the entry where I'm typing
[07:22] <didrocks> yeah, same with weechat
[07:22] <didrocks> doesn't change the struts
[07:22] <didrocks> (was that the X terminology? Didn't use it for years, not even sure)
[07:23] <seb128> unsure but I know what you mean
[07:24] <didrocks> _NET_WM_STRUT
[07:24] <seb128> good to see that the feedback is positive btw :-)
[07:24] <didrocks> not a bad memory, after all :)
[07:24] <seb128> hehe
[07:25] <seb128> and we know how to make things ever better
[07:25] <seb128> but that's more work than we can chew in one cycle
[07:25] <seb128> not even talking about things caribou not being a good osk or ibus vs fcitx there though
[07:27] <didrocks> yeah
[07:30] <jamesh> maybe we should create yet another input method framework and declare it a standard.  That will get rid of all the ibus vs. fcitx problems
[07:33]  * didrocks sees that jamesh tries to do, but I'll be strong and refrain posting the xkcd link :p
[07:34] <didrocks> oSoMoN: as you are in the wayland session, you confirm you have icons on the desktop, correct?
[07:34] <didrocks> seb128: maybe a second users as well? ^
[07:39] <amano> That seems to be useful with caribou: https://extensions.gnome.org/extension/993/slide-for-keyboard/:
[07:39] <seb128> didrocks, works here but I had icons on the desktop before so my config is not vanilla, going to try on my other config a bit later
[07:40] <didrocks> seb128: thx!
[07:40] <seb128> yw
[07:41]  * didrocks needs to do some dock rebase to work with G-S 3.26
[07:43] <oSoMoN> didrocks, yes, I have icons on my desktop, including the recyclebin icon, but no dock/launcher at all
[07:43] <amano> https://extensions.gnome.org/extension/1024/caribou-resize-workspace/ that's the other extension gnome people seem to use with caribou. Perhaps that makes it usable.
[07:43] <oSoMoN> I read your blog post but that didn't bring the dock back
[07:44] <didrocks> oSoMoN: do you have latest GNOME Shell?
[07:44] <didrocks> the one uploaded on Friday?
[07:44] <oSoMoN> $ apt policy gnome-shell
[07:44] <oSoMoN> gnome-shell:
[07:44] <oSoMoN>   Installé : 3.24.3-0ubuntu4
[07:44] <didrocks> hum, and rebooted since then, correct?
[07:44] <oSoMoN> yes
[07:45] <didrocks> dconf dump /org/gnome/shell/
[07:45] <oSoMoN> interestingly, now I have a warning sign icon next to the ubuntu dock extension in gnome-tweak-tool, it’s disabled and I can't switch it on
[07:45] <didrocks> yeah, tweaks doesn't report the status correctly for system-wide enabled extensions
[07:46] <oSoMoN> didrocks, http://paste.ubuntu.com/25361180/
[07:46] <didrocks> ok, nothing worrying
[07:46] <oSoMoN> why do I have dash-to-dock enabled, if it's uninstalled?
[07:46] <didrocks> echo $GNOME_SHELL_SESSION_MODE
[07:46] <didrocks> oh, didn't spot the first one
[07:46] <didrocks> that's why
[07:47] <didrocks> and why do you have ubuntu-dock enabled as well?
[07:47] <oSoMoN> well I'd like to know why…
[07:47] <didrocks> you shouldn't, did you try adding it manually?
[07:47] <oSoMoN> no
[07:47] <didrocks> hum, maybe tweaks is really doing bad things
[07:47] <didrocks> when you open it…
[07:47] <oSoMoN> I only uninstalled dash-to-dock after I saw ubuntu-dock being installed automatically
[07:47] <didrocks> reset the key
[07:47] <didrocks> close tweaks
[07:48] <didrocks> like, ubuntu-dock should even not be in your list
[07:48] <didrocks> as it's a system-wide enabled extension by a mode
[07:49] <oSoMoN> ah, fixed by resetting the key
[07:50] <oSoMoN> thanks for the help didrocks
[07:50] <didrocks> oSoMoN: if you play with Tweaks and see anything wrong, please report it
[07:50] <oSoMoN> I don't know how I managed to get into that state, but I messed up badly
[07:50] <didrocks> I really wonder if tweaks doesn't do anything weird, first the status report should say enabled/disabled
[07:50] <didrocks> (but still putting it in gray)
[07:50] <didrocks> the chromium extensions does it properly
[07:51] <didrocks> well, you can disable it there, which is a no-op
[07:51] <didrocks> so "almost" well :)
[07:51] <didrocks> (maybe the shell doesn't give all infos…)
[07:53] <didrocks> new version of the dock for 3.26 support, it's nice to see 2 dash to upstream + Jeremy reached out to me to warn to pick it :)
[07:53]  * didrocks git rebases anyway as I was planningto
[07:54] <didrocks> seb128: did you see my comments on the dock second upload vs dashtodock binary package
[07:55] <didrocks> seb128: any opinion on what we should do? I would split the schema in a separate file and have dashtodock deps on it, but it means no sync from debian on that one
[07:59] <seb128> I saw that, give me some time to consider it
[08:02] <Laney> moin
[08:02] <amano> I
[08:02] <amano> H
[08:03] <didrocks> hey Laney
[08:05] <andyrock> good morning
[08:06] <didrocks> bah, gdm branch isn't updated
[08:07] <didrocks> hey andyrock
[08:07] <oSoMoN> hey Laney
[08:09] <Laney> hey didrocks hey andyrock hey oSoMoN
[08:09] <Laney> how's it going? good weekends?
[08:11] <didrocks> Laney: excellent week-end! Spent part of a day to prepare a card game (cutting cards and figuring) before playing it :)
[08:11] <didrocks> rest was uneventful, finishing again GTA 5 and such… :p
[08:11] <didrocks> yourself?
[08:11] <Laney> cutting?
[08:11] <Laney> like some online thing?
[08:12] <Laney> yeah was good, family visit - walks, going to a restaurant, hanging out & stuff
[08:12] <didrocks> no, cutting, like taking paper, scissors…
[08:12] <Laney> right
[08:12] <Laney> but where did the thing you cut out come from?
[08:12] <Laney> or you made it up?
[08:14] <Laney> we have some home made dungeon exploring game here which is fun to play
[08:14] <Laney> xyzzy
[08:14] <didrocks> the game is named "bloc by bloc", which is sold out, and they provide all the pdf and generated assets on github: https://outofordergames.com/blocbybloc/
[08:14] <didrocks> (under CC:BY-NC-SA)
[08:15] <didrocks> oh, and ofc, we have lost against the game :)
[08:16] <Laney> as you should
[08:16] <Laney> have you played ghost stories?
[08:16] <Laney> we've tried that like 10 times and never won
[08:16] <didrocks> never :)
[08:16] <didrocks> we did chain with pandemia in hardcore difficulties mode
[08:16] <didrocks> as usual, everything is going very well
[08:17] <didrocks> and in one turn, you lose :)
[08:17] <didrocks> it's really from "all is fine, to OMG"
[08:19] <didrocks> jibel: hey! btw, today's iso have the glib/settings change
[08:19] <didrocks> would be great to check the ubiquity session, how it looks like :)
[08:20] <jibel> didrocks, okay, i'll have a look
[08:21] <didrocks> thx!
[08:22] <seb128> hey Laney andyrock
[08:23] <Laney> hey seb128
[08:23] <Laney> you doing good?
[08:24] <seb128> yes! you?
[08:25] <Laney> not too bad
[08:25] <Laney> new week, new fun
[08:27] <seb128> indeed
[08:27] <seb128> this week include ff fun
[08:27] <Laney> fff
[08:28] <Laney> f³
[08:30]  * didrocks reboots to test transition update
[08:35] <didrocks> ok, wayland transition works well
[08:35] <didrocks> let's push it :)
[08:36] <didrocks> or… let's write the blog post before maybe
[08:37] <duflu> Hah. Can't report bugs because ubuntu-bug crashes (!?)
[08:40] <jibel> didrocks, latest iso boots and looks all right at first glance. Although there is a visual annoyance, the desktop icons are half behind the dock
[08:41] <jbicha> no objections to dropping gjs/s390x ?
[08:42] <jibel> and there is an issue with network-manager and connectivity detection
[08:42] <jibel> it thinks I'm offline
[08:42] <didrocks> jibel: yeah, it's a bug I reported
[08:43] <didrocks> jibel: even ubiquity install mode is fine?
[08:43] <didrocks> (the icons behind the dock)
[08:43] <didrocks> hum, gnome-boxes crashes here
[08:43] <didrocks> jbicha: hey, mind pushing your gdm changes to the bzr branch?
[08:45] <jbicha> didrocks: try now
[08:47] <Laney> late nite jbicha
[08:47] <didrocks> jbicha: thx!
[08:49] <jbicha> Laney: early morning :|
[08:49]  * Laney cries
[08:50] <duflu> jibel, see bug 1696621
[08:55] <jibel> didrocks, the font is still not the ubuntu font.
[08:55] <didrocks> jibel: the theme is applied though?
[08:56] <jibel> didrocks, yes. we need a new ubiquity for the font?
[08:56] <didrocks> no, it should be theme + font or nothing
[08:56] <didrocks> so, just log the bug, will look after FF
[08:57] <didrocks> jibel: when you say the font
[08:57] <didrocks> is it the top panel
[08:57] <didrocks> ubiquity window itself
[08:57] <didrocks> or both?
[08:57] <jibel> didrocks, the ubiquity window. It's fixed in 17.10.3 but blocked in proposed
[08:58] <didrocks> oh right, this one
[08:58] <didrocks> hum, gnome-boxes fails
[08:58] <didrocks> telling the schema isn't here even if it is…
[09:00] <jibel> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubiquity missing build on all archs: oem-config ...
[09:00]  * Laney was just fixing ubiquity
[09:00] <jibel> thanks
[09:01] <jibel> didrocks, is name resolution working with latest iso?
[09:02] <didrocks> jibel: what do you mean?
[09:04] <jibel> didrocks, hostname resolution doesn't work for me with artful desktop 20170821
[09:04] <didrocks> jibel: I can't test latest iso due to gnome boxes crashing, so don't know
[09:26] <seb128> didrocks, jibel, the font/xsettings plugin not applied is waiting for an ubiquity upload, the fix got commited but something in new perl created issue and infinity/cyphermox said they needed to fix it
[09:26] <seb128> *g*ot applied
[09:26] <seb128> sorry misphrased, but the fix is commited we just didn't get an ubiquity build in artful since
[09:28] <seb128> Laney, do you fix the obvious build issue or the perl problem?
[09:29] <Laney> seb128: just trying to help, I'm running the autopkgtests before upload, but I don't have to do it if that's a problem for you
[09:31] <seb128> Laney, what did I say?
[09:31] <seb128> Laney, I was trying to be helpful
[09:31] <seb128> my upload fails to build because one line needs wrapping
[09:31] <seb128> which is easy to fix
[09:31] <seb128> but there was some other perlish problem on top
[09:31] <seb128> I was just unsure if you were aware of those
[09:31] <seb128> sorry for being too verbose
[09:32]  * seb128 shuts up and let you figure it out
[09:32] <Beret> hmm
[09:32] <seb128> sorry I didn't mean to say there was an problem, I'm not working on it, was just relaying the info I have
[09:32]  * Beret wakes up to see his desktop has grown a dock
[09:33]  * Beret looks for the off button
[09:33] <seb128> Laney, https://irclogs.ubuntu.com/2017/08/04/%23ubuntu-devel.html#t15:23 was what I was mentioning
[09:33] <seb128> anyway
[09:34] <seb128> (console-setup got updated but failed to build as well)
[09:36] <Laney> seb128: ok, I thought that I was dupping your work so I was going to back off
[09:36] <Laney> no big problem
[09:36] <seb128> not with me at least
[09:36] <seb128> but maybe with cyphermox though that discussion was a while ago and things didn't change much so I guess they probably welcome the help ;-)
[09:41] <Beret> are we going to let people set the size of the dock?
[09:44] <seb128> Beret, read https://didrocks.fr/2017/08/18/ubuntu-gnome-shell-in-artful-day-5/ ;-)
[09:45] <seb128> Beret, https://didrocks.fr/images/artful-shell-transition/gnome-control-center-ubuntu-dock-settings.png
[09:50] <Beret> thanks
[09:50] <Beret> it will take me a while to retrain my unity brain
[09:58] <Beret> seb128, what you guys have accomplished is quite impressive, I must say
[10:06] <seb128> Beret, thanks, send the kudos to didrocks who has been leading that work and writing all the details in awesome blog posts
[10:25] <Laney> cyphermox: seb128: thx for the hint, I fixed console-setup now :-)
[10:41] <xnox> Laney, \o/
[10:42] <xnox> means i can fix s390x active console bits, and drop upstart jobs.
[10:43] <Laney> nice
[10:44] <seb128> Laney, thanks!
[10:48] <oSoMoN> seb128, have you seen my e-mail about new LO deps that are in universe but once were in main?
[10:49] <seb128> oSoMoN, yes, I need to reply to that, but it's fine to re-promote things
[10:49] <seb128> no need of a new MIR
[10:49] <seb128> Laney, failed to build :-(
[10:50] <xnox> oSoMoN, hmmm that was intentional.
[10:51] <xnox> oSoMoN, due to archive reorg one can build-depend on universe, as long as that doesn't generate depends; or the packages that have new depends end up in universe.
[10:51] <xnox> what packages specifically are you asking about?
[10:53] <seb128> there is that as well
[10:59] <oSoMoN> xnox, yeah, I guessed the demotions were just maintenance cleanups, not due to actual package QA/security (although of course that needs to be confirmed)
[10:59] <oSoMoN> xnox, the source packages are lp-solve, suitesparse and liborcus
[11:00] <xnox> oSoMoN, no, as in. we implemented archive reorg in foundations to explicitely drop a whole bunch of things out of main. especially since libreoffice did pull in things that only were used by it optionally.
[11:01] <xnox> oSoMoN, yeah i don't think we want any of these back in main. what do you need these for?
[11:02] <xnox> you can build-depend on them, as long as binary packages generated with depends on e.g. liborcus-0.12-0 are split shipped into universe.
[11:02] <xnox> i see no reverse depends on liborcus at all in ubuntu
[11:03] <oSoMoN> xnox, not in 5.3, but it's a depends of libreoffice-calc in 5.4
[11:03] <xnox> ah
[11:03] <xnox> sigh
[11:04] <xnox> then we are cornered and have to re-promote those back in. But the proper way is to first upload libreoffice 5.4 that does that.
[11:04]  * xnox checks that
[11:04] <xnox> oSoMoN, yeah, upload first such that new depends are gained (universe is enabled by default, thus the package will build) and then AAs can re-promote, hopefully based on the old MIR
[11:07] <oSoMoN> xnox, ack, thanks
[11:15] <seb128> re
[11:15] <seb128> oSoMoN, sorry, I changed location and didn't see if you had more comments
[11:17] <oSoMoN> seb128, http://paste.ubuntu.com/25361988/
[11:20] <seb128> oSoMoN, thanks
[11:20] <Laney> seb128: WHAT
[11:21] <seb128> Laney, sorry :-(
[11:21] <Laney> it worked for me, how can this be
[11:21] <Laney> also what's up with this wifi
[11:21] <seb128> oSoMoN, that discussion is accurate, anyway I'm having another look to libreoffice today
[11:22] <Laney> Status: successful
[11:22] <Laney> Version: 1.142ubuntu7
[11:23] <oSoMoN> seb128, thanks
[11:24] <seb128> np, thanks for doing the update!
[11:55] <xnox> Laney, racy / parallel build inside debian/rules did not create the desired target dir?!
[11:56] <Laney> does look like a race
[11:56]  * Laney retried
[12:13] <Laney> win ;-)
[12:18] <xnox> hahaha. Fix the race, not retry =)
[12:18] <xnox> Laney, i guess you want _me_ to fix the race with my upload *har* *har*
[12:19] <Laney> sure
[12:19] <Laney> it wouldu be nice if you could wait for it to migrate
[12:20] <xnox> ack
[12:31] <Laney> xnox: I would bet that race is fixed in master btw - there are some commits that could be related
[12:31] <Laney> do you know why we're behind? hard merge?
[12:31] <xnox> Laney, cyphermox was working on a merge of console-setup to fix all the things
[12:31] <Laney> nod
[12:31] <xnox> Laney, and yes, very hard merge.
[12:33] <Laney> may the buildds smile upon you
[12:45] <casey> Hello, I recently stumbled upon this email thread regarding gnome music and photos and tracker (https://lists.ubuntu.com/archives/ubuntu-desktop/2017-August/005095.html)
[12:45] <casey> Gnome-Shell's search by default relies on tracker as its primary backend to surface files
[12:46] <casey> and from my own usage, the search is fast but noticeably less reliable than Unity's file search lens (which uses locate)
[12:47] <casey> some files will be indexed but cannot be found through tracker's search interface (e.g https://bugzilla.gnome.org/show_bug.cgi?id=776395)
[12:48] <jbicha> I replied to seb's recent nautilus/tracker question a bit earlier on LP: #1711241
[12:50] <jbicha> xnox: hi, UOA is already unsupported in Unity/artful LP: #1695928
[12:50] <casey> thanks. in that case, however, should nautilus's gnome-shell search provider be patched to search recursively?
[12:50] <casey> presently it will only look for files in the top level home directory
[12:51] <casey> (https://bugzilla.gnome.org/show_bug.cgi?id=766174)
[12:51] <casey> I'm referring to the "Simple search engine" which just crawls the filesystem
[12:51] <jbicha> casey: nautilus searches recursively by default for local files
[12:52] <jbicha> see Files>Preferences>Search & Preview>Search in subfolders
[12:52] <casey> jbicha: yes, if you search from a nautilus window. but from recent testing it seems that searches from the gnome-shell overview are not configured to be recursive
[12:52] <casey> see for example how Carlos's temporary patch had to explicitly set recursivity for gnome-shell searches
[12:53] <casey> i recently tested this in gdb
[12:53] <casey> at least for the nautilus that ships with Ubuntu 17.04 (maybe things have changed since then?)
[13:01] <casey> jbicha:anyway, should I open a bug on Launchpad about this?
[13:12] <xnox> jbicha, yes, i stand correct.
[13:19] <Laney> xnox: all yours
[13:34] <didrocks> jbicha: ubuntu dock extension compatile with 2.26 uploaded
[13:38] <jbicha> thanks
[13:43] <jbicha> I've done step 1 of the gjs transition https://lists.ubuntu.com/archives/ubuntu-desktop/2017-August/005123.html
[13:43] <didrocks> thanks to you! :)
[13:43] <jbicha> I'll need AA help for the rest of the steps
[13:43] <didrocks> are they built already?
[13:43] <didrocks> just poke me to get a review
[13:43] <jbicha> yes
[13:44] <didrocks> after z, will we have aa? :)
[13:46] <didrocks> jbicha: nothing blocking, but as we know we'll never align, maybe override in the future W: libgjs0g: package-name-doesnt-match-sonames libgjs0
[13:47] <didrocks> good, replaces for the typelib and libs are there, acking
[13:48] <didrocks> jbicha: NEWed in main
[13:51] <didrocks> jbicha: mozjs52 promoted
[13:52] <Laney> |o|
[13:52] <didrocks> jbicha: on gjs/s390x I'm not going to take a decision
[13:52] <Laney> <o/
[13:53] <xnox> didrocks, gjs & desktop are out of scope for the s390x port
[13:53] <didrocks> xnox: so DELETE DELETE DELETE? :-)

[13:54] <jbicha> we skip the tests on s390x so there's a good chance s390x was already broken for gnome-shell
[13:54] <xnox> didrocks, YOLO
[13:54] <jbicha> there's several rdepends, do you need me to try to come up with a list?
[13:56] <didrocks> jbicha: yes please :)
[13:56] <didrocks> like, log that to a bug report
[13:56] <didrocks> I'll quote xnox and DONE :)
[13:56] <jbicha> ok
[13:58] <jbicha> LP suggested LP: #696812 which I guess would be a lot less trouble ;)
[14:02] <didrocks> jbicha: let's close it… Oh wait :)
[14:08] <jbicha> LP: #1712083
[14:09] <didrocks> jbicha: I read well that you listed all binary packages?
[14:09] <jbicha> I did not check all the gnome-shell extensions (many are arch:all)
[14:09] <didrocks> (apart from gjs, which seems to be only the source package that you listed only gjs)
[14:12] <jbicha> I added a few more
[14:15]  * didrocks flushes
[14:23] <seb128> Laney, jamesh, jbicha, do you know if anyone is working on backporting the patch for gnome bug #785117 to artful?
[14:25] <Laney> Nobody that I know about
[14:26] <Laney> last I looked the UI changes were not yet reviewed
[14:26] <Laney> but this could happen first of course
[14:26] <jbicha> seb128: I started on it but it will probably take me a few more days
[14:27] <seb128> jbicha, is that because it's complex?
[14:27] <seb128> can you maybe see if jamesh can help you to get it done tomorrow?
[14:27] <seb128> jamesh, ^
[14:28] <seb128> Laney, right, we need the API first so we can as well land that and move closer from the solution
[14:28] <seb128> it's getting tight with ff
[14:30] <Laney> the upstream review of the control-center patch should be chased up
[14:32] <seb128> jbicha did that
[14:32] <jbicha> my initial attempt at backporting wasn't good enough for the g-control-center patches to build
[14:32] <seb128> I think it would make sense for jamesh to help you with that
[14:32] <seb128> jamesh, ^ if you have time during your day that would be nice
[14:33] <jbicha> honestly, I doubt the g-c-c maintainers are that interested in looking at the patches before Thursday since it seems too late for 3.26 and the 3.25.91 milestone is this week
[14:34] <seb128> right
[14:34] <seb128> backporting unofficial apis would have not been nice
[14:34] <seb128> but the g-c-c change as a distro patch shouldn't be too much of an issue
[14:35] <Laney> k, fine, do what you want
[14:35]  * Laney really goes to lunch
[14:36] <seb128> Laney, sorry I didn't mean to discard your comment, agree that getting upstream review would be best but if that doesn't happen what you would prefer? not include the feature or distro patch it?
[14:36] <seb128> Laney, enjoy lunch!
[14:36] <Laney> I think you could ask for some comment
[14:36] <Laney> "no we will never have a switch in the control centre" would be an interesting piece of feedback
[14:37] <seb128> right
[14:37] <seb128> let's try a bit more
[14:37] <seb128> but as said jbicha commented a few days ago saying we want to include it and would welcome comments
[14:37] <Laney> but I don't suggest dropping the feature if it's not merged by Thursday
[14:37] <seb128> g-c-c maintainers seems too busy/on holidays/mia at the moment
[14:38] <seb128> I opened a bunch of bugs since GUADEC and got no resppnses
[14:38] <Laney> IRC might be better
[14:38] <Laney> sometimes that gets a better response out of the ubuntu desktop team too :-)
[14:39] <seb128> right
[14:39] <seb128> jbicha, want to try pinging them on IRC?
[14:47] <Trevinho> seb128, didrocks I think here's fine, no?
[14:47] <didrocks> yep !
[14:47] <seb128> yes, please
[14:48] <seb128> Trevinho, I read the log from friday, sorry for the misunderstanding
[14:48] <seb128> Trevinho, you didn't ask me for more details or such so I though you understood the goal/requirement
[14:48] <seb128> seems I should have been more detailed in what I asked
[14:49] <Trevinho> yeah, sorry seb128 .... I also didn't get "top icons" as the extension
[14:49] <Trevinho> that's why the misunderstanding :)
[14:49] <didrocks> so, let's sum up?
[14:49] <didrocks> there are 2 extensions
[14:49] <didrocks> one supporting systray
[14:49] <Trevinho> yeah
[14:49] <didrocks> and the other supporting indicators
[14:49] <Trevinho> didrocks: no well systray is supported by GS in general
[14:49] <didrocks> only one has a maintainer, correct?
[14:49] <didrocks> Trevinho: not with 3.26
[14:49] <seb128> Trevinho, that has been removed from 3.26
[14:49] <Trevinho> didrocks: it's just that it puts icons close to the launcher
[14:49] <Trevinho> ok, fair enough..
[14:50] <seb128> and the issue was that this hidden in the corner support was not discoverable
[14:50] <Trevinho> so I've not been followed upstream in this, what's the preferred mode for 3rd party to put icons?
[14:50] <Trevinho> extensions?
[14:50] <Trevinho> yeah...
[14:50] <seb128> "don't"
[14:50] <Trevinho> ok... so I think we can put - in our side - appindicators back to the glory
[14:50] <seb128> they want to force upstreams to come up with another solution/UI
[14:50] <Trevinho> since electorn supports it, and many apps rely on that
[14:51] <seb128> does it give us dropbox and skype?
[14:51] <Trevinho> nope
[14:51] <Trevinho> well
[14:51] <didrocks> ok, so appindicators will bring us much of what we want, apart from the 2 that seb128 notes
[14:51] <Trevinho> skype *might*
[14:51] <Trevinho> but you need libappindicator1 and XDG_CURRENT_DESKTOP=Unity, whichis not really the case
[14:51] <seb128> let's step back and discuss solutions after
[14:52] <Trevinho> anyway it's possible to patch libchromium content for future in order to get it to use libappindicator in such cases
[14:52] <didrocks> is that something in the repo or they will need to do another release?
[14:52] <seb128> libappindicator fallbacks to display a systray if there is no indicator renderer right?
[14:52] <Trevinho> yes
[14:53] <seb128> are indicator giving us a better user experience than systray?
[14:53] <Trevinho> seb128: but in case of things such as electron, they only use libappindicator in unity
[14:53] <seb128> brb, door bell
[14:53] <Trevinho> seb128: I'd say yes
[14:53] <Trevinho> well, I'd love to put them alltogether in a way that only apps tha the user wants or that needs attention are always shown in the panel, while the others could be hidden in vertical mode...
[14:53] <Trevinho> maybe
[14:54] <Trevinho> but this is again one sep further
[14:54] <Trevinho> step*
[14:54] <didrocks> how would you know apps that the user wants or needs attention?
[14:54] <Trevinho> appindicator has that mode
[14:54] <Trevinho> you can define the "attention" mode as when you get mesages in telegram, it's marked red for example
[14:55] <didrocks> so, if I develop an app that I want to always be seen, I can abuse easily :)
[14:55] <didrocks> but ok
[14:55] <didrocks> so, why not as a first step…
[14:55] <didrocks> take the appindicator extension, fully
[14:56] <Trevinho> didrocks: that's what I'm doing
[14:56] <didrocks> and systray support, filtering skype/dropbox
[14:56] <didrocks> and only those?
[14:56] <Trevinho> well, I want to add some changes in order to respect more theming, but that's all
[14:56] <didrocks> (as we got the whitelist at first in unity)
[14:56] <jdstrand> didrocks: hi! I'm running the new ubuntu-session and it seems to be working really well
[14:56] <didrocks> the appindicator extension is actively maintained?
[14:56] <Trevinho> I would rather filter any electron-based apps hoestly
[14:56] <xnox> didrocks, did you move systray to the top bar, where it belongs? instead of the non-disoverable pop-up
[14:56] <xnox> didrocks, there is also virt-manager that appears in the bottom tray instead of top indicators
[14:57] <Trevinho> xnox: that's what we're doing anyway
[14:57] <didrocks> jdstrand: excellent, thanks for the feedback! (I hope there is no "but…" right? ;))
[14:57] <didrocks> xnox: easier, GNOME 3.26 removed it completely
[14:57] <didrocks> xnox: see my last blog post :p
[14:57] <Trevinho> xnox: virt-manager? has it appindincator support?
[14:57] <jdstrand> didrocks: I particularly like how Desktop is showing up again (I missed that) and the hot corner being disabled (gosh that was annoying)
[14:57] <jdstrand> didrocks: not a 'but', a question
[14:57] <didrocks> \o/
[14:57] <xnox> Trevinho, i do not know what it is, but it is something
[14:57] <didrocks> jdstrand: the hot corner has a 50-50 love/hate feedback, thanks for coming on my side ;)
[14:58] <xnox> hot corner is pile of doom
[14:58] <didrocks> and it's a +2 \o/
[14:58] <didrocks> ;)
[14:58] <jdstrand> didrocks: wrt hot corner> between the meta key and the Activities, how many different ways does one need to see the same data?
[14:58]  * Trevinho hates hot corner
[14:59] <Trevinho> anyway let's keep discussion back to notification icons for now
[14:59] <didrocks> jdstrand: a LOT apparently :)
[14:59] <Trevinho> or indicators
[14:59] <didrocks> yeah
[14:59] <didrocks> so
[14:59]  * xnox is yet to understand the difference between activities and meta key.... i thought meta key was actifinities....
[14:59] <jdstrand> didrocks: anyway, my question is about mountpoints showing up on the desktop. in unity7 the launcher would show them, but there was a way to hide them. is there something similar for gnome-shell?
[15:00] <Trevinho> at this point systray in 3.26 not being supported means... that... probably even top icons extension isn't working anyway
[15:00] <didrocks> jdstrand: yeah, it's the gsettings key for now if you want to hide them, no UI (yet, should we? unsure)
[15:00] <Trevinho> and we need something more
[15:00] <didrocks> Trevinho: uno momento, back to you then :)
[15:00] <Trevinho> un :)
[15:00] <jdstrand> didrocks: as to exposing via gui-- it was a right click in the laucnher if you recall. that was convenient (but bringing it back was not)
[15:01] <didrocks> jdstrand: $ gsettings set org.gnome.nautilus.desktop volumes-visible false
[15:01] <didrocks> ah
[15:01] <didrocks> hum, good point
[15:01] <jdstrand> didrocks: so, in my case one of the mountpoints is '/'. it isn't detecting full disk encryption right it seems
[15:01] <didrocks> mind log a bug for me to track?
[15:01] <didrocks> jdstrand: at least so that we ack/nack?
[15:01] <didrocks> oh
[15:01] <didrocks> yeah, quite annoying to your eyes :)
[15:03] <jdstrand> didrocks: yes, I can file that
[15:03] <didrocks> Trevinho: yeah, something to test about topicon not working, jbicha, do you know?
[15:03] <seb128> Trevinho, what are skype and dropbox using? I though they would both use libappindicator
[15:03] <didrocks> jdstrand: thanks! and meanwhile, the gsettings key ^ is here for you :)
[15:03] <Trevinho> seb128: dropbox does
[15:03] <didrocks> but skype check for "unity", correct?
[15:04] <Trevinho> seb128: skype being an elctron app, does it only if XDG_CURRENT_DESKTOP == Unity
[15:04] <xnox> skype is dead
[15:04] <seb128> xnox, we are speaking about the new electron version, how is that dead?
[15:04] <Trevinho> might be... but, still...
[15:04] <xnox> oh, their electron app also integrates indicators? ah interesting
[15:04] <Trevinho> *any* electron app integrates with indicator
[15:04] <seb128> Trevinho, can we get them to fix it?
[15:04] <didrocks> Trevinho: where is this check? XDG_CURRENT_DESKTOP == Unity, not in a shared lib, correct?
[15:04] <Trevinho> but onyl in unity
[15:04] <jdstrand> didrocks: what should I file it against?
[15:05] <Trevinho> seb128: it's a quite annoying thing as we need libchromium content to fix it
[15:05] <didrocks> jdstrand: g-c-c I would say
[15:05] <seb128> Trevinho, so basically we can support indicators only and fix electron/libchromium and get what we want?
[15:05] <Trevinho> i was telling oSoMoN I can prepare something like a patch, to get that, but then it needs to goes into the chrome release pipe and then to brigthray and electron
[15:05] <Trevinho> and they need to rebuild it
[15:05]  * Trevinho sometimes hates to give so much control in hands of upstreams :)
[15:06] <seb128> haha
[15:06] <didrocks> do we know how typically long this is for Skype?
[15:06] <Trevinho> seb128: here's where the "magic" happens https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/ui/libgtkui/app_indicator_icon.cc#98
[15:06] <didrocks> as it seems to be our only famous blocker there?
[15:07] <didrocks> I don't even understands how this can work today
[15:07] <seb128> k, so I think we understand the needs
[15:07] <didrocks> as it's a list
[15:07] <seb128> Trevinho, what is your recommended solution, for this cycle and for the futur?
[15:08] <seb128> didrocks, it's not since zesty because of the list thing, flexiondotorg mentioned it and asked if we could revert unity using a list since there is only one unity version left
[15:08] <Trevinho> I didn't test topicons with 3.26, as I wasn't aware they were getting rid of the systray... So it works there, but if the code underneath has been deleted we have to reimplement in order to have systray
[15:08] <Trevinho> so...
[15:08] <didrocks> seb128: ah, so not a regression per say, this gives us time
[15:09] <didrocks> hum, I would say, let's not care about sytray thus
[15:09] <Trevinho> so, if we don't want to reimplement it *just for skype*... We can just avoid to do that
[15:09] <didrocks> and just appindicator extension on my side + fixing the thing in chromium and getting the Skype team, via our contacts, to rebuild against it
[15:09] <didrocks> yeah
[15:10] <didrocks> even if not working on 17.10, right off the shelf for Skype, it's already the case as you told since zesty
[15:10] <Trevinho> I was thinking if we can *hack* things a bit inside libappindicator making electorn apps to work anyway...
[15:10] <Trevinho> but I really thing that playing inside there with `setenv` would be really, really, really, really mad :-D
[15:10] <didrocks> electron apps will work once you get the chromium fix in?
[15:11] <Trevinho> nope
[15:11] <Trevinho> they need to rebuild
[15:11] <didrocks> yeah
[15:11] <didrocks> but once rebuilt
[15:11] <didrocks> ?
[15:11] <Trevinho> And unfortuntealy they need chrome ot release that part
[15:11] <Trevinho> I guess
[15:11] <seb128> Trevinho, did you see my previous question?
[15:11] <seb128> what do you recommend doing
[15:11] <seb128> this cycle
[15:11] <seb128> and later?
[15:11] <Trevinho> since while you can rebuild your app with a specific electron / brighray version, you can't use a more recent of libchromiun content AFAK
[15:11] <Trevinho> AFAIK
[15:12] <Trevinho> seb128: yes... I wrote it. What I was doing was supporting *both* extensions in one (for now https://github.com/3v1n0/gnome-shell-ubuntu-appindicators), but if we won't hav e the upstream tray this won't work anyway I guess
[15:13] <Trevinho> I could get the tray back in maybe, and then filter skype but I need to check how long that will be.
[15:13] <seb128> Trevinho, why do you think we need the tray?
[15:14] <Trevinho> if there wasn't this my preferred thing was to support both things, without black/white listing much (waiting for electron to fix)
[15:14] <seb128> I like the "hack libappindicator to change the env" better if that can be done :p
[15:14] <didrocks> same, less code :)
[15:14] <Trevinho> seb128: I can give a try... not sure what it will cause
[15:14] <seb128> Trevinho, what's the problem you see if we decide to do appindicator only? (out of getting electron apps on a fixing codebase, which is just getting fix to land in the right place)
[15:14] <Trevinho> Well I'd do that only if it's an electon app anyway
[15:16] <Trevinho> not sure it's possible though, as it depends when they do getenv first (and I think it's done just once)...
[15:16] <Trevinho> Anyway, seb128 the only problem I see is that we would miss some apps
[15:16] <Trevinho> so, other than electron for me, systray can be dead.
[15:17] <seb128> right, the code you pointed would return before opening the lib
[15:17] <seb128> Trevinho, so there wouldn't be an issue out of needing to get libchromium code updated and the change to land in apps we care about?
[15:18] <Trevinho> yeah...
[15:18] <seb128> that seems fair enough to me?
[15:18] <seb128> systray is from the past, we already tried to deprecate it in unity7
[15:18] <seb128> GNOME removed it
[15:18] <Trevinho> the problem here is that we don't have control on what is happening for those apps
[15:18] <seb128> I would vote for indicator only
[15:19] <Trevinho> it's also true that we're giving a way
[15:19] <didrocks> same +1
[15:19] <seb128> well we have contact with the teams that work on that
[15:19] <seb128> let's start with indicator only
[15:19] <didrocks> exactly
[15:19] <seb128> and try to use our contacts to get the apps fixed
[15:19] <seb128> Trevinho, how does that sound to you?
[15:19] <Trevinho> seb128: agreedo
[15:20] <didrocks> so, what do we need to do in the appindicator extension?
[15:20] <seb128> k, that's the next question
[15:20] <seb128> is there an extension we can use/base on for indicators?
[15:20] <seb128> and what is it upstream status?
[15:21] <jdstrand> didrocks: ok, after looking into it, it wasn't root, it was two bind mounts. here is the bug https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1712100
[15:21] <jdstrand> s#root#/#
[15:21] <Trevinho> there are some missing functionalities (scrolling, middle clicking) which I want to check
[15:21] <Trevinho> I personally have an issue with dropbox that I was about to debug (no menu showing)
[15:21] <Trevinho> there are some missing functionalities (scrolling, middle clicking) which I want to check
[15:21] <Trevinho> for example... the same hover / press effects.
[15:22] <Trevinho> Argh... my messages are screwed... Got a disconnesion :)
[15:22] <Trevinho> disconnection*
[15:22] <didrocks> jdstrand: ah,the bug is different if you only want filtering thus, reaffecting to nautilus
[15:22] <jdstrand> that's cool
[15:22] <Trevinho> seb128: the extension is there and I've been hacking a bit in these days
[15:22] <didrocks> Trevinho: only things to add, nothing to remove?
[15:23] <jbicha> for 3.26 compatibility: https://github.com/phocean/TopIcons-plus/pull/78
[15:23] <Trevinho> didrocks: for this no... the topicons plus one had some features we didn't care and that I was removing
[15:23] <jdstrand> didrocks: I think volumes visible makes a lot of sense for removable storage since the default gnome-shell experience (afaics) requires you too open nautilus yourself and drill down when the device is hotplugged
[15:24] <didrocks> Trevinho: ok, we'll still need to light for for the update issue
[15:24] <jbicha> we intend to go with gnome-shell 3.26 for artful, right?
[15:24] <seb128> jbicha, correct
[15:24] <didrocks> jbicha: correct
[15:24] <didrocks> Trevinho: ok, we'll still need to light fork* for the update issue
[15:24] <didrocks> Trevinho: but apart from the extension ID
[15:24] <jbicha> ok, after the gjs transition, I'd like to do the gnome-settings-daemon/gnome-session transition
[15:24] <didrocks> nothing else is needed, just improving it
[15:24] <didrocks> Trevinho: that's correct? ^
[15:24] <seb128> jbicha, what is to transition in g-s-d and gnome-session?
[15:24] <Trevinho> didrocks: yeah, so I wanted to do since the first moment
[15:25] <didrocks> Trevinho: ok, so, we need to contact upstream
[15:25] <jdstrand> didrocks: Another idea might be to have:
[15:25] <jdstrand> $ gsettings set org.gnome.nautilus.desktop only-removable-volumes-visible true
[15:25] <didrocks> to tell them about our plan
[15:25] <Trevinho> ah... one more thing
[15:25] <jbicha> g-s-d drops the xrandr and orientation plugins so we need to upload gnome-session and budgie-desktop at the same time
[15:25] <jdstrand> didrocks: (added idea to the bug)
[15:25] <didrocks> jdstrand: and that works well for you?
[15:26] <jdstrand> didrocks: that isn't a thing. I was saying if it was a thing, that would probably suit me fine
[15:26] <didrocks> Trevinho: apple-conference-style, "one more thing" :
[15:26] <jbicha> the orientation and xrandr features will be in mutter 3.25 (which is why I was confirming that we will follow with gnome-shell)
[15:26] <didrocks> jdstrand: ah ok ;)
[15:26] <Trevinho> Qt5... I've to check some cases
[15:26] <seb128> jbicha, what has gnome-session to do with that?
[15:26] <Trevinho> since they support app-indicators, but there were some special things on XDG_CURRENT_DESKTOP = Unity again
[15:27] <didrocks> Trevinho: but basically, all is about adding more support to the extension
[15:27] <didrocks> which is good news for upstream
[15:27] <Trevinho> things that at this point we might fix in different way
[15:27] <didrocks> do you want me to email him/her and CC you tomorrow?
[15:27] <Trevinho> didrocks: yeah sure, but also qt could need some changes
[15:27] <didrocks> to lay out what and why we want to do it
[15:27] <didrocks> Trevinho: yeah, but doesn't need to be in before shipping this
[15:28] <Trevinho> didrocks: nope, sure...
[15:28] <Trevinho> didrocks: I can also get in touch, as you wish
[15:28] <seb128> didrocks, Trevinho, so let's start by adding libappindicator support and see if that's enough? if we feel like users are still unhappy/we can't get apps fixed as we want we might discuss a plan B systray temporary thing then?
[15:28] <jdstrand> didrocks: one more question-- how do I add custom launchers to the dock? (this applies to gnome-session as well as ubuntu-session)
[15:28] <didrocks> seb128: +1
[15:28] <jbicha> seb128: gnome-session (and ubuntu-session) lists those plugins as RequiredComponents so log in won't work if gnome-session isn't updated before or at the same time as g-s-d
[15:28] <seb128> jbicha, ah ok, easy transition then
[15:28] <jdstrand> it was super-convoluted with unity7. I haven't been able to find out how to do it in gnome-shell
[15:29] <seb128> jbicha, +1 from me
[15:29] <didrocks> Trevinho: I think we might want to upload and add to the session ASAP
[15:29] <seb128> jdstrand, you can dnd icons from the app grid to the favorites
[15:29] <didrocks> Trevinho: do you have all arguments on why we want to light fork?
[15:29] <Trevinho> seb128: fair enough
[15:29] <seb128> jdstrand, I expect than having a .desktop in .local/share/applications would work to get it listed then you can dnd
[15:30] <jdstrand> seb128: no, custom desktop files. or rephrased, how do I get a custom luancher into the app grid?
[15:30] <Trevinho> didrocks: well, since you're all ready for that you can proceed
[15:30] <jdstrand> ok, let me try that
[15:30] <jdstrand> that was definitely not enough for unity7
[15:30] <seb128> jdstrand, create a .desktop in .local/share/applications with the name/comment/exec you want
[15:30] <seb128> weird
[15:30] <didrocks> Trevinho: so, should I start a branch in the ubuntu org meanwhile and add you there?
[15:30] <seb128> it worked for me in unity7
[15:30] <Trevinho> didrocks: ack
[15:30] <Laney> that works in gnome-shell
[15:30] <didrocks> Trevinho: let me change the description/ID as well, as I did
[15:30]  * Laney has Laney Terminal
[15:30] <didrocks> Trevinho: we *may* do it by FF ;)
[15:31] <didrocks> then your other changes are just… "fixes"
[15:31] <seb128> Laney, that was working in unity as well no?
[15:31] <seb128> it's all the same standard using xdg dirs
[15:31] <Laney> I would expect so, but I don't actually explicitly remember doing it there
[15:31] <Laney> I don't know a reason why it wouldn't
[15:32] <didrocks> Trevinho: just to agree, we are discussing about https://extensions.gnome.org/extension/615/appindicator-support/, correct?
[15:32] <seb128> I had one which was working, I don't think I had anything special done
[15:33] <seb128> Trevinho, let didrocks write the email, he did one for dash to dock already
[15:33] <seb128> Trevinho, so you can focus on the code, ff is this week
[15:35] <Trevinho> ok
[15:37] <seb128> Trevinho, didrocks thanks
[15:37] <didrocks> thanks guys!
[15:39] <jdstrand> seb128: so, one of these launchers is for a browser snap, which reminded me: is there a bug for snaps not showing up in the app grid and also not being able to 'add to favorites' when launched from the command line (eg, 'gnome-clocks'
[15:39] <jdstrand> )
[15:40] <jdstrand> seb128: I thought there was, but I'm having trouble finding it...
[15:43] <jbicha> ugh, gnome-shell test failure on armhf (also not a release arch for Firefox 54), I'm thinking of just ignoring it…
[15:45] <k_alam> hi, url-dispatcher code moving out ui-toolkit...can anyone confirm? So url-diapatcher stays in main ? If user installs toolkit using Yunit/ubport ppa and url-dispatcher from main how will this work?
[15:47] <xnox> k_alam, ideally i want url-dispatcher to be gone from ubuntu and instead be maintained by these new ppas/forks.
[15:47] <xnox> k_alam, but we are not there yet.
[15:47] <xnox> k_alam, and there are multiple conflicting forks of indicators it seems
[15:50] <k_alam> xnox: Alright....url-dispatcher can be removed from...but I don't agree with moving the code out from ui-toolkit.....ideal solution would be patch indicators one by one......on desktop indicators doesn't need to depend on dispatcher any way.
[15:52] <seb128> jdstrand, https://forum.snapcraft.io/t/xdg-data-dirs-under-gnome-wayland/1553 https://bugs.launchpad.net/snappy/+bug/1681547
[15:52] <xnox> k_alam, i see three sets of indicators: what used to be in ubuntu, what is in yunit/ubports, what is in Arctica
[15:52] <seb128> jdstrand, if you could help getting a review of the change that would be nice
[15:52] <seb128> jdstrand, I've been using the forum and doing regular nagging without success :-/
[15:53] <xnox> k_alam, ubuntu's code has, in single code base, codes for - touch greeter, desktop greeter, unity7 desktop, unity8 desktop, lockscreen touch, lockscreen desktop, ubiquity installer
[15:53] <xnox> k_alam, ubports/yunit i'm guess only cares about the touch profiles
[15:53] <xnox> k_alam, arctica cares about classic desktop and more importantly non-unity* desktops
[15:53] <seb128> jdstrand, unsure about the command line thing, why don't you start gnome-clock from the dash? (or do you use a snap for it and hit that bug?
[15:54] <xnox> thus imho all of these should work and rework codebases to be non-concflicting
[15:54] <xnox> since in ubuntu, i can see e.g. xubuntu/mate using arctica indicators; and for example yunit/ubports one day becoming an ubuntu flavor with their evolved indicators.
[15:55] <xnox> k_alam, can you see some other way, in which indicators evolve to be maintainable and usable for all the currently active targets?
[15:55] <Beret> so
[15:55] <Beret> I have notification that's "stuck" on the screen
[15:55] <Beret> it's not going away and I can't dismiss it
[15:55] <Beret> it's a google calendar notification fwiw
[15:55] <Beret> anyone seen that?
[15:59] <jdstrand> seb128: that's what I'm saying. I have the gnome-clocks snap installed. I do not have the deb installed. 'gnome-clocks' doesn't show up in the app grid, therefore, I cannot add to favorites
[15:59] <seb128> Beret, no "x" in the corner?
[15:59] <seb128> jdstrand, right, we need to get that snapd bug fixed :-/
[15:59] <jdstrand> seb128: btw, I confirmed that ~/.local/share/applications is enough to have it show up in the grid
[15:59] <seb128> great!
[15:59] <jdstrand> so that's nice
[15:59] <jdstrand> :)
[15:59] <seb128> jdstrand, can you do the second snapd review for that bug? ;-)
[16:00] <jdstrand> seb128: what bug? what PR? /me was trying to find it
[16:03] <seb128> jdstrand, the one I just gave you at :52
[16:03] <jdstrand> oh, I missed that
[16:03] <seb128> :-)
[16:04] <Laney> does snapd try to avoid depending on systemd?
[16:05]  * Laney sees the comment about the environment generator in there
[16:05] <k_alam> xnox: Yunit cares about desktop........at the moment I don't know how to combine efforts for indicators (other than helping libappindicator to evolve)....but in future, if unity drop indicators Yunit can/should start using artica instead...maintaining multiple forks of same code doesn't make sense.
[16:05] <seb128> Laney, not that I know, they tried to avoid depending on it being pid1 to work on trusty though iirc
[16:07] <Laney> nod
[16:07]  * Laney tries that quickly
[16:08] <Beret> seb128, yeah, the x was unresponsive - restarting chrome sorted it, I'll consider it a chrome bug
[16:09] <seb128> Beret, k
[16:09] <seb128> Beret, is chrome using the GNOME notifications or its owns?
[16:11] <Beret> seb128, its own
[16:11] <Beret> they're in the lower right instead of top middle
[16:22] <jdstrand> seb128: review. just need a small change
[16:22] <jdstrand> reviewed*
[16:28] <seb128> jdstrand, thanks
[16:33] <Laney> bah my vm got broken somehow
[16:33] <Laney> back later on
[16:55] <k_alam> xnox: at the moment yunit and ubport using exactly same code that canonical wrote (+ some minor patches).....source packages have  same name and as per IPRRight's policy they can continue using "ubuntu-" prefix in all packages (though I could be wrong here)....which means we must use same code in ubuntu and debian at-least for the toolkit.... I will raise the issue in their respective mailing list...let's see their response. Thanks.
[17:11] <gQuigs> would someone mind uploading https://bugs.launchpad.net/ubuntu/+source/ubuntu-restricted-addons/+bug/1709166 before feature freeze, please?
[17:30] <Trevinho> muktupavels: hey, as per the discussion above, about Status Notifier (indicators and g-s) it could be a good time now to implement the specification you were proposing
[17:30] <Trevinho> muktupavels: having ubuntu gs
[17:30] <Trevinho> + mate would be a good start
[17:30] <Trevinho> and KDE could join us too I guess
[17:31] <Trevinho> at low level side we could just update libappindicator and glib-status-icon so that the change can be transparent for most of our "customers"
[17:44] <muktupavels> Trevinho: I don't rememeber what I proposed...
[17:46] <Trevinho> muktupavels: eheh, I know, long time ago... https://lists.freedesktop.org/archives/xdg/2015-December/013620.html
[17:46] <Trevinho> but you posted something more recently about that topic
[17:53] <muktupavels> Trevinho: at this point I would probably want that status notifier items are just icon + menu...
[17:53] <muktupavels> x and y arguments should be removed because it does not work in wayland.
[17:57] <muktupavels> Trevinho: also there should be way to request icon size. IconPixmap property should be removed.
[17:57] <Trevinho> yeah agree
[17:57] <muktupavels> Then I also was thinking that there should be way to tell if host prefers symbolic or non-symbolic icons.
[17:57] <Trevinho> muktupavels: although Qt by default uses that... It doesn't in unity only
[17:58] <muktupavels> Item registers with host, then host just requests icon at size it needs.
[17:58] <Trevinho> yeah, indeed...
[18:00] <muktupavels> Trevinho: do you plan to work on that?
[18:01] <Trevinho> muktupavels:  I would like to, not sure how much we want invest on it, but to me it looks like a good moment (seb128?)
[18:01] <Trevinho> muktupavels: since you did some paperwork already, it would be nice if we could integrate that in a .xml interface and start using it
[18:04] <Trevinho> muktupavels: an important element we missed in activation has always been the timestamp too
[18:04] <muktupavels> Trevinho: it needs updates, I dont remember if I have something updated, but I would want that I can request icons at size I need and also want option to request symbolic icons.
[18:06] <muktupavels> timestamp for what?
[18:06] <Trevinho> muktupavels: focus stealing prevention stuff
[18:06] <muktupavels> make it simple icon + dbus menu and nothing more.
[18:06] <Trevinho> oh, well indeed that's mostly a job for the menu
[18:07] <Trevinho> but... secondary activation for example might trigger an action
[18:08] <muktupavels> I would not keep secondary activation
[18:09] <muktupavels> click on item - you get menu.
[18:14] <muktupavels> Trevinho: https://paste.ubuntu.com/25364127/
[18:15] <muktupavels> that is watcher interface that I would use as update.
[18:16] <Trevinho> muktupavels: well, 2nd activation is something i'd like to keep personally, as I find it useful for some quick actions
[18:17] <muktupavels> What methods you would keep for item?
[18:21] <muktupavels> That watcher interface that I pasted is only thing that I would consider is ready. Host and Item interfaces needs updates...
[18:22] <Trevinho> ok
[18:23] <Trevinho> muktupavels: in items I'd use properties for elements instead of the signaling systems
[18:23] <muktupavels> ?
[18:23] <Trevinho> muktupavels: New{Icon,Title,...} signals
[18:23] <muktupavels> Also that many icon properties does not make sense to me.
[18:23] <Trevinho> using just properties
[18:23] <Trevinho> yep...
[18:23] <muktupavels> yes, that is what I proposed I think
[18:24]  * Trevinho didn't read it recently :)
[18:24] <Trevinho> the only icons we need are Attention and Normal icon names/path..
[18:24] <muktupavels> Why?
[18:24] <Trevinho> in case together with a flag defining the type
[18:24] <muktupavels> Just change icon
[18:25] <Trevinho> muktupavels: as far we keep the Status property could be ok
[18:25] <Trevinho> but that allowed to avoid the annoyance
[18:25] <muktupavels> If item change its status then it can change icon if needed.
[18:25] <Trevinho> so when you switch from "attention mode" (i.e. got new message) to normal mode you just have to do it automatically
[18:26] <Trevinho> yeah, there's no difference, but this allowed some better cachign i think.. Especially in the case of the pixmap icons, which we won't support anyuway... so it's fair
[18:27] <muktupavels> I think items should not set icons. When it registers to host host should request icon.
[18:27] <muktupavels> so item might have new method that returns requested icon
[18:27] <Trevinho> eh, but it might need to change icon... so a signal to inform host about this
[18:28] <Trevinho> or a property would just do that
[18:30] <muktupavels> is there any reason why status items could not use only icon names?
[18:31] <mitya57> Trevinho, out of curiosity, where do you want to implement the new interface? In Unity 7 indicators? Or as GNOME Shell extension?
[18:32]  * mitya57 is an interested party here because he wrote the client code implementation in Qt
[18:33] <Gargoyle> Is there a Gnome bug for the in-app file picker not being the same as the "Files" app?
[18:34] <popey> Gargoyle: which app in particular?
[18:34] <Gargoyle> Chrome at the mo, but I'm sure I've spotted it elsewhere?
[18:36] <Trevinho> mitya57: i wouldn't change unity7 probably, but the shell extension indeed could include this new interface
[18:37] <Trevinho> mitya57: since you did the Qt part, and since that has some code to behave differently in unity as per missing Pixmap support, are you ok in what is suggesting muktupavels for icons?
[18:39] <Trevinho> anyway muktupavels maybe in the GetIcon client request could be icon-size and the client could return a touple with both retourned type and content, or something like that
[18:40] <Gargoyle> popey, And the one in xchat is different too (Different from files and chrome)
[18:40] <Gargoyle> Sorry, HexChat!
[18:41] <mitya57> Trevinho, I am fine with the proposed changes, yes.
[18:42] <Gargoyle> And firefox too... close but not quite
[18:42] <muktupavels> Trevinho: that sounds good. I would also add flags parameter so there is way to request symbolic icons.
[18:42] <popey> Gargoyle: ah, not surprised at firefox, and some older gtk things too
[18:42] <Trevinho> muktupavels: ok, let's keep things symbolic though...
[18:43] <muktupavels> I guess I need to find time and try to update interfaces again.
[18:43] <Gargoyle> Popey, OK. Probably being a little naive - but why?
[18:43] <Trevinho> muktupavels: also one thing in the host... since apps in containers might not be able to verify if this is supported by the host or not, by querying o.f.dbus for available names, I guess we should provide informations about the supported system
[18:44] <Trevinho> muktupavels: so for example, an electron app can query dbus to verify weather it's available or not, and then enable it
[18:44] <Trevinho> and the same for any other apps
[18:44] <Trevinho> and the same for any other app
[18:44] <popey> Gargoyle: depends what toolkit they use
[18:45] <muktupavels> Trevinho: I did not understand that part...
[18:46] <Trevinho> muktupavels: apps might be interested knowing if the shell they're running on supports this or not
[18:46] <Gargoyle> popey, So there isn't jsut a standard "request file path" api or something?
[18:46] <Trevinho> so... so far we have lots of apps doing if (XDG_CURRENT_DESKTOP == {Unity,KDE,whathever})
[18:46] <Trevinho> and we need to avoid this
[18:46] <muktupavels> Trevinho: whatcher is for that. item just checks if there is at least one host.
[18:47] <Trevinho> however, a sandboxed app could not be able to verify if there's a such server or not
[18:47] <Trevinho> muktupavels: providing some other metadata wouldn't be bad
[18:47] <popey> Gargoyle: sure, multiple standards
[18:47] <muktupavels> Trevinho: why sandboxed app could not access watcher?
[18:47] <Trevinho> we had ProtocolVersion which was never really used or IsStatusNotifierHostRegistered... but
[18:48]  * Gargoyle scratches his head - but isn't this all gnome?
[18:48] <Trevinho> muktupavels: maybe it could just access to RegisterItem method
[18:48] <Trevinho> anyway, providing some "huma readable" informations about it wouldn't be bad
[18:48] <Trevinho> so an app can query for tetsing if the status icon is supported or not
[18:49] <Trevinho> anyway... gotta go,
[18:49] <popey> Gargoyle: chrome isnt
[18:49] <Gargoyle> I mean, if you really want to take linux desktop UX to the next level, isn't this the type of thing to be addressing?
[18:49] <popey> Good luck getting everyone working on things on the linux desktop to follow one standard :D
[18:50] <Gargoyle> Because it seems no-one is making life easy for other devs.
[18:52] <Gargoyle> So (genuinely trying to understand - as I am thinking at making a desktop app), where is the "goto resource" for asking a user for a filename for save/open/etc?
[18:54] <popey> Gargoyle: depends what type of app, gtk, qt, electron...
[18:56] <Gargoyle> So, my desktop of choice has no effect on those?
[18:57] <Gargoyle> Installing Gnome doesn't drop in a replacement qt library that maps calls to a standard set?
[19:01] <popey> Gargoyle: if you write a qt app, and use qt dialogs, you'll get qt dialogs on whatever desktop
[19:10] <Gargoyle> So in order to have any chance in hell of having a coherent desktop experience, Linux needs to bring together GTK, QT, Electron and any others into making an abstract library for apps to use?
[19:10] <Gargoyle> All apps use the same abstraction and then the DE is the one to actually implement it?
[19:21] <dobey> huh
[22:40] <JanC> it seems like there is an X window (resource/handle?) leak in Compiz on zesty...?