[06:35] o/ === chihchun_afk is now known as chihchun [06:52] hey zyga-arch [06:54] hey [06:54] what plugin can I use to manaully specify a config file [06:54] config file? [06:54] instead of ./configure [06:55] well, configure is not a config file :) [06:55] are you using the autotools plugin today? [06:55] Sorry, I am lazy :P [06:55] I am for most things [06:55] if your project is using auto{conf,make} then that's the right way [06:56] I was going to compile openssl [06:56] It uses ./config [06:56] if you have some other executable that is "autotools like" then you may need a custom plugin or just use the make plugin and write a makefile with all the rules [06:56] not a perfect example but... https://github.com/zyga/python0 [06:57] this uses makefile plugin to essentially do whatever you want [06:57] note that openssl is probably in the core snap [06:57] so you may not want to build it [06:58] I can probably use stage-packages [07:00] Compiling samba says it cant find openssl === chihchun is now known as chihchun_afk [07:04] you probably want openssl-dev package or something alike [07:06] waiting for travis for 7 hours on https://github.com/snapcore/snapd/pull/3639 now [07:06] PR snapd#3639: update to version of golang.org/x/crypto currently in Debian unstable [07:07] hmm [07:08] odd [07:08] seems like travis bug [07:08] I thought that but openssl-dev doesnt exist anymore.. I'll have to track down the package [07:08] mwhudson: since vendor.json conficted I'd suggest resolving the conflict and pushing over [07:08] zyga-ubuntu: yeah fair enough [07:10] libssl-dev I love consistency [07:11] openssl is an empty dependency package [07:11] it depends on libssl1.0.0 [07:11] s/empty/mostly empty/ === JanC is now known as Guest77859 === JanC_ is now known as JanC [08:30] ondra: hey [08:56] zyga-arch hey [08:57] zyga-suse or here? [08:58] ondra: commented and updated https://github.com/snapcore/snapd/pull/3624 [08:58] PR snapd#3624: interfaces/builtin: rework for avahi interface [09:01] zyga-ubuntu just saw it, good comments and sorry for test code, I used some existing test code, but I guess it's evolving all the time [09:02] that's fine, I didn't expect anything else, the test code is really in disarray [09:02] but changing that globally takes some time, ~100 interfaces is a lot of tweaking [09:02] * zyga-ubuntu just saw one more thing to weak [09:03] fixed [09:05] ok, what's next.. [09:05] Chipaca: 2nd review on https://github.com/snapcore/snapd/pull/3650 please [09:05] PR snapd#3650: cmd/snap-confine: don't share /etc/nsswitch from host [09:05] hadn't i already done this one? [09:06] sorry [09:06] morphis_: do you have a sec to eyeball https://github.com/snapcore/snapd/pull/3649 [09:06] PR snapd#3649: packaging: update arch packaging for 2.27 snapshot [09:06] zyga-ubuntu: +1 [09:06] Chipaca: thank you! [09:06] zyga-ubuntu: let me check [09:06] Chipaca: almost down to zero patches for arch :) [09:06] zyga-ubuntu: I _had_ already done it, just forgotten to … you know, *do* do it [09:06] Chipaca: 2.27.1 will be a nice release [09:06] hahaha [09:06] :D [09:07] PR snapd#3650 closed: cmd/snap-confine: don't share /etc/nsswitch from host [09:07] Chipaca: btw, I read the chatter from last night and noticed you found the double utf8 encoding bug that broke assertions [09:07] Chipaca: really nice and ouch! [09:08] harrumph [09:08] it should be fixed now [09:08] nothing nice about double encodes [09:09] https://github.com/snapcore/snapd/pull/3648 is simple as well [09:09] PR snapd#3648: release: remove default from VERSION_ID [09:09] Chipaca: they fix was easy, but also totally python3 meet http and surrender [09:09] pedronis: is the fix public to see somewhere? [09:09] or just ... to see somewhere? [09:09] no [09:10] anyway it was mostly s/resp.txt/resp.contet/ [09:10] *content [09:10] *text [09:10] aha [09:10] I see [09:10] django? [09:10] no [09:10] zyga-ubuntu: done [09:11] morphis_: thank you [09:11] requests (I think) [09:15] has anybody seen something like this before?: [09:15] $ snap refresh --beta --ignore-validation network-manager [09:15] error: cannot perform the following tasks: [09:15] - Mount snap "network-manager" (218) (installation not allowed by "core-support" plug rule of interface "core-support") [09:16] morphis_: replied, thank you, I'll iterate! [09:17] * zyga-ubuntu needs to buy more than 4GB of ram [09:24] morphis_: will you have a sec to do one more? https://github.com/snapcore/snapd/pull/3622 [09:24] PR snapd#3622: tests: enable regression, upgrade and completion test suites for fedora [09:24] zyga-ubuntu: if you review my snapd-xdg-open PR again :-) [09:26] zyga-ubuntu: done [09:28] morphis_: I will, thank you! [09:28] morphis_: basically today I will do just code reviews [09:28] :-) [09:28] morphis_: and I may iterate a little on this huge PR https://github.com/snapcore/snapd/pull/3617 to tweak it to my preference [09:28] PR snapd#3617: Using udev tagging for snap interfaces [09:29] zyga-ubuntu: please talk with gerry before you do so [09:29] he is actively working on that [09:33] morphis_: gerry is adglkh? [09:33] yes [09:33] morphis_: is here around somewhere where I can talk? [09:33] (I never met him before) [09:33] on slack :-) [09:34] uh [09:34] asking him [09:34] morphis_: where is he from roughly (timezone) [09:34] china [09:34] morphis_: and is he a canonical person? [09:34] yes [09:34] part of my team [09:34] why slack then? is irc blocked? [09:34] morphis_: if he can join here, please ask him [09:34] otherwise let me know how to join slack [09:36] zyga-ubuntu: asked him to join here [09:36] thank you [09:36] I heard there is a crackdown on VPNs in china [09:36] so not sure how to talk to people there [09:36] why are you using slack currently? [09:37] gary-wzl77: hey! [09:37] gary-wzl77: nice to meet you, thank you for joining [09:38] gary-wzl77: and thank you for working on fixing that huge udev issue, that's quite some work [09:38] zyga-ubuntu: Thanks for your code review. [09:38] Yes, I was told by Simon that you have sth to check with me about udev tagging. [09:38] gary-wzl77: I wanted to discuss a few ideas, mainly because that branch is huge (I'm still reviewing it) [09:38] sure [09:38] gary-wzl77: and that I wanted to de-compose it into pieces [09:39] gary-wzl77: if you don't mind me doing that I can work on the current state of the branch until the diff from there to master shinks to zero [09:39] Never mind :) [09:40] I'll submit changes later on per jamie's comments [09:40] gary-wzl77: I'll start with your improvement to common interface, then to individual interfaces that can be simplified with it [09:41] gary-wzl77: yes please, let's keep your PR open and iterating on the udev details [09:41] gary-wzl77: I'll work on the side, proposing small branches that land in master and also merging master back into your branch [09:41] Nice .thanks [09:41] gary-wzl77: so that it can shring in diff size [09:41] gary-wzl77: and then we can hopefully get to the point where everyone agrees and we can just merge it [09:41] RE: Interface simplified [09:42] I spoke to Jamie about it and I've been bit reluctant to do it for complex interface like mir, docker, browser-support and alike [09:42] gary-wzl77: I understand that given the nature of the bug we are in the red anyway until *all* the interfaces are fixed to use udev tagging [09:42] gary-wzl77: so I think it's fine to fix interface-by-interface [09:43] gary-wzl77: and even leave TODO/FIXME markers in things we know need love but are non-trivial to do [09:43] The reason is it will introduce a few code in common function(like connectedPlugAppArmor , connectedSlotAppArmor or permanent**) of commonInterface [09:43] That makes commonInterface a bit fat [09:44] that's fine [09:44] it's there to make most of the interface code easy to reason about [09:45] gary-wzl77: also, I recommend that you stick around on IRC (assuming it is not hard firewall-wise) and on the forum.snapcraft.io [09:45] sure:D [10:29] gary-wzl77: ok, starting now [10:38] zyga-ubuntu: sure thing, I also left a comment about spread-test in snap-confine. Would you mind to take a look if you find time-slot. [10:39] gary-wzl77: looking [10:41] gary-wzl77: huh, git.launchpad.net/snap-confine should be dead [10:41] gary-wzl77: which tests are you referring to? [10:50] zyga-ubuntu: just generic spread test in snap-confine folder, follow the guidance `make hack` and `run ./spread-prepare` [10:50] zyga-ubuntu: then we will have one dependency issue when building deb package along the way [10:51] gary-wzl77: in the snapd repo, in snapd/cmd/snap-confine folder? [10:52] hmmm [10:52] make hack should never be used for spread testing [10:52] can you point me to the tests you are thinking about? [10:52] yes [10:52] note that the spread tests in snap confine sub-directory are *not* working and need porting [10:52] Okay, that's it [10:58] zyga-ubuntu: I saw a few changes that we submitted recently improving the spread test for each interface. [10:59] Probably we need some tweaks then after we land udev tagging feature [10:59] definitely [11:05] PR snapd#3657 opened: daemon, client, cmd/snap: implement snap start/stop/restart [11:06] * zyga-ubuntu -> food [11:09] so, I'm stopping for lunch, and then I need to take one of the boys to the doctor. PR of services ops #n is up, hopefully alright and this PM I'll be working on completion. [11:09] * Chipaca out [11:54] Chipaca: ogra_: Hi again, do we have any news on https://bugs.launchpad.net/snappy/+bug/1687079 ? [11:54] Bug #1687079: cannot change profile for the next exec call: No such file or directory [11:56] kjackal__, what would you expect as a fix beyond a more descriptive error (i doubt mainline will want to hardcode apparmor support) ? [12:03] ogra_: that bug spawned the discussion we had last week on having daemons wait for the completion of other services before they start up [12:04] ogra_: honestly I am not sure what the fix for the above bug should be [12:05] oh, that one ... well, that discussion doesnt really look 100% related [12:05] IIRC Chipaca offered to extend the systemd unit generation with options for that ... [12:05] ogra_: Chipaca: here is the problem we are facing: https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/357 [12:05] (which should really be its own whishlist bug or even better a forum topic) [12:07] kjackal__, better make it a forum thred, so it doesnt get lost [12:07] *thread [12:08] ogra_: like this one: https://forum.snapcraft.io/t/snap-services-on-lxc-after-a-host-reboot/1470 ? [12:09] yeaah [12:10] (that doesnt reflect any of the IRC discussion though) [12:10] (IIRC there was aan offer from Chipaca for a fix ... ) [12:12] ogra_: Chipaca: we said we would setup a meeting next week with your architect, to discuss what we can do about this issue. If I am not mistaken daemons on lxd will not survive a reboot. [12:13] kjackal__, right, but i think he didnt know that niemeyer is (kind of) off this week ... [12:13] it would help if the findings from the discussion would be in the thread though ... [12:14] that forum topic is as undescriptive as it can be (like the bug :) ) [12:15] we will need it to end up with a specification what has to be implemented in snapd etc [12:15] (and how) [12:16] The issue on github is the point where we gather all the info on the incident. Should I link it to the topic? [12:18] kjackal__, i changed the title of the topic ... https://forum.snapcraft.io/t/snap-services-on-lxc-after-a-host-reboot/1470 [12:18] can you flesh the content out a bit more instead of talking about random snaps and bugs ... (like what do we want to achieve, what has been discussed and offered as possible implementation) [12:19] it should look more like a spec in the end [12:20] that way the snapd guys can just grab it, nod it off and start working on it [12:21] ok, thanks ogra_ [12:21] kjackal__, http://paste.ubuntu.com/25239691/ from my IRC logs [12:34] kjackal__: which kernel are you using? [12:36] zyga-ubuntu, not kernel related at all, see my paste [12:36] (that linking of these bugs is totally confusing the issue) [12:37] zyga-ubuntu, this is solely about snap services being able to wait for oother services to be up [12:38] (essentially about allowing "After=*" in snapd units of snaps) [12:38] aha [12:38] ok then, not my problem today :) [12:38] * zyga-ubuntu gets back to interfaces [12:39] zyga-ubuntu double check changes I commented on, I'm not sure about two changes there [12:41] ondra: thank you, I will in a moment [12:42] zyga-ubuntu I might be wrong, just double checking :) [12:43] Chipaca: question, what kind of tab completion should I get out of http? [12:43] I don't see any [12:44] zyga- it possible to run a command from inside the snap inside the configure hook? [12:45] zyga-ubuntu, it possible to run a command from inside the snap inside the configure hook? [12:45] ondra: replied [12:45] abeato: which command? [12:45] zyga-ubuntu, like using nmcli inside network-manager's configure hook [12:45] abeato: all hooks are arbitrary programs, so you can run anything you can otherwise run, remember that you are confined, as usual [12:46] abeato: one restriction is you should not run snap's exposed apps via /snap/bin/snap.app again [12:46] abeato: instead just run them directly via $SNAP/bin/app [12:47] zyga-ubuntu, it is strange because I get permissions error that should not happen if running it as root : https://pastebin.canonical.com/195195/ [12:48] oh please not that one [12:48] can you repaste to normal one, I don't have my token handy [12:49] zyga-ubuntu, http://paste.ubuntu.com/25239783/ [12:49] thank you, looking [12:49] abeato: can you show me the snap.yaml please? [12:50] zyga-ubuntu, http://paste.ubuntu.com/25239786/ [12:50] abeato, i suspect you need to connect all the interfaces the snap uses first [12:51] ogra_, they are connected [12:51] ogra_: no, not that [12:51] abeato: so [12:51] ok [12:51] abeato: notice that all the plugs are on the apps [12:51] abeato: the hooks don't get any [12:52] zyga-ubuntu, can I add plugs to the hooks? [12:52] you need to either define a plug at the top level (where it applies to everything) [12:52] Helloooo [12:52] zyga-ubuntu not sure I follow [12:52] or also add a hooks section and add specific plugs to your hook [12:53] ondra: look at that file, look at the symbols I replaced [12:53] couldnt he call the apps as well ? [12:53] aha, did not know that [12:53] zyga-ubuntu why do we need then avahiControlConnectedSlotAppArmor twice there? [12:53] zyga-ubuntu, thanks, that is useful :) [12:53] ondra: before my replacements there were unused snippets [12:53] ondra: looking [12:53] (if the apps are connected, calling them should work as well, no ?) [12:53] maybe some silly mistake on my end [12:53] ogra_: no [12:53] ogra_: the hooks have no slots [12:53] ogra_: according to that def [12:53] zyga-ubuntu and idea there was that control also includes rules from observe [12:53] oooooh [12:53] ondra: I'm blind [12:54] I didn't see the + [12:54] thanks! [12:54] zyga-ubuntu so it does not need to be defined same again there [12:54] yes, I don't know how I missed that :) [12:54] zyga-ubuntu, why would i need slots ... if i have an app "foobar" that has a plug connected, my hook shoud be able to use foobar [12:54] ondra: still, I'm somewhat inclined to use a common one [12:54] and not do + on snippets [12:54] just call the helper twice [12:54] (without any extra plugs or slots) [12:54] zyga-ubuntu don't worry I was staring at it for 5mins and even used string compare to make sure :D [12:54] ogra_: sorry, I meant plugs [12:55] ogra_: no, that's not how this is designed, the app may need super strong permissions [12:55] zyga-ubuntu ahh is that is possible then for sure calling helper twice is better [12:55] ogra_: and the hook can be separate [12:55] ogra_: like two apps can get two separate permissions [12:55] is it any different to me executing the foobar app manually ? [12:55] zyga-ubuntu shall I do the change? [12:55] ogra_: each hook and app can have a separate set of plugs [12:55] ogra_: a plug is either connected or not [12:55] hmm [12:55] ogra_: but the application of that connection is not the same to all executables [12:56] i wouldnt expect it to work like that as a consumer [12:56] ogra_: whoever is making the snap can associate a particular app or hook with a particular set of plugs [12:56] ogra_: so that you can do privilege separation inside one snap [12:56] ogra_: where nmcli doesn't need the full power to run as network-manager [12:56] ogra_: and the same thing applies to the hook [12:56] ogra_: inside that snap only network manager itself needs that [12:57] ogra_: the hook and the cli tool just need the permission to talk to it [12:57] ogra_: depending on how you define a plug it is scoped to either everything in the snap (by defining a top-level plug) [12:57] ogra_: or to a specific set of apps (by refering to a plug from their definitions) [12:57] right, and i would expect that if the cli tool is connected i could call out from any script to it to run it ... even if that script was a hook [12:57] ogra_: I think hooks have one more quirk but I'm not sure now [12:57] ogra_: right but he's not calling the CLI tool [12:58] ogra_: he's running the hook [12:58] and the hook runs as its own profile [12:58] yes, what i suggested was calling the cli tool from the hook :) [12:58] ogra_: and we don't allow profile transitions [12:58] ogra_: note that the CLI tool has two "instances" [12:58] ogra_: the /snap/bin/network-manager.cli (say) is one [12:58] ogra_: and $SNAP/bin/nmcli is another [12:58] that's the same executable [12:58] but two profiles [12:58] well [12:59] one profile and one no-profile [12:59] right [12:59] ogra_: the one in /snap sets the profile [12:59] (in /snap/bin) [12:59] and i as a user of it would expect that my script can use $SNAP/bin/nmcli [12:59] the other one runs as whoever is running it (it inherits the profile) [12:59] as long as all interfaces for it are cnnected [12:59] it can, but nmcli cannot talk to network manager because the hook doesn't have the permission to do so [12:59] wether that script is a hook or some script in my lhomedir [12:59] because as the user (developer of the snap really) that is what was specified [13:00] that seems duplicated to me [13:00] I don't understand the script in homedir aspect [13:00] ogra_: what exactly? [13:00] the only person that can alter the hook is the developer of the snap anyway [13:00] ogra_: it's like having two apps in a snap [13:00] and defining a plug on just one of them [13:00] so why do we need double confinement here [13:00] the other is not getting those permissions [13:00] that's exactly what is going on here [13:00] shipped apps should just be callable from a hook [13:00] ogra_: it's not double confinement, it's *scoping* the confinement [13:00] (as long as the app interfaces themselves are connected) [13:01] ogra_: they *are* with the permissions of the *hook* [13:01] and a hook is just as any other pap [13:01] *app [13:01] it has permissions derived from the plugs that apply to it [13:01] well, call it "wrapped confinement" then :) [13:01] its an extra level ... [13:01] and the only problem is that the *hook* was not defined as needing that permission (no plug) so it didn't et them [13:01] and i dont get why we'd need that [13:01] no, you don't understand [13:02] the hook is not calling /snap/bin/nmcli [13:02] if it did there would be a different message [13:02] that this is not allowed [13:02] Chipaca, zyga-ubuntu: standup [13:02] oh [13:02] sorry [13:02] joiuning [13:02] ogra_: let's discuss this later [13:03] i have one level of confinement in the app ... and another layer on top for the hook ... but i'm also the owner of the snap so i dont see the need for the extra confinement in the hook (just adds extra work for me to define additional slot/plug connections ... i have the power to do so anyway but need to separately declare it) [13:03] zyga-ubuntu, yeah [13:05] zyga-ubuntu I just pushed change, let me know if this is better way [13:09] nessita_, since you transferred the orangepi-zero gadget i have a giant red "REVOKED" at the top of my dashboard, is there any way to get rid of the snap from my dashboard oveview ? [13:11] ondra: thank you, I'll check after the call [13:13] zyga-ubuntu thanks :) [13:13] ogra_: those are not levels, those are scopes, each app and hook has its own confinement, you don't get any nested confinement in any place [13:14] well, i need to declare confinement stuff twice when wanting to use foobar in my hook ... once for foobar itself and once for the hook [13:14] what i mean is that any apps shipped inside the snap shouldnt require that to use them from the hook of the same snap [13:15] you *never* apply the conifnement to binaries in the snap [13:16] you only apply them to launchers (the command: section in each app) [13:18] yes [13:19] and my hook should be able to use them from the launchers ... thats what i mean [13:19] without having to specify any additional confinement [13:22] it can, that's never the problem, the problem is that they cannot do what they want because how would we know what they need? [13:22] you can *exec* each binary in your snap [13:22] no, then the interfaces for the app dont apply [13:22] nmcli talks over dbus with network-manager [13:22] binary != app [13:22] app is a command [13:22] what if I have two apps [13:22] that run one binary [13:23] with two different options [13:23] right and there is an interface that applied if i call it as /snap/bin/nmcli [13:23] and two different permissions? [13:23] *applies [13:23] yes but you cannot call that from inside a snap, that's explicitly denied [13:23] instead of $SNAP/usr/bin/nmcli directly [13:23] yes [13:23] and thats what i'm debating ;) [13:23] that /snap/bin/nmcli should be allowed? [13:23] an app shipped inside my own snap shouldnt be denied when called from inside that same snap [13:24] so that i can use it from a hook without having to jump through hoops [13:24] man, that's not the problem [13:24] one sec [13:24] indeed the dbus interface still needs to be connected for the app [13:24] (which my hook cant do) [13:26] ogra_: http://pastebin.ubuntu.com/25239924/ [13:26] yeah [13:26] ogra_: what permissions would you expect to see if the hook runs bin/foo? [13:26] well, my hook should run /snap/bin/a (or b) [13:26] and the normal confinement for a or b should apply [13:27] so that my hook doesnt need any different or separate confinement [13:27] right [13:27] that I agree with [13:27] but this is not allowed today for a few reasons [13:28] and in that case the answer to alfonso above would have been use /snap/bin/nmcli and be done [13:28] the thing is that the person writing the hook has the power to allow this anyway ... [13:28] but needs to jump through more hoops by defining interfaces for the hook today [13:29] apps declared in my snapcraft.yaml shoudl just be usable from my hook without extra work ... thats the point i'm making :) [13:30] ogra_: right, and that's, as I said, not allowed for a few reason [13:30] *reasons [13:30] i dont see any security advantage of the current model [13:30]