[02:33] <mup> PR core#128 opened: Handle PPAs being served from ppa.launchpadcontent.net <Created by cjwatson> <https://github.com/snapcore/core/pull/128>
[02:44] <mup> PR core18#186 opened: Handle PPAs being served from ppa.launchpadcontent.net <Created by cjwatson> <https://github.com/snapcore/core18/pull/186>
[02:44] <mup> PR core20#129 opened: Handle PPAs being served from ppa.launchpadcontent.net <Created by cjwatson> <https://github.com/snapcore/core20/pull/129>
[02:51] <mup> PR snapd#11300 opened: Handle PPAs being served from ppa.launchpadcontent.net <Created by cjwatson> <https://github.com/snapcore/snapd/pull/11300>
[06:23] <mborzecki> morning
[06:50] <mardy> mborzecki: hi!
[06:52] <mborzecki> mardy: heya
[07:21] <mardy> mborzecki: is it expected that we can restore a snapshot even if the corresponding snap is not installed?
[07:22] <mborzecki> mardy: it's just snap data, so i guess it's the same as if you remove the snap without --purge?
[07:23] <mardy> I guess not, because then it prevents the snap from being installed
[07:23] <mborzecki> heh
[07:24] <mardy> mborzecki: I'm investigating a test failure, and tried this: https://paste.ubuntu.com/p/D43P2fYYm3/
[07:24] <mborzecki> mardy: as the paths exist already?
[07:25] <mardy> or maybe the issue is different, and related to ~/snap/ vs ~/.snap/
[07:26] <mborzecki> mardy: fwiw restored snapshot with data under $SNAP_DATA does not break the install
[07:28] <mborzecki> mardy: but found another problem https://pastebin.ubuntu.com/p/HHXh3c4sGh/ or maybe that's intentional, I restored 2 snapshots here
[07:29] <mborzecki> mardy: yeah and your log suggest that it's a problem with migration
[07:29] <mardy> mborzecki: ok, ina  way that's good to know :-)
[07:30] <mardy> I'll collect some info and then ping Miguel
[08:12] <mardy> mborzecki: oh, this is interesting: the directories with the funny names (with ~) disappear after a minute or so. Not sure who removes them, there's nothing in the snapd logs.
[08:12] <mardy> so yeah, I guess we have two different issues
[08:32] <mup> PR snapd#11168 closed: tests/main/cgroup-tracking-failure: Make it pass when run alone <Created by valentindavid> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11168>
[08:37] <mup> PR snapd#11300 closed: tests: Handle PPAs being served from ppa.launchpadcontent.net <Simple 😃> <Created by cjwatson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11300>
[08:42] <mup> PR snapd#11271 closed: many: add Transactional to snapstate.Flags <Needs Samuele review> <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11271>
[08:42] <mup> PR snapd#11297 closed: gadget: rename DiskVolume...Opts to DiskVolume...Options <Simple 😃> <Skip spread> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11297>
[09:52] <mardy> miguelpires: hi! This morning I filed https://bugs.launchpad.net/snapd/+bug/1959072. I'm working to fix the test flackiness, but if you read the bug description you'll see there's also an issue with the migration, which you might want to look at
[09:52] <mup> Bug #1959072: test tests/main/hidden-snap-dir/task.yaml is flacky <snapd:In Progress by mardy> <https://launchpad.net/bugs/1959072>
[09:58] <miguelpires> mardy: I saw the flaky test briefly and opened https://github.com/snapcore/snapd/pull/11289 to ignore the test in CentOS, to avoid blocking people. I also filed a bug which includes a smaller reproducing spread test without any migration things (so I think the bug is related to snapshots and potentially CentOS, not migration)
[09:58] <miguelpires> https://bugs.launchpad.net/snapd/+bug/1959036
[09:58] <mup> Bug #1959036: "snap remove --purge" sometimes fails on CentOS <snapd:New> <https://launchpad.net/bugs/1959036>
[09:58] <mup> PR #11289: tests: skip migration test on centOS <Simple 😃> <Created by MiguelPires> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11289>
[09:58] <mup> PR snapd#11301 opened: tests: ensure the ca-certificates package is installed <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/11301>
[09:59] <miguelpires> mardy: and thanks for pointing out the copying issue, I haven't seen that one before. I'll have a look
[11:51] <zyga-mbp> hey mvo 
[11:51] <zyga-mbp> I saw your question last night but it was too late then
[12:18] <mup> PR snapd#11302 opened: exportmanager: add export manifest <Created by mvo5> <https://github.com/snapcore/snapd/pull/11302>
[12:33] <mup> PR snapd#11303 opened: overlord/servicestate: disallow mixing snaps and subgroups <Created by Meulengracht> <https://github.com/snapcore/snapd/pull/11303>
[12:49] <mup> PR snapd#11304 opened: snap/quota: add positive tests for the quota.Resources logic <Created by Meulengracht> <https://github.com/snapcore/snapd/pull/11304>
[14:28] <Guest30> Hallo zusammen ich habe ein Offline System wo ich regelmaßig einen Snap Update von Hand. Nur jetzt klappt das nicht mehr - es heißt epoch6* cant read the current epoch 3* was muss ich machen
[14:29] <zyga> Guest30, hello there
[14:30] <zyga> ogra, mvo: ^ perhaps around
[15:14] <bandali> hi all, i had two questions:
[15:14] <bandali> 1. are there any plans to fix the broken snapcraft image that's been broken for a few months now? (https://forum.snapcraft.io/t/snapcraft-docker-images-broken-again/27942)
[15:16] <bandali> 2. anyone know if it's possible to use `snapcraft remote-build` in a fully non-interactive way, e.g. from terminal or a CI pipeline? as of now, it seems i have to manually authorize each of canonical's launchpad buildmachines on every build, which is not reasonably doable in a non-interactive way
[15:59] <mup> PR snapd#11305 opened: systemd: actually test the function passed as a parameter <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/11305>
[16:00] <mborzecki> a trivial review ^^
[16:05] <mborzecki> mardy: can you take a look if you're still around? 
[16:06] <ijohnson[m]> +1d
[16:48] <mborzecki> thanks!
[16:55] <mup> PR snapd#11306 opened: many: add transactional flag to snapd API <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/11306>
[17:50] <mup> PR snapd#11307 opened: tests: skip snap-userd-reexec test when reexec is not enabled <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11307>
[18:05] <mup> PR snapd#11308 opened: asserts: start splitting out attrMatcher for reuse to constraint.go <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/11308>
[18:05] <mup> PR snapd#11309 opened: asserts: start generalizing attrMatcher <Created by pedronis> <https://github.com/snapcore/snapd/pull/11309>
[18:25] <ogra> bandali, for 2 you should perhaps ask in #launchpad ... though i think there is also a way described on the forum how to export credentials from snapcraft to a file to use it then in CI
[18:38] <bandali> ogra, thanks, i'll try there. yeah so i already do that for pushing or releasing an already-built snap, but seems like for remote-build i have to manually auth/approve for each launchpad build machine (which since there are more than 300 of them and they're randomly assigned, is not feasible)
[18:56] <gloin> API outage a known issue? I'm getting "Too Many Requests" here: https://api.snapcraft.io/api/v1/snaps/names?confinement=strict%2Cclassic
[19:15] <mup> PR snapd#11310 opened: tests: skip version check on lp-1871652 for sru validation <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11310>
[19:15] <mup> PR snapd#11311 opened: asserts: start implementing authority-delegation <Created by pedronis> <https://github.com/snapcore/snapd/pull/11311>
[19:25] <mup> PR snapd#11299 closed: tests: fix snaps-state test for sru validation <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11299>