[00:06] <mup> PR snapd#6133 opened: tests: fix how pinentry is prepared for new gpg v 2.1 and 2.2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6133>
[02:52] <mup> PR snapd#6134 opened: tests: skip opensuse from interfaces-openvswitch-support test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6134>
[06:14] <mborzecki> morning
[06:31] <zyga> good morning
[06:34] <mborzecki> zyga: hey, i usually stay away from the computer over the weekends, but i tried 2.36.1 snapd in opensuse TW, seems to be working fine, nvidia, basic AA
[06:34] <zyga> that's great, thank you for trying!
[07:36] <kjackal> hello snappy people, did we do a core release?
[07:38] <mvo> kjackal: we have not made a stable release yet, 2.36.1 is still under QA
[07:45] <zyga> hey mvo
[07:45] <mvo> zyga: good morning!
[07:45] <zyga> hey, just getting into the office
[07:47] <mborzecki> mvo: hey, had to restart travis job in 6039 as it timeouted
[07:47] <mvo> mborzecki: :( ok
[07:47] <mvo> mborzecki: thank you
[07:48] <mborzecki> mvo: heh, and another restart, was it the same yday?
[07:49] <zyga> mvo: what should I attack first? the bug that a customer found or anything else?
[07:49] <mvo> zyga: please check my PR on top of yours, it has a spread test. I'm cleaning the mock gpio a bit more as we speak but the basic idea is the same. but you can also wait for ~10min, then I shall push this small cleanup. either way is fine
[07:50] <zyga> super, I'll check it out
[08:04] <mvo> zyga: we should probably also switch the other gpio spread tests to the new method (6128). I pushed the updated code I may need to tweak a bit more, spread test is still running but this should allow you to see what is going on
[08:05] <pstolowski|afk> morning
[08:06] <zyga> mvo: thanks, I'm reading reviews and should get to yours in a moment
[08:06] <zyga> hey pawel
[08:08] <zyga> mvo: https://github.com/snapcore/snapd/pull/6128/commits/dd08e0ed21fe2dd9030887d386f0971391dd0459 hmm
[08:08] <mup> PR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <https://github.com/snapcore/snapd/pull/6128>
[08:08] <zyga> mvo: the reason I did it that way was to not change the behaviour of other code
[08:08] <zyga> that's not something we catch in tests today
[08:08] <zyga> but this changes the order of setup in all the interfaces
[08:08] <zyga> whereas the initial branch was just changing it for gpio (in practice, because that is the only consumer)
[08:08] <zyga> I'd like to postpone that tweak to 2.37
[08:09] <mvo> zyga: my PR is aimed for edge
[08:09] <pstolowski> zyga: hey, we need to talk about the mapper and implicit slots, can we have a chat in 10-15 mins?
[08:10] <mvo> zyga: we need to find out if the user who is affected is fine with refreshing to edge or if we wants something else
[08:10] <mvo> zyga: but unless we know that I think its ok to build something for edge
[08:10] <zyga> mvo: I think edge might be okay for them but regardless I think we should do a deeper inspection of the impact of the change in ordering
[08:10] <zyga> note that I fused the setup of the principal snap and the affected snaps
[08:11] <zyga> so now we do things in quite a different order in practice
[08:11] <mup> PR snapd#6135 opened: packaging/arch: fix bash completions path <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6135>
[08:11] <mvo> zyga: fair enough, I feel slightly uneasy about this too. is gpio the only thing that uses systemd?
[08:11] <zyga> yes
[08:11] <mborzecki> trivial PR ^^
[08:11] <zyga> don't get me wrong, I think what you did is _desired_
[08:11] <zyga> it's just that I wanted to do that separately, once the fire is put out
[08:11] <zyga> because it has bigger impact
[08:11] <mvo> zyga: yeah
[08:11] <zyga> and it may not be as fully tested
[08:11] <mvo> zyga: ok
[08:11] <zyga> since our unit tests use one test backend
[08:12] <zyga> they don't exercise those interactions
[08:12] <mvo> ok
[08:12] <zyga> so we only have spread tests to, hopefully, catch any issues
[08:12] <mvo> pstolowski: 6132 should be an easy merge
[08:13] <pstolowski> looking
[08:13] <mvo> zyga: ok, lets cherry pick the spread test to your PR and we can discuss the approach in the standup
[08:13] <zyga> ok
[08:15] <mup> PR snapd#6132 closed: many: some small doc comment fixes in recent hotplug code <Created by pedronis> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6132>
[08:18] <zyga> mvo: one thing I don't get about the spread test, where is the GPIO pin definition?
[08:18] <zyga> the slot that is
[08:21] <mvo> zyga: in prepare.sh
[08:21] <mup> PR snapd#6136 opened: tests: run interfaces-openvswitch-support on arch again, the arch bug is fixed <Created by mvo5> <https://github.com/snapcore/snapd/pull/6136>
[08:21] <mvo> zyga: it is part of the core snap
[08:21] <zyga> ah, I din't notice thatt
[08:21] <mvo> zyga: we unpack and modify the core snap during setup to add one
[08:21] <mvo> zyga: its quite hidden :(
[08:22] <mvo> zyga: also it is not done for core18 so there is work there as well, I want to look at this too
[08:22] <mvo> zyga: plus we have some existing gpio tests which can also be simplified
[08:26] <mvo> zyga: thanks for the review, I address your points now :) I pushed a small tweak already
[08:26] <zyga> mvo: thank *you* for writing this :)
[08:26] <zyga> I didn't think about mocking the whole thing this way
[08:28] <mborzecki> mvo: one more fix needed in 6039, will push it in a bit
[08:28] <mvo> mborzecki: what is the fix ? spread test that checks the error message? thanks for handling this!
[08:29] <mborzecki> mvo: yup, the spread test
[08:38] <mup> PR snapd#6131 closed: store:  remove unused currentSnap and currentSnapJSON <Simple 😃> <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6131>
[08:41] <pedronis> pstolowski: hi, I finished reading the already landed hot plug code, thanks for looking at my small doc tweaks. Of that the only bit I wasnt sure about is hotplug/spec.go,  it makes it look like a backend but it's not, also not sure why it's organized exactly like it is, but anyway nothing deep, can be reconsidered when I get further. I will start reviewing new code today, when I'm not in meetings :)
[08:47] <pstolowski> pedronis: thanks. sure, we can discuss if hotplug spec should be re-organized. it's an API for interfaces, not sure if this is clear from what already landed, but the camera interface is an example of how this is used - https://github.com/snapcore/snapd/pull/6098 ; i've done it like that to follow the general pattern of *.Specifificaton objects that we pass to interfaces, this was from suggestions from early reviews
[08:47] <mup> PR #6098: interfaces/builtin: support hotplug for camera interface <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6098>
[08:48] <pedronis> pstolowski: yes, I understand but is used very differently, I'm not sure if the similiraty helps or is confusing
[08:48] <pedronis> anyway there is no action atm
[08:49] <pedronis> just pointing out that I wondered a bit about this bit
[08:49] <pstolowski> sure, i see
[08:55] <mvo> zyga: updated 6128
[08:55] <zyga> mmm
[08:56] <zyga> neat, thank you!
[09:00] <pstolowski> zyga: do you have some time to talk about mapper/implicit slots?
[09:04] <pstolowski> #6124 is trivial, needs 2nd review
[09:04] <mup> PR #6124: tests: simple reproducer for snap try and hooks bug <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6124>
[09:09] <zyga> pstolowski: I think so
[09:15] <pstolowski> zyga: standup HO?
[09:15] <mvo> pstolowski: occupied ;)
[09:15] <pstolowski> :)
[09:16] <zyga> pstolowski: can we have a call on tg?
[09:16] <zyga> pstolowski: just need to print one last invoice
[09:16] <zyga> sorry, monthly accounting time
[09:17] <pstolowski> zyga: sure. nb, i recommend switching to queterly ;)
[09:17] <zyga> queterly?
[09:18] <zyga> ah
[09:18] <zyga> I get it
[09:18] <pstolowski> telegram is fine
[09:19] <zyga> one sec, printer didn't respond
[09:32] <mup> PR snapd#6130 closed: snap: make Epoch's MarshalJSON not simplify <Simple 😃> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6130>
[09:32] <zyga> pstolowski: ok, you have my full attention now
[09:32] <zyga> pstolowski: is the HO still used?
[09:34] <zyga> seems to be
[09:34] <pstolowski> zyga: yep
[09:34] <zyga> pstolowski: how about https://meet.google.com/fsz-xtpa-xqb?ijlm=1542101675152&adhoc=1&hs=125&authuser=0
[09:51] <mup> PR snapd#6039 closed: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6039>
[09:51] <mborzecki> yay!
[09:52] <popey> double yay
[10:01] <mvo> mborzecki: yay indeed - thank you!
[10:02] <mborzecki> mvo: thank you for picking it up in the first place :)
[10:07] <mvo> mborzecki: silly question about 6136 - the bug that prevented the openvswitch-support test to run is now fixed. but the test still fails. do we just need to blacklist it or is it something simple (like a missing package dependency)?
[10:08] <mborzecki> mvo: i think we may need to start uuidd.socket before the test (at least on arch)
[10:13] <mvo> mborzecki: aha, right - this does not happen on package install automatically
[10:13] <mup> PR snapd#6137 opened: snap: make Epoch default to {[0],[0]} on load from yaml <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6137>
[10:24] <zyga> I will need to work from the road one more time today
[10:24] <zyga> need to sign the paperwork and say goodbye to my car today
[10:24] <zyga> I will focus on reviews while on the road
[10:30] <mup> PR core18#88 closed: hooks: make ld-so symlink in /lib64 relative <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/88>
[10:30] <zyga> random test failure from reviews:
[10:30] <zyga> https://www.irccloud.com/pastebin/6mMG7HK9/
[10:31] <mup> PR core18#83 closed: add swapfile support (ported from ubuntu-core-config) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/83>
[10:32] <zyga> pedronis: question about an error I saw over weekend:
[10:33] <zyga> zyga@pi2-2:~$ sudo snap refresh
[10:33] <zyga> error: too early for operation, device not yet seeded or device model not acknowledged
[10:33] <zyga> pedronis: I updated the timezone, time shifted one hour forward
[10:33] <pedronis> that check is not time dependent afaik
[10:33] <zyga> pedronis: that device then went into "busted mode"
[10:34] <zyga> not sure what happened
[10:34] <pedronis> ah
[10:34] <zyga> I have it disconnected to inspect
[10:34] <zyga> perhaps some tasks didn't run
[10:34] <pedronis> it's really busted if it thinks is not seeded anymore
[10:34] <pedronis> or it lost its model
[10:34] <zyga> it went from "stable released on cdimage" to stable
[10:34] <zyga> just flash and refresh
[10:34] <zyga> I'll collect more data and report it
[10:36] <mvo> doko: hey, could you please click on "Request builds" in https://code.launchpad.net/~ubuntu-core-service/+snap/core18  and do an amd64 build for me? I don't have permissions to do this myself anymore :/ (or someone else from foundations maybe?)
[10:42] <Chipaca> zyga: if you're in review-mode, 6137 is nice an' easy :-)
[10:43] <Chipaca> it was a tiny part of #6052 but stands on its own
[10:44] <mup> PR #6052: snap, store, overlod/snapstate: always send epochs <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6052>
[10:44] <Chipaca> and will make the actually-send-epochs pr that much easier to review
[10:53] <mborzecki> hmm fake store does not send snap type :/
[10:54] <mup> PR snapd#6124 closed: tests: simple reproducer for snap try and hooks bug <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6124>
[10:54] <mvo> mborzecki: uh, I thought we fixed that :(
[11:24] <zyga> I’m in review mode but signing papers now
[11:25] <Chipaca> mvo: isn't there more than one fake store?
[11:41] <mup> PR snapd#6138 opened: overlord/ifacestate: use remapper when checking if system snap is installed <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6138>
[11:42] <pstolowski> zyga: does this make sense? ^
[11:51] <Chipaca> this epoch vs *epoch things gets annoying
[11:51] <mup> PR snapd#6134 closed: tests: skip opensuse from interfaces-openvswitch-support test <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6134>
[11:55] <mup> PR snapd#6129 closed: data/completion: pass documented arguments to completion functions <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6129>
[11:56] <zyga> pstolowski|afk: done
[11:57] <zyga> Chipaca: 6137 ready
[11:58] <mup> PR snapd#6137 closed: snap: make Epoch default to {[0],[0]} on load from yaml <Simple 😃> <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6137>
[12:01] <mup> PR snapd#6139 opened: snap, store, overlord/snapshotstate: drop epoch pointers <Created by chipaca> <https://github.com/snapcore/snapd/pull/6139>
[12:10] <Chipaca> zyga: you'll like 6139 but it's not simple
[12:10] <Chipaca> bah. It's simple. It's also long.
[12:10] <Chipaca> relatively
[12:24] <ogra> cjwatson, i have a prob with stage-packages when cross building, i have tired three variants yet: https://paste.ubuntu.com/p/XpRF9ND5tf/ the first one gets me a build error telling me i need "dpkg --add-architecture armhf", the latter two are completely ignored, am i doing anything wrong or do i need a pecial part that calls dpkg --add-architecture first ?
[12:25] <ogra> *special
[12:25] <ogra> note this works fine with a local build
[12:27] <ogra> (i had the impression with the recent architecture changes on the buildds such things should be possible without extra hacks)
[12:32] <cjwatson> ogra: I really have no idea, I'm sorry.  I would not have expected this to be at all affected by recent changes
[12:33] <cjwatson> All we did in LP was arrange to understand the syntax enough to dispatch builds to the right architectures
[12:33] <zyga> Looking
[12:33] <cjwatson> This is mostly on the snapcraft side AFAIK
[12:33] <ogra> ok, but we dont automatically add all possible arches to the sources.lists
[12:33] <cjwatson> We do not, at present
[12:34]  * Chipaca ~> lunch
[12:34] <ogra> i'll try a part that call "dpkg --add-architecture armhf" then, lets see
[12:34] <ogra> *calls
[12:34] <cjwatson> Maybe also apt update, not sure
[12:34] <ogra> yep
[12:34] <ogra> (was to lazy to type that out :) )
[12:35] <pstolowski> pedronis: can you take a look at https://github.com/snapcore/snapd/pull/6138 (it's trivial)?
[12:35] <mup> PR #6138: overlord/ifacestate: use remapper when checking if system snap is installed <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6138>
[12:36] <pedronis> pstolowski: in a bit, about to go to my dentist appt
[12:36] <pstolowski> sure
[12:40] <zyga> Chipaca: reviewed
[12:40] <Chipaca> who's best to pick up a custom store contact?
[12:41] <zyga> Dunno
[12:41] <Chipaca> JamieBennett: ^?
[12:41] <Chipaca> zyga: thanks
[12:41] <JamieBennett> Chipaca: feel free to pass them on to me
[12:43] <Chipaca> JamieBennett: @'ed you on the forum
[12:43] <Chipaca> JamieBennett: thanks
[12:43] <ogra> cjwatson, FYI ... seemss to have worked
[12:43] <Chipaca> now yes, lunch
[12:44] <ogra> ARGH !
[12:44] <ogra> Store upload failed:
[12:44] <ogra>     ('Connection aborted.', gaierror(-3, 'Temporary failure in name resolution'))
[12:44] <ogra> i hate when that happens !!
[12:45] <cjwatson> You and me both
[12:47] <cjwatson> I've asked for the haywire worker to be killed
[12:54] <mup> PR snapd#6140 opened: tests, fakestore: extend refresh tests with parallel installed snaps <Parallel installs ⛓> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6140>
[12:57] <zyga> mborzecki: will you have time to look at https://github.com/snapcore/snapd/pull/6111
[12:57] <mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
[12:57] <zyga> Nothing urgent
[12:57] <mborzecki> zyga: i'm going out to pick up the kids in a bit, i can do that later or during the standup
[12:58] <zyga> Sure
[12:58] <zyga> Looking at https://github.com/snapcore/snapd/pull/6104 now
[12:58] <mup> PR #6104: snapctl: add "services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6104>
[12:59] <Chipaca> zyga: I need to tweak that pr
[13:00] <Chipaca> also i need to actually go do something about lunch
[13:00] <Chipaca> drat
[13:00]  * Chipaca rips himself away
[13:24] <mup> PR snapd#6136 closed: tests: run interfaces-openvswitch-support on arch again, the arch bug is fixed <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6136>
[13:41] <cachio> plars, cwayne, hey, could you please confirm if 2.36.1 is ready for candidate?
[13:41] <cachio> thanks
[13:56] <zyga> Chipaca: sure, let me know
[14:01] <mborzecki> Chipaca: standup
[14:20] <popey> cjwatson: got a developer reporting the name resolution error on build.snapcraft.io
[14:21] <popey> apolitech is the developer account
[14:26] <popey> hello APolihron :)
[14:28] <cjwatson> popey: how long ago?
[14:28] <mup> PR snapcraft#2403 opened: project_loader: add git to build-packages for version: git <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2403>
[14:28] <popey> APolihron: ^ When did it happen?
[14:28] <cjwatson> never mind
[14:39] <pedronis> Chipaca: did you see my pm with the link?
[14:40] <APolihron_> hey all! so i've change the yalm file from my github projects to build only for a amd64 , bump up the release number and the grade to stable but i get build, fail to release when using snapcraft.io build serv
[14:40] <APolihron_> this is one of the project that will not release
[14:40] <APolihron_> https://github.com/apolitech/Udemy/blob/master/snap/snapcraft.yaml
[14:41] <APolihron_> and this is the error Error:('Connection aborted.', gaierror(-3, 'Temporary failure in name resolution'))
[14:42] <cjwatson> APolihron_: This is https://bugs.launchpad.net/launchpad/+bug/1792920 - I've asked for the worker to be killed
[14:42] <mup> Bug #1792920: celery workers sometimes end up cursed and produce OOPSes for all SnapStoreUploadJobs <oops> <Launchpad itself:Triaged> <https://launchpad.net/bugs/1792920>
[14:50] <APolihron_> so how can i help or what i need to do?
[14:51] <cjwatson> APolihron_: wait until I tell you to try again, then try again
[14:52] <cjwatson> (I'm waiting for a sysadmin to get back to me)
[14:54] <APolihron_> ok
[14:54] <APolihron_> thanks
[15:04] <cjwatson> APolihron_: try again now
[15:11] <mborzecki> heh, our file.sh helpers are not eally working well with char devices, the checks all use `if [ -f ... ]` which is onviously not true for paths that are not regular files
[15:18] <mup> PR snapd#6141 opened: interfaces: export gpio pin in AppArmorConnectedPlug <Created by mvo5> <https://github.com/snapcore/snapd/pull/6141>
[15:18] <pstolowski> mborzecki: oh wow, nice finding!
[15:19] <mvo> pedronis: sorry to put more burden on your shoulders - I pushed 6141 which contains an alternative fix for the gpio problem. your input on this would be most welcome
[15:19] <mvo> pedronis: it sidesteps the problem entirely by avoiding the dependency between appamror and systemd on the expense of some extra code in the gpio interface
[15:24] <pedronis> mvo: so we understand we are both exporting it permanently (across reboots) via systemd units, and explicit in the app armor backend?
[15:24] <pedronis> s/we/I/
[15:28] <mvo> pedronis: correct
[15:29] <mvo> pedronis: this way we avoid the dependency that the systemd backend needs to start the unit before the apparmor backend can stat the symlink
[15:29] <pedronis> mvo: ok, I left a question there
[15:30] <APolihron_> cjwatson working, thanks
[15:30] <mvo> pedronis: thanks, I will look at this and reply inline there is a tocttou race here I think, both places check. otoh we don't run this is parallel yet so it should be fine
[15:31] <pedronis> mvo: as I said we let go of the lock for backends, so whether is run in parallel or not is a bit unclear
[15:32] <mvo> pedronis: so the race would be if two tasks both want to export gpio30 ?
[15:32] <pedronis> or we might have the unit
[15:32] <pedronis> and systemd is doing strange things
[15:32] <pedronis> or the user
[15:33] <pedronis> mvo: it seems at least that if you fail to write, you need to check if by chance the link is there
[15:33] <pedronis> if it is ignore the error
[15:33] <pedronis> that's my 2cts
[15:33] <mvo> pedronis: indeed, that is a good suggestion
[15:33] <mvo> pedronis: we have the same problem with the unit, there is also a test || write in there which might race
[15:33] <mvo> pedronis: I look into it, thanks!
[15:34] <pedronis> np
[15:34] <cachio> niemeyer, hey, I need to save the images we use for beta/edge validation
[15:34]  * pedronis break
[15:34] <mvo> pedronis: on a meta level (not urgent) we need some suggestion which of the approaches we should take to fix the actual bug. zyga and I are not of the same opinion about what approach is the one to pick :)
[15:34] <mvo> pedronis: enjoy your break, not urgent
[15:34] <cachio> niemeyer, do you think we can store them in the gcloud filestorage?
[15:35] <cachio> niemeyer, we are not gonna use more than 5GB
[15:41] <micah> hi, i need to symlink /snap to /rw/snap on my system, but if I do that, then the core mount job fails because of: snap-core-5742.mount: Mount path /snap/core/5742 is not canonical (contains a symlink) -- is there some way I can override that?
[15:41]  * cachio lunch
[15:45] <micah> starting with systemd 238, mount units will fail if the mount point needs to follow a symbolic link
[15:49] <ppisati> ogra: for the wifi issue you were mentioning some time ago, could you test this kernel snap? -> https://code.launchpad.net/~p-pisati/+snap/raspi2-test/+build/377679/+files/pi2-kernel_4.4.0-1101.109_armhf.snap
[15:50] <ogra> ppisati, will do
[15:56] <pedronis> mvo: what are main zyga objections about?  the duplication, the fact that is new unproven code, the fact that is on the plug side?
[16:12] <zyga> That it feels like layering violation. No other interface code modified the system
[16:12] <pedronis> zyga: modified in which sense?
[16:13] <zyga> That it feels like layering violation. No other interface code modified the system
[16:13] <pedronis> ?
[16:14] <pedronis> zyga: modify in which sense? they all touch files on the system? and for sure the systemd code is creating a unit that modifies the system?
[16:14] <zyga> Writing to sysfs
[16:15] <zyga> Exporting GPIO from the kernel to userspace in a method that computes apparmor snippet
[16:15] <pedronis> ok, that's clearer
[16:16] <zyga> Systems unit is just defined
[16:16] <zyga> Not on disk
[16:16] <zyga> All changes are done by backend
[16:16] <mup> PR snapd#6139 closed: snap, store, overlord/snapshotstate: drop epoch pointers <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6139>
[16:17] <zyga> Systemd specification holds units in memory
[16:17] <pedronis> zyga: I understood
[16:17] <mup> PR snapd#6142 opened: overlord/snapstate, store: always send epochs <Created by chipaca> <https://github.com/snapcore/snapd/pull/6142>
[16:34] <pedronis> zyga: mvo: at the moment all considered #6128 seems my favorite fix, but it depends whether we think we need this also for 2.36.x
[16:35] <mup> PR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <https://github.com/snapcore/snapd/pull/6128>
[16:38] <zyga> pedronis: that's fine though this implementation has slightly bigger impact than the first one I pushed (with the special casing of systemd backend)
[16:38] <zyga> pedronis: after a QA pass I don't mind landing that at all
[16:40] <pedronis> zyga: that's why I said it depends whether we need something to backport
[16:40] <pedronis> zyga: anyway I think mvo is offline changing location
[16:40] <pedronis> atm
[16:40] <zyga> ack
[16:40] <zyga> I'll get onto other things
[16:41] <zyga> I'm happy to discuss this when needed
[16:48] <pedronis> zyga: what are you working on atm?  back to user namespaces?
[16:48] <zyga> yes
[16:48] <pedronis> ok, thanks
[16:48] <zyga> I will do some reviews of pawel's work as well
[16:52] <pstolowski> zyga: ty!
[17:39] <Chipaca> error: cannot install snap file: cannot refresh snap "basic" as new epoch (2) can't read old epoch (0)
[17:39] <Chipaca> looks like it might work
[17:40] <roadmr> epochs ftwwwww
[17:41] <Chipaca> that's from a local install
[17:42] <pedronis> roadmr: yes, Chipaca is progressing on them
[17:42] <roadmr> yya :)
[17:43] <zyga> Chipaca: _neat_
[17:43] <zyga> snaps get serious 🙂
[17:54]  * Chipaca mostly EODs
[17:57] <Chipaca> a little early because the chorizo + split lentil stew smell is distracting me too much
[18:49] <zyga> o/
[18:59]  * cachio afk
[19:33] <mvo> zyga: you had a chat about gpio? can you point me to a pastebin or give me a tl;dr summary?
[19:34] <zyga> with Samuele?
[19:34] <mvo> zyga: yes
[19:34] <mvo> zyga: i.e. should I stop messing around with 6141 ?
[19:34] <zyga> I only said what my objections are
[19:35] <pedronis> I wrote this: <pedronis> zyga: mvo: at the moment all considered #6128 seems my favorite fix, but it depends whether we think we need this also for 2.36.x
 PR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <https://github.com/snapcore/snapd/pull/6128>
 pedronis: that's fine though this implementation has slightly bigger impact than the first one I pushed (with the special casing of systemd backend)
 pedronis: after a QA pass I don't mind landing that at all
