[00:25] <mup> PR snapcraft#2878 closed: extensions: fix merging of build-environment <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2878>
[00:25] <zylop> everyday less channels interesting here
[00:25] <zylop> after an uodate from 28.8bps modem to a 5Mbps fiber t1 Line
[00:25] <zylop> its sad
[00:26] <zylop> at least #snappy doesnt have trolls thank god
[00:27] <zylop> well too late for chat today, maybe i'll create a project called aspies/will/be/ddosed
[00:27] <zylop> ciao and thanks
[00:45] <cjp256> ijohnson: yes, thanks! https://github.com/travis-ci/dpl/pull/1154
[00:45] <mup> PR travis-ci/dpl#1154: Update snapd <Created by BanzaiMan> <https://github.com/travis-ci/dpl/pull/1154>
[06:41] <mborzecki> morning
[08:14] <zyga> almost te
[08:14] <zyga> re
[08:14] <zyga> outside is lovely today
[08:14] <zyga> pstolowski: how does it look like outside for you?
[08:18] <pstolowski> zyga: hey, chilly (-1C) but sunny
[08:29] <mborzecki> zyga: pstolowski: -1 here too, mornig frost everwhere, yesteday evening was -3 and super foggy (no surprise though, +10 during the day)
[08:36] <zyga> re
[08:36] <zyga> -2 here when I woke up
[08:36] <zyga> and fog thick like cream
[08:36] <zyga> https://usercontent.irccloud-cdn.com/file/Phm3QnMj/image.png
[08:37] <zyga> when I finally got out to take Bit for a walk it was clearing
[08:37] <zyga> but still foggy
[08:37] <zyga> last night I read a little about table layout problem
[08:37] <zyga> and I decided not to  :)
[08:37] <zyga> at least not during work hours
[08:37] <zyga> it's a significant chunk of work
[08:37] <zyga> today I'll start with selinux
[08:39] <sdhd-sascha> good morning :)
[08:39] <sdhd-sascha> what is table layout problem ?
[08:39] <zyga> sdhd-sascha: you have a table comprised of cells
[08:39] <pstolowski> zyga: what about selinux?
[08:39] <zyga> sdhd-sascha: some cells may span several rows or columns
[08:39] <zyga> sdhd-sascha: each cell has text inside
[08:40] <zyga> sdhd-sascha: text can wrapped according to typical rules (e.g. break on spaces)
[08:40] <zyga> sdhd-sascha: the problem is
[08:40] <zyga> sdhd-sascha: given set width
[08:40] <zyga> sdhd-sascha: compute the minimum height of the table
[08:40] <zyga> sdhd-sascha: this is NP complete
[08:40] <zyga> sdhd-sascha: then you have more constraints, e.g. to make text look good according to some optimization function
[08:40] <zyga> sdhd-sascha: there are some heuristics to follow (that all the implementations use)
[08:41] <sdhd-sascha> ah, ok, cool
[08:41] <zyga> sdhd-sascha: there are perfect solutions using very expensive algorithms, mainly to measure the speed and quality of a given heuristic
[08:41] <sdhd-sascha> sounds like perfect for functional programming and recursion
[08:41] <zyga> sdhd-sascha: but they all involve heavy math and optimization problems
[08:41] <zyga> sdhd-sascha: linear algebra, dynamic programming
[08:42] <zyga> sdhd-sascha: not "I'll write this after reading a paper" in one evening
[08:42] <zyga> sdhd-sascha: the problem of figuring out how to size a cell is called cell configuration
[08:43] <zyga> sdhd-sascha: and each cell has a finite set of configurations
[08:43] <zyga> sdhd-sascha: typically one is best but it's quadratic or O(N^2/3) at best with tricks  to find cell configuration that's good
[08:43] <zyga> sdhd-sascha: that's per cell with N being word legth
[08:43] <zyga> *count
[08:43] <zyga> sdhd-sascha: anyway
[08:43] <zyga> sdhd-sascha: it's fun but not for work
[08:44] <sdhd-sascha> zyga: maybe, find the cell with the least possibilities. Then call the next, with least possibilities... Could be a starting point
[08:45] <sdhd-sascha> zyga: yes, that's really fun :-) And true, it needs time
[08:45] <zyga> This problem has been researched since 1960s
[08:45] <zyga> There are lots of good algorithms but they are all complex to implement
[08:45] <sdhd-sascha> 1960s - hmm, sounds like functional programming
[08:46] <sdhd-sascha> it's sure a compination of bread first and deep first searches
[08:46] <sdhd-sascha> combination - (sorry)
[08:47] <zyga> https://people.eng.unimelb.edu.au/gkgange/pubs/table_11.pdf
[08:48] <sdhd-sascha> and, sorry not "bread" - i mean breadth-first
[08:48] <sdhd-sascha> cool - thank you :-)
[08:50] <sdhd-sascha> zyga: hmm - because of the symlink not possible problem in snap. I will give the user at first a setup.sh script like alan it does.
[08:50] <sdhd-sascha> Maybe i can set an alias after the first start from setup-script to real-app.
[08:54] <zyga> we should discuss the problem
[08:54] <zyga> and come up with a strategy to fix it
[08:55] <zyga> pstolowski: I have a selinux denial to fix in my pR
[08:57] <pstolowski> ic
[09:07] <jamesh> zyga: while updating one of my PRs related to portal support, I noticed that a test I'd added was failing on Fedora 31 due to it using cgroups v2.  Is that something that is likely to be fixable?
[09:08] <zyga> jamesh: can you be more specific please?
[09:08] <zyga> jamesh: I have this for cgroupv2 https://github.com/snapcore/snapd/pull/7825
[09:08] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[09:08] <zyga> jamesh: but it needs another review
[09:08] <zyga> it's open since november
[09:08] <jamesh> zyga: it was code using this snapFromPid() code: https://github.com/snapcore/snapd/blob/master/usersession/userd/helpers.go#L76
[09:08] <zyga> jamesh: ah, yes
[09:09] <jamesh> which has a "if cgroup.IsUnified()" error case at the top
[09:09] <zyga> jamesh: I need to look but I think can be fixed
[09:09] <zyga> jamesh: we have some generic code in sandbox/cgroup
[09:09] <zyga> jamesh: so I think the answer is "yes"
[09:10] <zyga> jamesh: it literally needs reviews and nothing else I think
[09:10] <jamesh> zyga: I'm mainly concerned because I'd like to reimplement a quick "is this a snap?" check for xdg-desktop-portal itself (to replace the one relying on AppArmor)
[09:10] <zyga> yeah I remebmer that
[09:10] <zyga> I think mvo is trying to get reviews to work better
[09:10] <zyga> specifically security reviews
[09:11] <jamesh> and if the freezer cgroup thing can't be relied on in the snapd code, then I probably shouldn't be writing more code that uses that method
[09:11] <zyga> it cannot be relied on
[09:11] <jamesh> I remember at one point you'd talked about having some kind of marker file in the snap's mount namespace
[09:12] <zyga> jamesh: yes, we explored many ideas
[09:12] <zyga> jamesh: right now I cannot promise you the inode idea gets implemented
[09:12] <zyga> jamesh: but the cgroup idea is very close and seems to be entirely generic as well
[09:12] <zyga> jamesh: and all you need is one read() call to see which snap a process belongs to
[09:14] <jamesh> but it'd be a different check compared to what that function is currently doing?
[09:14] <zyga> jamesh: yes
[09:15] <zyga> jamesh: the PR I referenced changes most (need to see if it changes userd code, I wasn't aware it does this)
[09:16] <jamesh> zyga: I was looking at moving that utility function out of userd, so it could be used by the "snap routine portal-info" command
[09:16] <jamesh> but it is still essentially the same code
[09:16] <zyga> yeah I think it should move to sandbox
[09:16] <zyga> mainly because it's one implementation over many
[09:21] <zyga> jamesh: FYI I will land https://github.com/snapcore/snapd/pull/7238
[09:21] <mup> PR #7238: usersession: add systemd user instance service control to user session agent <Needs Samuele review> <Security-High> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7238>
[09:21] <zyga> jamesh: as soon as it goes green
[09:21] <zyga> jamesh: oh, and I have a question for you
[09:21] <jamesh> zyga: thanks
[09:22] <zyga> jamesh: is https://github.com/snapcore/snapd/pull/7589 ok?
[09:22] <zyga> jamesh: Samuele asked you to changed the PR description
[09:22] <mup> PR #7589: cmd/snap: add ability to register "snap routine" commands <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589>
[09:22] <zyga> but I wasn't following the history and not sure if you did or not
[09:22] <zyga> jamesh: can you comment  there please
[09:23] <jamesh> zyga: yep.  The initial comment was edited as requested.
[09:23] <zyga> excellent
[09:24] <zyga> I'll merge it as well
[09:24] <zyga> I'll just merge master into it to ensure it's green still
[09:25] <jamesh> zyga: out of interest, where in the sandbox package do you think that snapFromPid() function would best belong?
[09:26] <zyga> jamesh: sandbox/cgroup as it models the source of that information
[09:27] <jamesh> okay.  I was just wondering since the API is not particularly cgroup specific
[09:28] <jamesh> it currently uses cgroups, but that seems like an implementation detail
[09:33] <zyga> jamesh: yeah but that's how the sandbox package is modeled now, if it changes we can just adjust the calling code; I think it's more important to have one implementation than an abstract entry point
[09:33] <zyga> (we can have both eventually)
[09:33] <jamesh> fair enough
[09:51] <zyga> mborzecki: I cannot understand that selinux denial at all, looking at selinux policy now
[09:51] <mborzecki> zyga: got the avc log?
[09:51] <zyga> mborzecki: same as before but that's not the point
[09:51] <zyga> mborzecki: the denial is new
[09:51] <zyga> mborzecki: the denial comes from snap-discard-ns
[09:51] <zyga> mborzecki: using setegid
[09:51] <zyga> mborzecki: which it starts to in this PR
[09:52] <zyga> mborzecki: the point is - how can this be denied when it runs as root and snap-confine can setegid all it wants
[09:52] <zyga> and it calls setegid just prior to the fork/exec call
[09:52] <zyga> mborzecki: I must be missing something :/
[09:53] <mborzecki> zyga: can you paste that denial? con't find it in history
[09:53] <zyga> sure, one sec
[09:53] <mup> PR snapcraft#2882 closed: extensions: change extension merge-strategy to fix build-environment <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2882>
[09:53] <zyga> type=AVC msg=audit(01/16/20 18:15:29.361:1557) : avc:  denied  { setgid } for  pid=13356 comm=snap-discard-ns capability=setgid  scontext=system_u:system_r:snappy_mount_t:s0 tcontext=system_u:system_r:snappy_mount_t:s0 tclass=capability permissive=1
[09:54]  * Chipaca prepping for the trip
[09:55] <pedronis> mborzecki: mvo: hi, #7992 needs 2nd reviews and some tweaks (see my own review comments)
[09:55] <mup> PR #7992: bootloader: add ExtractedRunKernelImageBootloader interface, implement in grub <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7992>
[09:55] <mborzecki> pedronis: i can take care of the tweaks
[09:56] <pedronis> mborzecki: thx, please double check that my suggestions make sense
[09:56] <mborzecki> pedronis: ok
[09:59] <mup> PR snapcraft#2847 closed: Catkin plugin: consider only 'local' workspaces <Created by artivis> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2847>
[10:00] <mborzecki> zyga: hm does s-d-n explicitly setgid?
[10:00] <zyga> mborzecki: yes, but it runs as root at that time
[10:01] <mborzecki> zyga: that's the point of selinux, even though it runs as root, the policy is in effect
[10:01] <zyga> mborzecki: snap-confine doesn't run with egid=0
[10:01] <zyga> so it switches to egid=0 and back all the time
[10:01] <zyga> ?
[10:01] <zyga> sure
[10:01] <zyga> but
[10:01] <pedronis> mvo: open PRs have grown quite a bit again :/
[10:02] <zyga> why nothing for snap-confine
[10:02] <zyga> is it a separate policy?
[10:02] <mvo> pedronis: yeah, today is a busy day for me but I will try to do some more reviews
[10:02] <mborzecki> zyga: s-c already has setgid
[10:02] <zyga> ahhh
[10:02] <mborzecki> zyga: so selinux policy can actually confine root ;)
[10:03] <zyga> sure
[10:03] <zyga> I assumed that snap-confine policy would apply to snap-update-ns invoked from snap-confine
[10:03] <zyga> not that it would have a standalone policy
[10:03] <pedronis> zyga: my first impulse feeling on #8008 is that is too big
[10:03] <mup> PR #8008: render: add the render package and basic widgets <Created by zyga> <https://github.com/snapcore/snapd/pull/8008>
[10:03] <mborzecki> zyga: no, s-u-n and s-d-n are run with snappy_mount_t context which has a separate policy
[10:05] <Wouter0100> Hey guys! Is there any timeline/progress on RPi4 support for Ubuntu Core? :D Curious, as we don't want to be stuck on RPi3 if I start building using Core now
[10:06] <mborzecki> zyga: i see there's an entry with `allow snappy_mount_t self:capability {..}`, add setgid there
[10:07] <Chipaca> pedronis: looking at how o/auth handles user addition and removal, don't we need a graveyard for users?
[10:07] <Chipaca> pedronis: if you don't know offhand i can dig myself :)
[10:07] <zyga> mborzecki: I see snappy_mount_exec_t
[10:07] <zyga> is that the type?
[10:08] <pedronis> Chipaca: I'm not even sure I understand the question tbh
[10:08] <zyga> mborzecki: I don't see where it gets any permissions yet
[10:08] <Chipaca> pedronis: you know how we do refreshes bunched by user id
[10:08] <mborzecki> zyga: nope, snappy_mount_t, around like 426 in snappy.te
[10:08] <pedronis> Chipaca: yes
[10:08] <Chipaca> pedronis: when a user logs out, we delete the user completely
[10:08] <Chipaca> pedronis: if they then log back in they get a new id
[10:09] <zyga> mborzecki: how is snappy_mount_t related to snap-discard-ns?
[10:09] <mborzecki> zyga: https://paste.ubuntu.com/p/P4q7VYpMh7/
[10:09] <Chipaca> unless i'm missing something, that means the refreshes will be wrong?
[10:09] <Chipaca> as in, they'll be done as root from there on
[10:09] <pedronis> Chipaca: aren't the ids always growing
[10:09] <Chipaca> pedronis: yes
[10:09] <pedronis> we don't recycle ids, or do we
[10:09] <Chipaca> pedronis: no we don't
[10:10] <pedronis> Chipaca: well, the refreshes will already be not working once they log otu
[10:10] <Chipaca> pedronis: but shouldn't they work again once they log back in
[10:10] <zyga> mborzecki: but how is that related?
[10:10] <zyga> *related
[10:10] <pedronis> Chipaca: maybe yes
[10:11] <Chipaca> pedronis: i know this sounds related to my current work but it's actually because i resucitated an old laptop and the macaroon had expired so i logged out and back in and that got me thinking
[10:11] <mborzecki> zyga: both do stuff with mounts, so instead of making it even more fine grained both get the snappy_mount_t policy
[10:11] <pedronis> Chipaca: you basically are saying that we should reuse the id if matching email
[10:11] <pedronis> or something
[10:11] <zyga> I mean how is snap-discard-ns associated with snappy_mount_t
[10:11] <Chipaca> pedronis: meaning we should keep a graveyard of sorts to remember those things
[10:11] <mborzecki> zyga: how does selinux figure that out?
[10:12] <pedronis> Chipaca: what happens if you don't logout but login again?
[10:12] <zyga> my point is that I cannot trace anything from snap-discard-ns
[10:12] <pedronis> do we error?
[10:12] <zyga> to that place where you say to patch things
[10:12] <pedronis> or do something else?
[10:12] <pedronis> or it's a nop
[10:12] <pedronis> (I don't remember myself)
[10:13] <mborzecki> zyga: quick HO?
[10:13] <zyga> mborzecki: how are those entries connected
[10:13] <zyga> mborzecki: sure
[10:14] <Chipaca> pedronis: looks like you get new macaroni
[10:14] <Chipaca> pedronis: it works
[10:14] <Chipaca> pedronis: (so yes i should've done that)
[10:14] <pedronis> Chipaca: ok, so we have an issue but is not as bad as it could be
[10:14] <Chipaca> pedronis: yep
[10:14] <Chipaca> well, the error could be better
[10:15] <Chipaca> you just get an opaque 'invalid credentials'
[10:15] <Chipaca> but not clear we can improve on that easily
[10:15] <pedronis> Chipaca: we need to think a bit, can you create a bug or something
[10:15] <pedronis> to remember this
[10:16] <Chipaca> yes
[10:16] <pedronis> thx
[10:23] <Chipaca> pedronis: https://bugs.launchpad.net/snapd/+bug/1860102
[10:23] <mup> Bug #1860102: snap logout and snap login with same account creates new user <snapd:New> <https://launchpad.net/bugs/1860102>
[10:23] <pedronis> Chipaca: thanks, tracking as mine for now
[10:23] <Chipaca> pedronis: 👍
[10:24]  * Chipaca goes back to laptop resuscitation
[10:27] <mup> PR snapd#7238 closed: usersession: add systemd user instance service control to user session agent <Needs Samuele review> <Security-High> <Created by jhenstridge> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7238>
[10:27] <pedronis> jamesh: hi, could you add the comment jdstrand asked for in #7555, then it could be merged
[10:27] <mup> PR #7555: tests: add a test demonstrating that snaps can't access the session agent socket <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7555>
[10:29] <zyga> good luck Chipaca
[10:31] <mborzecki> https://github.com/snapcore/snapd/pull/8013 needs 2nd review
[10:31] <mup> PR #8013: cmd/snap-bootstrap: check device size before boostrapping and produce a meaningful error <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8013>
[10:31]  * zyga looks
[10:33] <zyga> mborzecki: is https://github.com/snapcore/snapd/pull/8013/files#diff-01caa2f676929e8131f31685ae61203cR216 a separate error that is fixed in this branch?
[10:33] <mup> PR #8013: cmd/snap-bootstrap: check device size before boostrapping and produce a meaningful error <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8013>
[10:34] <mborzecki> zyga: yes, separate patch in that branch
[10:34] <zyga> mborzecki: I have a small comment on the size code
[10:37] <mup> PR snapd#7366 closed: interfaces/gpg-keys: Allow access to gpg-agent and creation of lockfiles <Created by ppd1990> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7366>
[10:44] <mup> PR snapcraft#2883 opened: docker: add core18 snap that snapcraft now uses as a base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2883>
[10:46] <sdhd-sascha> Can i anything do, for #7927 ? I still need a patched `snapd` to start sway on classic ubuntu.
[10:46] <mup> PR #7927: interfaces: x11 allow apparmor on classic <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7927>
[10:47] <pedronis> sdhd-sascha: is not green atm, and needs a jdstrand review (he is off this week)
[10:48] <sdhd-sascha> pedronis: ok, i rebase it to current master
[10:49] <zyga> mborzecki: I opened https://github.com/snapcore/snapd/pull/7980 for review now - the SELinux denial is gone
[10:49] <mup> PR #7980: packaging,snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7980>
[11:17]  * Chipaca brb
[11:19] <mup> PR snapd#8017 closed: tests: add ubuntu 20.04 to the tests execution and remove tumbleweed from unstable <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8017>
[11:21] <sdhd-sascha> Hi, as you know, i never worked with golang before. Is there a way to reset the source to a clean working state ? I deleted snapd/cmd/VERSION. And it's in `.gitignore`. So i wonder, how to reset without `go get ...`
[11:24] <mup> PR snapd#8012 closed: o/devicestate: do not create perfTimings if not needed inside ensureSeed/Operational <Simple 😃> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8012>
[11:24] <pstolowski> sdhd-sascha: reset the git working dir of a project? 'git clean -xfd', beware it will forcefully remove any uncommited stuff in the working tree without asking
[11:26] <mup> PR snapd#8006 closed: tests: skip interfaces-network-manager on arm devices <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8006>
[11:27] <sdhd-sascha> pstolowski: thank you. I found mkversion.sh. But it's confusing if you change the branch and then the version remains nearly the same.
[11:27] <sdhd-sascha> I build 2.43 and wonder, why it still reports 2.42 ...
[11:28] <zyga> mborzecki: :) https://github.com/snapcore/snapd/pull/8016
[11:28] <mup> PR #8016: gitignore: ignore snap files <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8016>
[11:30] <mup> PR snapd#8016 closed: gitignore: ignore snap files <Simple 😃> <Created by anonymouse64> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8016>
[11:41] <zyga> pedronis__: does your blocked label mean that no progress can be done on the render branch for the next week?
[11:42]  * zyga jumps into https://github.com/snapcore/snapd/pull/7614
[11:42] <mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
[11:47] <sdhd-sascha> Hey, i read a lot of MAAS snap here. Is it in the store ? Or did i need to build it myself?
[11:48] <Chipaca> sdhd-sascha: I think it's unlisted until default tracks work, as upgrades from latest to 2.7 are painful
[11:49] <Chipaca> sdhd-sascha: but if you find sparkiegeek they might know more
[11:49] <Chipaca> (default tracks should be working on edge! woop woop)
[11:53] <sdhd-sascha> Chipaca: thank you. I'm already on 2.7 on local installation and want to migrate to snap.
[11:54] <Chipaca> sdhd-sascha: note the versions in 'snap info maas'
[11:55] <sdhd-sascha> hmm, i found it. thank you :)
[11:56] <sdhd-sascha> Chipaca: did you know if there is a maas-rack and/or maas-region snap ? Or is it all-in-one ? If you didn't know. Then i will figure it out. No stress ;-)
[11:56] <Chipaca> sdhd-sascha: I don't know either :) I know next to nothing about maas in fact
[11:58] <sdhd-sascha> Chipaca: I am also at the experimental level. would like to use maas with lxd and juju.
[11:59] <Chipaca> sdhd-sascha: #maas, maybe? (dunno)
[12:08] <pedronis> Chipaca: I think #7589 could land once green, can you quickly double check it again
[12:08] <mup> PR #7589: cmd/snap: add ability to register "snap routine" commands <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589>
[12:33]  * zyga looks at another PR
[12:35] <mup> PR snapd#7623 closed: tests: check world-writable and test-owned files <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7623>
[12:35] <cachio> mborzecki, hello
[12:35] <cachio> I am reviewing a failing test
[12:35] <cachio> selinux-clear which is failing on centos
[12:36] <cachio> mborzecki, this is the error https://paste.ubuntu.com/p/5DxBHnD93d/
[12:36] <cachio> seems to be real
[12:38] <mborzecki> cachio: hah, yeah, known problem, i'll update the policy, keeping centos in unstable systems doesn't help with catching issues like this one early
[12:38] <cachio> mborzecki, nice, thanks for the confirmation
[12:49] <pstolowski> cachio: updated #7871, thanks for pointing out pkgdb
[12:49] <mup> PR #7871: tests: add spread test for hook permissions <Created by stolowski> <https://github.com/snapcore/snapd/pull/7871>
[12:49] <cachio> pstolowski, yaw
[12:54] <mup> PR snapd#7875 closed: interfaces: refactor path() from raw-volume into utils with comments for old <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7875>
[12:57] <pedronis> mborzecki: am I misreading or #7845 should be closed ?
[12:57] <mup> PR #7845: cmd: add prefix to SYSTEMD_SYSTEM_GENERATOR_DIR <Simple 😃> <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7845>
[12:58] <mborzecki> pedronis: IMO yes, the problem should be addressed in systemd (if ever)
[12:59] <pedronis> ok
[13:00] <mup> PR snapd#7845 closed: cmd: add prefix to SYSTEMD_SYSTEM_GENERATOR_DIR <Created by sd-hd> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7845>
[13:03] <mborzecki> added a note to 7845 with some suggestions on hot to approach this sdhd-sascha, it'd be nice to hear what upstream systemd suggest to use there
[13:06]  * sdhd-sascha I'm back later. And look
[13:10] <Chipaca> pedronis: agreed, 7589 can land once green
[13:11] <pstolowski> pedronis: can we land #7934, and potentially address ijohnson's suggestion re test refactor in a followup?
[13:11] <mup> PR #7934: o/ifacestate,o/devicestatate: merge gadget-connect logic into auto-connect <Created by pedronis> <https://github.com/snapcore/snapd/pull/7934>
[13:13] <pedronis> pstolowski: yes, I suspect it would be good to fix the misleading comment though
[13:15] <pedronis> pstolowski: I'm taking care of that
[13:15] <pstolowski> pedronis: ty
[13:18] <pedronis> pstolowski: done, let's see if it gets green again
[13:20] <Chipaca> pedronis: btw, did you see https://forum.snapcraft.io/t/snapctl-changing-channel-ability/14900?u=chipaca ?
[13:20] <pedronis> Chipaca: yes, I don't think is something we want to let snap do
[13:20] <pedronis> in general
[13:20] <Chipaca> pedronis: right, not like that, but then they ask for more nuanced things in https://forum.snapcraft.io/t/snapctl-changing-channel-ability/14900/3?u=chipaca
[13:21] <Chipaca> some of them we already wanted (were already implementing?)
[13:21] <Chipaca> i mean, the 'are there updates in the current channel' one i thought was roadmapped even
[13:21] <pedronis> yes
[13:22] <pedronis> even refresh it's probably doable with some user confirmation
[13:22] <Chipaca> pedronis: 'reading current channel' seems a'ight, also
[13:22] <pedronis> changing channel likely not
[13:22] <zyga> brb
[13:22] <Chipaca> agreed, not without some way of asking the user
[13:29] <mborzecki> https://github.com/snapcore/snapd/pull/8005 needs a 2nd review
[13:29] <mup> PR #8005: api: don't return connections referring to non-existing plugs/slots <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8005>
[13:29] <zyga> looking
[13:31] <pedronis> Chipaca: answered or tried to
[13:31] <Chipaca> pedronis: some from → some form
[13:31] <Chipaca> :)
[13:31] <pedronis> Chipaca: yea, fixed
[13:31] <pedronis> already
[13:32] <Chipaca> pedronis: having to check version info to know channel breaks QAing a snap along channels though
[13:33] <pedronis> Chipaca: I don't know, there is a list of features there, not use cases
[13:33] <Chipaca> pedronis: I've been tempted to make snapd always log verbosely when in edge or beta, for example
[13:33] <pedronis> I would like to understand the use case more
[13:33] <Chipaca> pedronis: yep yep
[13:34] <zyga> hmm
[13:34] <zyga> pstolowski: do you remember the discussions from Malta about how we want to show connections
[13:34] <pedronis> Chipaca: is it realy about risks or is it about tracks?
[13:34] <pedronis> etc
[13:34] <zyga> pstolowski: when the thing is not present (e.g. dead hotplug connection)
[13:34] <Chipaca> pedronis: k
[13:34]  * zyga wonders where the notes from Malta might be
[13:34] <zyga> I recall gustavo recorded those in a web tool of some sort
[13:34]  * zyga looks
[13:38] <pedronis> afaik the agreement was then copied into: https://forum.snapcraft.io/t/snap-connections-command/4296/20
[13:38] <pedronis> and is what was implemented
[13:42] <mborzecki> hmm something still not right in 7992
[13:44] <pstolowski> zyga: i remember the topic and the general idea, but not details, i don't think we had a concrete plan
[13:44] <zyga> pstolowski: I'm looking into this
[13:44] <pstolowski> zyga: is this wrt my PR?
[13:44] <zyga> yep
[13:45] <zyga> give me a moment to go through what we planned to do
[13:45] <pstolowski> zyga: my PR is not closing any doors, but atm user experience is confusing. i made a comment in the code about what needs tweaking when we have an egreement
[13:46] <ijohnson> morning folks
[13:46] <pstolowski> ijohnson: hi!
[13:46] <ijohnson> thanks mborzecki and pedronis for the reviews/commits to the kernel things
[13:46] <ijohnson> hi pstolowski
[13:46] <mborzecki> ijohnson: hi, i'll push one more patch if you don't mind
[13:46] <ijohnson> mborzecki: go for it
[13:57] <mborzecki> ijohnson: ok, pushed now ;)
[13:57] <ijohnson> thanks!
[13:57] <zyga> pstolowski: reviewed
[13:57] <zyga> https://github.com/snapcore/snapd/pull/8005#pullrequestreview-344593087
[13:57] <zyga> oh
[13:57] <zyga> standup
[13:57] <mup> PR #8005: api: don't return connections referring to non-existing plugs/slots <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8005>
[13:58] <pstolowski> zyga: ty!
[14:15] <mup> PR snapd#8005 closed: api: don't return connections referring to non-existing plugs/slots <Bug> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8005>
[14:16] <cjp256> zyga: sergiusens suggested you might know... when I have a slot defined `slot: mpris: {interface: mpris, name: foo}` , review-tools fails with `"human review required due to 'deny-connection' constraint (interface attributes)"`
[14:17] <cjp256> review-tools specifically has a test case for this: https://git.launchpad.net/review-tools/tree/reviewtools/tests/test_sr_declaration.py#n5195
[14:18] <cjp256> but for some reason, if we drop the optional "interface" key, it passes: `slot: mpris: { name: foo }`
[14:23] <zyga> cjp256: I don't know the review tools code, I cannot explain why without jumping into it from scratch
[14:37] <zyga> brb, need to check up on kids
[14:56] <pedronis> ijohnson: if you are happy with the changes 7992 can land once it is green again
[14:58]  * Chipaca goes to have his head seen to
[14:58]  * Chipaca notes it's for a haircut
[14:58] <ijohnson> pedronis: ack I will try to get it in and rebase the other one for shorter diff
[15:10] <mup> PR snapd#7555 closed: tests: add a test demonstrating that snaps can't access the session agent socket <Created by jhenstridge> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7555>
[15:16]  * cachio lunch
[16:00] <mup> PR snapd#7589 closed: cmd/snap: add ability to register "snap routine" commands <Created by jhenstridge> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7589>
[16:02] <pedronis> mborzecki: does #8013 need a review from cmatsuoka ?
[16:02] <mup> PR #8013: cmd/snap-bootstrap: check device size before boostrapping and produce a meaningful error <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8013>
[16:07] <zyga> re
[16:10] <ijohnson> pedronis: shall I merge #7934 if it goes green today in my PM?
[16:10] <mup> PR #7934: o/ifacestate,o/devicestatate: merge gadget-connect logic into auto-connect <Created by pedronis> <https://github.com/snapcore/snapd/pull/7934>
[16:10] <pedronis> ijohnson: if it's green, yes, I made a note to myself about the test refactor
[16:10] <ijohnson> pedronis: ack
[16:28] <ijohnson> pedronis: mborzecki: reviewing the patches to 7992, I notice that now DisableTryKernel returns nil if the symlink is _missing_, I thought that we wanted it to return an error if the symlink is missing, but if it's a dangling symlink we don't return error
[16:29] <ijohnson> pedronis: mborzecki: the use case I was thinking of for that is that if we have a poorgramming error where we try to disable a try kernel when there isn't even a try-kernel.efi we still want to error
[16:30] <ijohnson> specifically https://github.com/snapcore/snapd/pull/7992/commits/ac52ca80c27aa3a796177628701b07c95e01ab28#diff-637bfac32ed88896fef8c212d836bf11L217-R217
[16:30] <mup> PR #7992: bootloader: add ExtractedRunKernelImageBootloader interface, implement in grub <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7992>
[16:33] <mup> PR snapd#8013 closed: cmd/snap-bootstrap: check device size before boostrapping and produce a meaningful error <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8013>
[16:40] <mup> PR snapd#7871 closed: tests: add spread test for hook permissions <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7871>
[16:40] <pstolowski> huh, finally, it took ages
[17:25] <cjp256> zyga: just out of curiousity, would you expect behavior changes if "interface" is defined?  The docs say it's optional if the plug/slot name matches the interface?
[17:48] <mup> PR snapd#8018 opened: spread.yaml: fix ubuntu 19.10 and 20.04 names <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8018>
[17:56] <zyga> cjp256: snapd doesn't consider it any different, both result in identical slot
[17:56] <zyga> cjp256: it feels like bug in the review tools to me
[17:58] <cjp256> zyga: ok thanks, that's what I figured.  :) have a good weekend!
[17:58] <zyga> thank you :)
[18:44] <mup> PR snapd#7992 closed: bootloader: add ExtractedRunKernelImageBootloader interface, implement in grub <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7992>
[18:46] <pedronis> ijohnson: in general given our use case we don't want to fail even if we get something wrong, we should fail if a kernel that we want to enable is not there, but if a symlink is not there that we are about too remove, well too bad
[18:47] <ijohnson> pedronis: hmm ok
[18:47] <pedronis> ijohnson: robustness and correctness is not always the same thing
[18:48] <ijohnson> pedronis: I guess I was looking at it from the standpoint of having more certainy about what happened
[18:48] <ijohnson> pedronis: less of a correctness thing and more of a logging thing, i.e. the fact that the symlink wasn't there when we delete it might be masking some other error that happened before
[18:49] <pedronis> ijohnson: I understand but we don't devices stuck unless there is a strong argument why we can't move forward
[18:50] <ijohnson> pedronis: sure I guess in that instance it would be a higher level thing and that the caller of DisableTryKernel would see "hey this symlink wasn't there" and still move on, but maybe could log a message
[18:50] <ijohnson> (IMHO)
[18:50] <pedronis> ijohnson: I see but it gets too subtle, locally it seems a reasonable enough call
[18:51] <pedronis> also people don't look at logs of things at appear to work
[18:51] <pedronis> s/at/that/
[18:52] <ijohnson> pedronis: well I'll defer to your judgment about the design of this, but I do disagree that folks don't look at logs when things are working, I think looking at logs is often times a measurement of whether things are working, i.e. when you have a thousand devices you don't want to only monitor the ones that failed
[18:53] <pedronis> ijohnson: being demanding of what we expect our code to do is a task for our tests, avoiding uncessary failure is something we do want at runtime
[18:53] <pedronis> because the cost of failure is possibly very high
[18:53] <ijohnson> pedronis: sure
[18:53] <ijohnson> I agree with that
[18:56] <pedronis> ijohnson: anyway we you think we should log that condintion then bootloader itself should do that
[18:56] <pedronis> there's no point making it the task of one level up
[18:56] <ijohnson> pedronis: that's fair I might do that then
[18:59] <mup> PR snapd#7934 closed: o/ifacestate,o/devicestatate: merge gadget-connect logic into auto-connect <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7934>
[19:54] <mup> PR snapcraft#2884 opened: plugs/slots: match output format read in snapcraft.yaml <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2884>
[20:01]  * cachio afk
[21:01] <mup> PR snapd#8019 opened: [RFC] interfaces/apparmor: don't omit deny rules in devmode confinement <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8019>
[21:07] <mup> PR snapd#8020 opened: interfaces/apparmor: fix doc-comments, unnecessary code <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8020>