mborzeckischool run, back in 3005:35
mvowelcome back mborzecki06:23
mvozyga: I added some comments to 7700 but I think we should merge it06:23
mvozyga: well, maybe merge or push my suggestions, either way, I think this should move forward :)06:23
mvozyga: and sorry that I left you hanging there for so long06:24
mborzeckimvo: zyga: hey06:24
mvohrm, I wish we had a "tell pawel once he joins" feature, hm, maybe mup supports this06:28
mupPR snapd#9270 closed: wrappers, systemd: allow empty root dir and conditionally do not pass --root to systemctl <Run nested> <Services ⚙️> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9270>06:29
mupPR snapd#9390 closed: boot: fix debug bootloader variables dump on UC20 systems <Simple 😃> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9390>06:29
mborzeckimvo: mattermost?06:33
mvomborzecki: yeah06:36
mborzeckii've always complained that core20 prepare takes long, but after workign with nested suite, i can't really complain anymore06:39
zygagood morning06:40
zygamvo: let me look at 770006:40
zygait's such a low number I suspect it's one of the older r-a-a branches06:40
mvozyga: it is06:40
mvozyga: should be very easy what I'm suggesting there06:41
zygamvo: I replied to most comments06:44
zygamvo: if you feel like it, I always wanted to do inotify06:44
zygamvo: but I will do inotify after the desktop notificatons api06:45
mvozyga: probably a followup in any case but it feels nice. it will be a lot of work, yes?06:45
zygaas we may also use that logic here06:45
mvozyga: right06:45
zygainotify? not at all06:45
zygafor a single file that's really easy to use06:45
zygait's only bad/hard api for unbound directories06:46
zygathank you for the review :)06:46
zygaI thought this PR will have a cake06:46
zyga2019 Oct06:46
* zyga had late PT at 20:00 last night and had quite a workount06:47
mvozyga: haha, let's try to avoid that it get's a cake06:53
zygagood plan06:53
zygaI'm making good progress on notifications, hopefully first PR doing this tomorrow06:53
zygamvo: wanna land a PR?06:54
mvozyga: I replied, but please consider the suggestions with an open mind, I'm happy to do the modificiations if you feels burdensome06:54
zygahttps://github.com/snapcore/snapd/pull/9407 needs a 2nd +106:54
mupPR #9407: overlord: explicitly set refresh-app-awareness in tests <Simple 😃> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/9407>06:54
mvozyga: we can land it but please consider the ideas in there for a followup06:54
zygamvo: I meant the more recent one06:55
mvozyga: I am not at this one yet, working my way up slowly :)06:55
zygaok :)06:55
mvozyga: and great to hear that inotify is easy, that's cool06:55
zygaah, I wasn't aware of the progress meter thing06:56
zygamvo: I'll do a small pass as it's ancient and needs master merge anyway06:56
zygamvo: but I'd like to keep the time duration anyway, 1s is really okay for this, snap refresh with a single aa compile is on the same order of magnitude06:56
zygaI'd actually keep it up *longer* after a brief period of being invisible06:57
zygaas this is user interaction06:57
zygaa window that blinks in and out of existence is poor UI06:57
zygabut this was really proposed to start a discussion06:57
zygaI'm just glad we got one now06:57
zygait's not the end game06:57
mvozyga: sure, that's fine06:58
mvozyga: the blink window is a good point, makes me wonder if the initial delay should actually be longer, oh well - bikeshed land :)06:58
zygamvo: we could do a headless UI for 3 seconds06:59
zygaand then open snap store with the refreshing snap instead06:59
zygathat shows progress already06:59
mvozyga: but yeah, let's keep it at 1s and maybe even add a code comment like: "// initial display should not be too short or the user just sees some irritating flashing if the refresh is almost finished"06:59
mvozyga: yeah, anyway, that is definitely followup material :)06:59
mvozyga: anyway, I think we are in agreement here, let's try to do minimal changes and land it as it's better than before07:01
zygao/ pawel07:07
mborzeckimvo: can you take another look at https://github.com/snapcore/snapd/pull/9393 ?07:14
mupPR #9393:  spread: drop vendor from the packed project archive <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9393>07:14
mvomborzecki: sure07:21
mupPR snapd#9393 closed:  spread: drop vendor from the packed project archive <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9393>07:24
mborzeckimvo: thanks!07:25
mborzeckimvo: something you asked for https://github.com/snapcore/snapd/pull/940807:42
mupPR #9408: tests/core/snap-debug-bootvars: spread test for snap debug boot-vars <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9408>07:42
mvopstolowski: what's the plan for snapshots and the setID of the zip files? I was just looking at the snapshot import PR again and tweaked some tests07:43
mvopstolowski: quick HO maybe if it's cumbersome to type?07:44
mupPR snapd#9408 opened: tests/core/snap-debug-bootvars: spread test for snap debug boot-vars <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9408>07:44
pstolowskimvo: inside the zip we want to store 0 and use set id inferred from the file name. with the changes that landed already we will ignore snapshots where set id from filename != set id inside (so, reverting to current snapd from future snapd will not show such snapshots)07:45
pstolowskimvo: does this make sense?07:46
mvopstolowski: yeah, that's great07:47
mvopstolowski: that means the import PR is actually pretty close, if the filename is now the authority07:47
mvopstolowski: so now we just need to change the code in master to use the filename for the sid? that sounds pretty neat and straightforard.07:49
mvopstolowski: or are there more complications?07:49
pstolowskimvo: yes, that's mostly it. however i think we want to land setting id=0 inside the zip in a release following current changes07:50
zygazyga@kaveri:~/go/src/github.com/snapcore/snapd/desktop/notifications/cmd/snapd-desktop-notify$ ./snapd-desktop-notify07:51
zygaserver capabilities: [actions body body-markup icon-static persistence sound]07:51
mvopstolowski: good point07:54
pstolowskiok, i've defocnflicted services PR with master.. now need to run spread tests to see if nothing broke07:57
mupPR snapd#9236 closed: kernel: remove "edition" from kernel.yaml and add "update" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9236>07:59
jameshzyga: this was the notifications code I started on way back: https://github.com/jhenstridge/snapd/tree/session-agent-notification-lib/usersession/agent/notification08:38
zygajamesh: looking08:39
zyga(and thanks for sharing that!)08:39
pedronispstolowski: mborzecki: #9400 and then #9404 are ready for reviews08:39
mupPR #9400: o/assertstate: support refreshing any number of snap-declarations <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9400>08:39
mupPR #9404: asserts: deserialize grouping only once in Pool.AddBatch if needed <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9404>08:39
pstolowskipedronis: ack08:39
zyganeat, some things I will steal from that, if you don't mind08:39
zygajamesh: do you have a link to the gtk spec?08:40
zygaI can google if not08:40
jameshzyga: there's something on the GNOME wiki, but I think the glib source is considered authoritative (for better or worse)08:41
jameshhttps://wiki.gnome.org/Projects/GLib/GNotification <- actually, this is pretty much it08:42
jameshwhat that page doesn't mention is that it is including the D-Bus activatable desktop spec by reference08:42
zygajamesh: are application IDs the appstream IDs or something else?08:43
jameshthat's how an (application_id, action) pair translates to a call back to the application08:43
jameshzyga: it is a D-Bus bus name, which also needs to be a desktop ID with the ".desktop" suffix removed08:44
jameshzyga: clicking on a notification turns into an Activate or ActivateAction call on the bus name using this interface: https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s08.html08:45
jameshI hadn't finished off the action handling in that code.08:47
zygajamesh: what decides if ActivateAction is used? can one convey the action somehow?08:47
jameshzyga: if you click on a notification with no default action, it activates the app08:48
jameshwhich the app would usually respond by raising itself08:49
paul424Hello the version of I need ogre3d disappeared09:20
paul424There is only   latest/stable:    1.12.7 2020-06-20 (151) 151MB09:21
paul424while mine program needs 1.12.5 are there any archives09:21
mvodegville: in a meeting still, will join soon10:01
mvodegville: sorry!10:01
degvillemvo: no problem at all!10:02
mupPR core18#172 opened: Add finalrd to core18 <Created by xnox> <https://github.com/snapcore/core18/pull/172>10:13
* zyga takes a break for coffee10:26
zygagood progress on notifications API10:26
zyganow need to play with demo program on some systems to see how things behave10:26
zygathen need to draft some text for actual messages10:26
zygathen start working on user agent changes10:26
mupPR core20#87 closed: Revert "hooks: mv docker user/group definition to extrausers" <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/87>10:45
mupPR snapd#9407 closed: overlord: explicitly set refresh-app-awareness in tests <Simple 😃> <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9407>11:05
zygathanks mvo :)11:05
pedronismborzecki: I reviewed #9401 but I have a question there (if it makes sense)11:43
mupPR #9401:  gadget: allow content observer to have opinions about a change  <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9401>11:43
mborzeckipedronis: thanks11:43
mborzeckipedronis: i'll drop that mock and remove GetRecoverySystemEnv from the interface11:59
mupPR snapd#9409 opened: cmd/snap: implement 'snap validate' command <validation-sets :white_check_mark:> <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9409>12:20
mupPR snapd#9235 closed: tests: new tests for nested and external <Run nested> <⛔ Blocked> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9235>12:30
mvopedronis: still in a meeting, will join in 1-2min12:30
mvoijohnson: do you mind if I squash merge 9379? will make the cherry picking easier12:37
ijohnsonmvo: go for it, thanks12:39
mvoijohnson: done and cherry-picked12:40
mupPR snapd#9379 closed: cmd/s-b/initramfs-mounts: use ConfigureTargetSystem for install, recover modes <Bug> <Run nested> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9379>12:40
mupPR snapcraft#3295 closed: specification: desktop extension font hook <specification> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3295>12:43
mupPR snapd#9410 opened: desktop/notification: add bindings for FDO notifications <Created by zyga> <https://github.com/snapcore/snapd/pull/9410>13:00
zyga-mbpjamesh: review welcome https://github.com/snapcore/snapd/pull/941013:21
mupPR #9410: desktop/notification: add bindings for FDO notifications <Created by zyga> <https://github.com/snapcore/snapd/pull/9410>13:21
=== seb128_ is now known as seb128
* zyga breaks to take the dog out13:36
pstolowskiijohnson: hey, #8960 is ready for review14:13
mupPR #8960: o/snapstate,servicestate: use service-control task for service actions (9/9) <Needs Samuele review> <Services ⚙️> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8960>14:13
ijohnsonpstolowski: great thanks I will try to take another look today/tomorrow14:13
ijohnsonpstolowski: is that going into 2.47 or 2.48 ?14:14
pstolowskiijohnson: not into 2.47, no14:14
ijohnsonpstolowski: ack thanks for clarifying14:14
cachiozyga, could you please take a look to that one? #898615:08
mupPR #8986: tests: new snaps-state command - part1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8986>15:08
zyga-mbpcachio in a call, I'll look in ~ hour15:08
cachiozyga-mbp, sure, no hurry15:08
ijohnson#9405 is super simple and green, only 3 lines deleted which enables kvm for another nested test15:39
mupPR #9405: tests/nested/manual/grade-signed-above-testkeys-boot: enable kvm <Run nested> <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9405>15:39
=== oer is now known as oerheks
ijohnsonthanks pstolowski !15:57
pstolowskizyga-mbp: i'm seeing https://pastebin.ubuntu.com/p/jW3jnbXrH2/ on 20.10; apparmor 3? for full context - https://github.com/snapcore/snapd/pull/940515:57
mupPR #9405: tests/nested/manual/grade-signed-above-testkeys-boot: enable kvm <Run nested> <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9405>15:57
zyga-mbpI saw that too, likely yes15:57
mupPR snapd#9405 closed: tests/nested/manual/grade-signed-above-testkeys-boot: enable kvm <Run nested> <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9405>16:01
zyga-mbpcachio https://github.com/snapcore/snapd/pull/8986#pullrequestreview-49573125416:15
mupPR #8986: tests: new snaps-state command - part1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8986>16:15
zyga-mbpcachio only two things I'd change, otherwise LGTM16:15
cachiozyga-mbp, tx16:15
zyga-mbpcachio thanks, please ping me for another pass or reply if you disagree strongly16:15
zyga-mbpI'm going to EOD now16:15
cachiozyga-mbp, sure, I'll ping you tomorrow16:17
cachiozyga-mbp, I answered on #939816:18
mupPR #9398: tests: split the nested helper in 2 parts <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9398>16:18
cachiofor tomorrow16:18
zyga-mbpyou don't have to create the tool this way16:18
zyga-mbpright now nested.sh is a library16:18
zyga-mbpkeep using it as such16:18
zyga-mbpbut only _from_ the tool16:18
zyga-mbpso write a shim tool that sources nested and invokes some functions16:19
zyga-mbphas a CLI and can be used from tests16:19
zyga-mbpport one test16:19
zyga-mbpnever touch nested.sh unless required16:19
zyga-mbpso you don't care if it gets changed16:19
zyga-mbpat the end of the day you should be able to just merge nested.sh into the tool, since nobody else is using it16:19
* zyga-mbp packs the last VM for the dy16:19
zyga-mbpcachio it's your choice, that's just my advice16:20
ijohnsoncachio: I agree with zyga-mbp on this one, your current pr is just too difficult to review16:22
ijohnsonI started to review it but it's just hard to do a good review considering so much is changing, even if the changes are mostly simple16:22
cachiozyga-mbp, ok, makes sense, what I don't want to do is to maintain 2 thinks16:23
cachioso if the idea is to maintain just the tool it is ok16:24
ijohnsoncachio: you don't need to maintain 2 versions of the same file, you keep nested.sh as-is, and add a nested-tool.sh or something which has subcommands which call the various functions defined from nested.sh instead16:25
cachioijohnson, yes, agree on that16:25
ijohnsoncachio: then gradually add commands and such to nested-tool.sh and move tests from using nested.sh to using nested-tool.sh gradually16:25
ijohnsonok, nice16:25
ijohnsonhappy to help get started on that if you need any help16:25
cachiozyga-mbp, ijohnson thanks for the advice, I'll create a new pr16:25
ijohnsonthank you cachio16:25
zyga-mbpthank you!16:26
* cachio lunch16:29
jdstrandzyga: fyi, pawel's denial has to do with the new kernel. snap-confine has: @{PROC}/[0-9]*/attr/current r,16:41
jdstrandzyga: that shoudl be changed to @{PROC}/[0-9]*/attr/{,apparmor/}current r,16:42
jdstrandzyga: that should happen in the the 'w' in snap-confine too, as well as cups_control.go, lxd_support.go, browser_support.go. ./sandbox/apparmor/process.go should be adjusted to see if proc/%v/attr/apparmor/current exists and if not, fallback to proc/%v/attr/current16:44
jdstrandijohnson: it seems zyga and pawel signed off. can you make sure they see ^16:44
ijohnsonjdstrand: sure I can also propose a pr for that, to be clear that is from apparmor3 in groovy though right ?16:44
ijohnsonoh sorry you said it's the new kernel16:45
ijohnsonbut yes I can take care of that16:45
jdstrandijohnson: yes and no. the LSM stacking support has been moving forward. selinux claimed @{PROC}/[0-9]*/attr/current for themselves and so apparmor couldn't reuse it and moved to @{PROC}/[0-9]*/attr/apparmor/current16:46
ijohnsonI see16:46
jdstrandijohnson: so libapparmor will first look at @{PROC}/[0-9]*/attr/apparmor/current if the kernel has it16:46
ijohnsonthat makes sense16:47
jdstrandijohnson: and that libapparmor change is in aa316:47
ijohnsonright yeah I seem to remember that aa3 was imminent in groovy16:47
ijohnsonjdstrand: do you expect any other regressions in groovy we should be on the look out for w/ respect to apparmor3 landing ?16:47
jdstrandijohnson: I didn't mean for you to 'take care of' the above, but if you want to, be all means, do :)16:48
ijohnsonyeah it doesn't sound like a lot of work I can take care of it16:48
jdstrandijohnson: no. I've been using aa3 for weeks16:48
jdstrandijohnson: and there was extensive tests. tbh, I would've alerted you to this had I known that groovy's kernel moved to @{PROC}/[0-9]*/attr/apparmor/current (and that ./sandbox/apparmor/process.go needed a corresponding update)16:49
ijohnsongreat, glad to hear that. we were all kinda nervous about aa3 in groovy regressing snapd since it was mentioned there would be work to make snapd work with aa3, but perhaps what was meant was more just moving snapd to take advantage of new things in aa3, not fixing snapd to work the way it did before aa316:49
jdstrandbut in terms of policy/etc, it should be ok with how we setup /etc/apparmor.d/abi16:49
ijohnsonand also considering how late in groovy cycle aa3 was landing16:49
jdstrandoh, yes, there is just this small stuff. the work to do is for cross distro and taking advantage of new aa3 features16:50
jdstrandijohnson: we're committed to fixing bugs with the highest urgency if you see problems in apparmor16:51
ijohnsoncool, sounds good16:52
jdstrandijohnson: we do hope to do PRs for snapd to take advantage of aa3 next cycle16:52
mupPR snapd#9411 opened: cmd/snap/auto-import: stop importing system user assertions from initramfs mnts <Bug> <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9411>17:16
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson
=== Eighth_Doctor is now known as Conan_Kudo
=== Conan_Kudo is now known as Eighth_Doctor
ijohnsoncachio: looks like tumbleweed is working again to run tests now, though there are some failures, but we now have at least 57 tests passing there now :-)18:09
ijohnsonjdstrand: pr for the apparmor 3 attr path change is up now at #941218:13
mupPR #9412: many/apparmor: adjust rule for reading apparmor profile for new kernel <Bug> <Needs security review> <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9412>18:13
mupPR snapd#9412 opened: many/apparmor: adjust rule for reading apparmor profile for new kernel <Bug> <Needs security review> <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9412>18:16
jdstrandijohnson: ack, approved18:26
cachioijohnson, yes, yesterday I updated again that image18:33
ijohnsonthanks cachio18:33
cachioijohnson, I'll check today or tomorrow why the tests are failing18:33
ijohnsoncachio: well it's a start since we have some tests running successfully there18:34
zygajdstrand: hey18:48
zygajdstrand: do you have any time to review snap-confine udev patch?18:49
jdstrandzyga: hey :)18:49
jdstrandzyga: yikes, no, I don't. but maybe I can find someone. which PR?18:49
zygajdstrand: https://github.com/snapcore/snapd/pull/761418:50
mupPR #7614: cmd/snap-confine: implement snap-device-helper internally <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>18:50
zygait's the one you reviewed before18:50
jdstrandamurray: hey, would you mind taking the security review to the finish line with https://github.com/snapcore/snapd/pull/7614 ? I did a review some time ago and it looks like the comments were addressed. having someone give it a once over would be helpful. if you can't let me know and I can find someone else18:52
mupPR #7614: cmd/snap-confine: implement snap-device-helper internally <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>18:52
zygathank you!18:52
zygaI know time is hard to find18:52
ijohnsoncachio: can you also take a quick look at https://github.com/snapcore/snapd/pull/9413? it is also really simple19:43
mupPR #9413: tests/lib/nested.sh: more little tweaks <Run nested> <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9413>19:43
mupPR snapd#9413 opened: tests/lib/nested.sh: more little tweaks <Run nested> <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9413>19:47
cachioijohnson, sure19:47
ijohnsonjdstrand: do we also need to allow for /proc/<>/attr/apparmor/exec ? I see that is used now in groovy too19:55
ijohnsonjdstrand: for example19:55
ijohnson2020-09-24T19:37:19.1095835Z [Thu Sep 24 19:36:48 2020] audit: type=1400 audit(1600976207.587:66): apparmor="DENIED" operation="open" profile="/snap/core/10045/usr/lib/snapd/snap-confine" name="/proc/38092/attr/apparmor/exec" pid=38092 comm="snap-confine" requested_mask="w" denied_mask="w" fsuid=0 ouid=019:55
jdstrandjjohansen: hey, can you answer ijohnson ^ (in meetings)20:18
jjohansenjdstrand: sorry which channel?20:19
jdstrandjjohansen: #snappy on frenode. this one :)20:19
jjohansenah, ijohnson, jdstrand: /proc/<>/attr/{apparmor/,}exec is used by apparmor for change_onexec20:21
ijohnsonjjohansen: with the new aa3 on groovy, to transition profiles, libapparmor will write to /proc/<pid>/attr/apparmor/exec now instead of /proc/<pid>/attr/exec correct ?20:21
ijohnsonjjohansen: thanks20:21
jjohansenthe new apparmor/exec path is the LSM stacking aware interface that is dedicated to apparmor20:21
jjohansenthe old attr/exec (no apparmor) is a shared interface20:22
jjohansenthe apparmor/exec is only on kernels 4.5 and newer20:22
jjohansenijohnson: apparmor3, will try both, it prefers the new apparmor/exec path20:23
jjohansenso it does it first20:23
jjohansenthings should work if it isn't allowed, but if we stack with another LSM we are going to want the newer path allowed20:23
ijohnsonjjohansen: ok, that makes sense, I will update snap-confine to allow both paths then20:24
ijohnsonjjohansen: do you want to quickly review https://github.com/snapcore/snapd/pull/9412/commits/0e2113642e4310c8e8c91cd58a00d01648f594d5 too? I pushed that commit after jdstrand gave +120:26
mupPR #9412: many/apparmor: adjust rules for reading profile/ execing new profiles for new kernel <Bug> <Needs security review> <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9412>20:26
ijohnsonit's only 2 lines :-)20:26
jjohansenijohnson: looks good20:27
ijohnsonjjohansen: thanks mind leaving a comment on the pr too?20:27
jjohansenijohnson: done20:30
ijohnsonjjohansen: thank you!20:31
mupPR snapcraft#3296 opened: meta: write stubs for command-chain using hooks when needed <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3296>20:54
* cachio afk21:18
mupPR snapd#9414 opened: tests: new nested tool <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9414>23:23
amurrayjdstrand: sure (re PR #7614) - I'll add it to my list23:27
mupPR #7614: cmd/snap-confine: implement snap-device-helper internally <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>23:27
jdstrandamurray: thanks!23:41

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!