[00:03] <mup> Bug #1841001 opened: removing docker snap leaves apparmor misconfigured <Snappy:New> <https://launchpad.net/bugs/1841001>
[05:16] <mborzecki> morning
[06:24] <mvo> mborzecki: hey, good morning
[06:26] <mborzecki> mvo: pedronis: morning guys
[06:30] <mup> PR snapd#7304 closed: many: move channel parsing to snap/channel <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7304>
[06:30] <mup> PR snapd#7305 closed: check-pr-title.py: allow {} in pr prefix <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7305>
[06:31] <mup> PR snapd#7303 closed: interfaces/wayland,x11: allow reading an Xwayland Xauth file. Fixes LP: #1840925 <Created by oSoMoN> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7303>
[06:33] <mborzecki> mvo: check this out https://i.imgur.com/4P10y8J.png
[06:35] <mvo> mborzecki: woooooooo
[06:35] <mborzecki> blender          2.80     33     stable    blenderfoundation*  classic
[06:35] <mborzecki> blender_279      2.79b    20     2.79      blenderfoundation*  classic
[06:35] <mvo> mborzecki: thats really cool
[06:38] <mborzecki> mvo: didn't try any rendering though, hope they don't do some funny ipc with named sockets/semaphores that could conflict
[06:42] <mvo> mborzecki: right
[06:43] <mup> PR snapd#7230 closed: tests: make interfaces-contacts-services cleanup more robust <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7230>
[06:54] <mvo> mborzecki: do you have a spread test (a very simple) one already for the parallel install on classic?
[06:56] <mborzecki> mvo: not yet, wanted to update zyga_'s mount-ns test, but doing some reviews first
[06:56] <mvo> mborzecki: ok, just curious
[07:11] <pstolowski> mornings
[07:18] <mvo> good morning pstolowski !
[07:22] <zyga> hey
[07:22] <zyga> I got renamed to zyga_ and got banned/muted, not sure why
[07:23] <zyga> I didn't realize nothing got through
[07:23] <zyga> mborzecki: nice work
[07:29] <mborzecki> looking at ian's PR, got confused by task handlers again, iirc when a do callback fails, it should clean all the work it did internally right? so for instance if doLinkSnap fails on say, createSnapCookie it should run UnlinkSnap() (which isn't done really)?
[07:31] <zyga> mborzecki: not entirely
[07:31] <mvo> zyga: happend to me earlier as well!
[07:31] <zyga> mborzecki: when a handler fails it should clean up itself
[07:31] <zyga> mborzecki: when a handler finishes but another fails later
[07:31] <zyga> mborzecki: the undo handler for that task is called
[07:31] <zyga> mborzecki: that's the current approach
[07:31] <zyga> it's a bit hard to use TBH and hard to get right
[07:32] <zyga> it would be nice if we ran the "undo" one automatically but none of the code is ready for it
[07:32] <zyga> I spent way too long last night fighting cgroups
[07:32] <mborzecki> right, so if something inside doLinkSnap() fails after backend.LinkSnap() is called, it should ideally call backend.UnlinkSnap() before returning from the handler
[07:32] <zyga> there's something wonky going on that doesn't make sense to me yet
[07:33] <zyga> especially that it spans both ancient systemd and super recent systemd (on arch)
[07:33] <zyga> but not on other systems
[07:33] <zyga> mborzecki: I think it's well worth having a discussion about task handlers
[07:33] <zyga> mborzecki: I doubt we write them correctly today, it's very hard to do
[07:37] <zyga> mborzecki: in addition I would raise that the use of get/set is very pythonish
[07:37] <zyga> and doesn't fit go
[07:37] <zyga> it'd be nice if there were actual types
[07:37] <mborzecki> zyga: snap get/set ?
[07:37] <zyga> no
[07:37] <zyga> task handlers call get/set on task state
[07:38] <zyga> it's all a bit of wild west without typing
[07:38] <zyga> task state that is
[07:51] <zyga> pstolowski: about 7081
[07:51] <zyga> I'm writing one quick test to check something and then if that fails I'm +1 it
[07:51] <zyga> brb
[07:54] <pstolowski> zyga: great, ty :)
[07:57]  * zyga writes actual hand-made test that could be changed to spread test later on
[08:09] <mborzecki> noticed some PRs form yday were restarted, anyone know what failed there?
[08:09] <mborzecki> pstolowski: Chipaca: hey
[08:10] <Chipaca> mborzecki: 👋
[08:20] <mup> PR snapd#7307 opened: mkversion.sh: fix version from git checkouts <Created by mvo5> <https://github.com/snapcore/snapd/pull/7307>
[08:24] <pstolowski> hey Chipaca
[08:38] <mvo> zyga: what exactly is needed for 7299?
[08:38] <zyga> mvo: let me push it
[08:38] <mvo> zyga: ta
[08:38] <mvo> zyga: you may need to pull first but there should be no conflicts
[08:38] <mvo> zyga: I just applied your suggestions
[08:38] <pedronis> #7271 and #7135 need 2nd reviews
[08:38] <mup> PR #7271: many: generalize assertstate.Batch to asserts.Batch, have assertstate.AddBatch <Created by pedronis> <https://github.com/snapcore/snapd/pull/7271>
[08:38] <mup> PR #7135: image: support prepare-image --classic for snapd snap only images <Created by pedronis> <https://github.com/snapcore/snapd/pull/7135>
[08:39] <mvo> 7287 also needs a second review, should be an easy win
[08:40] <mup> PR snapd#7297 closed: cmd/snap-mgmt: set +x on startup <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7297>
[08:42] <zyga> mvo: ah, I see it is only running on 18.04
[08:42] <mvo> zyga: I will work on your suggestions for 7288 now to land it I just saw another failure. or maybe we land as is and I do a followup?
[08:42] <mvo> zyga: it should unbreak some missing cleanups
[08:43] <mvo> 7300 was failing iirc
[08:43] <zyga> mvo: +1
[08:43] <pstolowski> mvo: ty for pushing the naming fix to #7306!
[08:43] <mup> PR #7306: overlord/configstate: sort patch keys to have deterministic order with snap set <Created by stolowski> <https://github.com/snapcore/snapd/pull/7306>
[08:44] <mvo> pstolowski: no worries, looked so trivial I figured it would do no harm
[08:44] <zyga> mvo: https://github.com/snapcore/snapd/pull/7299 +1
[08:44] <mup> PR #7299: sanity: report proper errror when fuse is needed but not available <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7299>
[08:44] <zyga> https://github.com/snapcore/snapd/pull/7299#discussion_r316560942
[08:45] <mup> PR snapd#7288 closed: tests: cleanup "snap_daemon" user in system-usernames-install-twice <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7288>
[08:51] <mborzecki> zyga: mvo: https://github.com/systemd/systemd/issues/10872#issuecomment-523809771
[08:52] <zyga> mborzecki: interesting!
[08:52] <zyga> mborzecki: I need to change our stuff
[08:52] <zyga> thanks!
[08:53] <mborzecki> zyga: btw. make fmt keeps changing cmd/libsnap-confine-private/error.c cmd/snap-confine/udev-support.c :/
[08:53] <zyga> mborzecki: indent suuucks
[08:53] <zyga> mborzecki: just don't use it
[08:54] <zyga> mborzecki: run it once and commit the changes to the new code
[08:54] <zyga> mborzecki: discard the rest
[08:54] <mborzecki> zyga: yeah, too small for a seaprate PR though
[08:55] <mborzecki> zyga: maybe i'll add those in a separate patch in the parallel installs PR
[08:55] <mup> PR snapd#7308 opened: tests: add new "user-tool" helper and use in system-user tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/7308>
[08:55] <zyga> mborzecki: I'm confused, what do you mean
[08:55] <zyga> mvo: oh :D
[08:55] <zyga> mvo: I was writing user tool just now
[08:55] <zyga> though my version is in python :D
[08:55] <zyga> mvo: let's get your version, I will only replace the implementation on top, ok?
[08:56] <mborzecki> zyga: https://paste.ubuntu.com/p/pQN7XFWP3V/ that's the diff, since it's fairly small, too small for a PR, so i'll add it to 7302
[08:57] <zyga> mborzecki: don't change that please
[08:57] <zyga> mborzecki: my suggestion is to respect indent only on new code
[08:57] <mborzecki> zyga: hm ok
[08:57] <zyga> and not change existing files exactly because indent is unstable
[08:57] <zyga> mborzecki: and new files, if possible, should be formatted with clang-format
[08:59] <pstolowski> zyga: can you also re-review #7287?
[08:59] <mup> PR #7287: hookstate/ctlcmd: snapctl unset command <Created by stolowski> <https://github.com/snapcore/snapd/pull/7287>
[08:59] <zyga> pstolowski: enqueued
[09:00] <pstolowski> zyga: fifo or lifo? ;)
[09:02] <zyga> pstolowski: life-o
[09:04] <diddledan> lipo? last-in, pooped-out? :-p
[09:06] <Chipaca> lipo is the opposite of pooped-out tho
[09:07] <Chipaca> hoovered-out more like
[09:08] <Chipaca> mvo: did you see #1841001 ?
[09:08] <mup> Bug #1841001: removing docker snap leaves apparmor misconfigured <Snappy:New> <https://launchpad.net/bugs/1841001>
[09:09] <zyga> mvo: I saw that
[09:09] <zyga> mvo: it's not easy to fix
[09:09] <zyga> mvo: we discussed that at the last sprint
[09:09] <zyga> we can only remove apparmor profiles after all processes using them are gone
[09:10] <zyga> but that's hard to measure now
[09:10] <mvo> Chipaca: I did not see it :/
[09:12] <zyga> mvo: https://github.com/snapcore/snapd/pull/7309
[09:12] <Chipaca> zyga: that's removing them from the kernel though, isn't it?
[09:12] <mup> PR #7309: tests: re-implement user tool in python <Created by zyga> <https://github.com/snapcore/snapd/pull/7309>
[09:12] <zyga> Chipaca: can you re-state your question?
[09:12] <zyga> Chipaca: we are not removing the profiles
[09:12] <Chipaca> zyga: as opposed to removing them from disk? Or is this bug about in-kernel?
[09:12] <mup> PR snapd#7309 opened: tests: re-implement user tool in python <Created by zyga> <https://github.com/snapcore/snapd/pull/7309>
[09:12] <zyga> Chipaca: because removing them would remove them from running processes
[09:12] <zyga> Chipaca: it's about kernel
[09:12] <zyga> Chipaca: they are gone from disk
[09:12] <Chipaca> ah
[09:12] <zyga> Chipaca: they persist in the kernel until you reboot
[09:13] <zyga> yeah :/
[09:14] <Chipaca> zyga: what's "any-python"?
[09:14] <zyga> Chipaca: tests/lib/bin/any-python
[09:14] <Chipaca> ah
[09:14] <zyga> I wish it wasn't needed
[09:14] <zyga> I wish unix had py
[09:14] <zyga> but ...
[09:14] <zyga> well :)
[09:16] <zyga> mvo: https://twitter.com/rbtcollins/status/1164327713269620737
[09:21] <mvo> zyga: uh
[09:21] <mvo> zyga: thanks
[09:22] <mvo> zyga: we had this discussion before, we suck and we need to fix it :(
[09:22] <zyga> there are three bugs there
[09:22] <zyga> I'm going through them now
[09:23] <mvo> zyga: thank you
[09:23] <mvo> zyga: nice picture of robert, haven't seen a picture of him in years, I'm quite impressed :)
[09:23] <zyga> https://bugs.launchpad.net/snappy/+bug/1841001
[09:23] <zyga> https://bugs.launchpad.net/snappy/+bug/1840244
[09:23] <zyga> https://bugs.launchpad.net/snappy/+bug/1656976
[09:23] <mup> Bug #1841001: removing docker snap leaves apparmor misconfigured <Snappy:Triaged> <https://launchpad.net/bugs/1841001>
[09:23] <mup> Bug #1840244: docker snap cannot bind mount ssh sockets correctly <Snappy:Triaged> <https://launchpad.net/bugs/1840244>
[09:23] <mup> Bug #1656976: classic mode cannot start services <Snappy:Triaged> <https://launchpad.net/bugs/1656976>
[09:23] <zyga> all triaged, the last one is easy-ish
[09:23] <zyga> the other two are not
[09:24] <zyga> the middle one is an UX usability bug
[09:24] <mvo> maybe we need to make twitter our bts?
[09:24] <zyga> the first one are two bugs in one
[09:24] <zyga> one needs to be handled by docker snap
[09:24] <zyga> the other by us eventually
[09:24] <zyga> I'll raise this at the standup
[09:25] <zyga> mvo: who wants to triage the remaining NEW bugs?
[09:26] <zyga> I need that coffee
[09:26] <mvo> zyga: I think we should talk in the standup but to make this work we will need something like bug triage duty on specific days
[09:26] <mvo> zyga: I think
[09:26] <mvo> zyga: like the security team is doing
[09:26] <zyga> yeah
[09:26] <zyga> it cannot be knee-jerk reactionary like that
[09:26] <mvo> zyga: or we need to put someone on it (like sergio) and make it his reposonbility
[09:30] <diddledan> coffee sounds like a plan, zyga
[09:30] <zyga> yeah
[09:30]  * zyga goes to make some
[09:39] <mup> PR snapd#7310 opened: devicestate: add missing test for remodeling possibly removing required flag <Created by pedronis> <https://github.com/snapcore/snapd/pull/7310>
[09:39] <pedronis> mvo: ^ there's a bit of doSetModel that was not unit tested that I need to tweak in the core20 model work
[09:39] <Chipaca> mvo: is #1579268 really an issue with snapd? I thought it was an issue with the snaps themselves
[09:40] <mup> Bug #1579268: Mouse cursor is different inside graphical windows of snaps (snaps not using system theme) <Snappy:New> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1579268>
[09:42] <diddledan> hah, we've just had that mentioned in the Ubuntu Podcast Telegram channel :-)
[09:43] <mvo> Chipaca: I think its a issue with the snaps but iirc zyga was looking into this a while ago, not sure if we need to tweak anything on our side
[09:44] <Chipaca> mvo: there's also the issue that if people use themes that aren't packaged they're not usable from the snap
[09:44] <Chipaca> mvo: that aspect i'd say is wontfix? or did we have plans for that? or is that what zyga was looking at
[09:46] <mvo> Chipaca: we had plans for this, the idea was to have theme-snaps that would be auto-downloaded
[09:46] <mvo> Chipaca: this was a colaboration with the desktop team, there should be a forum post somewhere
[09:46]  * mvo looks
[09:47] <mvo> Chipaca: jamesh is a good POC I think
[09:48] <diddledan> only a POC? I think james might claim to be GA/RTM
[09:48] <diddledan> at least MVP
[09:49] <Chipaca> diddledan: I don't think jamesh is an airport in Colombia
[09:49] <diddledan> really?
[09:49] <Chipaca> diddledan: 87% sure
[09:50] <diddledan> I think this needs more investigation
[09:55] <mup> Bug #1579268 changed: Mouse cursor is different inside graphical windows of snaps (snaps not using system theme) <Snappy:Invalid> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1579268>
[09:58] <mup> Bug #1581188 changed: How to run snappy from inside Docker - systemd issues? <Snappy:Won't Fix> <https://launchpad.net/bugs/1581188>
[10:00] <tomwardill> I'm doing `snap set snap-store-proxy.internal.store.id=''` but the value does not appear to change. Is this likely to be a problem with the snap-store-proxy configure hook, or am I doing something wrong?
[10:01] <tomwardill> ideally, I'd like to set it to null/no value
[10:02] <Chipaca> ogra: you around?
[10:02] <ogra> yes
[10:02] <Chipaca> tomwardill: doesn't =null do that?
[10:03] <ogra> and no, i have no idea about that nextcloud box :P
[10:03] <Chipaca> ogra: #1587453, i'm not sure if that's an Invalid or a Won'tFix or a Confirmed Wishlist
[10:03] <mup> Bug #1587453: Reduce write to SD cards <raspberry-pi> <Snappy:New> <https://launchpad.net/bugs/1587453>
[10:03] <tomwardill> Chipaca: `=null` will work on another key, but the value doesn't change on the key I care about
[10:03] <tomwardill> so I guess it's my problem somewhere :)
[10:04] <Chipaca> tomwardill: sounds like a validation bug yeah
[10:04] <Chipaca> tomwardill: also note there's going to be 'snap unset' soon
[10:05] <tomwardill> Chipaca: ah, that sounds like what I'm after :)
[10:05] <Chipaca> pstolowski: what release is snap unset scheduled for?
[10:05] <diddledan> is it even meant to be user changable considering it's marked internal?
[10:05] <ogra> Chipaca, wontfix unless you plan to hack up disk cache settings randomly
[10:06] <pstolowski> Chipaca: it partially landed for 2.41 (and what landed is fully usable), however 'snapctl unset' didn't make it
[10:07] <mup> Bug #1587453 changed: Reduce write to SD cards <raspberry-pi> <Snappy:Won't Fix> <https://launchpad.net/bugs/1587453>
[10:07] <mup> Bug #1593151 changed: Snapd should support custom servers <Snappy:Won't Fix> <https://launchpad.net/bugs/1593151>
[10:10] <mup> Bug #1593435 changed: snap install will go get store version instead of sideload <Snappy:Invalid> <https://launchpad.net/bugs/1593435>
[10:13] <mup> Bug #1593558 changed: sox not configured for pulseaudio when packaged in a snap <Snappy:Invalid> <https://launchpad.net/bugs/1593558>
[10:13] <mup> Bug #1593915 changed: Ad the "snap all refresh" command <Snappy:Fix Released> <https://launchpad.net/bugs/1593915>
[10:16] <mup> Bug #1593958 changed: Downloading snaps takes too long <Snappy:Fix Released> <https://launchpad.net/bugs/1593958>
[10:16] <mup> Bug #1593960 changed: snap refresh unfriendly error message <Snappy:Fix Released> <https://launchpad.net/bugs/1593960>
[10:19] <mup> Bug #1593989 changed: snap installed .desktops collide with .deb installed .desktops in unity7 <Snappy:Fix Released> <https://launchpad.net/bugs/1593989>
[10:20] <diddledan> all the bugs!
[10:20] <mup> PR snapd#7311 opened: snap/naming: introduce SnapRef, Snap, and SnapSet <Created by pedronis> <https://github.com/snapcore/snapd/pull/7311>
[10:22] <mup> PR snapd#7312 opened: tests: use user-tool to remove test user in the non-home test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7312>
[10:22] <mup> Bug #1594328 changed: snappy keeps several copies of the same snap <Snappy:Fix Released> <https://launchpad.net/bugs/1594328>
[10:24] <mup> PR snapd#7313 opened: many:  add the start of Core 20 extensions support to the model assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/7313>
[10:25] <pedronis> mvo: ^
[10:26] <mvo> pedronis: nice
[10:28] <diddledan> did someone turn on the firehose? http://www.belch.com/img/firehose.jpg :-p
[10:28] <mup> Bug #1580738 changed: exec in desktop file should be app name and not include the friendly (current) package name <snapd:Confirmed> <https://launchpad.net/bugs/1580738>
[10:28] <mup> Bug #1594842 changed: Docs have "revision" as an int <Snappy:Fix Released> <https://launchpad.net/bugs/1594842>
[10:31] <mup> Bug #1600140 changed: App indicator adds an entry for each snap launch <snap-desktop-issue> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1600140>
[10:31] <mup> Bug #1600489 changed: freecad after being installed with snap doesn't exists <Snappy:Invalid> <https://launchpad.net/bugs/1600489>
[10:33] <Chipaca> mvo: #1606539 is fixed, yes?
[10:33] <mup> Bug #1606539: handler errors from `snap create-user` gracefully <Snappy:New> <https://launchpad.net/bugs/1606539>
[10:34] <mup> Bug #1601859 changed: Need a way to autostart applications (not services) <Snappy:Fix Released> <https://launchpad.net/bugs/1601859>
[10:37] <mup> Bug #1607252 changed: User data is missing or lost when utilizing a snap instead of a traditional package <Snappy:Fix Released> <https://launchpad.net/bugs/1607252>
[10:37] <mup> Bug #1607744 changed: "snap install <filename>" over an already installed snap doesn't copy the user data <lxd> <Snappy:Fix Released> <https://launchpad.net/bugs/1607744>
[10:37] <mup> Bug #1609757 changed: Enable ordering of services provided by a snap <cpc> <Snappy:Fix Released> <https://launchpad.net/bugs/1609757>
[10:39] <Chipaca> pedronis: were you aware of the request in #1609864 ?
[10:39] <mup> Bug #1609864: Enable a command to be run on machine shutdown <cpc> <Snappy:New> <https://launchpad.net/bugs/1609864>
[10:41] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/7306
[10:41] <mup> PR #7306: overlord/configstate: sort patch keys to have deterministic order with snap set <Created by stolowski> <https://github.com/snapcore/snapd/pull/7306>
[10:41] <pstolowski> zyga: ty
[10:42] <mup> PR snapd#7290 closed: tests: allow test user XDG_RUNTIME_DIR to phase out <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7290>
[10:43] <pstolowski> zyga: otoh, i'm slightly scared of loosing 'green' spread status on that PR...
[10:43] <zyga> haha, sure
[10:43] <zyga> follow up +1
[10:44] <pstolowski> tough times
[10:44] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/7287#pullrequestreview-278333771 +1
[10:44] <mup> PR #7287: hookstate/ctlcmd: snapctl unset command <Created by stolowski> <https://github.com/snapcore/snapd/pull/7287>
[10:45] <zyga> pstolowski: I'm mid-way writing that spread test for batch profiles but I went upstairs for a moment and doing reviews from a laptop now
[10:45] <pstolowski> zyga: sure, thanks for trying to break it
[10:47] <mup> Bug #1611526 changed: temp directories not deleted when snap fails to start <lxd> <Snappy:Fix Released> <https://launchpad.net/bugs/1611526>
[10:47] <mup> Bug #1611530 changed: can't install devmode snap from store <landscape> <Snappy:Won't Fix> <https://launchpad.net/bugs/1611530>
[10:47] <mup> Bug #1611706 changed: Test suite failures on Arch <Snappy:Fix Released> <https://launchpad.net/bugs/1611706>
[10:47] <pstolowski> ah, 7287 is actually rebuilding anyway for previous changes...
[10:47] <zyga> pstolowski: 7287 can land now
[10:47] <zyga> oh
[10:47] <zyga> bummer
[10:47] <pstolowski> nah it can't
[10:47] <pedronis> Chipaca: no
[10:48] <pstolowski> let's see, if it fails for random reason, i'll make the spread test tweak as well
[10:49] <zyga> jdstrand: can you please enqueue https://github.com/snapcore/snapd/pull/7252
[10:49] <mup> PR #7252: interfaces/network-manager: allow using org.freedesktop.DBus.ObjectManager <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7252>
[10:50] <pstolowski> zyga: ah, no, 7287 can land indeed, ty, i confused my two PRs
[10:50] <mup> Bug #1611837 changed: all-snaps: Boot breaks on reboot <Snappy:Invalid> <https://launchpad.net/bugs/1611837>
[10:50] <mup> Bug #1612783 changed: snapd requires U1 account to install local packages <Canonical System Image:Fix Released> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1612783>
[10:50] <mup> Bug #1614730 changed: dpkg: dependency problems prevent configuration of snapd -  snapd depends on ubuntu-core-launcher (>= 1.0.23) <oil> <Snappy:Fix Released> <https://launchpad.net/bugs/1614730>
[10:50] <mup> PR snapd#7287 closed: hookstate/ctlcmd: snapctl unset command <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7287>
[10:51] <mup> PR snapd#7225 opened: tests: don't repeat checks <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/7225>
[10:51]  * zyga hugs Chipaca!
[10:53] <mup> Bug #1616508 changed: snap install overwrites its own output <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1616508>
[10:53] <mup> PR snapd#7234 closed: tests: make sure snapd is built against new gorilla mux <Simple 😃> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7234>
[10:55] <Chipaca> zyga: what's the status of #1620592 ?
[10:55] <mup> Bug #1620592: if your first installed snap contains a binary needing sudo ~/snap is created with root.root ownership <snap-confine:Triaged> <Snappy:New> <https://launchpad.net/bugs/1620592>
[10:56] <mup> Bug #1618239 changed: console-conf uses 20+MB memory at rest on embedded systems <subiquity (Ubuntu):Fix Released by mwhudson> <https://launchpad.net/bugs/1618239>
[10:56] <zyga> Chipaca: I'd have to re-check, I don't remember
[10:56] <Chipaca> :)
[10:56] <Chipaca> zyga: same question wrt #1620650 although that one might be for mborzecki these days
[10:56] <mup> Bug #1620650: After installing krita from beta channel, krita crashes when opening the snap. <Calligra:Unknown> <Snappy:New> <https://launchpad.net/bugs/1620650>
[10:57] <zyga> Chipaca: I don't know either, I could check but I'd need to update to 19.10 as my gpu doesn't work on ubuntu today (2080s)
[10:58] <Chipaca> i set it to confirmed because even if it's better than what it was in the bug, it's still not perfect
[10:58] <Chipaca> (wrt PRIME setup)
[11:02] <mup> Bug #1620771 changed: when /home is somewhere else, snaps don't work <link> <snap> <symlink> <Snappy:Won't Fix> <https://launchpad.net/bugs/1620771>
[11:04] <pedronis> mvo: I'm getting:  groupdel: cannot remove the primary group of user 'snap_daemon'
[11:04] <pedronis> is that fixed somewhere?
[11:04] <pedronis> (in spread to be clear)
[11:05] <mvo> pedronis: yes, should be fixed with current master
[11:06] <mvo> pedronis: https://github.com/snapcore/snapd/pull/7288 was the relevent pr
[11:06] <mup> PR #7288: tests: cleanup "snap_daemon" user in system-usernames-install-twice <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7288>
[11:08] <mup> Bug #1621132 changed: Porting guide is out of date <Snappy:Fix Released> <https://launchpad.net/bugs/1621132>
[11:08] <mup> Bug #1621142 changed: no "please press enter" message shown on serial console <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1621142>
[11:08] <mup> Bug #1621144 changed: serial console is not cleared before console-conf runs <subiquity:Triaged> <https://launchpad.net/bugs/1621144>
[11:09] <pedronis> pstolowski: if I understood zyga correctly #7081 can be merged?
[11:09] <mup> PR #7081: ifacestate: optimize auto-connect by setting profiles once after all connects <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7081>
[11:12] <pstolowski> pedronis: no, he is working on some kind of test to verify it
[11:12] <pedronis> pstolowski: did you speak again? I thought he said in the standup that he wasn't blocking it anymore
[11:12] <zyga> pstolowski: can we merge it now and adjust if my test finds something
[11:13] <zyga> pstolowski: it's just a spread test
[11:13] <pstolowski> pedronis: yes we talked about it this morning
[11:13] <zyga> if it works we can merge it anyway
[11:13] <zyga> and this way we get more exposure during the dev cycle
[11:13] <pedronis> yea, we just cut 2.41
[11:13] <pedronis> it's a good time as any
[11:13] <pstolowski> zyga: ok, sounds good
[11:13] <zyga> merge away
[11:14] <mup> PR snapd#7081 closed: ifacestate: optimize auto-connect by setting profiles once after all connects <Needs Samuele review> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7081>
[11:27] <mvo> zyga: I get this error in the (new) lxd test:
[11:27] <mvo> + lxd.lxc exec my-ubuntu -- su -c '/snap/bin/test-snapd-tools.echo from-the-inside' ubuntu
[11:27] <mvo> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[11:28] <mvo> zyga: do you have any idea ? its strange but maybe something missing inside the container or crazyiness like this?
[11:28] <zyga> that's odd, do you have a debug shell?
[11:28] <zyga> can you check aa-status
[11:28]  * zyga is still upstairs, reading https://github.com/snapcore/snapd/pull/7271
[11:28] <mup> PR #7271: many: generalize assertstate.Batch to asserts.Batch, have assertstate.AddBatch <Created by pedronis> <https://github.com/snapcore/snapd/pull/7271>
[11:30] <pedronis> fwiw it will be tweaked a bit, given mvo input, it had a bit of  along gestation/back and forth on my part on details
[11:30] <mvo> pedronis: thanks! I was wondering how useful my ramblings were, glad it seems they were :)
[11:30]  * mvo lunches 
[11:30] <zyga> mvo: ping me about the lxd failure
[11:30] <zyga> mvo: after lunch
[11:31] <mup> PR snapd#7298 closed: tests: clean up after NFS tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7298>
[11:35] <mup> Bug # changed: 1621147, 1621304, 1621323, 1621339, 1621378
[11:37] <Chipaca> mvo: what's your opinion on #1621666 ?
[11:38] <mup> Bug #1621666: It is possible to install the classic snap in a classic system <classic> <Snappy:New> <https://launchpad.net/bugs/1621666>
[11:38] <mup> Bug # changed: 1621380, 1621550, 1621568, 1621623
[11:38] <Chipaca> pedronis: is #1621769 accurate? care to comment there?
[11:38] <mup> Bug #1621769: impossible to create a model assertion compatible with both snapd 2.13 and 2.14 <Snappy:New for mvo> <https://launchpad.net/bugs/1621769>
[11:38] <Chipaca> pedronis: otherwise i'll tag it wontfix
[11:39] <pedronis> we would have to change the past
[11:41] <mup> Bug #1621805 changed: sudo snap abort <change-id> won't abort snap install process before downloading full package <snap> <snapd> <snappy> <Snappy:Fix Released> <https://launchpad.net/bugs/1621805>
[11:44] <mup> Bug # changed: 1623120, 1623802, 1625605, 1625698
[11:46] <mup> PR snapcraft#2680 opened: spread tests: minor performance improvements <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2680>
[11:47] <mup> Bug #1626617 changed: console-conf does not allow to set up dns for static ip <plano-acan> <verification-done-yakkety> <netplan:Fix Released by pitti> <nplan (Ubuntu):Fix Released by pitti> <subiquity (Ubuntu):Fix Released> <nplan (Ubuntu Xenial):Fix Released> <subiquity (Ubuntu Xenial):Won't Fix>
[11:47] <mup> <nplan (Ubuntu Yakkety):Fix Released> <subiquity (Ubuntu Yakkety):Won't Fix> <https://launchpad.net/bugs/1626617>
[11:47] <Chipaca> OK, I'm done triaging for today
[11:47] <Chipaca> more tomorrow (and every friday from now until forever)
[11:54] <zyga> Chipaca: fantastic stuff, thank you
[11:54] <zyga> Chipaca: I can happily work on triage every friday as well
[11:54] <Chipaca> zyga: question: does /v2/interfaces?doc=true&select=all return all even cross-arch?
[11:55] <zyga> cross-arch?
[11:55] <Chipaca> zyga: maybe better if we choose different days
[11:55] <Chipaca> zyga: like, are there armhf-only interfaces, and if so do those appear in that
[11:55] <zyga> interfaces don't model architecture
[11:55] <Chipaca> good :)
[11:55] <Chipaca> ok
[11:55] <zyga> so yeah
[11:59]  * zyga eats a snack qucikly
[11:59] <zyga> back to that integration test pawel :)
[12:00] <pstolowski> zyga: you're not giving up easily, i give you that ;)
[12:01] <zyga> pstolowski: it's mainly because I suck at reading the code well enough to have confidence in that
[12:01] <zyga> so black box tests FTW
[12:01] <zyga> pstolowski: btw, I updated to catalina
[12:01] <zyga> it's neat
[12:01] <pstolowski> zyga: it's stil beta isn't it?
[12:01] <zyga> yeah
[12:01] <zyga> coming out in fall as usual
[12:02] <pstolowski> zyga: yeah, it has know problems affecting x-plane, so no-no for me atm
[12:02] <pstolowski> *known
[12:13] <mborzecki> zyga: pushed changs to #7302
[12:14] <mup> PR #7302: cmd/snap-confine: add support for parallel instances of classic snaps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7302>
[12:18] <ogra> parallel insanity ...
[12:38] <pedronis> pstolowski: about 7207, I don't think we have any tests about using seed.yaml to install multiple instance, I wouldn't consider it supported atm
[12:43] <pstolowski> pedronis: right, that's why my initial changes were happy.. but if we want to address this (i.e. actively prevent), i'd opt for a separate PR
[12:45] <mup> PR snapd#7300 closed: interfaces/network-{control,manager}: allow 'k' on /run/resolvconf/** <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7300>
[12:46] <mup> PR snapd#7301 closed: interfaces/network-{control,manager}: allow 'k' on /run/resolvconf/** - 2.41 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7301>
[12:51] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7302#pullrequestreview-278394393
[12:51] <mup> PR #7302: cmd/snap-confine: add support for parallel instances of classic snaps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7302>
[12:52] <pstolowski> pedronis: thanks for the suggestions under #7005
[12:52] <mup> PR #7005: debug: state-inspect debugging utility <Created by stolowski> <https://github.com/snapcore/snapd/pull/7005>
[12:52] <pstolowski> pedronis: nice idea with 'state' as the main sub-command
[12:54] <zyga> mvo: I have a solution to all our problems ;-)
[12:54] <zyga> mvo: https://github.com/snapcore/snapcraft/pull/2676
[12:54] <mup> PR snapcraft#2676: spread: 64 workers for each system <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2676>
[12:56] <mvo> zyga: hehe
[12:56] <zyga> on the other hand I'd love to see the numbers if we tried that
[12:56] <zyga> just really curious
[12:58] <mup> PR snapd#7308 closed: tests: add new "user-tool" helper and use in system-user tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7308>
[13:00] <mup> PR snapd#7285 closed: httputil: improve http2 PROTOCOL_ERROR detection <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7285>
[13:20] <mup> PR snapd#7314 opened: tests/main/mount-ns: account for clone_children in cpuset cgroup on 18.04 <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7314>
[13:40] <zyga> this is scary https://lwn.net/Articles/796951/
[13:41] <pedronis> this needs a 2nd review: https://github.com/snapcore/snapd/pull/7135
[13:41] <zyga> git diff not showing changes because timestamps
[13:41] <mup> PR #7135: image: support prepare-image --classic for snapd snap only images <Created by pedronis> <https://github.com/snapcore/snapd/pull/7135>
[14:01]  * zyga child care break
[14:12] <Saviq> pstolowski: hey, I think you know about hooks ;) is there any way to know, in a pre-refresh hook, what revision we're getting refreshed to? we'd like to fail the refresh if someone tries to go from core18-based Multipass to a core16-based one if they have any instances running (as they will fail to resume again)
[14:13] <Saviq> it's a corner case, but if there is something we could do to let users know how to go about it, we would :)
[14:16] <ijohnson> Saviq: I don't think there's anything like that currently available in hooks, but you could use epochs
[14:17] <ijohnson> core16 based multipass could be epoch 0, and core18 multipass could be epoch 1, and as long as you never publish a epoch 1* (or maybe 0* I don't recall) a refresh between them will never be allowed or happen automatically
[14:17] <Saviq> ijohnson: right, I know, but that's too strict, we can refresh both ways, it's a runtime check whether it's ok or not
[14:18] <pstolowski> Saviq: as ijohnson says.. no way of knowing that right now.. that's not the first request for something like this we get
[14:18] <Saviq> ack, thanks guys :)
[14:19] <ijohnson> I suppose you could do something like write to a file in $SNAP_DATA or $SNAP_COMMON that says if there are instances running in pre-refresh, then in post-refresh check if that file is there and if you switched bases, then exit 1 from the post-refresh hook forcing a revert back to the previous one
[14:19] <pstolowski> Saviq: i have very vague memories of a forum topic about this, but can't find it...
[14:20] <ijohnson> Saviq: do multipass instances currently continuing running during a refresh?
[14:20] <Saviq> ijohnson: they get suspended and resumed
[14:20] <Saviq> (because they're actually child processes of multipassd)
[14:21] <ijohnson> okay, so then the instance would get resumed when multipassd starts up again?
[14:22] <ijohnson> if that's the case then the file method I mentioned above should work, it's a bit of a hack/workaround, but would have the desired affect I think
[14:29] <Saviq> ijohnson: yeah it sounds workable indeed
[14:29] <Saviq> thanks :)
[14:30] <ijohnson> Saviq: I prototyped a similar type of thing before and can share some example code if you're interested
[14:55] <mup> PR snapd#7315 opened: store, image, cmd: make 'snap download' leave partials <Created by chipaca> <https://github.com/snapcore/snapd/pull/7315>
[15:21] <ijohnson> jdstrand: from a gut feeling do you think that providing net_admin and sys_admin to daemon-notify is ack'able ? if your gut feeling is no, then I'm just gonna close #6697
[15:22] <mup> PR #6697: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>
[15:24] <jdstrand> ijohnson: gut feeling is no. I still have an item for it, but it is going to take a while for a full investigation (sorry it is lingering)
[15:24] <jdstrand> (ie, it is in trello so won't be forgotten)
[15:24] <zyga> ijohnson: sorry for lagging on older PRs, quick question on https://github.com/snapcore/snapd/pull/6697/files#r316741453
[15:24] <mup> PR #6697: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>
[15:27] <ijohnson> jdstrand: okay that's fine I think I'll leave it open in case you can find a workaround or something in your investigation, it would still be a nice to have
[15:28] <ijohnson> zyga: thanks I'll take a look, perhaps network isn't actually necessary there I have a habit of just shotgunning network access for every snap I write :-)
[15:30] <zyga> ijohnson: I asked because it tends to hide missing permissions in the actual interface being tested
[15:30] <ijohnson> right
[15:30] <zyga> if there's a legitimate reason for it please add a comment there
[15:33] <ijohnson> yep, running spread right now to see
[15:36] <jdstrand> ijohnson: you could still close it with a note that you will reopen pending investigation
[17:08] <mup> PR snapcraft#2680 closed: spread tests: minor performance improvements <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2680>
[17:17] <mup> PR snapcraft#2676 closed: spread: 64 workers for each system <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2676>
[17:25]  * ijohnson lunches
[18:35] <mup> PR snapd#7316 opened: tests: add unit tests for cmd_whoami <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7316>
[18:39] <ardaguclu_> hi, is there any mocking for logging?
[18:39] <ardaguclu_> I created PR 7316
[18:39] <mup> PR #7316: tests: add unit tests for cmd_whoami <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7316>
[18:48] <mup> PR snapd#7315 closed: store, image, cmd: make 'snap download' leave partials <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7315>
[21:38] <mup> PR snapcraft#2681 opened: spread: fix unbound variable error <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2681>
[21:41] <mup> PR snapcraft#2682 opened: tests: change default spread provider to lxd outside of travis <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2682>