[00:13] PR snapcraft#2753 closed: cli: use click utilities for registering on push [05:38] morning [05:58] Hey [05:58] Taking Bit for a walk [05:58] zyga: hey [06:33] back in the office [06:33] man it's so wet today [06:33] it's not so cold but there's so much humidity everything is sticky wet [06:34] mborzecki: 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] hahah [06:34] zyga: i'm on a bug triage duty today, but want to finish some gadget stuff first [06:37] mborzecki: cool, enjoy it :) [06:38] mborzecki: perhaps you could triage fedora/rhel bugs [06:38] zyga: hm let me check whether i have the right permissions, last time i tried i couldn't switch them to resolved and assign to myself [06:39] zyga: should probably nag you and Eighth_Doctor to maybe add me to the snapd package [06:39] you have the required accounts and there's probably lots of stuff that is fixed [06:39] yeah, that's a good idea [06:39] add me as well if that's not already the case please [07:01] PR snapd#7612 closed: gadget: add a public helper for parsing gadget metadata === pstolowski|afk is now known as pstolowski [07:09] morning [07:10] pstolowski: hey [07:10] hey pstolowski and mborzecki [07:10] mvo: hey [07:16] looks like we have lots of red, has anyone looked? [07:17] and happy release day [07:34] mvo: release day meaning we're going to see PRs failing on the store api? :) [07:34] mborzecki: most likely :/ [07:35] mvo: 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 403 [07:36] PR snapd#7599 closed: gadget: refactor ensureVolumeConsistency [07:56] PR snapd#7618 opened: snap-install: add ext4,vfat creation support [07:58] PR snapd#7618 closed: snap-install: add ext4,vfat creation support [07:58] PR snapd#7619 opened: image,seed: hide Seed16/Snap16, use seed.Open in image_test.go [07:58] mvo: 7618 was quick, should i review it still? [07:58] mborzecki: no [07:59] mborzecki: I just noticed it duplicates code from the gadget [07:59] mborzecki: better code [07:59] mborzecki: so I will update and repush, sorry, I'm extracting mergable bits from the draft PR of claudio and didn't notice the duplication [08:07] * zyga has some back pain today [08:07] I'll focus on reviews [08:13] pushed some seed/image cleanups, so now #7619 should be reviewed before #7595 [08:13] PR #7619: image,seed: hide Seed16/Snap16, use seed.Open in image_test.go [08:13] PR #7595: seed/seedwriter: support writing Core 20 seeds (aka recovery systems) [08:18] mborzecki: and its back again, had to tweak it a little to support contentless mkfs from gadget but still very easy I hope [08:18] PR snapd#7620 opened: snap-install: add ext4,vfat creation support [08:19] mborzecki: layering of the mocking is a bit debatable, happy to fix it [08:19] mborzecki: #1840751 is fix-released, if you have the bandwidth [08:19] Bug #1840751: Please include store-url when it exists [08:19] otherwise I'll leave it in my to-do [08:21] Chipaca: 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:22] drat, i forgot, yes [08:22] pedronis: thankyou for reminding me [08:22] np [08:23] Chipaca: added a note in the topic and tagged it as upcoming for both of us :P [08:24] mborzecki: all I heard was "it's a race" [08:25] degville: 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:26] mborzecki: yes of course, thanks so much for looking through them and updating them! [08:28] mborzecki: looks good - it's great to have the definitive article :) Thanks! [08:30] degville: 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 release [08:57] mborzecki: degville: shouldn't the link point to the same place the example downloads? [08:57] or is it a different file [08:58] Chipaca: which example downloads? [08:58] the relase tarbal? [09:01] mborzecki: the spec file, but now i don't know what puts it there [09:01] so i'm confused and probably wrong [09:02] mborzecki: wha creates ~/rpmbuild/SOURCES/snapd.spec ? [09:02] in those instructions i mean [09:02] Chipaca: the tar incantation [09:02] Chipaca: tar -xvJ -C ~/rpmbuild/SPECS --strip-components=3 -f snapd_2.42.no-vendor.tar.xz snapd-2.42/packaging/fedora/ [09:03] ahhh [09:03] mborzecki: i might have missed the strip-components option there :) [09:04] mborzecki: ok, so, question stands! shouldn't the link in "contains the recipe" point to the release recipe, not master? [09:04] ah right [09:04] Chipaca / mborzecki: right, that's my fault. I put that original link in, you're right Chipaca. [09:05] https://github.com/snapcore/snapd/blob/release/2.42/packaging/fedora/snapd.spec is the 2.42 release blob [09:05] fwiw [09:06] Chipaca: degville: updated [09:06] mborzecki: thank you! [09:06] mborzecki: is /blob/2.42/ the same as /blob/release/2.42? [09:07] anyway, i'll stop pestering now === alan_g is now known as alan_g_ [09:22] pedronis: is this syntax new in go? https://github.com/snapcore/snapd/pull/7619/files#diff-4a51d32715a8521893a1f9ecf9236fb9R26 [09:22] PR #7619: image,seed: hide Seed16/Snap16, use seed.Open in image_test.go [09:22] looks like type aliases [09:22] are those supported across all our go versions now? [09:27] * zyga afk for a second [09:27] need to find some painkillers for the back [09:27] gosh, I love autumn and all the windy weather it brings [09:31] zyga: yes, they are type aliases, we have already some (for tests) in the code base [09:31] zyga: they were added in 1.9 [09:31] I think [09:36] yep, 1.9 [09:36] PR snapd#7573 closed: [RFC] client: add support for the new "/v2/assertions/%s?remote=true" [09:50] ijohnson: 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 be [09:50] PR #7443: timeutil: fix schedules with ambiguous nth weekday spans [09:51] mborzecki: great, I'll take a look in a bit thanks for explaining that [09:52] ok, onto the bug triage [10:02] PR snapd#7621 opened: Add EPL-2.0 to licenses [10:02] mborzecki, zyga can someone on a fedora system check if "golang.org/x/xerrors" is available as a package? [10:02] mvo: hold on [10:03] mvo: a quick google ftp://rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/g/golang-x-xerrors-devel-0-0.1.20190916gita985d34.fc32.noarch.html [10:03] mvo: so I suspect so [10:03] mvo: i see it was released to 31 only [10:04] mborzecki: is it possible/easy to also releae for f30? [10:04] mvo: if needed it can be brouht to older releases [10:04] mvo: 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 tweaks [10:04] mvo: especially new devel packaes [10:04] will centos be a problem? [10:04] mvo: centos uses vendored pacakges [10:04] cool [10:05] well, it would make the PR I have here a lot nicer so would be nice to have it [10:05] and debian-sid has the package so its really just fedora [10:05] mvo: ah, it's the 1.13 error handling for older go releases [10:05] mborzecki: yeah [10:05] hmmmmm 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] mborzecki: I think we will benefit in other areas too [10:05] pstolowski: which mount unit? [10:06] pstolowski: maybe not enabled in /{etc,lib}/systemd/system/mount.wants or something? [10:06] zyga: mount unit for core snap [10:06] btw. do you have an ubuntu system with nvidia? [10:06] mborzecki: me? [10:07] zyga: yes :P [10:07] mborzecki: not with ubuntu, last time I tried it wasn't working with this GPU [10:07] mborzecki: I think 19.10 will now work [10:07] mborzecki: but I don't have one installed [10:07] mvo: hmm interesting, will check, although mount unit is fine for lxd snap [10:09] zyga: ok, https://bugs.launchpad.net/snapd/+bug/1824168 needs checking on nvidia, perhaps they updated the snap since that time [10:09] Bug #1824168: classic opengl application on 19.04 fail to find gl drivers

