[01:57] <mup> PR snapd#9956 opened: interfaces/system-observe: Allow reading /proc/zoneinfo <Simple 😃> <Created by alexmurray> <https://github.com/snapcore/snapd/pull/9956>
[06:46] <mborzecki> morning
[06:55] <mborzecki> errand, back in 1h or so
[07:51] <mborzecki> re
[07:51] <mborzecki> mvo: hey
[07:52] <mvo> good morning mborzecki
[07:58] <mup> PR snapd#9936 closed: interfaces: remove apparmor downgrade feature <Needs security review> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9936>
[08:11] <pstolowski> hey
[08:12] <mborzecki> pstolowski: hey
[08:17] <mvo> good morning pstolowski
[09:05] <abeato> 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] <abeato> I assume this is related to mount namespaces. This is on classic, not core
[09:06] <abeato> So, system-files would help me access /usr/share from the core snap, but not from the classic rootfs?
[09:06] <abeato> is there a way to have the later?
[09:10] <pedronis> abeato: there is always /var/lib/snapd/hostfs/... which has the actual root filesystem, if you have a clear use case
[09:11] <pedronis> s/actual/actual host/
[09:11] <abeato> pedronis, ah, nice, I did not know that exists, thanks
[09:43] <pstolowski> pedronis: hi, i rebased monitor-mode PR against pool changes
[09:44] <pedronis> pstolowski: thx
[10:04] <pedronis> pstolowski: I will try to look at both later today
[10:05] <pedronis> 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] <pstolowski> pedronis: no, i addressed it as well
[10:06] <pedronis> ah, ok, so it's ready for review? except it's a bit big because prereq?
[10:07] <pstolowski> pedronis: yes
[10:07] <pedronis> ok, thank you
[10:25] <pedronis> pstolowski: I approved 9930, thank you, one nitpick wasn't addressed though, it needs 2nd reviews
[10:29] <pstolowski> pedronis: uh, i was sure that was the first comment i addressed yesterday.. will do. thank you!
[10:29] <pedronis> pstolowski: it's a big PR, np
[10:40] <pedronis> https://github.com/snapcore/snapd/pull/9938 needs 2nd reviews (it's not too too big)
[10:40] <mup> PR #9938: daemon: move single snap querying and ops to api_snaps.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/9938>
[10:43] <pstolowski> looking
[10:56] <pstolowski> pedronis: i assume dropping of licenseData is in-line with any potential developments re EULAs etc?
[11:02] <pstolowski> any brave warriors here to look at #9930?
[11:02] <mup> PR #9930: asserts: pool changes for validation-sets <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9930>
[11:09] <mup> PR snapd#9956 closed: interfaces/system-observe: Allow reading /proc/zoneinfo <Simple 😃> <Created by alexmurray> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9956>
[11:14] <mup> PR snapd#9950 closed: tests: fix for preseed and dbus tests on 21.04 <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9950>
[11:14] <mup> PR snapd#9953 closed: overlord/snapshotstate: include the last message printed by tar in the error <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9953>
[11:19] <mup> PR snapd#9938 closed: daemon: move single snap querying and ops to api_snaps.go <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9938>
[11:19] <mup> PR snapd#9951 closed: tests/regression/lp-1910456: cleanup the /snap symlink when done  <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9951>
[11:25] <mborzecki> mvo: i'll open a followup for 9953 in a bit
[11:25] <mborzecki> sadly bit more changes were required
[11:28] <mvo> mborzecki: thanks! but not super urgent, I think the change from first to last is the big winner here
[11:29] <mborzecki> mvo: actually it's needed, the matcher kept only the first line even after 9953 landed :/
[11:31] <mborzecki> mvo: please take a look at #9957
[11:31] <mup> PR #9957: ovelord/snapshotstate: keep a few of the last line tar prints before failing <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9957>
[11:34] <mup> PR snapd#9957 opened: ovelord/snapshotstate: keep a few of the last line tar prints before failing <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9957>
[11:34] <mvo> mborzecki: oh, "fun"
[11:34] <mvo> mborzecki: thanks for the followup
[11:53] <pstolowski> nice!
[11:54]  * pstolowski lunch
[12:11] <mup> PR snapcraft#3448 opened: storeapi: rename SnapClientIndex to SnapAPI <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3448>
[12:19] <pedronis> mborzecki: I recommented on set-boot-vars, sorry is such a saga
[12:19] <mborzecki> pedronis: iirc no slash boot is implied for recovery
[12:20] <mborzecki> i can make it explicit though
[12:20] <pedronis> ah, I wasn't sure if we would error if they were mixed
[12:21] <mborzecki> actually even more interesting, we have:https://github.com/snapcore/snapd/blob/master/bootloader/bootloader.go#L68
[12:21] <pedronis> yea, I noticed the same
[12:21] <pedronis> we have also this though:  https://github.com/snapcore/snapd/blob/master/bootloader/bootloader.go#L77
[12:22] <mborzecki> pedronis: that would be --root-dir on a non uc20 system right? (we try to guess that by checking whethr modeenv exists)
[12:22] <pedronis> mborzecki: yes, --root-dir on non-uc20
[12:23] <pedronis> we might want to give a better error instead of ending up there
[12:23] <pedronis> but not super important
[12:23] <mborzecki> pedronis: yeah, maybe when we do a little refactor to have --recovery for boot-vars too?
[12:24] <pedronis> ok
[12:24] <pedronis> fwiw I wrote #L68
[12:25] <pedronis> but I do remember if was going to be a bit confusing either way
[12:25] <pedronis> *it was going
[12:28] <ogra> hmm, can i somehow find out in a hook if i'm running in --devmode ?
[12:31] <mborzecki> ogra: hmm, cat /etc/shadow ?
[12:32] <mborzecki> maybe not that file in particular, but you get the idea ;)
[12:33] <ogra> yeah, i was looking for something that doesnt necessary produce errors in the journal 🙂 ...
[12:34] <mborzecki> 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] <pedronis> we don't expose it in any explicit way atm
[12:36] <ogra> 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] <mup> PR snapcraft#3449 opened: ci: don't publish snap on push to master <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3449>
[13:29] <mup> PR snapd#9958 opened: tests: disable lxd tests for 21.04 until the lxd images are published for the system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9958>
[13:36] <mup> PR snapcraft#3449 closed: ci: don't publish snap on push to master <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3449>
[14:34] <mborzecki> cachio: do you recall if at some point the images from https://download.opensuse.org/tumbleweed/appliances/ were tried in gce?
[14:35] <mborzecki> 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] <ogra> hmm ... having "snapctl version" would really be handy in some situations
[14:52]  * ogra ponders to file a wishlist bug
[14:54] <cachio> mborzecki, I built the tumbleweed image
[14:54] <cachio> from leap
[14:55] <cachio> didn't try those in gce
[14:57] <ijohnson> 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] <ijohnson> we probably shouldn't use that link going forward much, but it's still in some forum topics for example
[14:58] <ijohnson> seems the new link is https://ubuntu.com/core/docs/uc20/release-notes
[14:59] <degville> ijohnson: good spot - thanks! I'll fix it now.
[14:59] <ijohnson> ah you were in the channel to see the message that made me ask you about this :-D
[14:59] <ijohnson> ETOOMANYCHANNELS
[14:59] <mborzecki> 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] <mborzecki> cachio: this should be a vanilla opensuse TW image
[15:01] <cachio> mborzecki, sure
[15:01] <mborzecki> cachio: and it uses cloud-init during boot, so that should be easy hopefully
[15:01] <cachio> I need to update that image to install the gce dependencies and install the give the correct format
[15:03] <mborzecki> cachio: ah, ok, i see there's cloud-netconfig-gce in the repositories, unless you need more packages
[15:04] <pedronis> mborzecki: is 9942 ready for re-review? any other PR?
[15:05] <cachio> 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] <mborzecki> pedronis: yes, it's ready
[15:11] <mup> PR snapcraft#3448 closed: storeapi: rename SnapClientIndex to SnapAPI <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3448>
[15:27] <ijohnson> 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] <degville> ijohnson: thanks! I'll do it now.
[15:29] <pedronis> mvo: is 9907 ready for re-review?
[15:32] <ijohnson> thanks degville
[15:32] <ijohnson> 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] <pedronis> ijohnson: I update the corresponding open question
[15:33] <ijohnson> ah let me look again then
[15:33] <ijohnson> pedronis: I see it now thanks
[16:05] <mup> PR snapd#9959 opened: o/snapstate: Update validation sets assertions with auto-refresh <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9959>
[16:05] <pstolowski> does anyone have capacity to review #9930?
[16:05] <mup> PR #9930: asserts: pool changes for validation-sets <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9930>
[16:15] <ijohnson> pstolowski: I will add it to my queue for today
[16:15] <ijohnson> probably in my PM though
[16:16] <pstolowski> ijohnson: thank you!
[16:26] <ijohnson> np
[16:47]  * cachio lunch
[17:01] <mvo> pedronis: re 9907> yes, I think so
[17:02] <mvo> pedronis: sorry for the delay, had a gazillion meetings
[17:03] <zyga> hello
[17:03] <zyga> mvo I have three patches for spread
[17:03] <zyga> mvo https://git.ostc-eu.org/OSTC/packaging/spread/-/tree/master/debian/patches
[17:04] <zyga> 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] <zyga> 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] <zyga> this set allows to use spread with openharmony images
[17:05] <zyga> 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] <mup> PR spread#112: Bump base version of go to 1.13 <Created by zyga> <https://github.com/snapcore/spread/pull/112>
[17:18] <pedronis> mvo: thanks, it's back in my queue
[17:21] <mvo> thanks!
[17:22] <mvo> zyga: let me check
[17:22] <zyga> mvo thanks, those are super tiny
[17:22] <zyga> hey pedronis :)
[17:25] <mvo> zyga: 0001 looks fine, the other two I guess need a bit of thinking, maybe config options about compression or something
[17:25] <zyga> I think xz is not so relevant but I agree that the 2nd patch may be an option somewhere
[17:26] <zyga> I wonder if there are any user of the artifact system currently
[17:26] <zyga> I'm certainly using it now and plan to depend on it
[17:27] <zyga> mvo I can propose all three and we can discuss things in the pull request
[17:42] <mup> PR snapcraft#3450 opened: storeapi: rename SCA to DashboardAPI <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3450>
[17:43] <zyga> hey kenvandine :)
[17:43] <kenvandine> hey zyga
[19:07] <mup> PR snapcraft#3450 closed: storeapi: rename SCA to DashboardAPI <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3450>
[20:51] <mup> PR snapd#9958 closed: tests: disable lxd tests for 21.04 until the lxd images are published for the system <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9958>
[21:25] <bandali> thanks again for your reply amurray :-) i just replied back with some more details
[21:56] <mup> PR snapd#9960 opened: tests: update permission denied message for test-snapd-event on ubuntu 2104 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9960>
[23:05] <padge> 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] <padge> Feb 24 17:30:09 nextcloud nextcloud.renew-certs[2711]: cannot create file nextcloud.mnt: Is a directory
[23:07] <oerheks> reinstall nextcloud perhaps?
[23:10] <padge> oerheks: Can I do this and maintain my configs and certificates?
[23:10] <padge> (and data)
[23:14] <oerheks> yes, backup the ~/snap folder to be safe, snap remove --purge nextcloud # would wipe your data too
[23:34] <padge> Installing it failed. This time with a message right to the console, "cannot create file nextcloud.mnt: Is a directory"
[23:34] <padge> I went looking for it, and found it in /run/snapd/ns
[23:34] <padge> I can't delete it, even as root, because "Is a directory"
[23:35] <padge> rm -f nextcloud.mnt
[23:35] <padge> Is this the part where I do an fsck?
[23:42] <amurray> bandali: thanks, will follow up via the forum
[23:43] <bandali> thanks to you! sounds good
[23:47] <ijohnson> padge: I'd recommend starting a forum topic about this, most folks are in EU or americas timezone and thus EOD