  We don't get much real snow any more :(
[09:09] <willcooke> morning seb128
[09:10] <hikiko> hi Laney willcooke desrt seb128 flexiondotorg
[09:10] <willcooke> hey hikiko!
[09:11] <desrt> willcooke, hikiko: welcome to the morning quadratic workout
[09:11] <willcooke> :))
[09:11] <flexiondotorg> Morning willcooke Laney desrt seb128
[09:11] <willcooke> yo flexiondotorg!
[09:11]  * hikiko google trandlates
[09:11] <Laney> ./greet-people
[09:11] <Laney> ./how-are-you
[09:11] <desrt> hikiko: "quadratic" as in O(n^2)
[09:12] <hikiko> lol
[09:17] <davmor2> Morning all
[09:18] <seb128> bah, I created a role account for launchpad uploads
[09:18] <seb128> but launchpad oops when I try to log in with it :-/
[09:18] <willcooke> hi davmor2 - any snow up your end?
[09:18] <seb128> hey davmor2
[09:19] <davmor2> willcooke: don't be daft the rest of the Country needs to be waist deep before it ventures into wolverhampton ;)
[09:19] <willcooke> :)
[09:23] <seb128> english people, how do you call that http://www.bricorama.fr/media/catalog/product/2/7/2771151-1.jpg ... is that a "foam seal"?
[09:23] <duflu> seb128: Yes
[09:23] <duflu> Useful for everything
[09:23] <duflu> almost
[09:23] <seb128> duflu, hey, thanks!
[09:24] <davmor2> duflu: no now you are mistaking it for duck tape ;)
[09:24] <duflu> Also useful, regardless of spelling
[09:25] <duflu> or name otherwise
[09:25] <duflu> Ducks are also musical
[09:25] <duflu> https://www.youtube.com/watch?v=zTijW72owNk
[09:26] <davmor2> seb128: yeap foam seal is as good a term and any, Foam seal, insulating strips, sealing tape just don't confuse it with foam pads which looks similar but is little cubes of it rather than a long strip
[09:26] <davmor2> duflu: duct even thanks for the heads up ;)
[09:26] <seb128> thanks
[09:31] <Laney> seb128: you had to make a new user?
[09:32] <seb128> Laney, Colin suggested I do, p_itti had the upload key assigned to his users but it means the key has more priviledge than it should
[09:32] <Laney> oh
[09:32] <Laney> it was a trick so he could get all the karma!
[09:32] <seb128> :-)
[09:33] <seb128> also uploads stopped working because he removed himself from that team
[09:33] <seb128> don't want to repeat that with the next person
[09:35] <Laney> makes sense
[09:46] <Laney> Get:71 http://archive.ubuntu.com/ubuntu zesty/main amd64 openjdk-8-jre-headless amd64 8u121-b13-3 [27.5 MB]
[09:46] <Laney> Get:72 http://archive.ubuntu.com/ubuntu zesty/universe amd64 openjdk-9-jre-headless amd64 9~b155-1 [109 MB]
[09:46] <Laney> what an update
[10:46] <Trevinho> hey Laney... it's snowing here tooo
[10:46] <Trevinho> seb128: hey dude..
[10:46] <seb128> hey Trevinho
[10:46] <Trevinho> seb128: did you see my pings of last night?
[10:46] <seb128> no
[10:46] <Trevinho> check the log :-)
[10:46] <seb128> I close IRC at night
[10:47] <Trevinho> night... it was before dinner ...
[10:47] <Trevinho> I mean you were here
[10:47] <Laney> hey Trevinho
[10:47] <Trevinho> at leat your client was
[10:47] <Laney> is it settling on the ground?
[10:47] <Trevinho> Laney: not in the city, but I see it in the hills nearby
[10:47] <Laney> nice
[10:48] <seb128> Trevinho, the mp?
[10:48] <Trevinho> seb128: anyway just to resume, please merge https://code.launchpad.net/~3v1n0/+junk/snap-gnome-udt@split-parts+indicators-support to the DT branch :-)
[10:48] <seb128> Trevinho, oh, that I read
[10:48] <Trevinho> and do the renaming you need so that we can adjust the tools too
[10:48] <seb128> I didn't understand why you were spliting the dependencies list
[10:49] <Trevinho> seb128: to make it easier to read
[10:49] <Trevinho> just a logical split
[10:49] <seb128> also we don't include unity libs
[10:49] <seb128> we said in DenHaag that we wanted a GNOME stack only there
[10:49] <Trevinho> seb128: you're including unity-gtk-module, isn't it?
[10:49] <seb128> so unsure why we would add the indicators
[10:49] <Trevinho> well, libappindicator isn't only unity related
[10:49] <Trevinho> also xfce uses that
[10:50] <Trevinho> and I think elementary and mate?
[10:50] <seb128> well it's not GNOME
[10:50] <Trevinho> mh, that would just make easier to snap apps that work in ubuntu tho
[10:50] <Trevinho> as we can't have a runtime that overides that too, isn't it?
[10:50] <seb128> what is that indicator part doing?
[10:51] <Trevinho> seb128: https://github.com/3v1n0/appindicators-snapcraft-parts/blob/master/snapcraft.yaml#L88
[10:55] <seb128> Trevinho, so it builds libappindicator from source ... why would we do that and not use the debs like we do for everything else?
[10:56] <Trevinho> it basically just adds http://paste.ubuntu.com/23966123/ (minus header and .so files)
[10:56] <Trevinho> seb128: because the debs in xenial doesn't support snap properly
[10:56] <Trevinho> Maybe we should SRU the fixes, but not there yet
[10:57] <seb128> yeah we should
[11:04] <Trevinho> not sure the test case would be easy tho, as if we enable proposed in system, will they be used by snapcraft too? :o
[11:04] <seb128> yes
[11:05] <seb128> Trevinho, I've no strong opinion either way, but ideally we would build everything the same way, either from debs or source
[11:06] <seb128> Trevinho, if there is anything blocked/not working due to that we can merge your changes as workaround and tweak later
[11:07] <Trevinho> seb128: indicators won't work without it... unless apps won't define themselves after: indicator-gtk3...
[11:08] <Trevinho> which is fine, but still needs more tweaking, while i'd prefer app writers to have all things in one place as this is quite standard for ubuntu based distros
[11:08] <Trevinho> ah, of course... also kde needs that
[11:09] <seb128> Trevinho, which is easy to do, and we don't have that much apps using indicators...
[11:10] <Trevinho> yeah, sure... I proposed that since didrocks suggested it in a PR (https://github.com/ubuntu/snapcraft-desktop-helpers/pull/36)
[11:10] <seb128> k
[11:10] <Trevinho> as we agree'd on getting that for desktop launchers by default
[11:10] <Trevinho> so...
[11:10] <seb128> Trevinho, I'm going for lunch for let me have another look once I'm back
[11:11] <Trevinho> I can either set it only a dependency of the gnome-runtime at that level
[11:11] <Trevinho> so the desktop-launcher has dependency on that, instead of the runtime itself
[11:11] <didrocks> yeah, I'm still waiting on your answer on this PR :)
[11:11] <didrocks> but
[11:12] <didrocks> I don't remember why this isn't part of this part itself
[11:12] <didrocks> and rather it's a dep
[12:27] <Trevinho> didrocks: sorry I had to take a train....
[12:27] <Trevinho> didrocks: anyway...
[12:28] <Trevinho> yeah.. That's the thing I would rather prefer to include everything in the runtime more than adding "after:" stanza's
[12:28] <Trevinho> actually also the qt5 runtime has the needed elements to support unity...
[12:28] <Trevinho> well, appmenu in fact.
[12:31] <Trevinho> didrocks: also I update the PR for gnome runtime thing, let's sync with seb128 when pushing new snap with proper name and such...
[12:32] <Trevinho> didrocks: by the way the remote part should do more I believe, like creating the ./gnome-runtime folder or s/runtime/platform if prefrred..
[12:55] <Trevinho> didrocks: I've done that using the "install:" stanza... In fact some stuff could be now done also by just using 'prepare:' or 'install:', not sure you like that more than Makefile's tho
[13:17] <didrocks> Trevinho: agreed on merging indicator in runtime then!
[13:17] <didrocks> Trevinho: hum, creating the dir, there is an issue, right?
[13:18] <didrocks> like $SNAP is ro
[13:18] <didrocks> wait, what's the install stenza?
[13:18] <didrocks> ah, I see what you mean
[13:18] <didrocks> as part of the part, at build time
[13:18] <didrocks> clever Trevinho ;)
[13:19] <didrocks> hum, it means it would need a custom plugin, though
[13:19] <didrocks> we can make it as part of make parameter
[13:19] <didrocks> but yeah, I like your idea :)
[13:19] <Trevinho> didrocks: yeah, I didn't want to clutter the makefile with something that is only related to that
[13:20] <Trevinho> and.. those new tools are nice for such things
[13:20] <didrocks> Trevinho: well, it's a variable
[13:20] <didrocks> so if present -> mkdir -p it
[13:20] <didrocks> as for FLAVOR
[13:20] <didrocks> let's separate this in another PR, agreed?
[13:20] <didrocks> (the creation thing)
[13:20] <didrocks> on the current one, I have few comments
[13:20] <didrocks> prefer doing it here or on the PR?
[13:20] <Trevinho> as you prefer... I can stash that commit for later :-)
[13:21] <didrocks> yeah, stash it :)
[13:21] <Trevinho> I'd keep it here as i's just one line..
[13:21] <Trevinho> but...
[13:21] <didrocks> snap connect $SNAP_NAME:gnome318-platform gnome318-udt:gnome318-platform
[13:21] <Trevinho> I would have loved to avoid defining the gnome-runtime multiple times too, so if we change it's not something we've to redo lods of times
[13:21] <didrocks> -> I would prefer now that we try to be consistent with qt to name it "platform"
[13:21] <didrocks> so gnome318-udt:platform
[13:21] <Trevinho> indeed... it's just that we need to update the snap too
[13:21] <didrocks> same for $SNAP_NAME:gnome318-platform -> $SNAP_NAME:platform
[13:22] <didrocks> yeah :)
[13:22] <Trevinho> otherwise that would fail
[13:22] <didrocks> we'll need anyway
[13:22] <Trevinho> seeeeb :-)
[13:22] <didrocks> for s/runtime/platform/
[13:22] <Trevinho> I whish I had write permission in the ~desktop-team stuff
[13:22] <didrocks> you don't?
[13:22] <Trevinho> of maybe seb would disagree :-)
[13:22] <didrocks> you don't have upload rights?
[13:22] <didrocks> I thought you have on the desktop team bucket
[13:22] <didrocks> I can do, but I have meetings this afternoon
[13:23] <Trevinho> nope... I still have to conquer those... seb128 wanted to do something, but... still he gave me no news on that
[13:24] <Trevinho> https://code.launchpad.net/~3v1n0/+junk/snap-gnome-udt@split-parts+indicators-support is also something I'd do, or we prefer to add the after: stuff in the gnome-platform remote part?
[13:24] <Trevinho> As personally I think that it's just better to ship this integration stuff inside the runtime, so people has not to repackage it multiple times and... we can update it independently from apps
[13:24] <didrocks> yeah, let's get it inside the runtime
[13:24] <didrocks> however, can you add it to other parts?
[13:24] <didrocks> like gtk3, qt…
[13:25] <didrocks> the ones that don't use any platform snap
[13:25] <Trevinho> I've the PR theat I linked before...
[13:25] <Trevinho> that's doing it
[13:25] <Trevinho> that*
[13:25] <didrocks> isn't that adding after:?
[13:25] <Trevinho> yeah, what you meant, sorry?
[13:26] <didrocks> no, I meant, let's get that inside the part
[13:26] <didrocks> not defining another part
[13:26] <Trevinho> ah... since it's compiling stuff, it would make things more cluttered
[13:26] <didrocks> I mean, this should just be part of desktop-launcher
[13:26] <didrocks> hum
[13:26] <Trevinho> we can do it later once I've SRUed the changes
[13:26] <didrocks> well, depending on it will ask to compile it anyway?
[13:26] <Trevinho> to xenial
[13:26] <didrocks> ok
[13:26] <Trevinho> sure... I fixed snapcraft for that
[13:27] <didrocks> yeah, but you know how it ends up with deps :)
[13:27] <Trevinho> also that is independent from desktop-launcher...
[13:27] <Trevinho> sure, you can still redefine those
[13:27] <didrocks> why should it be?
[13:27] <didrocks> it's all one block "run my snap on the desktop"
[13:27] <didrocks> and integrate it
[13:27] <Trevinho> sure, i mean... indicators can be used independently
[13:27] <didrocks> hem :)
[13:27] <Trevinho> see https://github.com/3v1n0/indicators-examples-snaps
[13:27] <didrocks> a non desktop app using indicators?
[13:28] <didrocks> they all deps on a toolkit
[13:28] <didrocks> but let's keep that separate and finish that PR first
[13:28] <Trevinho> I'd still need to use after anyway... So I'd keep them remote for now
[13:28] <didrocks> I'm quite opposed to "after:"
[13:28] <Trevinho> then I'll SRU and we'll just add the deps
[13:28] <didrocks> let's finish that one: change plug name and slot name to be "platform"
[13:28] <Trevinho> ok=
[13:28] <didrocks> yeah ;)
[13:29] <seb128> Trevinho, let me know if you need help with the SRU
[13:29] <didrocks> help/connect message
[13:29] <didrocks> and then, we sync that with the platform snap upload
[13:29] <Trevinho> seb128: i'm preparing the branches for bileto now...
[13:30] <didrocks> (remove the install for now, I keep a note on doing it separetely, that's a great idea)
[13:31] <seb128> Trevinho, didrocks, did you agree on something?
[13:31] <didrocks> seb128: yeah, let's have plug/slot name being "platform"
[13:32] <didrocks> and mount point gnome-platform
[13:32] <seb128> hum?
[13:32] <seb128> didn't we agree that we needed the plug to be versioned?
[13:32] <didrocks> the interface is versioned
[13:33] <didrocks> like content:
[13:33] <seb128> "interface"?
[13:33] <didrocks> (in a meeting)
[13:33] <Trevinho> didrocks: I pushed the change
[13:34] <didrocks> Trevinho: you didn't push strongly enough it seems :)
[13:34] <didrocks> still at https://github.com/ubuntu/snapcraft-desktop-helpers/pull/46/commits/2289e89d49bc86f2d4a9308846526cc4f137f18e
[13:35] <Trevinho> didrocks: ah, you don't want that too?
[13:35] <Trevinho> I mean, I removed the install thing
[13:35] <didrocks> ok, let me build on yours
[13:35] <didrocks> after the meeting
[13:35] <didrocks> that will be quicker
[13:36] <didrocks> you didn't get the renaming thing :)
[13:36] <Trevinho> what's missing :o
[13:36] <didrocks> as written
[13:36] <didrocks> let's rename the plug and slot to simply "platform"
[13:36] <didrocks> +    echo "snap connect $SNAP_NAME:gnome318-platform gnome318-udt:gnome318-platform"
[13:36] <didrocks> -> snap connect $SNAP_NAME:platform gnome318-udt:platform
[13:36] <Trevinho> ahhhhh
[13:36] <Trevinho> ok
[13:36] <didrocks> we don't need versioning here, because:
[13:37] <didrocks> - the platform snap is versioned
[13:37] <didrocks> - and the version is forced by +                content: gnome318-platform
[13:37] <didrocks> on both side
[13:37] <didrocks> making sense?
[13:37] <didrocks> seb128: as well? ^
[13:37] <Trevinho> sure
[13:39] <seb128> didrocks, Trevinho, sorry but I don't follow, what prevents somebody to "snap connect $SNAP_NAME:platform gnome319-udt:platform"?
[13:39] <seb128> if the content name is not versioned
[13:41] <didrocks> seb128: the content name is versioned
[13:41] <Trevinho> seb128: I guess that default-provider: gnome318-udt:platform does that
[13:41] <didrocks> gnome318-platform
[13:41] <didrocks> no?
[13:41] <didrocks> both end needs to agree on the naming
[13:42] <seb128> didrocks, isn't the first part the name of the snap and the second the content?
[13:42] <seb128> didrocks, like "platform" would be the content there
[13:43] <didrocks> seb128: sorry, can't follow the discussion in this meeting, will have few minutes in ~45m
[13:43] <didrocks> seb128: but no
[13:43] <didrocks> seb128: first part is snap name
[13:43] <didrocks> second is the plug name
[13:43] <seb128> right
[13:44] <seb128> didrocks, let's talk after your meeting
[13:44] <didrocks> yep :)
[13:44] <seb128> the content interface is confusing to me, nothing new
[13:44] <seb128> I keep mixing the content, slot, provider, et
[13:44] <seb128> etc
[13:53] <Trevinho> muktupavels: hey, are you here?
[13:53] <muktupavels> Trevinho: yes :)
[13:54] <Trevinho> muktupavels: good :-)
[13:55] <Trevinho> muktupavels: hey, do you remember the rationale for https://code.launchpad.net/~muktupavels/libappindicator/watch-status-notifier-watcher-dbus-name/+merge/298533
[13:55] <Trevinho> ?
[13:55] <Trevinho> and... would you like to get that SRUed to xenial...?
[13:55] <Trevinho> if so... I'd need a bug for that :-)
[13:56] <muktupavels> Not sure if I remember...
[13:56] <Trevinho> mh :-)
[13:57] <muktupavels> why do you want to sru it?
[13:57] <Trevinho> I don't want to, but since I've to do a release for libappindicator, I was wondering weather that was needed or not
[13:57] <mitya57> Trevinho, muktupavels: if for some reason indicator-application-service dies and restarts, the indicators should recover. That was the rationale.
[13:58] <Trevinho> yeah, that is somehing that I was wondering to, but it generally did that anyway isn't it?
[13:58] <muktupavels> mitya57: and it did not work before that, right?
[13:58] <mitya57> Yes, I think it didn't work.
[13:58] <Trevinho> however, let me look at the code further and... in the case, please mitya57 can you opena  bug with SRU headers please? :-)
[13:59] <mitya57> Trevinho, Actually I wanted to say that i-a-s rarely crashes (if at all), so maybe it's not worth a SRU
[13:59] <Trevinho> ok
[14:00] <Trevinho> as you guys prefer
[14:00] <Trevinho> thanks
[14:27] <Sweet5hark> seb128: libreoffice <IP_ADDRESS>/zesty has been in the ppa for some time w/o any issues. it still has needs some tweaks for the final (e.g. move some externals from internal tarball to use dpkgs), but that can be done later still.
[14:27] <seb128> hey Sweet5hark
[14:28] <Blu2_> Sweet5hark, are you maintaining the libre office snap?
[14:28] <Sweet5hark> seb128: would you be fine with e.g. uploading today, so it can build over the weekend?
[14:28] <seb128> Sweet5hark, uploading to zesty sounds good to me ... I guess you didn't reapply to the dmb yet? ;-)
[14:28] <seb128> Sweet5hark, yes
[14:28] <ricotz> Sweet5hark, hi, there are still transitional packages missing, and/or firebird re-enablement
[14:28] <Sweet5hark> Blu2_: yes
[14:30] <Blu2_> Sweet5hark, I recently noticed after installing the libre office snap, that I can't access my files which are in my symlinked folder (on seperate hdd)
[14:30] <ricotz> Sweet5hark, fyi https://launchpadlibrarian.net/305238964/libreoffice_1%3A5.3.0~rc3-0ubuntu1~yakkety1_1%3A5.3.0~rc3-0ubuntu1~yakkety1.1.diff.gz (don't apply it like that though)
[14:32] <Sweet5hark> Blu2_: if that symlinked folder isnt in home, that is a Feature(tm) of snap. It has little to do with LibreOffice, and everything with the containerization. Maybe discuss with the friendly folks at #snappy?
[14:35] <seb128> Sweet5hark, let me know when there is something ready for sponsoring
[14:35] <Sweet5hark> seb128: will do
[14:36] <Sweet5hark> ricotz: meh, yeah. human transitional is easy. lemme check the firebird stuff ...
[14:37] <ricotz> Sweet5hark, I guess the human transitional should pull in some other available theme package
[14:37] <ricotz> Sweet5hark, also libreoffice-sdbc-firebird is recommended while not being available
[14:38] <Sweet5hark> ricotz: hmm, why? the stuff using human should have proper deps ...
[14:38] <ricotz> Sweet5hark, and the mariadb vs mysql mentioned
[14:39] <ricotz> Sweet5hark, just a thought to forcefully install something instead having the user endup without any
[14:39] <ricotz> the transisional is empty of course ;(
[14:39] <ricotz> ;)
[14:40] <ricotz> Sweet5hark, https://paste.debian.net/plain/913697
[14:42] <Sweet5hark> ricotz: libreoffice-common deps on libreoffice-style, libreoffice-gtk3 does dep on libreoffice-styles. its unlikely you end up with libreoffice but without a theme
[14:43] <Blu2_> Sweet5hark, they sent me here :D
[14:43] <ricotz> Sweet5hark, right, hehe libreoffice-common suggests human
[14:47] <Sweet5hark> Blu2_: snaps are contained and the snappy folks are very proud of that. IIRC you can install snaps with --devmode, than you are not containered, which makes people unhappy. Anyway, this has nothing to do with the app and everything with snaps: so its wrong for this channel.
[14:48] <ricotz> Sweet5hark, please take note of those things, I don't want to mention it a fourth time
[14:49] <Sweet5hark> Blu2_: again: its not an accident this is the case, it its intentional and by design of snap. if you want to discuss it, discuss it with the snap people. nothing about libreoffice causes this, nothing in libreoffice can "fix" it. only snap can.
[15:04] <Sweet5hark> ricotz: what your beef with mariadb to create delta vs. Debian?
[15:09] <ricotz> Sweet5hark, it is delta to the current ubuntu packaging which looked important and if mysql is still the default(?) it seems better to keep -- using "default" here seems fuzzy imho
[15:10] <ricotz> haha, don't suggest you actually care about delta with debian ;)
[15:11] <Sweet5hark> ricotz: well, of course its a delta to previous Ubuntu: it was an intentional change by Rene. So I am basically asking: why do you think Rene was wrong?
[15:12] <ricotz> Sweet5hark, huh, I am *not* saying he/debian is wrong, I am just not aware of the situation of mariadb vs mysql in ubuntu
[15:13] <ricotz> (I am applying this for the backports to make sure keeping it mysql flavoured)
[15:13] <Sweet5hark> ricotz: well, unless we _know_ it is a problem, we will keep with what Debian does for new releases.
[15:13] <Sweet5hark> ricotz: but fine for backport (only) of course
[15:14] <Sweet5hark> no need to xkcd927 this more than needed.
[15:17] <ricotz> Sweet5hark, fyi, mariadb is in universe and mysql in main, which likely suggests something
[15:18] <Sweet5hark> ricotz: heh, now _thats_ and argument ;)
[15:18]  * Sweet5hark changes back to mysql.
[15:25] <Sweet5hark> well, checking back with _rene_. the main motive seems to be to use the internal build, not mysql-vs.-mariadb. in that case it might make sense. Also an internal mysql-cppconn wont cause new deps.
[15:25] <Sweet5hark> ricotz: ^^
[15:30] <didrocks> seb128: sooooooo
[15:30] <seb128> :-)
[15:30] <didrocks> seb128: content interface is a little bit special
[15:31] <didrocks> as any other interface, you have a slot/plug
[15:31] <didrocks> they can differ on both side
[15:31] <didrocks> but I think we should name them "platform"
[15:31] <didrocks> so that connect is:
[15:31] <didrocks> foo-app:platform gnome318-udt:platform
[15:31] <didrocks> for them to be able to connect
[15:31] <didrocks> they need to have a matching "content: <name>"
[15:32] <didrocks> content: gnome318-platform
[15:32] <didrocks> or even just content: gnome318
[15:32] <didrocks> for instance
[15:33] <seb128> so you have 3 parameters there?
[15:33] <didrocks> (yeah, I dislike the "content" term, it should be "type")
[15:33] <didrocks> right
 and a content which is not specified?
