[04:54] <ijohnson> morning mvo, there's some weirdness going on with some of the spread tests where it just dies immediately before running spread
[04:55] <ijohnson> The SU doc for me has an example build to look at, I couldn't figure it out, almost seems like spread itself is dying
[04:56] <ijohnson> Anyways time for me to log off, good luck
[04:56] <mvo> ijohnson: thank you, I noticed this right before going to bed too, I had hoped it was a fluke
[04:56] <mvo> ijohnson: thanks, get some rest!
[04:56] <mvo> ijohnson: I have a look
[05:04] <mup> PR snapd#7642 opened: travis.yml: add 'sh -x' to run-checks <Created by mvo5> <https://github.com/snapcore/snapd/pull/7642>
[05:15] <zyga> good morning
[05:16] <zyga> hey mvo
[05:18] <mborzecki> morning
[05:18] <mvo> hey zyga and mborzecki
[05:19] <zyga> hey mborzecki
[05:19] <mvo> looks like travis has some problems sometimes
[05:19] <mborzecki> mvo: zyga: hey
[05:19] <zyga> fog, fog as far as I can see :)
[05:19] <mvo> and of course my debug PR works just fine :(
[05:19] <mborzecki> hahaha
[05:19] <zyga> mvo: merge everything into it and land ;)
[05:20] <zyga> some store woes yesterday
[05:20] <zyga> error: cannot search: got unexpected HTTP status code 403 via GET to
[05:20] <zyga>        
[05:20] <zyga> "https://api.snapcraft.io/api/v1/snaps/search?confinement=strict%2Cclassic&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cbinary_filesize%2Cdownload_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Csnap_id%2Clicense%2Cbase%2Cmedia%2Csupport_url%2Ccontact%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdeveloper_id%2Cdeveloper_name%2Cdeveloper_vali
[05:20] <zyga> dation%2Cprivate%2Cconfinement%2Ccommon_ids&q=pc&scope=wide"
[05:20] <zyga> some 503 as well
[05:37] <zyga> hello niemeyer
[05:37] <zyga> niemeyer: when you are around today could you please look at sergio's fix for spread spread tests: https://github.com/snapcore/spread/pull/91
[05:37] <mup> PR spread#91: tests: Fix adhoc test <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/91>
[05:42] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7614 could use a review
[05:42] <mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
[05:42] <zyga> and it's green (shocking)
[06:00] <zyga> mvo: do you think you could look at https://github.com/snapcore/snapd/pull/7547
[06:00] <mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
[06:00] <zyga> at least conceptually
[06:01] <zyga> it is already being looked at by ian and jamie but I wanted to make sure you understand what is going on there as well
[06:01] <mvo> zyga: sure, was wondering if samuele needs to look but I'm happy to do it
[06:01] <zyga> mvo: I think we all should look because it's such a fundamental part
[06:01] <mvo> zyga: sounds good
[06:18] <mup> PR snapd#7634 closed: tests: ignore directories for go modules <Created by slimjim777> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7634>
[06:19]  * zyga needs to garden his PRs
[06:35] <mborzecki> zyga: left some comments under your PRs
[06:35] <mborzecki> zyga: btw. what's the problem with ijohnson's named hierarchy use?
[06:36] <zyga> none?
[06:36] <zyga> can you clarify please
[06:41] <mborzecki> zyga: https://github.com/snapcore/snapd/pull/7547#pullrequestreview-305622718 but i see it was nothing weird ;P
[06:41] <mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
[06:42] <zyga> mborzecki: did you see my reply on https://github.com/snapcore/snapd/pull/7547#issuecomment-545280953
[06:44] <mup> PR snapd#7629 closed: snap-recovery: create filesystems as defined in the gadget <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7629>
[06:51] <zyga> mvo: https://github.com/snapcore/snapd/pull/7642 is green
[06:51] <mup> PR #7642: travis.yml: add 'sh -x' to run-checks <Created by mvo5> <https://github.com/snapcore/snapd/pull/7642>
[06:53] <mvo> zyga: yeah, its strange
[06:53] <mvo> zyga: another of my PRs also went green
[06:53] <zyga> let's merge it and see
[06:53] <mvo> zyga: maybe it was a fluke
[06:54] <zyga> question is what was it, your PR might answer that
[06:54] <mvo> zyga: yeah, we can always revert
[07:04] <pstolowski> morning
[07:04] <zyga> hey pawel
[07:04] <zyga> pstolowski: sorry to jump into this straight away but I'm hunting for reviews for the emit() branch again :)
[07:05] <zyga> mborzecki: I debugged why I saw different numbers in spread and on my system, without the memory fix patch
[07:05] <zyga> mborzecki: turns out my desktop had more rules because of the document portal
[07:05] <mborzecki> hah
[07:05] <zyga> mborzecki: so the test is reliable
[07:05] <zyga> mborzecki: it just measures a smaller set of rules
[07:06] <zyga> mborzecki: but it's still clear as day and night that it is using small amount of memory vs huge before
[07:06] <pstolowski> zyga: will get to it in a moment
[07:06] <zyga> pstolowski: I rebased the original PR on the emit branch now
[07:07] <zyga> pstolowski: and it shows exactly how little has to change, on top of emit(), to fix the memory issue
[07:07] <zyga> pstolowski: this is the only remaining patch there: https://github.com/snapcore/snapd/pull/7632/commits/03ef1bd9b36c368c64c717879098f7fbe533c389
[07:07] <mup> PR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
[07:24] <zyga> brb
[07:24] <zyga> so cold and foggy today
[07:24] <zyga> hot tea anyone?
[07:42] <zyga> re
[07:52] <zyga> pstolowski: thank you, replied to both
[07:56] <zyga> kyrofa: hey, replied to https://github.com/nextcloud/nextcloud-snap/issues/913
[08:14] <niemeyer> zyga: Did you review the PR?
[08:15] <niemeyer> zyga: Good morning
[08:15] <zyga> niemeyer: good morning
[08:15] <zyga> niemeyer: I had a look at it, is there something wrong?
[08:15] <niemeyer> Feels flimsy
[08:15] <niemeyer> It broke because we're using awk to parse yaml
[08:15] <zyga> I'm happy to rework it, let me look again
[08:16] <niemeyer> The PR puts more shell to make more guesses about what the document happens to be
[08:16] <niemeyer> Trivial to break it again
[08:16] <zyga> sure, I'll make it less reliant on shell
[08:25] <niemeyer> zyga: The proper fix is to not use awk or head to parse yaml
[08:43]  * zyga had to help with the baby, back now
[08:43] <zyga> niemeyer: yeah, I have an idea how to do that now
[08:44] <niemeyer> Python would do
[08:44] <niemeyer> Single command line.. python3 -c "import yaml"
[08:50] <mborzecki> hmmm when a test suite is embedded in another test suite, and the first one has Test* funcs, shared tests are doubled when both suites are run
[08:50] <pedronis> mborzecki: yes
[08:50] <mborzecki> kind of expected when one things about it, but still a bit meh when doing a larger split
[08:51] <pedronis> you really need to create a Base
[08:51] <pedronis> of some kind
[08:51] <pedronis> without tests
[08:51] <mborzecki> s/things/thinks/
[08:51] <pedronis> for the share fixture stuff
[08:51] <pedronis> there are some examples
[08:51] <pedronis> in the code base
[08:51] <mborzecki> yeah, my concern is actually untangling devicemgr test suite
[08:52] <mborzecki> tried to be 'smart' about it :/
[08:52] <pedronis> mborzecki: if it's too onoreous you can always do it in two steps
[08:52] <pedronis> just split tests across files but keep one suite
[08:52] <pedronis> and do the suite splitting when it's less blocking
[08:52] <mborzecki> pedronis: mhm, that's what i have now
[08:53] <mborzecki> i suppose is good enough for now, at least the test file is no longer 4k+ lines
[08:53] <pedronis> yes, we have some packages in that state
[08:53] <pedronis> still better than too big test files
[08:53] <pedronis> and can be improved
[08:54] <Chipaca> 4k lines? them's rookie numbers!
[08:54] <mborzecki> 8 files changed, 4699 insertions(+), 4516 deletions(-)
[08:54] <mborzecki> heh
[08:54]  * Chipaca looks at snapstate_test
[08:55] <mup> PR snapd#7643 opened: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel :train:> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>
[08:55] <Chipaca> hmmm
[08:55] <zyga> niemeyer: yep, fixed locally, just running a quick check before pushing
[08:55] <mborzecki> haha github decided it's not going to show diffs ;P
[08:55] <zyga> are you seeing that too?
[08:56] <zyga> for the past few days I had issues with diff pane
[08:56] <zyga> it was just empty, apart from the typical github UI
[08:56] <mborzecki> zyga: nah, the diffs are just too large in this PR
[08:56] <Chipaca> #7643
[08:56] <mup> PR #7643: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel 🚋> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>
[08:56] <Chipaca> \o/
[08:58] <mvo> mborzecki: 7640 is ready for a review
[09:02] <zyga> niemeyer: updated now
[09:03] <zyga> oops
[09:03] <zyga> no permission to push
[09:05] <zyga> niemeyer: opened https://github.com/snapcore/spread/pull/92
[09:05] <mup> PR spread#92: tests: fix ad-hoc test <Created by zyga> <https://github.com/snapcore/spread/pull/92>
[09:09] <mborzecki> pushed a really shallow suite split with common suite
[09:18] <zyga> mborzecki: 8K diff
[09:18] <zyga> mborzecki: very appropriate, 5K is passe
[09:19] <niemeyer> zyga: Thanks! Let's see if it passes
[09:27] <mborzecki> heh, go.mod broke gorename?
[09:31] <zyga> niemeyer: it's green :)
[09:32] <niemeyer> ... and it's in
[09:32] <zyga> super! thank you
[09:33] <zyga> niemeyer: this was a prelude to a change that does more than just fixes tests: https://github.com/snapcore/spread/pull/90
[09:33] <mup> PR spread#90: runner: remove filterDir, default include to "." <Created by zyga> <https://github.com/snapcore/spread/pull/90>
[09:37] <niemeyer> Reviewed
[09:38] <zyga> niemeyer: the motivation behind this change is to eventually have "tar" invoked with project path and not the individual files and directories
[09:39] <zyga> niemeyer: because that in turns allows us to say tar --exclude-vcs-ignore, which will automatically handle .gitignore
[09:39] <zyga> niemeyer: there's an older branch that builds towards handling .gitignore: https://github.com/snapcore/spread/pull/89
[09:39] <mup> PR spread#89: runner: pass --exclude-vcs-ignores to tar <Created by zyga> <https://github.com/snapcore/spread/pull/89>
[09:39] <niemeyer> zyga: There are two different issues here:
[09:40] <niemeyer> The first one is that spread is meant to send whatever files the project needs it to send, and also exclude whatever files it wants to to drop
[09:40] <niemeyer> We cannot make assumptions about what the person using spread is actually trying to do with it
[09:40] <niemeyer> But you as the spread user should be able to tune that list to your desires
[09:41] <zyga> I agree, and therefore the idea is to allow users to configure spread to respect .gitignore-like files if they are present
[09:41] <niemeyer> The second thing is that filterDir has a specific purpose. The PR dropped that purpose silently, and said nothing about it. That's usually a bad sign.
[09:41] <niemeyer> zyga: The fact you want files to be ignored by git is not an indication that you want spread not to ship them
[09:41] <zyga> niemeyer: did I miss the prupose? it is duplicated by how tar is invoked
[09:42] <niemeyer> zyga: What is being done by filterDIr?
[09:42] <zyga> niemeyer: we filter out spread-reuse files
[09:42] <niemeyer> zyga: Maybe I'm the one missing it
[09:42] <zyga> niemeyer: but this is redundant because the way spread invokes tar does that already
[09:42] <zyga> niemeyer: it's not in the diff here because that part did not have to change
[09:43] <niemeyer> zyga: I see now, sorry and thanks
[09:43] <niemeyer> zyga: Let me play with it to see how it diverges if it all
[09:43] <niemeyer> if at all
[09:44] <zyga> niemeyer: thanks!
[09:44] <zyga> niemeyer: I think this part is safe, it really is about working around a bug in tar
[09:44] <zyga> niemeyer: tar needs to be shown the root of the project for it to consider .gitignore there (along with the required option to read it)
[09:45] <zyga> niemeyer: separarely https://github.com/snapcore/spread/pull/91 can be closed now because it was a part of the branch you just merged
[09:45] <mup> PR spread#91: tests: Fix adhoc test <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/91>
[09:47] <niemeyer> zyga: So, the outcome is different indeed:
[09:47] <zyga> oh?
[09:48] <niemeyer> https://www.irccloud.com/pastebin/kb82VgAp/
[09:49] <niemeyer> Weird..
[09:49] <niemeyer> The pastebin corrupted line breaks
[09:49] <zyga> is that different on the receiving end?
[09:49] <niemeyer> Yeah, I suspect these paths are actually stored into the file
[09:49] <niemeyer> Double checking
[09:50] <niemeyer> https://www.irccloud.com/pastebin/bXQa7OJX/
[09:58] <mup> PR snapd#7644 opened: gadget: rename existing and add new helpers for checking filesystem/partition presence <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7644>
[10:04] <zyga> mborzecki: https://github.com/snapcore/spread/pull/85 needs master merge
[10:04] <mup> PR spread#85: spread/client: workaround bash 4.3 subshell errexit issues <Created by bboozzoo> <https://github.com/snapcore/spread/pull/85>
[10:56] <zyga> brbr, need tea
[10:58] <zyga> we have a confusing spread system naming pattern
[10:59] <zyga> imagine in 2064
[10:59] <zyga> spread -debug -v google:ubuntu-core-64-64:
[11:02] <pedronis> :)
[11:07] <pedronis> it's non-problem until 2028, I mean we might want to clean it up, but I don't think we should do that now particularly
[11:07] <Chipaca> ubuntu-core-64-128 \o/
[11:08] <pedronis> I mean ubuntu-core-30-32  start to get confusing, otoh there might not be a 32 anymore at that point
[11:11] <zyga> ;D
[11:11] <zyga> I was totally joking btw
[11:11] <zyga> Iza is back, made her some tea as well
[11:26] <zyga> hmm
[11:26] <zyga> mvo: did we do any changes to core/core16 recently?
[11:27] <zyga> mvo: I'm seeing /system-data/etc/systemd/user added to host mount table
[11:27] <zyga> or is the test flawed
[11:27]  * zyga runs a small experiment
[11:29] <mup> PR snapd#7636 closed: gadget, overlord/devicestate: add support for customized update policy, add remodel policy <Remodel 🚋> <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7636>
[11:29] <zyga> listening to Parliament today, we should change our job titles to "due of snapd"
[11:29] <zyga> "duke*"
[11:31] <zyga> ah, I think I know why
[11:31] <zyga> but it needs changes anyway
[11:31]  * zyga small break
[11:42] <mup> PR snapd#7645 opened: client: add xerrors and wrap errors coming from "client" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7645>
[11:43] <mvo> zyga: this got added iirc because of the user session service that was added recently
[11:46] <zyga> mvo: that's excellent, thank you for confirming this
[11:50] <zyga> mvo: reviewed https://github.com/snapcore/snapd/pull/7645#pullrequestreview-305827995
[11:50] <mup> PR #7645: client: add xerrors and wrap errors coming from "client" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7645>
[11:51] <zyga> mborzecki: conflicts on https://github.com/snapcore/snapd/pull/7643
[11:51] <mup> PR #7643: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel 🚋> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>
[11:52] <mborzecki> ah damn, i expected the other PR to be in conflict
[11:53] <zyga> ijohnson, mborzecki: can you please finish your review on https://github.com/snapcore/snapd/pull/7639
[11:53] <mup> PR #7639: interfaces: emit update-ns snippets to function <Created by zyga> <https://github.com/snapcore/snapd/pull/7639>
[11:53] <zyga> it will help to review the bugfix PR in the evening
[11:58] <ogra> Chipaca, are you able to add categories in the forum ? i tend to think we should have a "multipass" one
[12:07] <zyga> what the .... ?!?!
[12:07]  * zyga looks closer
[12:08] <ijohnson> zyga sure thing, I'll get on that right after breakfast and then SU
[12:08] <zyga> thanks!
[12:10] <zyga> WHAT THE ?!
[12:10] <zyga> mvo: something changed drastically in core16
[12:10] <zyga> mvo: do you have a sec?
[12:11]  * Chipaca takes a break
[12:15] <zyga> mborzecki: you won't believe what's in this commit message
[12:15] <mup> PR snapd#7646 opened: tests: update mount-ns after addition of /etc/systemd/user <Created by zyga> <https://github.com/snapcore/snapd/pull/7646>
[12:15] <zyga> mborzecki: please have a look, I think we need to understand what is going on
[12:15] <zyga> note that core18 is okay
[12:16] <zyga> it was not affected by whatever caused this
[12:16] <mborzecki> zyga: one in 7646?
[12:16] <zyga> I'm looking at anything merged to snap-confine
[12:16] <zyga> yes
[12:16] <zyga> mborzecki: for the purpose of staying honest I can split this into two patches
[12:16] <zyga> but please read it first
[12:18] <zyga> mborzecki: I strongly suspect it is a fallout from 4b4cf41fd17951157221f406e6f7a5bb5f2f6fff
[12:19] <zyga> it probably was me not noticing the test didn't run
[12:19] <zyga> I'll double check in a moment
[12:20] <zyga> but I don't understand how this affects everything outside of /snap yet
[12:21] <zyga> hmm, but I did change the data set there
[12:21] <zyga> it cannot be that
[12:24] <zyga> I cannot find anything that would explain this in changes since the 6th of September
[12:32] <zyga> hmmmm
[12:32] <zyga> maybe a false alarm
[12:32] <zyga> I think I confused multiple runs together, I cannot reproduce this now, it must have been a run from the branch that enables sharing
[12:32] <zyga> mborzecki: I think crisis averted
[12:37] <mup> PR snapd#7644 closed: gadget: rename existing and add new helpers for checking filesystem/partition presence <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7644>
[12:38] <mborzecki> do we intend to land #7642?
[12:38] <mup> PR #7642: travis.yml: add 'sh -x' to run-checks <Created by mvo5> <https://github.com/snapcore/snapd/pull/7642>
[12:49] <zyga> mborzecki: please look at the last comment on https://github.com/snapcore/snapd/pull/7643
[12:49] <mup> PR #7643: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel 🚋> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>
[12:50] <ahasenack> hi guys, all my snaps stopped working this morning, I get this message:
[12:51] <ahasenack> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[12:51] <zyga> ahasenack: hello
[12:51] <zyga> ahasenack: can you please provide the output of "snap version"
[12:51] <ahasenack> zyga: hi, https://pastebin.ubuntu.com/p/fNNY5Fbk6t/
[12:52] <zyga> ahasenack: can you please share the output of systemctl status apparmor.service
[12:52] <ahasenack> zyga: https://pastebin.ubuntu.com/p/dcWgC4K2CV/
[12:52] <ahasenack> sounds like I have an ordering problem in systemd services
[12:53] <ahasenack> let me delete the zfskey one
[12:53] <zyga> something is off
[12:53] <zyga> can you paste the output of journalctl -u apparmor.service
[12:54] <ahasenack> it's the same, but I now started it explicitly, and it worked
[12:54] <ahasenack> zfskey-nsnx@nsnx.service/start is a systemd service I added recently, I'm guessing it has impossible targets/ordering
[12:54] <ahasenack> snaps are working after I started apparmor
[12:56] <zyga> thanks!
[12:56] <zyga> good luck :)
[12:57] <mvo> zyga: sorry, was at lunch
[12:57] <zyga> mvo: no more crisis :)
[12:58] <jdstrand> Saviq: fix, but...
[12:58] <jdstrand> sergiusens (cc Saviq): hey, is snapcraft running the review-tools in travis/LP now?
[12:58] <Saviq> o/ jdstrand
[12:59] <mup> PR snapd#7641 closed: tests: moving ubuntu-19.10-64 from google-unstable to google backend <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7641>
[12:59] <sergiusens> jdstrand: not yet, that is my next work item after I get some core20 stuff out of the way
[12:59] <jdstrand> sergiusens: Saviq mentioned https://travis-ci.org/CanonicalLtd/multipass/jobs/601308279#L4750, which I was surprised to see
[13:00] <sergiusens> jdstrand: line 55 and 59 from https://travis-ci.org/CanonicalLtd/multipass/jobs/601308279/config
[13:00] <jdstrand> sergiusens: since there are probably some things we want to auto-block on, but others we do not (eg, it would be ok to let the store handle personal-files, for example)
[13:01] <mup> PR snapd#7647 opened: gadget: skip structures with no partition table entry during remodel <Remodel 🚋> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7647>
[13:01] <jdstrand> sergiusens: ah, ok. note ^ before enabling everywhere :)
[13:01] <sergiusens> jdstrand: this was the contentious topic we did not reach an agreement on, we have no way to know what was whitelisted store side
[13:02] <zyga> jdstrand: hello! :)
[13:02] <jdstrand> sergiusens: right. so, you can give snap-review '--json' then read that and decide what to and what not to block on
[13:03] <jdstrand> sergiusens: eg, you could choose to entirely skip declaration-snap-v2
[13:03] <jdstrand> s/skip/ignore/
[13:03] <jdstrand> zyga: hi :)
[13:03] <zyga> jdstrand: I will have some things for you after the standup
[13:07] <sergiusens> jdstrand: should we also --allow-classic if the snap is classic? Do the review-tools issue some output when that flag is used?
[13:08] <Saviq> jdstrand: we're running it ourselves explicitly
[13:09] <Saviq> but it's likely we're using it wrong :)
[13:12] <jdstrand> Saviq: yeah, see that and now, you are fine, though you may want to set SNAP_ENFORCE_RESQUASHFS=0 for faster reviews
[13:12] <jdstrand> sergiusens: you will probably want that ^ too, or at the very least a way to opt in/out of it
[13:13] <Saviq> jdstrand: I just wonder if there's something we can do to make it pass with the new plugs? Does that talk to the store for assertions or?
[13:13] <jdstrand> zyga: fyi, I will be looking at https://github.com/snapcore/snapd/pulls/review-requested/jdstrand this week
[13:13] <jdstrand> Saviq: I issued the snap decl already. I said 'fix', I meant, 'I fixed it'
[13:14] <Saviq> Ah! :)
[13:14] <Saviq> ChrisTownsend: ^^
[13:14] <jdstrand> Saviq: actually, I only fixed part of it
[13:14] <zyga> jdstrand: thank you :)
[13:14] <jdstrand> Saviq, ChrisTownsend: when it is uploaded to the store, it will now pass
[13:15] <jdstrand> Saviq, ChrisTownsend: but not on your invocation of snap-review. gimme a sec for an updated invocation
[13:15]  * ChrisTownsend reads backlog
[13:16] <zyga> jdstrand: I prepared the apparmor memory fix in a way I believe can land after your reviews and some follow-ups for things like function names and typical iteration elements
[13:16] <dot-tobias> zyga / jdstrand: Re the NetworkManager D-Bus Introspectable issue from yesterday (https://bugs.launchpad.net/snapd/+bug/1849291) → sorry for being impatient, but I need a rough timeframe when this will be available in core to decide if I should postpone the refactor in my snap until Introspectable is allowed in the network-manager interface. Let me know if I can be of any help!
[13:16] <mup> Bug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable <papercut> <snapd:Confirmed> <https://launchpad.net/bugs/1849291>
[13:17] <zyga> jdstrand: I included a memory usage test as well
[13:17] <zyga> dot-tobias: I didn't manage to do it yesterday but I can propose a fix today
[13:17] <zyga> dot-tobias: please ask mvo about release schedule for core / snapd
[13:18] <dot-tobias> zyga: That would be marvelous, thank you! Will do
[13:18] <mvo> dot-tobias: is there a PR for this issue yet?
[13:18] <mvo> dot-tobias: (in a meeting so I may a bit slow replying)
[13:19] <zyga> mvo: no, not yet, it's a small change to allow dbus introspection method on network manager that was missing before
[13:24] <jdstrand> ChrisTownsend (cc Saviq): https://paste.ubuntu.com/p/RChQs4dkTQ/
[13:25] <Saviq> jdstrand: ack, thanks!
[13:26] <ChrisTownsend> jdstrand: cool, thanks!
[13:27] <Saviq> jdstrand: in theory we could also download the snap declaration from the store, right? So that we can flag any changes necessary early?
[13:28] <zyga> ijohnson: https://github.com/snapcore/snapd/pull/7547#issuecomment-545280953
[13:28] <ijohnson> zyga: after reading your response that all makes sense
[13:28] <mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
[13:28] <zyga> cool, excellent :)
[13:28] <pedronis> pstolowski: about that kind of code (loadSeed), you don't need to create the db either, you can pass nils to LoadAssertions, it's created there because the test wants to look at it
[13:30] <ijohnson> zyga: re-approved
[13:30] <zyga> ijohnson: woot, thanks!
[13:31] <pstolowski> pedronis: ah, good, this just answered another dillema that i'd have, good
[13:32] <pedronis> pstolowski: go doc Seed in seed should be helpful (it says this e.g.) hopefully
[13:33] <pedronis> mvo: pstolowski: I'm touching that area again, how strongly would you like me to change the places we use cstr(s) for constraint(s) expanding them to the full word, I vaguely remember you commented on this at some point
[13:36] <zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/7646
[13:36] <mup> PR #7646: tests: update mount-ns after addition of /etc/systemd/user <Created by zyga> <https://github.com/snapcore/snapd/pull/7646>
[13:36] <cachio> degville, hey
[13:36] <cachio> degville, I am free, just ping me when you have time
[13:36] <degville> cachio: hello!
[13:36] <cachio> ah, you already sent the app
[13:37] <cachio> perfect
[13:37] <mup> PR snapd#7579 closed: interfaces/net-setup-{observe,control}: add Info D-Bus method accesses <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7579>
[13:37] <degville> cachio: ok, cool! I was just going to say maybe 5 mins because I'm eating a bowl of sauerkraut :)
[13:37] <sergiusens> pedronis, mvo: would be nice to see some UX improvements on mandatory interfaces so every snap does not have to reimplement the wheel (which would bring wrappers into play again) https://forum.snapcraft.io/t/missing-shared-library-for-digikam/13674
[13:38] <cachio> degville, hehe
[13:38] <zyga> jdstrand: can you read the topic of the bug on https://bugs.launchpad.net/snapd/+bug/1849291 and comment if that's something that should be fixed
[13:38] <mup> Bug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable <papercut> <snapd:Confirmed> <https://launchpad.net/bugs/1849291>
[13:38] <zyga> jdstrand: the fix is simple and I can handle that today
[13:39] <ijohnson> zyga: also approved #7639
[13:39] <mup> PR #7639: interfaces: emit update-ns snippets to function <Created by zyga> <https://github.com/snapcore/snapd/pull/7639>
[13:40] <zyga> ijohnson: excellent, thank you
[13:40] <zyga> I will review comments and open follow-ups
[13:40] <pstolowski> pedronis: not super critical imho.. and there is a lot of those. i think it's better if your changes re greedy plugs are only about the new functionality, not renaming
[13:40] <pedronis> pstolowski: ok, I would have done them separately, not mixed
[13:40] <mup> PR snapd#7639 closed: interfaces: emit update-ns snippets to function <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7639>
[13:40] <pedronis> just gauging how annoying people find the current status
[13:41] <pedronis> I might just change things in policy because it might make the new code clearer
[13:41] <pedronis> and leave asserts alone for now
[13:41] <mborzecki> zyga: heh so we actually had user.conf.d for overriding the user session manager but didn't have /etc/systemd/user/ ?
[13:44] <jdstrand> Saviq: re download> you could, but it is in a modified yaml format so you would have to parse/translate it to json
[13:44] <zyga> mborzecki: yes
[13:44] <zyga> ;D
[13:44] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/7632 is ready from my POV
[13:44] <mup> PR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
[13:44] <mborzecki> well, at least it's accounted for now
[13:53] <oSoMoN> jdstrand, not sure whether this has been reported in the past: bug #1848919 , the home interface prevents access to ~/.Private, is there anything that can be done about it without compromising security?
[13:53] <mup> Bug #1848919: [snap] Permission denied on Private encrypted folder <chromium-browser (Ubuntu):Confirmed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1848919>
[13:53] <zyga> ijohnson: https://github.com/snapcore/snapd/pull/7632 needs a re-review from you, I believe the concern you had was addressed
[13:53] <mup> PR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
[13:53] <ijohnson> yes I'm re-reviewing it as we speak :-)
[13:53] <zyga> super, thank you! :)
[13:59] <mup> PR snapd#7648 opened: interfaces/policy: expand cstrs/cstrs1 to altConstraints/constraints <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7648>
[14:00] <pedronis> pstolowski: ^
[14:02] <pstolowski> pedronis: that's not too bad, i thought there were more. thanks
[14:02] <pedronis> pstolowski: not in policy
[14:02] <pedronis> there's a ton in asserts/ifacedecls*.go
[14:02] <pedronis> that's a bit more work, will leave it alone for now
[14:04] <pstolowski> pedronis: +1
[14:12] <jdstrand> zyga: commented
[14:15] <jdstrand> oSoMoN: I responded in the bug
[14:19] <Saviq> jdstrand: while we have a direct line with you ;), would you please allow auto-connection for kvm, network-control and firewall-control?
[14:19] <oSoMoN> jdstrand, thanks, I'll reproduce in a VM and will post the denial
[14:20] <Saviq> jdstrand: if you'd rather us go through the forum, just say so
[14:21] <jdstrand> Saviq: normally, yes, but this has been discussed previously, so I'll just make sure the reviewers are aware I did it
[14:22] <jdstrand> Saviq: cone
[14:22] <jdstrand> done*
[14:22] <Saviq> jdstrand: thanks!
[14:26] <zyga> jdstrand: thanj you
[14:26] <mup> PR snapcraft#2763 opened: "snap debug validate-seed" fails if the slot is specified in the default-provider <Created by kenvandine> <https://github.com/snapcore/snapcraft/pull/2763>
[14:26] <zyga> Saviq: as for the multipass category, if this is more popular as a theme, perhaps we should have a snap:multipass category instead, to indicate that this is a topic for a particular snap
[14:27] <Saviq> it's really more about snapcraft's use of Multipass there, so maybe a tag is more appropriate
[14:30] <oSoMoN> jdstrand, I commented on the bug with the denial I'm seeing
[14:31]  * zyga goes for lunch
[14:31] <zyga> Saviq: ah, I see
[14:33] <mvo> pedronis: I think 7626 is ready for another review, I think I addressed the points you raised
[14:35] <joedborg> morning all!  if anyone could cast their eyes on https://forum.snapcraft.io/t/fatal-python-error-py-initialize-unable-to-get-the-locale-encoding/13844 (TLDR, getting a python error with snapcraft), it'd be great
[14:39] <mvo> pedronis: also it looks like the following change broke the seeding of gnome-calculator https://paste.ubuntu.com/p/BJBBRkdcRQ/ - their snap is now adding something like  default-provider: gnome-3-28-1804:gnome-3-28-1804 and our validate-seed seems to break on this :/
[14:40] <pedronis> mvo: ?
[14:40] <pedronis> it's our change, no?
[14:40] <pedronis> default-provider is not a slot or  a plug
[14:40] <pedronis> what are they trying to do?
[14:40] <mvo> dot-tobias: uh, I think I did not get back to you about this bug we talked earlier. sorry for that. if its a trivial fix we could pull it in
[14:40] <mvo> pedronis: I don't know, its apparently snapcraft adding this
[14:41] <pedronis> mvo: the gnome extension thingy?
[14:41] <mvo> pedronis: in the kde and gnome plugsin
[14:41] <mvo> pedronis: yeah
[14:41] <pedronis> well, is not a snapd bug
[14:41] <mvo> pedronis: I need to look at the code, I think we allowed ":" there for histric reasons
[14:42] <pedronis> ?
[14:42] <mvo> pedronis: sorry, I will dig into this myself, the information I have is that building an image is currently failing withhttps://launchpadlibrarian.net/447954589/buildlog_ubuntu_focal_amd64_ubuntu_BUILDING.txt.gz
[14:43] <mvo> pedronis: https://launchpadlibrarian.net/447954589/buildlog_ubuntu_focal_amd64_ubuntu_BUILDING.txt.gz
[14:43] <mvo> pedronis: and I had a quick look and noticed the default provider changed in the snap
[14:43] <mvo> pedronis: now I need to remember things about this :/
[14:45] <pedronis> mvo: ok, yes
[14:45] <pedronis> we have two form of code
[14:46] <pedronis> we have a bit too many pieces of code extracting default providers
[14:47] <pedronis> mvo: we have this:  https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapstate.go#L490
[14:48] <mup> PR snapd#7649 opened: overlord: fix TestRemodelSwitchToDifferentKernel for bootvars <Created by mvo5> <https://github.com/snapcore/snapd/pull/7649>
[14:48] <pedronis> and this: https://github.com/snapcore/snapd/blob/master/snap/validate.go#L957
[14:49] <pedronis> they don't do the same thing
[14:50] <pedronis> mvo: we have a 3rd as well
[14:50] <mvo> pedronis: hrm, hrm, sounds like a good target for unification - oh well
[14:50] <mvo> pedronis: I try to have a look today
[14:51] <kenvandine> mvo: does this mean the kde snaps aren't working the way they think they are?
[14:51] <kenvandine> if the slot is being stripped...
[14:51] <pedronis> mvo: https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/handlers.go#L698
[14:52] <pedronis> it's not a slot
[14:53] <pedronis> / The default-provider is a name. However old
[14:53] <pedronis> 				// documentation said it is "snapname:ifname",
[14:53] <pedronis> 				// we deal with this gracefully by just
[14:53] <pedronis> 				// stripping of the part after the ":"
[14:54] <pedronis> of course only one place in our code does that, so there might be wobblyness anyway
[14:54] <kenvandine> yeah, but the kde snaps are trying to connect a plug with a different name than the slot
[14:54] <kenvandine> in the default-provider
[14:54] <pedronis> that's not a thing
[14:54] <kenvandine> what they are doing might not really work...
[14:55] <pedronis> usually what happens is that the default-provider kicks in
[14:55] <pedronis> and then auto-connection does its job
[14:55] <pedronis> that's kind of the only way it works
[14:55] <pedronis> s/kicks in/gets installed/
[14:56] <pedronis> mvo: our docs still says this:  default-provider (plug): name and slot of preferred providing snap (<SNAP>:<SLOT>)
[14:56] <pedronis> but we never implemented that
[14:56] <pedronis> funny
[14:56] <kenvandine> i'm saying the kde snaps are including the slot in the default-provider, and that slot name isn't the same as the plug name
[14:56] <pedronis> kenvandine: apparently it's documented
[14:56] <pedronis> but even I was not aware of that
[14:56] <kenvandine> plug=kde-frameworks-5-plug has default-provider = kde-frameworks-5-core18:kde-frameworks-5-core18-slot
[14:57] <pedronis> and as far as I know, it never was implemented like that
[14:57] <pedronis> you need mvo and zyga to tell you more
[14:58] <kenvandine> ok
[14:58] <pedronis> kenvandine: see this post by Gustavo: https://forum.snapcraft.io/t/the-snapd-roadmap/1973/9
[14:58] <pedronis> which doesn't match the doc
[14:58] <kenvandine> the seed validation are failing for something that's documented :)
[14:58] <pedronis> and doesn't work as documented
[14:58] <pedronis> and wasn't implemented as documented
[14:58] <kenvandine> indeed
[14:59] <pedronis> it's kind of a pain to implement it as documented actually
[14:59] <pedronis> so I don't see it get it fixed quickly
[14:59] <pedronis> to work as originally documented
[14:59] <pedronis> we can fix it quickly to ignore in more places
[14:59] <pedronis> kenvandine: I would like to understand if the feature is really needed
[15:00] <pedronis> it's not been there in that form
[15:00] <pedronis> ever
[15:00] <kenvandine> pedronis: i not really concerned to much about the feature
[15:00] <om26er> is there a way to expose an environment variable from one snap to another ? think snap A exposing what port snap B should connect to it on
[15:00] <kenvandine> the issue is the extension includes the slot in the default-provider and it is now breaking iso builds
[15:00] <pedronis> kenvandine: I understand
[15:01]  * zyga breaks for an hour
[15:01] <zyga> or two
[15:01] <pedronis> kenvandine: we can fix snapd to ignore it, but I think the extension should stop to add the slot
[15:01] <pedronis> at some point soon
[15:01] <zyga> need to go while there's some sunlight still
[15:01] <pedronis> and we need to do something about the doc
[15:03] <pedronis> om26er: not unless an interface is involved, all snaps to snaps relations should be via interfaces
[15:03] <zyga> om26er: this can be done via interface hooks, as a part of the post-connection "those are the attributes" phase for example
[15:04] <zyga> om26er: but as pedronis said it must be modeled as an interface
[15:04]  * zyga really AFK
[15:30] <ijohnson> hmm I can't seem to restart travis jobs anymore
[15:30] <ijohnson> can someone restart https://travis-ci.org/snapcore/snapd/jobs/601379249 for me? it failed due to store problems
[15:34]  * cachio lunch
[15:34] <pedronis> ijohnson: done
[15:35] <ijohnson> thanks pedronis
[15:35] <mup> PR snapcraft#2764 opened: Snapd doesn't actually honor the slot specified in the default-provider <Created by kenvandine> <https://github.com/snapcore/snapcraft/pull/2764>
[16:01] <mvo> team: 7595 needs a second review, would unblock some uc20 work (maybe ijohnson?)
[16:01] <ijohnson> mvo: ok I can take a look in my afternoon
[16:02] <mvo> ijohnson: great, thank you!
[16:08] <ogra> mvo, oh, 1849515 is an interesting one ... on zfs installs seemingly /var(snap becomes a mounted zpool so rm'ing it from the postinst seems to fall over
[16:08] <ogra> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849515
[16:08] <mup> Bug #1849515: package snapd (not installed) failed to install/upgrade: »installiertes snapd-Skript des Paketes post-removal«-Unterprozess gab den Fehlerwert 1 zurück <amd64> <apport-package> <focal> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1849515>
[16:36] <sil2100> mvo: hey! Could you sign-off formally on the UC20 u-i image spec if you have a moment? ;)
[16:43] <jdstrand> oSoMoN: one more question in the bug
[16:47] <Saviq> harr harr harr https://imgur.com/a/bRb6M1T
[16:53] <oSoMoN> jdstrand, replied
[17:13] <mup> PR snapd#7638 closed: interfaces/u2f-devices: add OnlyKey to devices list <Created by onlykey> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7638>
[17:20] <kenvandine> jdstrand: gnome-nibbles was getting rejected due to symlink issues.  I've fixed them and now it's rejected for the dbus slot... which isn't new
[17:20] <mup> PR snapd#7631 closed: interfaces/pulseaudio: adjust to manually connect by default <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/7631>
[17:21] <kenvandine> jdstrand: oh... maybe it's because the case changed :)
[17:27] <mup> PR snapcraft#2765 opened: remote-build: initial Windows support <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2765>
[17:30] <mup> PR snapcraft#2759 closed: remote-build: https token support <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2759>
[17:30] <mup> PR snapcraft#2762 closed: appstream: extract title and version <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2762>
[17:33] <mvo> ogra: thank you! we have a look, we just discussed this in our standup and we will add a 19.10 zfs machine to spread
[17:36] <jdstrand> kenvandine: it is the case change. I adjusted and it is passing now
[17:36] <kenvandine> thanks, i forgot when i bumped the version a few weeks ago i had to change the case
[17:45] <mup> PR snapcraft#2752 closed: errors: migrate handful of errors to SnapcraftException <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2752>
[17:45] <mup> PR snapcraft#2758 closed:  appstream: support legacy ids without desktop suffix  <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2758>
[17:54] <mup> PR snapcraft#2747 closed: nodejs plugin: fix errors when building in confinement <Created by NickZ> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2747>
[17:57] <mup> PR snapcraft#2672 closed: docker: use apt-get to avoid warnings <Created by abitrolly> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2672>
[17:57] <mup> PR snapcraft#2757 closed: Drop build_base check from make plugin. It is universal <Created by xnox> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2757>
[18:00] <mup> PR snapcraft#2699 closed: python plugin: add option to process-pipfile-lock for pipenv users <Created by cjp256> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2699>
[18:16] <zyga> re
[18:16] <zyga> I'm doing homework with kids but I'll do an evening pass and fix one more bug
[18:16] <zyga> jdstrand: is there anything I should look at from your point of view?
[18:53] <jdstrand> zyga: atm I am focusing on store reviews. it may be tomorrow when I look at it, so enjoy your eod :)
[19:08]  * cachio afk
[19:24] <zyga> jdstrand: understood, enjoy your evening as well :)
[19:24] <zyga> jdstrand: :-)
[22:24] <xnox> sergiusens:  why was https://github.com/snapcore/snapcraft/pull/2757 closed, but not merged? did i do something wrong?
[22:24] <mup> PR snapcraft#2757: Drop build_base check from make plugin. It is universal <Created by xnox> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2757>
[22:25] <sergiusens> xnox: my comment mentions I implemented it in that other PR... the plugin is not really universal, it depends on an apt based system so having the explicit check is fine
[22:27] <xnox> sergiusens:  make package is called make in rpm distros too
[22:28] <xnox> sergiusens:  so which PR should I look at?
[22:28] <xnox> sergiusens:  or which commits on master?
[22:28] <sergiusens> xnox: does "apt install make" work on RPM distros?
[22:29] <xnox> sergiusens:  obviously not =) but "yum install make" does. Reading the plugin, I got fooled that "pkg install make" works on things other than apt too =)
[22:30] <xnox> sergiusens:  i see core20 in https://github.com/snapcore/snapcraft/pull/2761/files#diff-c6b5575f0de40006219f3af3804ec78eR92 now, so yeah, that's fine
[22:30] <mup> PR snapcraft#2761: Core20 base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2761>
[22:30] <xnox> it's just it's not merged. Can you build that PR and publish it to a channel like edge/pr2761 ?
[22:31]  * xnox ponders if all PRs should be autobuilt and autopublished to edge/pr*
[22:34] <sergiusens> xnox: that would be ideal, but we cannot get attenuated macaroons yet for a channel glob like edge/pr-* so the builder would have too much access
[22:35] <xnox> ture
[22:35] <xnox> true
[23:12] <mup> PR snapcraft#2766 opened: project: truncate project directory hash <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2766>