[04:58] <mborzecki> morning
[05:48] <zyga> good  morning mborzecki
[05:48] <mborzecki> zyga: hey
[05:51] <zyga> mborzecki: trying the new atom feature
[05:51] <mborzecki> zyga: what is it?
[05:52] <zyga> https://blog.atom.io/2019/05/12/atom-1-37.html
[05:53] <zyga> it's pretty neat :)
[05:54] <mborzecki> zyga: interesting
[06:11] <zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/6856/files
[06:11] <mup> PR #6856: cmd/snap-update-ns: add tests for executeMountProfileUpdate <Created by zyga> <https://github.com/snapcore/snapd/pull/6856>
[06:11] <zyga> specifically this part https://github.com/snapcore/snapd/pull/6856/files#diff-6e1312a8e6236111d0199b57d496b986R87
[06:21] <mborzecki> zyga: do we have any helpers in the code to find a mount point given a device/source name?
[06:22] <mborzecki> oh, well, i'll use LoadMountInfo() then
[06:53] <mborzecki> off to drop some papers at my accountant's
=== pstolowski|afk is now known as pstolowski
[07:01] <pstolowski> mornings
[07:07] <pstolowski> zyga: hey, you there?
[07:48] <mborzecki> re
[08:03] <pstolowski> mborzecki: hey, 6868 can land
[08:03] <mborzecki> pstolowski: hey
[08:03] <mborzecki> pstolowski: Chipaca: thanks for the reviews
[08:04] <mup> PR snapd#6868 closed: systemd: workaround systemctl show quirks on older systemd versions <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6868>
[08:04] <mborzecki> #6860 has some new selinux denials, need to look at those
[08:04] <mup> PR #6860: tests: running tests on fedora 30 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6860>
[08:28] <mborzecki> Chipaca: morning, thanks for the reviews!
[08:29] <Chipaca> mborzecki: niets te danken, or something
[08:30] <mborzecki> Chipaca: nice :) still remembering some dutch?
[08:31] <Chipaca> mborzecki: i think 'niets te danken' and 'natuurlijk' are the only bits i remember at this point
[08:40] <Chipaca> mborzecki: dunno if you saw but i tagged #6868 for 2.39
[08:40] <mup> PR #6868: systemd: workaround systemctl show quirks on older systemd versions <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6868>
[08:41] <Chipaca> because it seems to me to be the right combination of safe and important
[08:41] <mborzecki> Chipaca: great, thanks
[08:41] <mborzecki> we'll be doing .1 anyway to include zyga's fixes
[08:41] <Chipaca> yep
[08:54] <zyga> hey hey
[08:54] <zyga> my fixes are almost ready, just need to add an instance test
[08:54] <zyga> I was trying to get to it between sessions
[08:56] <Chipaca> zyga: is that going to be in a separate pr?
[09:07]  * mborzecki feels sorry for whoever will review the raw image writer bits 
[09:15] <Chipaca> mborzecki: could you wrap up your review of #6721 at some point?
[09:15] <mup> PR #6721: tests: new profiler snap used to track cpu and memory for snapd and snap commands <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6721>
[09:15] <mborzecki> Chipaca: sure
[09:16] <mborzecki> Chipaca: all that was missing was +1 :)
[09:16] <Chipaca> mborzecki: :)
[09:16] <Chipaca> i'm using my gh.go thing to find low-hanging fruit
[09:17] <mborzecki> i've restarted travis jobs, last it built was 13 days ago
[09:18] <Chipaca> might need a re-merge, we'll see
[09:18] <Chipaca> anyway cazzo has a few housekeeping things to do with his PRs
[09:24] <Chipaca> cmatsuoka: you around?
[09:24] <cmatsuoka> Chipaca: hello
[09:24] <Chipaca> cmatsuoka: hiya! good morning
[09:25] <cmatsuoka> good morning!
[09:25] <Chipaca> cmatsuoka: the "RootOnly" flag is now merged, and I don't know what to do with #6679: if that work continues, is it going to start there, or are you going to do it again from scratch?
[09:25] <mup> PR #6679: many: implement user removal <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/6679>
[09:25] <Chipaca> cmatsuoka: IOW should I close the PR :)
[09:26] <Chipaca> RootOnly was only one of the parts of the puzzle that needed solving first
[09:26] <Chipaca> the other was about classic
[09:26] <cmatsuoka> Chipaca: I think it will be cleaner to restart from scratch, we can just drop the old PR
[09:27] <Chipaca> cmatsuoka: ok. I'll close it, unless you want to do so
[09:27] <cmatsuoka> close it, please
[09:29] <cmatsuoka> oh, the link is right here, I can close it as well
[09:29]  * cmatsuoka still sleepy, jet lag
[09:30] <mup> PR snapd#6679 closed: many: implement user removal <Created by cmatsuoka> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6679>
[09:31] <Chipaca> mborzecki: in #6680, when you say 'root only', do you mean _actual_ root only, or is logged-in ok also?
[09:31] <mup> PR #6680: [RFC] daemon: expose pprof endpoints <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6680>
[09:33] <mborzecki> Chipaca: hm it's trace & profiling, not sure if anthing sensitive is accessible through the api, it's probably just stacktraces & addresses
[09:33] <mborzecki> maybe addresses are sensitive ?
[09:34] <mborzecki> Chipaca: limiting access to uid 0 probably the safest approach
[09:34] <Chipaca> mborzecki: ok, i included how to do that in my review
[09:34] <Chipaca> ('s trivial)
[09:34] <mborzecki> Chipaca: see that now, thanks
[09:35] <Chipaca> cmatsuoka: I'll be working on the next bit of user thing refactoring, namely making the user thing not be there on classic by default
[09:35] <Chipaca> cmatsuoka: after that you should be able to work on the removal without issue
[09:43] <mup> PR snapcraft#2564 opened: remote_build: handle git push in detached head state <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2564>
[09:51] <mborzecki> going back home
[10:00] <zyga> Chipaca: that bug? no, all one PR
[10:00] <zyga> Chipaca: all the propagation fixes are in one PR (still pending because conference)
[10:01] <Chipaca> zyga: not related to #6866 then?
[10:01] <mup> PR #6866: cmd/snap-update-ns: allow changing mount propagation <Created by zyga> <https://github.com/snapcore/snapd/pull/6866>
[10:01] <popey_> when is 2.39 out?
[10:32] <mup> PR snapd#6869 opened: daemon: only allow `users`/`create-users` when not on classic* <Created by chipaca> <https://github.com/snapcore/snapd/pull/6869>
[10:32] <Chipaca> hmm, that PR looks a little daunting
[10:33] <Chipaca> popey_: cachio was coordinating with mvo and store people, dunno how that went
[10:33] <Chipaca> popey_: "asap"
[10:33] <popey_> ok
[10:34] <mborzecki> re
[10:34] <zigford> Anyone familiar with the recent change where snap-seccomp now requires a buildid? Version bumping my Gentoo snapd package and hung up on this.
[10:38] <Chipaca> zigford: yes
[10:38] <Chipaca> zigford: we landed a fix for that in master 15 days ago though
[10:38] <Chipaca> zigford: not sure what you're building
[10:38] <Chipaca> in particular: #6782
[10:38] <mup> PR #6782: osutil: use go build-id when no gnu build-id is available <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6782>
[10:39] <zigford> Did that make it into 2.39?
[10:40]  * Chipaca asks git
[10:40] <Chipaca> zigford: no
[10:41] <Chipaca> at least, git says no
[10:41] <zigford> okay, no worries. I'll see if I can just patch in that commit
[10:41] <Chipaca> k
[10:41] <Chipaca> zigford: I'll flag mvo to see if we add it to 2.39.1
[10:43] <zigford> Confirmed by looking in the release .tar.gz that it is not in 2.39
[10:44] <zigford> I don't know what it takes to use gnu buildid's which is probably why it is not working without that commit on my Gentoo ebuild.
[10:45] <Chipaca> zigford: I think it's because we got rid of CGO dependencies that would previously allow gnu buildid to be involved
[10:49] <mborzecki> hm that PR should not be required for snap-seccomp
[10:49] <mborzecki> zigford: does your snap-seccomp have no buildid?
[10:50] <zigford> correct. The output when running snap-seccomp: error: cannot get build-id of snap-seccomp: executable does not contain a build ID
[10:50] <zigford> I mean snap-seccomp version-info
[10:50] <zigford> It could be the way I'm compiling it too. I'm a bit of a n00b when it comes to golang
[10:53] <mborzecki> zigford: can you run `file <path-to-snap-seccomp>` ?
[10:53] <zigford> Certainly appears to have a buildid according to file: snap-seccomp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, Go BuildID=a8kMN841Luo-M1zG6V_w/k1vJUu3M_98NWHHNQyDR/4QcWrWhdOMwMS78nFYhQ/pb96YzBzA9BKT4Mc4AMS, stripped
[10:55] <mborzecki> interesting, that's only the buildid added by go toolchain
[10:57] <mborzecki> zigford: when you build the package, can you add -x -v to go build and upload the output somewhere
[10:57] <mup> PR snapd#6870 opened: cmd/snap, api, snapstate: implement "snap remove --purge" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6870>
[11:01] <zigford> http://zigford.org/build.log
[11:02] <zigford> might have to search, as that log builds all the bits
[11:06] <mborzecki> zigford: thanks, so it's using gcc to drive the linking, but somehoow there's no GNU buildid added
[11:07] <mborzecki> zigford: can you try this `echo 'int main() { return 0; }' | gcc -xc  - && file ./a.out` ?
[11:08] <zigford> ./a.out: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not stripped
[11:09] <mborzecki> zigford: right, but it adds gnu buildid automatically on my system
[11:09] <zigford> Could BuildID's be a compile time option of GCC, ie, On Gentoo, GCC is compiled by my system, and the feature to create buildid's might be disabled
[11:10] <mborzecki> zigford: maybe some defaults are different, i doubt it would be disabled
[11:10] <mborzecki> zigford: can you try this: `echo 'int main() { return 0; }' | gcc -xc -Wl,--build-id=sha1 - && file ./a.out` ?
[11:11] <zigford> ./a.out: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=9fe501acda2e1d8562da2548c42b9361344804f5, not stripped
[11:12] <mborzecki> zigford: just for the record, what's the version of binutils and gcc?
[11:13] <zigford> gcc = 8.3.0, binutils = 2.31.1
[11:15] <thomascm> Hey everyone, is there a way to know if a bug if good for newcomers?
[11:15] <mborzecki> zigford: can you check if there's --enable-linker-build-id in gcc -v output?
=== ricab is now known as ricab|bbl
[11:17] <zigford> alas, it is not
[11:19] <mborzecki> zigford: right, so the PR that Chipaca linked makes snapd side of things support both GNU build id and Go build id (in case the first one is missing), but that won't be available in 2.39 until 39.1 (?)
[11:20] <mborzecki> zigford: meanwhile, maybe there's a use flag to enable build-id by default? this is enabled in configure of gcc
[11:21] <zigford> Yeah, I quickly checked that, but I think I might be able to find another ebuild package the enables it and just plagerize their work :)
[11:21] <zigford> So, there does not appear to be a use flag for GCC to enable it by default
[11:21] <Chipaca> thomascm: what do you mean?
[11:22] <zigford> Many thanks for your assistence in tracking down the issue, mborzecki
[11:23] <mborzecki> zigford: np, perhaps you could tweak CC/CFLAGS/LDFLAGS to add -Wl,--build-id=sha1
[11:24] <thomascm> chipaca: well there many bugs in launchpad, and I am not sure where to start, this is the first opensource project that I contribute to...usually someone is assigning me issues :P
[11:24] <zigford> Great idea. I'll post back here if I get it working
[11:27] <Chipaca> thomascm: I don't think we've been good at tracking "bitesize" bugs
[11:27] <Chipaca> we tried to start doing that but it didn't get momentum
[11:27] <Chipaca> thomascm: are you wanting to contribute to snapd, or to snapcraft?
[11:36] <Chipaca> pstolowski: what's the "dangerous" thing in the purge pr?
[11:43]  * Chipaca hugs pstolowski 
[11:43] <Chipaca> pstolowski: 's good, just one mistake i think
[11:43] <pstolowski> Chipaca: thanks for catching!
[11:43] <thomascm> Chipaca: snapd
[11:44] <Chipaca> thomascm: what do you know? what can you do?
[11:54] <pstolowski> Chipaca: hmm. i think i will simply pass bool there in the client (+options which will still be expected to be nil as before). don't see any nice way to check if anything-but-purge was passed
[11:55] <thomascm> chipaca: sorry getting ready to leave for work. I can program in python, php, javascript, and new to golang ... I can handle most task, it just I don't have a lot of time, a few hours a week, so I rather start with smaller issues
[11:58] <mup> PR snapcraft#2565 opened: requirements: update to requests-toolbelt 0.8.0 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2565>
[12:11] <cachio> mborzecki, hey
[12:12] <cachio> mborzecki, there is a problem on fedora 30
[12:12] <zigford> mborzecki: fixed by adding a parm to go like so: go install --ldflags '-extldflags "-Wl,--build-id=sha1"'
[12:12] <cachio> I run the suite in a vm and after some tests it is out of space on disk
[12:13] <cachio> mborzecki, it is weird because du -h says we use 4.5 of 9 GB
[12:13] <cachio> mborzecki, I created a debug machine if you want to take  a look
[12:13] <mborzecki> zigford: yup, that should work too
[12:13] <cachio> I am debugging this as well
[12:14] <mborzecki> cachio: can you point me to the log?
[12:17] <cachio> mborzecki, https://paste.ubuntu.com/p/ckqhnFxvFC/
[12:17] <cachio> mborzecki, this is one from my machine
[12:21] <dot-tobias> jdstrand / diddledan: Ping re: /dev/shm if you have the time 😊  → https://forum.snapcraft.io/t/proposal-add-dev-shm-namespace-to-all-snaps-by-default/5416/5?u=tobias
[12:24] <diddledan> dot-tobias: have you tried the `browser-support` interface for the dev/shm access?
[12:25] <dot-tobias> diddledan: Not yet, since I thought using this interfaces prevents publishing on the store without exceptions
[12:25] <diddledan> you'll need to get approval for automatic connection of the interface if you need it
[12:26] <diddledan> you can request the store admins to verify and approve/deny the automatic connection by posting in the store-requests category on the forum
[12:30] <ijohnson> dot-tobias: fwiw the snap you mention in your forum post seems like a browser so it doesn't seem unreasonable to provide browser-support to that snap
[12:32] <mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
[12:32] <mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
[12:33] <mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
[12:33] <mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
[12:33] <dot-tobias>  ijohnson: Yep, its a browser 😊
[12:34] <dot-tobias> diddledan: Ok, will try out locally with browser-support instead of preload + desktop launch first. I'm including this snap in a gadget and ran into issues with auto-installing chromium-mir-kiosk with browser-support interface before, but maybe that's resolved
[12:35] <ijohnson> yeah so requesting browser-support should be fine
[12:35] <ijohnson> since you're using a kiosk, you may have your snap flagged since it would be a daemon and also use browser-support, which is not automatically allowed but that should be approved eventually
[12:37] <dot-tobias> diddledan / ijohnson: Just tested if browser-support resolves the shared memory error, but does not seem like it: Still getting “Failed to create shared memory file /WK2SharedMemory.3964029874: Permission denied” with browser-support interface connected for my snap.
[12:38] <ijohnson> dot-tobias: what is the apparmor denial for your snap when you try this?
[12:39] <dot-tobias> ijohnson: For whatever reason there's no syslog on my Core test machine … Core 18 on PC gadget+kernel
[12:40] <ijohnson> can you get logs from `journalctl -e --no-pager | grep apparmor | grep DENIED
[12:41] <dot-tobias> ijohnson: Yup: May 15 12:36:24 localhost kernel: audit: type=1400 audit(1557923784.977:691): apparmor="DENIED" operation="mknod" profile="snap.wpe-webkit-mir-kiosk.browser" name="/dev/shm/WK2SharedMemory.1479971001" pid=29142 comm="cog" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
[12:42] <ijohnson> dot-tobias: hmm that should be allowed: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/browser_support.go#L228
[12:43] <ijohnson> I assume your snap is a daemon because it's a kiosk, but just to clarify the wpe-webkit-mir-kiosk.browser app is a deamon right/
[12:43] <ijohnson> ?
[12:43] <dot-tobias> ijohnson: Correct
[12:43] <diddledan> that's with sandbox
[12:43] <diddledan> you either need to specify the sandbox on the interface or disable the webkit sandbox
[12:43] <ijohnson> ahh yes listen to diddledan
[12:44]  * ijohnson will be back in a bit
[12:57] <dot-tobias> diddledan: I'm testing locally with allow-sandbox: true and running into a very stupid problem … how do I specify a list of plugs for an app where one is not a simple list entry but a dict (i.e. browser-support: \n allow-sandbox: true)
[12:58] <diddledan> specifying interface options is a separate block to the `plugs` on an app:
=== ricab|bbl is now known as ricab
[12:59] <diddledan> https://www.irccloud.com/pastebin/LFF8yqR4/
[13:01] <Chipaca> cachio: standup?
[13:01] <diddledan> Chipaca: sit down!
[13:01] <Chipaca> diddledan: dance!
[13:02] <cachio> Chipaca, OMW
[13:02] <diddledan> boogy!
[13:02] <Chipaca> cachio: k
[13:02] <diddledan> /o/
[13:02] <diddledan> \o\
[13:02] <diddledan> \o/
[13:02] <diddledan> /o\
[13:02]  * Chipaca assigns bugs to diddledan 
[13:02] <diddledan> oh damn
[13:07] <dot-tobias> diddledan: Thanks, works – the /dev/shm error is gone, but for whatever reason WPE can't find libraries that are definitely in the snap (and work fine when using snapcraft-preload + desktop-launch). Need to investigate this more .
[13:09] <zyga> re
[13:11]  * dot-tobias waves at zyga
[13:15] <Chipaca> cachio: there should be a few lines wrt that cycle, listing all the things in the cycle
[13:15] <Chipaca> cachio: can you pastebin the whole thing?
[13:15] <Chipaca> systemd will be always killing one of the units in the cycle to break it, but it picks one at random
[13:16] <cachio> Chipaca, https://paste.ubuntu.com/p/8p3xhCRZTH/
[13:16] <cachio> Chipaca, random :s
[13:16] <cachio> that explains why it is happening randomly
[13:18] <Chipaca> cachio: so it's one of those four things
[13:18] <Chipaca> three, really, because one is a target
[13:18] <Chipaca> and two of them are google
[13:18] <Chipaca> so i guess it's just the one :-)
[13:18] <cachio> hehehe
[13:18] <Chipaca> suspect you need to talk with the cloud-init devs
[13:18] <Chipaca> cachio: this is only on fedora?
[13:19] <cachio> Chipaca, it is only on fedora 30
[13:19] <Chipaca> maybe they have a "different" version of something
[13:19] <Chipaca> cachio: can you compare the unit files for those four things in fedora 30 vs 29, say?
[13:19] <cachio> Chipaca, yes
[13:19] <Chipaca> cachio: digo 30 vs 29 so they might be closer than 30 vs 19.04
[13:19] <cachio> I'll check that
[13:20] <cachio> ok}
[13:20] <Chipaca> cachio: OTOH if you're seeing bug reports with this issue for ubuntus, maybe it's known and fixed in cloud-init and just needs updating on fedora
[13:22] <cachio> Chipaca, the issues reported are with the same error message but different root cause
[13:22] <Chipaca> cachio: aw
[13:22] <cachio> systemctl cat cloud-init
[13:24] <cachio> Chipaca, I'll review the open issues first and compare configuration with f29 and u19.04
[13:24] <cachio> to see I can find the diff
[13:24] <Chipaca> k
[13:42] <Chipaca> pstolowski: OTOH wrt checking whether only Purge is set, go can compare "flat" structs directly, so just checking whether the struct was equal to the empty one or the empty one with just purge set would work
[13:43] <Chipaca> (and client.SnapOptions is "flat" in this sense)
[13:44] <pstolowski> hmm indeed
[13:52] <pstolowski> Chipaca: nah, doesn't work because of Users []string
[13:52] <Chipaca> o dang
[13:53] <Chipaca> well
[13:53] <Chipaca> you could embed the bools and compare that
[13:53] <Chipaca> but it gets silly
[13:53] <Chipaca> every other option is not allowed in multi
[13:53] <Chipaca> so just, go with that
[13:53] <Chipaca> we'll add support for multi sometime, and it'll be fine
[13:53] <Chipaca> but there's not a lot of demand so ¯\_(ツ)_/¯
[13:54] <pstolowski> ok
[13:57] <Chipaca> pstolowski: maybe remove it from multiActionData also :)
[13:58] <pstolowski> oh yes!
[13:59] <pstolowski> ty
[14:27] <mup> PR snapd#6871 opened: gadget: raw/bare strcuture writer and updater <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6871>
[14:29] <mborzecki> only excuse i have is that tests make up ~70% of the whole thing
[14:38] <Chipaca> cachio: note #6618 is >this< close to a second +1, there's a suggestion from mvo that's hard to ignore
[14:38] <mup> PR #6618: tests: validates snapd from ppa <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6618>
[14:40] <cachio> Chipaca, yes, I'll update that PR today
[14:41] <cachio> thanks for the heads up
[14:41] <Chipaca> cachio: ping me when you do (and it's green) so we can land that
[14:41] <cachio> Chipaca, sure
[14:42]  * cachio lunch
[14:51] <Chipaca> ondra: ping
[14:58] <ondra> Chipaca hey
[14:58] <ondra> Chipaca what's up?
[15:01] <Chipaca> ondra: hey
[15:01] <Chipaca> ondra: looking at your PRs
[15:01] <Chipaca> ondra: in particular #6691
[15:01] <mup> PR #6691: boot: move ExtractKernelAssets <Created by kubiko> <https://github.com/snapcore/snapd/pull/6691>
[15:02] <Chipaca> ondra: it looks abandoned
[15:02] <ondra> Chipaca no, I just need update test based on mvo's comment
[15:02] <ondra> Chipaca just did not find time yet :(
[15:02] <Chipaca> ondra: ah, ok, so i'll review it then
[15:03] <ondra> Chipaca actually review avahi one pls
[15:03] <ondra> Chipaca https://github.com/snapcore/snapd/pull/6325
[15:03] <mup> PR #6325: Allowing avahi-observer/control slots from app snap also on classic <Created by kubiko> <https://github.com/snapcore/snapd/pull/6325>
[15:03] <Chipaca> ondra: it's got a needs-changes from jdstrand and conflicts
[15:04] <ondra> Chipaca yeah I did those
[15:04] <Chipaca> ondra: that means "stay away" in reviewese
[15:04] <ondra> Chipaca but it based on those changes it was bigger change, so it'd be good to have extra pair of eyes on it
[15:04] <ondra> Chipaca lol
[15:05] <Chipaca> ondra: i tried to look at your lk pr, and that looks interesting but it includs 6691 and is rather big to review in a single go
[15:05] <Chipaca> ondra: what's the status of #6327?
[15:06] <mup> PR #6327: Allowing sockets under /run/user/0/$SNAP_NAME <Created by kubiko> <https://github.com/snapcore/snapd/pull/6327>
[15:09] <ondra> Chipaca also more looking for time to rewrite it based on jdstrand comments, but that's last one on my priority list now
[15:09] <Chipaca> ondra: if it's a rewrite, would it be ok to close it? or is it not a rewrite in that sense
[15:10] <ondra> Chipaca not in that sense, still same idea, just a bit more clever implementation
[15:10] <Chipaca> ah well
[15:10]  * Chipaca goes on down the list
[15:24] <Chipaca> zyga: for per-user mounts is there something reviewable?
[15:33] <Chipaca> mborzecki: what should we do with #6708 ?
[15:33] <mup> PR #6708: packaging/ubuntu: enable PIE hardening flags <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>
[15:40] <Chipaca> #6734 could use a second review
[15:40] <mup> PR #6734: advise-snap: add --dump-db which dumps the command database <Created by shawnl> <https://github.com/snapcore/snapd/pull/6734>
[18:04] <zyga> Chipaca: I’m sorry for responding late
[18:04] <zyga> Not yet
[18:04] <zyga> Need to sit down tonight
[18:30] <Chipaca> zyga: no worries, asking only because i was going down the list