=== JanC_ is now known as JanC
[06:42] <didrocks> good morning
[06:44] <jibel> Salut didrocks
[06:44] <c-lobrano> hey, good morning :)
[06:45] <didrocks> salut jibel, hey c-lobrano
=== pstolowski|afk is now known as pstolowski
[07:25] <seb128> good morning desktopers
[07:26] <didrocks> re seb128
[07:27] <seb128> re didrocks :)
[07:29] <Nafallo> morning
[07:38] <oSoMoN> good morning desktoppers
[07:40] <seb128> lut oSoMoN, comment ça va ? passé un bon w.e?
[07:40] <didrocks> salut oSoMoN
[07:40] <oSoMoN> salut seb128, didrocks
[07:40] <oSoMoN> I spent a couple of hours at Ikea on Saturday morning, I thought I was going to die
[07:41] <oSoMoN> apart from that, a good week-end :)
[07:41] <seb128> don't go there in a w.e!
[07:41] <didrocks> and it was in the morning… :p
[07:42] <oSoMoN> yeah, never again…
[07:52] <willcooke> morning
[07:52] <Nafallo> hey willcooke :-)
[07:52] <seb128> hey willcooke, how are you?
[07:56] <willcooke> hey seb128, Nafallo - doing ok
[07:56] <willcooke> Nice break seb128?
[07:57] <didrocks> hey willcooke
[07:57] <seb128> willcooke, yeah, great week off, thx!
[07:57] <andyrock> good morning!
[07:58] <seb128> willcooke, how have things being for you? not too crazy post Berlin? good w.e?
[07:58] <oSoMoN> good morning willcooke, Nafallo, andyrock
[08:02] <Laney> yo
[08:02] <oSoMoN> morning Laney
[08:05] <seb128> hey Laney, how are you?
[08:05] <Laney> hey oSoMoN seb128
[08:06] <didrocks> hey Laney
[08:06] <Laney> hey didrocks!!!!
[08:06] <Laney> seb128: I'm good
[08:07] <Laney> nice weekend, saw some friends who were visiting, did the parkrun (still super slow), went to a folk club & went climbing!
[08:07] <Laney> good week off?
[08:07] <Laney> & how is everybody else?
[08:10] <didrocks> way better than this week-end! I was really sick and couldn't do much/sleep much
[08:10] <Laney> oh man
[08:11] <Laney> better now?
[08:11] <didrocks> yeah, way better, hopefully, thanks! :)
[08:11] <didrocks> I can at least walk :p
[08:11] <Trevinho> Morning...
[08:11] <oSoMoN> I'm good, had a good week-end except for that near-death experience in Ikea on Saturday morning, I barely survived
[08:12] <oSoMoN> hey Trevinho
[08:12] <Trevinho> Hi oSoMoN
[08:12] <oSoMoN> Trevinho, has the hackfest started?
[08:12] <seb128> Laney, yeah, excellent week off, lot of walking around or sitting/relaxing in the nice weather :)
[08:12] <seb128> hey Trevinho
[08:13] <Trevinho> seb128: hiii, had a good week off?
[08:13] <Laney> oSoMoN: under a pile of wardrobes?
[08:13] <Trevinho> oSoMoN: nope... In an hour
[08:13] <seb128> Trevinho, hey, very good indeed!
[08:13] <Laney> Trevinho has brought italian culture to the UK
[08:13] <oSoMoN> Laney, too much furniture, and too many people
[08:13] <Laney> 10am starts!
[08:14] <didrocks> Laney: could be worse, Spanish one :)
[08:14]  * didrocks almost wrote "snapish"
[08:15] <Trevinho> Laney: no, there's no need... Thank God Spanish guys are here :-)
[08:15] <didrocks> that's why 10am, you have found a middle ground between UK and Spanish :)
[08:16] <oSoMoN> Spaniards would start at 10 and go for breakfast at 10:15
[08:16] <didrocks> roh :p
[08:19] <seb128> oh, hackfest, that's why Trevinho is up, now it explains! :)
[08:20] <seb128> Trevinho, is there an agenda for the hackfest btw?
[08:20] <didrocks> roh ^2
[08:20] <Trevinho> seb128: yeah in the wiki, but not defined yet
[08:20] <Trevinho> seb128: also fill up the guadec doc for booking
[08:21] <seb128> Trevinho, I need to catch up on those discussions, I'm all still unsure how long I'm staying, I need to look at the conf schedule (if it's available yet)
[08:22] <didrocks> seb128: it's not yet
[08:23] <seb128> typical GNOME :
[08:23] <seb128> :/
[08:23] <Trevinho> seb128: ok, try to do it asap as they said me to be quick in finalizing the booking
[08:23] <didrocks> seb128: well, voting finished on Monday, delayed due to some delayed requests :p
[08:23] <seb128> Trevinho, who is "they"? we don't use the travel agent this time?
[08:24] <seb128> didrocks, I see
[08:25] <Trevinho> seb128: clan can pay for it, while I'm your travel agent :-D
[08:25] <andyrock> what's the raccomended way to get the ubuntu codename in C?
[08:25] <seb128> Trevinho, k, I guess I just need to read that backlog, I just glanced over it and it seemed lot of IM-bla :p
[08:26] <seb128> hey andyrock
[08:29] <Laney> hey andyrock
[08:29] <Laney> what for?
[08:29] <andyrock> hey Laney seb128
[08:29] <andyrock> we need to hide the canonical-livepatch page in gnome-initial-setup if the distro is not bionic
[08:29] <andyrock> because livepatch it's not supported in non-lts
[08:30] <seb128> livepatch doesn't give you an api to check supported or not?
[08:30] <Laney> oh right
[08:30] <Laney> wouldn't it be better for livepatch to tell you that?
[08:30] <Laney> ha
[08:31] <andyrock> livepatch does not have such API
[08:31] <andyrock> also we would need to install livepatch before to ask
[08:31] <seb128> we should request them to add one :)
[08:31] <seb128> good point
[08:32] <seb128> back to your question, I'm not sure what's the best way to check you are on bionic from C, maybe parsing /etc/os-release?
[08:32] <andyrock> it would be a good idea to had a snap api
[08:33] <seb128> right
[08:33] <andyrock> I'll ask the snap team
[08:42] <didrocks> I wonder if the snap shouldn't be published in the "bionic" channels
[08:42] <didrocks> and not master thus
[08:42] <didrocks> as it doesn't work everywhere
[08:42] <didrocks> and then, you "just" request if the snap is available for you
[08:44] <seb128> didrocks, yeah, I was wondering about that
[08:45] <seb128> but do we have per serie channels?
[08:45] <didrocks> I'm pretty sure that exists. However, I don't know if that's just a convention or it's something bundled
[08:45] <seb128> or do you mean the same we are using for pre-seeded snaps?
[08:45] <seb128> yeah, I don't know how "standard" it is
[08:45] <didrocks> this is what replace "latest" in the track name
[08:45] <didrocks> you have latest/stable/branch-name
[08:46] <didrocks> here, it's release/stable/branch-name for instance
[08:46] <didrocks> I think you have to request for them to open it thouh
[08:46] <didrocks> though
[08:46] <seb128> in any case sounds like something for the snap/livepatch team to solve
[08:46] <didrocks> but that's one year old memory, do not trust me too much :)
[08:46] <didrocks> yeah
[08:46] <seb128> it doesn't make sense to install that snap on bionic
[08:46] <seb128> even from the cli
[08:46] <didrocks> I guess it's something for them to consider
[08:46] <didrocks> you meant on non bionic?
[08:47] <seb128> I meant on cosmic
[08:47] <didrocks> yeah
[08:47] <seb128> I still need to get used to type that one :p
[08:47]  * didrocks has a name for a blog post series
[08:47] <didrocks> "opening the cosmic gate" :)
[08:48] <didrocks> but yeah, basically on non supported distro, you shouldn't be able to install the snap
[08:49] <didrocks> (and then, I'll steal what they do and the transition path from latest to that track for communitheme snap, lalalala)
[08:53] <seb128> (changing location, brb)
[09:10] <willcooke> Trevinho, re: GS Connect.  You said about starting a thread on the hub.  Good idea.  Since you're busy this week, would you like me to start one - or are you happy to wait until you're back to normal working mode?
[09:36] <ads20000> currently there's no way to remove a snap from someone's system, though I suspect the recent miningware incident could change that, perhaps by setting a precedent of refreshing to dummy packages, we'll see... Also maybe the livepatch snap could remain installed but it just won't do anything on non-LTS releases? Though then it is wasting data by refreshing needlessly...
[09:59] <didrocks> I guess not being able to install is the best API for both users not thinking they get it activated and for andyrock to know if LP is available or not
[10:29] <Trevinho> willcooke: it's fine if you start that, no worries
[10:30] <willcooke> Trevinho, will do
[10:30] <Trevinho> thanks
[10:42]  * Laney just got blinded
[10:43] <Laney> the sun crossed some threshold and started reflecting off some glossy paint directly into my eyes
[10:43] <Laney> actually can't see the whole screen
[10:43] <Laney> stupid daystar, turn it off please
[10:43] <ogra_> just take a 12h break and it solves itself :)
[10:44] <Laney> then i'll be in da club partying it up 💃💃💃💃💃💃
[10:44] <Laney> (🛏)
[10:46] <andyrock> daystar lol
[10:48] <seb128> oSoMoN, you are sure you are using the snap for g-s-m? I don't think we/security allowed the opening of help: URIs, or did that change?
[10:48] <seb128> I've a few snaps that hit "user-open error: Supplied URL scheme "help" is not allowed"
[10:48] <seb128> (that's in the journal)
[10:48] <willcooke> Trevinho, done https://community.ubuntu.com/t/gs-connect-as-part-of-18-10/5903
[10:49] <oSoMoN> seb128, d'oh, I wasn't, obviously
[10:50] <seb128> oSoMoN, k
[10:50] <oSoMoN> I'll edit my post
[10:50] <oSoMoN> is there some markup to strike through text
[10:51] <Laney> oSoMoN: ~~ usually
[10:51] <Laney> dunno about discourse tho
[10:52] <oSoMoN> [s] and [/s] (opening and closing tags) in discourse, apparently
[11:50] <oSoMoN> no more chromium updates on trusty: https://community.ubuntu.com/t/chromium-updates-on-trusty/5905
[11:54] <Laney> ⚰️
[13:28] <kenvandine> firefox 60 is in the stable channel
[13:28] <kenvandine> :-D
[13:33] <willcooke> yay
[13:35] <willcooke> oSoMoN, good post, thanks
[13:40] <oSoMoN> cheers
[13:40] <sergiusens> \o/
[13:40] <oSoMoN> kenvandine, speaking of which, can you confirm what I'm seeing with flash? https://forum.snapcraft.io/t/how-do-you-enable-flash-plugin-on-firefox-snap/5376
[13:42] <oSoMoN> gotta go pick up daughter from school, bbiab
[13:58] <jbicha> seb128: hi, could you subscribe the bugs team to tracker-miners and libcue? bug 1770877 bug 1770871
[13:58] <ubot5> bug 1770877 in tracker-miners (Ubuntu) "[MIR] tracker-miners" [Undecided,New] https://launchpad.net/bugs/1770877
[13:58] <ubot5> bug 1770871 in libcue (Ubuntu) "[MIR] libcue" [Undecided,New] https://launchpad.net/bugs/1770871
[13:59] <jbicha> also, except for the patch rename, are these changes fine for bionic? https://launchpad.net/ubuntu/+source/gnome-control-center/1:3.28.1-0ubuntu2
[14:00] <seb128> hey jbicha
[14:02] <seb128> jbicha, looks fine, if you do a SRU can you include the fix for bug #1759468 (https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/40)
[14:02] <ubot5> bug 1759468 in gnome-control-center (Ubuntu) "gnome-control-center (11) gtk_style_context_clear_property_cache → gtk_css_widget_node_update_style → gtk_css_node_ensure_style → gtk_css_node_ensure_style → gtk_css_node_validate_internal" [High,In progress] https://launchpad.net/bugs/1759468
[14:03] <ubot5-ng> seb128: Error: GNOME: Impossible to get infos for GNOME/gnome-control-center issue (Merge request) 40: 'dict' object has no attribute 'username'
[14:05] <jbicha> ok, I didn't see that one, also I was going to see if the commit mentioned on LP: #1766799 fixes our bug too
[14:05] <ubot5> Launchpad bug 1766799 in gnome-control-center (Ubuntu) "gnome-control-center (ERROR) ../shell/cc-panel-list.c → 926 → cc_panel_list_set_active_panel → assertion failed → (data != NULL)" [Low,In progress] https://launchpad.net/bugs/1766799
[14:09] <seb128> jbicha, thanks, yeah that one was also on my list
[14:12] <seb128> jbicha, "    - Drop now unnecessary fonts-ubuntu dependency" ... SRU team doesn't like such change without a bug reference, so best to drop the change or create a bug
[14:13] <jbicha> I've got a bug LP: #1770473 but maybe I'll mention the bug number twice or reformat the changelog :)
[14:13] <ubot5> Launchpad bug 1770473 in gnome-control-center (Ubuntu Bionic) "Don't hardcode Ubuntu font name in Settings > Details" [Low,Triaged] https://launchpad.net/bugs/1770473
[14:13] <seb128> well I guess that's part of the first snippet
[14:13] <seb128> but the changelog doesn't make that obvious
[14:13] <seb128> right
[14:14] <jbicha> mentioning the bug number twice wouldn't hurt if it makes things more clear :)
[14:14] <seb128> right
[14:51] <jbicha> seb128: could you also look at bug 1770146? I guess we should be the subscriber there too (it's replacing libappindicator in main, maybe universe too this cycle)
[14:52] <ubot5> bug 1770146 in libayatana-appindicator (Ubuntu) "[MIR] libayatana-appindicator" [Undecided,New] https://launchpad.net/bugs/1770146
[14:55] <seb128> jbicha, I don't think desktop team has any interest is signing to maintain that stack
[14:56] <seb128> what's the status of having the flavors that use indicators to switch to the ayatana variant?
[15:10] <jbicha> seb128: if the Desktop team won't be the bug subscriber, who will? we do use that library for our main apps that use the GNOME Shell appindicator extension
[15:12] <jbicha> Ubuntu MATE is the primary other user of appindicators, but MIR rules want a Canonical-ish team, right?
[15:12] <seb128> do we? what apps got transitioned?
[15:12] <seb128> well, I want to see other flavors starting using those first before we talk about MIR
[15:12] <jbicha> there are 5 main apps listed in https://wiki.debian.org/Ayatana/IndicatorsTransition#Packages_in_Ubuntu_main_that_need_to_be_ported_a.s.a.p.
[15:12] <seb128> I don't especially agree that the libayatana version is better maintained/tested enough
[15:13] <jbicha> all are waiting in cosmic-proposed for the MIR to be approved
[15:13] <seb128> shrug
[15:13] <seb128> that's doing thing reverse
[15:13] <seb128> also is there a transition plan for the gnome-shell extension? can it talk to apps using both libs at the same time?.
[15:14] <jbicha> I don't know, sometimes people want the packages to show up in component-mismatches to prioritize handling the MIR or something 🤷
[15:14] <seb128> that's not the documented process on the MIR wiki reference
[15:14] <jbicha> last cycle, I was told to do that for some of the MIRs
[15:14] <seb128> I mentioned it to dok_o and slangasek agrees with me
[15:15] <seb128> dok_o is not respecting the process
[15:15] <seb128> (I assume he's the one that asked you that)
[15:15] <seb128> anyway I'm not +1ing that MIR on hand waiving
[15:15] <seb128> ideally that stack would get more testing before we consider that change
[15:15] <jbicha> Locutus did the work for this transition
[15:16] <seb128> right, it doesn't give us any assurance the new codebase isn't crap
[15:16] <seb128> it happens that some people are eager to transition to new things even if they are less good and completly untested
[15:16] <seb128> (I'm not saying in the case there, but I don't know)
[15:16] <jbicha> my understanding is that libayatana-appindicator uses the same D-Bus name as libappindicator and the GNOME Shell extension just displays the stuff so it works just fine with either the Ayatana version or the classic Ubuntu version
[15:17] <jbicha> but I don't have a very deep understanding of indicators at all
[15:17] <seb128> my understanding is that they changed the namespace
[15:17] <seb128> I argued a lot over email with the libayatana maintainer about that
[15:17] <jbicha> I thought so too, but it seems to work right now
[15:17] <seb128> imho that was a stupid thing they did
[15:17] <seb128> maybe they fixed it
[15:18] <seb128> anyway, I'm adding to my queeue
[15:18] <jbicha> I agree with you that the namechange is annoying and even now, they could easily switch to the old library name that apps already use
[15:18] <seb128> but not subscribing us/giving a +1 before we have a proper look
[15:18] <seb128> thanks for pointing it out!
[15:18] <jbicha> I guess part of the complication was that sun_weaver didn't want it to be bound to the CLA
[15:20] <jbicha> and that's a Canonical thing, not much I can do there :)
[15:40] <oSoMoN> chrisccoulson, there's a minor chromium update ready for publication in the stage PPA: 66.0.3359.170 (fixes 3 CVEs)
[15:52] <oSoMoN> Laney, do you know why an octave-interval autopkgtest regression is blocking the migration of chromium-browser? http://autopkgtest.ubuntu.com/packages/o/octave-interval/cosmic/amd64 . I'm not sure where that dependency comes from…
[15:53] <oSoMoN> kenvandine, thanks for confirming the firefox flash issue, I'll file a bug
[15:57] <kenvandine> oSoMoN, maybe it's a gtk version mismatch
[15:57] <kenvandine> since that flash plugin was probably built against a much older gtk
[15:57] <kenvandine> than firefox
[15:58] <oSoMoN> could be, yeah
[15:58] <oSoMoN> kenvandine, but it's working with the deb version of firefox
[15:58] <oSoMoN> which was built against a recent gtk
[15:59] <kenvandine> interesting
[16:00] <kenvandine> the firefox snap is built against the 16.04 gtk
[16:00] <kenvandine> maybe the opposite problem
[16:01] <Laney> oSoMoN: via www-browser in some way probably
[16:02] <oSoMoN> mmm, octave-interval-doc depends on w3m | www-browser, could it be what creates that dependency chain?
[16:03] <oSoMoN> if so that doesn't look right, it's just a doc package that bundles html files
[16:03] <Laney> it depends on something, that means and update to that something could break it
[16:03] <Laney> s/and/an/
[16:04] <oSoMoN> Laney, I understand the logic, but then all doc packages in the archive could depend on www-browser, and every single update would trigger an autopkgtest run of chromium-browser
[16:05] <oSoMoN> that seems like a waste of resources
[16:05] <Laney> it's the other way around
[16:05] <Laney> and clearly you don't see a million tests running there, so it is not that
[16:06] <oSoMoN> right, it's the other way around indeed, so maybe it's just octave declaring that dependency on a browser for its doc package, and it shouldn't? 
[16:06] <oSoMoN> kenvandine, I'll check with the firefox deb in a xenial VM
[16:10] <oSoMoN> it works there, maybe I need to unpack the so from the xenial package to get it working
[16:12] <jbicha> html -doc packages shouldn't depend on (or even recommend) a web browser IMO
[16:12] <oSoMoN> I agree
=== pstolowski is now known as pstolowski|afk
[16:15] <oSoMoN> kenvandine, flash content corrupted when rendered in snap with flash plugin extracted from xenial deb, most likely because the version of gtk on xenial doesn't match the one in the gnome-3-26 PPA
[16:18] <oSoMoN> kenvandine, https://bugzilla.mozilla.org/show_bug.cgi?id=1461363
[16:18] <ubot5> Mozilla bug 1461363 in Untriaged "[snap] flash plugin content not rendered" [Normal,Unconfirmed]
[16:27] <kenvandine> oSoMoN, the firefox snap doesn't build against the PPA
[16:27] <kenvandine> it's against xenial proper
[16:29] <Laney> oSoMoN: that actually needed an update of autodep8; done, please retry all except for armhf which I used to test
[16:29] <Laney> also
[16:29] <oSoMoN> Laney, thanks
[16:29] <Laney> did you guys figure out that segfault problem with the desktop launcher?
[16:30] <oSoMoN> kenvandine, weird, because the firefox deb in xenial renders flash content fine, but the snap doesn't (using the flash plugin lib extracted from the xenial package)
[16:33] <kenvandine> Laney, i don't think so
[16:35] <Laney> blast
[16:35] <Laney> was hoping to hear the cool reason
[16:36] <kenvandine> Laney, in theory your reference to /lib/x86_64-linux-gnu/libdl.so.2 should actually be coming from core not your host system
[16:36] <kenvandine> unless that's not true for classic snaps
[16:36] <kenvandine> but i think it should be true
[16:36] <Laney> it does
[16:36] <Laney> you can check that with ldd
[16:37] <kenvandine> it does come from core right?
[16:37] <Laney> yep
[16:37] <Laney> but then you can preload the host one to make it use that and it starts working
[16:37] <Laney> which is weird but I didn't try anything more than that
[16:37] <kenvandine> very weird
[16:37] <kenvandine> and concerning
[16:38] <Laney> that's just running the thing from /snap directly on my system btw
[16:38] <kenvandine> ah
[16:38] <Laney> but it still segfaults like that
[16:39] <oSoMoN> jbicha, FYI https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898646
[16:39] <ubot5> Debian bug 898646 in octave-interval-doc "octave-interval-doc: doc package should not depend on a web browser" [Minor,Open]
[16:58] <oSoMoN> jbicha, that was quick: https://salsa.debian.org/pkg-octave-team/octave-interval/commit/29d526d21876ff43bfe2e939e6723c63837685c4 :)
[17:37] <oSoMoN> alrighty, I'm done for today, have a good evening / rest of the day everyone!
[18:56] <willcooke> night
[23:03] <jbicha> https://feaneron.com/2018/05/14/improving-the-development-experience-for-gnome-settings/