[06:03] morning [06:09] o/ [06:11] PR snapd#8809 opened: tests: fix and trim debug section in xdg-open-portal [06:18] some weird failures related to snap-mgmt script [06:18] chasing one now [06:21] PR snapd#8799 closed: interfaces/system-packages-doc: fix typo in variable names [06:21] PR snapd#8805 closed: tests: port interfaces-calendar-service to tests.session [06:21] PR snapd#8806 closed: tests: install/run the lzo test snap too [06:22] hey mvo [06:22] mvo: note: please don't merge the retry PR as it needs updates now [06:24] zyga: mvo: hey [06:25] zyga: hey [06:26] zyga: can you mark it blocked please? [06:26] mborzecki: good morning [06:26] ok [06:26] PR snapd#8792 closed: interfaces: miscellanious policy updates xlv [06:26] PR snapd#8793 closed: interfaces: miscellanious policy updates xlv - 2.45 [06:26] wow, 74 PRs, it was lower 60s yesterday [06:31] PR snapd#8788 closed: cmd/snap-confine: add support for libc6-lse [06:31] PR snapd#8801 closed: vendor: update to latest github.com/snapcore/bolt for riscv64 [06:33] + snap install --channel=edge core20 [06:33] error: too early for operation, device not yet seeded or device model not acknowledged [06:33] this is from https://github.com/snapcore/snapd/pull/8798/checks?check_run_id=734681152 [06:33] PR #8798: data/selinux: allow checking /var/cache/app-info [06:33] missing wait in our code somewhere? [06:33] mborzecki: 8798 has some failures in centos, looks like related to the diff? [06:33] zyga: yes, apaprently the centos 7 policy is quite old [06:34] well entirely unexpected, but it's missing the interface, hope it has the right types at least [07:12] PR snapd#8778 closed: tests: modernize and use snapd.tool [07:19] zyga: heh, so there's something about optional_policy() i don't understand, maybe #fedora-selinux folks can help [07:20] zyga: hi, you could also add a retry-tool symlink to 8796 with no spread and land it, and do another one to fix the other tests and remove the symlink later [07:20] pedronis: good idea, I'll do that [07:24] hmm, it is really hard to get the available disk space from a snap on core ... seems /writable is nowhere to be seen from inside the snap [07:25] and the size of /var/lib/snapd/hostfs is the size of / ... which is the core snap [07:25] ogra: I replied to something similar from a customer before, one simple way is to check the size of $SNAP_DATA and $SNAP_USER_DATA [07:25] as in statfs [07:25] oh, i actually remember that discussion, hah [07:25] thanks !! [07:26] root@pi4πŸ˜•home/ogra# df -h $SNAP_DATA [07:26] Filesystem Size Used Avail Use% Mounted on [07:26] /dev/sda1 458G 68G 367G 16% /var/snap [07:26] yeah, that works fine [07:28] (looks like hexchats emoji pligun needs fixing too ...) [07:28] *plugin [07:35] hmmm [07:35] curious failures [07:37] https://www.irccloud.com/pastebin/WxFz0F8w/ [07:37] I've seen this many times today [07:37] must be something recently introduced [07:38] hmm hmm h [07:43] would be good to know what is in there that makes it non-empty [07:43] it would give us a clue [07:44] what system is that on? [07:51] didn't we have a find/ls -l /var/lib/snapd/ in the spread.yaml level debug section? [07:53] not atm afaict [07:57] pedronis: it seems it was one of the first things this test did [07:57] it was still preparing the suite [07:57] I'll add a debug section to this [07:57] back from random power failure on x240 :( [07:58] I tried reproducing it with seed but failed twice [07:58] so it may not be test related but another kind of race that is just inside the system [08:00] .... and I know that holding my x240 close to the right side of the hinge shuts it down instantly [08:01] some cable is getting pinched? [08:01] not the best moment for this [08:12] PR snapd#8809 closed: tests: fix and trim debug section in xdg-open-portal [08:37] PR snapd#8810 opened: spread.yaml: show /var/lib/snapd in debug [08:38] no luck reproducing locally, I opened a PR to see if that has more luck [08:46] huh [08:46] we're not lucky today [08:46] check out this *unit test* failure [08:46] FAIL: cmd_export_key_test.go:60: SnapKeysSuite.TestExportKeyAccount [08:46] cmd_export_key_test.go:65: [08:46] c.Assert(err, IsNil) [08:46] ... value *errors.errorString = &errors.errorString{s:"/usr/bin/gpg2 --batch --list-secret-keys --fingerprint --with-colons --fixed-list-mode failed: exit status 2 (\"gpg: starting migration from earlier GnuPG versions\\ngpg: can't connect to the agent: IPC connect call failed\\ngpg: error: GnuPG agent unusable. Please check that a GnuPG agent can be started.\\ngpg: migration aborted\\n\")"} ("/usr/bin/gpg2 --batch [08:46] --list-secret-keys --fingerprint --with-colons --fixed-list-mode failed: exit status 2 (\"gpg: starting migration from earlier GnuPG versions\\ngpg: can't connect to the agent: IPC connect call failed\\ngpg: error: GnuPG agent unusable. Please check that a GnuPG agent can be started.\\ngpg: migration aborted\\n\")") [08:47] perhaps we should do something about ~/.gnupg in github actions startup [08:48] or perhaps we should mock gpg entirely and only test it in spread tests [08:48] mvo, pedronis: ^ any preference? [08:50] zyga: in a meeting [08:57] PR snapd#8796 closed: tests: modernize retry tool [08:59] hmmm [08:59] "too early for operation" *after* waiting for seeding https://www.irccloud.com/pastebin/faUH8YSh/ [09:01] zyga: don't we have code to make sure we shutdown the agent? [09:02] pedronis: this is during the go test ./... phase in github action itself, not in spread [09:02] pedronis: it seems the image we are running on top of, needs to perform the migration [09:03] (2nd topic: this failure occurred in prepare.sh:664 [09:03] which is weird, because there's clearly a "snap wait system seed.loaded" above [09:07] zyga: I see, sounds like we need to wait for something gpg related then in the action. I think we have code in the spread stuff related to that [09:07] pedronis: I'll look around [09:07] pedronis: the wait thing is more mysterious, it suggests there's a bug in snapd [09:28] pstolowski: seems there's a real unit test error on 14.04 in core 20 defaults PR [09:29] pedronis: looking [09:31] hmm interesting [09:31] will investigate in a sec [09:32] PR snapd#8795 closed: cmd/snap-bootstrap/initramfs-mounts: also copy systemd clock + netplan files [09:32] PR snapd#8797 closed: snap/naming: add helpers to parse app and hook security tags [09:32] PR snapd#8807 closed: Revert "Enable riscv64 builds in the edge PPA without PIE" [09:32] thanks mvo! [09:34] I will have more cgroup patches shortly === joc_ is now known as joc [10:12] pstolowski: the preseed-lxd test has a small bug, I'll send a patch shortly [10:13] ehh, selinux is so arcane [10:13] zyga: thanks [10:13] 2h+ of fighting with selinux policy, optional_policy(), ifndef(), m4 and make [10:15] #8798 is a trivial fix but making it work on all distros we built it on, with the limitations of how kernel policy files are compiles is a pita [10:15] PR #8798: data/selinux: allow checking /var/cache/app-info [10:18] pstolowski: https://github.com/snapcore/snapd/pull/8811 [10:18] PR #8811: tests: autoremove after removing lxd in preseed-lxd test [10:18] * zyga break, need to try to move a little [10:20] zyga: thank you! i think i saw this once when working on this test and running entire testsuite, then it couldn't reproduce [10:22] PR snapd#8811 opened: tests: autoremove after removing lxd in preseed-lxd test [10:26] pedronis: pushed a fix to #8567, it was missing mocking for systemctl [10:26] PR #8567: o/devicestate: core20 early config from gadget defaults [10:30] so what's the policy of adding snaps under tests/lib/snaps vs under the test directory? [10:30] there's test-snapd-sh in tests/lib/snaps and another one under tests/main/interfaces-appstream-metadata [10:32] oh and there's one in the store too [10:33] mborzecki: IIRC the current preference is to not share snaps if they are really specific to a test [10:33] you can create a shared snap if you think it makes sense to do so [10:33] sharing snaps is problematic because we had a pattern of sharing and then changing the snap [10:33] that had unexpected consequences [10:34] I have a feeling we could unshare an number of snaps [10:34] and then be left with a small pool of really shared snaps [10:34] that have well defined semantics [10:37] likely yes, but probably not a good time for that change, we don't have even a good story how we mantain those snaps [10:40] interesting, there's also a subset that is in the store [10:40] that are there for assertions [10:40] yeah, it's a bit messy, my recommendation is not to make it worse :) [10:42] mvo: question on https://github.com/snapcore/snapd/pull/8804#discussion_r435155159 [10:42] PR #8804: tests: port xdg-settings test to tests.session [10:45] zyga: replied [10:53] PR snapd#8785 closed: sandbox/cgroup: move FreezerCgroupDir from dirs.go [10:53] PR snapd#8790 closed: tests: update the file used to detect the boot path on uc20 [10:53] PR snapd#8810 closed: spread.yaml: show /var/lib/snapd in debug [10:53] thanks! [10:53] please alert me if tests fail on dpkg [10:53] we might find out what was there now [11:01] heh, shellcheck complains about tests/main/lxd https://paste.ubuntu.com/p/6pzGfwKC2n/ [11:08] mvo: zyga: i've updated https://github.com/snapcore/snapd/pull/8798 since you reviewed it before, please take another look [11:08] PR #8798: data/selinux: allow checking /var/cache/app-info [11:08] sure [11:09] ta [11:09] it'd still be nice to get it into 2.45.1 [11:10] ok, back to review [11:10] mborzecki: do you need the optional_policy now that you have the ifdef? [11:10] zyga: in theory it's nth [11:11] ? [11:11] nice to have, i should probably take a look at other interface uses and wrap them as well [11:12] mborzecki: what is the rename? github truncates things [11:12] ah, I see it in a tooltip [11:13] test-snapd-sh -> test-snapd-appstream-metadata [11:14] Could you update the snap to have less apps and the "sh" app actually holds the interface you want [11:14] otherwise it's a bit weird [11:14] or is it the only app there? [11:14] it's kind of verbose for no good reason saying the same thing twice [11:15] like test-snapd-apptream-metadata.sh? [11:15] yeah [11:15] personal preference, if you like it [11:17] ok, I need to take a break [11:17] try to move around a little [11:17] Eighth_Doctor: about the label https://paste.ubuntu.com/p/ZyzpPrZDHx/ unless it's owned by multiple packages, but not sure to make rpm query to show that [11:17] next up more cgroup branches [11:17] please remember to merge master and report test failures [11:17] mborzecki: rpm -qf /var/cache/app-info [11:18] if claudio asks: I did *not* deploy spread upgrade yet, because we had a backlog of tests to run through and I wanted to avoid interruptions, since everything is back to normal now I will do it tonight [11:18] offhand, appstream and PackageKit own that too [11:18] Eighth_Doctor: it shown only packagekit, [11:18] and actually... fwupd does not own that directory [11:18] ugh [11:18] I love SELinux, but god damn it [11:18] hahah [11:18] heheh [11:19] some humor in grim days [11:19] * zyga afk [11:20] Eighth_Doctor: feels like there should be a separate label, appstream_cache_t or somesuch [11:20] yes [11:20] Eighth_Doctor: also, the file contexts are defined in fwupd policy module :P [11:20] GAAH [11:21] that's definitely a bug [11:21] the label is wrong, and the ownership is broken [11:29] Eighth_Doctor: filed https://bugzilla.redhat.com/show_bug.cgi?id=1843881 [11:30] Eighth_Doctor: notice how /var/cache/fwupd inherits var_t :P [11:33] πŸ€¦β€β™‚οΈ [11:33] PR snapd#8591 closed: secboot,cmd/snap-bootstrap: add tpm sealing support to secboot [11:33] PR snapd#8812 opened: o/snapstate: service-control task handler (4/N) [11:33] yay sealing landed [11:34] wonder it'd be possible to chop #8340 into smaller bits [11:34] PR #8340: boot, snap-bootstrap: move initramfs-mounts logic to boot pkg [11:48] PR snapd#8813 opened: gadget,cmd/snap-bootstrap: move partitioning to gadget [12:23] PR snapd#8811 closed: tests: autoremove after removing lxd in preseed-lxd test === Ps1-Jack is now known as Psi-Jack [12:50] I'm seeing some network woes in gce [12:50] both on snap install/download and apt install [12:53] - Download snap "test-snapd-dbus-provider" (6) from channel "beta" (Get https://canonical-bos01.cdn.snapcraft.io/download-origin/canonical-lgw01/vnDT8UYR44P8qyBwRSiXHHCoaoq9pz9z_6.snap?token=1591286400_c8896515d76222f533efc97384292fa6e4826cc6: dial tcp 91.189.91.42:443: connect: connection timed out) [12:55] reported internally [12:55] interactively I cannot install any snap from the store, from GCE [13:12] https://github.com/snapcore/snapd/pull/7825/files is now at sub 2K additions, [13:12] PR #7825: many: use transient scope for tracking apps and hooks [13:12] I will trim it some more soon [13:21] hi everyone [13:21] i just build the core16 image use to flash some devices for test purposes [13:21] but something is wrong [13:21] snap list returns an empty list [13:22] under /var/lib/snapd/seed/snaps/ all snaps are here but they are not installed [13:22] snap warnings say that seeding failed with assertion is signed with expired public key [13:22] it says go here check it out https://forum.snapcraft.io/t/incorrect-seed-yaml-for-some-system/16341 [13:23] the mv command tells me to move the whole folder that includes snaps as well [13:23] this does not make that much sense to me [13:23] does the topic owner meant move the seed.yaml file or something [13:25] clmsy: that topic was about a bug in some seeds that were produced in development releases [13:25] how are you building your uc16 image? [13:25] the instructions there are correct [13:25] I think we need to understand what is wrong in your case [13:27] i have a kernel snap and a gadget snap based on core16 and i bundle them together with ubuntu-image tool [13:27] i can confirm this has worked multiple times before [13:28] but today i get this message: [13:28] "no matching public key "BWDE***********redacted" for signature by "canonical" [13:28] hmmm [13:28] is the key in the image? [13:28] not sure, maybe some new bug [13:28] if i try to do snap install something it says "too early for operation, device not yet seeded or device model not acknowledged" [13:29] hm [13:29] clock off ? [13:29] (does the device have an RTC ? does that have the correct time ) [13:30] maybe its time related let me double check that [13:30] expired key is pretty typical if your clock is completely off [13:31] heh [13:31] it's ironic that the message says [13:31] "too early for operation" [13:31] :D [13:33] * zyga small break [13:35] hmpf ... that store outage isnt nice ... (my PRs fail with download errors in travis) [13:35] * ogra considers a break too [13:39] haha [13:39] anyway yes you are correct [13:39] it was clock related issue [13:39] was a very new device i did not expect the date to be in 2016 [13:39] apologies [13:39] .. [13:40] heh, no problem πŸ™‚ [13:41] (i have run into that 1000s of times already ... though usually only on RTC-less devices) [13:47] same to be honest, sometimes we forget the "time" :) [13:48] mvo_, hey, in 2.45.1 is included the support for core.experimental.user-daemons right? [13:48] because it is affecting the tests for uc20 [14:01] ogra, clmsy: https://github.com/snapcore/snapd/pull/8814 [14:01] PR #8814: sanity: check for unsynchronized real time clock [14:02] <3 [14:03] hey zyga and mborzecki do you have any suggestions on how to get the machine arch on non-debian machines i.e. fedora/arch and map those to our snap arch values ? [14:03] I was using dpkg --print-architecture, but obvs that won't work on non-debian distros [14:03] PR snapd#8814 opened: sanity: check for unsynchronized real time clock <β›” Blocked> [14:05] ijohnson: fedora uses kernel names IIRC [14:05] ijohnson: uname -m [14:05] zyga: you mean just `uname -m` ? [14:05] right [14:05] ijohnson: would use that [14:05] you can map from that to debian arch names relatively easily [14:05] at least, it's a bound problem [14:06] zyga: ok that's what I was thinking of doing [14:06] zyga: do you have or know where I could find such a mapping? [14:06] I *think* we have a few implementations of that in the gree [14:06] yes :) [14:06] one sec [14:06] thank you [14:06] it's a cool find from last few weeks [14:06] it's right on your system in... [14:08] two files: /usr/share/perl5/Dpkg/Arch.pm and /usr/share/dpkg/cputable [14:08] the former has some more logic [14:08] the latter is a map that will have most instant answers [14:08] good luck :) === facundo__ is now known as facubatista [14:12] hm aren't we mapping that already somewhere? [14:12] pedronis: I think it would help if a blocked label had an accompanying comment [14:16] ijohnson: some comments in https://github.com/snapcore/snapd/pull/8340 i think we need a diagram or something to capture the whole of bootloader/initramfs/userspace snapd interaction [14:16] PR #8340: boot, snap-bootstrap: move initramfs-mounts logic to boot pkg [14:16] mborzecki: sure I can try to break it up and clarify the interaction between the interactions [14:16] zyga: my hunch is that is not great idea as is, but I don't have time to think it through or formulate it right now, I don't want it to land it why I'm not paying attention [14:16] s/why/while/ [14:17] ijohnson: i mean not for this PR, but in general, maybe when we're done with the refactor [14:17] pedronis: sure, that's fine, making such comment on the page can help when others come and look [14:18] PR snapd#8567 closed: o/devicestate: core20 early config from gadget defaults [14:21] pstolowski: ^ great! [14:21] yes.. [14:22] ijohnson: hey, do you have a moment for another look at #8780? [14:22] PR #8780: tests: core20 early defaults spread test [14:22] pstolowski: I will try to look at it in my PM today [14:26] thanks! [15:09] mvo_: bump about https://github.com/snapcore/snapd/pull/8352 -- should I close it or do you see it as something useful and worth rebasing? [15:09] PR #8352: wrappers: generate service files with EnsureDirState [WIP] [15:15] * zyga EODs and goes to the doctor [15:24] PR snapd#8352 closed: wrappers: generate service files with EnsureDirState [WIP] === ErichEickmeyer is now known as Eickmeyer [15:52] * cachio lunch === verterok` is now known as verterok === AdmWiggin is now known as tianon [16:45] back from doc [16:45] but afk due to pain [17:02] un 04 17:00:34 pi4 kernel: audit: type=1400 audit(1591290034.897:477😞 apparmor="DENIED" operation="capable" profile="/snap/snapd/7779/usr/lib/snapd/snap-confine" pid=4626 comm="snap-confine" capability=4 capname="fsetid" [17:02] hmm [17:02] thats new on my pi4 ... (freshly booted) [17:23] ogra: it isn't a new thing. it was reintroduced with snap-confine refactor [17:23] ogra: it is harmless but on my list to investigate [17:24] ok, i just had never noticed it ... and it shows up along with only two (expected) app denials ... that got my attention [17:24] well, it might be new in 2.45, but I've been seeing it for a while (we used to have it and I fixed it, but then some snap-confine changes (ie, the removal of setgid stuff) added it back [17:24] ogra: yes, thanks for bringing it up :) [17:24] the magic word was "harmless" πŸ˜‰ [17:25] i'll appily ignore it [17:30] "mostly harmless" [18:49] PR snapd#8815 opened: tests: port snap-handle-link test to tests.session === Ringtailed-Fox is now known as RingtailedFox [20:35] PR snapd#8816 opened: tests: port 2 uc20 part1 === KindTwo is now known as KindOne