=== chihchun is now known as chihchun_afk [04:21] I have configured my netplan to make the wifi working in my home on my dragon board. However, now I connect my board to an network cable in the office, the network is not working any more. Does it mean that we cannot make wifi and cable working at the same time? === chihchun_afk is now known as chihchun === diddledan___ is now known as diddledan === Tribaal_ is now known as Tribaal === andyrock_ is now known as andyrock === Trevinho_ is now known as Trevinho === rsalveti_ is now known as rsalveti [05:58] Bug #1647936 opened: Raspberry Pi 3: a small rainbow square on the top right of screen === JanC_ is now known as JanC [07:16] ogra_, ping [07:40] Bug #1647950 opened: Raspberry Pi 2/3: failed to umount /lib/modules and /lib/firmware [07:49] morning snappy [07:57] mvo, Could you please share the candidate images link for testing? :) [07:58] vigo: http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/.pending/ [07:59] mvo, yay!! thank you =) [08:07] hey hey [08:07] hey dholbach! [08:07] hi seb128 [08:32] Bug #1647992 opened: r620 core snap candidate change /etc/modprobe.d to "synced", and blacklist-watchdog.conf now cause rebooting every 7 min without iTCO_wdt module loaded [09:48] Quick snap question, if a snap provides a binary to classic ubuntu, can the snap access files on the classic file system tree? I am only seeing apparmor DENIED whenever that binary tries it [09:49] didrocks, heya. Me again. Do you think you could get wireshark onto the pi to capture the whole thing? (or somewhere along the route to the pi) [09:49] longsleep, some but not all files [09:50] longsleep, what are you trying to access? [09:50] longsleep, no 'hidden' files, for example [09:50] Chipaca: well i am trying out https://uappexplorer.com/app/hugo.hugo-authors - and the binary needs to access the files and folders from the static site, so you run it in the cwd of your site [09:51] Chipaca: eg. it fails to read the config.toml file which is cwd/config.toml - it gets the absolute path right but then apparmor prevents read access [09:52] let's see... [09:52] Chipaca: Snap support was added here https://github.com/spf13/hugo/pull/2443/files - and i wonder if i am just the first one to try or if i made a mistake [09:52] PR spf13/hugo#2443: add snapcraft.yaml file [09:53] ralsina, see? hugo uses snappy. Hint hint. [09:53] Chipaca: yeah would be pretty awesome if it would work too :) [09:53] longsleep, details! [09:54] hehe [09:54] right [09:54] longsleep, is there an easy way to run it? [09:54] i mean, i just installed it, have no config.toml :-) [09:55] sure, i think it can create one [09:55] hold on a sec [09:55] any idea what i may be doing wrong when trying to use the ubuntu-app-platform content interface? [09:55] http://paste.ubuntu.com/23592699/ [09:55] t1mp: ↑ [09:56] Chipaca: hugo new site lala [09:56] lala is the folder it would create, but it fails misterably :) [09:56] yeah, that worked [09:56] oh really [09:56] not for me [09:56] ah [09:56] longsleep, you're holding it wrong [09:56] longsleep, hugo uses the 'home' interface [09:56] Chipaca: i am on a fuse mount. Maybe thats the reason? [09:57] longsleep, which means it gets access to your home, except for dotfiles [09:57] oh ok [09:57] Chipaca: so when its not in home it fails [09:57] * longsleep tries in home [09:57] longsleep, fuse mounts are probably either /media (different interface) or something like ~/.gvfs/yadda (dotfile) [09:57] Chipaca: you are right [09:57] Chipaca: yes its in /media [09:57] Chipaca: it works in $HOME [09:58] Chipaca: anything i can do about it? I do not have enough storage in $HOME [09:58] longsleep, you could suggest to them to add whatever the interface was that gives you /media [09:58] * Chipaca doesn't remember [09:58] longsleep, or, you could bind-mount it into your home [09:59] Chipaca: ok i see - thanks ! [09:59] longsleep, the bind mount thing will not tolerate the fuse mount going away easily [09:59] but it should work [10:00] longsleep, if the fuse mount is a long-lived thing you could configure it to mount in your home directly [10:00] Chipaca: yeah i understand [10:00] Chipaca: no, encrypted USB device :P [10:00] LUKS-encrypted? [10:00] yes [10:01] you can make that mount on boot, but yeah, a lot of work [10:01] well its not connected all the time [10:01] t1mp: ok, got it to work [10:01] longsleep, ah [10:02] longsleep, in any case, you don't need fuse for that, if you want to do the work you need to set up crypttab and fstab appropriately [10:02] Chipaca: but i understand the problem now, and the snap basically works as long as the stuff is below $HOME [10:02] yep [10:03] Chipaca: without fuse, how does one enter the passphrase for the key? [10:03] Chipaca: i mean i have crypttab and all for the rootfs and there it prompts on bootup, but where would it prompt for optional devices on hotplug? [10:03] you get prompted for it, but I haven't tried doing it in a graphical environment [10:04] so, i don't know [10:04] sorry :-/ [10:04] Chipaca: fair enough - this is the snappy channel after all :) [10:07] Chipaca: hum, that's going to be complex due to my current schedule, would be great if we have a prepared snap for that [10:09] cjwatson, hmm, seems all core and ubuntu-core snaps failed to build due to what looks like a network error ... [10:09] OSError: Tunnel connection failed: 403 Forbidden [10:09] cjwatson, https://launchpadlibrarian.net/296915208/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz is an example build log [10:21] Chipaca, i think bug 1647950 was something you were working on, right ? (is there a bug i can duplicate to ?) [10:21] Bug #1647950: Raspberry Pi 2/3: failed to umount /lib/modules and /lib/firmware [10:22] yes, a mo' [10:25] tsdgeos: yes, I know what it wrong: https://bugs.launchpad.net/ubuntu-app-platform/+bug/1645731 [10:25] Bug #1645731: Fail to access the shared content if app starts before connect interface [10:25] zyga, do you remember the bug # for the system-shutdown thing? [10:25] tsdgeos: snappy bug. See https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/ what is the correct order to install/connect to work around that for now. [10:26] or Jamie's solution in his bug comment [10:28] ogra_, I'm pretty sure we have a bug for it; we certainly have a card and a few branches for it [10:29] ogra_, but as usual i can't find it; let's hope zyga or mvo can [10:42] is this https://github.com/snapcore/snapcraft/pull/951 how one is supposed to do pull requests for snapcraft? [10:42] PR snapcraft#951: snapcraft plugins -> snapcraft list-plugins [10:43] PR snapcraft#951 opened: snapcraft plugins -> snapcraft list-plugins [11:06] ogra_, ping [11:08] I used netplan to configure my wifi at home, then I went to my office. Since the wifi AP name is not right, I started to use a cable to connect my ubuntu coree device. However, I cannot find any IP address for the ubuntu core device even though I had a cable connected to it. is this a bug? [11:09] liuxg, yo [11:11] ogra_, I described my question above. is that a bug or a designed feature? thanks [11:17] liuxg, well, if you disabled wired network it wont run [11:18] if you did set a password you could do a local console login and run sudo console-conf to reconfigure it ... [11:18] ogra_, do you mean I need to turn it on? I configured the netplan during the console-conf. How can I configure it again? [11:18] but beyond this i dont see how you could get wired networking to work [11:19] and during console-conf you configured wired network as dhcp client ? [11:19] ogra_, during the console-conf, I just leave the default setting for the wired connection. [11:20] well, not sure if thats enough ... thats a mwhudson question i guess [11:20] ogra_, maybe not. I did not touch the default setting there. If that is the casse, would it be good to have the default setting for wired network as that? [11:21] no, because you probably dont want wired to wsork for security reasons as a manufacturer ... defaulting to always have wired obtain an IP would be a bad idea here [11:22] ogra_, ok. I see your point. but normally if I have a wired connection, in fact during the console-conf, I do not do anything there, and it starts to work directly. [11:22] ogra_, so, I thought wired network connection came automatically without any manipulation. [11:28] liuxg, iirc the firstboot code brings it up, but i'm not sure the config is applied to netplan if you dont take any action to do that in console-conf ... but as i said, thats an mwhudson question [11:29] ogra_, thanks for your answering. mwhudson, what do you think of the issue? thanks [11:45] Chipaca: Nikola has been snapped for MONTHS [11:55] PR snapd#2425 opened: store: decode response.Body json inside retry loops === hikiko is now known as hikiko|ln [12:31] mvo, sorry to disturb you again ;). Could you approve media-player-app and ubuntu-notes-app [12:35] pstolowski: hi! With snapctl, will it be possible to know the apparmor profile of the peer, when running inside an interface hook? [12:50] ralsina, d'oh :-) [12:51] ralsina, i typo'd my original `snap find`, i guess [12:51] Chipaca: we also have a snap for coil, a nikola-based CMS [12:51] that one is more experimental, tho [12:54] snap info tells me it's only in beta and edge :-) [12:55] is it really a CMS *for* Nikola, as its description says? [12:55] anyway. i've got a standup coming up === hikiko|ln is now known as hikiko [13:03] mardy, i'm not aware of such capability, sounds like something concerning apparmor more than snapd; perhaps jdstrand knows? [13:03] renato__: sure, soon [13:05] pstolowski: or, leaving apparmor aside, is it possible to somehow identify who's the snap which is connecting into your interface's slot? [13:08] mardy, that should be easily doable if required from interface hook, but syntax/semantics need to be defined [13:12] mardy: I know of no functionality in snapd for wrapping the libapparmor api. I don't know otoh if the rest api has anything about connected plugs to a snaps slot. maybe that is what interface hooks are for? kyrofa (or Chipaca) may know [13:14] jdstrand: yes, actually my original question was about interface hooks: I'll need a way from inside the unity8 snap to know what's the apparmor profile of the snaps connecting to the Online Accounts interface, so that I can add them to the ACL when the user enables them [13:25] mardy, so i think interface hooks will be able to expose this info during the execution of hooks, technically there is no challenge. it just needs to be defined in terms of how this is exposed [13:27] something we need to discuss with niemeyer, along other details of hooks currently in the review [13:31] mardy: you may want to read this: https://docs.google.com/document/d/1mwLfShu3K8LNa1cYySqhM0fp06TZoKygG0bs2KB9Z4I/edit# . That is something that tvoss and I came up with but it has not undergone review by niemeyer [13:31] pstolowski, jdstrand: thanks, reading... [13:32] niemeyer: hi! that document ^ is something we talked about me writing up ages ago but I never followed up with you after my meeting with tvoss since this is mostly about Personal and at the time Personal was far out [13:32] niemeyer: now Personal is here, so probably need to work through that. I'll let you decide on if before the end of year or not [13:32] zyga: that is probably something you would be interested in ^ [13:36] jdstrand: looking [13:36] jdstrand: mmm... I'm not sure I like the proposal in that document... why does snapd need to be modified at all? [13:36] jdstrand: thank you [13:36] jdstrand: trust-store (and Online accounts) have their own storage for the ACLs [13:37] jdstrand: it can be maintained by whatever snap is providing the slot (unity8, in our case) [13:37] jdstrand: hey, are yon on rocket chat? https://rocket.ubuntu.com/ [13:37] mardy: note the invariants [13:37] jdstrand: it's easy to join (just sso), it's browser based and has persistent ping history and other good ies [13:37] and it's public :) [13:38] zyga: and its browser based [13:38] * jdstrand joins [13:38] jdstrand: noted, and I don't see any conflict with what I'm suggesting [13:40] mardy: I added you, zyga, niemeyer, and pstolowski for comment (and edit) rights [13:40] jdstrand: thanks, will jump in right away :-) [13:41] mardy: feel free to comment. the design is based on direction from niemeyer [13:41] mardy: though again, he has not reviewed it yet, so still lots of time to comment, etc [13:41] mardy: also, this is specifically for *trust-store* and not online accounts which I understand is similar but different [13:42] but sufficiently similar in my mind that they should be considered in the same conversation [13:43] jdstrand: true, they are different in that location service connects the client to a system resource (the GPS), while OA connects the client to the user data (which in our case is stored by another snap (unity8) and not by the system [13:43] jdstrand: but I do believe that the solution for OA could be applied for the trust-store services too. Let's see... [13:44] mardy: this is meant to address multi-user. in fact it was written with pulseaudio microphone recording in mind [13:44] I think you might have been trying to express a different point there... [13:45] anyway, yeah-- let's get all the info in there [13:51] jdstrand: do I understand it correctly, that at the current stage, if user A manually connects a snap to the camera and user B launches that snap, the process started by user B will have access to the camera? [13:53] mardy (cc niemeyer): currently, yes. interface connections are at the system level. this document is about allowing a slot implementation to tie into snapd for mediating per-user connections [13:54] jdstrand: I'm starting to see the picture now [13:57] mvo: hey there, why was https://bugs.launchpad.net/snappy/+bug/1628289 marked fix released? [13:57] Bug #1628289: snapd should depend on squashfuse (for use in containers)