[15:33] <didrocks> yeah, content is in the plug and slot definition
[15:33] <didrocks> https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/snapcraft.yaml#L37
[15:33] <seb128> so why did you ask me to version the plugname back then?
[15:34] <didrocks> (you have a 4th parameter in the plug, which is target: path)
[15:34] <seb128> I had "gnome-runtime" in a first iteration
[15:34] <seb128> I think you asked me to add the version in a review round
[15:34]  * seb128 reads old logs
[15:34] <didrocks> seb128: I think I did for the content, then, I probably wasn't clear because of being tired (it was after some sleepless night after my child was born IIRC :p)
[15:35] <didrocks> so sorry for creating this misunderstanding/mistake
[15:35] <seb128> no, we did that in december
[15:35] <didrocks> oh really?
[15:35] <seb128> it's probably my fault
[15:35] <didrocks> I don't remember, my memory is all foggy :)
[15:35] <seb128> but I don't really understand
[15:36] <seb128> the gnome runtime snapcraft.yaml has only 1 name
[15:36] <seb128> slots:
[15:36] <seb128>     content:
[15:36] <seb128>       content: gnome318-runtime
[15:36] <didrocks> euh
[15:36] <didrocks> are you sure?
[15:36] <seb128> yes
[15:36] <didrocks> I don't understand the second line "content:"
[15:36] <didrocks> it's the slot name
[15:37] <didrocks> it should be gnome318-runtime from the current doc
[15:37] <didrocks> (and so, we want to change it to "platform")
[15:37] <seb128> sorry I opened an old version on disk
[15:37] <didrocks> phew
[15:37] <seb128> but that worked
[15:37] <seb128> iirc?
[15:37] <didrocks> with a different connect command
[15:37] <seb128> Kyle recommended to use "content" as the slot name because that way you don't need to add a "interface: content" line
[15:38] <didrocks> I slightely disagree to this, I think ease of use for the user is better
[15:38] <seb128> it's confusing though
[15:38] <didrocks> and knowing that slot and plug name would be "platform" for platform snaps help
[15:38] <seb128> current version is
[15:39] <seb128> slots:
[15:39] <seb128>     gnome318-runtime:
[15:39] <seb128>       interface: content
[15:39] <seb128>       content: gnome318-runtime
[15:39] <seb128>       read:
[15:39] <seb128>         - /
[15:39] <seb128>
[15:39] <seb128> so you get 2 labels which are the same but not the same
[15:39] <didrocks> yeah, that matches the instructions we got
[15:39] <didrocks> right, that's what I want to remove
[15:39] <didrocks> having line 2 "platform:"
[15:40] <seb128> so what is the "content" about?
[15:40] <didrocks> the content is what both slots/plugs needs to match to be able to connect
[15:40] <didrocks> it's the "type" of content if you prefer
[15:40] <didrocks> I would set this to "content: gnome318" if it was me
[15:40] <seb128> k
[15:40] <seb128> I don't understand snappy there
[15:40] <didrocks> so, if you have an app with content: gnome320, it won't connect to gnome318-udt snap
[15:41] <seb128> why do you need content to match
[15:41] <seb128> you connect to an content interface which as a name
[15:41] <seb128> the combo snap_name/slot_name should be unique
[15:41] <didrocks> yeah, I raised my concern on the spec doc about that
[15:41] <didrocks> they decided another way
[15:41] <didrocks> and that the ABI is on "content"
[15:42] <seb128> so the ABI is not exposed at connect time?
[15:42] <didrocks> nope, it's just ensured it matches though
[15:42] <didrocks> but not displayed in the command line
[15:42] <seb128> the issue I've with "platform" is that the connect line doesn't tell you what API you connect to
[15:42] <didrocks> well, you know what API you connect to
[15:42] <seb128> you connect to "platform" but don't know what is behind then
[15:43] <didrocks> from the snap platform name
[15:43] <seb128> unless you open the snapcraft
[15:43] <didrocks> gnome318-udt
[15:43] <seb128> well, as an user I've no clue if that provides the right thing
[15:43] <didrocks> nope
[15:43] <seb128> or what it provides
[15:43] <didrocks> neither naming the same will tell you
[15:43] <didrocks> it will be even worse
[15:43] <didrocks> you will think it's what should match
[15:43] <didrocks> but it won't
[15:44] <didrocks> (or it won't necesarrily)
[15:45] <seb128> I'm concerned that some user are going to think "ok, so it wants a platform, gnome320 has one as well, let's try how it works with 320 and connect to that one instead"
[15:45] <seb128> since they both provide a "platform" slot
[15:45] <didrocks> well
[15:45] <didrocks> the error message should tell you the content doesn't match
[15:45] <seb128> and then get confused
[15:45] <didrocks> I hope it does :)
[15:45] <didrocks> you can try, did you upload a snap working with your platform?
[15:46] <seb128> not yet, I've local builds though
[15:46] <seb128> but even if the error is clear
[15:46] <seb128> I'm not sure it's not going to confuse users?
[15:46] <didrocks> I start to wonder if it was me asking you to put the version in the slot or if you didn't yourself :)
[15:46] <didrocks> well, I find it confusing that in the same line, you set the same version 3 times, don't you?
[15:47] <seb128> yeah
[15:47] <didrocks> and even with that, you are not sure that content: will match
[15:47] <didrocks> so it's even more confusing if it doesn't
[15:47] <didrocks> let me see the error message
[15:47] <seb128> well if as a convention we use slot_name = content_name it's less ambigious
[15:47] <seb128> then you can have e.g gnome-xenial:gnome318-platform
[15:47] <didrocks> you can say snap_name = content_name
[15:48] <didrocks> which is what you did already
[15:48] <didrocks> (platform snap)
[15:49] <seb128> didrocks, reading the log you hinted that I should version the "content" indeed
[15:49] <seb128> I just got confused that we have a label for the slot and one for the content
[15:50] <didrocks> ahah!
[15:50] <didrocks> I'm not *that* inconsistent :)
[15:50] <didrocks> I'm trying to connect things that shouldn't
[15:50] <didrocks> one sec
[15:50] <seb128> didrocks, ok, so yeah, "platform" wfm, I still find it confusing but it's the snappy way which is (the 3 objects rather than 2), not something we can fix from that platform example
[15:50] <seb128> k
[15:51] <didrocks> waow
[15:51] <didrocks> we have autoconnects it seems now
[15:51] <didrocks> at least, for kde apps
[15:51] <seb128> needs to be set/flagged on the store side I think
[15:51] <didrocks> yeah
[15:51] <seb128> but yeah, if you know who to ask they can do it
[15:52] <didrocks> hum
[15:52] <didrocks> ubuntu-app-platform:platform            kbruch:kde-frameworks-5-plug
[15:52] <didrocks> I was able to connect…
[15:52] <didrocks> plugs:
[15:52] <didrocks>   kde-frameworks-5-plug:
[15:52] <didrocks>     content: kde-frameworks-5-all
[15:52] <didrocks> nice
[15:52] <didrocks> a new bug I think
[15:56] <didrocks> seb128: ok, look at #snappy
[15:56] <didrocks> known bug
[15:57] <didrocks> due to that, you almost convinced me of versionning the slot/plug name :p
[15:58] <seb128> lol
[15:59] <didrocks> oh man…
[15:59] <didrocks> so, rereading the spec
[15:59] <didrocks> you can avoid declaring "content:"
[15:59] <didrocks> if it matches plug name
[15:59] <didrocks> that could worth the addition
[15:59] <seb128> right, that was my example before
[15:59] <didrocks> well
[15:59] <didrocks> we did define content: still
[16:00] <didrocks> it seems you can just skip it this way
[16:00] <didrocks> from the spec
[16:00] <didrocks> to be tested, see what happens on enforcing the name…
[16:00] <seb128> oh ok
[16:00] <Trevinho> sorry, my train connection was too weak to follow the discussion... moved to 4g now...
[16:00] <Trevinho> so... what's the final decision? :-)
[16:00] <didrocks> Trevinho: no worry, no decision yet
[16:00] <didrocks> seb128: do you mind testing removing content: on both side?
[16:01] <didrocks> or I can on Monday
[16:01] <didrocks> and that way, we version the plug/slot name
[16:01] <didrocks> and just name it "gnome318-platform"
[16:03] <seb128> didrocks, I can try in a bit, but we can continue on monday ... though that would still mean duplication of versions on the command line which we didn't like
[16:03] <didrocks> yeah
[16:03] <seb128> didrocks, Trevinho, in fact I think I don't care much either way
[16:03] <seb128> so whatever you guys prefer is fine
[16:03] <didrocks> let's go with duplication, removing content:
[16:03] <didrocks> but ensuring it works first
[16:03] <seb128> k
[16:03] <seb128> it's 5pm on a friday anyway
[16:04] <didrocks> yeah :)
[16:04] <seb128> so let's test properly and land on monday
[16:04] <didrocks> Trevinho: if you want to prepare it. Remove "content:" line in help, plug-name is "gnome318-platform"
[16:04] <didrocks> not going to be merged right away
[16:04] <didrocks> this is the decision, if it works :)
[16:04] <seb128> :-)
[16:04] <Trevinho> ok
[16:06] <Trevinho> I'm in the SRU stuff now...
[16:07] <didrocks> yeah, no hurry!
[16:08] <Sweet5hark> ricotz: hmm, why "firebird reenablement"? AFAICS we had firebird disabled in 5.2 as well, so no change there?
[16:25] <willcooke> SNOWING!
[16:27] <Laney> get out there quick
[16:27] <Laney> it'll be gone
[16:27] <willcooke> :@(
[16:27] <willcooke> sad snowman
[16:27] <willcooke> maybe :^(
[16:30] <ricotz> Sweet5hark, right, so just a transitional needed while the previous empty package got dropped
[16:38] <xnox> willcooke, https://www.facebook.com/plugins/post.php?href=https%3A%2F%2Fwww.facebook.com%2Fsoverybritish%2Fposts%2F1273931125988106&width=500
[16:38] <Trevinho> LOL, I thought my laptop was becoming crazy, since without no reason from time to time it was writing stuff by itself.... After looking at all the software options I had in mind... I figured out that I had a bluetooth keyboard in my backpack...  I don't understand what's wrong on the langpack instance/how to fix it
[17:41] <Laney> look at /var/log/uptrack/
[17:41] <Laney> see if you can see it doing things
[17:42] <seb128> no such file or directory
[17:42] <Laney> uptrack*
[17:43] <Laney> not /
[17:43] <Sweet5hark> Laney: always require rebase/cherry-pick, problem solved. ¯\_(ツ)_/¯ https://twitter.com/Sweet5hark/status/829817127792214016
[17:45] <seb128> Laney, http://paste.ubuntu.com/23968015/
[17:48] <Laney> seb128: looks like it's doing stuff
[17:48] <Laney> check with #webops
[17:48] <Laney> I got some alerts about that check before that I think were false
[17:49] <seb128> k, thanks
[17:50] <Sweet5hark> seb128: currently uploading to http://people.canonical.com/~bjoern/zesty/5.3.0/ -- I havent tested yet to build on armhf. currently also upload that to lp today for armhf-testing. would you want to wait to make sure armhf builds, or go ahead as-is as ff is looming next week?
[17:50] <Laney> I think it puts things in syslog too maybe
[17:50] <Laney> dmesg | grep ksplice
[17:51] <Laney> Sweet5hark: debian merge :(
[17:51] <Laney> for git I'm all about the rebase
[17:51] <seb128> Sweet5hark, I would just upload
[17:52] <Sweet5hark> Laney: ah. heh. sympathies.
[17:53] <Sweet5hark> seb128: k, thx
[17:53] <seb128> Laney, only success lines, I asked on #webops, let's see
[17:53] <Sweet5hark> seb128: I give you a ping when the upload completed.
[17:54] <seb128> Sweet5hark, k
[18:02] <Laney> off to go and look at nice lights
[18:02] <Laney> bye!
[18:03] <seb128> Laney, enjoy! (is that a festival?)
[18:03] <Laney> yeah this thing http://www.nottinghamcity.gov.uk/media/456153/77686-ncd-robin-hood-energy-light-night-final-version.pdf
[18:08] <seb128> have a nice w.e desktopers!
[18:10] <flexiondotorg> And you seb128
[18:10] <willcooke> dinner time, niht all
[18:10] <willcooke> night
[19:08] <Sweet5hark> upload to http://people.canonical.com/~bjoern/zesty/5.3.0/ finished.
[19:09] <Sweet5hark> ^^ in case you are bored on the weekend, seb128
[19:09] <Sweet5hark> with that, /me is off too.
[19:19] <jbicha> seb128: I could probably upload LO, if you're done for the weekend