[10:10] Ok [10:12] PR snapd#7622 opened: snap: make `snap known --remote` use snapd if available [10:13] ogra@pocketbeagle:~$ grep BUG /etc/os-release [10:13] BUG_REPORT_URL="http://bugs.launchpad.net/snappy/" [10:13] given you guys did so much bug cleanup the last days ... [10:14] is that url in UbuntuCore still accurate ? [10:14] (thats core18) [10:14] mvo: aha! that is the case, thank you [10:16] zyga: hey, is there somewhere we could read about / provide feedback on the hardware-support snaps (GL)? [10:16] there used to be a forum thread about this ... [10:17] Saviq: they are not on the roadmap anymore. What is present is on the forum [10:17] You can respond to existing topics there [10:17] I made one for OpenGL and one for CUDA [10:18] well, the Mir team made one for opengl too ... before yours i think [10:19] https://forum.snapcraft.io/t/libgl-and-snaps/6270 [10:20] and 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/11250 [10:21] mborzecki: I checked with my nvidia gpu + 19.04 and I can reproduce [10:21] hm 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] ijohnson: thanks! [10:24] Saviq: yes [10:24] mborzecki: https://launchpad.net/ubuntu/+source/snapd/2.34.2ubuntu0.1 [10:24] mborzecki: perhaps look in security you did not [10:24] * Chipaca yodas [10:25] Chipaca: heh, thanks! [10:25] mborzecki: fwiw i got there via googling 'snapd ' [10:25] Chipaca: hmmm, still no deb there either, thought the old versions are just kept behind [10:26] unless, it was pulled maybe? [10:26] or the user has -proposed permanently enabled [10:26] mborzecki: ? the link is right there [10:26] mborzecki: on the right, "builds" [10:26] mborzecki: amd64 [10:26] mborzecki: https://launchpad.net/~ubuntu-security/+archive/ubuntu/ppa/+build/16332834/+files/snapd_2.34.2ubuntu0.1_amd64.deb [10:27] (and all the other debs we build) [10:27] Chipaca: 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 pools [10:28] ahhh [10:28] mborzecki: because it got superseded, i assume [10:28] archive doesn't keep all old versions [10:46] huh, we don't restart snapd on removing the snapd snap [10:49] well, if you remove the snapd snap as a general user, you probably expect the deb to be gone too ? [10:50] well you'd be expecting wrong, then [10:53] Chipaca: --purge? [10:54] mborzecki: ? [10:54] Chipaca: duh, misread, it's the snapd snap [10:54] how 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:55] this is 16.04 [10:55] and hello everyone [10:55] create a gadget for your install :P [10:56] (one thats base: core18 ... ) [10:56] for my lxd container running a classic system? [10:56] (i wasnt serious) [10:57] sergiusens: install core [10:57] sergiusens: 1 sec [10:57] note that our classic installs all default us use core, not core18 [10:57] good, I want to avoid installing core, snapcraft is on core18 and doesn't want to be installed [10:57] s/us/to/ [10:57] zyga: so to install snapcraft I need to install core and core18? [10:57] * ogra glares at his fingers [10:57] Yes [10:57] I went down this path as I was told the snapd snap fixed that [10:57] Until we ship snapd snap ootb [10:57] hold on [10:58] 1 sec [10:58] AFAIK it is not ready [10:58] sergiusens: can't you update your snapd package? [10:58] wouldnt that be snapd and core16 then, not core ? [10:58] sergiusens: otherwise, try this [10:58] Chipaca: I could add it to the work flow [10:58] sergiusens: snap set system experimental.snapd-snap=true [10:58] ogra: it is not ready yet [10:59] sergiusens: then snap install snapd [10:59] zyga, yes, i got that ... but you'd not be using core in that scenario, right = [10:59] ? [10:59] zyga: snapd + core18 on classic works fine [10:59] Chipaca: ok, useful for play, but not to get out of this pickle :-) [10:59] sergiusens: what is your pickle? [11:01] sergiusens: as an aside: why are you running things on a 16.04 that is not up to date? :) [11:01] Chipaca: I build snapcraft with assumes command-chain, and 16.04 holding an older snapd [11:01] Chipaca: it is the latest minimal image [11:01] how could it "hold an older snapd" ? it re-execs into core [11:02] sergiusens: snapd 2.40 is in xenial-updates for quite a while now, but ok [11:02] (which should be auto-installed with your first snap) [11:02] Chipaca: yeah, the apt update proved that [11:02] sergiusens: and why does the 'snap set system' call not get you out of there? [11:02] Chipaca: oh, I read "experimental" and sort of hid from it [11:03] well, it's no longer experimental in a new enough snapd :) [11:03] Chipaca: there are still some issues in that setup [11:03] great then [11:04] zyga: what issues? [11:08] Chipaca: snapd tools directory injection into snap mount namespaces leads to stale tools over time [11:08] There is a topic forum describing this [11:08] Along with three proposals for solving it [11:12] Chipaca: I can find the link if you want to know more [11:45] zyga: 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=chipaca [11:45] and more importantly why would it trip up snapd [11:51] zyga: ah, link to the forum, d'oh [11:58] * pstolowski lunch [12:07] sergiusens ping [12:11] sergiusens you might have regression in snapcraft which is in beta [12:11] sergiusens run snapcraft init and then add in snapcraft.yaml plug definition from here https://forum.snapcraft.io/t/the-content-interface/1074 [12:14] ondra: I suspect you'll need to state which of those plug definitions you're using - there's several on that page [12:14] details ... [12:14] PR snapd#7617 closed: snap-confine.apparmor.in: harden pivot_root until we have full mediation [12:14] ogra: details are the bane of our existence. down with details! [12:15] diddledan the very basic one https://paste.ubuntu.com/p/PpBrFGnMcf/ [12:15] diddledan I get "Sorry, an error occurred in Snapcraft: argument of type 'NoneType' is not iterable" [12:15] ooh, interesting [12:15] diddledan seems like missing tests [12:16] diddledan this should be caught during testing [12:16] yes, it should :-) [12:16] diddledan essentially it breaks now every snap using content interface plug [12:16] diddledan true I'm on beta :) [12:19] mborzecki: small test https://github.com/snapcore/snapd/pull/7623 [12:19] jdstrand: ^ [12:19] PR #7623: tests: check world-writable and test-owned files [12:19] PR snapd#7623 opened: tests: check world-writable and test-owned files [12:19] AFAIK we discussed this a while ago [12:20] I'll take a look [12:22] thank you [12:27] ondra: 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:28] sergiusens I used that example straight from our docs [12:28] sergiusens in snap it broke I was just sharing socket [12:28] because our docs are always correct indeed :) [12:29] sergiusens but I wanted to demonstrate it on official example [12:29] ogra :P [12:29] Chipaca: I know why there are no updates, policy today is that build images are based on -release with no -updates [12:30] ondra: that's fine, no worries, we made changes there so there most likley is a regression [12:30] Chipaca: so is the outcome to use the snapd snap or just install core? [12:39] sergiusens cool, thanks === ricab is now known as ricab|lunch [12:51] zyga: ok, fixed your hook comment (good catch!). See https://github.com/snapcore/snapd/pull/7616#pullrequestreview-303088818 for discussion [12:51] PR #7616: interfaces/many: allow k8s/systemd-run to mount volume subPaths plus cleanups [12:57] jdstrand: thank you, I'll look soon [12:58] zyga: thanks, not urgent (just needs to be in 2.43 :) [13:00] huh [13:00] so, yesterday I dropped pulseaudio from chocolate-doom-jdstrand and used audio-playback instead (fine) [13:01] I pushed that to git, which built the snap, which pushed it to edge which updated on my laptop [13:01] $ snap connections chocolate-doom-jdstrand|grep pulseaudio [13:01] pulseaudio chocolate-doom-jdstrand:pulseaudio :pulseaudio - [13:01] $ grep pulseaudio /snap/chocolate-doom-jdstrand/current/meta/snap.yaml [13:01] [1] [13:02] ondra: https://github.com/snapcore/snapcraft/pull/2754 [13:02] so... pulseaudio is connected after the refresh even though the current revision does not plugs it [13:02] PR snapcraft#2754: meta: support the case of a plug without a default provider [13:02] zyga: this seems like a bug ^ [13:03] PR snapcraft#2754 opened: meta: support the case of a plug without a default provider [13:03] jdstrand: aha [13:03] in standup now [13:04] jdstrand: can you clarify, even though the revision does not plug it? [13:07] jdstrand: are you referring to "snap connections" claiming there is a connection even though a plug or slot has been removed? [13:07] zyga: 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 connected [13:07] I see [13:07] zyga: unsurprisingly, that is also true of 'snap interfaces' [13:10] zyga: the profile on disk correctly only has audio-playback in the snippets [13:11] zyga: I'm going to file a bug. someone can mark it Invalid if it is operating as designed [13:12] jdstrand: any hints on this: [13:12] apparmor="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=0 [13:12] it comes from a command executing a python script [13:12] am I missing an interface? [13:13] or maybe not... what's going on LP? [13:13] jdstrand: thank you for the bug [13:13] jdstrand: lp is a bit wonky recently [13:13] release day ... [13:13] jdstrand: are you seeing timeout errors? [13:13] it is busy at some release party i guess [13:14] (getting drunk and such) [13:14] kjackal_v2: you can use mount-observe to avoid it [13:14] cool, trying that now, thanks zyga [13:15] kjackal_v2: plugs mount-observe [13:15] zyga: I see nothing. all white [13:15] jdstrand: oh that's even more buggy :) [13:15] there we go [13:16] there must be a tool suggesting the interfaces based on denials. thank you [13:16] * jdstrand writes his bug report in an editor to then paste in [13:16] kjackal_v2: snappy-debug [13:16] kjackal_v2: there's snappy-debug [13:16] kjackal_v2, it is called snappy-debug [13:16] bah, snap [13:16] but I think we could instead have a tree-like output of files and patterns and associated interfaces that grant access [13:16] woohoo, thank you [13:16] kjackal_v2: I don't know if you saw, but it is called snappy-debug ;) [13:17] snappy-what ??? [13:17] :) [13:18] jdstrand: I think snapd could even make that output [13:18] jdstrand: even based on dynamically created interfaces [13:18] jdstrand: that would be pretty neat actualy [13:18] *actually [13:20] zyga: the problem is globs and weird things like dbus rules and things with peers, etc [13:21] zyga: for best results (that snappy-debug is not currently doing) we need to use logprof to aid in suggestions [13:21] Yeah but those are all doable [13:21] and logprof is py3 [13:22] snappy-debug receives nearly no love and I would still consider it poc code [13:22] I mean, it works, but isn't perfect [13:27] brb [13:34] PR snapd#7518 closed: cmd/snap: sort tasks in snap debug timings output [13:36] zyga: 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 on [13:37] right now I have to dump the policy snippets to disk in a rather convoluted manner and ship those snippets in snappy-debug [13:38] which, again, 'works', but it gets out of date and there are some problems wrt implicitCore and implicitClassic [13:38] anyway, we could discuss this over lunch sometime. it isn't like any of this is resourced :) [13:40] jdstrand: hey there - hope it's not too short-notice, I scheduled the kickoff for the review-tools stateful thing in 50 min [13:42] roadmr: 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 before [13:42] pstolowski: 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 though [13:42] possibly... [13:43] roadmr: 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] pstolowski: I made a note [13:43] roadmr: that doesn't mean I can't attend the meeting, just trying to set expectations [13:44] jdstrand: 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 ideally [13:45] roadmr: ack [13:48] pedronis: ok [13:52] pstolowski: 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 disconnect [13:52] pstolowski: I don't recall if that was intentional (ie, it is still a known todo) [13:53] pstolowski: but if it was unknown, now it is known [13:53] :) [13:53] pstolowski: hey btw :) [13:56] jdstrand: 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 yet [13:56] PR #7601: overlord/ifacestate: use SetupMany in setupSecurityByBackend [13:56] jdstrand: so, thanks for pointing out [13:58]