[00:08] <mup> PR snapcraft#2968 opened: git: always fetch specified source-commit before using <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2968>
[04:18] <mup> Bug #1857358 changed: Not yet operational on Fedora systems <fedora> <Snappy:Expired> <https://launchpad.net/bugs/1857358>
[06:20] <mborzecki> morning
[06:20] <mvo> hey mborzecki
[06:20] <mup> PR snapd#8240 closed: tests: just remove user when the system is not managed on create-user-2 test (2.44) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8240>
[06:35] <mvo> mborzecki: a second review for 8231 would be great
[06:37] <mborzecki> mvo: wow, that AARE for nvme is scary ;)
[06:38] <mup> PR snapd#8231 closed: interfaces/{docker,kubernetes}-support: updates for lastest k8s <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8231>
[06:40] <mborzecki> school run, back in 30
[06:40] <mvo> mborzecki: aare?
[07:07] <mup> PR snapd#8243 closed: o/snapstate: set base in SnapSetup on snap revert <Bug> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8243>
[07:08] <mborzecki> re
[07:08] <mborzecki> mvo: apparmor regular expressions
[07:10] <mvo> mborzecki: aha, right
[07:11] <mborzecki> and with the latest regulations, parents can no longer enter school buildings, at least in my area
[07:12] <mborzecki> wouldn't be surprised if they close down all schools for a week or so
[07:14] <mvo> mborzecki: that's likely to happen
[07:14] <mvo> I think
[07:20] <mborzecki> hm the failures in 8185 that pedronis saw yday is probably services-watchdog test state leaking into subsequen tests
[07:28] <mup> PR snapd#8185 closed: tests: add uc20 kernel snap upgrade managers test, fix bootloadertest bugs <Test Robustness> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8185>
[07:48] <mup> PR snapd#8238 closed: many: fix a pair of ineffectual assignments <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8238>
[07:52] <mvo> mborzecki: I think 8206 is ready for a review too and hopefully an easy win
[07:52] <mvo> mborzecki: we are at 52 now, maybe we can hit 50!
[07:53] <mup> PR snapd#8237 closed: interfaces/{docker,kubernetes}-support: updates for lastest k8s - 2.44 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8237>
[07:53] <mvo> mborzecki: we have some simple ones like 8220 pending (unfortunately I think this one needs a security review)
[07:53] <mborzecki> mvo: ha, so it was a hanging sleep command
[07:55] <mvo> mborzecki: yes
[07:58] <zyga> good morning
[07:58] <zyga> how are things?
[07:58] <mborzecki> mvo: maybe we should set Ptdeahtsig to syscall.SIGKILL for most commands, not sure we use it at all
[07:59] <mborzecki> zyga: morning
[08:02] <mvo> mborzecki: I think we don't
[08:02] <mvo> hey zyga
[08:06] <pstolowski> morning
[08:06] <mborzecki> pstolowski: hey
[08:07] <mborzecki> mvo: #8206 is green!
[08:07] <mup> PR #8206: travis.yml: run unit tests on arm64 as well <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8206>
[08:21] <mvo> zyga: want to double check 8100 ? it got your +1 already but it changed a bit since (more abstractions mostly)
[08:22] <zyga> yeah sure
[08:22] <mvo> zyga: shoudl be simple
[08:22] <zyga> I am in despair
[08:22] <zyga> found my gpg key
[08:22] <zyga> and it's locked
[08:22] <zyga> and I don't recall the password :)
[08:26] <mup> PR snapd#8206 closed: travis.yml: run unit tests on arm64 as well <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8206>
[08:26] <mvo> one more and we are down to 50! maybe 8197? no code change just a refactor for snap downloads via snapd?
[08:27] <mvo> zyga: oh no!
[08:33] <zyga> some heavy rain today
[08:46] <mborzecki> mvo: i'm not dropping SetRecoverySystemEnv from uboot struct yet, for now i've updated ExtractedRecoveryKernelImage.. iface
[08:47] <mborzecki> mvo: although i don't expect needing to use SetRecoverySystemEnv, we'll know for sure after the meeting with the foundations
[08:54] <mvo> mborzecki: +1
[08:55] <mvo> mborzecki: I also added samuele as optional, not sure if he wants to join or not
[08:55] <mborzecki> ok
[08:58] <mborzecki> pedronis: hi, #8224 has conflicts now
[08:58] <mup> PR #8224: many: clean separation of bootenv mocking vs mock bootloader kinds  <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8224>
[08:59] <pedronis> mborzecki: yes, saw that, will try to merge master and address at least partially the XXXs soon
[08:59] <pedronis> mborzecki: thx
[09:01] <mvo> pstolowski: thanks for your update to 8201!
[09:01] <pstolowski> mvo: np. i'm nervous to see if it passes
[09:02] <mvo> pstolowski: heh :)
[09:02] <mvo> pstolowski: *fingers crossed*
[09:02] <zyga> mvo: can you please refresh my memory
[09:02] <zyga> how is snap-repair updated?
[09:04] <mvo> zyga: snap-repair is part of the snapd snap and gets updated when snapd gets updated, was that the question?
[09:04] <zyga> yes, that's mostly it
[09:04] <zyga> I recall we had a copy of snap-repair in core16 systems
[09:04] <zyga> somewhere in writable
[09:05] <zyga> is that the case?
[09:05] <mvo> zyga: I think we talked about it, I don't recall we did it
[09:06] <pedronis> mvo: it's still a todo
[09:06] <zyga> ok, that's what I was curious about thanks
[09:07] <pedronis> mvo: there are still current todos:  https://forum.snapcraft.io/t/repair-capability-emergency-fixes/311/39 and https://forum.snapcraft.io/t/repair-capability-emergency-fixes/311/42
[09:08] <pedronis> so the packaging bits, the task for this cycle, plus consider how early it can be run
[09:10] <mvo> yeah :/
[09:11] <zyga> I wonder if snap-repair makes sense in core 20 world
[09:14] <pedronis> it has a role, going through a recovery reboot is not always acceptable especially if there are other solutions
[09:14] <pedronis> otoh it hasn't been used yet for real, so hard to judge
[09:18] <zyga> mvo: reviewed
[09:20] <pedronis> pstolowski: I reviewed 8201, it needs a 2nd review
[09:22] <pstolowski> pedronis: ty
[09:41] <mvo> pedronis, pstolowski I did a pass on 8201
[09:42] <pstolowski> mvo: thanks!
[09:43] <mvo> pstolowski: hope it's not too annoying
[09:43] <pstolowski> mvo: no worries
[09:54] <pedronis> mvo: the extra ticks might be do go through Ensure as well
[09:54] <pedronis> it's not just about prune
[09:54] <pstolowski> yes. but i'll add a comment
[10:03] <mvo> pedronis: thanks, could be, I am just puzzled because AIUI we only mock the ticks for the pruneC and that calls st.Prune() directly, so not sure how Ensure() comes into play. but it's fine, it's so much nicer than before, just tried to get a good understanding what is going on
[10:04] <pedronis> mvo: aborting might need two passes through Ensure
[10:04] <pedronis> mvo: each time we tick prune we also go throgh Ensure
[10:04] <pedronis> or something like that
[10:05] <mvo> pedronis: ok
[10:10] <mvo> cachio: good morning! if you still see this failure of importing the user assertion on uc20 even in the second boot, could you please pastebin/take-a-picture of "journalctl -u systemd-udevd" from the second boot in run mode?
[10:22]  * zyga feels so so and goes for some tea/coffee upstairs
[10:22] <zyga> pedronis: when I'm back I'll attack env again
[10:22] <zyga> pedronis: I read your comments and I'll go and simplify the expression logic and combine it all into Apply
[10:35] <cachio> mvo, sure
[10:35] <cachio> mvo, good morning, I just triggered a new run
[10:36] <cachio> mvo, yesterday it was not goind the run mode, just install mode
[10:36] <cachio> I was waiting for the new core snap that should help on that
[10:37] <mvo> cachio: ok
[10:37] <mvo> cachio: thank you
[10:41] <cachio> mvo, today it is going into the run mode
[10:41] <cachio> https://paste.ubuntu.com/p/n6GJpXNjwQ/
[10:41] <cachio> but still it is not importing the user assertion
[10:42] <pedronis> zyga: I added some more comments about further simplifications I would like to see for now
[10:42] <zyga> pedronis: ok
[10:42] <zyga> I'll read them now
[10:44] <pedronis> zyga: let me know if you have questions
[10:44] <zyga> ack
[10:44] <mvo> cachio: can you do a reboot once it's in run mode and paste me the output of "journalctl -u systemd-udevd" please?
[10:45] <zyga> weird
[10:45] <cachio> yes, waiting for the reboot
[10:45] <zyga> github comments I mean
[10:45] <zyga> I can respond to some of your comments but not all
[10:45] <zyga> pedronis: I was thinking and I'm very happy with []osutil.ExpandableEnv
[10:45] <zyga> because that removes the need for some extra glue logic
[10:46] <zyga> and expresses more naturally what is really going on
[10:46] <pedronis> mvo: do we have a formatting problem in interfaces/policy/basedeclaration_test.go or it's just different go versions
[10:46] <cachio> mvo, https://paste.ubuntu.com/p/GZsNPyNRCC/
[10:46] <mvo> pedronis: I'm not aware of one, but it could be go version screw
[10:47] <zyga> pedronis: I ony edit that file in nano
[10:47] <pedronis> zyga: as far as I know there's no way to "merge" those envs before applying them, that would do what we need
[10:47] <zyga> pedronis: yeah, I came to the same conclusion
[10:47] <zyga> pedronis: I'll get to it :)
[10:48] <pedronis> zyga: we can probably also leave out the Overrides bit from those methods, and just call them Envs() []osutil.ExpandableEnv
[10:49] <zyga> pedronis: I just wanted something that is distinct from the field (Environment)
[10:49] <zyga> pedronis: perhaps we don't need a real method after all
[10:50] <zyga> pedronis: if we change the type to ExpandableEnv
[10:50] <zyga> we can just reach out to app.Snap.Environment and app.Environment
[10:50] <zyga> but we'll see
[10:50] <zyga> first some of the big moves
[10:51] <pedronis> mborzecki: I merged master and updated #8224, the last changes need a new pass
[10:51] <mup> PR #8224: many: clean separation of bootenv mocking vs mock bootloader kinds  <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8224>
[10:53] <mvo> cachio: thanks, do you see /lib/udev/rules.d/66-snapd* in your image?
[10:54] <cachio> I cant login to the image
[10:55] <cachio> but let me check if I can unsquash it
[10:55] <mvo> cachio: oh, so the journal output is also not from inside the image?
[10:55] <cachio> no
[10:55] <cachio> the journal output is from the host machine
[10:56] <cachio> in that case let me try to shell on it
[10:57] <mvo> cachio: ok, we probably need to somehow create an image that you can add "systemd.debug-shell=1" to the kernel commandline so that you get a root-shell
[10:57] <mvo> cachio: the output of the udevd would be great to have, that hopefully gives us clues what is brekaing
[10:57]  * mvo needs to leave for a wee bit
[10:58] <cachio> {
[10:58] <cachio> ok
[11:01] <zyga> kid invasion
[11:01] <zyga> silly stuff is lucyasd=ad
[11:01] <zyga> 4WT~WWW
[11:03] <pstolowski> noo, #8201 failed on google:ubuntu-core-20-64:tests/core/snapd-failover. and on prepare for fedora. and on google-unstable:opensuse-15.1-64:tests/main/session-tool
[11:03] <mup> PR #8201: tests: mock prune ticker in overlord tests to reduce wait times <Squash-merge> <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8201>
[11:04] <pstolowski> ^ zyga
[11:04] <pstolowski> zyga: https://api.travis-ci.org/v3/job/660982235/log.txt
[11:04] <zyga> pstolowski: ack,
[11:05] <zyga> pstolowski: there must be something I'm missing there
[11:05] <zyga> as it only fails infrequently, there must be some kind of race that makes PAM module which sets up XDG_RUNTIME_DIR fail
[11:07] <pstolowski> zyga: grab the log if you need it, i'm going to restart the tests soon
[11:07] <zyga> done
[11:19] <cachio> mvo, https://pastebin.com/Gh8rrwNP
[11:20] <cachio> for some reason it is getting stuck in that line
[11:20] <cachio> the shell never appeards
[11:20] <mborzecki> hmm arm64 unit tests still hanging?
[11:20] <cachio> mvo, could you chekc pleaseif I did it correctly?
[11:20] <cachio> mvo, https://paste.ubuntu.com/p/fHTdPT2j6Q/
[11:22] <mvo> cachio: please try setting it in  �*Run Ubuntu Core 20                                                         �
[11:22] <mvo> cachio: so when the second grub screen is there you need to press "e" for edit
[11:22] <mvo> cachio: and it in the line with the chainload...kernel.efi there
[11:22] <mvo> cachio: does that make sense?
[11:23] <cachio> mvo, ok, thanks
[11:23] <mvo> cachio: not sure if it gives you a debug shell on the serial console though, gives you one on vt9 for sure
[11:26] <cachio> mvo, I did what you said but it is getting stuck in the same line
[11:27] <cachio> mvo, https://paste.ubuntu.com/p/S8gQq64WPq/
[11:37] <mvo> cachio: oh no! maybe you just don't get a debug shell on the serial port :/ that's sad
[11:41] <cachio> mvo, do you want to connect?
[11:41] <mvo> cachio: not right now, I need to ponder a bit, I will probably need to try to run this locally in qemu to have the full vritual console access :/
[11:42] <cachio> ok, just ping me in case you need the image
[11:46] <mvo> mborzecki: I pushed https://github.com/snapcore/pi-gadget/pull/34
[11:46] <mup> PR pi-gadget#34: gadget.yaml: move ubuntu-boot to VFAT <Created by mvo5> <https://github.com/snapcore/pi-gadget/pull/34>
[11:55] <mup> PR snapd#8100 closed: httputil: add support for extra snapd certs <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8100>
[12:07] <mup> PR snapd#8244 opened: [RFC] config: add system.certs.[a-zA-Z0-9] support <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8244>
[12:21] <zyga> mvo: commented on the pi-gadget PR
[12:24]  * pstolowski lunch
[12:25] <mup> PR snapcraft#2963 closed: project: add fallbacks for os.sched_getaffinity <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2963>
[12:27] <mvo> zyga: thanks
[12:44] <cachio> mvo, hey
[12:44] <cachio> I am trying from serial port and I get this
[12:44] <cachio> https://paste.ubuntu.com/p/6RkcpYd4TV/
[12:49] <cachio> mvo, the following run I did't see tha terror https://paste.ubuntu.com/p/Cfkv2w7mfT/
[12:53] <mvo> cachio: this looks like a OVMF bug, I wonder what version is available in gce
[12:56] <cachio> ovmf:
[12:56] <cachio>   Installed: 0~20191122.bd85bf54-2
[12:56] <cachio>   Candidate: 0~20191122.bd85bf54-2
[12:56] <cachio>   Version table:
[12:56] <cachio>  *** 0~20191122.bd85bf54-2 500
[12:56] <cachio>         500 http://us-east1.gce.archive.ubuntu.com/ubuntu focal/main amd64 Packages
[12:56] <cachio>         100 /var/lib/dpkg/status
[12:57] <cachio> mvo, is it ok?
[13:04] <pedronis> mvo: can we turn off arm tests again, they timeout: https://travis-ci.org/github/snapcore/snapd/jobs/661020356?utm_medium=notification&utm_source=github_status
[13:04] <pedronis> sometimes
[13:17] <zyga> pedronis: type Foo *Bar behaves in odd ways in go
[13:17] <zyga> that hides the entire method set of Bar
[13:17] <zyga> is there any way to "reach" it?
[13:21] <pedronis> zyga: that's annoying, I missed this detail, or forgot it
[13:22] <mup> PR snapcraft#2969 opened: snap: re-add xml development packages for non x86 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2969>
[13:23] <pedronis> zyga: anyway the text here https://golang.org/ref/spec#Method_sets has that implication
[13:30] <zyga> thanks
[13:30] <pedronis> zyga: so embedding the OrderedMap seems the only solution
[13:30] <zyga> yeah, I see that
[13:31] <zyga> I think type a = b would be nicer
[13:31] <zyga> but we cannot for now
[13:31] <zyga> ok, I'm not blocked, thank you
[13:49] <zyga> suspend resume on linux with fractional scaling in gnome resizes everything, clipping parts of windows
[13:49] <zyga> oh well
[13:57] <mvo> pedronis: sure, let me do that
[13:59] <mup> PR snapd#8245 opened: travis: disable arm64 again <Created by mvo5> <https://github.com/snapcore/snapd/pull/8245>
[14:40] <mup> PR snapd#8244 closed: [RFC] config: add system.certs.[a-zA-Z0-9] support <Needs Samuele review> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8244>
[14:40] <mup> PR snapd#8246 opened: client, daemon, overlord/devicestate: structures and stubs for systems API <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8246>
[14:40] <mborzecki> pedronis: ^^
[14:52] <mup> PR snapd#8245 closed: travis: disable arm64 again <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8245>
[14:52]  * cachio lunch
[15:03]  * zyga lunch as well
[15:03] <zyga> and small break to fix backup server
[15:04] <mup> PR snapd#8247 opened: .travis.yml: enable arm64 again as unstable <Skip spread> <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8247>
[15:59] <pedronis> mborzecki: I queued it
[15:59] <pedronis> thx
[16:07]  * zyga is back to finish work
[16:08] <mvo> pstolowski: 8201 is green, do you want to squash merge it and edit the description? I will cherry pick to 2.44 then
[16:09] <zyga> offtopic, firefox is really really fast
[16:13] <pstolowski> mvo: yes, let's squash merge
[16:14] <pstolowski> mvo: doing
[16:14] <mvo> pstolowski: thank you!
[16:15] <mup> PR snapd#8201 closed: tests: mock prune ticker in overlord tests to reduce wait times <Reviewed> <Squash-merge> <⚠ Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8201>
[16:21] <mup> PR snapd#8248 opened: snap: introduce Container.RandomAccessFile <Created by pedronis> <https://github.com/snapcore/snapd/pull/8248>
[16:33] <pedronis> zyga: I looked at the uio fix, one question, also I notice that one of jdstrand comment isn't addressed, it didn't sound just a nice to have from him, in one form or the other
[17:06] <mup> PR snapd#8249 opened: interfaces: make gpio robust against not-existing gpios in /sys <Created by mvo5> <https://github.com/snapcore/snapd/pull/8249>
[17:07] <zyga> pedronis: hmm, which comment was that?
[17:07] <zyga> pedronis: the one about ordering?
[17:07]  * zyga looks
[17:07] <pedronis> yes
[17:09] <zyga> pedronis: I would not do that in this PR, as I explained in my response that's not a new property and doing anything better (for auditing) would require a smaller dive into the apparmor backend. Doable but not for 2.44 IMO
[17:10] <mup> PR snapd#8250 opened: tests: mock prune ticker in overlord tests to reduce wait times (2.44) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8250>
[17:10] <pedronis> zyga: I understand, let's see what he says
[17:11] <zyga> ok
[17:12] <zyga> if needed I can probably implement that ordering tomorrow if I didn't take the swap day
[17:12] <pedronis> is he around today?
[17:12] <zyga> I haven't seen him yet, let me check mail
[17:13] <zyga> no mail about absence (which he carefully sends each time) so I would assume he's around
[17:16] <mup> PR snapd#8251 opened: overlord: remove unneeded overlord.MockPruneInterval() mocks <Created by mvo5> <https://github.com/snapcore/snapd/pull/8251>
[17:25] <zyga> so
[17:25] <zyga> pedronis: env question
[17:25] <zyga> pedronis: snap run --shell foo
[17:25] <zyga> I guess we should apply the environment then, right?
[17:25] <zyga> I guess we should
[17:26] <zyga> I didn't look there deeply, just realized we do that "late" in snap-exec
[17:26] <zyga> and not in snap-confine
[17:44] <jdstrand> zyga: fyi, https://github.com/snapcore/snapd/pull/8241#pullrequestreview-372983889
[17:44] <mup> PR #8241: interfaces: work around apparmor_parser slowness affecting uio <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8241>
[17:44] <zyga> jdstrand: checking
[17:44] <jdstrand> zyga: conditional ack provided one small change. while doing that, you might do: s/clariry/clarity/
[17:45] <zyga> jdstrand: sure
[17:45] <zyga> jdstrand: I get it, that's sensible,
[17:45] <jdstrand> thanks!
[17:46]  * zyga needs to apologize to everyone, school is cancelled across the country and kids got crazy and are really bothering me all the time now
[17:50] <pedronis> zyga: we should apply the enviroment yes, don't we atm ?
[17:50] <zyga> pedronis: I _hope_ so :)
[17:50] <zyga> I'll get there soon
[17:50] <zyga> pedronis: just thinking about this
[17:51] <zyga> there's some discrepancy between hook and app environment
[17:51] <zyga> specifically we don't perform the save-restore across setuid-lost environment
[17:51] <zyga> though _perhaps_ that's okay, but there's no comment to account for why
[17:52] <pedronis> zyga: as I mentioned, we should move that logic to osutil I think, though it's a bit of an orthogonal problem
[17:52] <pedronis> and not something I would try in this PR
[17:52] <zyga> ok
[17:55] <pedronis> zyga: basically ForExec and OSEnviroment should grow flags or variants to deal with that
[17:55] <zyga> mmm
[17:55] <zyga> I'll stash that as a follow up, close to finishing the changes for the comments in the PR so far
[17:57] <pedronis> zyga: it's relates to this comment here: https://github.com/snapcore/snapd/pull/8242#discussion_r390880508
[17:57] <mup> PR #8242: many: improve environment handling, fixing duplicate entries <Bug> <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8242>
[18:27] <zyga> pedronis: so env, all but Transform is now done
[18:28] <zyga> I had to invent a method name EnvStack() so please look if you like it
[18:28] <zyga> in any case it's just an implementation detail and doesn't change the big picture
[18:29] <zyga> I'll go after Transform and try to wrap up for today
[18:29] <zyga> mvo: I'll send the paperwork tomorrow
[18:29] <zyga> it's late today
[18:36] <mvo> zyga: sure, see you
[18:37] <cachio> mvo, quick question, I am working tieh the snapd-failover16 test which fails randomly
[18:37] <cachio> mvo, I see this line Mar 11 18:36:27 localhost.localdomain systemd[1]: Started Failure handling of the snapd snap.
[18:37] <cachio> but the service cant fix the dydtem
[18:38] <cachio> is any other source of information to take alook why?
[18:38] <mvo> cachio: hm, journalctl -u snapd.failure  should have some info
[18:39] <cachio> I got that info from there
[18:39] <cachio> I just see that it tries to fix it but no mere info
[18:40] <mvo> cachio: oh, so it tries to fix and fails :(
[18:40] <mvo> cachio: snapd and snapd.failure are the relevant sources
[18:40] <cachio> mvo, right
[18:40] <mvo> cachio: can you pastebin those two when the failure happens?
[18:41] <cachio> mvo, snapd https://paste.ubuntu.com/p/W67D9yf7PG/
[18:42] <cachio> snapd-failure https://paste.ubuntu.com/p/SxGVRzn8YH/
[18:42] <cachio> mvo, it happens right after it installs the snapd broken snap
[18:43] <mvo> cachio: interessting, is it random, i.e. does it sometimes work? or always failing currently?
[18:45] <cachio> first time worked, and 2nd failed
[18:45] <cachio> iwht this vm
[18:45] <cachio> I'll run again
[18:45] <mvo> cachio: so it's essentially random?
[18:45] <mvo> cachio: the logs are really not giving clues, that's a bit sad
[18:45] <cachio> mvo, not happening 100% of the times for sure
[18:46] <cachio> but can't say if it random or not
[18:46] <mvo> cachio: aha, could be another test polluting it?
[18:46] <cachio> mvo, yes, but still trying to figure out that
[18:47] <mvo> cachio: thanks
[18:48] <zyga> pedronis: done
[18:51] <zyga> mvo: if you want to get https://github.com/snapcore/snapd/pull/8242 in to 2.44 please organize some review tomorrow
[18:51] <mup> PR #8242: many: improve environment handling, fixing duplicate entries <Bug> <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8242>
[18:51] <mvo> zyga: is it blocking someone
[18:51] <zyga> mvo: I think it's affecting micro k8s
[18:52] <mvo> zyga: ok,, I need to find out how badly
[18:52] <mvo> zyga: I'm a bit worried that we delay too much
[18:52] <mvo> zyga: but I will look at it tomorrow with fresh eyes and an open mind :)
[18:54] <pedronis> zyga: did you change SetExpandEnv to take multiple ExpandableEnvs ?
[18:54] <zyga> no
[18:54] <zyga> because it's not needed now, it's just applied in chain with the same result
[18:54] <zyga> have a look
[18:54] <zyga> it's also simple, really just a thin wrapper to os.Expand
[18:54] <zyga> I did that briefly but it was just noisier
[18:55] <pedronis> ok
[18:55] <pedronis> I'll look, the diff is smaller, there might be some naming stuff to tweak
[18:55] <zyga> yeah, please feel free to push name tweaks directly to the PR
[18:55] <zyga> I believe everything essential is addressed
[18:56] <zyga> if you want it to take a list or varadic list strongly I don't mind
[18:56] <pedronis> also I thought you weren't going to move the last bit to env
[18:56] <zyga> which last bit?
[18:56] <pedronis> (transform), that might need some tweaks as well
[18:56] <zyga> I killed transform
[18:56] <pedronis> I know
[18:56] <zyga> and made it into a simple pair of helpers to escape/unescape
[18:56] <pedronis> I know
[18:56] <zyga> do you mean that this was supposed to be in ForExec() ?
[18:56] <pedronis> I'm just not sure that the standalone helpers are the best way to encapsulate that
[18:56] <pedronis> but I'll see
[18:57] <zyga> I see
[18:57] <pedronis> they really matter at the process boundary
[18:57] <zyga> it's interesting because look where we escape
[18:57] <zyga> (in snap/snapenv)
[18:57] <zyga> and where we use that (in cmd/snap/cmd_run)
[18:57] <zyga> we'd have to move that logic
[18:57] <pedronis> I know, I thought exactly about that
[18:57] <zyga> that's okay but that's a bigger change than just shoving a function around
[18:57] <pedronis> it's unclear that is placed right in the first place
[18:57] <zyga> yeah
[18:58] <zyga> I think I'm too tired to give useful advice at this time
[18:58] <zyga> I tried to make both uio and exec env branches good today
[18:58] <zyga> and I think exec env should be re-reviewed with fresh head
[18:58] <pedronis> thank you, mostly saying that it might need some small tweaks
[18:58] <zyga> ack
[18:58] <zyga> ok, I'll EOD now
[18:58] <pedronis> that we can do, I think most pieces are there, mostly a matter how to call them
[18:58] <pedronis> where they fit
[18:58] <zyga> this was a good day :)
[18:59] <zyga> yeah
[18:59] <zyga> I think it's also interesting that we are not giving snap-confine the environment that we set in snap-exec
[18:59] <zyga> perhaps we should?
[18:59] <zyga> and snap-exec would not need to read that part of yaml at all
[19:00] <zyga> we could really move those few lines from snap-exec to snap-run with probably, no change at all
[19:00] <zyga> but perhaps that's simplistic, there's some extra interaction with non-run modes of snap-exec
[19:00] <zyga> like strace/gdb and the like
[19:00] <pedronis> yes, I wouldn't do that
[19:00] <zyga> anyway, something to ponder over
[19:00] <zyga> I think it's better than before :)
[19:00] <pedronis> I fear it would need jdstrand input
[19:00] <pedronis> it's a bit unclear what the consequences are
[19:00] <pedronis> also with linker related stuff
[19:00] <pedronis> for example
[19:00] <zyga> we escape those anyway
[19:00] <zyga> so linker would not see it
[19:01] <pedronis> that is true
[19:01] <zyga> but it's indeed interesting
[19:01] <zyga> because some things might affect snap-confine (perhaps) in ways we were not expecting
[19:01] <zyga> e.g. SNAP_CONFINE_DEBUG: true
[19:01] <zyga> so perhaps we should document why we are not setting them outright
[19:01] <zyga> snap/snapexec has some silly copying because I kept the existing structure
[19:01] <pedronis> anyway that's not  a change I want to try right now :)
[19:01] <zyga> but nothing terrible, it's just a few keys anyway
[19:02] <zyga> yes, agreed :)
[19:04] <zyga> jdstrand: FYI I'm off till the end of the week
[19:04]  * zyga waves
[19:10]  * jdstrand is back from meetings and reads scrollback
[19:10] <jdstrand> zyga: have a nice rest of the week!
[19:16] <jdstrand> I don't see anything specifically required of me but I've read the context for if a PR comes though
[19:51] <mup> PR snapd#8224 closed: many: clean separation of bootenv mocking vs mock bootloader kinds  <Reviewed> <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8224>
[19:51] <mup> PR snapd#8252 opened: tests: Update test to make snapd snap fixed twice <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8252>
[20:09] <mup> PR snapcraft#2969 closed: snap: re-add xml development packages for non x86 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2969>
[20:10] <pedronis> jdstrand: I marked a new PR for you to review, not related to the env stuff, I think there are some behavior changes in the env stuff, but nothing that effects the overall security design of what we had so far
[20:11] <pedronis> we set the same king of env vars from the same places, and do the same kind of mangling/unmangling of some
[20:11] <jdstrand> pedronis: ok, is this urgent for 2.44?
[20:11] <pedronis> jdstrand: is this one https://github.com/snapcore/snapd/pull/8249
[20:11] <mup> PR #8249: interfaces: make gpio robust against not-existing gpios in /sys <Security-High> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8249>
[20:12] <jdstrand> pedronis: I see, it is small
[20:12] <jdstrand> ok, let me look
[20:26] <jdstrand> pe
[20:26] <jdstrand> meh
[20:26] <jdstrand> pedronis: done
[20:30] <pedronis> thanks
[21:58] <mup> PR snapd#8253 opened: snap-bootstrap: expand data partition on install <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8253>