[01:07] <mup> PR snapcraft#2967 opened: requirements: uprev click to 7.1.1 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2967>
[06:11] <mborzecki> morning
[07:02] <mborzecki> re
[07:04] <zyga> Good morning
[07:04] <mborzecki> zyga: hey
[07:04] <zyga> I fixed the exec env bug but it will take me some more time to adjust tests in two packages
[07:04] <zyga> I made it impossible to easily cause bugs like that again
[08:02] <pstolowski> mornings
[08:05] <mborzecki> pstolowski: mvo: morning
[08:07] <mvo> mborzecki: good morning
[08:07] <mvo> and good morning to pstolowski
[08:08] <pstolowski> o/
[08:10] <zyga> hey pawel
[08:10] <zyga> mvo: I'm considering taking today off
[08:10] <zyga> I feel super tired somehow
[08:10] <zyga> I will work some more on wrapping up two things from yesterday
[08:10] <zyga> and EOD around noon
[08:23] <mup> PR snapd#8225 closed: snapcraft.yaml: use sudo -E and remove workaround <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8225>
[08:23] <mvo> zyga: sure, get well
[08:23] <zyga> mvo: I hope I'm not sick, I just feel tired
[08:23] <zyga> anyway, I'll finish what I have to first :)
[08:25] <mup> PR snapd#8233 closed: snap-confine: unconditionally add /dev/net/tun to the device cgroup <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8233>
[08:40] <mup> PR snapd#8214 closed: tests: test that after "remove-user" the system is unmanaged <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8214>
[08:41] <mup> PR snapd#8211 closed: tests: run ipv6 network-retry test too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8211>
[08:44] <mup> PR snapd#7999 closed: devicestate: allow encryption regardless of grade <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7999>
[09:19] <mup> PR snapd#7673 closed: interfaces/desktop: allow access to system prompter interface <Created by alexmurray> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7673>
[09:48] <amurray> mvo: thanks for merging my PR :)
[09:48] <mvo> amurray: thanks for making it in the first place :)
[09:59] <pedronis> pstolowski: hi, what's the status of #8201 ?
[09:59] <mup> PR #8201: tests: mock prune ticker in overlord tests to reduce wait times <Created by stolowski> <https://github.com/snapcore/snapd/pull/8201>
[10:00] <pstolowski> pedronis: hi; it's ready but i'm pondering if it makes sense to pass N to tick
[10:02] <pedronis> pstolowski: should we close #8198 ? afaiu mvo skipped some tests in 2.44 instead
[10:03] <mup> PR #8198: o/tests: bump TestEnsureLoopPruneAbortsOld sleep time <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8198>
[10:04] <pstolowski> done
[10:04] <mup> PR snapd#8198 closed: o/tests: bump TestEnsureLoopPruneAbortsOld sleep time <⛔ Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/8198>
[10:08] <mborzecki> we don't have a page that lists know model names do we?
[10:15] <pedronis> mborzecki: known in which sense?
[10:22] <mborzecki> pedronis: say, i forgot the actual model name for rpi3 on core18, not sure there's an easy way to find a list of model names of supported devices
[10:32] <pedronis> mborzecki: ah, no we don't have a list but should have one I suppose in the new UC docs (cc degville)
[10:33] <mborzecki> pedronis: our use case may be a bit weird, a i know where to find the models repo ;) others may not
[10:34] <mup> PR snapd#8234 opened: devicestate: support dropping "cloud.cfg" user-data cloud-init <Created by mvo5> <https://github.com/snapcore/snapd/pull/8234>
[10:48] <degville> pedronis / mborzecki: thanks for bringing this up. So, I guess I can get the model names from the model assertions (http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/). If so, I'll add them to the supported platforms page I've already created.
[10:51] <mborzecki> degville: sounds good, there's also a repository with model assertions right here https://github.com/snapcore/models in case it's useful
[10:51] <degville> mborzecki: brilliant, thanks!
[10:51] <mborzecki> degville: some of those are for core20 though
[10:52] <degville> mborzecki: ok, thanks.
[11:14] <pedronis> mborzecki: seems #8185 needs a master merge?  snapd-failover failed there (cc mvo)
[11:14] <mup> PR #8185: tests: add uc20 kernel snap upgrade managers test, fix bootloadertest bugs <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8185>
[11:16] <mborzecki> pedronis: i'll merge master and push there, hopefully it's not another unexpected failure more in snapd-failover
[11:17] <mvo> thanks mborzecki
[11:31]  * zyga has completed fixing snap environment
[11:31] <zyga> this was nice
[11:51] <mup> PR snapd#7731 closed: usersession/userd: add "apt" to the white list of URL schemes handled by xdg-open <⛔ Blocked> <Created by oSoMoN> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7731>
[11:51] <mup> PR snapd#8235 opened: cmd/snap-preseed: handle --reset flag <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8235>
[11:58] <mup> PR snapd#7588 closed: cmd/snap: add a "snap routine portal-info" command <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7588>
[12:05] <mup> PR snapd#8232 closed: interfaces: miscellaneous policy updates <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8232>
[12:11]  * zyga lunch
[12:12]  * zyga notices open season for PRs :)
[12:14] <mvo> zyga: haha - not quite, I think it's just the result of a week of staleness
[12:14] <jdstrand> mvo: hi! do you want a separate 2.44-specific PR for PR 8232?
[12:14] <mup> PR #8232: interfaces: miscellaneous policy updates <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8232>
[12:15] <ackk> hi, I'm seeing these errors when I "snap try" over the current running snap: https://paste.ubuntu.com/p/zQq2cFPCbM/ could it be related to the content interface?
[12:15] <jdstrand> mvo: also, is ijohnson off? if so, someone else can review PR 8231
[12:15] <mup> PR #8231: interfaces/{docker,kubernetes}-support: updates for lastest k8s <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8231>
[12:15] <zyga> mvo: can we merge https://github.com/snapcore/snapd/pull/8230 once green, I have a fix piled up on top and would love to reuse the branch
[12:15] <mup> PR #8230: cmd/snap-exec: add test case for LP:#1860369 <Created by zyga> <https://github.com/snapcore/snapd/pull/8230>
[12:16] <zyga> after lunch I'll address the uio issue raised by a customer
[12:16]  * zyga thanks jdstrand once again for insight on that topic
[12:16] <jdstrand> np :)
[12:22] <mvo> jdstrand: 8232> if it's not a burden to you, then yes
[12:22] <jdstrand> mvo: not at all! coming up :)
[12:23] <mvo> jdstrand: 8321> I think someone from the team can review it
[12:23] <mvo> zyga: 8230> we can merge once it has two reviews :)
[12:23] <zyga> it's just a test showing we have a bug, I guess we can get those quickly
[12:24] <ackk> with a simplified testcase I get: - Setup snap "maas" (unset) security profiles (cannot update mount namespace of snap "maas": cannot update preserved namespace of snap "maas": cannot update snap namespace: read-only file system)
[12:24] <mvo> zyga: uio> did you figure out more about this?
[12:24] <zyga> mborzecki: could you look at 8230 please, super easy
[12:24] <mvo> zyga: yeah
[12:24] <zyga> mvo: yes, mostly jdstrand did
[12:24] <jdstrand> mvo: thanks! I will continue to work on figuring out what to do with a weird k8s access with highest priority. I'd like to say it would be ready today, but I'm not sure yet
[12:24] <zyga> mvo: I can give you the details now or in the standup, as you wish
[12:24] <mvo> jdstrand: ok
[12:25] <mvo> jdstrand: I want to release 2.44-final this week but we are still early
[12:25] <mvo> zyga: either way is fine, maybe a tl;dr summary here?
[12:26] <zyga> mvo: tl;dr; is apparor-parser requires hand-holding without the optimizations that we disable; we disable them because they are very slow on smaller systems. The fix involves fine tuning the profile so that we don't hit this pathological case
[12:27] <jdstrand> mvo: ack. I'm trying not to cause you any delays! :)
[12:28] <mvo> jdstrand: :)
[12:28] <mvo> zyga: nice, thank you
[12:28] <zyga>  brb
[12:36] <mup> PR snapd#8236 opened: interfaces: miscellaneous policy updates - 2.44 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8236>
[12:36] <jdstrand> mvo: there you go ^
[12:36] <mvo> jdstrand: \o/
[12:37] <jdstrand> I'll do a similar on for PR 8231
[12:37] <mup> PR #8231: interfaces/{docker,kubernetes}-support: updates for lastest k8s <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8231>
[12:37] <mvo> jdstrand: +1
[12:40] <mup> PR snapd#8237 opened: interfaces/{docker,kubernetes}-support: updates for lastest k8s - 2.44 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8237>
[12:55] <pedronis> mborzecki: there's a arch failure in 8185 now: https://api.travis-ci.org/v3/job/660576207/log.txt
[13:02] <pedronis> pstolowski: did a pass on #8201, bunch of questions
[13:02] <mup> PR #8201: tests: mock prune ticker in overlord tests to reduce wait times <Created by stolowski> <https://github.com/snapcore/snapd/pull/8201>
[13:03] <pstolowski> pedronis: thanks
[13:11] <mborzecki> pedronis: hmm interesting, we had a workaround for a similar problem with snap services in one of the failover tests, restarted the travis job for now, but we'll probably need to add a litte fix tehre to make the test more robust
[13:11] <zyga> snapd/boot/export_test.go:38:14 uses type aliases
[13:14] <mup> PR snapd#8238 opened: many: fix a pari of ineffectual assignments <Created by zyga> <https://github.com/snapcore/snapd/pull/8238>
[13:16] <zyga> https://www.irccloud.com/pastebin/M7lC1BK4/
[13:16] <mup> PR snapd#8179 closed: interfaces: power control interface <Needs Samuele review> <⛔ Blocked> <Created by EthanHsieh> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8179>
[13:17] <zyga> pstolowski: is this still expected? overlordSuite.TestEnsureLoopPruneAbortsOld
[13:17] <zyga> pstolowski: IIRC you fixed it last week
[13:17] <pstolowski> zyga: yes, but not landed. the PR is being reviewed
[13:17] <zyga> ah
[13:17] <zyga> ok
[13:20]  * zyga switches to uio
[13:21] <mup> PR snapcraft#2967 closed: requirements: uprev click to 7.1.1 <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2967>
[13:28] <mup> PR snapd#8239 opened: interfaces/audio_playback: Fix pulseaudio config access [2.44] <Created by Erick555> <https://github.com/snapcore/snapd/pull/8239>
[13:29] <cmatsuoka> cachio: I retrieved the image and I'm booting it locally, it's failing in install mode but it's different from what we saw in Frankfurt
[13:32] <cmatsuoka> hmm, slightly different, but the cause seems to be the same
[13:42] <mup> PR snapd#8215 closed: interfaces: make the network-status interface implicit on classic <Created by jhenstridge> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8215>
[13:58] <mup> PR snapd#8239 closed: interfaces/audio_playback: Fix pulseaudio config access [2.44] <Created by Erick555> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8239>
[13:59] <mup> PR snapd#8236 closed: interfaces: miscellaneous policy updates - 2.44 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8236>
[14:00] <zyga> 2fa
[14:00] <zyga> logged out again?
[14:13] <mup> PR snapd#8240 opened: tests: just remove user when the system is not managed on create-user-2 test (2.44) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8240>
[14:13] <mup> PR snapd#8241 opened: interfaces: work around apparmor_parser slowness affecting uio <Created by zyga> <https://github.com/snapcore/snapd/pull/8241>
[14:15] <mup> PR snapd#8230 closed: cmd/snap-exec: add test case for LP:#1860369 <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8230>
[14:34] <mup> PR snapd#8242 opened: many: improve environment handling, fixing duplicate entries <Created by zyga> <https://github.com/snapcore/snapd/pull/8242>
[14:35] <zyga> ^ that's a longer PR sorry
[14:38] <zyga> mvo: about https://github.com/snapcore/snapd/pull/8242 -- let me know if you want a fix that's hacky but small and "maybe ok" for 2.44
[14:38] <zyga> mvo: otherwise I don't consider it a thing to rush
[14:38] <mup> PR #8242: many: improve environment handling, fixing duplicate entries <Created by zyga> <https://github.com/snapcore/snapd/pull/8242>
[14:39] <zyga> but please check as the bug affects microk8s
[14:39] <zyga> so perhaps we may have to
[14:39] <pstolowski> mvo: should the --reset be tagged for 2.44.x?
[14:39] <zyga> I did some impact analysis in the bug report, in comment 13
[14:39] <zyga> https://bugs.launchpad.net/snapd/+bug/1860369/comments/13
[14:39] <mup> Bug #1860369: Python apps broken in MicroStack (a classic snap) after Jan 14 snapcraft update <core20> <snapd:In Progress by zyga> <https://launchpad.net/bugs/1860369>
[14:41] <pedronis> mborzecki: now it (8185) failed again on arch and also fedora :/
[15:03]  * cachio lunch
[15:04] <mvo> pstolowski: +1
[15:04] <pstolowski> k
[15:23] <pstolowski> mvo: i remember you mentioned 'Core snap is installed when reverting a core18 based snap' ~last week; was the problem understood?
[15:30] <mvo> pstolowski: no :(
[15:30] <mvo> pstolowski: I think there is a bugreport and a testcase
[15:30] <mvo> pstolowski: but iirc noone looked at it
[15:30] <pstolowski> mvo: ack, ty
[15:35] <mvo> pstolowski: https://bugs.launchpad.net/snapd/+bug/1864944
[15:35] <mup> Bug #1864944: Core snap is installed when reverting a core18 based snap <original-1853411> <snapd:New> <https://launchpad.net/bugs/1864944>
[15:36] <mvo> pstolowski: it even has a test case that looks super easy to convert into ta spread test
[15:36] <pstolowski> mvo: yeah, i saw it, just wasn't sure if it was missing an update. i'm trying the steps right now
[15:37] <mvo> pstolowski: \o/
[15:55] <pstolowski> mvo: reproduced
[15:58] <mvo> pstolowski: nice!
[15:59] <zyga> back from break
[16:03] <pstolowski> mvo, pedronis: Revert() does not set base in snapsup, so it gets "core" by default
[16:04] <pedronis> pstolowski: ah
[16:04] <pedronis> good catch
[16:04] <mvo> pstolowski: \o/ nice find
[16:04]  * mvo hugs pstolowski 
[16:07] <zyga> pedronis: thank you for the review on environment PR
[16:07] <zyga> pedronis: I think we could chat about it tomorrow (or when you have time) to figure out what we want to do
[16:07] <zyga> pedronis: I'll spend the rest of today on fixing the uio performance bug to the point where the draft can be opened and we can try to cherry-pick that to 2.44
[16:08] <zyga> pedronis: but as I said to mvo earlier, I don't know the priority of the environment bug as it seems to affect microk8s
[16:08] <zyga> pedronis: could be low (workaround in snapcraft, perhaps) or higher (blocked on us)
[16:11] <pedronis> zyga: what's the bug number?
[16:11] <pedronis> anyway if this is the fix, we cannot rush it, it's kind of large
[16:12] <zyga> pedronis: I agree
[16:12] <zyga> pedronis: it's referred from the 2nd commit, let me find it
[16:12] <zyga> https://bugs.launchpad.net/snapd/+bug/1860369
[16:12] <mup> Bug #1860369: Python apps broken in MicroStack (a classic snap) after Jan 14 snapcraft update <core20> <snapd:In Progress by zyga> <https://launchpad.net/bugs/1860369>
[16:26] <pedronis> zyga: it seems the branch adds feature that were not there, like ignoring order of hook envs etc
[16:27] <zyga> ignoring order of hook envs?
[16:27] <pedronis> zyga: ApplyDelta seems much more powerful than SubstituteEnv
[16:28] <pedronis> (because of the changed check), I'm not sure fixing a bug and expanding feature should happen together unless they relate to each other
[16:29] <pedronis> zyga: SubsituteEnv says very precisely: "and substitutes them top-down from the given environment"
[16:32] <zyga> pedronis: while that is true I think we need to sit down and evaluate what is the semantics we want; We should check what is documented on snapcraft docs and if that makes sense. We should also check how adapters impact anything. I suspect that previous behavior was buggy in more than one way. At the same time I agree that ApplyDelta is more "able" than previous code and can result in what people meant more than what
[16:32] <zyga> people got
[16:33] <pedronis> zyga: I can only repeat my point, if we want this in quickly expanding feature is a problem
[16:34] <zyga> pedronis: I don't know if this is needed urgently, I hope it's not but in such case I also offered a small targeted branch that fixes PATH issue in a more hacky but controlled way
[16:35] <zyga> pedronis: I think we should discuss and figure out how to evolve the bigger branch to the point where we are happy with it as my main goal was to fix the type system of the problem. We can discuss and change specific bits of implementation if what I did would affect existing snaps in a way we didn't intend
[16:35] <pedronis> zyga: have you tried what happens with the new code and a circular reference ?
[16:35] <zyga> I don't believe I have, unless one of the existing tests has effective circular refs
[16:35]  * zyga looks
[16:37] <zyga> pedronis: both get expanded to empty
[16:38] <zyga> pedronis: there's an existing test for that
[16:38] <zyga> pedronis: in env_test.go:265
[16:39] <zyga> (it behaved this way before as well)
[16:39] <pedronis> yes, but for different reasons
[16:47] <mup> PR snapd#8243 opened: o/snapstate: set base in SnapSetup on snap revert <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8243>
[16:47] <pstolowski> mvo: ^
[16:50] <zyga> pedronis: I think this is interesting https://github.com/snapcore/snapd/pull/8242#discussion_r390461058
[16:50] <mup> PR #8242: many: improve environment handling, fixing duplicate entries <Bug> <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8242>
[16:51] <zyga> pedronis: I want to EOD soon as I want to sleep a little longer today, would you mind if we parked this until tomorrow?
[16:51] <zyga> pedronis: I want to spend some more time on the uio code
[16:51] <pedronis> zyga: that's fine, my general input that we should try to be more convervative with the change
[16:52] <zyga> I agree
[16:52] <mvo> pstolowski: nice, thank you
[16:52] <zyga> I wonder what people would expect in the example I gave, I think it's a good chance we will get 50-50 responses
[16:52] <pstolowski> eod, need to run an errand
[16:52] <zyga> pedronis: note that current code (in master) just inserts both PATH values, because of the bug
[16:53] <zyga> so you kind of get a superposition :)
[16:53] <zyga> but that's for sure not what we want
[16:53] <pedronis> unless we promised that we merge values
[16:53] <pedronis> the one in the app should win
[16:53] <cjp256> zyga/pedronis: the priority for build env is high for core20, as it won't generate command wrappers.  snapcraft currently forces the wrappers for when adapter != none, and it became a problem when we stopped generating unnecessary wrappers
[16:54] <cjp256> but core20 still isn't for some time, so it's not a rush imo :)
[16:55] <zyga> pedronis: I wonder if the fact that this was shoved through shell wrappers meant that we got the expanding semantics at any time in the past
[16:55] <zyga> pedronis: tomorrow I'll write a regression test for this
[16:55] <zyga> pedronis: as in end-to-end spread test
[16:55] <zyga> pedronis: at least then it's measured
[17:03] <mvo> cachio: if you could double check and approve 8240 that would be great
[17:09] <mvo> zyga: are you around? I wonder how 1866424 should be attacked, it seems a missing gpio should not cause snapd to stop refreshing forever
[17:09] <zyga> around
[17:09] <mvo> zyga: I wonder if we could make missing gpios a warning?
[17:09] <zyga> mvo: "ish", the problem is what you want to happen then
[17:09] <mvo> zyga: but it's a bit tricky as it's a real error
[17:09] <zyga> but yeagh
[17:09] <mvo> zyga: yeah, the gpio will be missing from the profile
[17:09] <zyga> it's not really missing, the user was holding it wrong (unexporting behind snapd's back)
[17:10] <mvo> zyga: so subsequent stuff may misbehave
[17:10] <zyga> but I agree it's a very bad property
[17:10] <zyga> mvo: consider this idea:
[17:10] <zyga> mvo: when an interface instance (plug or slot)'s corresponding method fails, we could mark it as bad and skip it in the profile generation
[17:10] <zyga> mvo: we could warn (finally a use case for warnings)
[17:11] <zyga> mvo: it would require some changes around but not too hard
[17:11] <zyga> mvo: I would rather do it at interface level
[17:11] <zyga> mvo: rather than at the level of a specific method
[17:11] <zyga> mvo: because it's more proper, in my eyes, to say "this plug or slot is entirely absent"
[17:11] <mvo> zyga: yeah, the downside of that is that it requires more discussion/work so it will take longer but I agree
[17:12] <zyga> mvo: rather than to say "a specific part of the implementation failed so we skipped it"
[17:12] <zyga> mvo: since those can have security implications
[17:12] <zyga> mvo: .e.g. apparmor gave you access to /dev but udev tagging failed so you have open access
[17:13] <mvo> zyga: aha, indeed, I was thinking we would only narrow access down
[17:13] <zyga> unfortunately that is not the case
[17:13] <zyga> mvo: I could look at that after UIO tomorrow
[17:13] <mvo> zyga: yeah, makes sense. i pasted what you wrote into the bug
[17:14] <zyga> mvo: if you have an agreement on the design
[17:14] <mvo> zyga: that would be nice indeed
[17:14] <zyga> perfect, thank you
[17:14] <mvo> zyga: it sounds like we can have a quick chat during standup/after stnadup
[17:14] <zyga> that sounds good
[17:14] <zyga> what I said has a scary component
[17:14] <mvo> zyga: we certainly need samuele to think about it/agree :)
[17:14] <zyga> because what it means if an implicit slot misbehaves?
[17:14] <zyga> mvo: does it mean it is disconnected
[17:14] <zyga> is it broken?
[17:15] <zyga> some things to ponder over
[17:15] <mvo> zyga: we could error in those cases maybe?
[17:15] <zyga> yes but the devil is in the details, a single interface (plug or slot) interacts with loads of parts
[17:15] <zyga> in my eyes it would be neutered _for the purpose of a given connection_
[17:15] <zyga> so not globally
[17:16] <zyga> so less chance to break the world
[17:16]  * mvo nods
[17:22]  * zyga EODs without finishing UIO
[17:23] <zyga> I'm sorry, need to rest
[17:26] <mvo> zyga: no worries, get some good rest!
[18:49] <mup> PR snapcraft#2965 closed: rosdep: include EOL ROS distros <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2965>
[19:04] <mup> PR snapcraft#2964 closed: build providers: remove LXD specific env setup <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2964>
[19:24] <ogra> $ grep ubuntu /etc/group
[19:24] <ogra> sudo:x:27:ubuntu
[19:24] <ogra> docker:x:113:ubuntu
[19:25] <ogra> hmm, so why are there entries for a non-existing ubuntu user in my readonly /etc/group file in core16
[21:53] <mup> PR snapcraft#2962 closed: Go: unable to build snap when using `go mod` and main package is not in the root <Created by pavel-d> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2962>