[01:11] <ijohnson> 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] <ijohnson> sdhd-sascha: as for what if you misspell something that's what code review is for :-)
[06:16] <mborzecki> morning
[06:26] <mborzecki> mvo: hey
[06:27] <mvo> mborzecki: good morning!
[07:09] <zyga> good morning!
[07:10] <mvo> zyga: good morning
[07:10] <zyga> just finishing my morning sandwich here
[07:10] <zyga> how are you guys?
[07:10] <zyga> I spent most of yesterday afternoon debugging issues related to gid dropping
[07:10] <zyga> (so snap-confine can stop being setgid root)
[07:10] <zyga> found a few things after sorting out the initial wave of mkdir problems
[07:11] <zyga> the spread test that finds wrong permissions on directories and files was invaluable
[07:11] <mvo> zyga: nice
[07:11] <zyga> one issue still remains, in snap-update-ns, it also creates some files
[07:11] <zyga> oh well :)
[07:11] <zyga> but today I should get through all of that
[07:11] <mvo> zyga: cool! I'm cleaning up boring spread tests :)
[07:11] <zyga> great
[07:12] <zyga> updating them to current standards?
[07:14] <mvo> zyga: nah, just updating the uc20 test so that it gets pass the review feedback :)
[07:15] <zyga> I see :)
[07:15] <zyga> well, not anywhere less noble :D
[07:19] <sdhd-sascha> good morning
[07:22] <zyga> hey sdhd-sascha, how are you doing?
[07:27] <mborzecki> zyga: 'standards'?
[07:27] <zyga> mborzecki: some tests are really quaint
[07:28] <zyga> the older the more likely you would rewrite it just after looking at it
[07:28] <mborzecki> hah i can imagine
[07:45] <sdhd-sascha> zyga: i'm fine. thank you :-) Hope you, too
[07:47] <mborzecki> something not right with apparmor spec in the desktop interface
[07:47] <mborzecki> 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] <zyga> mborzecki: did you change anything or can I just look at master?
[07:48] <zyga> mborzecki: (to look at the rules)
[07:48] <mborzecki> zyga: master is fine
[07:49] <zyga> huh
[07:49] <zyga> so
[07:50] <mborzecki> 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] <zyga> I wonder if this works at all
[07:50] <zyga> notice that we don't say member=...
[07:50] <zyga> maybe that means member=""
[07:50] <zyga> try adding that
[07:50] <zyga> member=OpenURI
[07:50] <zyga> and if this fixes it let's look at what else needs to be there
[07:50] <zyga> mborzecki: also check the confinement on the portal
[07:50] <zyga> maybe, by chance, it has a non-snap apparmor label
[07:51] <mborzecki> zyga: portal didn't even start, the request got blocked earlier
[07:51] <zyga> mborzecki: can you check that the relevant rule is really there in the apparmor profile?
[07:52] <mborzecki> zyga: unfortunately the rule is in the profile :/
[07:53] <zyga> hmm
[07:53] <zyga> so
[07:53] <zyga> I wonder if this is this:
[07:53] <zyga>     path=/org/freedesktop/portal/{desktop,documents}{,/**}
[07:54] <zyga> this can expand to path=/org/freedesktop/portal/desktop/**
[07:54] <mborzecki> zyga: as i udnersdtand, not specifying a member means to allow all members of the interface
[07:54] <zyga> what if that doesn't match /org/freedesktop/portal/desktop
[07:54] <zyga> mborzecki: try changing that regexp
[07:55] <zyga> mborzecki: to say path=...{,/,/**}
[07:55] <zyga> though perhaps I'm wrong
[07:55] <zyga> because it would probably match the plain expansion
[07:55] <zyga> without /**
[07:56] <mborzecki> hmm we have other spread tests for portals too and those are passing afaik, wonder what makes this one special
[07:56] <zyga> mborzecki: are you testing interactively or is there a spread test?
[07:57] <zyga> mborzecki: ha
[07:57] <zyga> mborzecki: one more idea
[07:57] <zyga> is this really true?
[07:57] <zyga> interface="org.freedesktop.portal.OpenURI"
[07:57] <mborzecki> zyga: spread test for snapctl user-open going to a desktop-portal rather than snap userd
[07:57] <zyga> is the interface really interface="org.freedesktop.portal.OpenURI"
[07:57] <zyga> or is OpenURI the method now (member)
[07:57] <zyga> if so the expression won't cover it
[07:57] <zyga> it requires portal.*
[07:58] <mborzecki> zyga: we have interface=org.freedesktop.portal.*
[07:58] <zyga> right
[07:58] <zyga> but what if the audit message is not really what it seems
[07:58] <zyga> I would say that the interface is org.freedesktop.portal - full stop there
[07:58] <zyga> and the member is OpenURI
[07:58] <zyga> see what I mean?
[07:59] <zyga> interface="org.freedesktop.portal.OpenURI"
[07:59] <zyga> er
[07:59] <zyga> https://www.irccloud.com/pastebin/As3p4zI1/
[08:00] <mborzecki> 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] <zyga> try this
[08:00] <mborzecki> opening a file gets blocked too :/
[08:00] <zyga> is this on arch?
[08:02] <mborzecki> 19.10
[08:04] <jamesh> zyga: there are multiple interfaces under org.freedesktop.portal
[08:04] <zyga> jamesh: hey :-)
[08:04] <zyga> jamesh: do you know if the OpenURI method is on the interface called OpenURI
[08:04] <jamesh> zyga: yes.  It is an OpenURI method on the o.f.p.OpenURI interface
[08:04] <zyga> aha
[08:05] <zyga> in that case I have no idea why there is a denial
[08:06] <pstolowski> mornings. i need to run an errand, will start for real a bit later (in ~1h)
[08:06] <zyga> good morning Pawel
[08:08] <mup> PR core-build#58 opened: initramfs: add neccessary modules for rockchip emmc and sdcard <Created by JeffyCN> <https://github.com/snapcore/core-build/pull/58>
[08:09] <jamesh> mborzecki: one idea: does it work if you manually start xdg-desktop-portal from outside of confinement first?
[08:09] <jamesh> I'm wondering if this is a "missing AssumedAppArmorLabel" problem
[08:10] <zyga> mmmm
[08:10] <zyga> good hunch
[08:11] <mborzecki> jamesh: good catch, yeah, it's different now, not getting blocked
[08:11] <zyga> ha
[08:11] <zyga> I wonder if we didn't notice that before
[08:11] <zyga> because snap run activates one of the portals on startup
[08:11] <zyga> so it would be activated by an unconfined program
[08:11] <jamesh> I am surprised we aren't hitting that denial in the other desktop-portal-* tests
[08:12] <jamesh> I don't see anything that would start it before hand
[08:12] <mborzecki> jamesh: not entirely sure, but test-snapd-portal-client activated the portal, but doing the same via xdg-open gets blocked
[08:14] <jamesh> 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] <jamesh> mborzecki: are the interface plugs of test-snapd-portal-client different to whatever snap you're using to call xdg-open?
[08:16] <mborzecki> jdstrand: nope, they're the same, only desktop plug
[08:16] <mborzecki> jamesh: ^^
[08:17] <jamesh> mborzecki: is there any difference in the order of operations in preparing the test?
[08:19] <zyga> mborzecki: which other portal test passes?
[08:19] <jamesh> zyga: tests/main/desktop-portal-*
[08:19] <zyga> https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_run.go#L691
[08:20] <mborzecki> zyga: that's document portal
[08:20] <zyga> those tests are interesting
[08:20] <zyga> they set up fake portals up front
[08:20] <zyga> so the portal is never activated
[08:20]  * zyga checks to be sure
[08:21] <zyga> I take that back
[08:21] <zyga> the portal is fake
[08:21] <jamesh> if xdg-document-portal causes xdg-desktop-portal to start, then we wouldn't hit the activation problem
[08:21] <zyga> but seems to be activated
[08:21] <jamesh> 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] <zyga> where is that file stored?
[08:22] <jamesh> nothing outside of the desktop-portal-* tests use test-snapd-portal-client
[08:22] <jamesh> it would be $XDG_RUNTIME_DIR/snap.$SNAP_NAME/.portals-unavailable
[08:22] <zyga> I doubt we clean that up
[08:22] <zyga> perhaps we ought to
[08:22] <jamesh> and that would be XDG_RUNTIME_DIR for  uid 1000
[08:23] <mborzecki> 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] <jamesh> uid 1234, even
[08:23] <mup> PR snapd#7943 closed: tests: add core20 tests <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7943>
[08:23] <sdhd-sascha> zyga: hey, what are you testing. And how can i reproduce it? Seems to be interresting for wayland-server snaps too
[08:24] <jamesh> mborzecki: does /run/user/1234/snap.test-snapd-desktop/.portals-unavailable exist?
[08:24] <zyga> sdhd-sascha: it's mborzecki, not me
[08:24] <zyga> sdhd-sascha: xdg portals and some apparmor interactions
[08:24] <sdhd-sascha> i see, is `test-snapd-desktop` in the store?
[08:25] <sdhd-sascha> or, in the tests?
[08:25] <mborzecki> jamesh: nope
[08:25] <zyga> sdhd-sascha: most of the snaps are in the snapd repo
[08:25] <jamesh> 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] <zyga> and only some are in the store, usually if they 1) require compilation 2) require being from the store
[08:25] <zyga> jamesh: I see
[08:44] <sdhd-sascha> Can i ask, if we could merge this #7927 ?
[08:44] <mup> PR #7927: interfaces: x11 allow apparmor on classic <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7927>
[08:50] <pstolowski> re
[09:00] <zyga> aha
[09:00] <zyga> I know what fails now
[09:00] <zyga> man
[09:00] <zyga> such a complex sooup
[09:00] <zyga> soup
[09:04] <mborzecki> jamesh: so it looks to me that the python dbus client actually starts the service https://paste.ubuntu.com/p/42ZWnBHwxN/
[09:08] <mborzecki> jamesh: looking at apparmor profile, sending org.freedesktop.DBus.StartServiceByName is allowed via included dbus-session-strict abstraction
[09:10] <jamesh> mborzecki: interesting.  That kind of makes the whole AssumedAppArmorLabel thing a bit pointless if you can arbitrarily start services anyway
[09:19] <mborzecki> jamesh: i've updated #7963, the spread test will fail atm until we figure out what's wrong
[09:19] <mup> PR #7963: xdgopenproxy: forward requests to the desktop portal <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7963>
[09:19] <jamesh> cool.  I'll have a look
[09:30] <zyga> brb
[09:42] <zyga> re
[09:43] <zyga> sdhd-sascha: it needs to be reviewed by jamie
[09:43] <zyga> and after xmas break we have a larger backlog of things to catch up with
[09:43] <zyga> expect maybe mid next week
[09:43] <zyga> perhaps earlier but I cannot speak for jamie's timetable
[09:44] <sdhd-sascha> zyga: it's not urgent. just saw the many PRs and thought this one, could be simple
[09:44] <zyga> sdhd-sascha: anything involving interfaces is tricky and needs to have a review from jamie
[09:45] <sdhd-sascha> ok
[09:50] <mvo> 7953 needs a second review (and is pretty trivial now)
[09:51] <zyga> let me look quicky
[09:51] <zyga> I resolved my blocker and now need to just code the solution
[09:51] <zyga> so good time to switch gears for a second
[09:52] <zyga> mvo: is that the right number? it has two +1s already
[09:53] <zyga> mvo: the commit and service name don't match
[09:53] <zyga> mvo: personally I prefer the shorter name (snapd.spread-tweaks.service)
[09:53] <zyga> 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] <zyga> mvo: I hope this makes sense
[09:54] <mvo> zyga: indeed, nice catch
[09:54] <mvo> zyga: thanks, I overlooked it had a second +1 already, silly me
[10:20] <mup> PR snapd#7962 closed: tests: cherry-pick fixes for  snap-set-core-config/ubuntu-core-config-defaults-once <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7962>
[11:05] <mborzecki> interesting but unrelated to 7953 https://paste.ubuntu.com/p/XG8tpZcG3s/
[11:13] <zyga> mborzecki: I saw that a number of times
[11:13] <zyga> at random
[11:13] <zyga> feels like something is racy
[11:26] <zyga> break
[11:34] <mup> PR core20#19 opened: static: add /etc/environment to writable-paths <Created by mvo5> <https://github.com/snapcore/core20/pull/19>
[11:37] <mborzecki> 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] <mup> PR #7958: snap-bootstrap: refactor partition creation <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7958>
[11:38] <cmatsuoka> mborzecki: thanks, checking...
[11:39] <mvo> 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] <zyga> ttyl
[11:41] <cmatsuoka> mborzecki: it's good, thanks for resolving the conflict
[11:42] <mborzecki> cmatsuoka: cool, hope the travis job will be green :)
[11:53] <mup> PR snapd#7953 closed: tests: use new snapd.spread-tests-run-mode-tweaks.service unit <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7953>
[12:06] <zyga> back
[12:35] <mup> PR snapd#7966 opened: tests: first core20 test fixes <Created by mvo5> <https://github.com/snapcore/snapd/pull/7966>
[12:35] <cachio> Saviq, hey
[12:36] <cachio> I am trying to create some snaps with base: core20
[12:36] <cachio> and I am getting this error related to multipass
[12:36] <cachio> launch failed: Unable to find an image matching "core20"
[12:36] <Saviq> cachio: there wasn't a build environment for them last year ;)
[12:36] <cachio> any idea about when that image will be published or if is there any workaround for that?
[12:37] <cachio> ll
[12:37] <cachio> Saviq, any idea when it should be ready?
[12:38] <Saviq> sergiusens: got any pointers for cachio ^? Is there an image yet that we could hook up to core20 builds?
[12:39] <Saviq> cachio: you could try launching daily:20.04 named snapcraft-<yourproject>, but there's some setup you might need
[12:39] <Saviq> That, or upgrade the one snapcraft launches for you
[12:39] <cachio> Saviq, ok, I'll try that, thanks!!
[12:40] <mborzecki> cachio: hi, do we have regular updates of centos spread images?
[12:41] <cachio> mborzecki, yes
[12:41] <cachio> weekly
[12:41] <cachio> mborzecki, this is the last one 2 days ago
[12:41] <cachio> https://travis-ci.org/snapcore/spread-cron/builds/633276566
[12:44] <mborzecki> cachio: thanks, i was hoping some updates for systemd landed, but apaprently not
[12:45] <cachio> mborzecki, long time waiting for that landing :(
[12:47] <sergiusens> cachio: Saviq build-base is what you could use
[12:47] <Saviq> sergiusens: but that would only accept "core18" and "core16", right?
[12:48] <Saviq> I'm thinking we could have a Multipass branch that does have "snapcraft:core20"
[12:48] <sergiusens> Saviq: yes, but even if you provide a core20 base quickly for multipass our plugins would need to gain support for core20
[12:49] <sergiusens> Saviq: which is a task I am going to start next Monday
[12:50] <Saviq> sergiusens: ack, let me know if we can help
[12:50] <Saviq> I'll bake a Multipass that has a core20 pointing somewhere sane-ish
[12:51] <sergiusens> 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] <Saviq> sergiusens: yeah but it would suggest it's something real, which it's not atm :)
[13:05] <pedronis> mvo: when #7939 is green it can be landed, reminder about #7947 needing a pass from you
[13:06] <mup> PR #7939: boot,o/devicestate: refactor MarkBootSuccessful over bootState <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7939>
[13:06] <mup> PR #7947: boot/many: support new UC20 style kernel extraction <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7947>
[13:09] <sdhd-sascha> somewhere, i had a patch for meson and core20. Don't know why i have closed the PR 2797
[13:09] <mup> PR #2797: tests: stop tying setting up staging store access to the setup of the state tarball <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2797>
[13:10] <sdhd-sascha> 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] <sdhd-sascha> i found my private changes - but i there is sure some refactor needed https://github.com/snapcore/snapcraft/pull/2854/commits
[13:21] <mup> PR snapcraft#2854: Core20 <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2854>
[13:21] <mup> PR snapcraft#2854 opened: Core20 <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2854>
[13:24] <mup> PR snapd#7958 closed: snap-bootstrap: refactor partition creation <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7958>
[13:25] <sdhd-sascha> zyga: "fires spread" - i didn't understand the context
[13:26] <zyga> niemeyer: hey, I'm sorry I haven't pinged you yet - still working on uid/gid bug
[13:26] <zyga> niemeyer: not sure how your day looks like with regards to meetings, I'll have the standup in half an hour
[13:27] <zyga> 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] <zyga> sdhd-sascha: as in run spread tests
[13:27] <zyga> sdhd-sascha: I'm chasing an annoying fix that takes some time to code right
[13:28] <sdhd-sascha> 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] <zyga> 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] <sdhd-sascha> 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] <zyga> sdhd-sascha: my recommendation would be to start with small test that you can run via spread
[13:32] <zyga> sdhd-sascha: even if that test needs to pull snaps from the store or from other places
[13:33] <zyga> sdhd-sascha: this allows you to have some kind of reproducibility
[13:33] <zyga> sdhd-sascha: so you can be more sure about changes than "it worked on my $complex_local_setup yesterday"
[13:34] <sdhd-sascha> yes
[13:39] <zyga> brb, so cold, need to get something warm
[13:39] <zyga> see you at the standup
[13:55] <ijohnson> morning folks
[13:55] <zyga> hey Ian, how are you doing!
[13:56] <zyga> I miss snow, did you get any this winter?
[14:01] <niemeyer> zyga: I should be free around 4 UTC
[14:12] <mup> PR snapd#7967 opened: overlord/snapstate: improve snapd snap backend link unit tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7967>
[14:20] <mborzecki> cachio: do you have a debug shell to a node with arch image by any chance?
[14:24] <abeato> 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] <mup> PR snapcraft#2855 opened: project: remove unused errors <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2855>
[14:30] <sdhd-sascha> 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] <mup> PR CanonicalLtd/ubuntu-image#182: rootfs: sync before measure size <Created by sd-hd> <https://github.com/CanonicalLtd/ubuntu-image/pull/182>
[14:31] <cachio> mborzecki, no
[14:32] <cachio> mborzecki, this is the erro https://travis-ci.org/snapcore/spread-cron/builds/633276548#L1446
[14:33] <mup> PR snapcraft#2855 closed: project: remove unused errors <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2855>
[14:34] <mborzecki> 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] <zyga> cachio: please ping me later about that machine state checker from before the break
[14:36] <Chipaca> mvo, degville: https://forum.snapcraft.io/t/behaviour-change-sticky-and-default-tracks/14970
[14:36] <zyga> 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] <cachio> zyga, sure
[14:36] <mborzecki> 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] <mup> PR snapcraft#2852 closed: wstool: don't rely on host git <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2852>
[14:37] <pedronis> 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] <cachio> 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] <cachio> mborzecki, could be caused by pacman-key --populate ??
[14:39] <mup> PR snapcraft#2842 closed: rust: add support for workspaces <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2842>
[14:42] <mup> PR snapcraft#2845 closed: remote-build: configurable timeout/deadline for starting and monitoring build <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2845>
[14:45] <mup> PR snapcraft#2767 closed: rust plugin: add rustup profile <Created by dalance> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2767>
[14:50] <mborzecki> cachio: hm i've never used it
[14:50] <mborzecki> cachio: what's the starting image that you use?
[14:50] <cachio> mborzecki, an old one
[14:50] <cachio> mborzecki, it is called arch-linux-64-base
[14:51] <cachio> mborzecki, I update it every 6 months aprox
[14:51] <mborzecki> cachio: ok, so the keys that are there may have expired
[14:52] <cachio> mborzecki, ok, I'll update the base image and try again
[14:53] <mborzecki> cachio: reading the manpage, --populate reloads the keys from keyring, but if those are expired, you still end up with outdated keys?
[14:53] <mvo> pedronis: uh, indeed
[14:53] <cachio> mborzecki, ah
[14:54] <mborzecki> cachio: could use just use the current image as base and update that to become the next snapshot?
[14:54] <cachio> mborzecki, well, I try to dont do it  because our current image has a lot a packages installed
[14:55] <cachio> I think best solution is to update weekly the base image
[14:55] <cachio> does it make sense?
[14:57] <cachio> currently we are updating the images using the bases
[14:57] <cachio> so, perhaps we should update the base image and then the test image
[14:58] <cachio> using the already updated image
[14:58] <cachio> the scripts that update the base images just make update/upgrade and reboot
[14:59] <cachio> the scripts that update hte test images so the same + creation ¿/deletion of users, management of service, etc
[14:59] <cachio> and install packages for snapd testing as well
[15:01] <cachio> mborzecki, the errror happens when we do this pacman -Suq --needed --noconfirm git jq python2 unzip wget
[15:01] <mborzecki> cachio: yeah, we should probably the base image and then the spread one using the new base
[15:02] <cachio> those are dependencies that we have for spread image project to run the scripts
[15:04] <cachio> mborzecki, I'll skipped those to see if it works
[15:05] <cachio> mborzecki, I am going to pick my daugther, I'll be back in 20 mins
[15:08]  * cachio afk
[15:08] <Chipaca> mvo: should we revert the 'known' change, then?
[15:08] <Chipaca> mvo: for .43 i mean
[15:09] <mborzecki> cachio: got it to work
[15:12] <mvo> Chipaca: yeah, I think that is sensible
[15:14] <mborzecki> cachio:  https://github.com/snapcore/spread-images/pull/24
[15:14] <mup> PR spread-images#24: tasks/google/update-arch-linux: update archlinux-keyring before other packages <Created by bboozzoo> <https://github.com/snapcore/spread-images/pull/24>
[15:32] <pedronis> 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] <Chipaca> pedronis: it does say TBC fwiw
[15:36] <pedronis> 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] <Chipaca> pedronis: ah
[15:38] <Chipaca> pedronis: it's useful if somebody wants to play with it
[15:39] <pedronis> Chipaca: anyway I clarified what will happen atm if they do that
[15:40] <Chipaca> you really didn't :) but now that you gave me extra context i understand what you meant
[15:42] <pedronis> Chipaca: feel free to incorporate my comment expanded at the top or something then
[15:43] <pedronis> 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] <pedronis> zyga: mvo: I got weird failures here: https://api.travis-ci.org/v3/job/634225161/log.txt
[15:47] <zyga> looking
[15:48] <zyga> aha, I saw this like around 5 times maybe in total
[15:48] <zyga> I was never able to reproduce this with a shell
[15:48] <zyga> 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] <zyga> maybe just after we install snapd the profiles are not really ready yet
[15:49] <zyga> but the service is up
[15:49] <zyga> as in systemd thinks we are good
[15:49] <zyga> so we install a snap and that explodes
[15:49] <zyga> would be good to check if the first-setup we is done before or after systemd considers us to be up
[15:50] <ijohnson> 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] <ijohnson> s to see what the issue was with that
[15:50] <zyga> because if it is after then this is clearly racy in that regard
[15:50] <zyga> to be precise: the setup of the snap-confine profile happens as a side effect of getting core/snapd snaps
[15:51] <zyga> and snap-confine actively checks if it has a profile, this is the failure that was printed here:
[15:51] <zyga> + lxd.lxc exec my-ubuntu -- su -c '/snap/bin/test-snapd-sh.sh -c '\''echo from-the-inside'\''' ubuntu
[15:51] <zyga> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[15:53] <pedronis> zyga: we are up for systemd before we do various things
[15:53] <zyga> I see
[15:53] <zyga> hmm, that's not great
[15:53] <zyga> but it seems that there's a 2nd depth to explore here
[15:53] <zyga> because why would snap-confine from core execute
[15:53] <zyga> when snap-confine is not set up yet?
[15:53] <zyga> perhaps we do the switch over incorrectly
[16:06] <mvo> pedronis: hm, that log does not even download for me :/
[16:06] <zyga> mvo: I still have it in my browser
[16:06] <zyga> I can probably copy paste it
[16:11] <mvo> zyga: would be nice if you could paste relevant bits, it loads only until something like 2020-01-08 16:11:20 Executing google:ubuntu-16.04-32:tests/main/snap-run-hook:reexec1 (810/3347)... for me
[16:12] <zyga> sure
[16:12] <zyga> the lxd failure is
[16:13] <zyga> https://pastebin.ubuntu.com/p/C5Vp8N6zMR/
[16:13] <zyga> then the failover test
[16:13] <zyga> https://pastebin.ubuntu.com/p/bR5pfQDxgK/
[16:14] <zyga> there's one more failure but it looks like regular journal error
[16:14] <zyga> I need to take a break now
[16:15] <zyga> see you around chaps
[16:18] <niemeyer> zyga: How're things going there?
[16:28] <mup> PR snapd#7957 closed: snap-bootstrap: mount the correct snapd snap to /run/mnt/snapd <UC20> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7957>
[16:31] <mup> PR core20#19 closed: static: add /etc/environment to writable-paths <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/19>
[16:33] <mup> PR snapd#7939 closed: boot,o/devicestate: refactor MarkBootSuccessful over bootState <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7939>
[16:35] <zyga> niemeyer: Hey, I can have a quick call, just making coffee
[16:35] <niemeyer> zyga: https://meet.google.com/nej-iory-rpy
[16:40] <pedronis> ijohnson: mvo: #7940 is ready for review
[16:40] <mup> PR #7940: boot: implement SetNextBoot in terms of bootState.setNext <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7940>
[16:45] <ijohnson> pedronis: ack
[16:49] <mvo> pedronis: thanks, in a meetng right now, I will try to look at it
[16:50] <pedronis> mvo: please if you have time do first Ian's one
[16:51]  * mvo nods
[16:51] <pstolowski> pedronis: hey, i've made 2nd pass over #7934, would love to land it, a few small remarks
[16:52] <mup> PR #7934: o/ifacestate,o/devicestatate: merge gadget-connect logic into auto-connect <Created by pedronis> <https://github.com/snapcore/snapd/pull/7934>
[16:52] <pedronis> pstolowski: thx, I will look in my morning
[16:57] <pedronis> it might be time to start a new standup document, it's using 0.5G here
[16:57] <pstolowski> heh, +1
[17:11] <ijohnson> mvo: pedronis: having just finished a review of #7940, I think I'm ready to start working on uc20 implementation of all that, matching what's been done for uc16, is that okay?
[17:11] <mup> PR #7940: boot: implement SetNextBoot in terms of bootState.setNext <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7940>
[17:17] <ijohnson> on that topic, it feels like in bootStateFor we may need to know the model to tell if it's a grade unset model in order to figure out we should use the (as of yet non-existent) bootState20, is that logical ?
[17:17] <mvo> ijohnson: sounds good to me
[17:18] <zyga> niemeyer: summarized as https://github.com/snapcore/snapd/pull/7728#issuecomment-572169180
[17:18] <mup> PR #7728: cmd: implement snap run --explain <Created by zyga> <https://github.com/snapcore/snapd/pull/7728>
[17:18] <zyga> niemeyer: thank you again :)
[17:18] <mvo> cachio: I uploaded a new systemd to focal and fixed the /etc/environment not writable, so hopefully a bunch of less failures with tomorrows uc20 core edge update
[17:28] <pedronis> ijohnson: yes, that's what my proposal mentions as adding a HasModeenv to boot.Device
[17:28] <ijohnson> pedronis: ah okay sorry I had forgotten about that proposal
[17:28] <ijohnson> sounds good!
[17:29] <pedronis> ijohnson: to be clear that can be implemented in terms of checking the model
[17:29] <ijohnson> right
[17:30] <pedronis> zyga: the plan to have a structured output api sounds good
[17:30] <zyga> I agree
[17:32] <pedronis> ijohnson: that will be implemented in devicestate/devicectx.go in the end
[17:32] <pedronis> plus a few test places
[17:32] <ijohnson> pedronis: yep that makes a lot of sense
[17:32] <ijohnson> will work on that after I finish up the tests for my kernel extraction PR
[17:33] <pedronis> ijohnson: great
[17:35] <pedronis> ijohnson: I answered mvo wonderined in your kernel PR, which relates to this work as well
[17:35] <pedronis> *wondering
[17:38] <ijohnson> pedronis: ah right I hadn't seen that mvo had reviewed the PR yet (thanks mvo!)
[17:39] <ijohnson> also I am going to merge in master to this PR since the uc20 spread tests are in master now so we have those tests too
[17:45] <cachio> mvo, nice, just saw the message
[17:50] <pedronis> ijohnson: yes, good idea. I added another comment there about the work
[17:56] <ijohnson> yes that's a good point, thanks
[18:03] <pedronis> ijohnson|lunch: we might not need though, because try-kernel is really relevant if try status is set
[18:03] <pedronis> we might just force disable things in some cases to cleanup
[18:03] <pedronis> but not sure
[18:04] <ijohnson|lunch> pedronis: I'll find out soon enough I think
[18:04] <pedronis> ijohnson|lunch: yes :)
[18:27]  * zyga made more progress and EODs
[19:16] <mup> PR snapcraft#2840 closed: plugs: plugs can have no element <Created by sd-hd> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2840>
[19:16] <mup> PR snapcraft#2853 closed: meta: do not set snapcraft-runner when adapter is "none" <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2853>
[19:20] <sdhd-sascha> sergiusens: hey, i come back later, and fix the comments about "core20"
[19:21] <pedronis> ijohnson: thinking a bit about the discussion in your kernel branch about the symlinks, it might be better if setNext in my PR taks a snap.PlaceInfo
[19:22] <mup> PR snapcraft#2856 opened: meta: convert Application's `adapter` from string to enum <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2856>
[19:23] <ijohnson> pedronis: hmm
[19:24] <pedronis> ijohnson: because that's what we use in the bootloader interfaces to refer to snaps
[19:25] <ijohnson> yes that makes sense now that I think about it
[19:25] <ijohnson> cause right now it's just a string
[19:25] <ijohnson> but it would be more meaningful as a snap.PlaceInfo
[19:25] <pedronis> ijohnson: yes, it can be parsed, but it's awkward
[19:25] <pedronis> and it's easy to get back that string
[19:25] <ijohnson> right
[19:25] <pedronis> if it's what is needed
[19:26] <pedronis> to be clear we didn't so far but if added some method to get the revision from PlaceInfo
[19:26] <pedronis> we could stop needing boot.NameAndRevision
[19:26] <pedronis> I'm tempted to finally do that, but that's not really an immediate concern
[19:26] <pedronis> but it's related
[19:27] <pedronis> ijohnson: I'm going to push the setNext change to my PR together with the comment fixes
[19:28] <ijohnson> pedronis: ok
[19:28] <pedronis> in a little bit
[19:28] <ijohnson> yeah I think it would be nice if we could use PlaceInfo instead of NameAndRevision, but looking at that interface it's a bit heavy for what we need in boot I think
[19:28] <ijohnson> maybe that's ok
[19:29] <pedronis> ijohnson: boot is taking it as input anyway
[19:29] <pedronis> and it's easy to make instances
[19:29] <ijohnson> right I was just thinking about places where we would need to construct a PlaceInfo in boot
[19:29] <ijohnson> perhaps it's not a big deal
[19:30] <ijohnson> ah well if it's easy enough to create a PlaceInfo instance then nvm
[19:30]  * ijohnson doesn't remember that code
[19:30] <pedronis> ijohnson: there's snap.MinimalPlaceInfo
[19:30] <pedronis> not any harder to make than NameAndRevision
[19:30] <pedronis> same input
[19:30] <ijohnson> ahhh perfect
[19:30] <pedronis> import wise nothing changes
[19:31] <ijohnson> if I had scrolled down from the file I literally had open I would have saw that :-)
[19:31] <pedronis> np, it's not used a lot to be fair
[19:31] <pedronis> ijohnson: the original purpose of PlaceInfo is mostly for remove-like operation in which we wanted to make sure we didn't assume we could get a lot of info on the snap
[19:32] <pedronis> because it might be broken to start with
[19:32] <ijohnson> I see
[19:35] <pedronis> ijohnson: if you are interested, that's why some methods in snapstate managerBackend interface take PlaceInfo vs Info
[19:35] <ijohnson> ijohnson: that makes sense
[19:35] <ijohnson> err
[19:35] <ijohnson> pedronis: that makes sense
[19:36] <pedronis> ijohnson: anyway a bit of context is probably useful now that you will work with this
[19:36] <ijohnson> yes, very much so thanks for sharing
[19:37] <mup> PR snapcraft#2857 opened: meta: enable Snap to be fully initialized with __init__ parameters <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2857>
[19:40] <mup> PR snapcraft#2821 closed: meta: remove __dict__ usage in Snap  <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2821>
[19:49] <mup> PR snapcraft#2838 closed: add support for system-usernames <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2838>
[19:49] <mup> PR snapcraft#2858 opened: schema: add support for system-usernames <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2858>
[19:53] <pedronis> ijohnson: pushed
[19:55] <ijohnson> pedronis: k, I'll take a look in a bit, in the middle of something right now
[19:55] <pedronis> ijohnson: np
[20:46] <cachio> cmatsuoka, hey
[20:46] <cmatsuoka> cachio: hello
[20:47] <cachio> cmatsuoka, do you know if the file /boot/efi/foo.cfg should exist on core20?
[20:49] <cachio> I have a test failing because of it is trying to read it
[20:49] <cmatsuoka> cachio: like grub.cfg? I think it should be in /EFI/ubuntu, let me check here...
[20:49] <cmatsuoka> ah, you mean literally foo.cfg?
[20:49] <cmatsuoka> maybe some test is creating it?
[20:50] <cachio> cmatsuoka, yes, the test is
[20:50] <cachio> gadget-update-pc
[20:50] <cachio> and it should leave that file
[20:50] <cachio> but is not doing that
[20:50] <cmatsuoka> hmm, let me check here...
[20:53] <cmatsuoka> cmatsuoka: I think we can leave this disabled until we check with mborzecki tomorrow
[20:53] <cmatsuoka> cachio: I think we can leave this disabled until we check with mborzecki tomorrow
[20:53] <cachio> ok
[20:53] <cachio> np
[20:54] <cachio> cmatsuoka, any idea why the file /var/lib/snapd/seed/seed.yaml does not exist on core20?
[20:54] <cachio> it is braking another test
[20:57] <cmatsuoka> there are things that are different there, I don't remember if this specific file should be there or not
[20:57]  * cmatsuoka checks the docs
[21:06] <cachio> ijohnson, hey
[21:06] <cachio> the netplan test is failing on core20
[21:06] <cachio> https://paste.ubuntu.com/p/fTcVRFPqdT/
[21:06] <cachio> the test is ubuntu-core-netplan
[21:06] <cachio> I have a debug session open if you want to take a look
[21:22] <cmatsuoka> cachio: yep, the structure is different
[21:23] <cachio> cmatsuoka, right
[21:23] <cmatsuoka> cachio: maybe you can check for something in /var/lib/snapd/seed/systems?
[21:24] <cachio> snap repair is failing because of this
[21:24] <cmatsuoka> cachio: hm, I think we can check this with mvo tomorrow
[21:24] <ijohnson> cachio: hey
[21:25] <cachio> cmatsuoka, yes
[21:25] <ijohnson> sorry I missed your ping
[21:25] <ijohnson> let me look
[21:25] <cachio> I'll leave a note in the doc with the details
[21:26] <cachio> ijohnson, do you want the credentials?
[21:27] <ijohnson> cachio: I'm kinda in the middle of working on other uc20 stuff, so I don't have the time to look into this, but I will look into it tomorrow
[21:27] <ijohnson> cachio: but out of curiosity are other dbus tests passing on uc20?
[21:27] <cachio> ijohnson, yes
[21:27] <cachio> many of tehm
[21:27] <cachio> them
[21:27] <ijohnson> cachio: that error message is from dbus and not specific to netplan (though the netplan test might have broken somehow)
[21:28] <ijohnson> cachio: okay that's what I would have thought from this error message
[21:28] <ijohnson> cachio: please just leave a note in the SU and I will look tomorrow if nobody else beats me in their AM
[21:28] <ijohnson> thanks
[21:28] <cachio> ijohnson, sure, thanks!!!
[21:31] <ijohnson> cachio: thanks
[23:02] <mup> PR snapcraft#2859 opened: meson plugin: add support for core20 <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2859>