[01:57] PR snapd#9956 opened: interfaces/system-observe: Allow reading /proc/zoneinfo [06:46] morning [06:55] errand, back in 1h or so [07:51] re [07:51] mvo: hey [07:52] good morning mborzecki [07:58] PR snapd#9936 closed: interfaces: remove apparmor downgrade feature [08:11] hey [08:12] pstolowski: hey [08:17] good morning pstolowski [09:05] hey, which are the limitations of the system-files interface? I have seen that I can access files in /etc with it, but not in, for instance, /usr/share [09:05] I assume this is related to mount namespaces. This is on classic, not core [09:06] So, system-files would help me access /usr/share from the core snap, but not from the classic rootfs? [09:06] is there a way to have the later? [09:10] abeato: there is always /var/lib/snapd/hostfs/... which has the actual root filesystem, if you have a clear use case [09:11] s/actual/actual host/ [09:11] pedronis, ah, nice, I did not know that exists, thanks [09:43] pedronis: hi, i rebased monitor-mode PR against pool changes [09:44] pstolowski: thx [10:04] pstolowski: I will try to look at both later today [10:05] pstolowski: though I think the point about using different groups and using the sequence-key to label that we discussed yesterday might have been the missing piece? [10:06] pedronis: no, i addressed it as well [10:06] ah, ok, so it's ready for review? except it's a bit big because prereq? [10:07] pedronis: yes [10:07] ok, thank you [10:25] pstolowski: I approved 9930, thank you, one nitpick wasn't addressed though, it needs 2nd reviews [10:29] pedronis: uh, i was sure that was the first comment i addressed yesterday.. will do. thank you! [10:29] pstolowski: it's a big PR, np [10:40] https://github.com/snapcore/snapd/pull/9938 needs 2nd reviews (it's not too too big) [10:40] PR #9938: daemon: move single snap querying and ops to api_snaps.go [10:43] looking [10:56] pedronis: i assume dropping of licenseData is in-line with any potential developments re EULAs etc? [11:02] any brave warriors here to look at #9930? [11:02] PR #9930: asserts: pool changes for validation-sets

