[02:23] <mup> PR snapd#9919 opened: many: add Delegate=true to generated systemd units for special interfaces <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9919>
[07:08] <mborzecki> morning
[07:30] <jamesh> mborzecki: for your comment on #9906, were you referring to some other observed bug?  I don't think snapd ever tried to enable these service files itself
[07:30] <mup> PR #9906: wrappers: don't generate an [Install] section for timer or dbus activated services <Simple 😃> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9906>
[07:31] <mborzecki> jamesh: ah, so we're ok then
[07:32] <jamesh> mborzecki: right.  This was primarily to stop the services being reported as disabled.  It has the side effect of stopping users running "systemctl enable" on them behind snapd's back though.
[07:36] <zyga> hey guys
[07:36] <zyga> hey mvo
[07:36] <mvo> good morning zyga
[08:03] <pstolowski> morning
[08:04] <mborzecki> zyga: mvo: pstolowski: hey
[08:04] <mborzecki> mvo: can you take a look at https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1915156 ?
[08:04] <mup> Bug #1915156: sudoers file keeps being tracked as part of snapd <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1915156>
[08:05] <mborzecki> mvo: i looked at package workflows, but it's not clear where is the right point where we can try to remove /etc/sudoers.d/99-snapd.conf
[08:18] <mvo> mborzecki: thanks, I have a look at this
[08:18] <mvo> mborzecki: conffile removal is a bit of a tricky topic
[08:19] <mvo> pstolowski: also good morning :)
[08:19] <pstolowski> o/
[08:29] <mup> PR snapd#9919 closed: many: add Delegate=true to generated systemd units for special interfaces <⚠ Critical> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9919>
[08:34] <mvo> pedronis, mborzecki, pstolowski I will do 2.49 now, just merged the delegate fix from ian. any concerns?
[08:34] <mup> PR snapd#9904 closed: tests/nested/core20/boot-config-update: skip when snapd was not built with test features <Run nested> <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9904>
[08:34] <mup> PR snapd#9920 opened: many: add Delegate=true to generated systemd units for special interfaces (master) <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9920>
[08:36] <pstolowski> mvo: sounds good, i don't have anything unmerged
[08:37] <mborzecki> mvo: go for it, i don't have anything to land for 2.49
[08:40] <mvo> thanks!
[09:28] <pstolowski> mborzecki: hey, i saw you self-requested your review on #9853, do you have some time to look at it? would be great to pave the way for the other PRs in the queue ;)
[09:28] <mup> PR #9853: api: validate snaps against validation set assert from the store <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9853>
[09:54] <mborzecki> pstolowski: yes, will do in a bit
[09:55] <pstolowski> ty
[09:55] <pedronis> pstolowski: hi, I tried to answer your question in #9901
[09:55] <mup> PR #9901: o/devicestate,many: introduce DeviceManager.preloadGadget for EarlyConfig <Run nested> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9901>
[09:56] <pstolowski> pedronis: thanks, btw, silly question, what do you mean with https://github.com/snapcore/snapd/pull/9893#discussion_r573065948 ?
[09:56] <mup> PR #9893: store: support validation sets with fetch-assertions action <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9893>
[10:00] <mup> PR snapd#9906 closed: wrappers: don't generate an [Install] section for timer or dbus activated services <Simple 😃> <Created by jhenstridge> <Merged by jhenstridge> <https://github.com/snapcore/snapd/pull/9906>
[10:00] <pedronis> pstolowski: sorry, I think I left out a word.  I meant to move the append to the first if with the same condition
[10:02] <pstolowski> pedronis: ah, that, yes, makes sense, i was considering it before
[10:02] <pstolowski> thx
[10:02] <pedronis> pstolowski: if the value appended was a value and not a pointer, that doesn't work, but it's a pointer here unless I'm mistaken
[10:03] <pstolowski> pedronis: yes, sure
[10:05] <mup> PR snapd#9921 opened: boot: helper for setting up a try recover system  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9921>
[11:11] <pstolowski> pedronis, mborzecki thanks for the review
[11:19] <mborzecki> yw
[12:15] <mup> PR snapd#9853 closed: api: validate snaps against validation set assert from the store <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9853>
[13:46] <mup> PR snapd#9922 opened: api: validation sets monitor mode <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9922>
[14:41] <mvo> mborzecki, ijohnson, pedronis the snapd build failure on risc-v on hirsute seems to be caused by a the go upload that dropped the risc-v patches, so nothing we can do on our side
[14:41] <ijohnson> weird, but also maybe good since it's not our problem for sure :-)
[14:42] <mborzecki> aka problem solved ;)
[14:50] <ijohnson> mvo: do you want me to sort out to conflicts with #9920 ?
[14:50] <mup> PR #9920: many: add Delegate=true to generated systemd units for special interfaces (master) <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9920>
[14:52] <mvo> ijohnson: uh, I did not even saw them, sorry
[14:52] <mvo> ijohnson: I must have done something silly, I thought I had based this on upstream/master
[14:53] <mup> PR snapcraft#3436 opened: WIP: More complete PYTHONPATH in the gnome-3-38 build environment <Created by kenvandine> <https://github.com/snapcore/snapcraft/pull/3436>
[14:54] <mvo> ijohnson: let me have a look
[14:54] <ijohnson> mvo: ok, I also have a branch ready too if you'd rather me just open a new pr
[14:56] <mvo> ijohnson: either way is fine, just had a look and the conflcit is trivial to fix (already done)
[14:56] <ijohnson> sure you can push your fix then
[14:56] <mvo> ijohnson: pushed then
[17:22] <mup> PR snapd#9918 closed: boot: use a common helper for mocking boot assets in cache <Simple 😃> <Skip spread> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9918>
=== ijohnson is now known as ijohnson|lunch
[18:12] <mup> PR snapd#9923 opened: o/snapstate/check_snap.go: add support for many subversions in assumes snapdX <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9923>
[18:18] <zyga> mvo hey
[18:18] <zyga> mvo a bit late, are you around?
[18:18] <mvo> zyga: in meetings
[18:18] <zyga> mvo sure, maybe I can catch you the day after tomorrow
[18:19] <zyga> wanted to sync about that snap-update-ns problem
[18:25] <mvo> zyga: sure, maybe I can answer async?
[18:26] <zyga> mvo sure, wanted to ack if anyone had more insight into this problem and if it was pin-pointed as to exact which mount entry is at fault
[18:39] <mvo> zyga: we did not dig deeper but I think it is and we need to implement your idea about x-fragile
[18:41] <zyga> mvo did maciek comment on the idea and the problem?
[18:42] <zyga> mvo tomorrow I have a whole day of meetings, but I would love to sync later to see how to implement it
[18:42] <zyga> (so Friday)
[18:43] <mvo> zyga: the consensus is that you are right but we did not yet dove deep
[18:43] <mvo> (AFAIK)
[18:43] <zyga> thanks
[18:43] <zyga> I'd love to try this over wekeend
[18:43] <zyga> I'll send some ideas on Sunday
[18:47] <mvo> zyga: \o/
[20:13] <mup> PR snapcraft#3436 closed: WIP: More complete PYTHONPATH in the gnome-3-38 build environment <Created by kenvandine> <Closed by kenvandine> <https://github.com/snapcore/snapcraft/pull/3436>
[20:42] <mup> PR snapd#9924 opened: interfaces/docker-support: add autobind unix rules to docker-support <Needs security review> <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9924>
=== ijohnson|lunch is now known as ijohnson
[21:25] <jdstrand> emi__torino: hi! would you mind adding me as a collaborator to the ufw snap? I talked about this with Beret before I left (and also roadmr, but he isn't here now; also, hi Beret! :)
[21:25] <jdstrand> emi__torino: I'll give you the address in privmsg
[21:27] <jdstrand> emitorino: hey, I didn't see your answer if you gave one
[21:27] <emitorino> sure, let me do it (trying again)
[21:27] <jdstrand> emitorino: thanks! :)
[21:29] <emitorino> jdstrand, I cannot. Since I am not a collaborator it seems I dont have the permissions to do it
[21:29] <jdstrand> hmm, well, roadmr said he would do it for me. I guess I can ask him when he is around
[21:29] <emitorino> I can ask in the internal snappy mattermost channel to roadmr
[21:30] <jdstrand> emitorino: ah, if he's there, that would be great. thank you :)
[21:56] <kenvandine> hey jdstrand!
[22:02] <emitorino> jdstrand, you should be again a collaborator to the ufw snap. Could you please share? roadmr un-revoked the share
[22:10] <jdstrand> hey kenvandine :) nice to 'see' you :)
[22:10] <jdstrand> emitorino: let me check
[22:18] <jdstrand> emitorino: ok, I was looking for an invite, but it looks like it was just done without it. I now see it in 'my published snaps' and can see https://dashboard.snapcraft.io/snaps/ufw/. I'm good. thanks and thanks to roadmr :)
[22:18] <emitorino> great jdstrand !