[13:57] mardy (cc niemeyer): the gist of the document is: slot implementation 'foo' wants to provide a may to allow its services to some users but not others (via prompting or not, that doesn't matter). foo uses the trust-store library. the trust-store library under the hood talks to snapd. a user talks to foo, foo asks trust-store if this user is allowed, trust-store asks snapd, etc [13:59] jdstrand: all clear, I just don't see the reason for the latter point: trust store could have its own storage, just like it has on UT [14:00] mardy: that gets back to the invariant [14:00] jdstrand: mmm... which one? [14:01] mardy: 'Snapd should be the central authority for anything interface-connection related'. that came from guidance from niemeyer. [14:02] jdstrand: sure, that would still be the case: the interface between the client and the "service" snap (the one using trust store) would be autoconnected, and the interface between the service and the resource (e.g., GPS) would be manually connected via snapd [14:02] mardy: a nice feature of this approach is that a tool can be written to talk to snapd to manipulate all trust-store connections. ie, the trust-stores aren't siloed. they are in snapd. this makes it easy to see with one command all the user connections. it would help ubuntu-system-settings, etc [14:03] jdstrand: mmm... I think you are trying to solve two different issues with a single solution [14:03] mardy: I understand what you are saying. the storage doesn't have to be in snapd, but it is a feature that it is [14:03] mardy: please comment in the PR. this has not been approved and was following particular guidance [14:03] jdstrand: OK [14:05] stgraber: sorry, that was incorrect [14:07] Bug #1628289 opened: snapd should depend on squashfuse (for use in containers)

[14:09] zyga: can you send me a message on rocket? [14:15] jdstrand: yes [14:15] jdstrand: PM or @-mention? [14:16] PR snapd#2426 opened: spread.yaml: run dmesg -c with sudo and log the id before running it [14:20] zyga: I don't know. I closed my window to see what offline notifications look like. both? [14:20] OK [14:22] jdstrand: done [14:24] jdstrand: thanks for the replies! I think all what you wrote makes a lot of sense if interface connections continue to be per-system, but I hope that there are plans to change that, eventually? [14:27] mardy: there isn't a way to make them per user for the foreseeable future. apparmor policy is for the system, not per-user [14:28] mardy: therefore the trusted helpers continue to mediate their APIs like always [14:28] mardy: and this merely provides a way to move the storage to a central place [14:29] (for those trusted helpers that use trust-store) [14:29] * mardy thinks [14:30] mardy: I added a couple more comments to hopefully clarify. this isn't a radical change. this is adjusting the trust-store library to use snapd as its storage. that's it. with that, we can do cool things with tooling, etc [14:30] niemeyer: cc ^ [14:31] niemeyer: also, sorry for all the pings, just want you to have all the context for whenever that spec is reviewed (again, doesn't have to be today) [14:31] zyga: if you sent anything, I didn't get them [14:32] zyga: via email. I logged in and see them [14:40] Bug #1646479 opened: Unity8 applications require access to name=com.ubuntu.MenuRegistrar === jamespag` is now known as jamespage [15:11] i'm getting 504 gateway timeouts whenever I attempt to upload updates to the snap store [15:12] not only you [15:13] but if you check via the store UI you will find your package got uploaded fine [15:13] ogra_, i'm just trying to navigate on that website to check other snaps I've done and all I get is 504s [15:14] go to the toplevel of the snap in the store (cut off rev/#### from the url) [15:14] and you will see the revision landed fine [15:14] at least thats the case for my LP builds [15:15] heh, even that 504s on me [15:15] wow, i can usually reach the toplevel [15:16] oh, nth attempt and it worked [15:16] heh [15:16] its a game of patience :) [15:16] doesn't feel that snappy to me [15:16] no pun intended [15:16] that is because the store still runs on classic :P [15:20] ogra_, on a raspi2 I guess [15:20] haha [15:20] probably a pi1 with raspbian [15:21] and the CPU clocked at 50% to make sure it don't get too toasty [15:24] heh, yeah [15:39] jdstrand, I was wondering abut the snapd-control / local snap install/connection issue we talked about a week ago, will the fix (if any) be in 2.19? [15:43] alex-abreu: I don't know. we talked about it extensively and Gustavo was going to work through a few things. I have a todo to talk to him today about it [15:59] jdstrand, ok thx === chihchun is now known as chihchun_afk [16:11] sergiusens, hey, is snapcraft doing some magic to bring in libraries used by a binary you try to include? [16:11] PR snapd#2422 closed: tests: re-enable snap-confine unit tests via spread [16:21] Hi there. I am working through the snap tour and have little problems with "20-PARTS-PLUGINS/01-reusable-part/". Error: No CMAKE_CXX_COMPILER could be found. [16:21] Looks like the is a build dependency missing. [16:23] had to install build-essentials because of missing g++. [16:23] PR snapd#2427 opened: cmd/snap-confine: add support for classic confinement [16:24] Please fix this. It is an easy problem to fix for me. But with a bit less experience i wouldn't be able to solve it. [16:24] jdstrand: poke on rocket :) [16:24] Is there a issue tracker for the tour? [16:25] jamiebennett: ^^ [16:26] zyga: is that pr what will allow us to call snaps from other snaps? [16:26] lof_mt: Here please - https://github.com/ubuntudesign/snapcraft.io/issues [16:27] cwayne: no, that's classic confinement [16:28] cwayne: (super close, release is tonight) === tgm4883_ is now known as tgm4883 [16:28] lof_mt: sorry, just looking at the backlog, the github page is correct for the tour working [16:28] cwayne: the other PR will be merged next cycle, I tried it and I think there are some bits missing still [16:28] lof_mt: i.e. the page [16:28] lof_mt: for the code itself, that is snapcraft - https://bugs.launchpad.net/snapcraft [16:29] zyga: ah ok [16:29] cwayne: but I'll try to merge it anyway, we can see how far that gets us :) [16:35] What snap path belongs into a users $PATH? [16:36] lof_mt: there should be /snap/bin, added by /etc/profile.d/apps-bin-path.sh [16:37] nacc that only works if the user was create after snapd was installed right? (As the bash profile is already written) [16:38] lof_mt: no, /etc/profile (which is used at runtime) sources all .sh in /etc/profile.d (on ubuntu) [16:39] On debian too. But in both my users bash and zsh there is no snap path. [16:40] Must be a user not distro issue. [16:41] Thanks nacc [16:41] lof_mt: that seemds odd ... almost like profile isn't being read, then [16:41] lof_mt: but that'swhere i'd start; maybe try setting some other variable in /etc/profile (or a new.sh in /etc/profile.d) and see if your user sees it on re-login? [16:42] Works for my root user. Definitly messed the users bash profile up at some point. Haven't noticed because of zsh. [16:42] lof_mt: ok :) [16:44] hello. i am trying to update my ubuntu gnome system and snapd wont set up during the installation or is takng a very very long time. is there any way i can fix this? and is this the right place to ask? [16:50] stormchaser3000_: The Ubuntu upgrade is finished? [16:51] lof_mt: no. it just sits there saying Setting up snapd (2.16ubuntu3) ... [16:51] no error message or anything [16:51] Is there a way to deploy gsettings schemas? Does the gtk3 "cloud part" anything of that for me? Or do i need to write a script that deploys the schemas? [16:51] stormchaser3000_: Graphical or cli update? [16:51] cli [16:52] ugh i will be back later have to go [16:54] Looks like it: https://github.com/ubuntu/snapcraft-desktop-helpers/blob/1bff18219659caa849950858c6021eaa2289f1d0/common/desktop-exports#L102 [16:54] But where do i put them? [16:56] Or is that only for making the plug work? [16:59] lof_mt: you should just use the desktop parts, like destkop-gt3 [16:59] gtk3* [16:59] it will build this script, then you only need to use command: desktop-launch [16:59] (and it will build the schemas as needed and such) [17:00] + brings the deps [17:00] lof_mt: some example and content: https://developer.ubuntu.com/en/blog/2016/07/06/announcing-new-snap-desktop-launchers/ [17:00] (note that desktop/gtk3 and others have been renamed desktop-gtk3 since this post) [17:21] Can i specify an ubuntu version with cleanbuild? [17:26] Or an existing lxd container [17:32] PR snapd#2418 closed: snapstate/backend: add backend methods to manage aliases [17:32] is there a generic fix for relocating shared memory file creation location? [17:32] snappy-debug says "adjust program to create files and directories in /dev/shm/snap.$SNAP_NAME.*" [17:33] but I'm hoing there's a workaround without patching or re-building the program [17:33] mhall119: no [17:33] :( [17:33] mhall119: I looked at it multiple times [17:33] mhall119: maybe if we teach glibc about snappy [17:34] mhall119: but that changes semantics and exsitng software will break [17:36] lof_mt: ok i am back [17:36] Did it ran through? [17:37] ? [17:37] no [17:38] Can you look in /var/log/dpkg.log ? [17:38] tail /var/log/dpkg.log [17:39] lof_mt: http://paste.ubuntu.com/23594390/ [17:40] kill all apt and dpkg processes. We try to install it manually with dpkg, look for the error then continue with the rest. [17:40] This might be a better fit for #ubuntu [17:41] ok [17:42] lof_mt: that seems to have worked [17:42] but i am not sure yet [17:42] yep it worked [17:42] thanks [17:42] seb128 yes [17:43] (installing manually with dpkg -i) [17:43] stormchaser3000_: What does that mean? Is snapd fully configured anyway? [17:43] i think so. i downloaded the package and then installed it using dpkg -i [17:43] and then it configured [17:43] i think [17:44] and then i run apt-get upgrade and then it tries to install snapd [17:44] and it fails to configure [17:44] i think. i am still waiting [17:44] and sorry for spamming [17:45] nope it isn't configuring [17:47] and then it works when i manually install the package [17:47] oh well. at least it works XD [17:47] Can you run md5sum on both files and compare if you get the same package? Or does the package name indicate a different version number? [18:01] about schemas again. They are installed in the right location. (/usr/share/glib-2.0/schemas/) on my local system. And on the build server they are in (prime/usr/share/glib-2.0/schemas/). But the application segfaults " GLib-GIO-ERROR **: Settings schema 'org.gnome.feedreader' is not installed" [18:01] i don't have any idea where else it has to be installed. :( [18:01] (non snap version from same git revision works. [18:01] ) [18:06] lof_mt: it is because of chroot [18:06] lof_mt: http://www.zygoon.pl/2016/08/snap-execution-environment.html [18:07] alex-abreu, jdstrand: Yes, it should be in 2.19.. John has been on it [18:08] niemeyer, ah awesome ! is there a PR for this? [18:11] alex-abreu: Yeah [18:11] alex-abreu: snapd#2415 [18:11] snapd#2415 [18:11] PR snapd#2415: overlord/ifacestate: no interface checks if no snap id [18:12] thank you [18:12] zyga: i don't see how that is a problem. It should be the same path externally and internally. And both have the needed files. [18:12] lof_mt: prime/usr/share/whatever will end up as /snap/$SNAP_NAME/$SNAP_REVISION/usr/share/whatever [18:12] lof_mt: at runtime that is [18:24] zyga so the code can't open /usr/… but needs to open $SNAP/usr/… ? [18:24] ogra_, ping [18:25] lof_mt: correct [18:30] Wasn't there an organise instruction for moving files around with snapcraft.yaml? [18:36] lof_mt: snapcraft organize can only organize files within $SNAP [18:36] lof_mt: you cannot currently put any contant at another location [18:36] lof_mt: and $SNAP expands to /snap/$SNAP_NAME/$SNAP_REVISION [18:37] *content [18:43] PR snapcraft#952 opened: Add Features for Conditional Compilation [19:15] jdstrand, what do you think about all telephony services. Should we have a telepathy exclusive for telepathy and another for telephony-service and history-service? [19:16] jdstrand, or should we include the telepathy permissions in each interface? [19:17] niemeyer: oh, John has been on it? I missed the decision. you were going to think about it over the weekend. what did you land on? [19:28] jdstrand: We're working on allowing dangerous to allow such connections [19:28] Will be on 2.20 though [19:30] jdstrand: can you +1 https://github.com/snapcore/snapd/pull/2427 [19:30] PR snapd#2427: cmd/snap-confine: add support for classic confinement [19:39] niemeyer, ah not 2.19? [19:46] niemeyer: ack, thanks! [19:46] zyga: I was reviewing it while you pinged me [19:46] zyga: I gave my feedback [19:47] +1 with an extremely minor request) [19:49] PR snapcraft#921 closed: Add support for hooks [19:49] PR snapcraft#941 closed: Support symlinks within deb sources