[05:19] <mborzecki> morning
[05:34] <mup> PR snapd#8874 opened: spread: use find rather than recursive ls, skip mounted snaps <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8874>
[05:39] <mup> PR snapd#8875 opened: tests/main/sudo-env: check snap path under sudo <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8875>
[06:37] <mborzecki> heh, debian sets secure_path too
[06:58] <mborzecki> wierd things happening in google:centos-8-64:tests/main/selinux-clean
[06:59] <zyga> Good morning
[06:59] <zyga> Hey Maciek
[06:59] <mup> PR snapd#8859 closed: tests: enable snap-auto-mount test on core20 <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8859>
[06:59] <zyga> Ha, is the spread test immediately useful?
[07:00] <zyga> I just took meds, should be able to work in 30 minutes
[07:02] <mborzecki> zyga: there's some denials coming from systemd-logind trying to read 'linger' file (whcih we created?)
[07:02] <mborzecki> trying to make sure it's not us doing something wrong
[07:04] <pstolowski> morning
[07:06] <zyga> Heh
[07:06] <zyga> Linger is tests.session
[07:07] <zyga> It is a systemd feature
[07:07] <zyga> But probably underused and missing in selinux profiles
[07:08] <mborzecki> pstolowski: hello sir
[07:08] <zyga> Hey Paweł :-)
[07:21] <mborzecki> zyga: hm i'm seeing this:
[07:21] <mborzecki> type=SYSCALL msg=audit(1592291609.858:541): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=55ce2c1a6420 a2=f0000 a3=0 items=0 ppid=1 pid=39430 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(d-logind)" exe="/usr/lib/systemd/systemd" subj=system_u:system_r:init_t:s0 key=(null)
[07:21] <mborzecki> type=AVC msg=audit(1592291609.858:541): avc:  denied  { read } for  pid=39430 comm="(d-logind)" name="linger" dev="sda2" ino=17559683 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:systemd_logind_var_lib_t:s0 tclass=dir permissive=1
[07:21] <mborzecki> H
[07:22] <zyga> which os is this?
[07:23] <mborzecki> which seems fine, because /var/lib/systemd/linger is labeled as systemd_logind_var_lib_t (correct & confimed with semanage fcontext), the pid is systemd-logind, which has systemd_logind_t and policy allows modifing that location
[07:23] <mborzecki> zyga: centos-8
[07:23] <mborzecki> zyga: so for some short while, init_t (systemd itself?) tries to read the linger directory
[07:23] <zyga> hmmmm
[07:24] <mborzecki> afair yesterday centos 8.2 was released, and looking at dnf log, the test pulled in a bunch of upgrades
[07:24] <mborzecki>      9 | -y --refresh install /us | 2020-06-16 07:03 | I, U           |   35 EE
[07:24] <mborzecki>      8 | -y --refresh install --s | 2020-06-16 07:01 | I, U           |  278 EE
[07:24] <mborzecki> perhaps the policy changed, and we just need to update the image
[07:25] <zyga> grep for linger in systemd shows only logind and related things
[07:25] <mborzecki> and the selinux-policy package got updated too
[07:25] <zyga> though
[07:26] <zyga> login also uses it
[07:26] <mborzecki> hm i'll try adding daemon-reexec in test prepare
[07:26] <zyga> not surem, maybe it just is used in init itself too
[07:28] <mborzecki> zyga: btw. debian uses sudo secure_path
[07:28] <zyga> mborzecki: commented on https://github.com/snapcore/snapd/pull/8875/files
[07:28] <mup> PR #8875: tests/main/sudo-env: check snap path under sudo <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8875>
[07:29] <zyga> su -l is nearly always dangerous
[07:29] <mborzecki> zyga: ha, ok will fix that
[07:34] <mup> PR snapd#8872 closed: tests/lib/prepare-restore.sh: if we failed to purge snapd deb, ls /var/lib/snapd <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8872>
[07:34] <mup> PR snapd#8873 closed: interfaces: misc small interface updates <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8873>
[07:34] <mup> PR snapd#8874 closed: spread: use find rather than recursive ls, skip mounted snaps <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8874>
[07:34] <pedronis> mborzecki: should we close or try to land #7414 ? it seems ok to me, one question is whether should we purge packages or just remove them?
[07:34] <mup> PR #7414: tests: keep track of installed packages and restore the state after the test <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7414>
[07:37] <pedronis> mborzecki: I commented in it directly
[07:37] <mborzecki> pedronis: thanks, will chekc in a minute
[07:39] <mup> PR snapd#8871 closed: tests/prepare-restore.sh: reset-failed systemd-journald before restarting <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8871>
[07:40] <zyga> mvo is on a merging spree :)
[07:43] <mvo> zyga: I was shocked to see 80(!) open PRs when I woke up
[07:43] <mvo> zyga: and figured I need to do something :)
[07:43] <zyga> :D
[07:44] <mup> PR snapd#7417 closed: interfaces/wayland: on classic systems only consider the OS slot for auto-connect <Needs Samuele review> <⛔ Blocked> <Created by AlanGriffiths> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7417>
[07:44] <mup> PR snapd#8789 closed: interfaces/docker: use implicitOnClassic: true <Needs Samuele review> <⛔ Blocked> <Created by jdstrand> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8789>
[07:56] <mborzecki> zyga: hm this looks like a bug in the policy or our setup, what happens is that we set StateDirectory=systemd/linger, then systemd tries to set up (create?) that directory for systemd-logind, but gets blocked by the policy
[07:56] <mvo> pedronis: in 8870 the interface name "gconf" is uncontroversial I assume? or is that something you want to review ?
[07:56] <zyga> hmm
[07:56] <zyga> mborzecki: up-to-date systemd has StateDirecty=systemd/linger
[07:57] <zyga> maybe centos-8 is just too old
[07:57] <zyga> it works fine on fedora
[07:57] <mvo> pedronis: other than the name 8870 is ready to get merged
[07:57] <zyga> I mean, the policy is probably too old
[07:57] <pedronis> mvo: I probably need to double check it
[07:58] <mvo> pedronis: sure thing, added the label
[08:01] <mvo> zyga: I updated 8865, it's a bit annoying that we can't use a pre-canned action but it should be simple enough, hopefully the comment explains enough
[08:01] <zyga> thanks, I'll check it in a moment
[08:01] <zyga> digging into some kernel bit for uinput
[08:01] <mvo> pedronis: I assume you also want to double check 8867 (uinput) ? if so I will add the label
[08:01] <mvo> zyga: oh, nice
[08:02] <pedronis> mvo: yes
[08:08] <mvo> a second review for 8857 would be great, should be quick and an easy win
[08:21] <zyga> mvo: added some comments there
[08:21]  * zyga small break
[08:26] <mborzecki> heh, so one of the tests moves xdg-open aside
[08:27] <mborzecki> zyga: and for now i have no clear solution for that selinux problem, feels like a policy bug, maybe if i can procure the ame state on rhel8 i could file a bug
[08:28] <mvo> zyga: nice, thanks!
[08:30] <mup> PR snapd#8855 closed: cmd,many: move Version and bits related to snapd tools to snapdtool, merge cmdutil <Cleanup :broom:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8855>
[08:36] <mborzecki> zyga: do i need tests.session {prepare,restore} if i don't need anything or can i just tests.session exec in the test?
[08:37] <zyga> I would do it just in case
[08:37] <zyga> you probably just want restore
[08:37] <zyga> as using test.session without prepare still gives you a session
[08:37] <zyga> just makes it die briefly
[08:37] <zyga> I found it more reliably with prepare restore
[08:37] <zyga> as otherwise stuff starts and stops and may overrun
[08:41] <zyga> Gah thinkpad died again
[08:41] <mborzecki> i think i see the problem with xdg-open disappearing
[08:41] <zyga> I will use this as an excuse to eat breakfast
[08:41] <zyga> Hmmm?
[08:43] <mborzecki> zyga: xdg-open-compat overwrites /usr/bin/xdg-open, and then removes it
[08:49] <zyga> Ahhh
[08:49] <zyga> Nice catch!
[08:54] <mborzecki> i know we're not supposed to open new PRs but this one is super simple and fixes the problem ijohnson found https://github.com/snapcore/snapd/pull/8876
[08:54] <mup> PR #8876: tests/main/xdg-open-compat: backup and restore original xdg-open <Simple 😃> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8876>
[08:55] <mborzecki> zyga: mvo: ^^
[08:55] <mup> PR snapd#8876 opened: tests/main/xdg-open-compat: backup and restore original xdg-open <Simple 😃> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8876>
[08:56] <mvo> mborzecki: thanks
[08:58] <zyga> Looking
[09:00] <mup> PR snapd#8846 closed: tests: move update-related tests to snapstate_update_test.go <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8846>
[09:00] <pstolowski> mvo: thank you! 🙏
[09:01] <mvo> pstolowski: thank you!
[09:02] <pedronis> pstolowski: I'm looking at it to, it needs a follow up
[09:05] <pstolowski> pedronis: thank you. it's quite possible i overlooked something, or some tests can be re-ordered
[09:06] <pedronis> pstolowski: https://github.com/snapcore/snapd/pull/8846#issuecomment-644637199
[09:06] <mup> PR #8846: tests: move update-related tests to snapstate_update_test.go <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8846>
[09:07] <pedronis> pstolowski: yes, the order is a bit weird of some tests, but not sure is the main worry at this point
[09:07] <pstolowski> pedronis: right, i was pondering about sequence tests in the PR description
[09:07] <pstolowski> pedronis: will prep a followup
[09:08] <pedronis> thank you
[09:10] <pedronis> pstolowski: once we have split more we can consider if reordering is worth it, I agree is a bit strange that for example TestInstallTasks or TestUpdateTasks are not among the first tests one encouters in those files, same more the main run through ones
[09:11] <pedronis> more of an issue for people reading these for the first tiem
[09:13] <pstolowski> sounds good
[09:16] <zyga> I will work on existing PRs and reviews today
[09:16] <zyga> Need to relocate to another room though
[09:33] <mborzecki> zyga:  i've updated https://github.com/snapcore/snapd/pull/8875
[09:33] <mup> PR #8875: tests/main/sudo-env: check snap path under sudo <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8875>
[09:33] <zyga> ack
[09:35] <mup> PR snapd#8814 closed: sanity: check for unsynchronized real time clock <⛔ Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8814>
[09:35] <zyga> hmm
[09:36] <mborzecki> hm?
[09:38] <zyga> mborzecki: commented
[09:38] <zyga> I missed that you are running sudo to become root, not the test user
[09:38] <zyga> lets merge it
[09:38] <zyga> and if it shows up in any scans we can react
[09:39] <zyga> we MIGHT enable disable linger for root
[09:39] <zyga> but tests.session -u root restore does not do the same as it does for test user
[09:39] <zyga> so the protection is weaker
[09:39] <mborzecki> zyga: mhm, fwiw it needs to be run via sudo, otherwise that part of the test does not make sense
[09:40] <zyga> yeah, I understand
[09:52] <mvo> zyga: sorry for being pushy but a quick look at 8865 would be appreciated
[09:52] <zyga> sure
[09:53] <zyga> done
[09:53] <zyga> I think this is fine for now, we can look for how to support this better but it is not high priority
[09:54] <mvo> zyga: \o/
[09:55] <mup> PR snapd#8865 closed: workflow: test PR title as part of the static checks again <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8865>
[09:55] <mup> PR snapd#8876 closed: tests/main/xdg-open-compat: backup and restore original xdg-open <Simple 😃> <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8876>
[09:58] <mborzecki> yay
[10:14] <zyga> degville: hi
[10:17] <zyga> degville: I wasn't sure how to covey this otherwise
[10:17] <mborzecki> zyga: unexpected failure in the PR with sudo env: https://paste.ubuntu.com/p/85m38SNbGm/ idk if it's related though
[10:17] <zyga> there are three new pull requests that add interfaces
[10:17] <zyga> I "assigned" them to you to make sure you are at least aware
[10:17] <zyga> mborzecki: looking
[10:19] <zyga> mborzecki: interesting, let me try
[10:20] <degville> zyga: yes, I saw - and did a little +1 on your comments to let you know. I think it's a great idea and I'll make sure they're documented when they land.
[10:29] <zyga> mborzecki: checking some more
[10:39] <zyga> sigh
[10:42] <mborzecki> zyga: hm?
[10:45] <zyga> wifi range
[10:45] <zyga> I don't know what's in the walls here
[10:45] <zyga> but feels like tinfoiil
[10:51] <mborzecki> zyga: lots of reinforced concrete maybe?
[10:51] <zyga> I think so
[10:51] <zyga> so
[10:51] <zyga> I managed to get a debug shell
[10:51] <zyga> I started simple
[10:51] <zyga> tests.session -u prepare
[10:52] <zyga> then tests.session -u test exec id
[10:52] <zyga> then
[10:52] <zyga> tests.session -u test exec sudo id
[10:52] <zyga> so that all worked
[10:52] <zyga> I wonder if the OS matters, I picked xenial
[10:52] <zyga> I also tried sudo env
[10:52] <zyga> what was broken was sudo -l, right?
[10:53] <zyga> hmm
[10:53] <zyga> and that gave odd output
[10:53] <zyga> it just printed /usr/bin/id (I ran sudo -l id)
[10:53] <mborzecki> zyga: no it failed in a different test
[10:53] <mborzecki> zyga: but that sudo-env PR nonetheless
[10:53] <zyga> hmm?
[10:54] <zyga> can you remind me please
[10:54] <zyga> mborzecki: but sudo --login works
[10:54] <zyga> sudo -l doesn't
[10:54] <zyga> WTH?
[10:54] <mborzecki> zyga: thoght you're looking into https://paste.ubuntu.com/p/85m38SNbGm/ in the context of that sudo-env pr
[10:55] <mborzecki> zyga: sudo --login != sudo -d
[10:55] <mborzecki> pff -l
[10:55] <mborzecki> sudo --login == sudo -i :)
[10:55] <zyga> ah
[10:55] <zyga> stupid font
[10:55] <zyga> sorry!
[10:56] <zyga> I didn't notice
[10:57] <zyga> mborzecki: sorry, I was confused, i see what you mean now
[11:11] <mborzecki> we should land https://github.com/snapcore/snapd/pull/8761 once it's green
[11:11] <mup> PR #8761: add msteams url support <Needs security review> <Created by call-a3> <https://github.com/snapcore/snapd/pull/8761>
[11:25] <mup> PR snapd#8877 opened: tests: move a few more tests to snapstate_update_test.go <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8877>
[11:26] <pstolowski> pedronis: ^ i'll handle sequence tests separately
[11:27] <pedronis> pstolowski: yes, should probably wait until we have closed more PRs
[11:27] <pstolowski> 👍
[11:35] <zyga> Heh, debugged my x240 shutdown problem
[11:35] <zyga> There is a “emergency reset hole” on the bottom
[11:36] <zyga> Which instantly powers of the unit
[11:36] <zyga> With a physical button
[11:36] <zyga> Those tiny clicker type
[11:36] <zyga> Squeezing the unit close to the right hinge just puts enough pressure to press it
[11:37] <zyga> Let me see about that
[11:37] <zyga> And I didn’t invent the name https://support.lenovo.com/us/en/solutions/pd029569
[11:41] <zyga> i will be around shortly, my wife is removing that button
[11:51] <zyga> done
[11:51] <zyga> no more emergency reset hole
[11:51] <zyga> no more annoying shutdowns
[11:51] <zyga> just popped that button off the motherboard
[11:51] <zyga> sorry, mborzecki back to your review
[11:53] <mvo> second review for 8857 would be nice, should be an easy win, thanks to mborzecki  for the tweaks
[11:54] <zyga> mvo: in a moment
[11:56] <zyga> mvo: added a comment
[11:56] <zyga> but LGTm
[11:57] <zyga> back to https://github.com/snapcore/snapd/pull/7414
[11:57] <mup> PR #7414: tests: keep track of installed packages and restore the state after the test <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7414>
[12:09] <ijohnson> morning folks
[12:09] <ijohnson> in the interest of merging small PR's, could I get a review on https://github.com/snapcore/snapd/pull/8519 ?
[12:09] <mup> PR #8519: tests/special-home-can-run-classic-snaps: re-enable <Test Robustness> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8519>
[12:10] <ijohnson> the only test failure there is the current ongoing one about not being able to prepare uc20 systems due to failure to cleanup after snapd
[12:11] <zyga> mborzecki: added comments to 7414 that I think should be changed, I'll review the rest so please hold on :)
[12:14]  * zyga needs painkillers, brb
[12:16] <ijohnson> mvo: 8519 is ready for a sudo git merge and will take us back to the 60's (in terms of open PR's, time travel side effects are unknown)
[12:25] <pstolowski> hi ijohnson !
[12:26] <ijohnson> o/ pstolowski
[12:26] <ijohnson> I updated the install hook spread test PR btw
[12:26] <ijohnson> please have a look when you have a chance
[12:29] <pstolowski> +1
[12:41] <mup> PR snapd#7982 closed: o/snapstate, wrappers: enable services on start <Complex> <⛔ Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7982>
[12:50] <pedronis> pstolowski: I looked again at #8812, and I have a few more questions there
[12:50] <mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services ⚙️> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
[12:54] <pstolowski> pedronis: ty
[12:56] <mup> PR snapd#8519 closed: tests/special-home-can-run-classic-snaps: re-enable <Test Robustness> <⚠ Critical> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8519>
[13:02] <mup> PR snapcraft#3169 closed: package-repositories: allow empty component list <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3169>
[13:06] <mup> PR snapd#8878 opened: tests: fix how gadget pc is detected when the snap does not exist and ls fails <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8878>
[13:11] <mborzecki> zyga: looks like deskto portal activation is failing quite consistently now in 18.04 https://github.com/snapcore/snapd/pull/8875/checks?check_run_id=776173782
[13:11] <mup> PR #8875: tests/main/sudo-env: check snap path under sudo <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8875>
[13:11] <zyga> mborzecki: looking
[13:13] <zyga> mborzecki: I think we should silence that line, it's just a fact that we kill dbus-monitor from awk when we see the stuff we care about
[13:13] <zyga> mborzecki: wonder how it didn't show up before
[13:18]  * zyga lunch 
[13:41] <mup> PR snapd#7414 closed: tests: keep track of installed packages and restore the state after the test <Test Robustness> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7414>
[13:41] <mup> PR snapd#8857 closed: tests/lib/prepare: increase the size of the uc16/uc18 partitions <Test Robustness> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8857>
[13:46] <mup> PR snapd#8366 closed: cmd/snap-bootstrap/initramfs-mounts: verify the seed snap matches bootloader env <Needs Samuele review> <UC20> <⛔ Blocked> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8366>
[13:57] <mborzecki> mvo: shall we land https://github.com/snapcore/snapd/pull/8761 or do we need more input from jdstrand?
[13:57] <mup> PR #8761: usersession/userd: add msteams url support <Needs security review> <Created by call-a3> <https://github.com/snapcore/snapd/pull/8761>
[14:01] <mup> PR snapd#8856 closed: [RFC] tests/main/install-fontconfig-cache-gen: for bionic, focal use broken font <Precious Logs> <Test Robustness> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8856>
[14:06] <jdstrand> mborzecki: fyi, I'd like jamesh to comment on https://github.com/snapcore/snapd/pull/8761#issuecomment-639674545 for the xdg-desktop-portal code since he was involved in PR 8269's review
[14:06] <mup> PR #8761: usersession/userd: add msteams url support <Needs security review> <Created by call-a3> <https://github.com/snapcore/snapd/pull/8761>
[14:06] <mup> PR #8269: apparmor: use rw for uuidd request to default and remove from elsewhere <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8269>
[14:06] <jdstrand> mborzecki: but aside from that PR 8761 has a LGTM for allowedURLSchemes so it doesn't need to wait on me
[14:07] <mborzecki> jdstrand: got it
[14:07] <jdstrand> also, do we expect centos-8-64 to pass atm?
[14:08] <jdstrand> I keep mashing retry but that one doesn't seem to pass
[14:08] <ijohnson> jdstrand: I think centos 8 has some selinux problems right now
[14:08] <jdstrand> ok, I'll stop mashing retry then :)
[14:11] <mborzecki> jdstrand: there's some pending updates on centos, and the recent batch of package updates they pushed broke systemd/systemd-logind/selinux-policy
[14:12] <jdstrand> mborzecki: yikes
[14:12] <mborzecki> jdstrand: i hope that when cachio updates the image this may go away, but from what i could tell going through selinux policy and systemd it's bug
[14:13] <cachio> mborzecki,  when I update the image the test still fails
[14:13] <cachio> mborzecki, this is the error I see https://paste.ubuntu.com/p/Z9KRsbh7vG/
[14:14] <mborzecki> cachio: ok, let's push the image image then, and i'll try to make the test smarter
[14:14] <cachio> mborzecki, sure, thanks
[14:14] <mborzecki> cachio: thank you!
[14:16] <mborzecki> time to run some errands
[14:36] <cachio> mborzecki, image updated
[14:36] <ogra> zyga, hmm, cn layouts live in /run ?
[14:36] <ogra> File: /run/utmp (read)
[14:36] <ogra> Suggestions:
[14:36] <ogra> * adjust program to use $SNAP_DATA
[14:36] <ogra> * adjust program to use /run/shm/snap.$SNAP_NAME.*
[14:36] <ogra> * adjust program to use /run/snap.$SNAP_NAME.*
[14:36] <ogra> * adjust snap to use snap layouts (https://forum.snapcraft.io/t/snap-layouts/7207)
[14:37] <ogra> (i thought they could not)
[14:37] <zyga> no
[14:37] <ogra> then snappy-debug should perhaps not suggest it 🙂
[14:46] <pstolowski> pedronis: it seems you were somehow involved already in https://bugs.launchpad.net/snapd/+bug/1882665 ; do you know if the length restriction for snap name is ok on our side and will be fixed in the store?
[14:46] <mup> Bug #1882665: single-letter snaps are available in the store, but not installable <snapd:Triaged> <Snap Store:Confirmed> <https://launchpad.net/bugs/1882665>
[14:47] <pedronis> pstolowski: there's a conversation going on with the store about that
[14:49] <ijohnson> mvo: https://github.com/snapcore/snapd/pull/8866 is ready to be merged, but note that it failed on other tests in interesting ways so I have saved the logs in a pastebin
[14:49] <mup> PR #8866: tests/main: add spread test for running svc from install hook <Services ⚙️> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8866>
[14:50] <ijohnson> mvo: specifically we got a little bit of info on what is left behind preparing uc20 sometimes insofar as there is still stuff in the /var/lib/snapd dir when purging the snapd deb
[14:51] <ijohnson> mvo: and your google:ubuntu-core-20-64:tests/core/snap-auto-mount changes seem to not have worked
[14:51] <ijohnson> mvo: it seems that the imported assertion was not trusted or was wrong? I'm not sure, the test failure output is quite unclear
[14:51] <ijohnson> mvo: the full log is in https://pastebin.ubuntu.com/p/NbKty2yd3k/
[14:53] <mvo> ijohnson: thank you, I have a look in a wee bit, in a meeting right now
[14:53] <ijohnson> ok, no rush
[15:01] <mvo> ijohnson: looking at the log now, strange that snap-auto-mount does not work - oh well
[15:01] <mup> PR snapd#8866 closed: tests/main: add spread test for running svc from install hook <Services ⚙️> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8866>
[15:01] <mvo> ijohnson: woah, this is very confusing, the /var/lib/snapd is stull of stuff
[15:02] <ijohnson> mvo: yes I'm not sure how it's leftover tbh
[15:02] <mvo> ijohnson: yeah, that looks more like it was not run at all or something
[15:02] <ijohnson> unless somehow because the google-cloud-sdk snap is classic it breaks things ?
[15:03] <ijohnson> or possibly the lxd snap too because the lxd snap is effectively classic as well
[15:06] <mvo> ijohnson: yeah, I'm poking at it now
[15:09] <mvo> ijohnson: same failure in 8877 it seems, fun
[15:09] <ijohnson> mmm at least we can see some stuff now
[15:11] <mvo> ijohnson: yeah but we run the apt-get remove -y --purge snapd with quiet so we loose some information :(
[15:11] <ijohnson> oh yeah maybe we shouldn't do that ...
[15:11] <mup> PR snapd#8877 closed: tests: move a few more tests to snapstate_update_test.go <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8877>
[15:12] <mvo> ijohnson: yeah, it looks like this is the next step
[15:31] <mup> PR snapd#8879 opened: tests: simplify the tpm test by removing the test-snapd-mokutil snap <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8879>
[15:47] <mup> PR snapd#8608 closed: configcore: issue a warning on core16 when journal.persistent option is set <Squash-merge> <⛔ Blocked> <Created by stolowski> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8608>
[15:47] <mup> PR snapd#8609 closed:  Adds missing paths to desktop, solves lp:1876804 <⛔ Blocked> <Created by sklei4> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8609>
[15:48]  * cachio lunch
[15:53] <mup> PR snapcraft#3171 opened: snap: debug enabled by default <do-not-merge> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3171>
[15:58] <pstolowski> cachio: #8558 has a conflict
[15:58] <mup> PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
[16:07] <mup> PR snapd#8880 opened: tests/lib/prepare.sh: adjust comment about sgdisk <Simple 😃> <Skip spread> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8880>
[16:27] <mup> PR snapd#8878 closed: tests: fix how gadget pc is detected when the snap does not exist and ls fails <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8878>
[16:48] <mup> PR core18#155 opened: hooks: fix broken symlink /etc/sysctl.conf.d/99-sysctl.conf <Created by mvo5> <https://github.com/snapcore/core18/pull/155>
[16:51] <mup> PR core20#73 opened: hooks: fix broken symlink /etc/sysctl.conf.d/99-sysctl.conf <Created by mvo5> <https://github.com/snapcore/core20/pull/73>
[16:53] <mup> PR snapcraft#3172 opened: cli: restore --target-arch with warning for LXD and Multipass <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3172>
[16:54] <ijohnson> pedronis: #8794 is ready for re-review (I added the requested unit tests)
[16:54] <mup> PR #8794: boot/bootstate16.go: clean snap_try_* vars when not in Trying status too <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8794>
[16:57] <mup> PR snapd#8761 closed: usersession/userd: add msteams url support <Needs security review> <Created by call-a3> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8761>
[16:57] <mup> PR snapd#8880 closed: tests/lib/prepare.sh: adjust comment about sgdisk <Simple 😃> <Skip spread> <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8880>
[17:06] <mup> PR core20#74 opened: .travis.yml: use snapcraft w/ lxd to build the snap <Created by anonymouse64> <https://github.com/snapcore/core20/pull/74>
[17:47] <mup> PR snapd#8869 closed: asserts/internal: expand errors about invalid serialized grouping labels <Bulk assert refresh :scroll::scroll::scroll:> <Skip spread> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8869>
[18:02] <mup> PR snapd#8881 opened: interfaces: simplify rules of multiple connected iio plugs <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
[18:32] <Intelo> Hi
[18:32] <Intelo> I connected to vnc, all fine, firefox from console opens. I installed chromium-browser but when run, it says 'Client is not authorized to connect to server. Unable to open x display
[18:42] <mup> PR snapd#8576 closed: tests/main/lxd: add test for snaps inside nested lxd containers not working <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8576>
[19:05] <roadmr> hi jdstrand  :) we got a write request for system-files, for /run/lock. Is this covered by another interface maybe?
[19:07] <jdstrand> roadmr: no, but that is a directory. you wouldn't want to grant it for /run/lock, but rather for /run/lock/something /run/lock/somethingelse
[19:07] <jdstrand> roadmr: but really their snap should be updated to use SNAP_COMMON/lock or similar
[19:07] <mup> PR snapd#8875 closed: tests/main/sudo-env: check snap path under sudo <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8875>
[19:08] <roadmr> jdstrand: right, I think the advice they themselves posted pointed in that direction
[19:08] <jdstrand> roadmr: of even better: /{dev,run}/shm/snap.@{SNAP_INSTANCE_NAME}.something
[19:08] <jdstrand> or*
[19:09] <roadmr> jdstrand: ok, I'll try to nudge them in that direction (it also suggested using layouts) and leave system-files as a last resort if they can point me to the specific files they need
[19:12] <jdstrand> roadmr: a layout won't work for /run
[19:12] <roadmr> ok, noted :( bummer heh
[19:13] <cachio> cmatsuoka, ijohnson thanks for the review on #8879, I already update the test
[19:13] <mup> PR #8879: tests: simplify the tpm test by removing the test-snapd-mokutil snap <Simple 😃> <Skip spread> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8879>
[19:13] <jdstrand> roadmr: but they can use /run/snap.<snapname>.something all day every day :)
[19:13] <ijohnson> cachio: thanks I'll look again
[19:16] <cmatsuoka> cachio: thanks, checking again
[19:16] <cachio> ijohnson, just matching 0600 0000 01
[19:16] <ijohnson> cachio: why can't you match the whole pattern ?
[19:17] <cachio> ijohnson, I did it just to avoid to check too much
[19:17] <ijohnson> if there was garbage data for example xxd could output something like `0600 0000 0000 0600 0000 01` and the test would be wrong
[19:17] <cachio> not sure if the format could change
[19:17] <ijohnson> cachio: the correct format should not change it's in the UEFI spec IIRC
[19:17] <cachio> MATCH "00000000: 0600 0000 01\s+....."
[19:17] <cachio> ijohnson, that should be the correct one?
[19:17] <cachio> the match
[19:18] <ijohnson> cachio: yes that should be correct
[19:18] <cachio> ok
[19:19] <cachio> ijohnson, updated
[19:19] <ijohnson> thanks let me look again
[19:20] <cachio> ijohnson, thanks for checking
[19:20] <ijohnson> cachio: can you also specify the full SecureBoot variable name ?
[19:21] <cachio> ijohnson, is it fixed?
[19:21] <ijohnson> cachio: because there could be devices with random uefi firmware implementations that also define some kind of SecureBoot variable, but those will never be the same as SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
[19:21] <ijohnson> cachio: I really would like to see us be as specific as possible here
[19:22] <ijohnson> cachio: so instead of doing `SecureBoot-*` I think we should do `SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c`
[19:22] <cachio> ijohnson, sure
[19:22] <ijohnson> thank you
[19:23] <cachio> ijohnson, so the filename SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c is not gonna change right?
[19:23] <ijohnson> cachio: yes that name is part of the spec
[19:23] <cachio> ijohnson, ah, ok
[19:23] <cachio> in that case makes sense
[19:23] <cachio> thanks for the explanation
[19:24] <cmatsuoka> the uuid is the vendor uuid and in this case it's the EFI consortium or something like that
[19:24] <ijohnson> yes
[19:31] <cmatsuoka> cachio: I think there's an extra space in the middle of the file name now
[19:31] <cmatsuoka> SecureBoot-8be4df61-93ca-11d2 <space> -aa0d-00e098032b8c
[19:35] <roadmr> wow
[19:36] <cmatsuoka> cachio: please ignore the comment about the shell expansion
[19:39] <cachio> cmatsuoka, nice
[19:39] <cachio> I am wating for test results for the latest change yet
[19:40] <cmatsuoka> my mistake there, I tested the regexp using plain grep but then I noticed that MATCH uses grep -E
[19:40] <cmatsuoka> so the match didn't work in my first test
[19:41] <cmatsuoka> but with grep -E it's fine
[20:10] <pedronis> ijohnson: sorry about https://github.com/snapcore/snapd/pull/8340#discussion_r434490285 but basically my original comment/proposal wasn't possible, I probably misread some bit of the code and then the change applied was something else
[20:11] <mup> PR #8340: boot, snap-bootstrap: move initramfs-mounts logic to boot pkg <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8340>
[20:11] <ijohnson> pedronis: no worries
[20:11] <ijohnson> I mean with large PR's that are open for months there's bound to be back and forth
[20:11] <ijohnson> I'm almost done addressing feedback for that PR and will push up the changes in a little bit
[20:30] <ijohnson> pedronis: PR is updated if you're still around and want to look at it
[20:30]  * ijohnson small break
[20:33] <mup> PR snapd#8794 closed: boot/bootstate16.go: clean snap_try_* vars when not in Trying status too <Test Robustness> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8794>
[20:33] <mup> PR snapd#8879 closed: tests: simplify the tpm test by removing the test-snapd-mokutil snap <Simple 😃> <Skip spread> <Created by sergiocazzolato> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8879>
[21:26] <cmatsuoka> ijohnson: when a new kernel snap is installed on arm, where do we trigger kernel extraction?
[21:28] <cmatsuoka> ijohnson: never mind, I just found it :)
[21:28] <mup> PR snapcraft#3173 opened: cli: use snap pack instead of mksquashfs <maintenance> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3173>
[22:24] <ijohnson> cmatsuoka: you found the ExtractKernelAssets functions?
[22:26] <ijohnson> Whoops
[22:27] <cmatsuoka> ijohnson: yes, I followed it to backend/setup
[22:27] <cmatsuoka> ijohnson: now I'm thinking how to get model information from there
[22:28] <cmatsuoka> but I'll continue tomorrow
[22:28]  * cmatsuoka EODs