[01:11] sdhd-sascha: that's expected since if you copy cmd_sign.go to cmd_foo.go, then you're really just adding a `snap foo` command rather than a new command like `foo bar` [01:12] sdhd-sascha: as for what if you misspell something that's what code review is for :-) [06:16] morning [06:26] mvo: hey [06:27] mborzecki: good morning! [07:09] good morning! [07:10] zyga: good morning [07:10] just finishing my morning sandwich here [07:10] how are you guys? [07:10] I spent most of yesterday afternoon debugging issues related to gid dropping [07:10] (so snap-confine can stop being setgid root) [07:10] found a few things after sorting out the initial wave of mkdir problems [07:11] the spread test that finds wrong permissions on directories and files was invaluable [07:11] zyga: nice [07:11] one issue still remains, in snap-update-ns, it also creates some files [07:11] oh well :) [07:11] but today I should get through all of that [07:11] zyga: cool! I'm cleaning up boring spread tests :) [07:11] great [07:12] updating them to current standards? [07:14] zyga: nah, just updating the uc20 test so that it gets pass the review feedback :) [07:15] I see :) [07:15] well, not anywhere less noble :D [07:19] good morning [07:22] hey sdhd-sascha, how are you doing? [07:27] zyga: 'standards'? [07:27] mborzecki: some tests are really quaint [07:28] the older the more likely you would rewrite it just after looking at it [07:28] hah i can imagine [07:45] zyga: i'm fine. thank you :-) Hope you, too [07:47] something not right with apparmor spec in the desktop interface [07:47] Jan 08 07:35:17 jan080727-593014 dbus-daemon[18726]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/org/freedesktop/portal/desktop" interface="org.freedesktop.portal.OpenURI" member="OpenURI" mask="send" name="org.freedesktop.portal.Desktop" pid=18835 label="snap.test-snapd-desktop.cmd" [07:48] mborzecki: did you change anything or can I just look at master? [07:48] mborzecki: (to look at the rules) [07:48] zyga: master is fine [07:49] huh [07:49] so [07:50] zyga: i mean looking at the code in master is fine, not that it works on master ;) the relevant bit https://github.com/snapcore/snapd/blob/master/interfaces/builtin/desktop.go#L189-L194 [07:50] I wonder if this works at all [07:50] notice that we don't say member=... [07:50] maybe that means member="" [07:50] try adding that [07:50] member=OpenURI [07:50] and if this fixes it let's look at what else needs to be there [07:50] mborzecki: also check the confinement on the portal [07:50] maybe, by chance, it has a non-snap apparmor label [07:51] zyga: portal didn't even start, the request got blocked earlier [07:51] mborzecki: can you check that the relevant rule is really there in the apparmor profile? [07:52] zyga: unfortunately the rule is in the profile :/ [07:53] hmm [07:53] so [07:53] I wonder if this is this: [07:53] path=/org/freedesktop/portal/{desktop,documents}{,/**} [07:54] this can expand to path=/org/freedesktop/portal/desktop/** [07:54] zyga: as i udnersdtand, not specifying a member means to allow all members of the interface [07:54] what if that doesn't match /org/freedesktop/portal/desktop [07:54] mborzecki: try changing that regexp [07:55] mborzecki: to say path=...{,/,/**} [07:55] though perhaps I'm wrong [07:55] because it would probably match the plain expansion [07:55] without /** [07:56] hmm we have other spread tests for portals too and those are passing afaik, wonder what makes this one special [07:56] mborzecki: are you testing interactively or is there a spread test? [07:57] mborzecki: ha [07:57] mborzecki: one more idea [07:57] is this really true? [07:57] interface="org.freedesktop.portal.OpenURI" [07:57] zyga: spread test for snapctl user-open going to a desktop-portal rather than snap userd [07:57] is the interface really interface="org.freedesktop.portal.OpenURI" [07:57] or is OpenURI the method now (member) [07:57] if so the expression won't cover it [07:57] it requires portal.* [07:58] zyga: we have interface=org.freedesktop.portal.* [07:58] right [07:58] but what if the audit message is not really what it seems [07:58] I would say that the interface is org.freedesktop.portal - full stop there [07:58] and the member is OpenURI [07:58] see what I mean? [07:59] interface="org.freedesktop.portal.OpenURI" [07:59] er [07:59] https://www.irccloud.com/pastebin/As3p4zI1/ [08:00] Jan 08 07:58:31 jan080727-593014 dbus-daemon[18726]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/org/freedesktop/portal/desktop" interface="org.freedesktop.portal.OpenURI" member="OpenFile" mask="send" name="org.freedesktop.portal.Desktop" pid=19338 label="snap.test-snapd-desktop.cmd" [08:00] try this [08:00] opening a file gets blocked too :/ [08:00] is this on arch? [08:02] 19.10 [08:04] zyga: there are multiple interfaces under org.freedesktop.portal [08:04] jamesh: hey :-) [08:04] jamesh: do you know if the OpenURI method is on the interface called OpenURI [08:04] zyga: yes. It is an OpenURI method on the o.f.p.OpenURI interface [08:04] aha [08:05] in that case I have no idea why there is a denial [08:06] mornings. i need to run an errand, will start for real a bit later (in ~1h) [08:06] good morning Pawel [08:08] PR core-build#58 opened: initramfs: add neccessary modules for rockchip emmc and sdcard [08:09] mborzecki: one idea: does it work if you manually start xdg-desktop-portal from outside of confinement first? [08:09] I'm wondering if this is a "missing AssumedAppArmorLabel" problem [08:10] mmmm [08:10] good hunch [08:11] jamesh: good catch, yeah, it's different now, not getting blocked [08:11] ha [08:11] I wonder if we didn't notice that before [08:11] because snap run activates one of the portals on startup [08:11] so it would be activated by an unconfined program [08:11] I am surprised we aren't hitting that denial in the other desktop-portal-* tests [08:12] I don't see anything that would start it before hand [08:12] jamesh: not entirely sure, but test-snapd-portal-client activated the portal, but doing the same via xdg-open gets blocked [08:14] mborzecki: the problem is that we don't know the AppArmor label xdg-desktop-portal will run with prior to it starting. So the AppArmor rule allowing communication with peer=(label=unconfined) doesn't match [08:15] mborzecki: are the interface plugs of test-snapd-portal-client different to whatever snap you're using to call xdg-open? [08:16] jdstrand: nope, they're the same, only desktop plug [08:16] jamesh: ^^ [08:17] mborzecki: is there any difference in the order of operations in preparing the test? [08:19] mborzecki: which other portal test passes? [08:19] zyga: tests/main/desktop-portal-* [08:19] https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_run.go#L691 [08:20] zyga: that's document portal [08:20] those tests are interesting [08:20] they set up fake portals up front [08:20] so the portal is never activated [08:20] * zyga checks to be sure [08:21] I take that back [08:21] the portal is fake [08:21] if xdg-document-portal causes xdg-desktop-portal to start, then we wouldn't hit the activation problem [08:21] but seems to be activated [08:21] hmm. If portalsUnavailableFile has leaked from a previous test using the snap in mborzecki's test, then we might not try to start the document portal [08:21] where is that file stored? [08:22] nothing outside of the desktop-portal-* tests use test-snapd-portal-client [08:22] it would be $XDG_RUNTIME_DIR/snap.$SNAP_NAME/.portals-unavailable [08:22] I doubt we clean that up [08:22] perhaps we ought to [08:22] and that would be XDG_RUNTIME_DIR for uid 1000 [08:23] jamesh: don't think it's the cause, i stop the deskto portal, then run test-snapd-portal-client open-uri and it gets activated, but doing the same with test-snapd-desktop.cmd xdg-oopen gets blocked [08:23] uid 1234, even [08:23] PR snapd#7943 closed: tests: add core20 tests [08:23] zyga: hey, what are you testing. And how can i reproduce it? Seems to be interresting for wayland-server snaps too [08:24] mborzecki: does /run/user/1234/snap.test-snapd-desktop/.portals-unavailable exist? [08:24] sdhd-sascha: it's mborzecki, not me [08:24] sdhd-sascha: xdg portals and some apparmor interactions [08:24] i see, is `test-snapd-desktop` in the store? [08:25] or, in the tests? [08:25] jamesh: nope [08:25] sdhd-sascha: most of the snaps are in the snapd repo [08:25] zyga: also: the tests are running against the real xdg-desktop-portal service: they're just faking the UI service that the snap doesn't communicate with [08:25] and only some are in the store, usually if they 1) require compilation 2) require being from the store [08:25] jamesh: I see [08:44] Can i ask, if we could merge this #7927 ? [08:44] PR #7927: interfaces: x11 allow apparmor on classic [08:50] re [09:00] aha [09:00] I know what fails now [09:00] man [09:00] such a complex sooup [09:00] soup [09:04] jamesh: so it looks to me that the python dbus client actually starts the service https://paste.ubuntu.com/p/42ZWnBHwxN/ [09:08] jamesh: looking at apparmor profile, sending org.freedesktop.DBus.StartServiceByName is allowed via included dbus-session-strict abstraction [09:10] mborzecki: interesting. That kind of makes the whole AssumedAppArmorLabel thing a bit pointless if you can arbitrarily start services anyway [09:19] jamesh: i've updated #7963, the spread test will fail atm until we figure out what's wrong [09:19] PR #7963: xdgopenproxy: forward requests to the desktop portal [09:19] cool. I'll have a look [09:30] brb [09:42] re [09:43] sdhd-sascha: it needs to be reviewed by jamie [09:43] and after xmas break we have a larger backlog of things to catch up with [09:43] expect maybe mid next week [09:43] perhaps earlier but I cannot speak for jamie's timetable [09:44] zyga: it's not urgent. just saw the many PRs and thought this one, could be simple [09:44] sdhd-sascha: anything involving interfaces is tricky and needs to have a review from jamie [09:45] ok [09:50] 7953 needs a second review (and is pretty trivial now) [09:51] let me look quicky [09:51] I resolved my blocker and now need to just code the solution [09:51] so good time to switch gears for a second [09:52] mvo: is that the right number? it has two +1s already [09:53] mvo: the commit and service name don't match [09:53] mvo: personally I prefer the shorter name (snapd.spread-tweaks.service) [09:53] mvo: but I think it's fine to just change the commit message to talk about snapd.spread-tests-run-mode-tweaks.service [09:54] mvo: I hope this makes sense [09:54] zyga: indeed, nice catch [09:54] zyga: thanks, I overlooked it had a second +1 already, silly me [10:20] PR snapd#7962 closed: tests: cherry-pick fixes for snap-set-core-config/ubuntu-core-config-defaults-once [11:05] interesting but unrelated to 7953 https://paste.ubuntu.com/p/XG8tpZcG3s/ [11:13] mborzecki: I saw that a number of times [11:13] at random [11:13] feels like something is racy [11:26] break [11:34] PR core20#19 opened: static: add /etc/environment to writable-paths [11:37] cmatsuoka: hi, there were some conflicts in https://github.com/snapcore/snapd/pull/7958 i've merged master and pushed, can you double check it looks ok? [11:37] PR #7958: snap-bootstrap: refactor partition creation [11:38] mborzecki: thanks, checking... [11:39] ijohnson: hey, you asked about docker-smoke failing on uc20 the other day - here is the full log https://paste.ubuntu.com/p/Z2JStRP6sw/ [11:39] * zyga takes the dog out [11:39] ttyl [11:41] mborzecki: it's good, thanks for resolving the conflict [11:42] cmatsuoka: cool, hope the travis job will be green :) [11:53] PR snapd#7953 closed: tests: use new snapd.spread-tests-run-mode-tweaks.service unit [12:06] back [12:35] PR snapd#7966 opened: tests: first core20 test fixes [12:35] Saviq, hey [12:36] I am trying to create some snaps with base: core20 [12:36] and I am getting this error related to multipass [12:36] launch failed: Unable to find an image matching "core20" [12:36] cachio: there wasn't a build environment for them last year ;) [12:36] any idea about when that image will be published or if is there any workaround for that? [12:37] ll [12:37] Saviq, any idea when it should be ready? [12:38] sergiusens: got any pointers for cachio ^? Is there an image yet that we could hook up to core20 builds? [12:39] cachio: you could try launching daily:20.04 named snapcraft-, but there's some setup you might need [12:39] That, or upgrade the one snapcraft launches for you [12:39] Saviq, ok, I'll try that, thanks!! [12:40] cachio: hi, do we have regular updates of centos spread images? [12:41] mborzecki, yes [12:41] weekly [12:41] mborzecki, this is the last one 2 days ago [12:41] https://travis-ci.org/snapcore/spread-cron/builds/633276566 [12:44] cachio: thanks, i was hoping some updates for systemd landed, but apaprently not [12:45] mborzecki, long time waiting for that landing :( [12:47] cachio: Saviq build-base is what you could use [12:47] sergiusens: but that would only accept "core18" and "core16", right? [12:48] I'm thinking we could have a Multipass branch that does have "snapcraft:core20" [12:48] Saviq: yes, but even if you provide a core20 base quickly for multipass our plugins would need to gain support for core20 [12:49] Saviq: which is a task I am going to start next Monday [12:50] sergiusens: ack, let me know if we can help [12:50] I'll bake a Multipass that has a core20 pointing somewhere sane-ish [12:51] Saviq: if you add it to "mainline" multipass no harm should be done since snaps built with it will be marked grade devel [12:52] sergiusens: yeah but it would suggest it's something real, which it's not atm :) [13:05] mvo: when #7939 is green it can be landed, reminder about #7947 needing a pass from you [13:06] PR #7939: boot,o/devicestate: refactor MarkBootSuccessful over bootState [13:06] PR #7947: boot/many: support new UC20 style kernel extraction [13:09] somewhere, i had a patch for meson and core20. Don't know why i have closed the PR 2797 [13:09] PR #2797: tests: stop tying setting up staging store access to the setup of the state tarball [13:10] i will recreate that PR. It was easy for meson to enable the plugin on core20 [13:18] * zyga fires spread, hoping to see some progress [13:21] i found my private changes - but i there is sure some refactor needed https://github.com/snapcore/snapcraft/pull/2854/commits [13:21] PR snapcraft#2854: Core20 [13:21] PR snapcraft#2854 opened: Core20 [13:24] PR snapd#7958 closed: snap-bootstrap: refactor partition creation [13:25] zyga: "fires spread" - i didn't understand the context [13:26] niemeyer: hey, I'm sorry I haven't pinged you yet - still working on uid/gid bug [13:26] niemeyer: not sure how your day looks like with regards to meetings, I'll have the standup in half an hour [13:27] niemeyer: after that I'm free, we can quickly chat about snap run --explain either now or after if you have the time for that today [13:27] sdhd-sascha: as in run spread tests [13:27] sdhd-sascha: I'm chasing an annoying fix that takes some time to code right [13:28] zyga: yeah - there i have to check if my local spread is working. Without time, i like to use my github repo and my patches for that ;-) [13:29] sdhd-sascha: I develop locally for most of the time but I run a specific set of tests to see if my understanding of the code matches reality [13:31] zyga: yeah, i want to test locally too. But currently dive into so many git-repo's to understand Xwayland, ubuntu-image, ... And my wife... So i have still a todo on setting up the spread locally. (I know it's started last year, but it was so slow, so that i abort it before all tests was run...) [13:32] sdhd-sascha: my recommendation would be to start with small test that you can run via spread [13:32] sdhd-sascha: even if that test needs to pull snaps from the store or from other places [13:33] sdhd-sascha: this allows you to have some kind of reproducibility [13:33] sdhd-sascha: so you can be more sure about changes than "it worked on my $complex_local_setup yesterday" [13:34] yes === ricab is now known as ricab|lunch [13:39] brb, so cold, need to get something warm [13:39] see you at the standup [13:55] morning folks [13:55] hey Ian, how are you doing! [13:56] I miss snow, did you get any this winter? [14:01] zyga: I should be free around 4 UTC [14:12] PR snapd#7967 opened: overlord/snapstate: improve snapd snap backend link unit tests [14:20] cachio: do you have a debug shell to a node with arch image by any chance? [14:24] sergiusens, hi! I was wondering, is there a way to stage packages for a snap without the dependencies? (that is, to strictly stage only what is specified in stage-packages) [14:24] PR snapcraft#2855 opened: project: remove unused errors [14:30] Hey, if someone is interested. I found why "ubuntu-image" always create a too small rootfs-partition on my system. https://github.com/CanonicalLtd/ubuntu-image/pull/182 [14:31] PR CanonicalLtd/ubuntu-image#182: rootfs: sync before measure size [14:31] mborzecki, no [14:32] mborzecki, this is the erro https://travis-ci.org/snapcore/spread-cron/builds/633276548#L1446 [14:33] PR snapcraft#2855 closed: project: remove unused errors [14:34] cachio: heh, so there's some changes in keys apparently, and it looks like the prompt doesn't work too well when input is not a tty [14:35] cachio: please ping me later about that machine state checker from before the break [14:36] mvo, degville: https://forum.snapcraft.io/t/behaviour-change-sticky-and-default-tracks/14970 [14:36] I completely forgot about it but I did work on it a bit more to get to the point where it can ship a standalone version [14:36] zyga, sure [14:36] cachio: hm weird, i have pacman -Syu in spread prepare section for arch, and got a shell just fine, so an update must have been applied without problems [14:36] PR snapcraft#2852 closed: wstool: don't rely on host git [14:37] Chipaca: mvo: also it seemed you didn't want to ship snap known --remote using snapd but not download, but that's the state in 2.43 I think, no? [14:38] mborzecki, this is the file which we use to update arch https://github.com/snapcore/spread-images/blob/master/tasks/google/update-arch-linux/task.yaml [14:39] mborzecki, could be caused by pacman-key --populate ?? [14:39] PR snapcraft#2842 closed: rust: add support for workspaces [14:42] PR snapcraft#2845 closed: remote-build: configurable timeout/deadline for starting and monitoring build [14:45] PR snapcraft#2767 closed: rust plugin: add rustup profile [14:50] cachio: hm i've never used it [14:50] cachio: what's the starting image that you use? [14:50] mborzecki, an old one [14:50] mborzecki, it is called arch-linux-64-base [14:51] mborzecki, I update it every 6 months aprox [14:51] cachio: ok, so the keys that are there may have expired [14:52] mborzecki, ok, I'll update the base image and try again [14:53] cachio: reading the manpage, --populate reloads the keys from keyring, but if those are expired, you still end up with outdated keys? [14:53] pedronis: uh, indeed [14:53] mborzecki, ah [14:54] cachio: could use just use the current image as base and update that to become the next snapshot? [14:54] mborzecki, well, I try to dont do it because our current image has a lot a packages installed [14:55] I think best solution is to update weekly the base image [14:55] does it make sense? [14:57] currently we are updating the images using the bases [14:57] so, perhaps we should update the base image and then the test image [14:58] using the already updated image [14:58] the scripts that update the base images just make update/upgrade and reboot [14:59] the scripts that update hte test images so the same + creation ¿/deletion of users, management of service, etc [14:59] and install packages for snapd testing as well [15:01] mborzecki, the errror happens when we do this pacman -Suq --needed --noconfirm git jq python2 unzip wget [15:01] cachio: yeah, we should probably the base image and then the spread one using the new base [15:02] those are dependencies that we have for spread image project to run the scripts === ricab|lunch is now known as ricab [15:04] mborzecki, I'll skipped those to see if it works [15:05] mborzecki, I am going to pick my daugther, I'll be back in 20 mins [15:08] * cachio afk [15:08] mvo: should we revert the 'known' change, then? [15:08] mvo: for .43 i mean [15:09] cachio: got it to work [15:12] Chipaca: yeah, I think that is sensible [15:14] cachio: https://github.com/snapcore/spread-images/pull/24 [15:14] PR spread-images#24: tasks/google/update-arch-linux: update archlinux-keyring before other packages [15:32] Chipaca: given how far 2.44 is atm, this feels a bit premature to me: https://forum.snapcraft.io/t/behaviour-change-sticky-and-default-tracks/14970 , not sure if it was discussed at standup [15:33] pedronis: it does say TBC fwiw [15:36] Chipaca: I got a bit worried about you liking sparkiegeek answer about how to set it now, which is kind of too early I feel [15:37] pedronis: ah [15:38] pedronis: it's useful if somebody wants to play with it [15:39] Chipaca: anyway I clarified what will happen atm if they do that [15:40] you really didn't :) but now that you gave me extra context i understand what you meant [15:42] Chipaca: feel free to incorporate my comment expanded at the top or something then [15:43] Chipaca: it should probably say that snap where this is not set will still use latest, and snapd <2.44 will still ask for latest anyway [15:47] zyga: mvo: I got weird failures here: https://api.travis-ci.org/v3/job/634225161/log.txt [15:47] looking [15:48] aha, I saw this like around 5 times maybe in total [15:48] I was never able to reproduce this with a shell [15:48] it seems that some of the setup, perhaps of just the test, is racy and the container runs before it can really execute [15:49] maybe just after we install snapd the profiles are not really ready yet [15:49] but the service is up [15:49] as in systemd thinks we are good [15:49] so we install a snap and that explodes [15:49] would be good to check if the first-setup we is done before or after systemd considers us to be up [15:50] pedronis: off-topic but I've seen that snapd-failover task fail before as well, I added an additional debug section to one of my PR' [15:50] s to see what the issue was with that [15:50] because if it is after then this is clearly racy in that regard [15:50] to be precise: the setup of the snap-confine profile happens as a side effect of getting core/snapd snaps [15:51] and snap-confine actively checks if it has a profile, this is the failure that was printed here: [15:51] + lxd.lxc exec my-ubuntu -- su -c '/snap/bin/test-snapd-sh.sh -c '\''echo from-the-inside'\''' ubuntu [15:51] snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks [15:53] zyga: we are up for systemd before we do various things [15:53] I see [15:53] hmm, that's not great [15:53]