| 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:11 |
|---|---|---|
| ijohnson | sdhd-sascha: as for what if you misspell something that's what code review is for :-) | 01:12 |
| mborzecki | morning | 06:16 |
| mborzecki | mvo: hey | 06:26 |
| mvo | mborzecki: good morning! | 06:27 |
| zyga | good morning! | 07:09 |
| 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:10 |
| 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:11 |
| zyga | updating them to current standards? | 07:12 |
| mvo | zyga: nah, just updating the uc20 test so that it gets pass the review feedback :) | 07:14 |
| zyga | I see :) | 07:15 |
| zyga | well, not anywhere less noble :D | 07:15 |
| sdhd-sascha | good morning | 07:19 |
| zyga | hey sdhd-sascha, how are you doing? | 07:22 |
| mborzecki | zyga: 'standards'? | 07:27 |
| zyga | mborzecki: some tests are really quaint | 07:27 |
| zyga | the older the more likely you would rewrite it just after looking at it | 07:28 |
| mborzecki | hah i can imagine | 07:28 |
| sdhd-sascha | zyga: i'm fine. thank you :-) Hope you, too | 07:45 |
| 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:47 |
| 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:48 |
| zyga | huh | 07:49 |
| zyga | so | 07:49 |
| 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:50 |
| 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:51 |
| mborzecki | zyga: unfortunately the rule is in the profile :/ | 07:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| zyga | interface="org.freedesktop.portal.OpenURI" | 07:59 |
| zyga | er | 07:59 |
| zyga | https://www.irccloud.com/pastebin/As3p4zI1/ | 07:59 |
| 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:00 |
| mborzecki | 19.10 | 08:02 |
| 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:04 |
| zyga | in that case I have no idea why there is a denial | 08:05 |
| pstolowski | mornings. i need to run an errand, will start for real a bit later (in ~1h) | 08:06 |
| zyga | good morning Pawel | 08:06 |
| 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:08 |
| 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:09 |
| zyga | mmmm | 08:10 |
| zyga | good hunch | 08:10 |
| 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:11 |
| 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:12 |
| 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:14 |
| jamesh | mborzecki: are the interface plugs of test-snapd-portal-client different to whatever snap you're using to call xdg-open? | 08:15 |
| mborzecki | jdstrand: nope, they're the same, only desktop plug | 08:16 |
| mborzecki | jamesh: ^^ | 08:16 |
| jamesh | mborzecki: is there any difference in the order of operations in preparing the test? | 08:17 |
| 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:19 |
| 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:20 | |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:44 |
| pstolowski | re | 08:50 |
| 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:00 |
| mborzecki | jamesh: so it looks to me that the python dbus client actually starts the service https://paste.ubuntu.com/p/42ZWnBHwxN/ | 09:04 |
| mborzecki | jamesh: looking at apparmor profile, sending org.freedesktop.DBus.StartServiceByName is allowed via included dbus-session-strict abstraction | 09:08 |
| jamesh | mborzecki: interesting. That kind of makes the whole AssumedAppArmorLabel thing a bit pointless if you can arbitrarily start services anyway | 09:10 |
| 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:19 |
| zyga | brb | 09:30 |
| zyga | re | 09:42 |
| 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:43 |
| 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:44 |
| sdhd-sascha | ok | 09:45 |
| mvo | 7953 needs a second review (and is pretty trivial now) | 09:50 |
| 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:51 |
| zyga | mvo: is that the right number? it has two +1s already | 09:52 |
| 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:53 |
| 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 | 09:54 |
| 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> | 10:20 |
| mborzecki | interesting but unrelated to 7953 https://paste.ubuntu.com/p/XG8tpZcG3s/ | 11:05 |
| zyga | mborzecki: I saw that a number of times | 11:13 |
| zyga | at random | 11:13 |
| zyga | feels like something is racy | 11:13 |
| zyga | break | 11:26 |
| mup | PR core20#19 opened: static: add /etc/environment to writable-paths <Created by mvo5> <https://github.com/snapcore/core20/pull/19> | 11:34 |
| 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:37 |
| cmatsuoka | mborzecki: thanks, checking... | 11:38 |
| 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:39 |
| cmatsuoka | mborzecki: it's good, thanks for resolving the conflict | 11:41 |
| mborzecki | cmatsuoka: cool, hope the travis job will be green :) | 11:42 |
| 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> | 11:53 |
| zyga | back | 12:06 |
| 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:35 |
| 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:36 |
| cachio | ll | 12:37 |
| cachio | Saviq, any idea when it should be ready? | 12:37 |
| Saviq | sergiusens: got any pointers for cachio ^? Is there an image yet that we could hook up to core20 builds? | 12:38 |
| 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:39 |
| mborzecki | cachio: hi, do we have regular updates of centos spread images? | 12:40 |
| 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:41 |
| mborzecki | cachio: thanks, i was hoping some updates for systemd landed, but apaprently not | 12:44 |
| cachio | mborzecki, long time waiting for that landing :( | 12:45 |
| sergiusens | cachio: Saviq build-base is what you could use | 12:47 |
| Saviq | sergiusens: but that would only accept "core18" and "core16", right? | 12:47 |
| 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:48 |
| sergiusens | Saviq: which is a task I am going to start next Monday | 12:49 |
| 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:50 |
| 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:51 |
| Saviq | sergiusens: yeah but it would suggest it's something real, which it's not atm :) | 12:52 |
| pedronis | mvo: when #7939 is green it can be landed, reminder about #7947 needing a pass from you | 13:05 |
| 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:06 |
| 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:09 |
| sdhd-sascha | i will recreate that PR. It was easy for meson to enable the plugin on core20 | 13:10 |
| * zyga fires spread, hoping to see some progress | 13:18 | |
| 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:21 |
| 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:24 |
| sdhd-sascha | zyga: "fires spread" - i didn't understand the context | 13:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:31 |
| 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:32 |
| 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:33 |
| sdhd-sascha | yes | 13:34 |
| === ricab is now known as ricab|lunch | ||
| zyga | brb, so cold, need to get something warm | 13:39 |
| zyga | see you at the standup | 13:39 |
| ijohnson | morning folks | 13:55 |
| zyga | hey Ian, how are you doing! | 13:55 |
| zyga | I miss snow, did you get any this winter? | 13:56 |
| niemeyer | zyga: I should be free around 4 UTC | 14:01 |
| 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:12 |
| mborzecki | cachio: do you have a debug shell to a node with arch image by any chance? | 14:20 |
| 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:24 |
| 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:30 |
| 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:31 |
| cachio | mborzecki, this is the erro https://travis-ci.org/snapcore/spread-cron/builds/633276548#L1446 | 14:32 |
| mup | PR snapcraft#2855 closed: project: remove unused errors <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2855> | 14:33 |
| 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:34 |
| zyga | cachio: please ping me later about that machine state checker from before the break | 14:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:42 |
| mup | PR snapcraft#2767 closed: rust plugin: add rustup profile <Created by dalance> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2767> | 14:45 |
| 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:50 |
| cachio | mborzecki, I update it every 6 months aprox | 14:51 |
| mborzecki | cachio: ok, so the keys that are there may have expired | 14:51 |
| cachio | mborzecki, ok, I'll update the base image and try again | 14:52 |
| 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:53 |
| 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:54 |
| cachio | I think best solution is to update weekly the base image | 14:55 |
| cachio | does it make sense? | 14:55 |
| 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:57 |
| cachio | using the already updated image | 14:58 |
| cachio | the scripts that update the base images just make update/upgrade and reboot | 14:58 |
| 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 | 14:59 |
| 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:01 |
| cachio | those are dependencies that we have for spread image project to run the scripts | 15:02 |
| === ricab|lunch is now known as ricab | ||
| cachio | mborzecki, I'll skipped those to see if it works | 15:04 |
| cachio | mborzecki, I am going to pick my daugther, I'll be back in 20 mins | 15:05 |
| * cachio afk | 15:08 | |
| Chipaca | mvo: should we revert the 'known' change, then? | 15:08 |
| Chipaca | mvo: for .43 i mean | 15:08 |
| mborzecki | cachio: got it to work | 15:09 |
| mvo | Chipaca: yeah, I think that is sensible | 15:12 |
| 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:14 |
| 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:32 |
| Chipaca | pedronis: it does say TBC fwiw | 15:33 |
| 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:36 |
| Chipaca | pedronis: ah | 15:37 |
| Chipaca | pedronis: it's useful if somebody wants to play with it | 15:38 |
| pedronis | Chipaca: anyway I clarified what will happen atm if they do that | 15:39 |
| Chipaca | you really didn't :) but now that you gave me extra context i understand what you meant | 15:40 |
| pedronis | Chipaca: feel free to incorporate my comment expanded at the top or something then | 15:42 |
| 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:43 |
| pedronis | zyga: mvo: I got weird failures here: https://api.travis-ci.org/v3/job/634225161/log.txt | 15:47 |
| zyga | looking | 15:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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 | 15:53 |
| 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:06 |
| 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:11 |
| zyga | sure | 16:12 |
| zyga | the lxd failure is | 16:12 |
| zyga | https://pastebin.ubuntu.com/p/C5Vp8N6zMR/ | 16:13 |
| zyga | then the failover test | 16:13 |
| zyga | https://pastebin.ubuntu.com/p/bR5pfQDxgK/ | 16:13 |
| zyga | there's one more failure but it looks like regular journal error | 16:14 |
| zyga | I need to take a break now | 16:14 |
| zyga | see you around chaps | 16:15 |
| niemeyer | zyga: How're things going there? | 16:18 |
| 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:28 |
| 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:31 |
| 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:33 |
| zyga | niemeyer: Hey, I can have a quick call, just making coffee | 16:35 |
| niemeyer | zyga: https://meet.google.com/nej-iory-rpy | 16:35 |
| 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:40 |
| ijohnson | pedronis: ack | 16:45 |
| mvo | pedronis: thanks, in a meetng right now, I will try to look at it | 16:49 |
| pedronis | mvo: please if you have time do first Ian's one | 16:50 |
| * mvo nods | 16:51 | |
| pstolowski | pedronis: hey, i've made 2nd pass over #7934, would love to land it, a few small remarks | 16:51 |
| 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:52 |
| pedronis | it might be time to start a new standup document, it's using 0.5G here | 16:57 |
| pstolowski | heh, +1 | 16:57 |
| 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:11 |
| 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:17 |
| 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:18 |
| 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:28 |
| pedronis | ijohnson: to be clear that can be implemented in terms of checking the model | 17:29 |
| ijohnson | right | 17:29 |
| pedronis | zyga: the plan to have a structured output api sounds good | 17:30 |
| zyga | I agree | 17:30 |
| 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:32 |
| pedronis | ijohnson: great | 17:33 |
| pedronis | ijohnson: I answered mvo wonderined in your kernel PR, which relates to this work as well | 17:35 |
| pedronis | *wondering | 17:35 |
| ijohnson | pedronis: ah right I hadn't seen that mvo had reviewed the PR yet (thanks mvo!) | 17:38 |
| 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:39 |
| cachio | mvo, nice, just saw the message | 17:45 |
| pedronis | ijohnson: yes, good idea. I added another comment there about the work | 17:50 |
| ijohnson | yes that's a good point, thanks | 17:56 |
| === ijohnson is now known as ijohnson|lunch | ||
| 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:03 |
| ijohnson|lunch | pedronis: I'll find out soon enough I think | 18:04 |
| pedronis | ijohnson|lunch: yes :) | 18:04 |
| * zyga made more progress and EODs | 18:27 | |
| === ijohnson|lunch is now known as ijohnson | ||
| 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:16 |
| sdhd-sascha | sergiusens: hey, i come back later, and fix the comments about "core20" | 19:20 |
| 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:21 |
| 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:22 |
| ijohnson | pedronis: hmm | 19:23 |
| pedronis | ijohnson: because that's what we use in the bootloader interfaces to refer to snaps | 19:24 |
| 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:25 |
| 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:26 |
| pedronis | ijohnson: I'm going to push the setNext change to my PR together with the comment fixes | 19:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| pedronis | because it might be broken to start with | 19:32 |
| ijohnson | I see | 19:32 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:40 |
| 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:49 |
| pedronis | ijohnson: pushed | 19:53 |
| ijohnson | pedronis: k, I'll take a look in a bit, in the middle of something right now | 19:55 |
| pedronis | ijohnson: np | 19:55 |
| cachio | cmatsuoka, hey | 20:46 |
| cmatsuoka | cachio: hello | 20:46 |
| cachio | cmatsuoka, do you know if the file /boot/efi/foo.cfg should exist on core20? | 20:47 |
| 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:49 |
| 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:50 |
| 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:53 |
| 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:54 |
| 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 | 20:57 | |
| 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:06 |
| cmatsuoka | cachio: yep, the structure is different | 21:22 |
| cachio | cmatsuoka, right | 21:23 |
| cmatsuoka | cachio: maybe you can check for something in /var/lib/snapd/seed/systems? | 21:23 |
| 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:24 |
| 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:25 |
| cachio | ijohnson, do you want the credentials? | 21:26 |
| 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:27 |
| 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:28 |
| ijohnson | cachio: thanks | 21:31 |
| mup | PR snapcraft#2859 opened: meson plugin: add support for core20 <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2859> | 23:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!