mupPR snapcraft#2753 closed: cli: use click utilities for registering on push <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2753>00:13
zygaTaking Bit for a walk05:58
mborzeckizyga: hey05:58
zygaback in the office06:33
zygaman it's so wet today06:33
zygait's not so cold but there's so much humidity everything is sticky wet06:33
zygamborzecki: I'll work on the fix for apparmor now but later on I'd like to push some code through your review eyes ;)06:34
mborzeckizyga: i'm on a bug triage duty today, but want to finish some gadget stuff first06:34
zygamborzecki: cool, enjoy it :)06:37
zygamborzecki: perhaps you could triage fedora/rhel bugs06:38
mborzeckizyga: hm let me check whether i have the right permissions, last time i tried i couldn't switch them to resolved and assign to myself06:38
mborzeckizyga: should probably nag you and Eighth_Doctor to maybe add me to the snapd package06:39
zygayou have the required accounts and there's probably lots of stuff that is fixed06:39
zygayeah, that's a good idea06:39
zygaadd me as well if that's not already the case please06:39
mupPR snapd#7612 closed: gadget: add a public helper for parsing gadget metadata <Remodel :train:> <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7612>07:01
=== pstolowski|afk is now known as pstolowski
mborzeckipstolowski: hey07:10
mvohey pstolowski and mborzecki07:10
mborzeckimvo: hey07:10
mvolooks like we have lots of red, has anyone looked?07:16
mvoand happy release day07:17
mborzeckimvo: release day meaning we're going to see PRs failing on the store api? :)07:34
mvomborzecki: most likely :/07:34
mborzeckimvo:  only 2 of recent PRs were red, pushed a little spelling fix to one with apparmor and pivot_root, the k8s one failed on store api returning 40307:35
mupPR snapd#7599 closed: gadget: refactor ensureVolumeConsistency <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7599>07:36
mupPR snapd#7618 opened: snap-install: add ext4,vfat creation support <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7618>07:56
mupPR snapd#7618 closed: snap-install: add ext4,vfat creation support <Simple 😃> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7618>07:58
mupPR snapd#7619 opened: image,seed: hide Seed16/Snap16, use seed.Open in image_test.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/7619>07:58
mborzeckimvo: 7618 was quick, should i review it still?07:58
mvomborzecki: no07:58
mvomborzecki: I just noticed it duplicates code from the gadget07:59
mvomborzecki: better code07:59
mvomborzecki: so I will update and repush, sorry, I'm extracting mergable bits from the draft PR of claudio and didn't notice the duplication07:59
* zyga has some back pain today08:07
zygaI'll focus on reviews08:07
pedronispushed some seed/image cleanups,  so now #7619 should be reviewed before #759508:13
mupPR #7619: image,seed: hide Seed16/Snap16, use seed.Open in image_test.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/7619>08:13
mupPR #7595: seed/seedwriter: support writing Core 20 seeds (aka recovery systems) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7595>08:13
mvomborzecki: and its back again, had to tweak it a little to support contentless mkfs from gadget but still very easy I hope08:18
mupPR snapd#7620 opened: snap-install: add ext4,vfat creation support <Created by mvo5> <https://github.com/snapcore/snapd/pull/7620>08:18
mvomborzecki: layering of the mocking is a bit debatable, happy to fix it08:19
Chipacamborzecki: #1840751 is fix-released, if you have the bandwidth08:19
mupBug #1840751: Please include store-url when it exists <Snap Store:Fix Released> <https://launchpad.net/bugs/1840751>08:19
Chipacaotherwise I'll leave it in my to-do08:19
pedronisChipaca: hi, could you quickly backfill your standup notes for yesterday (maybe mvo should tell this, but I fear it might go all a bit downhill if we starts having gaps that are not because of time off)08:21
Chipacadrat, i forgot, yes08:22
Chipacapedronis: thankyou for reminding me08:22
mborzeckiChipaca: added a note in the topic and tagged it as upcoming for both of us :P08:23
Chipacamborzecki: all I heard was "it's a race"08:24
mborzeckidegville: i've gone through instructions in https://forum.snapcraft.io/t/building-a-snap-rpm-for-red-hat-enterprise-linux-rhel-8/13728 and updated them a bit, can you take a look whether i haven't butchered the language in the process?08:25
degvillemborzecki: yes of course, thanks so much for looking through them and updating them!08:26
degvillemborzecki: looks good - it's great to have the definitive article :) Thanks!08:28
mborzeckidegville: it's using the release packages from github, at the cost of uglier download url :/ but i figured this would be better if the spec in master gains support for some new bianries that aren't in the latest release08:30
Chipacamborzecki: degville: shouldn't the link point to the same place the example downloads?08:57
Chipacaor is it a different file08:57
mborzeckiChipaca: which example downloads?08:58
mborzeckithe relase tarbal?08:58
Chipacamborzecki: the spec file, but now i don't know what puts it there09:01
Chipacaso i'm confused and probably wrong09:01
Chipacamborzecki: wha creates ~/rpmbuild/SOURCES/snapd.spec ?09:02
Chipacain those instructions i mean09:02
mborzeckiChipaca: the tar incantation09:02
mborzeckiChipaca: tar -xvJ -C ~/rpmbuild/SPECS --strip-components=3 -f snapd_2.42.no-vendor.tar.xz snapd-2.42/packaging/fedora/09:02
Chipacamborzecki: i might have missed the strip-components option there :)09:03
Chipacamborzecki: ok, so, question stands! shouldn't the link in "contains the recipe" point to the release recipe, not master?09:04
mborzeckiah right09:04
degvilleChipaca / mborzecki: right, that's my fault. I put that original link in, you're right Chipaca.09:04
Chipacahttps://github.com/snapcore/snapd/blob/release/2.42/packaging/fedora/snapd.spec is the 2.42 release blob09:05
mborzeckiChipaca: degville: updated09:06
degvillemborzecki: thank you!09:06
Chipacamborzecki: is /blob/2.42/ the same as /blob/release/2.42?09:06
Chipacaanyway, i'll stop pestering now09:07
=== alan_g is now known as alan_g_
zygapedronis: is this syntax new in go? https://github.com/snapcore/snapd/pull/7619/files#diff-4a51d32715a8521893a1f9ecf9236fb9R2609:22
mupPR #7619: image,seed: hide Seed16/Snap16, use seed.Open in image_test.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/7619>09:22
zygalooks like type aliases09:22
zygaare those supported across all our go versions now?09:22
* zyga afk for a second09:27
zyganeed to find some painkillers for the back09:27
zygagosh, I love autumn and all the windy weather it brings09:27
pedroniszyga: yes, they are type aliases, we have already some (for tests) in the code base09:31
pedroniszyga: they were added in 1.909:31
pedronisI think09:31
Chipacayep, 1.909:36
mupPR snapd#7573 closed: [RFC] client: add support for the new "/v2/assertions/%s?remote=true" <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7573>09:36
mborzeckiijohnson: silly me, pushed a fix for https://github.com/snapcore/snapd/pull/7443/files#r335908588 should have simplified this earlier since i was using the funky mon1-mon schedule in testing while working on the code, that's how the other part of the || came to be09:50
mupPR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>09:50
ijohnsonmborzecki: great, I'll take a look in a bit thanks for explaining that09:51
mborzeckiok, onto the bug triage09:52
mupPR snapd#7621 opened: Add EPL-2.0 to licenses <Created by ralight> <https://github.com/snapcore/snapd/pull/7621>10:02
mvomborzecki, zyga can someone on a fedora system check if "golang.org/x/xerrors" is available as a package?10:02
zygamvo: hold on10:02
zygamvo: a quick google ftp://rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/g/golang-x-xerrors-devel-0-0.1.20190916gita985d34.fc32.noarch.html10:03
zygamvo: so I suspect so10:03
mborzeckimvo:  i see it was released to 31 only10:03
mvomborzecki: is it possible/easy to also releae for f30?10:04
zygamvo: if needed it can be brouht to older releases10:04
mborzeckimvo: could probably ask the guy who maintains it to push a build for 30, although it's unsing a new packaging, so will require some tweaks10:04
zygamvo: especially new devel packaes10:04
mvowill centos be a problem?10:04
mborzeckimvo: centos uses vendored pacakges10:04
mvowell, it would make the PR I have here a lot nicer so would be nice to have it10:05
mvoand debian-sid has the package so its really just fedora10:05
mborzeckimvo: ah, it's the 1.13 error handling for older go releases10:05
mvomborzecki: yeah10:05
pstolowskihmmmmm is there anything special about mount unit for core? on my WIP pre-baked image the unit is there in the fs (along one other snap), yet on boot it's not mounted and there is no trace of it in journal (the mount unit of other snap does appear there and gets mounted)10:05
mvomborzecki: I think we will benefit in other areas too10:05
zygapstolowski: which mount unit?10:05
mvopstolowski: maybe not enabled in /{etc,lib}/systemd/system/mount.wants or something?10:06
pstolowskizyga: mount unit for core snap10:06
mborzeckibtw. do you have an ubuntu system with nvidia?10:06
zygamborzecki: me?10:06
mborzeckizyga: yes :P10:07
zygamborzecki: not with ubuntu, last time I tried it wasn't working with this GPU10:07
zygamborzecki: I think 19.10 will now work10:07
zygamborzecki: but I don't have one installed10:07
pstolowskimvo: hmm interesting, will check, although mount unit is fine for lxd snap10:07
mborzeckizyga: ok, https://bugs.launchpad.net/snapd/+bug/1824168 needs checking on nvidia, perhaps they updated the snap since that time10:09
mupBug #1824168: classic opengl application on 19.04 fail to find gl drivers <amd64> <apport-bug> <disco> <snapd:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1824168>10:09
mupPR snapd#7622 opened: snap: make `snap known --remote` use snapd if available <Created by mvo5> <https://github.com/snapcore/snapd/pull/7622>10:12
ograogra@pocketbeagle:~$ grep BUG /etc/os-release10:13
ogragiven you guys did so much bug cleanup the last days ...10:13
ograis that url in UbuntuCore still accurate ?10:14
ogra(thats core18)10:14
pstolowskimvo: aha! that is the case, thank you10:14
Saviqzyga: hey, is there somewhere we could read about / provide feedback on the hardware-support snaps (GL)?10:16
ograthere used to be a forum thread about this ...10:16
zygaSaviq: they are not on the roadmap anymore. What is present is on the forum10:17
zygaYou can respond to existing topics there10:17
zygaI made one for OpenGL and one for CUDA10:17
ograwell, the Mir team made one for opengl too ... before yours i think10:18
Saviqand I suppose what you mean is https://forum.snapcraft.io/t/gpu-support-proposal/11247 and https://forum.snapcraft.io/t/hello-world-cuda-analysis/1125010:20
ijohnsonmborzecki: I checked with my nvidia gpu + 19.04 and I can reproduce10:21
mborzeckihm someone reported a but about snapd 2.34.2ubuntu0.1 to 2.37.4ubuntu0.1 upgrade, but there's no 2.34 in the archive :?10:21
mborzeckiijohnson: thanks!10:21
zygaSaviq: yes10:24
Chipacamborzecki: https://launchpad.net/ubuntu/+source/snapd/2.34.2ubuntu0.110:24
Chipacamborzecki: perhaps look in security you did not10:24
* Chipaca yodas10:24
mborzeckiChipaca: heh, thanks!10:25
Chipacamborzecki: fwiw i got there via googling 'snapd <version>'10:25
mborzeckiChipaca: hmmm, still no deb there either, thought the old versions are just kept behind10:25
mborzeckiunless, it was pulled maybe?10:26
ograor the user has -proposed permanently enabled10:26
Chipacamborzecki: ? the link is right there10:26
Chipacamborzecki: on the right, "builds"10:26
Chipacamborzecki: amd6410:26
Chipacamborzecki: https://launchpad.net/~ubuntu-security/+archive/ubuntu/ppa/+build/16332834/+files/snapd_2.34.2ubuntu0.1_amd64.deb10:26
Chipaca(and all the other debs we build)10:27
mborzeckiChipaca: right, there's where i downlaoded it from, but i'm not sure why it's not in archive.u.c or security.u.c pacakge pools10:27
Chipacamborzecki: because it got superseded, i assume10:28
Chipacaarchive doesn't keep all old versions10:28
Chipacahuh, we don't restart snapd on removing the snapd snap10:46
ograwell, if you remove the snapd snap as a general user, you probably expect the deb to be gone too ?10:49
Chipacawell you'd be expecting wrong, then10:50
mborzeckiChipaca: --purge?10:53
Chipacamborzecki: ?10:54
mborzeckiChipaca: duh, misread, it's the snapd snap10:54
sergiusenshow do I deal with "error: cannot install snap file: snap "snapcraft" assumes unsupported features: snapd2.39 (try to update snapd and refresh the core snap)" but installing the snapd snap instead? I get "error: cannot install "snapd": cannot install snapd snap on a model without a base snap yet"10:54
sergiusensthis is 16.0410:55
sergiusensand hello everyone10:55
ogracreate a gadget for your install :P10:55
ogra(one thats base: core18 ... )10:56
sergiusensfor my lxd container running a classic system?10:56
ogra(i wasnt serious)10:56
zygasergiusens: install core10:57
Chipacasergiusens: 1 sec10:57
ogranote that our classic installs all default us use core, not core1810:57
sergiusensgood, I want to avoid installing core, snapcraft is on core18 and doesn't want to be installed10:57
sergiusenszyga: so to install snapcraft I need to install core and core18?10:57
* ogra glares at his fingers10:57
sergiusensI went down this path as I was told the snapd snap fixed that10:57
zygaUntil we ship snapd snap ootb10:57
Chipacahold on10:57
Chipaca1 sec10:58
zygaAFAIK it is not ready10:58
Chipacasergiusens: can't you update your snapd package?10:58
ograwouldnt that be snapd and core16 then, not core ?10:58
Chipacasergiusens: otherwise, try this10:58
sergiusensChipaca: I could add it to the work flow10:58
Chipacasergiusens:  snap set system experimental.snapd-snap=true10:58
zygaogra: it is not ready yet10:58
Chipacasergiusens: then snap install snapd10:59
ograzyga, yes, i got that ... but you'd not be using core in that scenario, right =10:59
Chipacazyga: snapd + core18 on classic works fine10:59
sergiusensChipaca: ok, useful for play, but not to get out of this pickle :-)10:59
Chipacasergiusens: what is your pickle?10:59
Chipacasergiusens: as an aside: why are you running things on a 16.04 that is not up to date? :)11:01
sergiusensChipaca: I build snapcraft with assumes command-chain, and 16.04 holding an older snapd11:01
sergiusensChipaca: it is the latest minimal image11:01
ograhow could it "hold an older snapd" ? it re-execs into core11:01
Chipacasergiusens: snapd 2.40 is in xenial-updates for quite a while now, but ok11:02
ogra(which should be auto-installed with your first snap)11:02
sergiusensChipaca: yeah, the apt update proved that11:02
Chipacasergiusens: and why does the 'snap set system' call not get you out of there?11:02
sergiusensChipaca: oh, I read "experimental" and sort of hid from it11:02
Chipacawell, it's no longer experimental in a new enough snapd :)11:03
zygaChipaca: there are still some issues in that setup11:03
sergiusensgreat then11:03
Chipacazyga: what issues?11:04
zygaChipaca: snapd tools directory injection into snap mount namespaces leads to stale tools over time11:08
zygaThere is a topic forum describing this11:08
zygaAlong with three proposals for solving it11:08
zygaChipaca: I can find the link if you want to know more11:12
Chipacazyga: you're mentioned in this thread, but dunno if you were aware (nor if you know what they're talking about): do you know what a 'readonly snapshot' means in this context? https://discourse.ubuntu.com/t/intent-to-provide-chromium-as-a-snap-only/5987/2?u=chipaca11:45
Chipacaand more importantly why would it trip up snapd11:45
Chipacazyga: ah, link to the forum, d'oh11:51
* pstolowski lunch11:58
ondrasergiusens ping12:07
ondrasergiusens you might have regression in snapcraft which is in beta12:11
ondrasergiusens run snapcraft init and then add in snapcraft.yaml plug definition from here https://forum.snapcraft.io/t/the-content-interface/107412:11
diddledanondra: I suspect you'll need to state which of those plug definitions you're using - there's several on that page12:14
ogradetails ...12:14
mupPR snapd#7617 closed: snap-confine.apparmor.in: harden pivot_root until we have full mediation <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/7617>12:14
diddledanogra: details are the bane of our existence. down with details!12:14
ondradiddledan the very basic one https://paste.ubuntu.com/p/PpBrFGnMcf/12:15
ondradiddledan I get "Sorry, an error occurred in Snapcraft: argument of type 'NoneType' is not iterable"12:15
diddledanooh, interesting12:15
ondradiddledan seems like missing tests12:15
ondradiddledan this should be caught during testing12:16
diddledanyes, it should :-)12:16
ondradiddledan essentially it breaks now every snap using content interface plug12:16
ondradiddledan true I'm on beta :)12:16
zygamborzecki: small test https://github.com/snapcore/snapd/pull/762312:19
zygajdstrand: ^12:19
mupPR #7623: tests: check world-writable and test-owned files <Created by zyga> <https://github.com/snapcore/snapd/pull/7623>12:19
mupPR snapd#7623 opened: tests: check world-writable and test-owned files <Created by zyga> <https://github.com/snapcore/snapd/pull/7623>12:19
zygaAFAIK we discussed this a while ago12:19
jdstrandI'll take a look12:20
zygathank you12:22
sergiusensondra: thanks, we will look into it, adding the Sharing a C-level library ? I guess we are naively expecting a default to be defined.12:27
ondrasergiusens I used that example straight from our docs12:28
ondrasergiusens in snap it broke I was just sharing socket12:28
ograbecause our docs are always correct indeed :)12:28
ondrasergiusens but I wanted to demonstrate it on official example12:29
ondraogra :P12:29
sergiusensChipaca: I know why there are no updates, policy today is that build images are based on -release with no -updates12:29
sergiusensondra: that's fine, no worries, we made changes there so there most likley is a regression12:30
sergiusensChipaca: so is the outcome to use the snapd snap or just install core?12:30
ondrasergiusens cool, thanks12:39
=== ricab is now known as ricab|lunch
jdstrandzyga: ok, fixed your hook comment (good catch!). See https://github.com/snapcore/snapd/pull/7616#pullrequestreview-303088818 for discussion12:51
mupPR #7616: interfaces/many: allow k8s/systemd-run to mount volume subPaths plus cleanups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7616>12:51
zygajdstrand: thank you, I'll look soon12:57
jdstrandzyga: thanks, not urgent (just needs to be in 2.43 :)12:58
jdstrandso, yesterday I dropped pulseaudio from chocolate-doom-jdstrand and used audio-playback instead (fine)13:00
jdstrandI pushed that to git, which built the snap, which pushed it to edge which updated on my laptop13:01
jdstrand$ snap connections chocolate-doom-jdstrand|grep pulseaudio13:01
jdstrandpulseaudio              chocolate-doom-jdstrand:pulseaudio              :pulseaudio              -13:01
jdstrand$ grep pulseaudio /snap/chocolate-doom-jdstrand/current/meta/snap.yaml13:01
sergiusensondra: https://github.com/snapcore/snapcraft/pull/275413:02
jdstrandso... pulseaudio is connected after the refresh even though the current revision does not plugs it13:02
mupPR snapcraft#2754: meta: support the case of a plug without a default provider <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2754>13:02
jdstrandzyga: this seems like a bug ^13:02
mupPR snapcraft#2754 opened: meta: support the case of a plug without a default provider <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2754>13:03
zygajdstrand: aha13:03
zygain standup now13:03
zygajdstrand: can you clarify, even though the revision does not plug it?13:04
zygajdstrand: are you referring to "snap connections" claiming there is a connection even though a plug or slot has been removed?13:07
jdstrandzyga: the 'current' revision (ie, 81) does not 'plugs: pulseaudio'. the previous revision did. when snapd refreshed the snap from the previous to the current, pulseaudio remains connected13:07
zygaI see13:07
jdstrandzyga: unsurprisingly, that is also true of 'snap interfaces'13:07
jdstrandzyga: the profile on disk correctly only has audio-playback in the snippets13:10
jdstrandzyga: I'm going to file a bug. someone can mark it Invalid if it is operating as designed13:11
kjackal_v2jdstrand: any hints on this:13:12
kjackal_v2apparmor="DENIED" operation="open" profile="snap.microk8s.daemon-cluster-agent" name="/proc/18749/mounts" pid=18749 comm="python3" requested_mask="r" denied_mask="r" fsuid=0 ouid=013:12
kjackal_v2it comes from a command executing a python script13:12
kjackal_v2am I missing an interface?13:12
jdstrandor maybe not... what's going on LP?13:13
zygajdstrand: thank you for the bug13:13
zygajdstrand: lp is a bit wonky recently13:13
ograrelease day ...13:13
zygajdstrand: are you seeing timeout errors?13:13
ograit is busy at some release party i guess13:13
ogra(getting drunk and such)13:14
zygakjackal_v2: you can use mount-observe to avoid it13:14
kjackal_v2cool, trying that now, thanks zyga13:14
jdstrandkjackal_v2: plugs mount-observe13:15
jdstrandzyga: I see nothing. all white13:15
zygajdstrand: oh that's even more buggy :)13:15
jdstrandthere we go13:15
kjackal_v2there must be a tool suggesting the interfaces based on denials. thank you13:16
* jdstrand writes his bug report in an editor to then paste in13:16
jdstrandkjackal_v2: snappy-debug13:16
zygakjackal_v2: there's snappy-debug13:16
ograkjackal_v2, it is called snappy-debug13:16
ograbah, snap13:16
zygabut I think we could instead have a tree-like output of files and patterns and associated interfaces that grant access13:16
kjackal_v2woohoo, thank you13:16
jdstrandkjackal_v2: I don't know if you saw, but it is called snappy-debug ;)13:16
kjackal_v2snappy-what ???13:17
zygajdstrand: I think snapd could even make that output13:18
zygajdstrand: even based on dynamically created interfaces13:18
zygajdstrand: that would be pretty neat actualy13:18
jdstrandzyga: the problem is globs and weird things like dbus rules and things with peers, etc13:20
jdstrandzyga: for best results (that snappy-debug is not currently doing) we need to use logprof to aid in suggestions13:21
zygaYeah but those are all doable13:21
jdstrandand logprof is py313:21
jdstrandsnappy-debug receives nearly no love and I would still consider it poc code13:22
jdstrandI mean, it works, but isn't perfect13:22
mupPR snapd#7518 closed: cmd/snap: sort tasks in snap debug timings output <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7518>13:34
jdstrandzyga: what would be quite cool is for snappy-debug to be able to query snapd on the fly (perhaps using your output) to obtain the policy to base suggestions on13:36
jdstrandright now I have to dump the policy snippets to disk in a rather convoluted manner and ship those snippets in snappy-debug13:37
jdstrandwhich, again, 'works', but it gets out of date and there are some problems wrt implicitCore and implicitClassic13:38
jdstrandanyway, we could discuss this over lunch sometime. it isn't like any of this is resourced :)13:38
roadmrjdstrand: hey there - hope it's not too short-notice, I scheduled the kickoff for the review-tools stateful thing in 50 min13:40
jdstrandroadmr: that's fine. do note that I'm booked til the roadmaap sprint and won't personally be able to do much wrt this until likely after. possibly just before13:42
pedronispstolowski: which should probably discuss this issue with enable because I still think there is either a small bug in snapd or in some snaps, probably next week at this point though13:42
jdstrandroadmr: my understanding was this was a 'next cycle' thing (in fact, the base snap stuff I've communicated in the forum as early next cycle)13:43
pedronispstolowski: I made a note13:43
jdstrandroadmr: that doesn't mean I can't attend the meeting, just trying to set expectations13:43
roadmrjdstrand: right, we can clarify that in a bit. Our plan is to feature-flag this so it's ready to go once the tools support it, so there's no pressure on you ideally13:44
jdstrandroadmr: ack13:45
pstolowskipedronis: ok13:48
jdstrandpstolowski: fyi, in 2.42 snap install is fast since we only do the apparmor_parser at the end, but snap remove runs the parser on each disconnect13:52
jdstrandpstolowski: I don't recall if that was intentional (ie, it is still a known todo)13:52
jdstrandpstolowski: but if it was unknown, now it is known13:53
jdstrandpstolowski: hey btw :)13:53
pstolowskijdstrand: hi! yes and no, we know we have a few variants of ops that need their own treatment... btw i've next PR up - https://github.com/snapcore/snapd/pull/7601 ; but yes i haven't considered remove yet13:56
mupPR #7601: overlord/ifacestate: use SetupMany in setupSecurityByBackend <Created by stolowski> <https://github.com/snapcore/snapd/pull/7601>13:56
pstolowskijdstrand: so, thanks for pointing out13:56
jdstrandack on that PR (had it in my todo)13:58
jdstrandzyga: https://bugs.launchpad.net/snapd/+bug/184851614:06
mupBug #1848516: snap connections/interfaces shows dropped interfaces as connected after refresh <snapd:New> <https://launchpad.net/bugs/1848516>14:06
jdstrandzyga: the end of that report is bizarre14:07
=== ricab|lunch is now known as ricab
Chipacafound the issue with brave14:20
Chipacaanybody know the brave devs? popey?14:20
ograthey used to be active on the forum when packaging it first14:20
ogra@posix4e on the forum it seems14:21
Chipacaogra: thanks14:22
Chipacahm, last seen jan 2714:23
ograyeah ... at least this year though :)14:24
zygajdstrand: returning from lunch and looking14:24
SaviqCan't find this documented anywhere, does the store expire old revisions of software? What are the rules for that?14:29
ograafaik the store never deletes anything ... and revisions are only wiped when new stuff comes in14:30
ogra(unless you manually unrelease/close channels etc)14:30
ChipacaSaviq: if you're the publisher you can still install the old revisions14:31
Chipacae.g. i can snap install --revision=1 http14:31
ograshow off ...14:31
Chipacawait, i lied, i can onlu install 14 and on14:32
ChipacaSaviq: so maybe there's more to it than that and we should ask the store :-D14:33
ograprobably only revisions that have been published once ?14:35
Saviqwell, multipass's revisions start with no. 700+ (at least as far as `snapcraft revisions` is concerned)14:37
Saviqwhy I'm asking is I'm considering edge/pr-123 branches for pull requests, but would not like those to live ad infinitum14:37
Saviqso if there are *some* rules for expiration, I'd be much happier :)14:38
* cachio lunch15:23
popeyChipaca: they haven't been active for ages15:29
popeyWe may have to re-home it15:29
=== pedronis_ is now known as pedronis
zygajdstrand: question about https://github.com/snapcore/snapd/pull/7623 -- it shows we actually do use wrong permissions16:08
mupPR #7623: tests: check world-writable and test-owned files <Created by zyga> <https://github.com/snapcore/snapd/pull/7623>16:08
zygajdstrand: I made some changes to snap-confine where this test passes, do you think I should open that as a PR?16:09
jdstrandzyga: I have to step away but will circle back16:09
zygaI'll commit and push it and give you a link16:09
mupPR snapd#7624 opened: snap: make `snap download` download via snapd if availalbe <Created by mvo5> <https://github.com/snapcore/snapd/pull/7624>16:10
=== pstolowski is now known as pstolowski|afk
mupPR snapd#7619 closed: image,seed: hide Seed16/Snap16, use seed.Open in image_test.go <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7619>16:12
mvopedronis: yay16:17
mvopedronis: ping me once this is merged into your other PR16:17
pedronismvo: it is now16:17
pedronis#7595 is ready for review16:18
mupPR #7595: seed/seedwriter: support writing Core 20 seeds (aka recovery systems) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7595>16:18
mupPR snapd#7625 opened: cmd/snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7625>16:18
mupPR snapd#7233 closed: interfaces/firewall-control: add nf_nat_* to kmod plug <Created by alfonsosanchezbeato> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7233>16:22
mupPR snapd#7626 opened: [RFC] managers: add remodel undo test for new required snaps case <Created by mvo5> <https://github.com/snapcore/snapd/pull/7626>18:22
joedborghey ijohnson, do you happen to have the snapcraft.yaml for the docker snap you wrote?18:33
ijohnsonjoedborg: it's being maintained by tianon now on LP18:33
joedborgijohnson: thanks!18:34
ijohnsonjoedborg: but anyways it's here : https://git.launchpad.net/~docker/+git/snap/tree/18:34
joedborgijohnson: ah, nice, thanks.  just needed to "borrow" some bits :)18:40
mupPR snapcraft#2741 closed: extensions: support using gjs from gnome runtime <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2741>18:42
=== zigford_ is now known as zigford
jdstrandzyga: can you take a look at this and bring it up in your standup: https://bugs.launchpad.net/snapd/+bug/184856719:11
mupBug #1848567: autogenerated per-snap snap-update-ns apparmor profile may contain many duplicate rules causing excessive parser memory usage <aa-parser> <AppArmor:New> <snapd:New> <https://launchpad.net/bugs/1848567>19:11
jdstrandcc pedronis ^19:13
jdstrandzyga (cc pedronis): that could be an easy performance win19:13
jdstrandI say 'easy' because it is no risk for production, but I realize there could be a lot of testsuite changes19:14
mupPR snapd#7627 opened: overlord: add checks for bootvars in TestRemodelSwitchToDifferentKernel <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7627>19:35
ijohnsonjdstrand: I'll make sure it's discussed, that's could be a huge performance win it seems19:51
jdstrandijohnson: yes, huge! and not just UC. eg, Ubuntu with preinstalled snaps on first boot could swap (or even OOM) due to this19:56
ijohnsonyeah totally19:56
jdstrandijohnson: the biggest number of dupes seems to be mostly around the content interface19:57
jdstrandlayouts aren't too bad19:58
jdstrandat least anecdotally19:58
ijohnsonyes it's quite odd because I have 3 graphical snaps on my system and they all have 17k line long snap-update-ns profiles and all the rest of my profiles are only about 100-200 lines19:59
jdstrandijohnson: jjohansen mentioned to me that the issue is because mount rules don't have a quick and dirt second pass to pull out dupes19:59
ijohnsonbut also all the graphical snaps use the content interface too19:59
jdstrandijohnson: yes, exactly19:59
jdstrandijohnson: I see that chromium ,discord, gedit, gimp, gnome-calculator, gnome-characters, gnome-logs, gnome-system-monitor, indicator-sensors, libreoffice, remmina, ...20:01
jdstrandijohnson: you know, all the stuff no one uses :P20:01
ijohnsonhaha yeah :-O20:01
oSoMoNjdstrand, hey, until the voting period is over for https://forum.snapcraft.io/t/auto-connecting-the-personal-files-interface-for-the-chromium-snap-part-ii/13705, the chromium snap in the candidate channel is not installable. If I wanted to publish unrelated bug fixes in the chromium snap, should I simply revert the change to the personal-files plug temporarily, then add it back when auto-connection is granted?20:17
jdstrandoSoMoN: yes, that would be the best course. let me look at that request real quick20:18
jdstrandoSoMoN: let me look at the snapcraft.yaml. recall there is a review-tools change that is also needed20:19
jdstrandoSoMoN: I'd like to proactively add that ahead of the voting period expiration20:20
jdstrandoSoMoN: so your plan is to update the existing 'chromium-config' plug?20:22
oSoMoNjdstrand, yes, unless you advise otherwise20:22
oSoMoNthe change is here: https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/commit/?id=ffd7ad54bca62c325f906014cd3b96bd2bcd2ee720:22
jdstrandoSoMoN: in this case, I think that is fine. it also means I don't need to add anything to the review-tools20:22
oSoMoNeven better20:23
mupPR snapcraft#2755 opened: extensions: kde-neon: add icon and sound themes <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/2755>22:16

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