[11:09] PR snapd#9956 closed: interfaces/system-observe: Allow reading /proc/zoneinfo [11:14] PR snapd#9950 closed: tests: fix for preseed and dbus tests on 21.04 [11:14] PR snapd#9953 closed: overlord/snapshotstate: include the last message printed by tar in the error [11:19] PR snapd#9938 closed: daemon: move single snap querying and ops to api_snaps.go [11:19] PR snapd#9951 closed: tests/regression/lp-1910456: cleanup the /snap symlink when done [11:25] mvo: i'll open a followup for 9953 in a bit [11:25] sadly bit more changes were required [11:28] mborzecki: thanks! but not super urgent, I think the change from first to last is the big winner here [11:29] mvo: actually it's needed, the matcher kept only the first line even after 9953 landed :/ [11:31] mvo: please take a look at #9957 [11:31] PR #9957: ovelord/snapshotstate: keep a few of the last line tar prints before failing [11:34] PR snapd#9957 opened: ovelord/snapshotstate: keep a few of the last line tar prints before failing [11:34] mborzecki: oh, "fun" [11:34] mborzecki: thanks for the followup [11:53] nice! [11:54] * pstolowski lunch [12:11] PR snapcraft#3448 opened: storeapi: rename SnapClientIndex to SnapAPI [12:19] mborzecki: I recommented on set-boot-vars, sorry is such a saga [12:19] pedronis: iirc no slash boot is implied for recovery [12:20] i can make it explicit though [12:20] ah, I wasn't sure if we would error if they were mixed [12:21] actually even more interesting, we have:https://github.com/snapcore/snapd/blob/master/bootloader/bootloader.go#L68 [12:21] yea, I noticed the same [12:21] we have also this though: https://github.com/snapcore/snapd/blob/master/bootloader/bootloader.go#L77 [12:22] pedronis: that would be --root-dir on a non uc20 system right? (we try to guess that by checking whethr modeenv exists) [12:22] mborzecki: yes, --root-dir on non-uc20 [12:23] we might want to give a better error instead of ending up there [12:23] but not super important [12:23] pedronis: yeah, maybe when we do a little refactor to have --recovery for boot-vars too? [12:24] ok [12:24] fwiw I wrote #L68 [12:25] but I do remember if was going to be a bit confusing either way [12:25] *it was going [12:28] hmm, can i somehow find out in a hook if i'm running in --devmode ? [12:31] ogra: hmm, cat /etc/shadow ? [12:32] maybe not that file in particular, but you get the idea ;) [12:33] yeah, i was looking for something that doesnt necessary produce errors in the journal 🙂 ... [12:34] i don't think we expose any information to the snaps on whether it was installed with --devmode, or whether strict isn't supported by the host [12:34] we don't expose it in any explicit way atm [12:36] i designed pi-fancrontrol for Core ... and it has a check if gpio is connected in teh configure hook ... now apparently more and more people run it on raspbian which has no gpio slots in --devmode ... not really hw i envisioned it to be used but i'D like to at least make it not fail hard in that constellation [12:36] PR snapcraft#3449 opened: ci: don't publish snap on push to master [13:29] PR snapd#9958 opened: tests: disable lxd tests for 21.04 until the lxd images are published for the system [13:36] PR snapcraft#3449 closed: ci: don't publish snap on push to master [14:34] cachio: do you recall if at some point the images from https://download.opensuse.org/tumbleweed/appliances/ were tried in gce? [14:35] cachio: there's a bunch of images for kvm and openstack, they are the JeOS flavor (translates to 'just enough OS'), which should be pretty minimal [14:52] hmm ... having "snapctl version" would really be handy in some situations [14:52] * ogra ponders to file a wishlist bug [14:54] mborzecki, I built the tumbleweed image [14:54] from leap [14:55] didn't try those in gce [14:57] hey degville it seems the old link to uc20 doc at https://ubuntu.com/core/docs/releases/uc20 doesn't redirect, could you look into that? [14:58] we probably shouldn't use that link going forward much, but it's still in some forum topics for example [14:58] seems the new link is https://ubuntu.com/core/docs/uc20/release-notes [14:59] ijohnson: good spot - thanks! I'll fix it now. [14:59] ah you were in the channel to see the message that made me ask you about this :-D [14:59] ETOOMANYCHANNELS [14:59] cachio: if you have some spare cycles, could you try and import https://download.opensuse.org/tumbleweed/appliances/openSUSE-Tumbleweed-JeOS.x86_64-OpenStack-Cloud.qcow2 ? [15:00] cachio: this should be a vanilla opensuse TW image [15:01] mborzecki, sure [15:01] cachio: and it uses cloud-init during boot, so that should be easy hopefully [15:01] I need to update that image to install the gce dependencies and install the give the correct format [15:03] cachio: ah, ok, i see there's cloud-netconfig-gce in the repositories, unless you need more packages [15:04] mborzecki: is 9942 ready for re-review? any other PR? [15:05] mborzecki, all the packages should be in zypper ar -f -c http://download.opensuse.org/repositories/Cloud:Tools/openSUSE_Tumbleweed/Cloud:Tools.repo [15:05] pedronis: yes, it's ready [15:11] PR snapcraft#3448 closed: storeapi: rename SnapClientIndex to SnapAPI [15:27] degville: (CC pedronis) the API systems REST doc looks good, thanks for cleaning that up, can you put it on the forum in the REST API doc ? [15:28] ijohnson: thanks! I'll do it now. [15:29] mvo: is 9907 ready for re-review? [15:32] thanks degville [15:32] pedronis: did you see my comments in the refresh spec doc about --kill to have a hook indicate it wants to refresh anyways even if there are running snaps? I don't see where my comments went in that doc, so I assume you resolved them [15:33] ijohnson: I update the corresponding open question [15:33] ah let me look again then [15:33] pedronis: I see it now thanks [16:05] PR snapd#9959 opened: o/snapstate: Update validation sets assertions with auto-refresh [16:05] does anyone have capacity to review #9930? [16:05] PR #9930: asserts: pool changes for validation-sets

