[07:12] <zyga> good morning
[07:22] <mardy> zyga: hi! Long time no see :-)
[07:22] <zyga> hey mardy :)
[07:23] <zyga> I'm back in my office _finally_
[07:23] <zyga> after nearly two weeks of summer holidays and travel and working from weird places
[07:26] <mardy> uh, summer holidays, that must have been horrible! ;-)
[07:28] <zyga> mardy, yes when it's not for you but for your family ;)
[07:28] <zyga> and you work from the back seat
[07:41] <mardy> hehe :-)
[07:42] <zyga> mardy, over the years I've been following my family, working, wherever they go 
[07:47] <mardy> next year hopefully you'll have accumulated some holidays of your own
[08:20] <mardy> can someone please confirm, that calling i18n.G() from inside snapd does not make much sense (and we should use it on the clients only)? Or does i18n.G() have some way to know the locale of the client, and does the right thing even when run from inside snapd?
[08:34] <zyga> mardy, I think it still makes sense, it's likely that the system wide locale is consistent and the messages are useful in general
[08:34] <zyga> I recognize the general issue though
[08:50] <mardy> zyga: I see, that's also true. But you do agree that the solution suggested here is better? https://github.com/snapcore/snapd/pull/10606#discussion_r687857298
[08:50] <mup> PR #10606: o/hookstate/ctlcmd: unify the error message when context is missing <Simple 😃> <Created by mardy> <https://github.com/snapcore/snapd/pull/10606>
[08:52] <mardy> but it's far from being trivial to implement
[10:13] <zyga_> mardy, yes this is true
[10:13] <zyga_> mardy, it's the good old API problem
[10:14] <zyga_> and "error codes"
[11:33] <mup> PR snapd#10613 opened: interfaces/builtin/firewall_control: allow ufw accesses <Created by mardy> <https://github.com/snapcore/snapd/pull/10613>
[13:08] <mup> PR core18#180 opened: Generate dpkg.yaml <Created by ilasc> <https://github.com/snapcore/core18/pull/180>
[13:28] <mup> PR snapd#10614 opened: tests: new function to detect installed packages <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10614>
[14:37] <mardy> is snapd or snapcraft treating iptables in some special way? I'm trying to modify this snap to use ufw instead, but it's never found: https://github.com/snapcore/snapd/blob/master/tests/main/interfaces-firewall-control/firewall-control-consumer/meta/snap.yaml
[14:37] <mardy> in the host system it's in /usr/sbin/ufw (iptables is in the same dir)
[14:37] <ijohnson[m]> mardy: what do you mean ? like ufw is not found inside the snap?
[14:37] <mardy> from inside the snap, "which iptables" gives /sbin/iptables
[14:37] <mardy> ijohnson[m]: exactly, iptables is found, ufw is not
[14:38] <ijohnson[m]> mardy: hmm is ufw in the base snap? 
[14:39] <mardy> ijohnson[m]: ah, it's not in ls /snap/core/current/sbin/ at least (whereas iptables is there)
[14:40] <mardy> ijohnson[m]: ah, is this the issue we were discussing with the microk8s guys, when you said that they need to ship the binary themselves?
[14:43] <ijohnson[m]> mardy: which base snap are you using ?
[14:43] <ijohnson[m]> though interestingly core20 only has `/snap/core20/current/etc/ufw` in it, no actual ufw binary
[14:43] <ijohnson[m]> I seem to recall jdstrand saying something about ufw in core20 / focal ... I don't remember what though :-)
[14:44] <ijohnson[m]> mardy: anyways in the sort term the right thing is probably the same as what we discussed yes, just ship ufw in your snap instead of trying to consume from the base snap
[14:44] <mardy> ijohnson[m]: I can I check? I'm acually playing in the spread image google:ubuntu-20.04-64
[14:44] <jdstrand> I needed to make changes to ufw so the snap could be made to work with core20
[14:44] <ijohnson[m]> mardy: what's the snap.yaml
[14:44] <ijohnson[m]> oh hi jdstrand !
[14:44] <jdstrand> /etc/ufw in the core20 snap would be a mistake in the core20 snap
[14:44] <jdstrand> hi!
[14:45] <mardy> hi :-)
[14:45] <mardy> ijohnson[m]: the snap.yaml is https://github.com/snapcore/snapd/blob/master/tests/main/interfaces-firewall-control/firewall-control-consumer/meta/snap.yaml
[14:45] <jdstrand> fyi, I gave a detailed response just now: https://github.com/snapcore/snapd/pull/10613#pullrequestreview-729689088
[14:45] <mup> PR #10613: interfaces/builtin/firewall_control: allow ufw accesses <Created by mardy> <https://github.com/snapcore/snapd/pull/10613>
[14:45] <ijohnson[m]> jdstrand: so what changes to ufw need to be made to work in a core20 based snap?
[14:46] <ijohnson[m]> thanks jdstrand  for that!
[14:47] <ijohnson[m]> mardy: so since that snap.yaml does not have a `base` it is implicity using `core` as it's base, i.e. 16.04
[14:50] <mardy> jdstrand: just read your response; thanks a lot! It's indeed way more trivial than I though. But it seems you are also implying that the whole firewall-control interface we have now is not such a good idea, as it's very iptables specific (and should be called iptables-control, probably)
[14:50] <mardy> s/trivial/conplex/ :-D
[14:50] <jdstrand> ijohnson[m]: I made those changes already to the ufw snap and it is all upstream in master and the edge snap. *but* see my comment. note, I'm heading into a meeting and can't discuss this, but I hope I laid out enough info for you
[14:50] <mardy> "complex", oh, what's wrong with me :-)
[14:51] <jdstrand> mardy: it is, though nftables should be supported imo
[14:52] <ijohnson[m]> jdstrand: that all makes sense, thanks for sharing!
[14:52] <jdstrand> mardy: an argument could be made to allow cli utilities that use ipc. firewalld might fit into that. note, firewall-control is ancient and one of the first so we didn't yet have our experience with interfaces
[14:52] <ijohnson[m]> mardy: maybe you could relay this over to the k8s folks to see what they think? honestly I don't know in what way microk8s is driving firewall things
[14:53] <jdstrand> mardy: the thing is, none of these firewall programs are ubiquitous, except iptables (and nftables, sorta, but you gotta be careful which to choose (see ufw and lxd for how they decide)
[14:54] <jdstrand> which suggests to me that separate, specific -control interfaces are likely appropriate
[14:54] <jdstrand> mardy: though, even though firewall-control is ancient, we did think through it
[14:55] <jdstrand> mardy: network-control is to network-manager as firewall-control would be to {ufw,firewalld,shorewall,etc}-control
[14:55] <jdstrand> ok, gotta run! :)
[14:56] <jdstrand> fwiw, I suggest 'a' or if that proves difficult, 'b'
[14:57] <jdstrand> I haven't tried 'a', it might be a little finicky
[14:57] <jdstrand> s/finicky/fiddly/
[14:59] <mup> PR snapd#10615 opened: Revert "cgroup-support: allow to hide cgroupv2 warning via ENV" <Created by slyon> <https://github.com/snapcore/snapd/pull/10615>
[15:49] <mup> PR snapd#10612 closed: tests: fix core-early-config test to use tests.nested tool <Run nested> <Created by sergiocazzolato> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/10612>
[16:57] <ijohnson[m]> is the forum down for anybody else? forum.snapcraft.io is not responding to pings for me
[17:57]  * cachio afk