/srv/irclogs.ubuntu.com/2019/10/23/#snappy.txt

ijohnsonmorning mvo, there's some weirdness going on with some of the spread tests where it just dies immediately before running spread04:54
ijohnsonThe SU doc for me has an example build to look at, I couldn't figure it out, almost seems like spread itself is dying04:55
ijohnsonAnyways time for me to log off, good luck04:56
mvoijohnson: thank you, I noticed this right before going to bed too, I had hoped it was a fluke04:56
mvoijohnson: thanks, get some rest!04:56
mvoijohnson: I have a look04:56
mupPR snapd#7642 opened: travis.yml: add 'sh -x' to run-checks <Created by mvo5> <https://github.com/snapcore/snapd/pull/7642>05:04
zygagood morning05:15
zygahey mvo05:16
mborzeckimorning05:18
mvohey zyga and mborzecki05:18
zygahey mborzecki05:19
mvolooks like travis has some problems sometimes05:19
mborzeckimvo: zyga: hey05:19
zygafog, fog as far as I can see :)05:19
mvoand of course my debug PR works just fine :(05:19
mborzeckihahaha05:19
zygamvo: merge everything into it and land ;)05:19
zygasome store woes yesterday05:20
zygaerror: cannot search: got unexpected HTTP status code 403 via GET to05: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_vali05:20
zygadation%2Cprivate%2Cconfinement%2Ccommon_ids&q=pc&scope=wide"05:20
zygasome 503 as well05:20
zygahello niemeyer05:37
zyganiemeyer: when you are around today could you please look at sergio's fix for spread spread tests: https://github.com/snapcore/spread/pull/9105:37
mupPR spread#91: tests: Fix adhoc test <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/91>05:37
zygamborzecki: https://github.com/snapcore/snapd/pull/7614 could use a review05:42
mupPR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>05:42
zygaand it's green (shocking)05:42
zygamvo: do you think you could look at https://github.com/snapcore/snapd/pull/754706:00
mupPR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>06:00
zygaat least conceptually06:00
zygait is already being looked at by ian and jamie but I wanted to make sure you understand what is going on there as well06:01
mvozyga: sure, was wondering if samuele needs to look but I'm happy to do it06:01
zygamvo: I think we all should look because it's such a fundamental part06:01
mvozyga: sounds good06:01
mupPR snapd#7634 closed: tests: ignore directories for go modules <Created by slimjim777> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7634>06:18
* zyga needs to garden his PRs06:19
mborzeckizyga: left some comments under your PRs06:35
mborzeckizyga: btw. what's the problem with ijohnson's named hierarchy use?06:35
zyganone?06:36
zygacan you clarify please06:36
mborzeckizyga: https://github.com/snapcore/snapd/pull/7547#pullrequestreview-305622718 but i see it was nothing weird ;P06:41
mupPR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>06:41
zygamborzecki: did you see my reply on https://github.com/snapcore/snapd/pull/7547#issuecomment-54528095306:42
mupPR 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:44
zygamvo: https://github.com/snapcore/snapd/pull/7642 is green06:51
mupPR #7642: travis.yml: add 'sh -x' to run-checks <Created by mvo5> <https://github.com/snapcore/snapd/pull/7642>06:51
mvozyga: yeah, its strange06:53
mvozyga: another of my PRs also went green06:53
zygalet's merge it and see06:53
mvozyga: maybe it was a fluke06:53
zygaquestion is what was it, your PR might answer that06:54
mvozyga: yeah, we can always revert06:54
=== pstolowski|afk is now known as pstolowski
pstolowskimorning07:04
zygahey pawel07:04
zygapstolowski: sorry to jump into this straight away but I'm hunting for reviews for the emit() branch again :)07:04
zygamborzecki: I debugged why I saw different numbers in spread and on my system, without the memory fix patch07:05
zygamborzecki: turns out my desktop had more rules because of the document portal07:05
mborzeckihah07:05
zygamborzecki: so the test is reliable07:05
zygamborzecki: it just measures a smaller set of rules07:05
zygamborzecki: but it's still clear as day and night that it is using small amount of memory vs huge before07:06
pstolowskizyga: will get to it in a moment07:06
zygapstolowski: I rebased the original PR on the emit branch now07:06
zygapstolowski: and it shows exactly how little has to change, on top of emit(), to fix the memory issue07:07
zygapstolowski: this is the only remaining patch there: https://github.com/snapcore/snapd/pull/7632/commits/03ef1bd9b36c368c64c717879098f7fbe533c38907:07
mupPR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>07:07
zygabrb07:24
zygaso cold and foggy today07:24
zygahot tea anyone?07:24
zygare07:42
zygapstolowski: thank you, replied to both07:52
zygakyrofa: hey, replied to https://github.com/nextcloud/nextcloud-snap/issues/91307:56
niemeyerzyga: Did you review the PR?08:14
niemeyerzyga: Good morning08:15
zyganiemeyer: good morning08:15
zyganiemeyer: I had a look at it, is there something wrong?08:15
niemeyerFeels flimsy08:15
niemeyerIt broke because we're using awk to parse yaml08:15
zygaI'm happy to rework it, let me look again08:15
niemeyerThe PR puts more shell to make more guesses about what the document happens to be08:16
niemeyerTrivial to break it again08:16
zygasure, I'll make it less reliant on shell08:16
niemeyerzyga: The proper fix is to not use awk or head to parse yaml08:25
* zyga had to help with the baby, back now08:43
zyganiemeyer: yeah, I have an idea how to do that now08:43
niemeyerPython would do08:44
niemeyerSingle command line.. python3 -c "import yaml"08:44
mborzeckihmmm 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 run08:50
pedronismborzecki: yes08:50
mborzeckikind of expected when one things about it, but still a bit meh when doing a larger split08:50
pedronisyou really need to create a Base08:51
pedronisof some kind08:51
pedroniswithout tests08:51
mborzeckis/things/thinks/08:51
pedronisfor the share fixture stuff08:51
pedronisthere are some examples08:51
pedronisin the code base08:51
mborzeckiyeah, my concern is actually untangling devicemgr test suite08:51
mborzeckitried to be 'smart' about it :/08:52
pedronismborzecki: if it's too onoreous you can always do it in two steps08:52
pedronisjust split tests across files but keep one suite08:52
pedronisand do the suite splitting when it's less blocking08:52
mborzeckipedronis: mhm, that's what i have now08:52
mborzeckii suppose is good enough for now, at least the test file is no longer 4k+ lines08:53
pedronisyes, we have some packages in that state08:53
pedronisstill better than too big test files08:53
pedronisand can be improved08:53
Chipaca4k lines? them's rookie numbers!08:54
mborzecki8 files changed, 4699 insertions(+), 4516 deletions(-)08:54
mborzeckiheh08:54
* Chipaca looks at snapstate_test08:54
mupPR 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
Chipacahmmm08:55
zyganiemeyer: yep, fixed locally, just running a quick check before pushing08:55
mborzeckihaha github decided it's not going to show diffs ;P08:55
zygaare you seeing that too?08:55
zygafor the past few days I had issues with diff pane08:56
zygait was just empty, apart from the typical github UI08:56
mborzeckizyga: nah, the diffs are just too large in this PR08:56
Chipaca#764308:56
mupPR #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:56
mvomborzecki: 7640 is ready for a review08:58
zyganiemeyer: updated now09:02
zygaoops09:03
zygano permission to push09:03
zyganiemeyer: opened https://github.com/snapcore/spread/pull/9209:05
mupPR spread#92: tests: fix ad-hoc test <Created by zyga> <https://github.com/snapcore/spread/pull/92>09:05
mborzeckipushed a really shallow suite split with common suite09:09
zygamborzecki: 8K diff09:18
zygamborzecki: very appropriate, 5K is passe09:18
niemeyerzyga: Thanks! Let's see if it passes09:19
mborzeckiheh, go.mod broke gorename?09:27
zyganiemeyer: it's green :)09:31
niemeyer... and it's in09:32
zygasuper! thank you09:32
zyganiemeyer: this was a prelude to a change that does more than just fixes tests: https://github.com/snapcore/spread/pull/9009:33
mupPR spread#90: runner: remove filterDir, default include to "." <Created by zyga> <https://github.com/snapcore/spread/pull/90>09:33
niemeyerReviewed09:37
zyganiemeyer: the motivation behind this change is to eventually have "tar" invoked with project path and not the individual files and directories09:38
zyganiemeyer: because that in turns allows us to say tar --exclude-vcs-ignore, which will automatically handle .gitignore09:39
zyganiemeyer: there's an older branch that builds towards handling .gitignore: https://github.com/snapcore/spread/pull/8909:39
mupPR spread#89: runner: pass --exclude-vcs-ignores to tar <Created by zyga> <https://github.com/snapcore/spread/pull/89>09:39
niemeyerzyga: There are two different issues here:09:39
niemeyerThe 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 drop09:40
niemeyerWe cannot make assumptions about what the person using spread is actually trying to do with it09:40
niemeyerBut you as the spread user should be able to tune that list to your desires09:40
zygaI agree, and therefore the idea is to allow users to configure spread to respect .gitignore-like files if they are present09:41
niemeyerThe 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
niemeyerzyga: The fact you want files to be ignored by git is not an indication that you want spread not to ship them09:41
zyganiemeyer: did I miss the prupose? it is duplicated by how tar is invoked09:41
niemeyerzyga: What is being done by filterDIr?09:42
zyganiemeyer: we filter out spread-reuse files09:42
niemeyerzyga: Maybe I'm the one missing it09:42
zyganiemeyer: but this is redundant because the way spread invokes tar does that already09:42
zyganiemeyer: it's not in the diff here because that part did not have to change09:42
niemeyerzyga: I see now, sorry and thanks09:43
niemeyerzyga: Let me play with it to see how it diverges if it all09:43
niemeyerif at all09:43
zyganiemeyer: thanks!09:44
zyganiemeyer: I think this part is safe, it really is about working around a bug in tar09:44
zyganiemeyer: 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:44
zyganiemeyer: separarely https://github.com/snapcore/spread/pull/91 can be closed now because it was a part of the branch you just merged09:45
mupPR spread#91: tests: Fix adhoc test <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/91>09:45
niemeyerzyga: So, the outcome is different indeed:09:47
zygaoh?09:47
niemeyerhttps://www.irccloud.com/pastebin/kb82VgAp/09:48
niemeyerWeird..09:49
niemeyerThe pastebin corrupted line breaks09:49
zygais that different on the receiving end?09:49
niemeyerYeah, I suspect these paths are actually stored into the file09:49
niemeyerDouble checking09:49
niemeyerhttps://www.irccloud.com/pastebin/bXQa7OJX/09:50
mupPR 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>09:58
zygamborzecki: https://github.com/snapcore/spread/pull/85 needs master merge10:04
mupPR spread#85: spread/client: workaround bash 4.3 subshell errexit issues <Created by bboozzoo> <https://github.com/snapcore/spread/pull/85>10:04
zygabrbr, need tea10:56
zygawe have a confusing spread system naming pattern10:58
zygaimagine in 206410:59
zygaspread -debug -v google:ubuntu-core-64-64:10:59
pedronis:)11:02
pedronisit's non-problem until 2028, I mean we might want to clean it up, but I don't think we should do that now particularly11:07
Chipacaubuntu-core-64-128 \o/11:07
pedronisI mean ubuntu-core-30-32  start to get confusing, otoh there might not be a 32 anymore at that point11:08
zyga;D11:11
zygaI was totally joking btw11:11
zygaIza is back, made her some tea as well11:11
zygahmm11:26
zygamvo: did we do any changes to core/core16 recently?11:26
zygamvo: I'm seeing /system-data/etc/systemd/user added to host mount table11:27
zygaor is the test flawed11:27
* zyga runs a small experiment11:27
mupPR 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
zygalistening to Parliament today, we should change our job titles to "due of snapd"11:29
zyga"duke*"11:29
zygaah, I think I know why11:31
zygabut it needs changes anyway11:31
* zyga small break11:31
mupPR snapd#7645 opened: client: add xerrors and wrap errors coming from "client" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7645>11:42
mvozyga: this got added iirc because of the user session service that was added recently11:43
zygamvo: that's excellent, thank you for confirming this11:46
zygamvo: reviewed https://github.com/snapcore/snapd/pull/7645#pullrequestreview-30582799511:50
mupPR #7645: client: add xerrors and wrap errors coming from "client" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7645>11:50
zygamborzecki: conflicts on https://github.com/snapcore/snapd/pull/764311:51
mupPR #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:51
mborzeckiah damn, i expected the other PR to be in conflict11:52
zygaijohnson, mborzecki: can you please finish your review on https://github.com/snapcore/snapd/pull/763911:53
mupPR #7639: interfaces: emit update-ns snippets to function <Created by zyga> <https://github.com/snapcore/snapd/pull/7639>11:53
zygait will help to review the bugfix PR in the evening11:53
ograChipaca, are you able to add categories in the forum ? i tend to think we should have a "multipass" one11:58
zygawhat the .... ?!?!12:07
* zyga looks closer12:07
ijohnsonzyga sure thing, I'll get on that right after breakfast and then SU12:08
zygathanks!12:08
zygaWHAT THE ?!12:10
zygamvo: something changed drastically in core1612:10
zygamvo: do you have a sec?12:10
* Chipaca takes a break12:11
zygamborzecki: you won't believe what's in this commit message12:15
mupPR 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
zygamborzecki: please have a look, I think we need to understand what is going on12:15
zyganote that core18 is okay12:15
zygait was not affected by whatever caused this12:16
mborzeckizyga: one in 7646?12:16
zygaI'm looking at anything merged to snap-confine12:16
zygayes12:16
zygamborzecki: for the purpose of staying honest I can split this into two patches12:16
zygabut please read it first12:16
zygamborzecki: I strongly suspect it is a fallout from 4b4cf41fd17951157221f406e6f7a5bb5f2f6fff12:18
zygait probably was me not noticing the test didn't run12:19
zygaI'll double check in a moment12:19
zygabut I don't understand how this affects everything outside of /snap yet12:20
zygahmm, but I did change the data set there12:21
zygait cannot be that12:21
zygaI cannot find anything that would explain this in changes since the 6th of September12:24
zygahmmmm12:32
zygamaybe a false alarm12:32
zygaI think I confused multiple runs together, I cannot reproduce this now, it must have been a run from the branch that enables sharing12:32
zygamborzecki: I think crisis averted12:32
mupPR 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:37
mborzeckido we intend to land #7642?12:38
mupPR #7642: travis.yml: add 'sh -x' to run-checks <Created by mvo5> <https://github.com/snapcore/snapd/pull/7642>12:38
=== ricab is now known as ricab|lunch
zygamborzecki: please look at the last comment on https://github.com/snapcore/snapd/pull/764312:49
mupPR #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:49
ahasenackhi guys, all my snaps stopped working this morning, I get this message:12:50
ahasenacksnap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks12:51
zygaahasenack: hello12:51
zygaahasenack: can you please provide the output of "snap version"12:51
ahasenackzyga: hi, https://pastebin.ubuntu.com/p/fNNY5Fbk6t/12:51
zygaahasenack: can you please share the output of systemctl status apparmor.service12:52
ahasenackzyga: https://pastebin.ubuntu.com/p/dcWgC4K2CV/12:52
ahasenacksounds like I have an ordering problem in systemd services12:52
ahasenacklet me delete the zfskey one12:53
zygasomething is off12:53
zygacan you paste the output of journalctl -u apparmor.service12:53
ahasenackit's the same, but I now started it explicitly, and it worked12:54
ahasenackzfskey-nsnx@nsnx.service/start is a systemd service I added recently, I'm guessing it has impossible targets/ordering12:54
ahasenacksnaps are working after I started apparmor12:54
zygathanks!12:56
zygagood luck :)12:56
mvozyga: sorry, was at lunch12:57
zygamvo: no more crisis :)12:57
jdstrandSaviq: fix, but...12:58
jdstrandsergiusens (cc Saviq): hey, is snapcraft running the review-tools in travis/LP now?12:58
Saviqo/ jdstrand12:58
mupPR 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
sergiusensjdstrand: not yet, that is my next work item after I get some core20 stuff out of the way12:59
jdstrandsergiusens: Saviq mentioned https://travis-ci.org/CanonicalLtd/multipass/jobs/601308279#L4750, which I was surprised to see12:59
sergiusensjdstrand: line 55 and 59 from https://travis-ci.org/CanonicalLtd/multipass/jobs/601308279/config13:00
jdstrandsergiusens: 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:00
mupPR 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
jdstrandsergiusens: ah, ok. note ^ before enabling everywhere :)13:01
sergiusensjdstrand: this was the contentious topic we did not reach an agreement on, we have no way to know what was whitelisted store side13:01
zygajdstrand: hello! :)13:02
jdstrandsergiusens: right. so, you can give snap-review '--json' then read that and decide what to and what not to block on13:02
jdstrandsergiusens: eg, you could choose to entirely skip declaration-snap-v213:03
jdstrands/skip/ignore/13:03
jdstrandzyga: hi :)13:03
zygajdstrand: I will have some things for you after the standup13:03
sergiusensjdstrand: should we also --allow-classic if the snap is classic? Do the review-tools issue some output when that flag is used?13:07
Saviqjdstrand: we're running it ourselves explicitly13:08
Saviqbut it's likely we're using it wrong :)13:09
jdstrandSaviq: yeah, see that and now, you are fine, though you may want to set SNAP_ENFORCE_RESQUASHFS=0 for faster reviews13:12
jdstrandsergiusens: you will probably want that ^ too, or at the very least a way to opt in/out of it13:12
Saviqjdstrand: 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
jdstrandzyga: fyi, I will be looking at https://github.com/snapcore/snapd/pulls/review-requested/jdstrand this week13:13
jdstrandSaviq: I issued the snap decl already. I said 'fix', I meant, 'I fixed it'13:13
SaviqAh! :)13:14
SaviqChrisTownsend: ^^13:14
jdstrandSaviq: actually, I only fixed part of it13:14
zygajdstrand: thank you :)13:14
jdstrandSaviq, ChrisTownsend: when it is uploaded to the store, it will now pass13:14
jdstrandSaviq, ChrisTownsend: but not on your invocation of snap-review. gimme a sec for an updated invocation13:15
* ChrisTownsend reads backlog13:15
zygajdstrand: 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 elements13:16
dot-tobiaszyga / 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
mupBug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable <papercut> <snapd:Confirmed> <https://launchpad.net/bugs/1849291>13:16
zygajdstrand: I included a memory usage test as well13:17
zygadot-tobias: I didn't manage to do it yesterday but I can propose a fix today13:17
zygadot-tobias: please ask mvo about release schedule for core / snapd13:17
dot-tobiaszyga: That would be marvelous, thank you! Will do13:18
mvodot-tobias: is there a PR for this issue yet?13:18
mvodot-tobias: (in a meeting so I may a bit slow replying)13:18
zygamvo: no, not yet, it's a small change to allow dbus introspection method on network manager that was missing before13:19
jdstrandChrisTownsend (cc Saviq): https://paste.ubuntu.com/p/RChQs4dkTQ/13:24
Saviqjdstrand: ack, thanks!13:25
ChrisTownsendjdstrand: cool, thanks!13:26
Saviqjdstrand: in theory we could also download the snap declaration from the store, right? So that we can flag any changes necessary early?13:27
zygaijohnson: https://github.com/snapcore/snapd/pull/7547#issuecomment-54528095313:28
ijohnsonzyga: after reading your response that all makes sense13:28
mupPR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>13:28
zygacool, excellent :)13:28
pedronispstolowski: 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 it13:28
ijohnsonzyga: re-approved13:30
zygaijohnson: woot, thanks!13:30
pstolowskipedronis: ah, good, this just answered another dillema that i'd have, good13:31
pedronispstolowski: go doc Seed in seed should be helpful (it says this e.g.) hopefully13:32
pedronismvo: 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 point13:33
zygamborzecki: can you look at https://github.com/snapcore/snapd/pull/764613:36
mupPR #7646: tests: update mount-ns after addition of /etc/systemd/user <Created by zyga> <https://github.com/snapcore/snapd/pull/7646>13:36
cachiodegville, hey13:36
cachiodegville, I am free, just ping me when you have time13:36
degvillecachio: hello!13:36
cachioah, you already sent the app13:36
cachioperfect13:37
mupPR 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
degvillecachio: ok, cool! I was just going to say maybe 5 mins because I'm eating a bowl of sauerkraut :)13:37
sergiusenspedronis, 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/1367413:37
cachiodegville, hehe13:38
zygajdstrand: 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 fixed13:38
mupBug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable <papercut> <snapd:Confirmed> <https://launchpad.net/bugs/1849291>13:38
zygajdstrand: the fix is simple and I can handle that today13:38
ijohnsonzyga: also approved #763913:39
mupPR #7639: interfaces: emit update-ns snippets to function <Created by zyga> <https://github.com/snapcore/snapd/pull/7639>13:39
zygaijohnson: excellent, thank you13:40
zygaI will review comments and open follow-ups13:40
pstolowskipedronis: 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 renaming13:40
pedronispstolowski: ok, I would have done them separately, not mixed13:40
mupPR 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
pedronisjust gauging how annoying people find the current status13:40
pedronisI might just change things in policy because it might make the new code clearer13:41
pedronisand leave asserts alone for now13:41
mborzeckizyga: heh so we actually had user.conf.d for overriding the user session manager but didn't have /etc/systemd/user/ ?13:41
jdstrandSaviq: re download> you could, but it is in a modified yaml format so you would have to parse/translate it to json13:44
zygamborzecki: yes13:44
zyga;D13:44
zygajdstrand: https://github.com/snapcore/snapd/pull/7632 is ready from my POV13:44
mupPR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>13:44
mborzeckiwell, at least it's accounted for now13:44
oSoMoNjdstrand, 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
mupBug #1848919: [snap] Permission denied on Private encrypted folder <chromium-browser (Ubuntu):Confirmed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1848919>13:53
zygaijohnson: https://github.com/snapcore/snapd/pull/7632 needs a re-review from you, I believe the concern you had was addressed13:53
mupPR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>13:53
ijohnsonyes I'm re-reviewing it as we speak :-)13:53
zygasuper, thank you! :)13:53
mupPR snapd#7648 opened: interfaces/policy: expand cstrs/cstrs1 to altConstraints/constraints <Simple ๐Ÿ˜ƒ> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7648>13:59
pedronispstolowski: ^14:00
pstolowskipedronis: that's not too bad, i thought there were more. thanks14:02
pedronispstolowski: not in policy14:02
pedronisthere's a ton in asserts/ifacedecls*.go14:02
pedronisthat's a bit more work, will leave it alone for now14:02
pstolowskipedronis: +114:04
=== ricab|lunch is now known as ricab
jdstrandzyga: commented14:12
jdstrandoSoMoN: I responded in the bug14:15
Saviqjdstrand: while we have a direct line with you ;), would you please allow auto-connection for kvm, network-control and firewall-control?14:19
oSoMoNjdstrand, thanks, I'll reproduce in a VM and will post the denial14:19
Saviqjdstrand: if you'd rather us go through the forum, just say so14:20
jdstrandSaviq: normally, yes, but this has been discussed previously, so I'll just make sure the reviewers are aware I did it14:21
jdstrandSaviq: cone14:22
jdstranddone*14:22
Saviqjdstrand: thanks!14:22
zygajdstrand: thanj you14:26
mupPR 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
zygaSaviq: 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 snap14:26
Saviqit's really more about snapcraft's use of Multipass there, so maybe a tag is more appropriate14:27
oSoMoNjdstrand, I commented on the bug with the denial I'm seeing14:30
* zyga goes for lunch14:31
zygaSaviq: ah, I see14:31
=== ricab is now known as ricab|bbl
mvopedronis: I think 7626 is ready for another review, I think I addressed the points you raised14:33
joedborgmorning 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 great14:35
mvopedronis: 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:39
pedronismvo: ?14:40
pedronisit's our change, no?14:40
pedronisdefault-provider is not a slot or  a plug14:40
pedroniswhat are they trying to do?14:40
mvodot-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 in14:40
mvopedronis: I don't know, its apparently snapcraft adding this14:40
pedronismvo: the gnome extension thingy?14:41
mvopedronis: in the kde and gnome plugsin14:41
mvopedronis: yeah14:41
pedroniswell, is not a snapd bug14:41
mvopedronis: I need to look at the code, I think we allowed ":" there for histric reasons14:41
pedronis?14:42
mvopedronis: 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.gz14:42
mvopedronis: https://launchpadlibrarian.net/447954589/buildlog_ubuntu_focal_amd64_ubuntu_BUILDING.txt.gz14:43
mvopedronis: and I had a quick look and noticed the default provider changed in the snap14:43
mvopedronis: now I need to remember things about this :/14:43
pedronismvo: ok, yes14:45
pedroniswe have two form of code14:45
pedroniswe have a bit too many pieces of code extracting default providers14:46
pedronismvo: we have this:  https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapstate.go#L49014:47
mupPR snapd#7649 opened: overlord: fix TestRemodelSwitchToDifferentKernel for bootvars <Created by mvo5> <https://github.com/snapcore/snapd/pull/7649>14:48
pedronisand this: https://github.com/snapcore/snapd/blob/master/snap/validate.go#L95714:48
pedronisthey don't do the same thing14:49
pedronismvo: we have a 3rd as well14:50
mvopedronis: hrm, hrm, sounds like a good target for unification - oh well14:50
mvopedronis: I try to have a look today14:50
kenvandinemvo: does this mean the kde snaps aren't working the way they think they are?14:51
kenvandineif the slot is being stripped...14:51
pedronismvo: https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/handlers.go#L69814:51
pedronisit's not a slot14:52
pedronis/ The default-provider is a name. However old14:53
pedronis// documentation said it is "snapname:ifname",14:53
pedronis// we deal with this gracefully by just14:53
pedronis// stripping of the part after the ":"14:53
pedronisof course only one place in our code does that, so there might be wobblyness anyway14:54
kenvandineyeah, but the kde snaps are trying to connect a plug with a different name than the slot14:54
kenvandinein the default-provider14:54
pedronisthat's not a thing14:54
kenvandinewhat they are doing might not really work...14:54
pedronisusually what happens is that the default-provider kicks in14:55
pedronisand then auto-connection does its job14:55
pedronisthat's kind of the only way it works14:55
pedroniss/kicks in/gets installed/14:55
pedronismvo: our docs still says this:  default-provider (plug): name and slot of preferred providing snap (<SNAP>:<SLOT>)14:56
pedronisbut we never implemented that14:56
pedronisfunny14:56
kenvandinei'm saying the kde snaps are including the slot in the default-provider, and that slot name isn't the same as the plug name14:56
pedroniskenvandine: apparently it's documented14:56
pedronisbut even I was not aware of that14:56
kenvandineplug=kde-frameworks-5-plug has default-provider = kde-frameworks-5-core18:kde-frameworks-5-core18-slot14:56
pedronisand as far as I know, it never was implemented like that14:57
pedronisyou need mvo and zyga to tell you more14:57
kenvandineok14:58
pedroniskenvandine: see this post by Gustavo: https://forum.snapcraft.io/t/the-snapd-roadmap/1973/914:58
pedroniswhich doesn't match the doc14:58
kenvandinethe seed validation are failing for something that's documented :)14:58
pedronisand doesn't work as documented14:58
pedronisand wasn't implemented as documented14:58
kenvandineindeed14:58
pedronisit's kind of a pain to implement it as documented actually14:59
pedronisso I don't see it get it fixed quickly14:59
pedronisto work as originally documented14:59
pedroniswe can fix it quickly to ignore in more places14:59
pedroniskenvandine: I would like to understand if the feature is really needed14:59
pedronisit's not been there in that form15:00
pedronisever15:00
kenvandinepedronis: i not really concerned to much about the feature15:00
om26eris 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 on15:00
kenvandinethe issue is the extension includes the slot in the default-provider and it is now breaking iso builds15:00
pedroniskenvandine: I understand15:00
* zyga breaks for an hour15:01
zygaor two15:01
pedroniskenvandine: we can fix snapd to ignore it, but I think the extension should stop to add the slot15:01
pedronisat some point soon15:01
zyganeed to go while there's some sunlight still15:01
pedronisand we need to do something about the doc15:01
pedronisom26er: not unless an interface is involved, all snaps to snaps relations should be via interfaces15:03
zygaom26er: this can be done via interface hooks, as a part of the post-connection "those are the attributes" phase for example15:03
zygaom26er: but as pedronis said it must be modeled as an interface15:04
* zyga really AFK15:04
ijohnsonhmm I can't seem to restart travis jobs anymore15:30
ijohnsoncan someone restart https://travis-ci.org/snapcore/snapd/jobs/601379249 for me? it failed due to store problems15:30
* cachio lunch15:34
pedronisijohnson: done15:34
ijohnsonthanks pedronis15:35
mupPR 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>15:35
=== ricab|bbl is now known as ricab
mvoteam: 7595 needs a second review, would unblock some uc20 work (maybe ijohnson?)16:01
ijohnsonmvo: ok I can take a look in my afternoon16:01
mvoijohnson: great, thank you!16:02
ogramvo, 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 over16:08
ograhttps://bugs.launchpad.net/ubuntu/+source/snapd/+bug/184951516:08
mupBug #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:08
sil2100mvo: hey! Could you sign-off formally on the UC20 u-i image spec if you have a moment? ;)16:36
=== pstolowski is now known as pstolowski|afk
jdstrandoSoMoN: one more question in the bug16:43
Saviqharr harr harr https://imgur.com/a/bRb6M1T16:47
oSoMoNjdstrand, replied16:53
mupPR 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:13
kenvandinejdstrand: 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 new17:20
mupPR 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:20
kenvandinejdstrand: oh... maybe it's because the case changed :)17:21
mupPR snapcraft#2765 opened: remote-build: initial Windows support <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2765>17:27
mupPR snapcraft#2759 closed: remote-build: https token support <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2759>17:30
mupPR snapcraft#2762 closed: appstream: extract title and version <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2762>17:30
mvoogra: thank you! we have a look, we just discussed this in our standup and we will add a 19.10 zfs machine to spread17:33
jdstrandkenvandine: it is the case change. I adjusted and it is passing now17:36
kenvandinethanks, i forgot when i bumped the version a few weeks ago i had to change the case17:36
mupPR 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
mupPR snapcraft#2758 closed:  appstream: support legacy ids without desktop suffix  <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2758>17:45
mupPR 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:54
mupPR 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
mupPR 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>17:57
mupPR 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:00
zygare18:16
zygaI'm doing homework with kids but I'll do an evening pass and fix one more bug18:16
zygajdstrand: is there anything I should look at from your point of view?18:16
jdstrandzyga: atm I am focusing on store reviews. it may be tomorrow when I look at it, so enjoy your eod :)18:53
* cachio afk19:08
zygajdstrand: understood, enjoy your evening as well :)19:24
zygajdstrand: :-)19:24
=== arnatious_ is now known as arnatious
xnoxsergiusens:  why was https://github.com/snapcore/snapcraft/pull/2757 closed, but not merged? did i do something wrong?22:24
mupPR 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:24
sergiusensxnox: 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 fine22:25
xnoxsergiusens:  make package is called make in rpm distros too22:27
xnoxsergiusens:  so which PR should I look at?22:28
xnoxsergiusens:  or which commits on master?22:28
sergiusensxnox: does "apt install make" work on RPM distros?22:28
xnoxsergiusens:  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:29
xnoxsergiusens:  i see core20 in https://github.com/snapcore/snapcraft/pull/2761/files#diff-c6b5575f0de40006219f3af3804ec78eR92 now, so yeah, that's fine22:30
mupPR snapcraft#2761: Core20 base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2761>22:30
xnoxit's just it's not merged. Can you build that PR and publish it to a channel like edge/pr2761 ?22:30
* xnox ponders if all PRs should be autobuilt and autopublished to edge/pr*22:31
sergiusensxnox: 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 access22:34
xnoxture22:35
xnoxtrue22:35
mupPR snapcraft#2766 opened: project: truncate project directory hash <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2766>23:12

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!