[07:07] <didrocks> good morning
[07:08] <jibel> Salut didrocks
[07:08] <jibel> ça va?
[07:11] <didrocks> salut, ça va, et toi ?
[07:11] <jibel> didrocks, bien bien, I took the day off to relax a bit after this release and before next one next week
[07:12] <didrocks> jibel: totally deserved :)
[07:16] <duflu> Morning didrocks, jibel
=== ecloud is now known as ecloud_wfh
[07:26] <didrocks> hey duflu
=== pstolowski|afk is now known as pstolowski
[08:00] <oSoMoN> good morning desktoppers
[08:01] <duflu> Hi oSoMoN
[08:06] <oSoMoN> hey duflu
[08:15] <didrocks> hey oSoMoN
[08:16] <oSoMoN> salut didrocks
[08:57] <willcooke> morning all
[08:59] <didrocks> hey willcooke
[09:01] <seb128> hey willcooke & desktopers
[09:01] <seb128> how is it going today?
[09:02] <didrocks> morning seb128, still sunny here! But wint^W^W^W^Wrain is coming from what I heard :p
[09:02] <Laney> yo
[09:02] <didrocks> hey Laney
[09:02] <didrocks> how are you?
[09:03] <duflu> Morning willcooke and seb128
[09:03] <duflu> and morning Laney
[09:03] <seb128> hey Laney, duflu
[09:04] <seb128> didrocks, I'm ok, was up in the night because of the cold and it took me some time to sleep again so a bit tired :/
[09:05] <oSoMoN> good morning willcooke, seb128, Laney
[09:06] <didrocks> seb128: sounds like your cold will never end. Good luck :/
[09:06] <Laney> hey didrocks duflu seb128 oSoMoN willcooke
[09:06] <willcooke> ahoy all
[09:06] <willcooke> Going to see Dave Gorman tonight \o/
[09:06] <Laney> didrocks: good, looks like the fake spring has ended
[09:07] <seb128> didrocks, I keep getting new one, thanks to sprint & kid
[09:07] <seb128> lut oSoMoN
[09:07] <Laney> last night we went to: https://photos.google.com/share/AF1QipPM5u4K_t2HQCR7VQ0TMkXaOSBE5yZK66SrTp40SB0cyGxcPvnZsP1LmbmVMjBSsA/photo/AF1QipPUnZ4Ru2LCVwa0bde0u-1tkMFiwR35zBC0d3iA?key=VzNQMlFkN0V4djJZRGYzcHZ6NEpOUHU3VGMwNVZB #quality #link
[09:07] <didrocks> seb128: renewed membership :p
[09:07] <seb128> :)
[09:07] <didrocks> Laney: we still have it for one day! I'll make it worth it :p
[09:07] <didrocks> Laney: oh nice
[09:09] <didrocks> I can't recognize you in the crowd, because, you were part of the dancing crowd, right, right RIGHT? :)
[09:09] <Laney> hahah
[09:09] <Laney> I was behind the camera
[09:09] <didrocks> next year then? ;)
[09:10] <seb128> jbicha, kenvandine, the desktop list moderation queue got emails about eog-master snap failing to upload to the store (monday), gedit-master too (today) and build failure for gnome-hitori-master
[09:10] <seb128> (quite annoying to have those going to the list without being sure if they also reach the right people, I don't know if/how we can resolve that)
[09:10] <Laney> could be fun to do
[09:11] <seb128> jbicha, gnome-hitori fails on 'cp: cannot stat '../src/data/icons/48x48/org.gnome.Hitori.png': No such file or directory'
[09:11] <Laney> seb128: what's wrong with them ending up on the list?
[09:12] <seb128> they don't end up in the list
[09:12] <seb128> they end up in a moderation queue I've to manual deal with every morning
[09:12] <Laney> not from a known address that can be whitelisted?
[09:12] <seb128> some have private token or store link so I'm unsure we want to whitelist
[09:13] <Laney> then that's what's wrong
[09:13] <seb128> yeah, probably
[09:13] <seb128> I don't feel like I understand the snap/store process enough atm to take an informed decision on what needs to be done
[09:14] <Laney> ok
[09:14] <seb128> I also don't feel like those snaps are team maintainer, we don't have shared knowledge of the process and acl are not open to the team afaik
[09:14] <seb128> maintained*
[09:14] <seb128> which I would like to fix
[09:15] <seb128> anyway, a discussion to have with Ken when he's around, he's the one mostly owning that stack atm, we should look at how we make that more of a team owned topic
[09:15]  * seb128 adds to backlog
[10:34] <willcooke> How easy is it to convert a live USB stick in to a persistent one?
[10:34] <jbicha> gedit-master said "internal server error" so all I had to do was click the retry button
[10:34] <clobrano> good morning everyone o/
[10:34] <jbicha> I already handled eog-master with Ken on Monday
[10:35] <clobrano> Laney: about desktop-icon fix, the release is blocked by a DBus API change, which in turn will be released in the next gnome version
[10:36] <seb128> version being 31.91 or next cycle?
[10:37] <jbicha> I'm fixing gnome-hitori-master (upstream made icon filename changes which is good because it should finally fix bug 1670214 )
[10:37] <ubot5> bug 1670214 in hitori (Ubuntu) "Hitori missing from Software app" [Medium,Triaged] https://launchpad.net/bugs/1670214
[10:37] <clobrano> seb128: they only said "next release" actually
[10:38] <seb128> jbicha, hey, k
[10:38] <jbicha> good morning
[10:38] <clobrano> and "there isn't a release cycle"
[10:38] <clobrano> morning jbicha
[10:46] <jbicha> gnome-hitori-master is fixed now
[10:47] <jbicha> I got the eog-master email because I had directly requested the failed build and it doesn't look to me like it had private data in the email
[10:48] <jbicha> our snaps are listed at https://wiki.ubuntu.com/DesktopTeam/GNOMESnaps
[10:49] <seb128> I didn't say it had
[10:49] <seb128> I said I don't whitelist snap emails because I think some of those sometime have
[10:49] <jbicha> to fix hitori, I went to https://code.launchpad.net/~ubuntu-desktop/+snap/gnome-hitori-master
[10:50] <jbicha> I looked at the build logs and then fixed the yaml which in this case is upstream, so that's https://gitlab.gnome.org/GNOME/hitori/commits/master
[10:51] <jbicha> I don't bother with merge requests since generally GNOME maintainers don't deal with Snap stuff and are fine with us fixing Snap issues
[10:51] <seb128> :)
[10:51] <seb128> ah, that is still core 16 I see
[10:52] <jbicha> https://launchpad.net/~ubuntu-desktop/+snap/gnome-hitori-master has a source line, I click it and get to https://code.launchpad.net/~gnome3-team/hitori/+git/hitori/+ref/master
[10:52] <jbicha> I click the breadcrumb think to "go up" to to the main page which is https://code.launchpad.net/~gnome3-team/hitori/+git/hitori
[10:53] <jbicha> I clicked Import Now because I didn't want to wait several hours for the next automatic import
[10:54] <seb128> ah, that's good to know
[10:54] <jbicha> you can then go back to https://launchpad.net/~ubuntu-desktop/+snap/gnome-hitori-master and request a rebuild manually
[10:54] <jbicha> but the manual request button doesn't let you use the candidate channel for snapcraft (like you can with the automatic builds)
[10:55] <jbicha> at least earlier this month, there were some issues with the final snap size in the stable channel
[10:55] <jbicha> so there's a cli tool you can use instead:  start with    snap install lp-build-snap
[10:55] <willcooke> seb128, Laney - do you remember... we did something about screensaver not being disabled a while back.  I can't remember if that was upgrades or installs.. do you remember?  (i.e. a fresh disco install and the screensaver kicks in - so not really a problem)
[10:56] <jbicha> and then you can just run something like:
[10:56] <jbicha> snap run lp-build-snap --lpname ubuntu-desktop --series bionic --core-channel stable --snapcraft-channel candidate gnome-hitori-master
[10:56] <jbicha> and see   snap run lp-build-snap --help
[10:56] <seb128> willcooke, it was ubiquity not blocking the screen idle which was killing your screenreader?
[10:57] <willcooke> ahh, that's it
[10:57] <willcooke> Lemme test then
[10:57] <willcooke> thanks seb128
[10:57] <jbicha> I believe Ken is currently the only one that can handle the upload authorization and publishing to stable channel for most of those snaps, but anyone in ~ubuntu-desktop can directly fix build problems
[10:58] <jbicha> we need to document this stuff better though
[10:58] <seb128> willcooke, https://git.launchpad.net/ubiquity/commit/?id=eb92fecbc432122df059a082945063e650ca47b5
[10:58] <jbicha> I had never touched snap packaging until a few weeks ago
[10:58] <seb128> willcooke, that just got commited yesterday, unsure from what angle you are coming/what you ask exactly today though?
[10:58] <seb128> jbicha, right, that was mostly my point, we need to document/share knowledge (and probably resolve the fact that Ken only can publish to stable)
[10:59] <seb128> willcooke, ah, you just tried disco and had the screen blanking? I believe that should be fixed by ^ then, which hasn't been uploaded yet
[11:00] <willcooke> seb128, ah kk, might need to wait for another image then.  Reason I ask is:  I wanted to test iOS 12 devices on disco (seeing more people say it's broken still, but yet it isn't for me...wat?!) so I was doing a fresh disco install.  Then I went to answer the door and when I came back the screensaver was on, and it rang a little bell in the back of my mind which made me think it wasn't supposed to be doing that.
[11:00] <willcooke> seb128, ack! thx
[11:00] <willcooke> back to iOS then
[11:00] <seb128> :)
[11:00] <seb128> (needs an ubiquity source upload first, then an iso build with it, but it's in the pipe now)
[11:01] <willcooke> in other news:  Amazon just delivered me a lovely empty box.
[11:02] <willcooke> and ios 12 works for me.  damn it
[11:02] <willcooke> something for next Thursday then :)
[11:02] <seb128> yeah
[11:02] <seb128> really you should ask for a testing device
[11:02] <didrocks> willcooke: empty box -> toy for your children :)
[11:02] <seb128> your years old iphone isn't enough
[11:03] <Laney> I'm actually testing a ubiquity upload right now.
[11:03] <willcooke> well, it runs the latest release of iOS, but yeah, I will ask Father Christmas, err Dean, for one
[11:03] <willcooke> nice, thanks Laney
[11:03] <seb128> :)
[11:06] <willcooke> didrocks, :D
[11:21] <sentiment> hello. I want to contribute to the gnome-music project.
[11:22] <sentiment> But Ubuntu has its own package repository for that project.
[11:22] <sentiment> How should I proceed? I just downloaded the source for the latest gnome-music and it is refusing to build. I think it's because of some dependency issues.
[11:22] <seb128> hey sentiment, you better contribute directly upstream for it
[11:23] <sentiment> Ubuntu'version is lagging behind gnome's
[11:23] <seb128> sentiment, https://launchpad.net/ubuntu/+source/gnome-music/3.31.90-1 ?
[11:23] <sentiment> hmm. mine is version 3.28
[11:24] <sentiment> and no update was available last I checked one hour ago
[11:24] <sentiment> I'm running Ubuntu 18.04
[11:25] <sentiment> I am totally new to Linux development. What are the usual procedures to follow when I want to contribute to an Ubuntu package?
[11:26] <sentiment> same as what seb128 suggested? Directly contribute to the original source?
[11:26] <seb128> sentiment, https://wiki.ubuntu.com/ContributeToUbuntu
[11:26] <seb128> sentiment, what sort of contribution do you want to do?
[11:26] <sentiment> Yes I have that link open right now
[11:26] <seb128> and yes, older series of Ubuntu have older versions of software
[11:26] <sentiment> mainly gnome packages
[11:26] <seb128> well, do you want to contribute to the code?
[11:26] <sentiment> yes
[11:27] <seb128> sentiment, you better look there then, https://gitlab.gnome.org/GNOME/gnome-music
[11:27] <seb128> and https://wiki.gnome.org/Apps/Music
[11:27] <sentiment> yes, that's the first link that I visited
[11:27] <seb128> https://wiki.gnome.org/Apps/Music/Resources
[11:27] <sentiment> from which I got the source
[11:27] <sentiment> ok
[11:27] <seb128> k
[11:28] <seb128> well then you are at the right place
[11:28] <sentiment> I think I need to remove the Gnome-Music package from my system though.
[11:28] <sentiment> There must be a reason that the latest build is not available for Ubuntu 18.04
[11:29] <sentiment> I'll ask in the gnome-music channel.
[11:29] <Laney> Ubuntu's not a rolling release, so applications stay (mostly) at the versions that it was released with
[11:42] <seb128> ricotz, jbicha, any idea if https://bugs.launchpad.net/ubuntu/+source/seahorse/+bug/1818053 could be a vala bug?
[11:42] <ubot5> Ubuntu bug 1818053 in seahorse (Ubuntu) "/usr/bin/seahorse:11:g_atomic_ref_count_dec:g_variant_unref:___lambda22_:____lambda22__gasync_ready_callback:g_simple_async_result_complete" [High,Confirmed]
[11:42] <seb128> it segfaults on that code line
[11:42] <seb128> 				service.prompt_at_dbus_path.begin(prompt_path.dup(), null, null, (obj, res) => {
[11:43] <seb128> well rather
[11:43] <seb128> 				service.prompt_at_dbus_path.begin(prompt_path.dup(), null, null, (obj, res) => { 					try { 						service.prompt_at_dbus_path.end(res);
[11:44] <andyrock> jbicha: https://salsa.debian.org/gnome-team/tracker/merge_requests/1 or https://gitlab.gnome.org/GNOME/tracker/merge_requests/65 to fix tracker autopkgtest
[11:44] <gitbot> GNOME issue (Merge request) 1 in tracker "debian/rules: Drop -Bsymbolic(-functions)" [Opened]
[11:44] <gitbot> GNOME issue (Merge request) 65 in tracker "meson: Enforce build order using generated headers directly" [Opened]
[11:49] <ricotz> seb128, taking a look
[11:52] <seb128> andyrock, well done on that test issue
[11:52] <seb128> I wonder if the Bsymbolic-function win is worth the engineering work we put in dealing with such problems
[11:53] <andyrock> -Bsymbolic was introduced in tracker when libtracker-client used to be dlopen-ed
[11:53] <andyrock> libtracker-client does not exists anymore
[11:53] <andyrock> at least that's what the git history tells me :)
[11:54] <andyrock>  anyway you can reproduce the issue even without -bsymbolic (you need to enable lto and -O3)
[11:55] <andyrock> because the duplicate function will be inlined from the optimizer
[11:55] <andyrock> *by the op...
[12:21] <cpaelzer> tjaalton: willcooke was so kind to let me know you are looking after mesa - it would be great if you could take a look at 1815889 and let me know what you think
[12:21] <cpaelzer> The TL;DR is please revert https://github.com/mesa3d/mesa/commit/d877451b48a59ab0f9a4210fc736f51da5851c9a if that seems ok from an Ubuntu-mesa POV
[12:25] <tjaalton> cpaelzer: does it happen with 19.0rc5 from ppa:canonical-x/x-staging ?
[12:30] <tjaalton> I'd assume yes, would move the bug to 19.0 blockers
[12:36] <cpaelzer> tjaalton: mesa-19.0.0-rc6 still has the code making it fail
[12:36] <cpaelzer> so yes it will be bad with that as well
[12:37] <cpaelzer> even thou to admit - I haven't set up a system with ppa:canonical-x/x-staging to verify
[12:37] <cpaelzer> but I see no reason it wouldn't
[12:38] <cpaelzer> tjaalton: do you strictly need me to upgrade the system to the PPA to be sure to be able to go on?
[12:38] <cpaelzer> or can I leave it as-is for now?
[12:40] <cpaelzer> well, let me do it - shouldn't be too hard ...
[12:42] <cpaelzer> Runnin on the x-staging PPA you asked for (now missing libgl1-mesa-dri-dbgsym for nicer debug) but the TL;DR is - yes it is still failing
[12:42] <cpaelzer> tested 19.0.0~rc5-1ubuntu0.1
[12:42] <cpaelzer> The stack trace looks pretty much the same, some line numbers changed
[12:49] <tjaalton> cpaelzer: yup, do you need it reverted soon?
[12:58] <mpt> jamesh, kenvandine: Hi, I’d appreciate your feedback on the theme snap GUI. https://github.com/CanonicalLtd/desktop-design/issues/147
[12:58] <gitbot> CanonicalLtd issue 147 in desktop-design "Design GUI for installing theme snap" [Review: Ux Needed, Open]
[13:10] <kenvandine> mpt: I'll look at it today
[13:10] <kenvandine> seb128: thanks, why do they get moderated?
[13:18] <seb128> hey kenvandine
[13:19] <ricotz> seb128, do you know if this seahorse issue is an even older issue?
[13:19] <seb128> kenvandine, because they come from launchpad email addressed which are not member of the list
[13:19] <kenvandine> I see
[13:20] <ricotz> seb128, I am wondering if the libsecret g-i-annotations/binding is correct
[13:20] <seb128> ricotz, reports started recently, could be a change in the new 31.91 though
[13:20] <seb128> I didn't see anything obvious in the git commits though
[13:20] <ricotz> me neithre
[13:21] <ricotz> I haven't used this feature before, is this working in cosmic?
[13:21] <seb128> I think so yes
[13:23] <seb128> kenvandine, do you if there is a "store status checker" somewhere? https://launchpad.net/~ubuntu-desktop/+snap/gnome-hitori-master/+build/479227 is failing to upload with '
[13:23] <seb128>     500 Server Error: INTERNAL SERVER ERROR'
[13:23] <seb128> which I just reetried but same error
[13:25] <seb128> retried again and it worked :/
[13:25] <seb128> is that usual for uploads to be flaky?
[13:27] <kenvandine> i'll tell the store
[13:28] <kenvandine> notified :)
[13:29] <seb128> thx
[13:30] <seb128> kenvandine, also, do you know what's the "store series" about on launchpad?
[13:30] <seb128> kenvandine, like https://launchpad.net/~ubuntu-desktop/+snap/gedit-master is on "ubuntu core 16" but I though master builds were migrated to 18?
[13:31] <seb128> seems like launchpad only list 16 :/
[13:31] <kenvandine>     500 Server Error: INTERNAL SERVER ERROR'
[13:32] <kenvandine> is all i have
[13:32]  * kenvandine is just relaying info from seb128  :)
[13:32] <seb128> kenvandine, wrong channel?
[13:32] <kenvandine> whoops :)
[13:33] <seb128> where is the action? ;)
[13:33]  * kenvandine is still not feeling well :)
[13:34] <kenvandine> i was talking to nessita in another channel
[13:34] <seb128> kenvandine, https://lists.ubuntu.com/archives/ubuntu-desktop/2019-February/005863.html if you want the full context
[13:34] <kenvandine> great
[13:34] <kenvandine> but that doesn't have any more info :)
[13:34] <seb128> kenvandine, 2 retries and it worked, but it's a bit annoying having to manually follow to make sure things get published
[13:35] <seb128> kenvandine, well, they are the ones generating the emails, so if it's missing info they should be the ones fixing it :p
[13:35] <kenvandine> :)
[13:35] <kenvandine> indeed
[13:35] <kenvandine> they think they have an issue with blob storage, working on it
[13:36] <seb128> great
[13:36] <seb128> thx ken!
[13:36] <Laney> swift is being a piece of crap, I think the snap store uses that
[13:36] <kenvandine> seb128: thank you
[13:36] <kenvandine> it is swift
[13:36] <Laney> biting us for autopkgtest too, see #ubuntu-release
[13:37] <seb128> thx Laney
[14:07] <seb128> ricotz, do you look at the seahorse issue from a vala perspective or do you want me to try to look at what update/change started it?
[14:10] <ricotz> seb128, please take a further look, afaics libsecret (secret_service_prompt_at_dbus_path_finish) is returning an invalid and not-null GVariant
[14:10] <seb128> ricotz, ok, thx
[14:10] <seb128> ups
[14:11] <ricotz> not sure from which backend this originally comes from, maybe gnome-shell?
[14:12] <seb128> no idea
[14:29] <didrocks> random question: do we support non UTF-8 filenames?
[14:30] <kenvandine> ugh, snaps I just published yesterday are affected by USNs for libnss3 today :(
[14:30] <didrocks> "nice" timing
[14:31] <kenvandine> indeed
[14:31] <kenvandine> another round of building and testing today for a bunch of snaps :/
[14:32] <willcooke> kenvandine, could we get cwayne's machine to test them?
[14:32] <kenvandine> when it's ready
[14:33] <kenvandine> i haven't gotten the word yet
[14:33] <willcooke> kk
[14:33] <kenvandine> it's only about 10 snaps... only
[14:33] <willcooke> heh
[14:33] <kenvandine> 4 of wish i published yesterday :)
[14:33] <didrocks> 1 snap, lalala, 2 snaps, lalala, 3…
[14:37] <seb128> didrocks, non-UTF8 as in what format? and in what context? python/snaps/fs/...?
[14:38] <didrocks> seb128: for file names, like writing and handling those files on disk. I don't remembre if we support that or not
[14:39] <seb128> do you have an example?
[14:39] <seb128> I'm not even sure how you create a nonUTF8 filename?
[14:39] <didrocks> I guess copying a file with accent from windows using iso-something?
[14:40] <didrocks> I'm just trying to ensure if we use this option or not from zfs (which has a consequence of forcing utf-8 only file names)
[14:41] <seb128> we had report in the past about wrong filename rendering in e.g nautilus
[14:41] <seb128> so I guess it's supposed to be working but we are probably not bug free in the UI stack
[14:42] <didrocks> ok, let's see if we turn it on as an experiment first, see how it goes in the real world, and assess
[14:44] <seb128> makes sense
[14:47] <didrocks> we should add notes for things to test ourself (like extracting a tar with non utf-8 names) to see how it explodes :p
[14:47] <didrocks> thx for the feedback seb128
[14:49] <didrocks> btw: http://open-zfs.org/wiki/Platform_code_differences
[14:49] <didrocks> under "Platform specific", there is autotools
[14:49] <seb128> np
[14:49] <didrocks> I'm unsure I would put that first :p
[14:50] <seb128> haha
[15:30] <Trevinho> question.... upstream g-s removed the adaptive panel bg, this is because it should actually be blurred probably in such case, but we didn't fix this yet, so went back to black...
[15:30] <Trevinho> Now, dash-to-dock upstream was fine to remove such support too, but the problem of the panel was the hard readability
[15:30] <Trevinho> which is not an issue in the dock
[15:31] <Trevinho> so... d2d code is removed now upstream, but could be readdded easily without panel support
[15:31] <Trevinho> thing is, do we want the dock (only) to be adaptive or we go back to just transparent one?
[15:34] <Trevinho> imho isn't a problem to have only the dock to be adaptive, since isn't really something that has to be consindered the same of the panel, but as you guys prefer.
[15:34] <Trevinho> didrocks: maybe you care?
[15:39] <didrocks> Trevinho: I would say as we had before the panel got adapative, semi-transparence of the dock in intellihide, wdyt?
[15:39] <didrocks> (and so, value set, no adaptative thingy)
[15:39] <Trevinho> ok
[15:39] <didrocks> otherwise, for fixed dock, panel color…
[15:49]  * seb128 has no opinion, not even sure to understand the question
[15:49] <Trevinho> seb128: basically weather making the dock to become transparent when you approach a window or not
[15:50] <Trevinho> well the other way around xD
[15:50] <seb128> I personally found it confusing when that change was added
[15:50] <seb128> but probably not the best person to ask about those things :)
[15:50] <seb128> seems like didrocks has an opinion, get maybe a second one from willcooke and if they agree we have a consensus
[15:51]  * willcooke reads
[15:51] <didrocks> I guess the question can become: "was the 17.10 behavior fine with everyone? If so, let's revert to this"
[15:52] <willcooke> hrm, not sure I understand either
[15:52] <willcooke> let me install a 17.10 VM
[15:52] <Trevinho> Basically the idea is: when you have windows nearby the dock it uses a solid color, otherwise it is sem-transparent
[15:53] <didrocks> willcooke: basically, it was no "adaptative thingy": dock is opaque when always visible and semi-transparent (but fixed) in intellihide mode IIRC
[15:53] <didrocks> I suggest to revert to that ^ (as the top panel won't be adaptative anymore)
[15:53] <seb128> +1
[15:53] <willcooke> I thought upstream got rid of the semi transparent thing because it was hard to read
[15:53] <seb128> I always found the adaptative thing to be ugly
[15:53] <Trevinho> yeah, that's the point
[15:53] <Trevinho> but the hard-to-read doesn't apply to the dock
[15:53] <willcooke> oh, because no text
[15:53] <Trevinho> and we don't have to match dock and panel
[15:53] <willcooke> well, I think they *should* match
[15:53] <Trevinho> yep
[15:53] <seb128> you switch workspaces with one having something next to the launcher and one which doesn't and the visual changes
[15:54] <didrocks> yeah, but only having part being adaptative would be weird IMHO
[15:54] <Trevinho> well, they never matched in unity, nor they do now since it's still something different... the panel can't have windows underneath while the dock does
[15:54] <willcooke> yeah, I think I agree with didrocks.  Have the dock to semi-trans but the top bar not is weird.
[15:54] <willcooke> s/to/do
[15:54] <Trevinho> anyway, I'm not really a lover of this, so we can go whatever you guys prefer
[15:55] <willcooke> :)
[15:55] <didrocks> so dock opaque in "always visible" but fixed transparency in intellihide?
[15:55] <seb128> open when visible+1 from me
[15:55] <didrocks> (which was the 17.10 behavior)
[15:55] <seb128> no opinion on intellihide
[15:55] <willcooke> why not opaque in intelide as well?
[15:55] <didrocks> in intellihide, the reasoning is that it can go over windows
[15:55] <seb128> I didn't dare asking :p
[15:55] <didrocks> when you reveal it
[15:56] <didrocks> and so might still want to see what's beneath
[15:56] <Trevinho> well, fully opaque or not is also a theming thing, in 18.04 is  semi-tranparent with opaque panel and I think is a good combo
[15:56] <didrocks> I don't think we had user complains on this
[15:56] <willcooke> hrm, not convinced myself.  I open the dock to see whats on it
[15:56] <willcooke> my 18.04 dock is solid black I think
[15:56] <didrocks> because is adapatitive
[15:57] <willcooke> ah right
[15:57] <didrocks> so you have a window next to it -> fully opaque
[15:58] <didrocks> actually, my memory is bad
[15:58] <willcooke> hehe
[15:58] <didrocks> 17.10 already had adaptative transparency
[15:58] <willcooke> Imma install 17.10
[15:58] <didrocks> we never shipped a release with the fix transparency
[15:58] <didrocks> we only had it for some months, before upstream changed at the last minute the top panel transparency to be adaptative
[15:58] <didrocks> (after code freeze)
[16:00] <Trevinho> gnome code freeze... Well it's  not as we mean it :)
[16:01] <didrocks> ok, that was before we themed it, but that was our default for a short while: https://didrocks.fr/images/artful-shell-transition/friday-18-august-default.png
[16:01] <didrocks> so a little bit of transparency by default
[16:01] <didrocks> similar to unity: https://didrocks.fr/images/artful-shell-transition/thursday-17-august-unity-session.png
[16:02] <didrocks> nice to have blogged about those, easy for digging in history :p
[16:02] <seb128> :)
[16:02] <seb128> +1 from me for going back to that
[16:02] <didrocks> yeah, let's try
[16:02] <seb128> Trevinho, don't waste too much time on that, you have more important work to focus on
[16:03] <didrocks> also, let's tweak our theme back to this: https://didrocks.fr/images/artful-shell-transition/another_proposal_for_ubuntu_theme.png :)
[16:03] <seb128> haha :)
[16:03]  * didrocks remembers to have work at 4am (couldn't sleep) in the hotel room in London
[16:03] <didrocks> this is where bad things like this happens :p
[16:03] <willcooke> :D
[16:03] <willcooke> I remember the green
[16:03] <willcooke> ok, looking at the screenshot (while 1710 is still installing) I'm +1 as well
[16:04] <didrocks> willcooke: don't install 17.10, as told, the finale release was adaptative, so not different than bionic
[16:04] <willcooke> nod
[16:05] <didrocks> waow, installing ubuntu-desktop from a debootstrap install for zfs is soooo long… happy that we rsync/cp the installs and stopped installing one deb after another…
[16:05] <Trevinho> willcooke: you can probably try play with settings
[16:06] <willcooke> maybe, but I'm fine with that ^
[16:08] <kenvandine> sigh... gnome-contacts and gnome-calendar snaps no longer sync with google accounts after upgrading to disco.  I'm guessing something changed in GOA?
[16:10] <willcooke> could it be that the API keys have been revoked?
[16:13] <didrocks> reboot successful on desktop + zfs manually tweaked \o/
[16:13] <willcooke> didrocks, neat!"
[16:20] <seb128> didrocks, well done!
[16:22] <didrocks> thx ;)
[17:04] <kenvandine> willcooke: debugging, it looks like API change
[17:05] <kenvandine> but perhaps EDS not GOA
=== pstolowski is now known as pstolowski|afk
[17:30] <seb128> kenvandine, the lack of definition/Stability for e-d-s is an issue :/ (the flatpak guys also often raise it as something that needs to be resolved)
[17:30] <kenvandine> :-(
[17:34] <kenvandine> seb128: so far it hasn't bit us
[17:37] <seb128> we got lucky
[17:41] <kenvandine> Yup
[17:59] <willcooke> g'night all
[18:05] <Laney> bye
[18:05] <Laney> off tomorrow, see you monday
[18:05] <kenvandine> bye Laney !
[18:05] <kenvandine> enjoy
[18:06] <kenvandine> seb128: got any references to flatpak and eds issues?  i don't see any of it on their mailing list
[18:06] <kenvandine> i'm guessing some gnome lists?
[18:07] <didrocks> see you Laney!
[18:13] <seb128> Laney, enjoy the long w.e, see you next week!
[18:13] <seb128> kenvandine, no, just mclasen discussing with others on #gnome-hackers
[18:13] <kenvandine> seb128: ok
[18:17] <kenvandine> maybe this is why gnome-contacts and gnome-calendar aren't on flathub :/
[18:20] <ahayzen[m]1> kenvandine: FYI https://flathub.org/apps/details/org.gnome.Contacts https://flathub.org/apps/details/org.gnome.Calendar :-)   And i think some apps bundle their own e-d-s to get things to work if the host one isn't compatible (eg Evolution).
[18:21] <kenvandine> weird... i did a search for "contacts" and it found nothing
[18:21] <kenvandine> same for calendar
[18:21] <kenvandine> i guess the search is busted
[18:21] <kenvandine> oh... now the search works... wtf
[18:24] <kenvandine> i bundle the libs in the snap, but i guess i need to bundle the service too
[18:25] <ahayzen> although i can't see them starting a custom service in the contacts/calendar flatpak, only Evolution seems to do that. So they probably also suffer the same situation
[18:45] <oSoMoN> good night all
[19:50] <kenvandine> ahayzen[m]1: they do
[19:50] <kenvandine> in flatpak-wrapper.sh
[19:51] <kenvandine> kind of stinks you can't share a calendar and contacts between apps
[19:51] <ahayzen[m]1> Ah is that in the upstream repo I only looked at the manifest and not the launcher
[19:52] <kenvandine> yeah
[19:52] <kenvandine> they spawn all the eds services needed
[19:52] <ahayzen[m]1> Yeah hopefully now we are sandboxing things a solution will be found, I think there are similar problems with tracker
[19:53] <kenvandine> yeah
[19:53] <kenvandine> eds hasn't really changed in ages
[19:53] <kenvandine> but now it has
[19:53] <kenvandine> i guess they've been busy this cycle :/
[22:45] <jbicha> I think some Flatpak apps bundle a tracker miner and hope that the system is running tracker :|
[22:52] <ahayzen> yeah i think some do that like music :-/  i think there are discussions about how tracker can be changed to suit sandboxed environments better