[00:54] <mup> PR snapcraft#2488 closed: cli: Fix traceback count check in error test <Created by cmatsuoka> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2488>
[00:54] <mup> PR snapcraft#2489 closed: cli: Mock Raven client in error tests <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2489>
[05:59] <mborzecki> morning
[08:03] <zyga> good morning
[08:06] <mborzecki> zyga: hey hey
[08:06] <zyga> how are you feeling?
[08:06] <mborzecki> zyga: quite fine, thanks
[08:08] <zyga> I was fighting odd build issue last night
[08:08] <zyga> golang changed in suse again
[08:08] <zyga> but this time for the better
[08:08] <mborzecki> zyga: again?
[08:08] <zyga> yeah, the maintainer applied my suggestion
[08:08] <zyga> and removed /etc/profile.d/go.sh
[08:09] <zyga> so no more magic variables
[08:09] <pstolowski> mornings
[08:09] <zyga> the problem is that now it doesn't work because we start with those
[08:09] <zyga> I will try to sprinkle unset in strategic places
[08:10] <mborzecki> pstolowski: hey
[08:15] <zyga> I think I have a fix
[08:15] <zyga> not sure if it's just me or is master broken too
[08:15] <zyga> but I'm working oni t
[08:16] <kjackal> 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] <mup> Bug #1817300: autotools plugin fails to build in classic confinement <Snapcraft:Fix Committed by sergiusens> <Snapcraft legacy:Fix Committed by sergiusens> <Snapcraft trunk:Fix Committed by sergiusens> <https://launchpad.net/bugs/1817300>
[08:40] <mborzecki> 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] <zyga> yay
[08:41] <zyga> master is fixed with my patch
[08:41] <zyga> pushed
[08:41] <zyga> once green I'll land https://github.com/snapcore/snapd/pull/6111
[08:41] <mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
[08:43] <pstolowski> mborzecki: ok
[08:43] <zyga> if urgent we can cherry-pick https://github.com/snapcore/snapd/pull/6111/commits/27d844a3b86b73bddf97a837faa6e2fb66124003
[08:43] <mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
[08:48] <sborovkov> ogra, zyga https://github.com/snapcore/core/pull/98 can this be merged in, has been in this state for months
[08:48] <mup> PR core#98: Add force_turbo rpi option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/98>
[08:48] <zyga> sborovkov: looking
[08:49] <zyga> sborovkov: I will merge it today after getting an ack from pedronis
[08:49] <sborovkov> thanks
[08:51] <pedronis> sborovkov: zyga: remember that we don't use that configure hook anymore
[08:52] <sborovkov> oh ok, this needs to be changed then?
[08:53] <sborovkov> pedronis, because I can't see any other references to rpi config options anywhere
[08:53] <pedronis> https://github.com/snapcore/snapd/blob/master/overlord/configstate/configcore/picfg.go
[08:54] <sborovkov> got it thanks
[08:55] <pedronis> we probably need to decide what to do with the hook is was mostly there for compat in some refresh scenarios
[08:58] <Chipaca> mo'in
[09:05] <pedronis> Chipaca: hi, yes we discussed about allowing connectivity also without sudo
[09:05] <pedronis> Chipaca: #6540 can be merged
[09:05] <mup> PR #6540: daemon, client, cmd/snap: debug GETs ask aspects, not actions <Created by chipaca> <https://github.com/snapcore/snapd/pull/6540>
[09:05] <mup> PR snapd#6543 opened: Add force_turbo to the list valid pi config keys <Created by sergey-borovkov> <https://github.com/snapcore/snapd/pull/6543>
[09:05] <Chipaca> huzzah
[09:05] <sborovkov> pedronis, zyga https://github.com/snapcore/snapd/pull/6543
[09:06] <mup> PR #6543: Add force_turbo to the list valid pi config keys <Created by sergey-borovkov> <https://github.com/snapcore/snapd/pull/6543>
[09:06] <mup> PR snapd#6540 closed: daemon, client, cmd/snap: debug GETs ask aspects, not actions <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6540>
[09:09] <mup> PR snapd#6530 closed: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core <Squash-merge> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6530>
[09:16] <mup> PR snapd#6472 closed: overlord: fix ensure before slowness on Retry <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6472>
[09:23] <zyga> hmm, build failed on https://travis-ci.org/snapcore/core/builds/444677088
[09:23] <zyga> sil2100: are you looking after core builds with mvo?
[09:23] <zyga> or is that just mvo?
[09:23] <mup> PR snapd#6544 opened: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core (2.37) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6544>
[09:30] <sil2100> zyga: I think it's just mvo, I don't do much with core itself
[09:30] <zyga> I see, thanks
[09:30] <sil2100> Since core is still a snapd thingy ;)
[09:30] <pstolowski> pedronis: hey, do you have time today to talk about perf measurements?
[09:33] <pedronis> pstolowski: yes,  would in 45 mins work?
[09:33] <mborzecki> interesting, xdg-open does not work with portal-test snap, which uses core18 base
[09:33] <pstolowski> pedronis: yes
[09:33] <mborzecki> all i get is /usr/bin/xdg-open: 2: exec: snapctl: not found
[09:34] <pedronis> mborzecki: seems like a real bug
[09:34] <mborzecki> relevant strace https://paste.ubuntu.com/p/YsXvK7tYQW/
[09:35] <mborzecki> a random snap with core base works just fine
[09:36] <zyga> mborzecki: interesting
[09:36] <zyga> mborzecki: what is /usr/bin/xdg-open?
[09:36] <zyga> mborzecki: in core it was a special version that came from a PPA
[09:36] <zyga> perhaps we... missed that?
[09:36] <zyga> (should have upstreamed a patch to xdg-open)
[09:37] <mborzecki> zyga: no, it's a shell script that calls to snapctl user-open "$@"
[09:37] <zyga> mborzecki: that's good
[09:37] <zyga> what happens when you call snapctl user-open http://example.com/
[09:37] <zyga> does it work?
[09:38] <mborzecki> zyga: bash: snapctl: command not found :? hmm
[09:38] <zyga> oh
[09:38] <zyga> I know
[09:38] <zyga> is /usr/bin/snapctl there?
[09:38] <zyga> no? that's that :)
[09:38] <zyga> it's not on path
[09:38] <zyga> it's only in /usr/lib/snapd/snapctl
[09:38] <zyga> is it?
[09:38] <zyga> \o/
[09:39] <mborzecki> zyga: nope, not there
[09:39] <pedronis> in core it's a symlink
[09:39] <zyga> real bug
[09:40] <zyga> so...
[09:40] <oSoMoN> 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] <zyga> how does /usr/bin/snap work?
[09:40] <zyga> mborzecki: where is `snap` on core18?
[09:40] <mborzecki> btw. core18 is withouth snapd, so that content of /usr/lib/snapd i see is from the host?
[09:40] <pedronis> yes
[09:40] <zyga> oSoMoN: you cannot run apps this way, you can run executables but you will retain your current set of permissions
[09:40] <zyga> mborzecki: correct
[09:41] <zyga> oSoMoN: you can run anything via $SNAP/... (not /snap/bin)
[09:41] <zyga> oSoMoN: but as I said, if you have two apps with different permissions, you will not transfer the permissions over
[09:41] <mborzecki> is snapctl a symlink to /usr/lib/snapd/snapctl on ubuntu?
[09:41] <zyga> mborzecki: yes
[09:41] <pedronis> mborzecki: yes
[09:41] <zyga> mborzecki: not just on ubuntu
[09:42] <zyga> mborzecki: it should be that everywhere
[09:42] <pedronis> but it comes from the package
[09:42] <zyga> a symlink to ../lib/snapd/snapctl
[09:42] <oSoMoN> zyga, that probably won't work then… thanks for confirming
[09:43] <oSoMoN> I guess I'll have to split chromedriver into its own separate, classic snap
[09:43] <mborzecki> 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] <zyga> mborzecki: /usr/lib/snapd should not be on path anywhere
[09:43] <zyga> the bug is the symlink
[09:43] <zyga> mborzecki: but but but
[09:43] <zyga> mborzecki: you can use snapd.mk to fix arch package RSN
[09:43] <zyga> :D
[09:44] <zyga> I'm happy to help
[09:44] <mborzecki> zyga: haha ok
[09:44] <zyga> it handles all that
[09:44] <zyga> aaand it's in
[09:44] <mborzecki> zyga: but w8, if /usr/lib/snapd is not in $PATH inside snap executio env, how will xdg-open work then?
[09:44] <zyga> just got green :)
[09:44] <zyga> mborzecki: xdg-open works because snapctl is on path
[09:44] <zyga> via the symlink
[09:45] <mborzecki> unless core18 should ship a symlink then?
[09:45] <zyga> yeah, that's the next question
[09:45] <zyga> I ... think so
[09:45] <mup> PR snapd#6111 closed: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6111>
[09:45] <zyga> but perhaps mvo has some opinions
[09:45] <mborzecki> ah there is a symlink
[09:45] <zyga> oh?
[09:45] <mborzecki> yeah, bash is smart to not show it in completion when it's dead :/
[09:46] <zyga> ah
[09:46] <zyga> makes sense
[09:46] <zyga> why is it dead?
[09:46] <zyga> no snapctl in /usr/lib/snapd?
[09:46] <mborzecki> yup, ok, i'm gonna fix arch package then
[09:46] <zyga> try using snapd.mk
[09:46] <zyga> if it sucks for whatever reason please tell me
[09:47] <mborzecki> zyga: but it's in master only now, isn't it?
[09:47] <zyga> yeah
[09:47] <zyga> ah, i see what you meant now
[09:47] <zyga> for release do whatever makes sense
[09:47] <zyga> just for future reference packaging in master
[09:47] <mborzecki> so, it looks like we're missing a ... spread test :)
[09:48] <zyga> mborzecki: indeed!
[09:48] <zyga> but that's true of lots of core18 things
[09:48] <oSoMoN> 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] <mup> PR snapd#6545 opened: cmd/snap, daemon: make the connectivity check use GET <Created by chipaca> <https://github.com/snapcore/snapd/pull/6545>
[09:54] <mup> PR core#98 closed: Add force_turbo rpi option <Created by sergey-borovkov> <Closed by zyga> <https://github.com/snapcore/core/pull/98>
[09:54] <mup> PR core#102 opened: hooks: add force_turbo to PI_CONFIG_KEYS <Created by zyga> <https://github.com/snapcore/core/pull/102>
[09:56] <mborzecki> as a side note, since snapctl runs in snap mount ns, it should probably be built statically
[09:57] <zyga> mborzecki: yeah
[10:10] <mup> PR snapcraft#2487 closed: Release changelog for 3.2 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2487>
[10:20] <pedronis> pstolowski: in the standup ho?
[10:22] <zyga> https://github.com/snapcore/core/pull/102 this needs a review
[10:22] <zyga> ogra: ^
[10:22] <mup> PR core#102: hooks: add force_turbo to PI_CONFIG_KEYS <Created by zyga> <https://github.com/snapcore/core/pull/102>
[10:22] <mborzecki> pushing an update to arch package in a bit
[10:22] <pstolowski> pedronis: coming
[10:24] <zyga> brb, need to get daughter to school
[10:42] <zyga> re
[10:42] <zyga> 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] <zyga> blast from the pastQ
[10:44] <mborzecki> arch package updated
[10:44] <mborzecki> and we do have a symlink in our packaging/arch setup already
[10:50] <oSoMoN> 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] <zyga> +1
[10:54] <mup> PR snapd#6546 opened: packaging: build snapctl as a static binary <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6546>
[10:54] <mborzecki> zyga: ^^
[10:54] <zyga> looking
[10:55] <zyga> replied
[10:56] <zyga> I think snapd.mk doesn't handle snap-failure
[10:56] <zyga> what is that for?
[10:56] <vvug> Hi. Should I prefer the LibreOffice snap package or deb package? Which one is the best maintained one?
[10:57] <mborzecki> zyga: lest build a static tree :P
[10:57] <zyga> heh
[10:57] <zyga> vvug: both should be maintained but the snap should have more versions to choose from
[10:57] <zyga> vvug: for example, the classic package can be from a less recent major / minor versions
[10:57] <zyga> but with security fixes applied
[10:58] <Chipaca> zyga: snap only has 6.2.0.3 right now tho :-)
[10:58] <zyga> the snap package may offer multiple versions (including most recent one)
[10:58] <zyga> vvug: having said that, I'm not maintaining that snap, perhaps popey would know?
[10:59] <Chipaca> vvug: the snap package is 6.2.0.3 which is newer than any in-distro one fwiw
[10:59] <vvug> 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] <zyga> 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
[11:01] <vvug> 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] <zyga> vvug: just complexity, you get to see the intermediate points
[11:06] <pedronis> 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] <Chipaca> drat
[11:07]  * zyga gives Chipaca a battery for his calendar
[11:07]  * Chipaca hopes it's an artillery battery
[11:25] <mborzecki> wish systemctl had something like try-stop to return whether a stop action was actually executed or not
[11:25] <mborzecki> otherwise systemctl is-active .. && systemctl stop feels racy
[11:26] <Chipaca> mborzecki: why do you care?
[11:26] <Chipaca> mborzecki: i mean, stop works even if the thing is stopped
[11:27]  * pstolowski lunch
[11:27] <mborzecki> Chipaca: hmm maybe i shouldn't, otoh when patching mount units for selinux i can't restart them without affecting the services
[11:28] <Chipaca> mborzecki: mount units don't do reload?
[11:29] <mborzecki> Chipaca: they may do, but you cannot change a security context of a mounted block device
[11:29] <mborzecki> Chipaca: the kernel blocks it intentionally
[11:40] <pedronis> 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] <mup> PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356>
[11:40] <mup> PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6322>
[11:40] <pedronis> in case of doubt ask me
[11:41] <Chipaca> and conflicts!
[11:43] <tobikoch> Hi
[11:43] <tobikoch> Is there a way to skip the connectivity check during snapcraft cleanbuilds?
[11:44] <pedronis> Chipaca: that oo
[11:44] <pedronis> too
[11:44] <Chipaca> pedronis: did you understand the comment about the filter, or should I ask mvo?
[11:46] <pedronis> Chipaca: I think he is proposing that reRefreshUpdateMany be set to a function that hides the passing of the filter
[11:46] <pedronis> not sure if that messes with testing or not
[11:47] <pedronis> Chipaca: changing this line var reRefreshUpdateMany = updateManyFiltered
[11:47] <pedronis> to be = func ...
[11:52] <pedronis> Chipaca: I'm also not sure I like that change
[11:52] <pedronis> Chipaca: I think the issue is more with the name: reRefreshUpdateMany
[11:54] <Chipaca> pedronis: i.e. if it's for reRefresh already why does it need a filter?
[11:54] <pedronis> Chipaca: yes, I think that's his thinking (guessing here)
[11:55] <pedronis> the name implies it does the full job
[11:55] <Chipaca> yeah
[11:55] <Chipaca> 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] <zyga>   /me walk ...
[11:55] <pedronis> Chipaca: change that in which way? the name or the line?
[11:55] <Chipaca> the name
[11:55] <pedronis> ok
[11:56] <Chipaca> I'll call it totallyNotReRefreshUpdateManyMaybe
[11:56]  * Chipaca hides
[11:56] <pedronis> doingTheThingConsideringTheThingsAndTheTimeOfTheYear
[12:06] <Chipaca> pedronis: ...(thing Thing, things map[string]Thinger, moon moon.Phase) Result { …
[12:07] <pedronis> mborzecki: I did pass over #6079
[12:07] <mup> PR #6079: cmd/snap: `snap connections` command <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6079>
[12:07] <mborzecki> pedronis: thanks!
[12:07] <pedronis> Chipaca: ^ something for your list of things to look at as well
[12:07] <Chipaca> ack
[12:28] <Chipaca> pedronis: do you have a suggestion for a better name for the "laneSnaps" helper?
[12:32] <pedronis> Chipaca: refreshedSnaps ?
[12:32] <pedronis> the comment can say how their are determined, but is not so relevant to the role
[12:32] <pedronis> s/role/purpose/ of the function
[12:33] <Chipaca> pedronis: sgtm
[12:35] <zyga> back now
[12:35] <zyga> feels like spring now :)
[12:57] <dot-tobias> 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] <Chipaca> dot-tobias: is it a script, or a binary?
[12:58] <zyga> good hunch
[12:59] <dot-tobias> Chipaca: script, starts with shebang and only creates a directory in $SNAP_COMMON
[12:59] <zyga>  dot-tobias what is the interpreter?
[12:59] <Chipaca> zyga: no, just 'shebang' :-p
[12:59] <dot-tobias> #!/bin/sh -e, like in the docs
[12:59] <zyga> ah
[12:59] <zyga> dot-tobias: any apparmor denials?
[13:01] <dot-tobias> zyga: I'm trying in devmode, getting three STATUS messages with “profile_replace”, “same as current profile, skipping”
[13:01] <zyga> those are harmless
[13:01] <zyga> look for ALLOWED
[13:01] <dot-tobias> Nothing, just those three. (Note: I'm tailing /var/log/syslog during the install attempt, any other logs?)
[13:01] <zyga> mmm, that should be it
[13:01] <zyga> dot-tobias: can you report a bug with a reproducer please?
[13:02] <dot-tobias> zyga: Sure, will do
[13:04] <zyga>  what is https://github.com/snapcore/snapd/pull/6544 failing on
[13:04] <mup> PR #6544: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core (2.37) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6544>
[13:04] <zyga> I see it restarted over and over
[13:24] <mup> PR snapd#6513 closed: [RFC] many: support `snap install --skip-service-start` <⛔ Blocked> <Created by chipaca> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6513>
[13:25] <pedronis> zyga: master is green, so it would be something 2.37 specific
[13:36] <zyga> pedronis: I merged https://github.com/snapcore/snapd/pull/6544
[13:36] <zyga> are we ready for .4?
[13:36] <mup> PR #6544: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core (2.37) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6544>
[13:37] <mup> PR snapd#6544 closed: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core (2.37) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6544>
[13:39] <pedronis> zyga: I think so afaik
[13:40] <pedronis> I pinged mvo in tg
[13:44] <cwayne> zyga: will you be pushing a .4 to beta imminently?
[13:44] <zyga> no, not me
[13:44] <zyga> if anyone, mvo would
[13:45] <cwayne> I mean you as in the collective team :)
[13:45] <zyga> let me ask if he would consider this
[13:45] <zyga> mvo is off this week
[13:47] <cwayne> 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] <zyga> cwayne: mvo is on the road now, he will do it later today
[13:48] <cwayne> zyga: thanks for the headsu p
[13:48] <zyga> cwayne: I will let you know more once I konw
[13:48] <zyga> *know
[13:48] <cwayne> no worries, thanks man
[14:01] <Chipaca> pedronis: stdup?
[14:08] <mup> PR snapd#6547 opened: tests: enable opensuse tumbleweed on spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6547>
[14:10] <mup> PR snapd#6546 closed: packaging: build snapctl as a static binary <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6546>
[14:11] <dot-tobias> 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] <zyga> oh
[14:11] <zyga> layout for _entire_ /usr?
[14:11] <zyga> or for a sub-directory?
[14:11] <zyga> can you tell me more what your use case was?
[14:13] <dot-tobias> 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] <zyga> ok, thank you
[14:15] <zyga> I think we should warn / do something smart about layout for /usr
[14:15] <zyga> as that hides /usr/lib
[14:15] <zyga> and thus /usr/lib/snapd
[14:17] <zyga> cachio: https://en.opensuse.org/Lifetime -- openSUSE Leap 42.3 will be supported till the 30th of June
[14:17] <zyga> 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] <zyga> (that is switch 15.0 to 15.1)
[14:23] <mup> PR snapcraft#2490 opened: test: test-beta <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2490>
[14:27] <pedronis> 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] <pedronis> otherwise it can go in
[14:29] <pstolowski> pedronis: thank you, indeed, i will tweak it
[14:33] <jdstrand> 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] <jdstrand> Chipaca: is there something I should be doing differently? /me thought bionic and 1.10 would be good enough these days
[14:34] <zyga> oh
[14:34] <zyga> are we  using type aliases?
[14:34] <zyga> hey jdstrand :)
[14:35] <jdstrand> hey zyga :)
[14:35] <zyga> pedronis: https://github.com/snapcore/snapd/pull/6499 is a low hanging fruit, has +2, just needs your ack
[14:35] <mup> PR #6499: cmd/snap-confine: allow moving tasks to pids cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/6499>
[14:36] <mup> PR snapd#5962 closed: ifacestate/hotplug: integration with udev monitor <Complex> <Hotplug 🔌> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5962>
[14:42] <pstolowski> 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] <pstolowski> cachio: was it your suggestion?
[14:45] <Chipaca> zyga: for testing, yes
[14:45] <cachio> pstolowski, let me check
[14:46] <Chipaca> jdstrand: that should work from 1.9 onwards
[14:46] <Chipaca> jdstrand: where's the error from?
[14:46] <Chipaca> jdstrand: (we run the unit tests with 1.9 and 1.10 so it should all work)
[14:46] <jdstrand> Chipaca: run-checks
[14:47] <jdstrand> $ ./run-checks
[14:47] <jdstrand> ...
[14:47] <jdstrand> Checking for naked returns
[14:47] <jdstrand> could not parse input /home/ubuntu/gocode/src/github.com/snapcore/snapd/overlord/snapstate/export_test.go:221:19: expected type, found '='
[14:47] <cachio> pstolowski, it is required
[14:47] <jdstrand> $ go version
[14:47] <jdstrand> go version go1.10.4 linux/amd64
[14:47] <jdstrand> Chipaca: ^
[14:47] <pstolowski> cachio: ack, thanks for checking!
[14:47] <Chipaca> jdstrand: rebuild nakedret
[14:47] <cachio> pstolowski, np
[14:47] <Chipaca> jdstrand: :-)
[14:48] <cachio> pstolowski, it is a more powerfull machine than the regular ones
[14:53] <jdstrand> Chipaca: that seemed to work
[14:53] <Chipaca> jdstrand: huzzah :-)
[14:55] <jdstrand> Chipaca: thank you :)
[14:55] <Chipaca> jdstrand: np. Sadly there's no good way of rebuilding the tools conditionally
[14:56] <Chipaca> and non-conditionally slows things down without a huge gain
[14:57] <jdstrand> ack. I made a note in case this happens again
[16:31] <pstolowski> pedronis: https://github.com/snapcore/snapd/pull/6491/ has been updated with master and is ready for reviews
[16:31] <mup> PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491>
[16:35] <zyga> pstolowski: any luck with there LMP board for your work?
[16:37] <pstolowski> zyga: i didn't have time yet to check it out
[16:53] <Wimpress> Snapcraft Live starts in a few minutes - https://www.youtube.com/watch?v=B4OFvrwoZ8I
[16:55]  * zyga goes after the forum :-)
[16:55] <zyga> Wimpress: nice, I wish I could watch that now
[16:57] <Chipaca> zyga: keep the tab going in the background, it's like being at a sprint or sth
[16:59] <mup> PR snapd#6542 closed: cmd/snap: fix `snap services` completion <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6542>
[17:01] <zyga> Chipaca: I would but the people studying around me might complain :-)
[17:02] <Chipaca> zyga: it's in a different language, it doesn't interfere
[17:02] <Chipaca> right?
[17:03] <zyga> I’d ask but I’m just starting ;-)
[17:06] <cwayne> zyga: they should be studying snapcraft anyway
[17:06] <cwayne> its a favor really
[17:15] <mup> PR snapd#6547 closed: tests: enable opensuse tumbleweed on spread <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6547>
[17:46] <Chipaca> popey: I need to report a bug in word-salad :-)
[17:50] <popey> haha
[17:51] <popey> https://github.com/popey/word-salad-snap/issues
[17:51] <Chipaca> need to EOD now, but I'll file a pr later :-)
[18:00] <roadmr> zyga: are you around? ;)
[20:11] <mup> PR snapd#6548 opened: release: snapd 2.37.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6548>
[20:24] <zyga> roadmr: re (though I won't be long)
[20:25] <roadmr> zyga: oh, it was about that thing about the store :)
[20:25] <zyga> ack
[20:39] <jdstrand> roadmr: hi! can you pull r1190 of the review-tools. This would be best for a Monday/Tuesday deploy. I rewrote the snap decl checks for better clarity, quality and maintenance and fixed various bugs. all the old unit tests pass (167 iirc) as well as new ones
[20:40] <roadmr> jdstrand: great! thanks! sure, I'll put it in the queue
[20:40] <jdstrand> roadmr: thanks! :)
[22:43] <mup> PR snapd#6549 opened: apparmor: support AppArmor 2.13 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6549>