[19:35] <mup> PR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <https://github.com/snapcore/snapd/pull/6128>
 zyga: that's why I said it depends whether we need something to backport
 zyga: anyway I think mvo is offline changing location
[19:35] <zyga> we did not discuss more than that
[19:35] <pedronis> we can chat more in the morning, but we do need to try to converge, and also decide about 2.36.x
[19:36] <zyga> I agree
[19:38] <mvo> zyga: ok, thanks
[19:39] <mvo> pedronis: thank you as well
[19:39] <mvo> it looks like they all need reviews anyway, so lets sync up in the morning
[19:54] <mvo> ackk: core18 with the ld-so symlink fix is in edge now, please let me know if you it is not sufficient
[21:01] <jdstrand> roadmr: hi! whenever its convenient, can you pull 1155 of the review-tools?
[21:01] <mup> PR #1155: integration-tests: remove the integration daemon tests <Created by elopio> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1155>
[21:01] <roadmr> jdstrand: sure thing!
[21:02] <jdstrand> roadmr: thanks
[21:03] <Caelum> zyga: thank you so much for finally doing the snapd update, to be honest I've been using flatpak spotify in the meantime
[21:05] <Caelum> zyga: if you ever want help with anything, just ping me
[21:47] <mup> PR snapcraft#2404 opened: cli: handle yaml errors for cleanbuild <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2404>
[23:25] <mup> PR snapd#6143 opened: cmd: install snap-discard-ns in "make hack" <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6143>
[23:28] <mup> PR snapd#6144 opened: cmd: handle tumbleweed and leap in autogen.sh <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6144>
[23:29] <ijohnson> zyga: sorry I forgot but I just filed https://bugs.launchpad.net/snapd/+bug/1803210 for you to look at
[23:29] <mup> PR snapd#6145 opened: cmd/snap-confine: capture initialized per-user mount ns <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>
[23:30] <mup> Bug #1803210: snap's device cgroup is not discarded upon uninstall <snapd:New> <https://launchpad.net/bugs/1803210>
[23:30] <ijohnson> no rush it's a low priority