[05:14] <zyga> good morning
[05:30] <jamesh> zyga: I ran into a weird bug when mixing the content interface with layouts: https://bugs.launchpad.net/snapd/+bug/1831010
[05:30] <mup> Bug #1831010: Snapd fails to upgrade package that uses layouts to remap a content plug mount <snapd:New> <https://launchpad.net/bugs/1831010>
[05:30] <jamesh> with the mount namespace in place, I can't upgrade the package
[05:31] <zyga> Hey
[05:31] <mborzecki> morning
[05:31] <zyga> jamesh: can you please try with ...
[05:32] <zyga> https://github.com/snapcore/snapd/pull/6891
[05:32] <mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
[05:35] <jamesh> I'll give it a go.
[05:35] <zyga> Thanks!
[05:36] <zyga> I’ll be in the office soon
[05:48] <zyga> back now
[05:48] <zyga> jamesh: so, I'm not sure that branch will help
[05:48] <zyga> jamesh: but surprisingly it did help with another test that documented a bug
[05:48] <zyga> jamesh: I'm not 100% sure when the kenels returns EBUSY on mount ops, perhaps it was due to the fact than an app was running?
[05:48] <jamesh> zyga: I haven't tested it yet, but it wasn't obvious it would
[05:49] <zyga> jamesh: if this is a blocker for you I can take the bug report and jump into the kernel to see what is really going on
[05:49] <jamesh> zyga: my guess is that it is trying to unmount the layout mount without first doing the submounts
[05:49] <zyga> jamesh: but we almost always do that, it never complains
[05:50] <zyga> jamesh: we always MS_DETACH (aka --lazy) so that should work
[05:50] <zyga> jamesh: I think there is something else that must be at play
[05:50] <zyga> jamesh: I know you are busy with lots of stuff and that we owe you a ton of reviews but if you could also review https://github.com/snapcore/snapd/pull/6891 I would love to get some feedback -- it's a tricky PR that involves user mount namespaces
[05:51] <mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
[05:52] <mup> PR snapd#6934 opened: tests: fix repack_snapd_snap_with_deb_content <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6934>
[05:52] <zyga> mborzecki: I cherry picked a bugfix from mvo so that it can land faster ^
[05:53] <mborzecki> zyga: ah, that one
[06:01] <mborzecki> zyga: any ideas about sid here? https://github.com/snapcore/snapd/pull/6927#partial-pull-merging if that's something in the distro, i'd expect master to fail too
[06:01] <mup> PR #6927: release: 2.39.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6927>
[06:01] <jamesh> zyga: I simplified things a bit to reduce the number of mounts (i.e. not using gtk-common-themes), and was able to reproduce the problem: https://bugs.launchpad.net/snapd/+bug/1831010/comments/2
[06:01] <mup> Bug #1831010: Snapd fails to upgrade package that uses layouts to remap a content plug mount <snapd:New> <https://launchpad.net/bugs/1831010>
[06:02] <zyga> jamesh: thanks!
[06:02] <jamesh> zyga: I think it is the last duplicated mount not present in the snapd fstab that is confusing things
[06:02] <zyga> curious
[06:02] <zyga> thanks!
[06:03] <zyga> jamesh: it might be this bug https://bugs.launchpad.net/snapd/+bug/1828357
[06:03] <mup> Bug #1828357: snap-update-ns incorrectly sorts mount profile entries <snapd:New for zyga> <https://launchpad.net/bugs/1828357>
[06:03] <zyga> but then again, maybe not, I'll check
[06:03] <zyga> mborzecki: looking
[06:04] <zyga> mborzecki: do you mean:
[06:04] <zyga> dpkg-source: error: can't build with source format '3.0 (quilt)': non-native package version does not contain a revision
[06:04] <zyga> dpkg-source: info: using options from snapd/debian/source/options: --include-removal
[06:04] <zyga> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 255
[06:04] <mborzecki> zyga: yup
[06:04] <zyga> feels like new debian feature
[06:05] <mborzecki> zyga: right, but why it doesn't fail on master
[06:05] <zyga> ah, good question :)
[06:05] <zyga> dunno
[06:06] <mborzecki> zyga: btw. are you off today?
[06:06] <zyga> mborzecki: no no :)
[06:06] <zyga> today I will be busy
[06:43] <mup> PR snapd#6934 closed: tests: fix repack_snapd_snap_with_deb_content <Bug> <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6934>
[06:58] <pstolowski> mornings
[06:59] <marcustomlinson> morning :)
[07:25] <mborzecki> pstolowski: hey
[07:25] <pstolowski> hey marcustomlinson and mborzecki!
[08:58] <mup> PR snapd#6935 opened: cmd/snap: support snap debug timings --startup=.. and measure loadState time <Created by stolowski> <https://github.com/snapcore/snapd/pull/6935>
[09:00] <cjwatson> zyga: unlikely to be new - that error was first added in dpkg commit acc1f37933 in 2013 (with slightly different text at that point)
[09:07] <cjwatson> zyga,mborzecki: It's a bug in the PR - top line of packaging/debian-sid/changelog should say 2.39.1-1 rather than 2.39.1 (compare with the following changelog stanza in that same file)
[09:07] <mborzecki> cjwatson: thanks!
[09:08] <cjwatson> np, took me a little while to spot it
[09:10] <mborzecki> zyga: that means the changelog in release/2.39 branch is busted too
[09:10] <mborzecki> zyga: the one for sid
[09:15] <mborzecki> zyga: well, the travis job on the branch failed :P
[09:17] <mup> PR snapd#6936 opened: packaging/debian-sid: fix changelog, add revision <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6936>
[09:19] <mborzecki> zyga: pstolowski: ^^
[10:11] <mup> PR snapd#6855 closed: overlord: implement store switch remodeling  <Remodel :train:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6855>
[10:17] <zyga> re; sorry for missing half of today, I was baby-sitting upstairs due to unexpected errand for my wife; I'll handle paperwork for half day off
[10:17] <zyga> back to work now
[10:18] <zyga> cjwatson: thanks for the analysis, I totally missed that
[10:18] <zyga> jamesh: hey, any luck with the extra patch?
[10:24] <jamesh> zyga: sorry.  Got side tracked before setting up a test system.
[10:24] <zyga> no worries
[10:24] <zyga> I'll see if I can debug that today
[10:24] <jamesh> zyga: I suspect it won't make a difference: https://paste.ubuntu.com/p/GV4bQW8XKy/
[10:24] <jamesh> zyga: I did manage to simplify the test snap down to only using layouts, so it is self contained
[10:24] <zyga> wow
[10:24] <zyga> jamesh: what's the kernel version?
[10:25] <jamesh> zyga: this was on an 18.10 box with 4.18.0-15-generic
[10:26] <jamesh> I'll grab my other system to see if the same happens with 19.04
[10:28] <zyga> pstolowski: hey
[10:28] <zyga> pstolowski: do you have a moment for a quick HO?
[10:29] <jamesh> zyga: same result on 5.0.0-11-generic
[10:29] <pstolowski> zyga: hey, sure
[10:29] <jamesh> (that system needs a reboot)
[10:31] <jamesh> zyga: https://launchpadlibrarian.net/425983579/snapcraft.yaml <-  that's the simpler version exhibiting the bug
[10:53] <zyga> pstolowski: pushed to https://github.com/snapcore/snapd/pull/6932
[10:53] <mup> PR #6932: tests: run unit tests without networking <Created by zyga> <https://github.com/snapcore/snapd/pull/6932>
[10:55] <mup> PR snapcraft#2575 closed: catkin spread tests: use kinetic instead of indigo <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2575>
[10:56] <pstolowski> zyga: thanks
[11:00] <mborzecki> journald on opensuse is acting up, i've restarted a spread run that failed on opensuse again and again the log the test is looking for isn't there
[11:31] <mborzecki> zyga: conflicts in #6932
[11:31] <mup> PR #6932: tests: run unit tests without networking <Created by zyga> <https://github.com/snapcore/snapd/pull/6932>
[11:32] <zyga> mborzecki: aha
[11:33]  * Chipaca wanders off in search of sustenance
[11:34]  * zyga hands Chipaca a copy of the GNU manifesto ;)
[11:34]  * Chipaca is suspicious
[11:35] <zyga> Chipaca: to start the fire ;D
[11:36]  * Chipaca puts on his FSFLA tee and scowls
[11:37] <zyga> mborzecki: resolved
[11:42] <mup> PR snapd#6936 closed: packaging/debian-sid: fix changelog, add revision <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6936>
[11:43] <mborzecki> pushed the changelog fix to #6927
[11:43] <mup> PR #6927: release: 2.39.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6927>
[11:48] <zyga> more unit test failures... https://www.irccloud.com/pastebin/uqQwKN1R/
[11:49] <zyga> that is curious...
[11:58] <zyga> pstolowski: heh, that test fails *again*
[11:58] <zyga> debugging
[11:58] <zyga> but apparently the unshare -n trick is not enough
[11:58] <zyga> man, that's fum
[11:58] <cachio> mborzecki, hey
[11:59] <cachio> mborzecki, there is an issue on i386, it is going out of memory
[11:59] <cachio> mborzecki, https://paste.ubuntu.com/p/xbqvTQSp6Y/
[11:59] <pstolowski> zyga: fails again after your fix?
[11:59] <cachio> yesterday I was researching about it wit mvo
[12:00] <zyga> pstolowski: it passes in unshare -n tests, fails in "osc build"
[12:00] <cachio> mborzecki, but then I spent time doing tests and could reproduce it on beta and candidate
[12:01] <mborzecki> zyga: maybe loopback is down there after all?
[12:02] <zyga> mborzecki: no, that causes lots of tests to fail
[12:02] <zyga> mborzecki: I'd like to get "osc shell" or something like that to play
[12:02] <zyga> let's see
[12:04] <mborzecki> cachio: hm looks like something failed while loading apparmor profiles?
[12:04] <cachio> mborzecki, yes
[12:04] <cachio> apparmor_parser: Unable to replace "snap.test-snapd-tools.fail".  Out of memory
[12:05] <cachio> mborzecki,  kernel: vmalloc: allocation failure: 68497 bytes
[12:06] <cachio> I tested that with kernel on stable and works well
[12:06] <cachio> but kernel on candidate and beta are failing at some point
[12:11] <zyga> cachio: can you look at aa-status?
[12:12] <cachio> zyga, https://paste.ubuntu.com/p/RBPTNpXz4Z/
[12:14] <zyga> cachio: perhaps after running each test we should remove loaded apparmor profiles
[12:15] <cachio> zyga, I could try that
[12:15] <cachio> zyga, it is weird becuase it doesn't fail with pc-kernel=stable
[12:15] <zyga> cachio: and this is with which kernel?
[12:16] <cachio> this is with kernel on beta or candidate
[12:16] <cachio> works well with kernel on stable
[12:16] <zyga> cachio: do we know what is the difference between those?
[12:16] <cachio> zyga, no
[12:16] <cachio> I left tests running
[12:16] <zyga> cachio: perhaps we can ask the kernel team for a summary?
[12:16] <zyga> pstolowski: so ...
[12:16] <cachio> and I just got the results
[12:17] <zyga> failure in osc build, with extra debugging https://www.irccloud.com/pastebin/xy59XKOr/
[12:17] <zyga> cachio: +1
[12:17] <jdstrand> cachio: curious, have you seen https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502? jjohansen is looking at that
[12:17] <mup> Bug #1830502: apparmor uses excessive memory leading to oom kill <apparmor (Ubuntu):New> <https://launchpad.net/bugs/1830502>
[12:18] <cachio> jdstrand, nice
[12:18] <cachio> jdstrand, that could explains that
[12:19] <mborzecki> zyga: hmmm that error, looks like temporary/permanent/retryable mess again
[12:19] <zyga> mborzecki: yeah, we just worked on that with pstolowski
[12:19] <jdstrand> cachio: it may or it may not, but there are debugging details that jjohansen laid out that might be helpful
[12:19] <zyga> !!! https://launchpadlibrarian.net/425906431/snapcraft.yaml
[12:19] <zyga> jdstrand: that's one long layout
[12:20] <zyga> mborzecki: this is supposed to run with this applied https://github.com/snapcore/snapd/pull/6932/commits/c3b1296f1124158fd7e0987e9bd0196b20b3634d
[12:20] <mup> PR #6932: tests: run unit tests without networking <Created by zyga> <https://github.com/snapcore/snapd/pull/6932>
[12:20] <jdstrand> zyga: heh, yes. I think I'm going to put something in the review-tools for an abusive use of layouts. I'm not sure what that number should be, but clearly it is less than what is in that yaml :)
[12:20] <cachio> jdstrand, sure
[12:20] <zyga> jdstrand: at most a dozen
[12:20] <zyga> we can expand if we have to
[12:21] <mborzecki> zyga: well, so now it connection refused? :)
[12:21] <jdstrand> ack
[12:21] <zyga> mborzecki: yeah
[12:21] <zyga> different error
[12:21] <pstolowski> uhm
[12:23] <zyga> pstolowski: ah, I see what the bug is now
[12:23] <zyga> https://www.irccloud.com/pastebin/62CfKEFd/
[12:29] <pstolowski> zyga: uhmmm.. horror continues
[12:29] <zyga> yeahj
[12:29] <zyga> fixed locally, let's see
[12:29] <zyga> I'll push that to the offline tests PR
[12:29] <mborzecki> idk maybe our approach is wrong
[12:30] <zyga> mborzecki: perhaps
[12:30] <zyga> mborzecki: we'd have to get some data about how the errors look like
[12:30] <zyga> put that into a table
[12:30] <zyga> then train an AI against someone saying if this is good or bad
[12:30] <zyga> and then if you have a CUDA card we'd retry correctly ;)
[12:30] <zyga> pstolowski: tests passed!
[12:30] <pstolowski> \o/
[12:31] <mborzecki> cachio: did you get a chance to look into updating opensuse to 15.1?
[12:32] <cachio> mborzecki, no, but I can do it today
[12:32] <zyga> mborzecki: but in all seriousness, I think we could be better if we had a good data set and wrote proper algorithm
[12:32] <mborzecki> cachio: 15.1 is out, hope they published the images too
[12:33] <cachio> mborzecki, nice, I'll check that and create the image if it is available
[12:33] <cachio> mborzecki, thanks for hte heads up
[12:33] <zyga> https://build.opensuse.org/project/show/system:snappy
[12:33] <zyga> darn OSC is *insanely quick*
[12:33] <zyga> I wrote "osc commit"
[12:33] <zyga> moved to another display
[12:33] <zyga> reloaded a tab
[12:33] <zyga> and it's building already
[12:35] <zyga> mborzecki, cachio: FYI, I'm discontinuing builds for openSUSE Leap 42.2 and 42.3 as they don't provide golang-go >= 1.9
[12:35] <cachio> zyga, ok, so I'll clean up them when I create the PR for opensuse 15.1
[12:36] <zyga> thanks
[12:36] <cachio> zyga, thanks to you
[12:37] <zyga> build complete
[12:38] <mborzecki> zyga: sounds fair
[12:40]  * zyga looks at mount bug from jamesh now
[12:58] <mup> PR snapd#6931 closed: tests: force removal to prevent restore fails when directory doesn't exist on lp-1801955 test <Simple 😃> <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6931>
[13:00] <jdstrand> cachio: hey, mvo is out and not sure if you need it, but I saw core20 float into the store queue and I've approved it, but it needs to be released to a channel
[13:00] <jdstrand> zyga: perhaps you're interested in ^
[13:00] <zyga> jdstrand: thanks
[13:00] <zyga> jdstrand: I think we want it in edge only, we'll discuss that
[13:01] <jdstrand> I figured and would've put it there, but didn't have the perms
[13:27] <zyga> eh, btrfs corrputed
[13:27] <roadmr> haha, rancid butter :)
[13:30] <mborzecki> zyga: clearly production ready fs
[13:30] <mborzecki> zyga: can you restore from a snapshot at least or sth?
[13:31] <zyga> yeah, managed to mount a ro copy
[13:31] <zyga> I'll just add a HDD, reformat and move over
[13:31] <zyga> using ext4 was my best tumbleweed choice
[13:31] <zyga> btrfs is cool but no thanks :/
[13:37] <zyga> rsyncing...
[14:18] <roadmr> jdstrand: 20190528-2014UTC click-reviewers-tools version  now in production 💪
[14:18] <roadmr> (nothing broke after the big rename-refactor)
[14:18] <jdstrand> TooLmaN: exciting! :)
[14:18] <jdstrand> yikes
[14:18] <jdstrand> TooLmaN: sorry, nm :)
[14:18] <jdstrand> roadmr: exciting! :)
[14:18] <jdstrand> (tab fail)
[14:18] <roadmr> if you want to get rid of the click-review symlink, I can change the command we invoke
[14:18] <roadmr> jdstrand: hehe yes tabs can be tricky
[14:19] <jdstrand> roadmr: it helps if I type the first letter correctly :)
[14:19] <roadmr> hehe a clear case of autocowreck
[14:19] <jdstrand> roadmr: I would like to get rid of the click-review symlink, but it is far from urgent. maybe let's sit on 20190528-2014UTC for a little while and then revisit?
[14:22] <roadmr> jdstrand: sure thing; yes, I think I can change the executable name on my side and if things look stable in a few weeks we can kill the symlink
[14:24] <jdstrand> roadmr: sounds like a plan
[14:27] <zyga> mborzecki: wanna see something curious
[14:27] <mborzecki> zyga: hm?
[14:30] <cachio> zyga, mborzecki opensuse-15.1 nor available on glcoud yes
[14:30] <cachio> yet
[14:30] <cachio> I'll see if I could upgrade from 15.0
[14:30] <cachio> and start using that
[14:32] <zyga> mborzecki: https://bugs.launchpad.net/snapd/+bug/1831010
[14:32] <mup> Bug #1831010: Snapd fails to upgrade package that uses layouts to bind mount parent directory of another mount point <snapd:New for zyga> <https://launchpad.net/bugs/1831010>
[14:32] <zyga> mborzecki: last two comments
[14:33] <zyga> this seems to show that our assumptions that we can detach anything are wrong
[14:33] <zyga> if we need to investigate detach algorithms that untangle mounts then it will be a fun thing to fix
[14:37] <zyga> cachio: can you ask some suse people about this?
[14:37] <zyga> cachio: I found this https://build.opensuse.org/package/show/Cloud:Images:Leap_15.1/openSUSE-Leap-15.1-GCE-Guest
[14:38] <zyga> cachio: https://download.opensuse.org/repositories/Cloud:/Images:/Leap_15.1/images/
[14:38] <zyga> there are images here
[14:38] <zyga> can you please try those?
[14:40] <mborzecki> zyga: at least it's reproducible here too
[14:42] <zyga> mborzecki: some ideas here
[14:42] <zyga> mborzecki: we can construct an in memory tree from mountinfo mount-id / parend-id pairs
[14:42] <zyga> and then walk that
[14:43] <zyga> to unmount leaves before inner nodes
[14:43] <zyga> I'm still puzzled by propagation of detach mounts
[14:43] <zyga> perhaps what is really breaking is the propagation of the unmount conflicting with itself?
[15:44] <tim-jone_> nmcli critical error trying to enable wifi interface on ubuntu core (18.04.2) on raspberry pi
[15:44] <tim-jone_> sudo network-manager.nmcli r wifi on gives error: (process:3062): nmcli-CRITICAL **: Error: Could not create NMClient object: Could not connect: Permission denied.
[15:45] <tim-jone_> can anyone suggest what I might do to get wifi working with ubuntu core on a raspberry pi
[15:53] <Chipaca> tim-jone_: i thought that was handled via netplan
[15:53] <Chipaca> tim-jone_: but i'm not too certain
[15:53] <Chipaca> ogra: help?
[15:53] <tim-jone_> following instructions here: https://gist.github.com/cyan198/6ecdb86267498a51587b4337e47e10f6
[15:54] <Chipaca> tim-jone_: one thing I see you do that I don't see in that gist is 'sudo'
[15:55] <cyphermox> tim-jone_: maybe just skip that first part; it might not be disabled at all
[15:55] <tim-jone_> have been using sudo
[15:55] <cyphermox> Chipaca: his pasted command did include sudo
[15:55] <Chipaca> cyphermox: exactly
[15:55] <Chipaca> the gist does not use sudo
[15:55] <tim-jone_> yes that error is with sudo
[15:55] <Chipaca> tim-jone_: and what happens without sudo?
[15:56] <tim-jone_> same error
[15:56] <cyphermox> I think you just want to move on to 'network-manager.nmcli d wifi list'
[15:56] <Chipaca> tim-jone_: what's the output of 'snap connections network-manager'?
[15:57] <tim-jone_> Interface              Plug                                   Slot                     Notes
[15:57] <tim-jone_> dbus                   network-manager:wpa                    -                        -
[15:57] <tim-jone_> firewall-control       network-manager:firewall-control       :firewall-control        -
[15:57] <tim-jone_> modem-manager          network-manager:modem-manager          :modem-manager           -
[15:57] <tim-jone_> network                network-manager:network                :network                 -
[15:57] <tim-jone_> network-manager        -                                      network-manager:service  -
[15:57] <tim-jone_> network-manager        network-manager:nmcli                  -                        -
[15:57] <tim-jone_> network-setup-observe  network-manager:network-setup-observe  :network-setup-observe   -
[15:57] <tim-jone_> ppp                    network-manager:ppp                    :ppp                     -
[15:57] <tim-jone_> (is there a better way to paste output or should I use a pastebin link or similar in IRC?)
[15:57] <Chipaca> tim-jone_: paste.ubuntu.com ftw
[15:58] <Chipaca> tim-jone_: do all nmcli commands end with the same error?
[15:59] <tim-jone_> cyohermox network-manager.nmcli d wifi list gives the same error (with or without sudo)
[15:59] <cyphermox> mmkay
[15:59] <cyphermox> so some kind of real permission issue; Chipaca will def know more about it than me if it has to do with the connections
[15:59] <Chipaca> tim-jone_: can you pastebin 'snap logs network-manager'?
[16:00] <tim-jone_> sudo network-manager.nmcli gives version OK, but try any objects (radio etc) it fails
[16:01] <Chipaca> yeah, there's something wrong permissions-wise, but the connections seem a'ight -- which, unless i'm missing something, means there's a bug in the snap
[16:01] <tim-jone_> output of snap log network manager : https://paste.ubuntu.com/p/QPwwTx68gv/\
[16:01] <Chipaca> but that's snap in rather prominent use so somehting's up
[16:01] <Chipaca> tim-jone_: that seems ok
[16:02] <Chipaca> tim-jone_: it seems ogra is away, could you open a topic in forum.snapcraft.io (in the 'devices' category)?
[16:02] <Chipaca> sorry, 'device'
[16:04] <tim-jone_> OK - will do - but reading the log I pasted I see that despite network manager not working the wlan0 interface is listed via ifconfig which it was not before
[16:15] <tim-jone_> @Chipaca: have opened a topic in device category as you suggested :-)
[16:34] <Chipaca> woo, my pr is green, time to take a break
[16:37] <ogra> Chipaca, what makes you think i know how to use NM on core ? ... none of my images ever used it ;)
[16:37]  * ogra just uses a proper netplan.yaml and the network-setup-control interface from a configuration snap
[16:45] <tim-jone_> ogra: is this gist wrong then? : https://gist.github.com/cyan198/6ecdb86267498a51587b4337e47e10f6 (pity its the first hit on google if so)
[16:46] <tim-jone_> BTW did configure /etc/netplan/50-cloud-init.yaml manually and the wifi interface is up and running
[16:46] <tim-jone_> is there some other documentation I should be reading?
[16:55] <jjohansen> cachio, jdstrand, zyga: that is a different bug
[17:15] <cachio> jjohansen, thanks
[17:16] <cachio> zyga, , I could reproduce the error using the core from stable and the kernel from beta
[17:54] <cmatsuoka> what is a common cause for "Reported install problem for xxx" in handlers?
[17:55] <mup> PR snapd#6927 closed: release: 2.39.1 <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6927>
[17:55] <zyga> jjohansen: thank you for confirming that
[17:55] <cmatsuoka> May 30 12:39:53 localhost snapd[702]: handlers.go:414: Reported install problem for "snapd" as 05c989c0-82d8-11e9-9fdc-fa163e6cac46 OOPSID
[17:56] <Chipaca> ogra: I just assume you know everything
[17:57]  * Chipaca vanishes in a cloud of EOD
[18:04] <mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
[18:05] <mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
[18:24] <mup> PR snapcraft#2578 opened: keyrings: update ROS signing key <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2578>
[20:43] <Odd_Bloke> Hey folks, how can I remove a snap without wasting time on snapshots?
[20:44] <Odd_Bloke> (I'm removing it because all the (ephemeral) data ended up corrupted; I really don't want a snapshot.)
[20:45] <ijohnson> there either is or will be a --purge option to snap remove
[20:45] <ijohnson> not sure if that has landed or not
[20:45] <Odd_Bloke> There isn't where I am, unfortunately.
[20:46] <Odd_Bloke> And it looks like because I've started the remove operation, I'm stuck with the snapshotting regardless.
[20:46] <ijohnson> you might try refreshing to the edge channel of the core snap
[20:46] <ijohnson> if you use `snap changes` you can see what id of the remove task is, and then abort that task with `snap abort $id`
[20:48] <Odd_Bloke> Aha, that got me to the point where I could run `snap set system snapshots.automatic.retention=no` before removing again.
[20:48] <Odd_Bloke> Thanks for the help, ijohnson!
[20:48] <ijohnson> also fwiw the --purge option is at least in the edge channel too
[20:48] <ijohnson> glad to help
[21:36] <mup> PR snapd#6937 opened: cmd/snap-update-ns: detach unused mount points <Created by zyga> <https://github.com/snapcore/snapd/pull/6937>
[21:37] <zyga> jdstrand: ^
[21:37] <zyga> jamesh: ^
[21:37] <zyga> running final spread locally before opening
[21:40]  * zyga EODs