[00:54] PR snapcraft#2488 closed: cli: Fix traceback count check in error test [00:54] PR snapcraft#2489 closed: cli: Mock Raven client in error tests [05:59] morning [08:03] good morning [08:06] zyga: hey hey [08:06] how are you feeling? [08:06] zyga: quite fine, thanks [08:08] I was fighting odd build issue last night [08:08] golang changed in suse again [08:08] but this time for the better [08:08] zyga: again? [08:08] yeah, the maintainer applied my suggestion [08:08] and removed /etc/profile.d/go.sh [08:09] so no more magic variables === pstolowski|afk is now known as pstolowski [08:09] mornings [08:09] the problem is that now it doesn't work because we start with those [08:09] I will try to sprinkle unset in strategic places [08:10] pstolowski: hey [08:15] I think I have a fix [08:15] not sure if it's just me or is master broken too [08:15] but I'm working oni t [08:16] Hi snappy people. Do we know when the next snapcraft release is scheduled? I cannot work on MicroK8s since I am not able to build it due to this https://bugs.launchpad.net/snapcraft/+bug/1817300 . Do we at least have a workaround? [08:16] Bug #1817300: autotools plugin fails to build in classic confinement [08:40] pstolowski: i'm thinking the script that patches mount units to add selinux context should be part of the PR with policy refactor [08:40] yay [08:41] master is fixed with my patch [08:41] pushed [08:41] once green I'll land https://github.com/snapcore/snapd/pull/6111 [08:41] PR #6111: packaging/opensuse: move most logic to snapd.mk [08:43] mborzecki: ok [08:43] if urgent we can cherry-pick https://github.com/snapcore/snapd/pull/6111/commits/27d844a3b86b73bddf97a837faa6e2fb66124003 [08:43] PR #6111: packaging/opensuse: move most logic to snapd.mk [08:48] ogra, zyga https://github.com/snapcore/core/pull/98 can this be merged in, has been in this state for months [08:48] PR core#98: Add force_turbo rpi option [08:48] sborovkov: looking [08:49] sborovkov: I will merge it today after getting an ack from pedronis [08:49] thanks [08:51] sborovkov: zyga: remember that we don't use that configure hook anymore [08:52] oh ok, this needs to be changed then? [08:53] pedronis, because I can't see any other references to rpi config options anywhere [08:53] https://github.com/snapcore/snapd/blob/master/overlord/configstate/configcore/picfg.go [08:54] got it thanks [08:55] we probably need to decide what to do with the hook is was mostly there for compat in some refresh scenarios [08:58] mo'in [09:05] Chipaca: hi, yes we discussed about allowing connectivity also without sudo [09:05] Chipaca: #6540 can be merged [09:05] PR #6540: daemon, client, cmd/snap: debug GETs ask aspects, not actions [09:05] PR snapd#6543 opened: Add force_turbo to the list valid pi config keys [09:05] huzzah [09:05] pedronis, zyga https://github.com/snapcore/snapd/pull/6543 [09:06] PR #6543: Add force_turbo to the list valid pi config keys [09:06] PR snapd#6540 closed: daemon, client, cmd/snap: debug GETs ask aspects, not actions [09:09] PR snapd#6530 closed: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core [09:16] PR snapd#6472 closed: overlord: fix ensure before slowness on Retry [09:23] hmm, build failed on https://travis-ci.org/snapcore/core/builds/444677088 [09:23] sil2100: are you looking after core builds with mvo? [09:23] or is that just mvo? [09:23] PR snapd#6544 opened: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core (2.37) [09:30] zyga: I think it's just mvo, I don't do much with core itself [09:30] I see, thanks [09:30] Since core is still a snapd thingy ;) [09:30] pedronis: hey, do you have time today to talk about perf measurements? [09:33] pstolowski: yes, would in 45 mins work? [09:33] interesting, xdg-open does not work with portal-test snap, which uses core18 base [09:33] pedronis: yes [09:33] all i get is /usr/bin/xdg-open: 2: exec: snapctl: not found [09:34] mborzecki: seems like a real bug [09:34] relevant strace https://paste.ubuntu.com/p/YsXvK7tYQW/ [09:35] a random snap with core base works just fine [09:36] mborzecki: interesting [09:36] mborzecki: what is /usr/bin/xdg-open? [09:36] mborzecki: in core it was a special version that came from a PPA [09:36] perhaps we... missed that? [09:36] (should have upstreamed a patch to xdg-open) [09:37] zyga: no, it's a shell script that calls to snapctl user-open "$@" [09:37] mborzecki: that's good [09:37] what happens when you call snapctl user-open http://example.com/ [09:37] does it work? [09:38] zyga: bash: snapctl: command not found :? hmm [09:38] oh [09:38] I know [09:38] is /usr/bin/snapctl there? [09:38] no? that's that :) [09:38] it's not on path [09:38] it's only in /usr/lib/snapd/snapctl [09:38] is it? [09:38] \o/ [09:39] zyga: nope, not there [09:39] in core it's a symlink [09:39] real bug [09:40] so... [09:40] I'm trying to ship chromedriver in the chromium snap, but it needs to run chromium with a full path, which I specify as "/snap/bin/chromium", but it's not seeing it, I assume that's a confinement thing. Is there a documented way of making one app in a strictly confined snap execute another app in the same snap? [09:40] how does /usr/bin/snap work? [09:40] mborzecki: where is `snap` on core18? [09:40] btw. core18 is withouth snapd, so that content of /usr/lib/snapd i see is from the host? [09:40] yes [09:40] oSoMoN: you cannot run apps this way, you can run executables but you will retain your current set of permissions [09:40] mborzecki: correct [09:41] oSoMoN: you can run anything via $SNAP/... (not /snap/bin) [09:41] oSoMoN: but as I said, if you have two apps with different permissions, you will not transfer the permissions over [09:41] is snapctl a symlink to /usr/lib/snapd/snapctl on ubuntu? [09:41] mborzecki: yes [09:41] mborzecki: yes [09:41] mborzecki: not just on ubuntu [09:42] mborzecki: it should be that everywhere [09:42] but it comes from the package [09:42] a symlink to ../lib/snapd/snapctl [09:42] zyga, that probably won't work then… thanks for confirming [09:43] I guess I'll have to split chromedriver into its own separate, classic snap [09:43] ok, so there's 2 things that can be wrong in my setup, /usr/lib/snapd not in PATH (is it on ubuntu?) and arch packaging (snapctl is not a symlink) [09:43] mborzecki: /usr/lib/snapd should not be on path anywhere [09:43] the bug is the symlink [09:43] mborzecki: but but but [09:43] mborzecki: you can use snapd.mk to fix arch package RSN [09:43] :D [09:44] I'm happy to help [09:44] zyga: haha ok [09:44] it handles all that [09:44] aaand it's in [09:44] zyga: but w8, if /usr/lib/snapd is not in $PATH inside snap executio env, how will xdg-open work then? [09:44] just got green :) [09:44] mborzecki: xdg-open works because snapctl is on path [09:44] via the symlink [09:45] unless core18 should ship a symlink then? [09:45] yeah, that's the next question [09:45] I ... think so [09:45] PR snapd#6111 closed: packaging/opensuse: move most logic to snapd.mk [09:45] but perhaps mvo has some opinions [09:45] ah there is a symlink [09:45] oh? [09:45] yeah, bash is smart to not show it in completion when it's dead :/ [09:46] ah [09:46] makes sense [09:46] why is it dead? [09:46] no snapctl in /usr/lib/snapd? [09:46] yup, ok, i'm gonna fix arch package then [09:46] try using snapd.mk [09:46] if it sucks for whatever reason please tell me [09:47] zyga: but it's in master only now, isn't it? [09:47] yeah [09:47] ah, i see what you meant now [09:47] for release do whatever makes sense [09:47] just for future reference packaging in master [09:47] so, it looks like we're missing a ... spread test :) [09:48] mborzecki: indeed! [09:48] but that's true of lots of core18 things [09:48] zyga, given that chromedriver's sole purpose it to execute and drive chromium, it shouldn't be too bad if I give the app the same set of permissions as chromium itself, I'll give that a try [09:53] PR snapd#6545 opened: cmd/snap, daemon: make the connectivity check use GET [09:54] PR core#98 closed: Add force_turbo rpi option [09:54] PR core#102 opened: hooks: add force_turbo to PI_CONFIG_KEYS [09:56] as a side note, since snapctl runs in snap mount ns, it should probably be built statically [09:57] mborzecki: yeah [10:10] PR snapcraft#2487 closed: Release changelog for 3.2 [10:20] pstolowski: in the standup ho? [10:22] https://github.com/snapcore/core/pull/102 this needs a review [10:22] ogra: ^ [10:22] PR core#102: hooks: add force_turbo to PI_CONFIG_KEYS [10:22] pushing an update to arch package in a bit [10:22] pedronis: coming [10:24] brb, need to get daughter to school === ricab is now known as ricab|bbiab [10:42] re [10:42] Feb 27 09:57:30 feb270955-025300 snapd[2233]: link.go:75: cannot update fontconfig cache: cannot run fc-cache-v6 on core: signal: terminated [10:43] blast from the pastQ [10:44] arch package updated [10:44] and we do have a symlink in our packaging/arch setup already [10:50] zyga, for information, the approach of pointing chromedriver to the chromium wrapper script under $SNAP and giving it the same permissions worked, thanks for the help [10:50] +1 [10:54] PR snapd#6546 opened: packaging: build snapctl as a static binary [10:54] zyga: ^^ [10:54] looking [10:55] replied [10:56] I think snapd.mk doesn't handle snap-failure [10:56] what is that for? [10:56] Hi. Should I prefer the LibreOffice snap package or deb package? Which one is the best maintained one? [10:57] zyga: lest build a static tree :P [10:57] heh [10:57] vvug: both should be maintained but the snap should have more versions to choose from [10:57] vvug: for example, the classic package can be from a less recent major / minor versions [10:57] but with security fixes applied [10:58] zyga: snap only has 6.2.0.3 right now tho :-) [10:58] the snap package may offer multiple versions (including most recent one) === chihchun is now known as chihchun_afk [10:58] vvug: having said that, I'm not maintaining that snap, perhaps popey would know? [10:59] vvug: the snap package is 6.2.0.3 which is newer than any in-distro one fwiw [10:59] zyga: thanks. It's a bit confusing to have both. I wonder if there is a longish-term plan to ditch the .deb in favor of the snap [10:59] vvug: I think both will remain supported for a while, eventually the deb might cease to be installed by default but I suspect it will stay being available forever === ricab|bbiab is now known as ricab [11:01] I see. I guess that if one want to follow the LTS releases but have an up-to-date LibreOffice the snap is a good option. But there is also a "fresh release" PPA I think. It's nice to have options, but sometimes confusing too :) [11:05] vvug: just complexity, you get to see the intermediate points [11:06] Chipaca: the new api_debug*.go should probably says 2019 ? [11:07] * Chipaca looks at the calendar [11:07] * Chipaca notices it still says 1974 [11:07] drat [11:07] * zyga gives Chipaca a battery for his calendar [11:07] * Chipaca hopes it's an artillery battery [11:25] wish systemctl had something like try-stop to return whether a stop action was actually executed or not [11:25] otherwise systemctl is-active .. && systemctl stop feels racy [11:26] mborzecki: why do you care? [11:26] mborzecki: i mean, stop works even if the thing is stopped [11:27] * pstolowski lunch [11:27] Chipaca: hmm maybe i shouldn't, otoh when patching mount units for selinux i can't restart them without affecting the services [11:28] mborzecki: mount units don't do reload? [11:29] Chipaca: they may do, but you cannot change a security context of a mounted block device [11:29] Chipaca: the kernel blocks it intentionally [11:40] Chipaca: pstolowski: some of mvo commens on #6356 and #6322 (not sure about the Commit helper there though, would have to be tried) [11:40] PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump [11:40] PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get [11:40] in case of doubt ask me [11:41] and conflicts! === chihchun_afk is now known as chihchun [11:43] Hi [11:43] Is there a way to skip the connectivity check during snapcraft cleanbuilds? [11:44] Chipaca: that oo [11:44] too [11:44] pedronis: did you understand the comment about the filter, or should I ask mvo? [11:46] Chipaca: I think he is proposing that reRefreshUpdateMany be set to a function that hides the passing of the filter [11:46] not sure if that messes with testing or not [11:47] Chipaca: changing this line var reRefreshUpdateMany = updateManyFiltered [11:47] to be = func ... [11:52] Chipaca: I'm also not sure I like that change [11:52] Chipaca: I think the issue is more with the name: reRefreshUpdateMany [11:54] pedronis: i.e. if it's for reRefresh already why does it need a filter? [11:54] Chipaca: yes, I think that's his thinking (guessing here) [11:55] the name implies it does the full job [11:55] yeah [11:55] ok, I'll change that because it's a good point, and then will confirm with mvo there wasn't a deeper one [11:55] /me walk ... [11:55] Chipaca: change that in which way? the name or the line? [11:55] the name [11:55] ok [11:56] I'll call it totallyNotReRefreshUpdateManyMaybe [11:56] * Chipaca hides [11:56] doingTheThingConsideringTheThingsAndTheTimeOfTheYear === chihchun is now known as chihchun_afk [12:06] pedronis: ...(thing Thing, things map[string]Thinger, moon moon.Phase) Result { … [12:07] mborzecki: I did pass over #6079 [12:07] PR #6079: cmd/snap: `snap connections` command [12:07] pedronis: thanks! [12:07] Chipaca: ^ something for your list of things to look at as well [12:07] ack [12:28] pedronis: do you have a suggestion for a better name for the "laneSnaps" helper? [12:32] Chipaca: refreshedSnaps ? [12:32] the comment can say how their are determined, but is not so relevant to the role [12:32] s/role/purpose/ of the function [12:33] pedronis: sgtm [12:35] back now [12:35] feels like spring now :) [12:57] I'm suddenly getting “execv failed: No such file or directory” during the install hook run of my snap – but the hook is in snap/hooks, has mode 0700 and is included in the snap file [12:57] dot-tobias: is it a script, or a binary? [12:58] good hunch [12:59] Chipaca: script, starts with shebang and only creates a directory in $SNAP_COMMON [12:59] dot-tobias what is the interpreter? [12:59] zyga: no, just 'shebang' :-p [12:59] #!/bin/sh -e, like in the docs [12:59] ah [12:59] dot-tobias: any apparmor denials? [13:01] zyga: I'm trying in devmode, getting three STATUS messages with “profile_replace”, “same as current profile, skipping” [13:01] those are harmless [13:01] look for ALLOWED [13:01] Nothing, just those three. (Note: I'm tailing /var/log/syslog during the install attempt, any other logs?) [13:01] mmm, that should be it [13:01] dot-tobias: can you report a bug with a reproducer please? [13:02] zyga: Sure, will do [13:04] what is https://github.com/snapcore/snapd/pull/6544 failing on [13:04] PR #6544: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core (2.37) [13:04] I see it restarted over and over [13:24] PR snapd#6513 closed: [RFC] many: support `snap install --skip-service-start` <⛔ Blocked> [13:25] zyga: master is green, so it would be something 2.37 specific === chihchun_afk is now known as chihchun [13:36] pedronis: I merged https://github.com/snapcore/snapd/pull/6544 [13:36] are we ready for .4? [13:36] PR #6544: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core (2.37) [13:37] PR snapd#6544 closed: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core (2.37) [13:39] zyga: I think so afaik [13:40] I pinged mvo in tg [13:44] zyga: will you be pushing a .4 to beta imminently? [13:44] no, not me [13:44] if anyone, mvo would [13:45] I mean you as in the collective team :) [13:45] let me ask if he would consider this [13:45] mvo is off this week [13:47] its not a problem if youre not, just wanted to be ready in case [13:47] * cwayne isnt pushing for one right now :) [13:47] cwayne: mvo is on the road now, he will do it later today [13:48] zyga: thanks for the headsu p [13:48] cwayne: I will let you know more once I konw [13:48] *know [13:48] no worries, thanks man [14:01] pedronis: stdup? === ricab is now known as ricab|lunch [14:08] PR snapd#6547 opened: tests: enable opensuse tumbleweed on spread [14:10] PR snapd#6546 closed: packaging: build snapctl as a static binary [14:11] zyga , Chipaca: nvm the previous query about install hook failures, it seems like it was caused by a layout I added for /usr (which, what I would've seen if I had scrolled the layout docs down to the bottom, is currently not possible) [14:11] oh [14:11] layout for _entire_ /usr? [14:11] or for a sub-directory? [14:11] can you tell me more what your use case was? [14:13] zyga: entire /usr, dunno what I was thinking. I'm currently snapping the WPE fork of WebKit and it assumes a bunch of libs and other stuff in /usr/ sub-directories, so I was basically being lazy. I specified /usr/share/X11 and it's installing fine again; although I now have the problem that some libs are in arch-triplet subdirectories and I want to avoid that. Final target is arm, testing on amd64 … but I think I'll use organize for this [14:14] ok, thank you [14:15] I think we should warn / do something smart about layout for /usr [14:15] as that hides /usr/lib [14:15] and thus /usr/lib/snapd [14:17] cachio: https://en.opensuse.org/Lifetime -- openSUSE Leap 42.3 will be supported till the 30th of June [14:17] 15.0 will be EOLd in November but .1 is pending so I think we will drop 42.3 and switch to 15.1 [14:17] (that is switch 15.0 to 15.1) [14:23] PR snapcraft#2490 opened: test: test-beta [14:27] pstolowski: is the hotplug main PR description/commit msg correct or does it need updating to reflect the bit really in the change? [14:28] otherwise it can go in [14:29] pedronis: thank you, indeed, i will tweak it [14:33] Chipaca: hey, I noticed in a895e537c55a350af30250e5bedc1b16e0c095ab you introduced src/github.com/snapcore/snapd/overlord/snapstate/export_test.go:221:19: expected type, found '=' on bionic with golang 1.10 [14:34] Chipaca: is there something I should be doing differently? /me thought bionic and 1.10 would be good enough these days [14:34] oh [14:34] are we using type aliases? [14:34] hey jdstrand :) [14:35] hey zyga :) [14:35] pedronis: https://github.com/snapcore/snapd/pull/6499 is a low hanging fruit, has +2, just needs your ack [14:35] PR #6499: cmd/snap-confine: allow moving tasks to pids cgroup [14:36] PR snapd#5962 closed: ifacestate/hotplug: integration with udev monitor [14:42] cachio: hey, in my nested vm branch i've a change in spread.yaml and i'm not sure if is required - plan: n1-standard-2 - i probably added it long time ago [14:42] cachio: was it your suggestion? [14:45] zyga: for testing, yes [14:45] pstolowski, let me check [14:46] jdstrand: that should work from 1.9 onwards [14:46] jdstrand: where's the error from? [14:46] jdstrand: (we run the unit tests with 1.9 and 1.10 so it should all work) [14:46] Chipaca: run-checks [14:47] $ ./run-checks [14:47] ... [14:47] Checking for naked returns [14:47] could not parse input /home/ubuntu/gocode/src/github.com/snapcore/snapd/overlord/snapstate/export_test.go:221:19: expected type, found '=' [14:47]