[16:15] pstolowski: I will add it to my queue for today [16:15] probably in my PM though [16:16] ijohnson: thank you! [16:26] np [16:47] * cachio lunch [17:01] pedronis: re 9907> yes, I think so [17:02] pedronis: sorry for the delay, had a gazillion meetings [17:03] hello [17:03] mvo I have three patches for spread [17:03] mvo https://git.ostc-eu.org/OSTC/packaging/spread/-/tree/master/debian/patches [17:04] the 1st one is extremely simple and just removes a hard-coded root directory: https://git.ostc-eu.org/OSTC/packaging/spread/-/blob/master/debian/patches/0001-No-hard-coded-root-home-dir.patch [17:04] the 2nd and 3rd https://git.ostc-eu.org/OSTC/packaging/spread/-/blob/master/debian/patches/0002-Description-Add-support-for-busybox-tar.patch https://git.ostc-eu.org/OSTC/packaging/spread/-/blob/master/debian/patches/0003-Use-gzip-to-compress-artifacts.patch improve support for busybox [17:05] this set allows to use spread with openharmony images [17:05] mvo I'm happy to send them but I worry that there's no progress on merging a patch I've sent well over a month ago: https://github.com/snapcore/spread/pull/112 [17:05] PR spread#112: Bump base version of go to 1.13 [17:18] mvo: thanks, it's back in my queue [17:21] thanks! [17:22] zyga: let me check [17:22] mvo thanks, those are super tiny [17:22] hey pedronis :) [17:25] zyga: 0001 looks fine, the other two I guess need a bit of thinking, maybe config options about compression or something [17:25] I think xz is not so relevant but I agree that the 2nd patch may be an option somewhere [17:26] I wonder if there are any user of the artifact system currently [17:26] I'm certainly using it now and plan to depend on it [17:27] mvo I can propose all three and we can discuss things in the pull request === pfsmorigo_ is now known as pfsmorigo [17:42] PR snapcraft#3450 opened: storeapi: rename SCA to DashboardAPI [17:43] hey kenvandine :) [17:43] hey zyga === ijohnson is now known as ijohnson|lunch [19:07] PR snapcraft#3450 closed: storeapi: rename SCA to DashboardAPI === ijohnson|lunch is now known as ijohnson [20:51] PR snapd#9958 closed: tests: disable lxd tests for 21.04 until the lxd images are published for the system [21:25] thanks again for your reply amurray :-) i just replied back with some more details [21:56] PR snapd#9960 opened: tests: update permission denied message for test-snapd-event on ubuntu 2104 [23:05] I'm having trouble getting a service to start back up. I was running a Nextcloud snap and the computer froze. Upon reboot, the services are set to "enabled" but they remain "inactive." After trying to start, I see problems in the log. This one stands out: [23:05] Feb 24 17:30:09 nextcloud nextcloud.renew-certs[2711]: cannot create file nextcloud.mnt: Is a directory [23:07] reinstall nextcloud perhaps? [23:10] oerheks: Can I do this and maintain my configs and certificates? [23:10] (and data) [23:14] yes, backup the ~/snap folder to be safe, snap remove --purge nextcloud # would wipe your data too [23:34] Installing it failed. This time with a message right to the console, "cannot create file nextcloud.mnt: Is a directory" [23:34] I went looking for it, and found it in /run/snapd/ns [23:34] I can't delete it, even as root, because "Is a directory" [23:35] rm -f nextcloud.mnt [23:35] Is this the part where I do an fsck? [23:42] bandali: thanks, will follow up via the forum [23:43] thanks to you! sounds good [23:47] padge: I'd recommend starting a forum topic about this, most folks are in EU or americas timezone and thus EOD