[05:58] hi [08:50] Morning hikiko [08:59] hi flexiondotorg [09:02] it'sssssssssssssssssssss [09:02] snowingggggggggggggggggggggggggggggggggggggggg [09:03] yay! [09:04] what up willcooke [09:04] how was LDN? [09:06] british people are weird :) [09:08] hey Laney - was great! [09:08] Saw some people, got out the house [09:09] hey flexiondotorg hikiko Laney willcooke desrt [09:09] morning seb :) [09:09] happpy tgif [09:09] morning desrt! We don't get much real snow any more :( [09:09] morning seb128 [09:10] hi Laney willcooke desrt seb128 flexiondotorg [09:10] hey hikiko! [09:11] willcooke, hikiko: welcome to the morning quadratic workout [09:11] :)) [09:11] Morning willcooke Laney desrt seb128 [09:11] yo flexiondotorg! [09:11] * hikiko google trandlates [09:11] ./greet-people [09:11] ./how-are-you [09:11] hikiko: "quadratic" as in O(n^2) [09:12] lol [09:17] Morning all [09:18] bah, I created a role account for launchpad uploads [09:18] but launchpad oops when I try to log in with it :-/ [09:18] hi davmor2 - any snow up your end? [09:18] hey davmor2 [09:19] willcooke: don't be daft the rest of the Country needs to be waist deep before it ventures into wolverhampton ;) [09:19] :) [09:23] 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] seb128: Yes [09:23] Useful for everything [09:23] almost [09:23] duflu, hey, thanks! [09:24] duflu: no now you are mistaking it for duck tape ;) [09:24] Also useful, regardless of spelling [09:25] or name otherwise [09:25] Ducks are also musical [09:25] https://www.youtube.com/watch?v=zTijW72owNk [09:26] 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] duflu: duct even thanks for the heads up ;) [09:26] thanks [09:31] seb128: you had to make a new user? [09:32] 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] oh [09:32] it was a trick so he could get all the karma! [09:32] :-) [09:33] also uploads stopped working because he removed himself from that team [09:33] don't want to repeat that with the next person [09:35] makes sense [09:46] Get:71 http://archive.ubuntu.com/ubuntu zesty/main amd64 openjdk-8-jre-headless amd64 8u121-b13-3 [27.5 MB] [09:46] Get:72 http://archive.ubuntu.com/ubuntu zesty/universe amd64 openjdk-9-jre-headless amd64 9~b155-1 [109 MB] [09:46] what an update [10:46] hey Laney... it's snowing here tooo [10:46] seb128: hey dude.. [10:46] hey Trevinho [10:46] seb128: did you see my pings of last night? [10:46] no [10:46] check the log :-) [10:46] I close IRC at night [10:47] night... it was before dinner ... [10:47] I mean you were here [10:47] hey Trevinho [10:47] at leat your client was [10:47] is it settling on the ground? [10:47] Laney: not in the city, but I see it in the hills nearby [10:47] nice [10:48] Trevinho, the mp? [10:48] 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] Trevinho, oh, that I read [10:48] and do the renaming you need so that we can adjust the tools too [10:48] I didn't understand why you were spliting the dependencies list [10:49] seb128: to make it easier to read [10:49] just a logical split [10:49] also we don't include unity libs [10:49] we said in DenHaag that we wanted a GNOME stack only there [10:49] seb128: you're including unity-gtk-module, isn't it? [10:49] so unsure why we would add the indicators [10:49] well, libappindicator isn't only unity related [10:49] also xfce uses that [10:50] and I think elementary and mate? [10:50] well it's not GNOME [10:50] mh, that would just make easier to snap apps that work in ubuntu tho [10:50] as we can't have a runtime that overides that too, isn't it? [10:50] what is that indicator part doing? [10:51] seb128: https://github.com/3v1n0/appindicators-snapcraft-parts/blob/master/snapcraft.yaml#L88 [10:55] 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] it basically just adds http://paste.ubuntu.com/23966123/ (minus header and .so files) [10:56] seb128: because the debs in xenial doesn't support snap properly [10:56] Maybe we should SRU the fixes, but not there yet [10:57] yeah we should [11:04] 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] yes [11:05] Trevinho, I've no strong opinion either way, but ideally we would build everything the same way, either from debs or source [11:06] Trevinho, if there is anything blocked/not working due to that we can merge your changes as workaround and tweak later [11:07] seb128: indicators won't work without it... unless apps won't define themselves after: indicator-gtk3... [11:08] 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] ah, of course... also kde needs that [11:09] Trevinho, which is easy to do, and we don't have that much apps using indicators... [11:10] yeah, sure... I proposed that since didrocks suggested it in a PR (https://github.com/ubuntu/snapcraft-desktop-helpers/pull/36) [11:10] k [11:10] as we agree'd on getting that for desktop launchers by default [11:10] so... [11:10] Trevinho, I'm going for lunch for let me have another look once I'm back [11:11] I can either set it only a dependency of the gnome-runtime at that level [11:11] so the desktop-launcher has dependency on that, instead of the runtime itself [11:11] yeah, I'm still waiting on your answer on this PR :) [11:11] but [11:12] I don't remember why this isn't part of this part itself [11:12] and rather it's a dep [12:27] didrocks: sorry I had to take a train.... [12:27] didrocks: anyway... [12:28] yeah.. That's the thing I would rather prefer to include everything in the runtime more than adding "after:" stanza's [12:28] actually also the qt5 runtime has the needed elements to support unity... [12:28] well, appmenu in fact. [12:31] 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] 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] 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] Trevinho: agreed on merging indicator in runtime then! [13:17] Trevinho: hum, creating the dir, there is an issue, right? [13:18] like $SNAP is ro [13:18] wait, what's the install stenza? [13:18] ah, I see what you mean [13:18] as part of the part, at build time [13:18] clever Trevinho ;) [13:19] hum, it means it would need a custom plugin, though [13:19] we can make it as part of make parameter [13:19] but yeah, I like your idea :) [13:19] didrocks: yeah, I didn't want to clutter the makefile with something that is only related to that [13:20] and.. those new tools are nice for such things [13:20] Trevinho: well, it's a variable [13:20] so if present -> mkdir -p it [13:20] as for FLAVOR [13:20] let's separate this in another PR, agreed? [13:20] (the creation thing) [13:20] on the current one, I have few comments [13:20] prefer doing it here or on the PR? [13:20] as you prefer... I can stash that commit for later :-) [13:21] yeah, stash it :) [13:21] I'd keep it here as i's just one line.. [13:21] but... [13:21] snap connect $SNAP_NAME:gnome318-platform gnome318-udt:gnome318-platform [13:21] 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] -> I would prefer now that we try to be consistent with qt to name it "platform" [13:21] so gnome318-udt:platform [13:21] indeed... it's just that we need to update the snap too [13:21] same for $SNAP_NAME:gnome318-platform -> $SNAP_NAME:platform [13:22] yeah :) [13:22] otherwise that would fail [13:22] we'll need anyway [13:22] seeeeb :-) [13:22] for s/runtime/platform/ [13:22] I whish I had write permission in the ~desktop-team stuff [13:22] you don't? [13:22] of maybe seb would disagree :-) [13:22] you don't have upload rights? [13:22] I thought you have on the desktop team bucket [13:22] I can do, but I have meetings this afternoon [13:23] nope... I still have to conquer those... seb128 wanted to do something, but... still he gave me no news on that [13:24] 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] 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] yeah, let's get it inside the runtime [13:24] however, can you add it to other parts? [13:24] like gtk3, qt… [13:25] the ones that don't use any platform snap [13:25] I've the PR theat I linked before... [13:25] that's doing it [13:25] that* [13:25] isn't that adding after:? [13:25] yeah, what you meant, sorry? [13:26] no, I meant, let's get that inside the part [13:26] not defining another part [13:26] ah... since it's compiling stuff, it would make things more cluttered [13:26] I mean, this should just be part of desktop-launcher [13:26] hum [13:26] we can do it later once I've SRUed the changes [13:26] well, depending on it will ask to compile it anyway? [13:26] to xenial [13:26] ok [13:26] sure... I fixed snapcraft for that [13:27] yeah, but you know how it ends up with deps :) [13:27] also that is independent from desktop-launcher... [13:27] sure, you can still redefine those [13:27] why should it be? [13:27] it's all one block "run my snap on the desktop" [13:27] and integrate it [13:27] sure, i mean... indicators can be used independently [13:27] hem :) [13:27] see https://github.com/3v1n0/indicators-examples-snaps [13:27] a non desktop app using indicators? [13:28] they all deps on a toolkit [13:28] but let's keep that separate and finish that PR first [13:28] I'd still need to use after anyway... So I'd keep them remote for now [13:28] I'm quite opposed to "after:" [13:28] then I'll SRU and we'll just add the deps [13:28] let's finish that one: change plug name and slot name to be "platform" [13:28] ok= [13:28] yeah ;) [13:29] Trevinho, let me know if you need help with the SRU [13:29] help/connect message [13:29] and then, we sync that with the platform snap upload [13:29] seb128: i'm preparing the branches for bileto now... [13:30] (remove the install for now, I keep a note on doing it separetely, that's a great idea) [13:31] Trevinho, didrocks, did you agree on something? [13:31] seb128: yeah, let's have plug/slot name being "platform" [13:32] and mount point gnome-platform [13:32] hum? [13:32] didn't we agree that we needed the plug to be versioned? [13:32] the interface is versioned [13:33] like content: [13:33] "interface"? [13:33] (in a meeting) [13:33] didrocks: I pushed the change [13:34] Trevinho: you didn't push strongly enough it seems :) [13:34] still at https://github.com/ubuntu/snapcraft-desktop-helpers/pull/46/commits/2289e89d49bc86f2d4a9308846526cc4f137f18e [13:35] didrocks: ah, you don't want that too? [13:35] I mean, I removed the install thing [13:35] ok, let me build on yours [13:35] after the meeting [13:35] that will be quicker [13:36] you didn't get the renaming thing :) [13:36] what's missing :o [13:36] as written [13:36] let's rename the plug and slot to simply "platform" [13:36] + echo "snap connect $SNAP_NAME:gnome318-platform gnome318-udt:gnome318-platform" [13:36] -> snap connect $SNAP_NAME:platform gnome318-udt:platform [13:36] ahhhhh [13:36] ok [13:36] we don't need versioning here, because: [13:37] - the platform snap is versioned [13:37] - and the version is forced by + content: gnome318-platform [13:37] on both side [13:37] making sense? [13:37] seb128: as well? ^ [13:37] sure [13:39] didrocks, Trevinho, sorry but I don't follow, what prevents somebody to "snap connect $SNAP_NAME:platform gnome319-udt:platform"? [13:39] if the content name is not versioned [13:41] seb128: the content name is versioned [13:41] seb128: I guess that default-provider: gnome318-udt:platform does that [13:41] gnome318-platform [13:41] no? [13:41] both end needs to agree on the naming [13:42] didrocks, isn't the first part the name of the snap and the second the content? [13:42] didrocks, like "platform" would be the content there [13:43] seb128: sorry, can't follow the discussion in this meeting, will have few minutes in ~45m [13:43] seb128: but no [13:43] seb128: first part is snap name [13:43] second is the plug name [13:43] right [13:44] didrocks, let's talk after your meeting [13:44] yep :) [13:44] the content interface is confusing to me, nothing new [13:44] I keep mixing the content, slot, provider, et [13:44] etc [13:53] muktupavels: hey, are you here? [13:53] Trevinho: yes :) [13:54] muktupavels: good :-) [13:55] muktupavels: hey, do you remember the rationale for https://code.launchpad.net/~muktupavels/libappindicator/watch-status-notifier-watcher-dbus-name/+merge/298533 [13:55] ? [13:55] and... would you like to get that SRUed to xenial...? [13:55] if so... I'd need a bug for that :-) [13:56] Not sure if I remember... [13:56] mh :-) [13:57] why do you want to sru it? [13:57] 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] Trevinho, muktupavels: if for some reason indicator-application-service dies and restarts, the indicators should recover. That was the rationale. [13:58] yeah, that is somehing that I was wondering to, but it generally did that anyway isn't it? [13:58] mitya57: and it did not work before that, right? [13:58] Yes, I think it didn't work. [13:58] however, let me look at the code further and... in the case, please mitya57 can you opena bug with SRU headers please? :-) [13:59] 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] ok [14:00] as you guys prefer [14:00] thanks [14:27] seb128: libreoffice 5.3.0.3/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] hey Sweet5hark [14:28] Sweet5hark, are you maintaining the libre office snap? [14:28] seb128: would you be fine with e.g. uploading today, so it can build over the weekend? [14:28] Sweet5hark, uploading to zesty sounds good to me ... I guess you didn't reapply to the dmb yet? ;-) [14:28] Sweet5hark, yes [14:28] Sweet5hark, hi, there are still transitional packages missing, and/or firebird re-enablement [14:28] Blu2_: yes [14:30] 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] 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] 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] Sweet5hark, let me know when there is something ready for sponsoring [14:35] seb128: will do [14:36] ricotz: meh, yeah. human transitional is easy. lemme check the firebird stuff ... [14:37] Sweet5hark, I guess the human transitional should pull in some other available theme package [14:37] Sweet5hark, also libreoffice-sdbc-firebird is recommended while not being available [14:38] ricotz: hmm, why? the stuff using human should have proper deps ... [14:38] Sweet5hark, and the mariadb vs mysql mentioned [14:39] Sweet5hark, just a thought to forcefully install something instead having the user endup without any [14:39] the transisional is empty of course ;( [14:39] ;) [14:40] Sweet5hark, https://paste.debian.net/plain/913697 [14:42] 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] Sweet5hark, they sent me here :D [14:43] Sweet5hark, right, hehe libreoffice-common suggests human [14:47] 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] Sweet5hark, please take note of those things, I don't want to mention it a fourth time [14:49] 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] ricotz: what your beef with mariadb to create delta vs. Debian? [15:09] 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] haha, don't suggest you actually care about delta with debian ;) [15:11] 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] 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] (I am applying this for the backports to make sure keeping it mysql flavoured) [15:13] ricotz: well, unless we _know_ it is a problem, we will keep with what Debian does for new releases. [15:13] ricotz: but fine for backport (only) of course [15:14] no need to xkcd927 this more than needed. [15:17] Sweet5hark, fyi, mariadb is in universe and mysql in main, which likely suggests something [15:18] ricotz: heh, now _thats_ and argument ;) [15:18] * Sweet5hark changes back to mysql. [15:25] 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] ricotz: ^^ [15:30] seb128: sooooooo [15:30] :-) [15:30] seb128: content interface is a little bit special [15:31] as any other interface, you have a slot/plug [15:31] they can differ on both side [15:31] but I think we should name them "platform" [15:31] so that connect is: [15:31] foo-app:platform gnome318-udt:platform [15:31] for them to be able to connect [15:31] they need to have a matching "content: " [15:32] content: gnome318-platform [15:32] or even just content: gnome318 [15:32] for instance [15:33] so you have 3 parameters there? [15:33] (yeah, I dislike the "content" term, it should be "type") [15:33] right [15:33] : and a content which is not specified? [15:33] yeah, content is in the plug and slot definition [15:33] https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/snapcraft.yaml#L37 [15:33] so why did you ask me to version the plugname back then? [15:34] (you have a 4th parameter in the plug, which is target: path) [15:34] I had "gnome-runtime" in a first iteration [15:34] I think you asked me to add the version in a review round [15:34] * seb128 reads old logs [15:34] 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] so sorry for creating this misunderstanding/mistake [15:35] no, we did that in december [15:35] oh really? [15:35] it's probably my fault [15:35] I don't remember, my memory is all foggy :) [15:35] but I don't really understand [15:36] the gnome runtime snapcraft.yaml has only 1 name [15:36] slots: [15:36] content: [15:36] content: gnome318-runtime [15:36] euh [15:36] are you sure? [15:36] yes [15:36] I don't understand the second line "content:" [15:36] it's the slot name [15:37] it should be gnome318-runtime from the current doc [15:37] (and so, we want to change it to "platform") [15:37] sorry I opened an old version on disk [15:37] phew [15:37] but that worked [15:37] iirc? [15:37] with a different connect command [15:37] Kyle recommended to use "content" as the slot name because that way you don't need to add a "interface: content" line [15:38] I slightely disagree to this, I think ease of use for the user is better [15:38] it's confusing though [15:38] and knowing that slot and plug name would be "platform" for platform snaps help [15:38] current version is [15:39] slots: [15:39] gnome318-runtime: [15:39] interface: content [15:39] content: gnome318-runtime [15:39] read: [15:39] - / [15:39] [15:39] so you get 2 labels which are the same but not the same [15:39] yeah, that matches the instructions we got [15:39] right, that's what I want to remove [15:39] having line 2 "platform:" [15:40] so what is the "content" about? [15:40] the content is what both slots/plugs needs to match to be able to connect [15:40] it's the "type" of content if you prefer [15:40] I would set this to "content: gnome318" if it was me [15:40] k [15:40] I don't understand snappy there [15:40] so, if you have an app with content: gnome320, it won't connect to gnome318-udt snap [15:41] why do you need content to match [15:41] you connect to an content interface which as a name [15:41] the combo snap_name/slot_name should be unique [15:41] yeah, I raised my concern on the spec doc about that [15:41] they decided another way [15:41] and that the ABI is on "content" [15:42] so the ABI is not exposed at connect time? [15:42] nope, it's just ensured it matches though [15:42] but not displayed in the command line [15:42]