[00:05] Is pulseaudio now snap only install? [00:08] pulseaudio is still in Ubuntu. The snap seems pretty out of date. [00:08] (still in Ubuntu as a .deb, I mean) [00:40] cjwatson: Thanks. Looks like an update to 7.5 was reverted to 7.4, causing issues in apt/dpkg [01:02] is there a way to do full disk encryption on ubuntu core for Pi4 without paying $30,000 for a smart start plugin? === diddledan6 is now known as diddledan [02:12] PR snapcraft#2658 closed: candidate testing [02:12] PR snapcraft#2873 opened: candidate testing [06:24] morning [07:08] PR snapd#7988 closed: snap: remove "host" output from `snap version` <⚠ Critical> [07:37] mvo: morning [07:37] mvo: can you cherry pick #7988 to 2.43? [07:37] PR #7988: snap: remove "host" output from `snap version` <⚠ Critical> [07:42] mborzecki: good morning! [07:42] mborzecki: yes, will do now [07:42] mborzecki: do you know if we need anything else for .1 ? [07:42] mvo: hmm, selinux policy would be nice [07:43] mborzecki: yeah, could you please tag as 2.43? [07:43] mvo: https://github.com/snapcore/snapd/pull/7978 want me to open a PR with backport? [07:43] PR #7978: data/selinux, test/main/selinux-clean: update the test to cover more scenarios [07:43] good morning [07:43] mborzecki: backport is fine, if its small I can cherry-pick [07:43] zyga: good morning [07:43] mvo: .1 release coming for that snap version output changeW? [07:43] zyga: yes, anything from you we need for .1 ? [07:44] no, sorry [07:44] I'll try to do better today [07:44] zyga: that's fine [07:44] zyga: no worries [07:44] mborzecki: it's just three commits, if they apply cleanly I will just cherry pick them [07:44] mvo: yeah, that should be fine [07:45] mborzecki: yeah, no conflicts, done [07:45] mvo: cool, thank you! [07:46] mborzecki: thank you ! [07:46] mborzecki: I will wait for pawel and samuele to double check if they think we need to add anything and then proceed with the release of .1 [07:52] PR snapd#7981 closed: snap-bootstrap: create encrypted partition [07:58] https://github.com/snapcore/snapd/pull/7974#issuecomment-574050904 is the weirdest python review I ever made [07:58] PR #7974: many: run black formatter on all python files [08:01] * zyga reviews indirect download PR [08:02] mornings [08:12] hey pawel [08:12] pstolowski: it's coming today [08:12] pstolowski: :) [08:13] zyga: yay :) [08:16] hey pstolowski ! good morning! anything you can think of we need/should include in 2.43.1 ? [08:18] mvo: hey, nothing from me [08:19] ta [08:41] errand, back in 1h or so [08:54] brb [08:56] mvo: hi, I commented on #7989 [08:56] PR #7989: devicestate: do not allow remodel between core20 models [08:56] mborzecki: mvo: #7990 is missing some end of doc comment sentence . [08:57] PR #7990: many: misc tweaks [08:59] pedronis: thank you [09:00] pedronis: makes sense [09:05] back [09:27] mvo: https://github.com/snapcore/snapd/pull/7977#pullrequestreview-341982749 [09:27] PR #7977: snap: add (hidden) `snap download --indirect` option to download via snapd [09:28] mvo: not sure if I'm right, otherwise +1 [09:28] mvo: though I want to check one more thing that landed before [09:28] mvo: as it is realted [09:28] *related [09:29] checked out, ok [09:34] zyga: aha, nice one. I need to double check but I think you are right [09:34] zyga: \o/ [09:34] re [09:34] * zyga reviews the SnapAction PR next [09:35] mvo: just for reference, I checked if the remote download API cannot be used to abuse snapd to write to arbitrary files [09:35] mvo: but I'm happy to see it is not that [09:35] mvo: the API is just streaming the file via snapd, correct? [09:35] (that's how I understood the api_download.go code) [09:37] zyga: correct, in this regard there is no change to the old download code, the old code would connect to the download server directly, the new code connects to snapd for the download [09:37] mvo: right, I was specifically looking for how the write to disk is done [09:37] mvo: it is done via snap download running as user, which is what was important to me [09:38] mvo: and specifically there is no path that snapd writes to that could be used to attack anything [09:38] mvo: could we create a test-snapd- snap to test default tracks? [09:39] zyga: correct [09:39] Chipaca: yes [09:39] mvo: in the snaps@ account an' everything? [09:40] Chipaca: please create it under your account for now and then share with me/cachio - I need to create/use the new snapd-testing store account but I have not yet :( probably this is a good time to do that but I don't want to block you [09:41] mvo: ok [09:45] Chipaca: share it with me too [10:14] Chipaca: https://github.com/snapcore/snapd/pull/7984#pullrequestreview-342411978 [10:14] PR #7984: store, overlord/snapstate, etc: SnapAction now returns a []…Result [10:15] zyga: ack [10:15] i'll do it in a followup when i switch to the new snap [10:17] oh well, we have a bug [10:17] pstolowski: oh? [10:20] snap connections and snap interfaces reports connections for missing slots/plugs (e.g. after refreshing to a snap that doesn't have a plug/slot anymore). the repo doesn't have such plug/slot anymore, but api reads "conns" and doesn't intersect with repo (or snap.yaml data) [10:20] I think we knew about this [10:20] it's reported AFAIK [10:20] hmm maybe you're right. i think issues around that had a few incarnations [10:21] fwtw it's just the list of connections affected; security profiles are generated from repo data so they're fine [10:23] anyway.. i'll look at fixing it [10:24] pstolowski: do you have an idea on how the fix should look like? [10:28] zyga: quick/rough one:L maybe collectConnections() in the daemon should (or ifaceMgr.ConnectionStates() one level deeper) intersect conns with repo [10:29] i'll look at details later. i stumbled on it accidently when working on spread test for snap disconnect --forget [10:32] pstolowski: I'll give it some thought and get back to you [10:37] Chipaca: hmm hmm https://forum.snapcraft.io/t/596-523-hours-left-0-bytes-sec/15033/7 IDK what to say ;) [10:38] mborzecki: moved it to the cafe [10:38] Chipaca: thx [10:40] zyga: thanks [10:41] pstolowski: hi, I did a pass on #7982 [10:41] PR #7982: o/snapstate, wrappers: enable services on start <⛔ Blocked> [10:42] pedronis: ty [10:44] quick errand [10:48] Chipaca: hi, it seems 7984 can be merged [10:48] pedronis: yep [10:48] pedronis: was waiting for a nod on the next one; don't want to merge it if I then need to change the refactor [10:49] pedronis: but I guess I have that [10:49] pstolowski: mborzecki: we need to remember to try to s/GetType/Type/ at some point before .44 [10:49] as your comments were about the details, not about the guts of it [10:49] so, yeah, merging [10:50] Chipaca: one non-blocking question is whether it would make logic sense to move EffectiveChannel to SAR as well or not [10:50] PR snapd#7984 closed: store, overlord/snapstate, etc: SnapAction now returns a []…Result [10:50] pedronis: the followup (7986) is red because the snap i use to test isn't in i386, so i decided to create our own snap now [10:51] pedronis: (i had planned to that sometime anyway, which is why i put it in a variable :) ) [10:51] pedronis: right [10:51] pedronis: right [10:51] PR snapd#7990 closed: many: misc tweaks [11:02] pstolowski: https://forum.snapcraft.io/t/opera-requests-auto-connect-to-gnome-3-28-1804-interface/14505/14 [11:02] pstolowski: can you snap install `opera-developer` it looks like we have a serious autoconnect issue [11:02] I just want to double check that it's equally broken on Ubuntu for you [11:03] looking at what's going on now [11:03] zyga: will do in a sec [11:05] pstolowski: I think it's caused by the snap declaration [11:08] zyga: confirmed, gnome-3-28 content plug is not autoconnected [11:08] pstolowski: check my response on the forun [11:08] pstolowski: I don't recall how that part works [11:09] pstolowski: if we have a snap declaration with plugs/content/allow-auto-connection entry [11:09] pstolowski: does it mean _only_ that entry is auto-connected [11:09] pstolowski: or does it mean that defaults apply but those are extras? [11:09] zyga: yes, if the snap has a content thing like that then it will not use the slot one [11:09] pedronis: what do you mean by "it will not use the slot one"? [11:10] I mean that the slot side snap-declaration on gnome-* will not be used [11:10] the only content auto-connection they wil get is the one they are allowing in their declaration [11:10] there is n merging [11:10] there is no merging [11:10] mhm [11:11] so there are two bugs here [11:11] 1) the declaration for opera-developer needs fixing [11:11] 2) this is not discoverable much [11:11] discoverable what? [11:11] they asked somebody in the store for that declaration [11:11] pedronis: snap install did not respect auto-connection that otherwise normally happens [11:12] pedronis: and didn't say anything about why [11:12] why would it? the declaration asked for this [11:12] is not something the user can fix [11:12] pedronis: why would it? because the developer defined a plug and a default provider [11:12] re [11:12] and we used additional data to ignore that [11:12] I think this warrants a message [11:12] zyga: data that they asked for [11:12] and I think the existence of that thread agrees [11:13] anyway user != developer [11:13] pedronis: if I have a snap and I say I want to connect to a default provider snapd should 1) connect to it 2) tell me why it doesn't [11:13] I wonder what is that snap [11:13] anything else is silent behavior that defies request [11:14] this is not a typical scenario [11:14] no but I think my point stands [11:14] I wonder if they were early adopter of something [11:14] we should say "not connecting despite default provider because snap-declaration data says not to" [11:15] pedronis: I would also argue that part of no-merging is also a bug / surprising [11:15] I know it's the design, since I've been to that meeting [11:15] but it's surprising [11:15] zyga: we will not change that [11:16] pedronis: I think the only thing that really needs to be changed in snapd is to make this more discoverable [11:16] anyway they are connecting to chromium-ffmpeg [11:16] that's what that connect is [11:16] so that it doesn't require a snapd developer to debug each time [11:16] but now they need something else to connect to gnome as well [11:17] pedronis: and if they didn't need ffmpeg they would get the connection to gnome-* by default [11:17] pedronis: I know you said we're not doing merging but I think you can see how that is surprising [11:19] zyga: the correct solution is probably to move that decl on the chromium-ffmpeg side [11:30] zyga: we publish chromium-ffmpeg it seems, it should have a policy of what snaps can use it (any snaps, some publishers, don't know) [11:34] zyga: to be clear my impression is that this is particularly brittle because content is essentially a completely different interface for each value of the content label [11:35] but is still a single interface for a our logic [11:41] pedronis: I agree entirely [11:41] re [11:41] * zyga was upstairs to help with Lucy [11:41] pedronis: can you comment on the thread with your preference please [11:41] pedronis: I've advised jdstrand to issue a declaration for opera-* snaps [11:45] pedronis: updated #7972 [11:45] PR #7972: overlord/snapstate, wrappers: undo of snapd on core [11:46] zyga: btw jdstrand is off this week [11:46] zyga: I need to check something, but my preference would be for chromium-ffmpeg to control access to itself [11:47] we probably need desktop input on that [11:49] pedronis: yes, as a tweak to assertions it would be preferable O(1) vs O(N) solution [11:49] man, my hand :/ [11:49] my wrist hurts so badly today, I was wrestling with Janek over weekend and I think I hurt myself [11:49] (Janek = son) [11:49] it was so-so yesterday but today it just hurts to do anything [11:50] it's my right hand so I don't use it as often but man, so annoying [11:51] pedronis: I updated 7989 based on your suggestion [11:51] mvo, hello [11:51] cachio: good morning [11:52] mvo, any idea if there is any special configuration for qemu to run core20 images? I see this log trying to start the image https://paste.ubuntu.com/p/QKJw2fPmXt/ [11:52] cachio: anything I should add to 2.43.1 before the release? [11:52] cachio: looking [11:52] mvo, no [11:52] tests for 2.43 ran almost with almost 100% of pass rate [11:53] cachio: the pastebin lookslike something is not quite right with the image, do you have a link to the work-in-progress PR of yours? then I can poke a bit how ubuntu-image and qemu are called [11:54] cachio: e.g. the qemu needs -bios /usr/share/OVMF/... [11:54] mvo, this is the branch https://github.com/sergiocazzolato/snapd/tree/tests-enable-nested-on-core20 [11:55] mvo, I'll try that [11:55] cachio: /usr/share/OVMF/OVMF_CODE.ms.fd to be precise, but I think it depends on the version of ubuntu where that file is :/ [11:56] mvo, did you see https://forum.snapcraft.io/t/how-to-use-camera-in-ubuntu-core18/14971/5 ? seems the start_x parameter does not work for the core18 pi installs [11:57] mvo, thanks for the info, I'll try and debug [12:00] ogra. meh, I have not, looking [12:00] cachio: yeah, I suspect that might be it [12:00] i wonder if there is some pattern match falling over the underscore ? [12:00] cachio: or at least this must be tweaked too, maybe there is more [12:01] ogra: I don't think we support "_" in the config, I wonder if start-x=1 will help [12:01] ogra: but this should behave the same on uc16 and uc18, if not I'm puzzled [12:01] * mvo also has not read the whole thread yet, it seems to be quite long [12:02] ogra@pi4:~$ snap set system pi-config.start-x=1 [12:02] ogra@pi4:~$ [12:02] ogra@pi4:~$ snap set system pi-config.start_x=1 [12:02] error: cannot perform the following tasks: [12:02] - Run configure hook of "core" snap (invalid option name: "start_x") [12:02] ogra@pi4:~$ [12:02] yeah, its the underscore [12:02] zyga: afaict only opera is connecting to chromium-ffmpeg [12:03] all their various snaps: opera, opera-beta, opera-developer [12:04] pedronis: still, I think it makes sense to do what you said about the assertions [12:04] yes [12:04] PR snapcraft#2874 opened: LP-1661626 : Symlink $XDG_RUNTIME_DIR/../dconf/user [12:09] zyga: I added something to thread and pinged kenvandine there [12:09] pedronis: thank you! :) [12:28] * Chipaca steps out for a bit [12:33] pedronis: started adding https://github.com/snapcore/snapd/pull/7991#pullrequestreview-342491713 to ian's PR [12:33] PR #7991: boot: add HasModeenv to Device [12:33] quick errand, back in 20 or so [13:09] mvo, hey, I see these errors starting the core20 image https://paste.ubuntu.com/p/FJfZdsNVrM/ [13:09] these 3 services cannot be started [13:10] correctly [13:11] mvo, do you know if any other configuration is needed for qemu? [13:25] cachio: the e2scrub_reap service is known, the other two are not [13:28] re [13:41] Chipaca: could you please split https://forum.snapcraft.io/t/snapd-2-36-snap-confine-logic-walkthrough/7843/4 into a new topic [13:41] "cannot fsck volume mounted on /var/snap" [13:41] Chipaca: last two messages there please [13:41] zyga: title? [13:41] "cannot fsck volume mounted on /var/snap" [13:42] zyga: in snapd? [13:42] yes please [13:42] thank you! [13:42] zyga: done [13:42] super :) [13:46] gosh, almost standup time already [13:46] where did my morning go [13:50] right? :) [13:52] PR snapd#7993 opened: devicestate: enable encryption based on model grade [13:54] mvo: is .1 out? [13:56] zyga: not yet, one question (if 7879 can be included pending for pedronis first) [13:56] zyga: why, do you have something? [13:56] mvo: I have a 1 liner fix [13:56] mvo: for a small bug [13:56] yeah [13:56] zyga: please push it then [13:56] yup one sec [13:56] zyga: and we can decide. thank you [13:58] mvo: https://github.com/snapcore/snapd/pull/7994 [13:58] PR #7994: cmd/snap-discard-ns: fix pattern for .info files [13:58] PR snapd#7994 opened: cmd/snap-discard-ns: fix pattern for .info files [14:04] * Chipaca sneaks in a risk level "mauve" [14:22] oSoMoN: can you please respond to the question about chromium-ffmpeg in https://forum.snapcraft.io/t/opera-requests-auto-connect-to-gnome-3-28-1804-interface/14505/19 [14:28] sure [14:33] ijohnson: looking at https://pastebin.ubuntu.com/p/568vkDFB7P/ from you standup [14:33] zyga: thanks for that python0 patch, I commited it to the PR :-) [14:33] hopefully the tests are happy again on this [14:34] ijohnson: my pleasure :) [14:34] mborzecki: nice thanks [14:34] ijohnson: I only know because I made the python0 snap [14:34] mborzecki: that one at least is easier cause you have a backtrace from SIGQUIT the other ones are just "timed out" :-( [14:34] ijohnson: looks like a deadlock, between the snippet at standby_test.go:135 and m.Stop() [14:35] zyga: :-) programming archeology indeed [14:35] ijohnson: there's no channel cleaneup, none of the ch{1,2} are closed, so if the we're stuck in querying the opinions, stop will hang [14:36] mborzecki: ah good find [14:40] * zyga breaks for lunch === ricab is now known as ricab|lunch [14:48] oSoMoN: sorry, I mean are we genereally comfortable with any snap using chromium-ffmep? [14:49] pedronis, the typical use case is third-party browser snaps, but I don't see why other snaps couldn't connect to it if they wanted to [14:49] oSoMoN: I'm trying to remove the step where they need to ask for auto-connection, because as opera shows it's likely to get wrong, because all content conection nees to take care holistically [14:50] *needs to be taken care holistically [14:51] degville, ijohnson re snapctl start & --enable (if I got Graham's remarks right), it seems that snacptl start --help is not listing enable even though it's in the code; seems that the command descriptions are not set up correctly (i haven't investigated if it works as expected) [14:52] pstolowski: thank you! that's exactly what I was looking for. [14:52] degville: snap start --help works as expected [14:52] oSoMoN: I have tried to ask this in the forum [14:53] pstolowski: thanks! [14:55] * cachio lunch and bank [14:57] pedronis, that would certainly be better for third-party browser snaps [15:03] degville: pstolowski: yes sorry got distracted, shall I still find you the relevant code snippet? [15:04] * ijohnson was busy reading about how old python 0.9.1 is [15:04] haha [15:05] ijohnson: i looked at ctlcmd/start.go and it seems wrong as far as help is concerned. but maybe i misunderstand what the issue was [15:05] ijohnson: the flag itself should work, i'm talking only about help [15:05] pstolowski: yes the help message there does need to be updated [15:08] degville: as for finding where snapctl is implemented, were you able to sort through the code? snapctl specifically is a bit weird in that really the command options are stored inside the code for the snapd binary and not in the code for the snapctl binary [15:08] ijohnson: yes, thank you! I've got it now - I've got enough to update the docs. [15:09] degville: great glad to hear it [15:11] oSoMoN: if you answer on the forum we can take it from there [15:17] also zyga did you have any thoughts on having black run on all the python code in the snapd repo? [15:17] ijohnson: we should do it [15:17] :) [15:17] I regard black as a good thing [15:17] should we do it as part of run-checks or like spread-shellcheck do you think ? [15:18] personally, I wouldn't really be happy if to contribute to snapd (a Go project) I needed to standup python tools just to run checks [15:18] so I'm leaning towards having a spread test which checks all the formatting in the python code [15:18] ijohnson: I would not go there [15:19] ijohnson: it's not ultra-relevant and any kind of enforced format things ended up sucking IMO [15:19] zyga: ok fair enough [15:23] ijohnson: I reviewed #7992, it seems to be missing unit tests afaict [15:23] PR #7992: bootloader: add ExtractedRunKernelImageBootloader interface, implement in grub [15:24] pedronis: did you mean unit tests of the grub methods? [15:24] yes I think I am missing those now that you mention it [15:24] yes [15:24] sorry I will add those today [15:25] there seem to be a buglet as well [15:25] which hopefully those will find :) [15:26] pedronis: yes :-) [15:26] pedronis: also regarding "." do you just mean in comments that are for doc-comments on exported methods or do you mean everywhere I should use "." ? [15:27] ijohnson: my POV on that is doc comment for exported things, I don't have a strict pattern for internal comments, it depends [15:28] pedronis: ok IMHO I don't think it's needed for internal comments so I will just add to exported doc-comments then [15:28] pedronis: do you want me to open the third PR for you to use for context now (even though it has still at least one bug) ? [15:29] ijohnson: as you prefer, this one looks good to me, except the missing tests etc [15:29] pedronis: ok I wasn't sure if you were able to review the design of that interface without seeing it used in other places [15:30] ijohnson: well I proposed that design, so I have I sense how I imagine it used [15:30] yes :-) [15:31] my imagination might be wrong, but it doesn't really affect the PR in itself [15:35] mborzecki: there's a preexisting bug in readModeenvImpl [15:35] pedronis: hm? [15:35] mborzecki: modeenvPath := filepath.Join(rootdir, dirs.SnapModeenvFile) doesn't make sense [15:36] dirs stuff has already a rootdir in it, we need a SnapModenvFileUnder helper instead [15:36] same approach as SnapStateFileUnder(rootdir string) for example [15:36] hah [15:36] right [15:37] mborzecki: can you look into this when you have moment [15:37] pedronis: yes, sure [15:37] thx [15:40] mborzecki: thansk for the changes to 7991, I made one more nitpick comment that relates to this. [15:44] mvo: I noticed https://forum.snapcraft.io/t/the-snapd-roadmap/1973 is a bit out of date now for 2.43 estimates? [15:50] ijohnson: yes, I need to update it, hopefully later today [15:51] great, thanks [15:52] pedronis: as I'm updating the doc-comments on those grub methods it occured to me that currently EnableKernel() and EnableTryKernel() don't check that the kernel snap referenced there exists, do you think we should error out if an incorrect kernel snap is passed to those things? [15:52] also the only topic there will not make 2.43, but I doubt is the only thing we did in 2.43 === pedronis_ is now known as pedronis [15:53] ijohnson: that makes sense, OTOH Disable should probably be ok even the symlink is not there [15:53] pedronis: ack, and yes agreed about Disable() === ricab|lunch is now known as ricab [15:58] PR snapd#7995 opened: debian: check embedded keys for snap-{bootstrap,preseed} too