[00:19] <mup> PR snapcraft#3265 closed: colcon v2 plugin: honour http(s) proxy for stage-runtime-dependencies <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3265>
[00:19] <mup> PR snapcraft#3266 closed: cli: add --enable-experimental-extensions option for expand-extensions <enhancement> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3266>
[05:20]  * zyga-x240 debugs failing core/apt test
[05:24] <mborzecki> morning
[05:27] <zyga-x240> hey
[05:27] <zyga-x240> something broke, new core18 has apt-get
[05:27] <zyga-x240> I've adjusted a test and will push a branch soon
[05:27] <zyga-x240> master is red currently
[05:27] <zyga-x240> mborzecki: I have something for you
[05:27] <zyga-x240> https://github.com/snapcore/snapd/pull/9212
[05:27] <mup> PR #9212: cgroup,snap: track hooks on system bus only <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/9212>
[05:27] <zyga-x240> can you quickly look please, it's very small apart from extra tests
[05:28] <mborzecki> zyga-x240: hey
[05:28] <mborzecki> master red? ehh
[05:28] <zyga-x240> yep
[05:28] <zyga-x240> but fix is coming
[05:55] <zyga-x240> mborzecki: https://github.com/snapcore/snapd/pull/9229
[05:55] <mup> PR #9229: tests: account for apt-get on core18 <Test Robustness> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9229>
[05:55] <zyga-x240> this should fix master
[05:55] <mup> PR snapd#9229 opened: tests: account for apt-get on core18 <Test Robustness> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9229>
[06:09] <zyga-x240> mborzecki: so your question was on the right track
[06:09] <zyga-x240> mborzecki: hooks were tracked in the root session
[06:09] <zyga-x240> mborzecki: that is fixed with that PR
[06:10] <zyga-x240> mborzecki: the next step is to rebase the selinux patches, this change made them useless
[06:10] <zyga-x240> mborzecki: when mvo is around we can start making progress
[06:28] <zyga-x240> mvo: hey
[06:28] <zyga-x240> mvo: good morning
[06:29] <zyga-x240> mvo: I have a few things for you
[06:34] <mvo> good morning zyga-x240
[06:34] <zyga-x240> mvo: hello
[06:34] <zyga-x240> mvo: so first thing first, master is broken because core18 now ships the apt-get wrapper script
[06:34] <zyga-x240> mvo: because we no longer maintain core18 I chose to adjust tests instead of chasing the snap
[06:35] <zyga-x240> mvo: this is https://github.com/snapcore/snapd/pull/9229
[06:35] <mup> PR #9229: tests: account for apt-get on core18 <Test Robustness> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9229>
[06:35] <zyga-x240> mvo: second thing, the bug you poked me about last night
[06:35] <zyga-x240> mvo: it's very embarrassing as I wrote that code
[06:35] <zyga-x240> mvo: the fix is in https://github.com/snapcore/snapd/pull/9228 and should be merged to 2.46 if we are getting a .1
[06:35] <mup> PR #9228: interfaces/systemd: compare dereferenced Service <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/9228>
[06:36]  * zyga-x240 goes to review https://github.com/snapcore/snapd/pull/9098
[06:36] <mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
[06:36] <zyga-x240> and then other things
[06:36] <mvo> zyga-x240: thank you!
[06:36]  * mvo hugs zyga-x240 for 9228
[06:38] <zyga-x240> mvo: it never failed before because our tests and our customers never had a case where a gpio was used by more than one plug at a time
[06:38] <zyga-x240> mvo: anyway, it's fixed now
[06:39] <mvo> zyga-x240: great job
[06:39] <mvo> zyga-x240: also good timing as 2.46.1 will happen very soon
[06:39] <zyga-x240> that's great
[06:39] <zyga-x240> mvo: I would also like to include one more thing
[06:39] <zyga-x240> https://github.com/snapcore/snapd/pull/9212
[06:39] <mup> PR #9212: cgroup,snap: track hooks on system bus only <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/9212>
[06:39] <zyga-x240> it's only for people who enabled r-a-a
[06:39] <zyga-x240> this corrects a mistake in how we track hooks
[06:39] <mborzecki> mvo: hey
[06:39] <zyga-x240> it should be better even if root logs out
[06:39] <mvo> good morning mborzecki and welcome back
[06:40] <zyga-x240> (right now the hook might get killed if root logs out after the hook starts running)
[06:40] <zyga-x240> not a must but I'd love to get it in, it's only used for feature flag users anyway
[06:42] <mvo> zyga-x240: re core18> looking now but there are some messages that core18 is held in the review queue, maybe related
[06:42] <zyga-x240> mvo: maybe it got unblocked?
[06:43] <zyga-x240> in any case, master is broken now so we should probably do something to the test, other ideas are welcome
[06:43] <mvo> zyga-x240: yeah, probably, but in any case, it's fine that apt-get exists
[06:43] <zyga-x240> yeah, I think so
[06:43] <mvo> zyga-x240: so your fix is probably right, looking at it now
[06:44] <zyga-x240> mvo: meh
[06:44] <zyga-x240> I botched the fix
[06:44] <zyga-x240> sorry
[06:44] <mvo> zyga-x240: which one?
[06:45] <zyga-x240> the one for apt
[06:45] <zyga-x240> I forgot *
[06:45] <zyga-x240> ubuntu-core-16-*
[06:45] <mvo> zyga-x240: no worries, just force push
[06:45] <zyga-x240> done
[06:45] <mup> PR snapd#9228 closed: interfaces/systemd: compare dereferenced Service <Bug> <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9228>
[06:48] <mborzecki> zyga-x240: nice 9212 is green, selinux does not complain
[06:49] <zyga-x240> mborzecki: not really
[06:49] <zyga-x240> mborzecki: selinux is not tested there
[06:50] <zyga-x240> mborzecki: the other PR enabled tracking to get more coverage
[06:50] <zyga-x240> mborzecki: this one just prepares for that, selinux still needs changes
[06:50] <zyga-x240> at some point we should run all tests with selinux checks
[06:50] <zyga-x240> but that would be a lot of work today, I fear
[06:51] <zyga-x240> mborzecki: would you mind if I make those changes in a follow-up
[06:51] <zyga-x240> the PR is green now
[06:51] <mborzecki> zyga-x240: it's fine
[06:51] <zyga-x240> ok
[06:51] <zyga-x240> merging then, thank you
[06:52] <zyga-x240> and we have more tests for tracking now as well, thank you for reviewing :)
[06:53]  * zyga-x240 runs for quick breakfast
[06:55] <mup> PR snapd#9212 closed: cgroup,snap: track hooks on system bus only <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9212>
[07:00] <mup> PR snapd#9223 closed: mkversion.sh: simple hack to include dirty in version if the tree is dirty <Bug> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9223>
[07:02] <pstolowski> morning
[07:02] <mvo> good morning pstolowski
[07:03] <mborzecki> pstolowski: heya
[07:19] <pedronis> mborzecki: hi, I added this comment: https://github.com/snapcore/snapd/pull/9201#discussion_r478204904, not sure it's clear
[07:19] <mup> PR #9201: [RFC] boot: observe update & rollback of trusted assets <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9201>
[07:21] <zyga-x240> back from breakfast
[07:36] <pedronis> I tweaked #9227
[07:36] <mup> PR #9227: snap: add size to the random access file return interface <Simple 😃> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9227>
[07:40] <zyga-x240> ta
[07:50]  * zyga-x240 goes for the desktop call
[07:50] <mborzecki> pedronis: yes, i think it makes sense, i need to think a bit how to do it reliably for newly added assets though
[07:50] <mborzecki> pedronis: and i've updated the PR since the tweaks for install observer landed
[07:55] <pedronis> mborzecki: we are holding the state lock during the whole gadget assets update right?
[08:05] <mborzecki> pedronis: let me double check, i don't think so
[08:06] <mborzecki> pedronis: we don't, there's an explicit unlock/lock around call to gadget.Update
[08:10] <Chipaca> ullo ullo
[08:10] <mborzecki> Chipaca: heya
[08:10] <Chipaca> zyga: snapd.socket is dead right now, want to know more?
[08:10] <zyga> Chipaca yes
[08:10] <zyga> mborzecki ^^^
[08:10] <zyga> I'm in a call
[08:10] <zyga> please use this opportunity to learn more
[08:10] <zyga> Chipaca did snapd snap refresh or did the classic package update?
[08:10] <zyga> mvo ^
[08:11] <zyga> could be pretty serious
[08:11] <Chipaca> neither afaik, but i'll check
[08:11] <Chipaca> logs are swamped by microk8s poking snapctl (and failing) all the time
[08:11] <mborzecki> Chipaca: systemctl status snapd.socket please
[08:12] <Chipaca> mborzecki: https://paste.ubuntu.com/p/K87wFBQwt3/
[08:13] <mborzecki> Chipaca: heh interesting, Transaction for snapd.service/start is destructive (systemd-suspend.service has 'start' job queued, but 'stop' is included in transaction)
[08:13] <mborzecki> the system is suspending so systemd won't start the socket or what?
[08:14] <zyga> woah
[08:14] <zyga> interesting
[08:14] <zyga> Chipaca are you suspending your computer often?
[08:15] <Chipaca> 21.55.20 is a 'reached target Sleep'
[08:15] <Chipaca> zyga: when i don't use it
[08:15] <Chipaca> zyga: so, no :-) but daily for sure
[08:25] <Chipaca> zyga, mborzecki, anything else you want to get out of this, or should i go ahead and restart the socket?
[08:25] <zyga> Chipaca I think restarting the socket is ok
[08:25] <mborzecki> Chipaca: hm maybe snap changes and snap change if there's something relevan tin there
[08:25] <Chipaca> mborzecki: can't do that without restarting the socket :-)
[08:26] <Chipaca> mborzecki: no changes newer than yesterday at 18:54
[08:26] <Chipaca> and that was core18 refreshing
[08:27] <mborzecki> Chipaca: ha, you actually can now, snap debug state
[08:27] <Chipaca> oooh, schmancy!
[08:27] <zyga> Chipaca haha, yeah
[08:27] <mborzecki> snap debug state /var/lib/snapd/state.json [--change=<id> if there's anything relevant]
[08:59]  * zyga reboots for upgrade quickly
[09:11] <mup> PR snapd#9226 closed: cmd/snap-bootstrap/initramfs-mounts: compute string outside of loop <Cleanup :broom:> <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9226>
[09:11] <mup> PR snapd#9229 closed: tests: account for apt-get on core18 <Test Robustness> <⚠ Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9229>
[09:15] <zyga> mvo do you need a backport of the GPIO bug fix?
[09:15] <mvo> zyga: I already cherry-picked it
[09:15] <zyga> superb, thanks!
[09:15] <zyga> mvo it's such a terrible bug, I'm sorry for causing this
[09:16] <mvo> zyga: don't worry
[09:22] <pedronis> mborzecki: there's probably a bad idea at this point, we need to rethink that
[09:23] <pedronis> mborzecki: that's probably a bad idea at this point
[09:23] <mborzecki> pedronis: not locking state?
[09:23] <pedronis> mborzecki: I mean releasing the lock
[09:23] <pedronis> yes
[09:23] <pedronis> it's not clear that that op should so slow to matter
[09:23] <pedronis> and now we are playing with modeenv without a lock
[09:23] <pedronis> not a good idea
[09:23] <mborzecki> ah right
[09:24] <mborzecki> pedronis: hm thre's some unclear scenarios, can you request a reboot to recovery when assets update is in progress?
[09:25] <pedronis> mborzecki: well, if we hold the lock you won't be able to
[09:25] <pedronis> no?
[09:26] <pedronis> mborzecki: RequestSystemAction asks for the lock
[09:27] <mborzecki> pedronis: yeah
[09:28] <mborzecki> pedronis: otoh, it's not like there's going to be GBs of assets being updated, so holding a lock during the update isn't too bad
[09:28] <pedronis> yes
[09:28] <pedronis> and the new code is reading modeenv once and then writing it multiple times
[09:29] <pedronis> so we really need some kind of lock
[09:29] <pedronis> I don't think it's very explicit but in general the assumption is that we hold the lock
[09:29] <pedronis> when manipulating modeenv
[09:31] <mborzecki> pedronis: would a boot package level modeenv lock work?
[09:32] <pedronis> mborzecki: yes, but I think it will be messy, I wouldn't do that unless we have a strong reason to
[09:32] <mborzecki> pedronis: hm state lock also has some nice checks built in already
[09:33] <pedronis> like the code as is would have to old for the existence of the observer
[09:33] <pedronis> you need to unlock at the right times also on error paths etc etc
[10:21]  * zyga quick break for something warm (temperature dropped by 15C) and back to reviews
[11:00] <pedronis> mvo: seems 20.04 is failing degraded with secureboot-db.service loaded failed failed Secure Boot updates for DB and DBX
[11:02] <mvo> pedronis: fun, I saw this too
[11:02] <mvo> pedronis: do you plan to review 9227 or shall I do that ? the size() helper one
[11:03] <pedronis> mvo: I touched it myself now so a review from somebody else is better
[11:03] <mvo> pedronis: sure thing, doing that now
[11:03] <mvo> pedronis: similar question about 9213
[11:06] <pedronis> mvo: 9213, it looks okish, I'm not sure it makes 100% sense but I'm also not sure this the last version of that code we need
[11:08] <pedronis> mvo: it looks too much like guessing to me
[11:12] <mvo> pedronis: thanks
[11:15] <pedronis> mvo: should I leave a comment there?
[11:16] <mvo> pedronis: I think that would be good
[11:16] <mup> PR snapd#9209 closed: daemon: correctly parse Content-Type HTTP header <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9209>
[11:17] <mvo> pedronis: I also looked at 9227 and added a possible suggestion
[11:23] <pedronis> mvo: done https://github.com/snapcore/snapd/pull/9213/files#r478343623
[11:23] <mup> PR #9213: secboot: read kernel efi image from snap file <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9213>
[11:25] <mvo> pedronis: ta
[11:25] <pedronis> mvo: your suggestion is exactly what I undid , see my new comment
[11:25] <pedronis> the code originally had the error and use stat
[11:25] <pedronis> in Size
[11:27] <pedronis> mvo: sorry, you wasted a bit of time, your suggesting is exactly the reverse of my last commit
[11:27] <mvo> pedronis: aha, then I misunderstood your comment, I thought you said too much stuff in stat is ill-defined. but this variation is only returning size not the full stat info
[11:28] <pedronis> mvo: sorry, that was the original comment, my motivation for my last change is its commit
[11:28] <mvo> pedronis: I see it there now, that's fine then. thank you
[11:28] <pedronis> mvo: snaps are meant to be immutable (notwithstanding all the fun of try and snapdir) so the size shouldn't really be variable
[11:30] <mvo> pedronis: yeah, it makes sense
[11:31] <mup> PR snapd#9227 closed: snap: add size to the random access file return interface <Simple 😃> <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9227>
[11:52] <zyga> pedronis: while reviewing validation sets and refreshing my memory, I came across a TODO and wrote https://github.com/zyga/snapd/commit/76049517f35f25e68b165fe0f427555fb790bf93 -- should I propose it later?
[11:54] <pedronis> zyga: I don't know, I expect there are changes needed also outside of asserts
[11:54] <zyga> ah, I didn't think about that
[11:54] <zyga> anyway, it's not a big thing, just something I noticed while reviewing
[11:55] <pedronis> yes, is something to do
[11:55] <pedronis> at least seed and seedwrite needs changes as well
[11:55] <pedronis> don't know if there are other places
[12:00] <pedronis> naive grepping says likely only seed and seed/seedwriter
[12:08] <zyga> pedronis validation sets have perfect test coverage, nice
[12:10] <cachio> zyga, hey
[12:10] <zyga> hey!
[12:10] <zyga> I had a quick look at your branch
[12:10] <zyga> I left some comments,
[12:10] <cachio> so, yesterday tried everything
[12:11] <cachio> to make work the user session for root
[12:11] <zyga> cachio did you get a logind session?
[12:11] <cachio> also tried the change in spread
[12:11] <cachio> no
[12:11] <zyga> cachio ok, I'll try to help after the standup
[12:12] <cachio> zyga, thnanks
[12:25] <ijohnson> morning folks
[12:26] <pedronis> pstolowski: hi, I re-reviewed #9211
[12:26] <mup> PR #9211: o/snapstate: disk space check with InstallMany <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9211>
[12:27] <pstolowski> pedronis: thank you!
[12:27] <pstolowski> will push the tweaks in a moment
[12:42] <zyga> pedronis https://github.com/snapcore/snapd/pull/9155#pullrequestreview-476677226
[12:42] <mup> PR #9155: asserts/snapasserts: introduce ValidationSets <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9155>
[13:27] <mup> PR snapd#9230 opened: overlord/devicestate: do not release the state lock when updating gadget assets <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9230>
[13:43] <zyga> cachio I'll look at the external thing in a moment, let me grab some food
[13:43] <cachio> zyga, sure, thanks a lot
[13:43] <ijohnson> pedronis: actually sorry I forgot I need to step out for a few minutes, can we chat in like 15 minutes or later today about the ensure boot problem ?
[13:47] <mup> PR snapd#9213 closed: secboot: read kernel efi image from snap file <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9213>
[13:50] <pedronis> ijohnson: I have meetings in 10 mins for 1h
[13:50] <pedronis> I can chat after that
[13:54] <zyga> cachio back with food, let me tinker a little and I'll get back to you
[13:58] <cachio> zyga, sure
[14:01] <ijohnson> pedronis: ack I'll send a meeting invite just to be sure
[14:30] <zyga> cachio I have something that works
[14:30] <zyga> let me minimize it
[14:30] <cachio> great
[14:32] <jdstrand> mvo: hey, so I addressed all feedback in PR 8920 quite some time ago and this is one of the items that I milestoned for 2.46. I'm not sure if people are waiting on pedronis because it has his tag, but I addressed all his feedback so I think really anyone could review
[14:32] <mup> PR #8920: interfaces: update cups-control and add cups for providing snaps <Needs Samuele review> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8920>
[14:34] <jdstrand> mvo: zyga did review and approve the now closed PR 9194 (with some non-blocking comments), but 8920 doesn't have reviews
[14:34] <mup> PR #9194: interfaces: update cups-control and add cups for providing snaps - 2.46 <Created by jdstrand> <Closed by zyga> <https://github.com/snapcore/snapd/pull/9194>
[14:34] <jdstrand> s/reviews/approvals/
[14:34] <zyga> mmm
[14:34] <zyga> I should review those
[14:43] <zyga> cachio ok
[14:43] <zyga> cachio try this: sudo systemd-run --unit "spread-$RANDOM" --property=User=root --property=PAMName=runuser-l --pipe sh -c "loginctl"
[14:44] <zyga> works on 18.04 for sure, I can look at older systems too
[14:44] <zyga> you can drop the sh -c thing, just give it a path to a script
[14:45] <cachio> ok
[14:46] <cachio> systemd-run: unrecognized option '--pipe'
[14:46] <zyga> cachio 16.04?
[14:46] <cachio> zyga, core16
[14:46] <zyga> can you try on newer system
[14:46] <zyga> I will adjust it to core16
[14:46] <zyga> try core18 for now
[14:47] <cachio> sure, let me get the image
[14:52] <zyga> cachio for 16.04
[14:52] <zyga> sudo systemd-run --unit "spread-$RANDOM" --property=User=root --property=PAMName=runuser-l --tty  sh -c "loginctl"
[14:52] <zyga> it's not the best but meh
[14:52] <zyga> it probably is enough
[14:55] <cachio> zyga, works
[14:55] <zyga> note that --pty may be problematic
[14:55] <zyga> so we may need something slightly different like a hand-rolled code that does this and bridges stdin/stdout
[14:55] <zyga> without making a pty
[14:55] <zyga> ptys are problematic
[14:56] <cachio> so, we a new unit that runs this?
[14:56] <cachio> to keep the session up during the test?
[14:57] <zyga> cachio this runs a program with a PAM name
[14:57] <zyga> in isolation from the session of the calling user
[14:57] <zyga> that's enough
[14:58] <cachio> https://paste.ubuntu.com/p/WsPfXcfTH8/
[14:58] <cachio> I see this
[14:59] <cachio> same if I run with a test user
[14:59] <zyga> right
[15:00] <zyga> on core16 with core18 snap installed:
[15:02] <zyga> nah, that doesn't work
[15:02] <zyga> try what I gave you
[15:02] <zyga> and I'd like to know what you tried
[15:03] <zyga> since it didn't work for you before
[15:03] <ijohnson> pedronis: ready ?
[15:03] <pedronis> ijohnson: finishing previous meeting
[15:04] <ijohnson> sure let me know when you're ready
[15:04] <cachio> zyga, just tried manually with the command you sent
[15:04] <zyga> which command?
 sudo systemd-run --unit "spread-$RANDOM" --property=User=root --property=PAMName=runuser-l --tty  sh -c "loginctl"
[15:04] <cachio> that one
[15:04] <pedronis> ijohnson: ready now, sorry
[15:04] <zyga> I mean before, when it failed?
[15:05] <cachio> yesterday tried updating spread to use runuser instead of sudo -i
[15:05] <cachio> to run the script
[15:05] <cachio> also tried manually to start the session for root using runuser
[15:06] <cachio> I created a systemd unit with that
[15:07] <cachio> something similar to what you just passed but without --property=PAMName
[15:07] <cachio> I manually created the unit
[15:08] <cachio> I tried to make the unit sleep forlong time
[15:08] <cachio> to it was going to be running
[15:09] <cachio> zyga, does it make sense?
[15:09] <zyga> cachio I wonder why that didn't work
[15:09] <zyga> but anyway
[15:09] <zyga> now you have something to work with
[15:10] <cachio> zyga, yes, I'll try with this
[15:10] <cachio> I think I can make it work
[15:11] <cachio> zyga, thanks
[15:12] <cachio> I'll try again after lunch
[15:12]  * cachio lunch
[15:45] <ijohnson> jdstrand: rebuilding a snap with go 1.15, I see a seccomp denial that isn't there when compiled with go 1.14 for copy_file_range, and that is only allowed for docker-support currently
[15:46] <ijohnson> jdstrand: is it possible / feasible / sensible to add that to the default template ?
[15:46] <ijohnson> the denial looks like this: `audit: type=1326 audit(1598542961.776:12423): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=157684 comm="security-secret" exe="/snap/edgexfoundry/x1/bin/security-secrets-setup" sig=0 arch=c000003e syscall=326 compat=0 ip=0x47b5ea code=0x50000`
[15:50] <ijohnson> jdstrand: see also this update in the go 1.15 release notes:
[15:51] <ijohnson> > The os.File type now supports a ReadFrom method. This permits the use of the copy_file_range system call on some systems when using io.Copy to copy data from one os.File to another.
[15:53] <ijohnson> jdstrand: ah apparently there is an upstream fix for this where if copy_file_range returns EPERM then Go falls back to an alternate impl that should work in confinement see https://go-review.googlesource.com/c/go/+/249257/
[16:06] <ijohnson> so I guess this problem will just go away with the next Go release, but is there a security reason not to allow copy_file_range in the default profile ?
[16:07]  * zyga goes to work upstairs 
[16:16] <ijohnson> cachio: the regexp in ubuntu-core-20-64:tests/main/listing needs to be updated too to account for pre versions
[16:16] <ijohnson> cachio: see the failure here: https://pastebin.ubuntu.com/p/MBG5Crr8bC/
[16:19] <cachio> ijohnson, ah, yes, I'll do it today
[16:20] <cachio> ijohnson, thanks for the heads up
[16:20] <ijohnson> cachio: np
[17:14]  * cachio afk 30 minues
[17:31] <jdstrand> ijohnson: sorry, was in a meeting
[17:34] <ijohnson> jdstrand: no worries, if you prefer I can open a PR tagged with security review and discussion can take place there
[17:41] <jdstrand> ijohnson: reading the man page, it seems like a reasonable addition for the default template since a) you are giving it open fds that should be mediated by apparmor and b) this is not dissimilar to write()
[17:41] <jdstrand> ijohnson: so, logically, it makes sense but would need to look deeper into how the LSM handles it
[17:42] <jdstrand> ijohnson: that sounds fine
[17:42] <ijohnson> jdstrand: ack I can certainly throw up a PR for you to look at eventually
[17:42] <ijohnson> jdstrand: they are unblocked since go 1.15 will be updated to fix the problem sometime soon, so it's not a rush to fix anymore
[17:42] <ijohnson> thanks!
[17:43] <mup> PR snapd#9230 closed: overlord/devicestate: do not release the state lock when updating gadget assets <Simple 😃> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9230>
[17:48] <mup> PR snapd#9231 opened: tests: update listing test for "-dirty" versions <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9231>
[19:03] <mup> PR snapd#9232 opened: run-checks: check for dirty build tree too <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9232>
[19:18] <mup> PR snapd#9231 closed: tests: update listing test for "-dirty" versions <Test Robustness> <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9231>
[19:23] <mup> PR snapd#9233 opened: vendor: run ./get-deps.sh to update the secboot hash <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9233>
[22:02] <mup> PR snapcraft#3268 opened: v2 plugins: add catkin plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/3268>
[22:44] <mup> PR snapd#9234 opened: systemd/systemd.go: support journald JSON messages with arrays for values <Bug> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9234>