=== benfrancis2 is now known as benfrancis
=== not_phunyguy is now known as phunyguy
[04:26] <mup> Bug #1916816 changed: File picker and other native windows have garbled fonts in Arch & Manjaro <fonts> <Snappy:Expired> <https://launchpad.net/bugs/1916816>
[04:26] <mup> Bug #1935054 changed: Unable to connect to Core20 server from outside my VLAN <Snappy:Expired> <https://launchpad.net/bugs/1935054>
[06:01] <mborzecki> morning
[06:07] <mardy> 'morning mborzecki 
[06:08] <mborzecki> mardy: heya
[07:01] <pstolowski> morning
[07:03] <zyga-mbp> good morning :)
[08:35] <mup> PR snapd#10905 closed: gadget, osutil/disks: fix some bugs from prior PR's <Simple 😃> <Needs Samuele review> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/10905>
[08:35] <mup> PR snapd#10916 closed: osutil/disks: fix bug in BlkIDEncodeLabel, add BlkIDDecodeLabel <Simple 😃> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/10916>
[08:40] <mup> PR snapd#10876 closed:  o/devicestate, o/servicestate: update gadget assets and cmdline when remodeling <Remodel 🚋> <Run nested> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/10876>
[08:40] <mup> PR snapd#10925 closed: tests/nested/manual/refresh-revert-fundamentals: re-enable encryption  <Simple 😃> <Run nested> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/10925>
[08:40] <mup> PR snapd#10941 opened: tests: simplify mock script for apparmor_parser <Simple 😃> <Skip spread> <Created by mardy> <https://github.com/snapcore/snapd/pull/10941>
[09:21] <mup> PR snapd#10942 opened: cmd/snap-confine: die when snap process is outside of snap specific cgroup (2.53) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10942>
[09:31] <mup> PR snapd#10943 opened: o/snapstate: tweak error, add unit tests for remodel helpers <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10943>
[10:13] <dust> neither eclipse nor tiled does work in ubuntu 21.10
[10:17] <pstolowski> dust: if this is about snaps for those apps, then best to raise this on the forum
[10:33] <dust> pstolowski, ofc its about the snap of this programs... otherwise i wouldnt write it here... no account there so i posted here...
[11:21] <ogra> dust, well, the maintainers of these snaps are most likely not in this channel ... but there are chances they read the forum (or others that read the forum are able to help because they had similare issues before)
[11:23] <mborzecki> hmmm so we seem to be doing something wrong in our tests
[11:24] <mborzecki> sometimes we have a pattern when we have a list of test cases and run a test for this, usually a for{} loop, but we often set up some mocks and call defer restore()
[11:24] <mborzecki> so those restores won't run until the function exists
[11:27] <pstolowski> mborzecki: oh that's wrong. i might have done such mistake in my early days of Go programming ;/
[11:27] <mborzecki> i'm trying to untangle such code in our secboot wrapper tests
[11:29] <pstolowski> mborzecki: sometimes it's hard to do right and best option is to have a test function that takes the parameters, and make separate instances of all tests cases
[11:46] <mup> PR snapd#10941 closed: tests: simplify mock script for apparmor_parser <Simple 😃> <Skip spread> <Created by mardy> <Merged by mardy> <https://github.com/snapcore/snapd/pull/10941>
[11:46] <mup> PR snapd#10944 opened: [RFC] o/snapstate: maintain a stack of enforced validation sets per snap revision <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10944>
[12:06] <mardy> I need some help in understanding what happened here: https://paste.ubuntu.com/p/r7nyM4krH4/
[12:06] <mardy> the context is https://github.com/snapcore/snapd/pull/10935
[12:06] <mup> PR #10935: tests: wait for snapd to be fully setup before installing snaps <Created by mardy> <https://github.com/snapcore/snapd/pull/10935>
[12:07] <mardy> I don't understand why /dev/loop8 timed out; who should create the systemd unit for it? How to investigate why it timed out?
[12:07] <mborzecki> mardy: i think systemd creates it these days, before it was done by mount
[12:09] <mborzecki> mardy: anyways, iirc the protocol was that you first create a loopback device, and then race against other requests associate it with a file descriptor of an open file
[12:10] <mborzecki> i think we should cherry-pick fixes for snapd-sigterm to 2.53, i the test failing on some systems in my PR
[12:10] <mardy> mborzecki: do you know how snapd does it? I see that the tests are using losetup, but I don't see it used in snapd source code
[12:10] <mborzecki> mardy: snapd does what?
[12:11] <mardy> mborzecki: allocate a loop device
[12:11] <mborzecki> mardy: we just ask ssytemd to start the mount unit, and it figures it out that a loop device is needed, associates the file and so on
[12:11] <mardy> oh, I didn't know that systemd did this magic
[12:12] <mborzecki> mardy: or `mount` (the command)
[12:13] <mardy> systemd timed out after 30 seconds, trying to allocate the loop device. Which doesn't sound very reasonable, given that it should be rather immediate
[12:13] <mborzecki> mardy: there's one occasion where we call mount directly, and it's in sanity/squashfs.go to check whether the host supports mounting squashfs at all
[12:15] <pstolowski> miguelpires: is https://bugs.launchpad.net/snappy/+bug/1939218 the bug you mentioned you looked at the other day?
[12:15] <mup> Bug #1939218: snapd startup crash after install of standalone microk8s <Snappy:New> <https://launchpad.net/bugs/1939218>
[12:16] <mardy> mborzecki: thanks, but at a first sight it doesn't look like this code path is relevant. So it must be systemd...
[12:18] <miguelpires> pstolowski: no, it was https://bugs.launchpad.net/snapd/+bug/1946996
[12:18] <mup> Bug #1946996: snapd: slice bounds out of range <snapd:Incomplete> <https://launchpad.net/bugs/1946996>
[12:20] <mardy> mborzecki: looking at the logs in https://paste.ubuntu.com/p/r7nyM4krH4/, do you understand why the test-snapd-svc-flip-flop mount unit was umounted right when starting the snap's service (line 50 of the log)?
[12:21] <miguelpires> But looking at that one, they're definitely about the same issue. That one has some new info, I'll try to reproduce it. Thanks!
[12:21] <pstolowski> miguelpires: snapstate.undoLinkSnap in both bug reports, and microk8s
[12:26] <mborzecki> mardy: maybe it's the test, it intercepts systemctl command
[12:26] <mborzecki> bind mounts a mock on top
[12:27] <mardy> mborzecki: no, the failure happens before that change, it happens when installing the snap, on the "snap install --dangerous app.snap" line
[12:27] <mardy> mborzecki: I do not see the umount happening when the snap installs successfully
[12:30] <pstolowski> miguelpires: i marked one of them as duplicate of the other. i can poke around at this as well for a bit
[12:42] <mup> Bug #1939218 changed: snapd startup crash after install of standalone microk8s <snapd:Triaged> <https://launchpad.net/bugs/1939218>
[12:44] <pstolowski> miguelpires: i cannot reproduce that issue with snapd 2.51.3 and this microk8s snap... maybe it depends on what configure hook has to do on install
[12:44] <pstolowski> this looks interesting: taskrunner.go:271: [change 899 "Run configure hook of \"microk8s\" snap if present" task] failed: run hook "configure": signal: segmentation fault
[12:44] <pstolowski> maybe it contributes to the problem. but it installs fine for me
[12:45] <mup> Bug #1939218 opened: snapd startup crash after install of standalone microk8s <snapd:Triaged> <https://launchpad.net/bugs/1939218>
[12:48] <mup> Bug #1939218 changed: snapd startup crash after install of standalone microk8s <snapd:Triaged> <https://launchpad.net/bugs/1939218>
[12:56] <miguelpires> pstolowski:  also can't reproduce it. Did you just run download and install? Did you have the microk8s snap installed previously?
[12:57] <pstolowski> miguelpires: yes I downloaded/installed as in the bug description. I might have had microk8s before
[12:57] <pstolowski> miguelpires: or no, actually not, i'm using a fresh VM
[12:57] <pstolowski> so no k8s before
[13:04] <miguelpires> Hm, I ran the download and install with microk8s already installed to see if it'd confuse it. It fails in the configure, undoes everything, but doesn't panic
[13:44] <ack> hi, does this message point to an issue or is it just informational: "WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement" ?
=== dbungert1 is now known as dbungert
[14:12] <mardy> ack: just informational; though I think that in the newest releases of snapd this warning was removed, since cgroup v2 is now fully supported (please mborzecki correct me if I'm wrong)
[14:13] <mborzecki> yes, it's gone in 2.53
[14:21] <ack> ah, cool, thanks
[14:47] <ijohnson[m]> mardy: hey so I was thinking about the issue in #10935, I notice it only seems to happen on core18, and I also notice that it started failing recently, and I finally noticed that there is a new core18 available in edge, maybe it's worth trying to run that spread test with the core18 version from stable instead of edge and see if it keeps failing? 
[14:47] <mup> Bug #10935: backuppc: new changes from Debian require merging <backuppc (Ubuntu):Fix Released by lamont> <https://launchpad.net/bugs/10935>
[14:47] <mup> PR #10935: tests: wait for snapd to be fully setup before installing snaps <Created by mardy> <https://github.com/snapcore/snapd/pull/10935>
[14:47] <ijohnson[m]> maybe this is a systemd bug
[15:16] <flotter> flotter@flotter-pc:~/snapd/packaging$ grep -r python3-docutils
[15:16] <flotter> debian-sid/control:               python3-docutils,
[15:16] <flotter> ubuntu-16.04/control:               python3-docutils,
[15:16] <flotter> opensuse/snapd.spec:BuildRequires:  python3-docutils
[15:16] <flotter> ubuntu-14.04/control:               python3-docutils,
[15:17] <flotter> Hi, it looks like my run-checks has a dependency on python3-yamlordereddictloader
[15:18] <flotter> I would like to fix the problem. Adding it to the debian packages feels easy. I am not 100% sure about fedora / opensuse. Are they still maintained? 
[15:32] <mup> PR snapd#10945 opened: osutil/disks/labels: simplify decoding algorithm <Simple 😃> <Skip spread> <Created by mardy> <https://github.com/snapcore/snapd/pull/10945>
[15:40] <mardy> ijohnson[m]: ^ unfortunately it's not as simple as I thought, because regexp.ReplaceAllStringFunc() does not pass index information.
[15:47] <ijohnson[m]> mardy: ah thanks I'll take a look, did you see my ping above about systemd though ?
[15:48] <ijohnson[m]> flotter: iirc that python package is only needed to check the yaml files are laid out in the expected way, I thought that cachio (who seems to be offline at the moment) had fixed all that up, are you saying there's an issue in the packaging?
[15:52] <mup> PR snapd#10544 closed: cmd/snap: support --ignore-validation with snap install client command <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/10544>
[15:52] <mup> PR snapd#10934 closed: tests/snapd-sigterm: be more robust against service restart <Simple 😃> <Created by mardy> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/10934>
[15:57] <mup> PR snapd#10883 closed: o/snapstate, hookstate: print remaining hold time on snapctl --hold <Squash-merge> <Needs Samuele review> <Refresh control> <cherry-picked> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/10883>
[15:58] <mup> PR snapd#10912 closed: tests: not testing lxd snap anymore on i386 architecture <Simple 😃> <Created by sergiocazzolato> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/10912>
[16:08] <mup> PR snapd#10946 opened: secboot: use latest secboot with tpm legacy platform and v2 fully optional <UC20> <Run nested> <Created by pedronis> <https://github.com/snapcore/snapd/pull/10946>
[16:44] <ijohnson[m]> ijohnson-test: test
[16:44] <ijohnson-test> ijohnson[m] echo
[16:44] <ijohnson[m]> hmm seems to work fine
[16:48] <mup> PR snapd#10947 opened: tests: run spread tests on debian 11 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10947>
[17:28] <mup> PR snapd#10948 opened: tests: skip interfaces-timeserver-control on debian-sid <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10948>
[17:54] <mardy> ijohnson[m]: oh, no, I didn't see it. I'll give it a try tomorrow.
[20:23] <ijohnson[m]> hey mwhudson or dbungert what was that lp bug for the live server installer when trying to do snap things would hang because snapd didn't shut itself down when subiquity kept too many connections open to it?
[20:24] <ijohnson[m]> ah it was https://bugs.launchpad.net/snapd/+bug/1946656 
[20:24] <mup> Bug #1946656: [daily impish-live-server] snap stuck in the installer system <fr-1794> <snapd:In Progress by mardy> <subiquity:Fix Committed> <Ubuntu CD Images:New> <https://launchpad.net/bugs/1946656>
[20:24] <ijohnson[m]> nvm me
[20:25] <dbungert> :)
[20:25]  * mwhudson avoids minding
[20:25] <mwhudson> i would still like to know what state the sockets were in when all that was going on