[00:42] PR snapd#8127 opened: interfaces/cpu-control: allow to control cpufreq tunables [06:13] morning [08:00] morning [08:00] good morning [08:01] pstolowski: mvo_: zyga: pedronis: morning guys [08:02] PR snapd#8102 closed: o/ifacestate: move ResolveDisconnect to ifacestate

[08:17] PR snapd#8125 closed: data/selinux: unify tabs/spaces [08:18] pushed snapd update to arch and updated https://src.fedoraproject.org/rpms/snapd/pull-request/8 in fedora, but i see Eight_Doctor isn't around :( [08:19] PR snapd#8124 closed: tests: Fix core revert channel after 2.43 has been released to stable [08:32] * zyga is in the office [08:32] I need to shift a few hours back [08:54] * zyga grabbed quick breakfast [09:35] PR snapd#8015 closed: [RFC] daemon, store: support download resume from /v2/download [09:50] zyga: some questions in #8123 [09:50] PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) [09:51] pstolowski: hi, let me know when #8003 can be reviewed again [09:51] PR #8003: o/ifacestate, api: implementation of snap disconnect --forget <⛔ Blocked> [09:55] pedronis: hey, it can (when becomes green) [09:57] mborzecki: thank you, looking [10:20] * zyga reboots [10:26] * zyga dives into failures [10:37] PR snapd#8109 closed: [RFC] o/devicestate: don't prune tasks immediediately <⛔ Blocked> [10:51] hmm in tests prepare we cache the snaps, core among them, then proceed to `snapd download --$CORE_CHANNEL core` obviously the cached version is from stable but tests run with edge [11:09] hmmm [11:12] PR snapd#6708 closed: packaging/ubuntu: enable PIE hardening flags <⛔ Blocked> [11:16] mvo_: thanks for spotting the Println in Ian's PR, I saw them but then forgot to mention them somehow [11:20] PR snapd#8128 opened: o/devicestate: OperationalTime helper for Prune (1/2) [11:28] just saw failover test failure, does anyone remember if it's the same we saw before? https://pastebin.ubuntu.com/p/8n4GPdfp32/ [11:30] PR snapd#6708 opened: packaging/ubuntu: enable PIE hardening flags <⛔ Blocked> [11:43] pedronis: mvo_: i've updated Ian's boot base PR [11:43] i'll do one last pass in case we missed something [11:51] PR snapd#8126 closed: release: 2.43.3 [12:13] hmm, more snapd failover failures [12:13] * zyga checks pawel's messages from earlier today [12:15] https://www.irccloud.com/pastebin/8RcV0Ocb/ [12:15] zyga: do you have the debug log? [12:15] nope :/ [12:17] mvo_: we should update https://salsa.debian.org/debian/snapd === mvo_ is now known as mvo [12:19] zyga: yes [12:44] the fonts in snaps seem to be rendered correctly on fedora, why do they render as boxes on arch? [12:54] cachio: hi, can you enable epel8 in our centos-8 images? should be as simple as `dnf install -y epel-release` [12:55] mborzecki, sure [12:55] I'm seeing a failure on core 16 [12:55] cachio: thanks! [12:55] likely unrelated to the PR [12:55] did we change anything core prepare/restore lately? [12:55] zyga: what failure? [12:55] + mount --bind /home/gopath/src/github.com/snapcore/snapd/tests/regression/lp-1805838/bad-snap-seccomp /snap/snapd/current/usr/lib/snapd/snap-seccomp [12:55] mount: mount point /snap/snapd/current/usr/lib/snapd/snap-seccomp does not exist [12:55] this is the final error [12:56] we try to bind mount test file over snap-seccomp from snapd snap [12:56] but it's not there [12:56] debug output shows [12:56] https://www.irccloud.com/pastebin/Ilmc7Kxz/ [12:56] which confirms that we don't have snapd snap [12:57] but $SNAP_MOUNT_DIR/snapd exists [12:57] weird [12:58] zyga: maybe a snapd on core failover left something? this landed ~2 days ago [12:58] aha [12:58] I suspect so [12:58] let me run my mount detector :P [12:58] which test was that? test/failover? [12:59] tests/main/failover? [12:59] zyga: i mean, maybe a directory /snap/snapd is left behind [12:59] aha [12:59] indeed, this is core 16 so probably no snapd snap [12:59] but the directory may be enough to fool the logic [12:59] * zyga checks [12:59] thanks! [13:00] zyga: tests/main/ubuntu-core-snapd* [13:02] mborzecki: hmm [13:02] mborzecki: the comment there talks about REBOOT and restore [13:02] cannot we reboot in restore? [13:03] mborzecki: what removes snapd.snap in that restore code? [13:04] hi, what's the reason https://github.com/snapcore/snapd/commit/a836400012b70541a20de058b2a951f9386dddf0#diff-2bc16f6bf7e15ff07cc61fb337428314 didn't make it to any 2.43.x release? [13:04] zyga: iirc restore on core does not expect snapd snap and any of the 'trickery' that we do there [13:05] mborzecki: I don't understand how that is related [13:05] mborzecki: can restore do REBOOT? [13:05] anyway, I'm running the test [13:05] I suspect it is broken as it doesn't seem to clean up after itself [13:05] thanks for the tip, I would chase this for a while without success [13:06] zyga: idk, probably it can, but the problem ehre was that project restore has assumptions about the state of the system at that point [13:06] mborzecki: that may be but task-level restore runs before [13:06] so it can do whatever, reboot, and then hand off to suite code [13:07] Hi. I have a question concerning glvnd in spand: As far as I can see (snap-confine/mount-support-nvidia.c#L555), snapd mounts the host's glvnd dir to /var/lib/snapd/lib _if_ the nvidia module is loaded. Why not for mesa though? Some apps need that for their GL context on wayland. [13:07] ppd1990: hey [13:07] ppd1990: we never knew about that, can you tell us more please [13:08] ppd1990: but also because nvidia binary driver is usually abi compatible with everything [13:08] ppd1990: and FOSS libs are more or less random [13:08] ppd1990: so it's more of an exception than the rule [13:08] pedronis: in the followup to #8128 i'm using release.PreseedMode in the overlord to avoid prung when preseeding, is that ok for now? i'd like to attack release.preseedmode after remaining preseed PRs land [13:08] PR #8128: o/devicestate: OperationalTime helper for Prune (1/2) [13:08] ppd1990: FOSS graphics is usually bundled into the app snap (bad but common) or into one of the helpers (like gnome content snap) [13:09] zyga: do you know when https://github.com/snapcore/snapd/commit/a836400012b70541a20de058b2a951f9386dddf0 will land in 2.43.x? [13:09] pstolowski: it's ok, we need to rediscuss what exactly we want to do about release.PreseedMode, my original plan doesn't entirely work [13:09] but release is still a slightly horrible place for it [13:09] vidal72[m]: my guess would be never [13:09] vidal72[m]: it will be in 2.44 [13:10] vidal72[m]: unless it is in 2.43 release branch [13:10] but if it were you would not be asking [13:10] zyga: Hey :). Yes, that's true. I'm mostly only concerned with /usr/share/glvnd/egl_vendor.d/50_mesa.json. If that's not in __EGL_VENDOR_LIBRARY_DIRS, gdk throws something like this on wayland: "No GL implementation is available" [13:10] pedronis: sure. you mean the original plan of DeviceContext-like approach? [13:11] pstolowski: yes [13:11] pstolowski: anyway, let's talk about it when you reach a point where you want to attack it [13:11] ppd1990: can you give me an example on how to reproduce this [13:11] ppd1990: ideally as a bug report so that I can track it as well [13:11] ppd1990: including host distro / gpu / snap app [13:11] ppd1990: but the short answer is that the dots are not connected there [13:12] ppd1990: we had some plans but they never materialized [13:14] zyga: Take solvespace, an app that uses the gnome-extension. Simply pointing __EGL_VENDOR_LIBRARY_DIR to $SNAP/gnome-platform/usr/share/glvnd/egl_vendor.d is enough. So almost everything is set up and working [13:15] pedronis: ok, will do, thanks [13:15] ppd1990: should that be handled by the gnome extension? it can influence the environment [13:15] also is __EGL_VENDOR_LIBRARY_DIR an implementation detail or something we can rely on long term? [13:15] zyga: It does indeed. But only if it finds /var/lib/snapd/[...]/egl_vendor.d [13:16] zyga: Which brings me back to "why is that mounted on nvidia only" :) [13:16] ppd1990: because that belongs to extended nvidia support which as a rule takes libraries from the host [13:16] ppd1990: and ... thats that [13:16] no nvidia - dormant code path [13:16] zyga: what's the policy about what lands in releases then? That commit was done about one month before 2.43 release and isn't in release while similar commits done in recent days are already there: https://github.com/snapcore/snapd/commits/2.43.3/interfaces/builtin [13:17] zyga: I see. So that's more of a snapcraft thing then [13:17] vidal72[m]: this is a question for our release manager, mvo [13:17] mborzecki, hey [13:17] https://paste.ubuntu.com/p/cxmZjbq4JM/ [13:17] I see this error when I try to install depdencies in centos8 [13:17] ppd1990: I would personally like to remove nvidia support entirely [13:17] ppd1990: and ship those files via snaps [13:17] I am trying to install the snap dependencies [13:17] ppd1990: (shared snaps) [13:17] vidal72[m]: looks like we forgot to set a milestone and do a cherry-pick [13:17] ppd1990: but that's not moving forward [13:18] mborzecki, but it works when we run tests on travis, right? [13:18] zyga: It's almost like you guys are solving non-trivial problems :D [13:18] ppd1990: it's a combination of lack of experience and known-how as to how mesa is moving [13:19] ppd1990: and lack of time on our side to dive into it and commit [13:19] mvo: can you cherry pick https://github.com/snapcore/snapd/commit/a836400012b70541a20de058b2a951f9386dddf0 to 2.43 in case we do another patch release? [13:19] ppd1990: if you'd like to help by drafting how that ought to look like we can help [13:20] cachio: yes, the set of packages for centos-8 is bit differnt, more like fedora, look at the changes in https://github.com/snapcore/snapd/pull/8083 [13:20] PR #8083: spread: add CentOS 8 [13:20] ppd1990: ideally we'd ship a set of userspace libs as snaps, one per "driver" whatever that means [13:20] ppd1990: snapd would figure out which to install [13:20] ppd1990: possibly a matrix of driver and base snap used which defines the ABI [13:20] mborzecki, ok [13:20] ppd1990: and snapcraft would cull the libraries that belong to the driver from built snaps [13:21] zyga: where 'driver' means a mesa snap probably or sth [13:21] ppd1990: there's also some configuration as defined by magic environment and random files [13:21] ppd1990: and that _should_ be it [13:21] mborzecki, in that case I'll not install the dependencies yet [13:21] ppd1990: assuming the host provides the kernel and any services that the driver needs [13:21] ppd1990: matching the host driver (userspace side) is possible in the realm of snaps [13:21] ppd1990: but none of this is implemented [13:22] mborzecki: hmmm, -shell-after shows we have snapd [13:22] zyga: snap or directory? [13:22] mborzecki: everything [13:22] mborzecki: working mounted and all that [13:23] mborzecki: when you wrote this test, how were you expecting the recovery to work? [13:24] ppd1990: btw, if my idea of how this ought to work is wrong based on your experience, please do tell [13:24] zyga: mvo wrote the test iirc :P let me see what's happening there [13:24] oh? [13:25] mborzecki: commit 31312f02c18660a71c856f7c0f413e8c9c41a590 [13:25] that says you wrote it ; [13:25] zyga: yeah, took over mvo's branch at some point, suashing merging, resetting, probably author got reset, nvm, i'll try to fix it [13:25] zyga: I have little experience and my question was fueled by an incomplete understanding of the interface between host and the snap environment [13:25] mborzecki: aha, I se [13:25] *see [13:26] mborzecki: yeah [13:26] mborzecki: ok let me handle that for now [13:26] I'll share my ideas in a moment [13:26] zyga: ok, the problem is that we need to stop the snapd process, clean up everything it wrote to /etc/systemd/system/* and stop the hacky-mount-unit [13:27] zyga: basically restore to snapd from 'core' rather than 'snapd' snap [13:27] yeah [13:27] I agree [13:28] zyga: But your ideas are very interesting and seem to go in the direction of "more explicit interfaces" and less of "let's "mix" host & snap. Should be mostly OK" [13:29] ppd1990: somewhere along there is the desire to stop mixing host /etc [13:29] ppd1990: and provide a synthetic etc that is writable and snap-specific [13:29] ppd1990: but $fonts $pam $random_stuff and others all need to be handled [13:33] pstolowski: +1, the summary and description needs the rename [13:33] sure, thanks [13:39] zyga: It reads like a very extensive problem if apps are not required to conform to a very limited "snap-platform" [13:39] ppd1990: wild-west apps can ship and use anything [13:39] ppd1990: but we want to provide a sensible base for the vast majority [13:41] mborzecki, image ready [13:41] cachio: thanks! [13:41] mborzecki, yaw [13:41] zyga: As a mere user/packager, I like it a lot. I feel things are moving into the right direction; that's for sure [13:43] So thank you for doing what you do @snap(d|craft) team [13:44] ppd1990: you are welcome, it's always good to get questions and opinions from the wider community :) [13:48] mborzecki: https://github.com/snapcore/snapd/pull/6708#pullrequestreview-358227261 [13:48] PR #6708: tests/main/buildmode: verify usability of PIE hardening for deb packages <⛔ Blocked> [13:57] mvo: I'll join in 5 minutes [13:59] zyga: ok [14:24] pedronis: https://github.com/snapcore/snapd/pull/8078 [14:24] PR #8078: daemon: support resuming downloads [14:29] cachio: I have your PR open, I'm sorry I didn't get to it yet [14:29] I'll focus more on reviews after unblocking this bug [14:29] zyga, np [14:29] take your time [14:32] jdstrand: tools r20200211-blahblah is now in production \o/ [14:34] roadmr: woohoo! :) [14:38] cachio: sorry I missed your ping yesterday, your explanation makes sense I don't think we need to write unit tests for that spread bit at this time, but I will try to test your PR with those commands locally [14:44] zyga: hmm that snapd snap is a local repack? so rev will be unset, and the code allows removal in such scenario afaict (cc pedronis) [14:44] mborzecki: that's probably what happens [14:44] mborzecki: it failed to be removed after simplification [14:44] zyga: do you have snap list maybe? [14:44] mborzecki: it worked when it was broken [14:44] not anymore [14:44] waiting for another run [14:48] zyga: hmm error: cannot remove "snapd": snap "snapd" is not removable: snapd required on core devices [14:48] zyga: maybe it was the failover test? [14:48] no, it was the non-failover one [14:48] hold on [14:48] zyga: ubuntu-core-snapd installs snapd snap from the store [14:49] zyga: while the other one does magic hackery [14:56] PR snapcraft#2930 closed: extensions: Handle case when user-dirs.dirs exits but not user-dirs.locale [14:59] PR snapcraft#2929 closed: elf: fixes for corrupt shared objects [14:59] mvo: is #8077 ready then? [14:59] PR #8077: boot: enable base snap updates in bootstate20 [15:18] * cachio lunch [15:22] mborzecki: maybe this [15:24] pstolowski: mind giving a quick re-review to https://github.com/snapcore/snapd/pull/7904 ? we should have a version of snapcraft that supports using `build-base: core` _without_ `type: snapd` released soon so it would be good to be ready to land this PR when that happens so we can make xnox happy :-) [15:24] PR #7904: snapcraft.yaml: use build-base and adopt-info, rm builddeb plugin <⛔ Blocked> [15:25] mborzecki: 8129 [15:25] PR snapd#8129 opened: tests: remove snapd in ubuntu-core-snapd [15:26] PR snapcraft#2934 opened: meta: fix for missing content slot's 'content' property [15:27] ijohnson: yay, sure! [15:38] PR snapcraft#2935 opened: build providers: remove tzdata workaround [15:39] mborzecki: what do you think? [15:42] PR snapd#8077 closed: boot: enable base snap updates in bootstate20 [15:47] zyga: i'm surprised that snap remove snapd line works [15:47] because it is broken [15:47] PR snapcraft#2936 opened: build providers: clean up LXD startup message [15:48] but I believe this does fix master [15:49] I added robustness and critical labels to it [15:52] mborzecki: I updated the description to be meaningful [15:56] force pushed to squash and fix shellcheck [15:56] mborzecki: please review :) [15:56] it's really annoying when master is broken [16:03] zyga: which PR ? [16:03] https://github.com/snapcore/snapd/pull/8129 [16:03] PR #8129: tests: remove snapd in ubuntu-core-snapd <⚠ Critical> [16:03] thanks looking now [16:04] thank you! [16:09] I should make some coffee [16:14] ijohnson: I reviewed #8112 [16:14] thanks for it [16:14] PR #8112: tests: move main/ubuntu-core-* tests to core/ suite [16:14] thanks pedronis [16:14] roadmr hey! can you please check if flatbuffers snap has any issues in the store. The publisher has been getting some build failure notifications due to wrong version string; we just fined that https://github.com/google/flatbuffers/pull/5727 [16:14] PR google/flatbuffers#5727: [snap] Fix versioning [16:15] pedronis: I'll change those things and then merge when it's green [16:15] thx [16:16] ijohnson: it might conflcit with #8129 ? [16:16] hmm [16:16] PR #8129: tests: remove snapd in ubuntu-core-snapd <⚠ Critical> [16:17] pedronis: oh yes it might, but it's just a file rename so I can merge master to resolve that easily enough I think [16:17] om26er: I'll check in a bit [16:20] * zyga combines coffee with dinner [16:20] om26er: latest upload/build was 17h ago, still getting this bogus version string ".11.0+git226.gcc08c083" [16:21] roadmr we just landed the new PR, I am hoping that will trigger a new build then [16:21] though I don't see anything here https://launchpad.net/builders [16:22] roadmr are you able to force a build ? [16:22] om26er: might take a bit to kick off the build, I'd suggest waiting a few mins [16:22] alright, sounds good [16:23] om26er: do let me know if it hasn't built in a couple of hours [16:24] roadmr, I will, thanks [16:56] PR snapd#8130 opened: overlord, state: don't abort changes if spawn time before StartOfOperationTime (2/2) [16:58] pstolowski: I think we can close 7836 ? [17:01] PR snapd#7836 closed: o/ifacestate: fix binding of implicit hooks to implicit slots on core snap <⛔ Blocked> [17:01] pedronis: yes, done, i may pick it up again at a later time [17:01] if needed [17:03] ijohnson: we want build-base:core in https://github.com/snapcore/snapd/pull/7904, no? I don't see any change to the PR since I last reviewed it [17:03] PR #7904: snapcraft.yaml: use build-base and adopt-info, rm builddeb plugin <⛔ Blocked> [17:03] pstolowski: oh I must have mis-force-pushed good catch! [17:09] pstolowski: didn't really do a full review, but I made a comment on 8130 [17:09] ty [18:15] zyga: mind if I force push the change mborzecki requested to #8129 to your PR? Also your PR will conflict with #8112, so if it's okay I would like to land that, then I can rebase that PR and apply the fixed maciej requested [18:15] PR #8129: tests: remove snapd in ubuntu-core-snapd <⚠ Critical> [18:15] PR #8112: tests: move main/ubuntu-core-* tests to core/ suite [18:15] ijohnson: not at all [18:15] zyga: cool thanks! [18:27] PR snapcraft#2934 closed: meta: fix for missing content slot's 'content' property [18:42] PR snapcraft#2937 opened: spread tests: do not attempt to remove snapd snap [18:54] ijohnson: thanks for restarting, macos build now passed [18:55] roadmr flatbuffers build didn't trigger yet. Can you force it manually ? [19:03] zyga: np, my PR didn't pass non-ubuntu spread so I retriggered it, I guess we will see which PR passes tests first :-) [19:05] one of those days [19:05] but I'm happy we're moving forward [19:06] indeed [19:35] om26er: sorry, I cannot :( maybe the snap owner can? [19:36] roadmr, ok, will wait it off today and will "find" him tomorrow (I guess on GitHub) ;) [19:37] om26er: thanks - I can check with Colin tomorrow morning about why this might not have been triggered; it should trigger on new commits to master [20:07] ijohnson: it's merged! [20:07] * zyga takes the dog out, ttyl [20:07] zyga: ack seems your PR beat mine :-) [20:08] I will include the patch in my PR [20:08] PR snapd#8129 closed: tests: remove snapd in ubuntu-core-snapd <⚠ Critical> [20:12] PR snapd#8112 closed: tests: move main/ubuntu-core-* tests to core/ suite