[05:17] <mborzecki> morning
[05:30] <mup> PR snapd#8763 closed: gadget: make ext4 filesystems with or without metadata checksum <UC20> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8763>
[06:03] <mborzecki> quick errand
[06:25] <mup> PR snapd#8758 closed: tests: run ubuntu-20.04-* tests on all ubuntu-2* releases <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8758>
[06:30] <mvo> zyga: I see "2020-05-27T16:45:02.9982589Z invariant-tool: crashed-snap-confine not-ok" in some tests, most recently in https://github.com/snapcore/snapd/pull/8744/checks?check_run_id=713534659
[06:30] <mup> PR #8744: interfaces-ssh-keys: Support reading /etc/ssh/ssh_config.d/ <Needs security review> <Created by andrewsomething> <https://github.com/snapcore/snapd/pull/8744>
[06:30] <mup> PR snapd#8744 closed: interfaces-ssh-keys: Support reading /etc/ssh/ssh_config.d/ <Needs security review> <Created by andrewsomething> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8744>
[06:41] <pedronis> mborzecki: mvo: hi, #8763 needs to be ported to master?  (I didn't notice it was target at 2.45 only)
[06:41] <mup> PR #8763: gadget: make ext4 filesystems with or without metadata checksum <UC20> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8763>
[06:43] <mvo> pedronis: I think there were two, let me quickly check (one for master, one for 2.45)
[06:44] <mvo> pedronis: oh, you are right, let's fix this :(
[06:47] <pedronis> mvo: does the test in #8762 works?
[06:47] <mup> PR #8762: snap-bootstrap: remove sealed key file on reinstall <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>
[06:48] <mvo> pedronis: yes, I'm reworking it now though to put the files into the right places, i.e. simulate more closely what we really do (/run/mnt/ubuntu-seed/keyfile, /run/mnt/ubuntu-data/system-data/var/lib/snapd/fde/... for the rest)
[06:48] <pedronis> ah, good
[06:50] <mup> PR snapd#8765 opened: gadget: make ext4 filesystems with or without metadata checksum (master) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8765>
[06:53] <pedronis> mvo: btw the comment in the description was wrong, given that the note mentions reboot, I don't think it's just a creation-time issue
[06:54] <zyga> Good morning
[06:55] <mborzecki> re
[06:55] <mborzecki> mvo: pedronis: zyga: hey
[06:55] <pedronis> mvo: and sorry for the many rounds of comments on #8762, I wasn't concetrating properly last night
[06:55] <mup> PR #8762: snap-bootstrap: remove sealed key file on reinstall <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>
[07:01] <mvo> pedronis: thank you for the comments, the opposite - my stuff was not coherent enough :( but I will push an updated version soon that is hopefully good
[07:02] <pstolowski> morning
[07:04] <mvo> good morning pstolowski
[07:17] <zyga> mvo: I need to look, I think it's not really that but leftover from package upgrade, trying to reproduce now
[07:18] <zyga> offtopic, I was thinking, that 8GB pi may be just able to run run spread with qemu backend
[07:33] <mvo> zyga: finally a arm spread runner?
[07:33] <zyga> mvo: we'll see, but I think given the low cost and 8GB of ram, might be possible
[07:37] <mborzecki> zyga: do ou know what's the status of kvm and virtio-* on aarch64?
[07:37] <mborzecki> i would guess it's a major factor for making the tests run smoothly
[07:38] <pstolowski> i'd appreciate a second review for #8710, test only
[07:38] <mup> PR #8710: tests: spread test for preseeding in lxd container (3/3) <Preseeding 🍞> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8710>
[07:39] <mborzecki> pstolowski: i can take a look
[07:39] <pstolowski> mborzecki: thanks!
[07:45] <zyga> mborzecki: not really, I think 32 bit kvm was removed but 64 bit should be ok
[07:52] <pstolowski> mvo: i was talking to Sergio yesterday about uc20 model assertions and the TODO you have in gadget-config-defaults-vitality spread test; apparently it's not possible yet to port this to uc20? i'd like a similiar test for nested uc20
[07:55] <mvo> pstolowski: I need to look again, but iirc the simulation of firstboot is slightly diffreent on uc20
[08:01] <pedronis> we need to think
[08:02] <pedronis> pstolowski: can you explain what you mean with similar but for nested?
[08:02] <pedronis> those tests are not nested
[08:03] <pstolowski> pedronis: i'm repacking the gadget,  but not cheating about firstboot (booting for real)
[08:03] <pstolowski> *i mean
[08:05] <pedronis> pstolowski: I see, you need a dangerous model, you need to your unasserted snaps into the seed partition in /systems/SYSTEM/snaps and you need a /systesm/SEED/options.yaml which is a bit like seed.yaml but only for overrides
[08:10] <pedronis> pstolowski: about options.yaml see seed/internal/options20.go
[08:12] <mborzecki> mvo: can you merge https://github.com/snapcore/snapd/pull/8271 ? the failure on 19.10 is unratelated to the change
[08:12] <mup> PR #8271: interfaces: add hugepages-control <Needs security review> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8271>
[08:12] <mvo> mborzecki: sure
[08:13] <pstolowski> pedronis: thanks for pointers, that helps!
[08:13] <mvo> mborzecki: does it have two +1 ?
[08:13] <mvo> mborzecki: nevermind, I have a look
[08:14] <mborzecki> mvo: ah no ;) jdstrand_ gave +1, but i can't cause i pushed some changes there
[08:16] <mup> PR snapd#8271 closed: interfaces: add hugepages-control <Needs security review> <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8271>
[08:20] <pstolowski> pedronis: do you have a moment to talk about sysconfig changes?
[08:20] <pedronis> pstolowski: yes
[08:23] <pstolowski> pedronis: ok, coming to standup ho
[08:28] <mborzecki> mup is asleep?
[08:28] <mborzecki> fairly simple fix in daemon: https://github.com/snapcore/snapd/pull/8766
[08:28] <mup> PR #8766: daemon: fix filtering of service-control changes for snap.app <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8766>
[08:31] <mup> PR snapd#8766 opened: daemon: fix filtering of service-control changes for snap.app <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8766>
[08:36] <abeato> mborzecki, hey, thanks for taking care of the hugepages PR - I should really have done those changes, but got trapped with other things
[08:37] <zyga> mvo: I spent some time looking at the log you referenced and it does seem like something is randomly failing in that test
[08:41] <mborzecki> abeato: hey, np, we're here to help land things too :)
[08:54] <mvo> zyga: thanks, yeah, it looks like 19.10 and 20.04 are a bit more unhappy today than earlier this week :/
[08:55] <zyga> I'll try to do something about that :)
[08:55] <zyga> call in 5, let me prepare
[08:56] <mup> PR snapd#8767 opened: snap: refactor download code for testing/extending <Created by mvo5> <https://github.com/snapcore/snapd/pull/8767>
[08:59] <zyga> ah
[08:59]  * zyga is dummy
[08:59] <zyga> that's not today :0
[08:59] <zyga> ok :)
[09:00] <zyga> back to original task
[09:22] <zyga> journal logs don't show failures from snapd-session-agent
[09:22] <zyga> but
[09:22] <zyga> mvo: this is the failure
[09:22] <zyga> May 28 20:06:30 may281929-399859 snapd[27253]: May 28 19:59:05 may281929-399859 systemd[1273]: snapd.session-agent.socket: Socket unit configuration has changed while unit has been running, no open socket file descriptor left. The socket unit is not functional until restarted.
[09:23] <zyga> I suspect those are branches without https://github.com/snapcore/snapd/pull/8753 but let me verify
[09:23] <mup> PR #8753: tests: reload systemd --user for root, if present <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8753>
[09:24] <zyga> hmm, no, that patch is present
[09:24] <zyga> curious
[09:24] <zyga> let's dig deeper
[09:25] <zyga> hmm
[09:25] <zyga> actually
[09:25] <zyga> just reading the error message
[09:25] <zyga> it seems to suggest the problem is not daemon-reload
[09:25] <zyga> but the fact that the socket needs restarting as wel
[09:25] <zyga> *well
[09:26] <zyga> that might be it
[09:26] <zyga> we'll know soon
[09:26] <mvo> zyga: thanks!
[09:31] <mup> PR snapd#8749 closed: configcore: show better error when disabling services <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8749>
[09:31] <mup> PR snapd#8757 closed: tests: update statx test to run on all LTS releases <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8757>
[09:41] <pedronis> mvo: oops, there was confusion, my proposal was to replace the second line of the comment, not all of it
[09:41] <pedronis> in #8782
[09:41] <mvo> pedronis: oh, sorry. let me fix that
[09:41] <pedronis> heh
[09:41] <pedronis> #8762
[09:41] <mup> PR #8762: snap-bootstrap: remove sealed key file on reinstall <Squash-merge> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>
[09:44] <mvo> pedronis: updated again
[09:45] <pedronis> thanks
[09:50] <zyga> pedronis: nitpick, can we call $TESTTOOLS $TESTTOOLS instead?
[09:50] <zyga> er
[09:50] <zyga> TESTSTOOLS -> TESTTOOLS
[09:50] <zyga> the  env vra
[09:50] <zyga> *var
[09:53] <pedronis> we have TESTSLIB not TESTLIB
[09:53] <zyga> the var mimicks path
[09:53] <zyga> but the name sounds bad if you think about it
[09:53] <zyga> both plural
[09:54] <pedronis> I'm worried about TESTSLIB TESTTOOLS
[09:54] <zyga> that they differ?
[09:54] <zyga> test libs would be better for english var
[09:54] <zyga> the path can stay as is
[09:54] <zyga> TESTLIBS
[09:54] <zyga> TESTTOOLS
[09:55] <pedronis> plural in programming are always trouble
[09:55] <pedronis> as I said I'm more worried about consistency than english here
[09:55] <zyga> we can do both ;)
[09:55] <zyga> I mean we can rename both while we are at it
[09:56] <zyga> $TESTTOOLS/foo reads better than $TESTSTOOLS/foo
[09:56] <pedronis> I don't  know, not a fan of TESTLIBS
[10:01] <pedronis> zyga: I fear TESTSLIB and TESTSTOOLS, anyway my nature we shouldn't need to use the latter that much
[10:01] <pedronis> s/my nature/by nature/
[10:01] <zyga> not sure what you mean by feal
[10:01] <zyga> fear *
[10:01] <pedronis> I mean, that we go with those
[10:02] <pedronis> mvo: I re-reviewed #8762
[10:02] <mup> PR #8762: snap-bootstrap: remove sealed key file on reinstall <Skip spread> <Squash-merge> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>
[10:04] <pedronis> anyway on unrelated note the user service stuff seems still fragile, I think we could tweak the tests more, but probably the fragility is real and the code need some changes
[10:05] <mvo> pedronis: thanks! so your suggestion is to run the same tests as for the install case in the reinstall case?
[10:05] <pedronis> mvo: either that because it seems cheap (at least code wise), or to at least run a small subset related to the encrypted partition
[10:06] <mvo> pedronis: yeah, it makes sense
[10:06] <mvo> pedronis: do you prefer duplication of the code or should I move it into a helper like with "prepare.sh" ?
[10:07] <pedronis> mvo: sorry, you don't need to duplicate code
[10:08] <pedronis> you can just reduce the scope of the if, no?
[10:08] <zyga> pedronis: it's a test bug, I fixed it just now
[10:08] <zyga> pedronis: (user service stuff)
[10:08] <mvo> pedronis: aha, nice
[10:08] <mvo> pedronis: yeah, I think this will work
[10:08] <pedronis> zyga: I doubt is just a test bug
[10:08] <zyga> apart from the known TODO, I think it is
[10:09] <zyga> the TODO being that removing snapd doesn't properly clean up user session services
[10:10] <zyga> you'll see in a moment
[10:10] <pedronis> zyga: there's a deeper issue, the existence of the snapd.session-agent.socket used by the code, doesn't really tell much about the state of the session
[10:11] <zyga> what kind of state are you referring to?
[10:13] <pedronis> we are going to ask to do it things with services in the session but the session, might be just starting up
[10:14] <pedronis> we don't know if the session overall in in a steady state
[10:15] <zyga> I think there's no such thing as a stady state, there are concurrently running processes that may stop or start as they please; I think it depends on what kind of ops we'd like the agent to perform
[10:15] <pedronis> I understand that
[10:16] <pedronis> but the existence of the socket is not here nor there
[10:16] <mborzecki> mvo: can we land https://github.com/snapcore/snapd/pull/8520 ? the failure on 20.04 is the user service again
[10:16] <pedronis> in terms of a barrier related to the state of other services
[10:16] <mup> PR #8520: data: fix shellcheck warnings in snapd.sh.in <Simple 😃> <Created by jelovac> <https://github.com/snapcore/snapd/pull/8520>
[10:17] <zyga> pedronis: the problem we are seeing in tests right now is related to the particular handling of socket units by systemd; I think that's a separate issue from what you are describing
[10:17] <zyga> our tests continously remove and reinstall snapd, making the socket definition in memory wrong, that was fixed (for tests) recently; what we are seeing now is that when a socket is removed from disk you must perform additional actions, more than just daemon-reload, for it to go away
[10:18] <zyga> and oddly enough installing a new definition of the socket is not sufficient
[10:21] <mup> PR snapd#7869 closed: travis-ci: split integration tests into parts (>4MB log limit) <Created by sd-hd> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7869>
[10:23] <zyga> I also wonder if this is not the same problem we had with pulseaudio, without realizing it
[10:23] <zyga> it's just there are so few tests that touch it it may not be triggered often
[10:39] <pedronis> zyga: btw, related question, does the refresh-awareness tracking for services also works for user services?
[10:39] <zyga> yes
[10:39] <zyga> fortunately :)
[10:40] <mborzecki> anyone tried the liferea snap? the font cache from the host is not mounted inside the snap, but i still get boxes
[10:42] <mborzecki> all i get is https://i.imgur.com/rNFMezE.png
[10:42] <zyga> hmmm
[10:42] <zyga> mborzecki: nsenter and poke around
[10:42] <zyga> wonder if there's something more going on
[10:42] <zyga> at some point fontconfig will figure out how to IPC the boxes around
[10:47] <mborzecki> hm i mounted a tmpfs over /usr/share/fonts in the mount ns of a snap and there's no more boxes
[10:47] <zyga> what's in /usr/share/fonts?
[10:47] <zyga> maybe a read only cache?
[10:47] <zyga> mborzecki, pedronis: please check this out https://github.com/snapcore/snapd/pull/8768
[10:47] <mup> PR #8768: tests: fix broken snapd.session agent.socket <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>
[10:48] <mborzecki> what if the fontconfig from gnome runtime is jsut buggy?
[10:48] <zyga> is there any configuration in /usr/share/fonts that is read by fontconfig?
[10:49] <mborzecki> zyga: there shouldn't be, i have a tmpfs on /etc/fonts and /usr/share/fonts
[10:49] <zyga> I mean
[10:49] <zyga> before you do the tmpfs
[10:50] <zyga> before you hide stuff there
[10:50] <zyga> what do you see if you find /usr/share/fonts
[10:50] <zyga> mborzecki: alternatively strace and explore
[10:50] <mborzecki> just fonts in directories
[10:51] <zyga> or ltrace
[10:51] <zyga> so are you saying those fonts cannot be rendered?
[10:51] <mborzecki> zyga: yeah, either boxes or segfaults again
[10:51] <zyga> hmmm
[10:51] <zyga> what kind of fonts do you have there
[10:51] <mup> PR snapd#8768 opened: tests: fix broken snapd.session agent.socket <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>
[10:51] <zyga> maybe bisect
[10:52] <zyga> and see which file triggers it
[10:52] <zyga> I think there must be something more than that
[10:52] <mborzecki> nothign special, looks like i need 18.04 desktop vm
[10:52] <zyga> maybe some font has a special hint bytecode that is disabled in arch
[10:52] <zyga> and then without a build option that crashes
[10:53] <mborzecki> zyga: but fontconfig is from the snap, if it can't handle arbitrary fonts the all hope is lost ;P
[10:53] <zyga> ahhh
[10:53] <zyga> interesting
[10:53] <zyga> yeah
[10:53] <zyga> but I think bisecting is the way to go
[10:53] <zyga> how many files do you have there?
[10:54] <pedronis> zyga: is tests cleanup meant to be on the PATH?
[10:54] <zyga> mborzecki: or maybe another idea: are there any duplicates?
[10:54] <pedronis> zyga: sorry, tests.cleanup
[10:54] <zyga> pedronis: I don't think so, it's only going to be used in prepare-restore in two places
[10:54] <pedronis> zyga: then it shouldn't have the tests. prefix
[10:54] <zyga> it's not something I expect to see in any task.yaml
[10:54] <zyga> oh? I misread the readme then
[10:54] <zyga> yeah, I see the fragment now
[10:55] <zyga> "commands that expect to be on PATH should follow more speicfic naming conventions"
[10:55] <zyga> I'll correct that, it's just a draft :)
[10:55] <zyga> so just $TESTSTOOLS/clenaup?
[10:55] <zyga> *cleanup
[10:55] <pedronis> or state-cleanup
[10:55] <zyga> ok
[10:55] <zyga> we should think about session services more
[10:56] <zyga> I think without handling the remove story we should be very careful
[10:58] <zyga> mborzecki: what do you think about the agent socket
[10:58] <zyga> I think this is actually a property of any unit
[10:59] <zyga> it's just sockets seem worse as "hey, it's there, let me talk to it"
[10:59] <zyga> and for non-session stuff we do stop services and sockets so it's not something we've seen before
[10:59] <mvo> pedronis: I reworked 8762, test is much nicer now and shares a ton. silly me for not thinking about this earlier :)
[11:05] <mborzecki> zyga: hmm making /usr/share/fonts/adobe-source-code-pro available inside the snap causes boxes and segfaults :P
[11:06] <zyga> awesome
[11:06] <zyga> now put that font on a 18.04 vm
[11:06] <zyga> what's the base of the snap you tried?
[11:06] <zyga> maybe strace/gdb the app
[11:06] <zyga> and get fontconfig-dbg
[11:06] <mborzecki> zyga: funny, i don't even use any of that fonts
[11:06] <mup> PR snapd#8765 closed: gadget: make ext4 filesystems with or without metadata checksum (master) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8765>
[11:07] <mborzecki> zyga: the backtrace is the same as before https://forum.snapcraft.io/t/gimp-and-glimpse-editor-snaps-segfault-on-arch/17100
[11:08] <zyga> where's the backtrace?
[11:08] <zyga> that's just some log
[11:12] <zyga> time to take Bit out for a walk
[11:12] <zyga> back in a bit
[11:12] <mborzecki> zyga: SourceCodeVariable-Roman.otf this font is causing a problem
[11:12] <mborzecki> wodner what's so special about it
[11:12] <zyga> mborzecki: developers and their fancy pantsy fonts ;)
[11:12] <zyga> mborzecki: yeah, it's curious
[11:12] <zyga> if you can reporduce the crash outside of snaps
[11:12] <zyga> we should report those
[11:12] <mborzecki> zyga: but i'm not even using this font
[11:13] <zyga> and even debug and fix them, if possible
[11:13] <zyga> mborzecki: so what, it's there
[11:13] <zyga> it gets scanned
[11:13] <mborzecki> glimpse-editor and gimp segfault, probably because the load up all info about fonts
[11:13] <zyga> yeah
[11:13] <ogra> try inkscape
[11:13] <mborzecki> apps that aren't so interested get boxes?
[11:13] <ogra> from the edge channel
[11:13] <zyga> mborzecki: maybe boxes are for another reason
[11:13] <zyga> the cache is corrupted
[11:13] <ogra> it has this new fancy font handling hack
[11:13] <mborzecki> ogra: oh, right
[11:13] <zyga> try generating the cache
[11:13] <zyga> and see if that crashes
[11:14] <ogra> try inkscape first to see if the hack works !
[11:14] <zyga> mvo: please check this out
[11:14] <zyga> https://github.com/snapcore/snapd/pull/8768
[11:14] <mup> PR #8768: tests: fix broken snapd.session agent.socket <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>
[11:14] <zyga> now really afk
[11:14] <mborzecki> yeah, inkscape edge works
[11:14] <ogra> awesome
[11:15] <ogra> it throws some font.conf errors on startup though ... (unknown options) ... but i see it working in zoom as well
[11:25] <mup> Bug #1881276 opened: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>
[11:26] <pstolowski> pedronis: i've updated #8567, let me know if this is what you had in mind. image_linux became slightly ugly
[11:26] <mup> PR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
[11:29] <mborzecki> mvo: can you take a look at https://github.com/snapcore/snapd/pull/8766 ?
[11:29] <mup> PR #8766: daemon: fix filtering of service-control changes for snap.app <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8766>
[11:31] <mup> Bug #1881276 changed: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>
[11:34] <ijohnson> morning folks
[11:37] <mup> Bug #1881276 opened: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>
[11:43] <mup> Bug #1881276 changed: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>
[11:46] <mup> Bug #1881276 opened: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>
[11:49] <mborzecki> zyga: so the same font works in ubuntu, even in the same snap on ubuntu
[11:49] <mborzecki> i've mounted tmpfs over the fonts cache and /etc/fonts
[11:49] <mborzecki> and it still works, wtf??
[11:58] <zyga> Hmmmmm
[11:58] <zyga> Drop font cache
[11:58] <zyga> Does it crash?
[12:04] <mborzecki> no
[12:04] <mborzecki> it's dropped already
[12:04] <mborzecki> no /var/cache/fontconfig, no /etc/fonts
[12:05] <ogra> and ~/.local/fonts ... etc ?
[12:06] <ogra> (iirc the desktop launchers pick these up too)
[12:06] <pedronis> pstolowski: I reviewed #8567
[12:06] <mup> PR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
[12:07] <pstolowski> pedronis: thanks
[12:07] <pedronis> thank you
[12:10] <mborzecki> heh, wiped ~/.cache/fontconfig/ and it's working now
[12:10] <mborzecki> damn, i don't see how we can make it work if there's even a slightest bit of fontconfig cache being shared
[12:12] <ijohnson> mborzecki: re 8766, if you do `snap restart lxd.daemon` now we don't pass in inst.Names though, we always pass in namesToSnapNames(...) so how could the names on the task get set to the inst.Names
[12:12] <mup> PR snapd#8639 closed: o/cmdstate: handle ignore flag on exec-command tasks (1/N) <Services ⚙️> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8639>
[12:14] <mborzecki> ijohnson: i clarified in a comment there, what meant by `names` in the comment is inst.Names
[12:14] <mborzecki> ijohnson: anyways, i rephrased the comment, please check if it makes sense now
[12:14] <ijohnson> mborzecki: ahhhhh sorry I'm a bit slow this morning it seems
[12:14]  * ijohnson looks now
[12:14] <ijohnson> thank you makes sense now
[12:15] <mborzecki> cool
[12:17] <zyga> mborzecki: so which part of our code makes your ~/.cache/fontconfig available to the snap?
[12:18] <zyga> mborzecki, mvo: please review https://github.com/snapcore/snapd/pull/8768 to unbreak master
[12:18] <mup> PR #8768: tests: fix broken snapd.session agent.socket <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>
[12:21] <mborzecki> zyga: desktop-launch copies over the cache from $HOME/.cache/fontconfig, it works because the snap uses `home`
[12:21] <mborzecki> zyga: so outside of our control apaprently
[12:21] <zyga> mborzecki: wait, cannot we block the cache somehow?
[12:21] <zyga> we could also add a user mount namespace directory to mask ~/.cache/fontconfig
[12:21] <zyga> make it empty
[12:22] <zyga> right?
[12:22] <mborzecki> zyga: sounds like slippery slope
[12:22] <zyga> why?
[12:22] <mborzecki> feels too fiddly
[12:23] <mborzecki> it's probably ok as some temporar fix
[12:23] <zyga> but that's not a good answer :) on one hand side we have crashes and boxes
[12:23] <mborzecki> but it'd really prefer to have the right fix
[12:23] <zyga> on the other "feels too fiddly"?
[12:23] <zyga> sure, what's the right fix?
[12:23] <zyga> (I'm with you on that)
[12:24] <zyga> I would love to know if it's a specific font
[12:24] <zyga> or just any cache
[12:24] <mborzecki> zyga: didn't we discuss that? have snaps build their own cache during install, find a way to share that maybe witht the gnome content snap
[12:24] <zyga> mborzecki: we did discuss that but I think we ought to fix the crashes without requiring all snaps to rebuild
[12:33] <pedronis> mborzecki: we discusses something like that platform snaps taking care of this for snaps that use them, or possibly individual snaps
[12:33] <pedronis> *discussed
[12:36] <mborzecki> zyga: hmm, w8, we can't really expand $HOME in user mounts, can we?
[12:36] <zyga> mborzecki: so, not yet but I kind of wrote a patch for that
[12:36] <mborzecki> xD
[12:36] <zyga> not sure if you noticed a QFG1 themed tweet a few weekends ago
[12:36] <zyga> I added support for all the goodies required to have ~ available
[12:37] <zyga> today is too late but I can post them next week with some cleanups
[12:39] <mborzecki> i recall i had a patch for $HOME too at some point, but for some reason we didn't do it
[12:39] <zyga> it was somewhat fiddly
[12:39] <zyga> anyway, I will post it later
[12:39] <mborzecki> perhaps it was aroudn the time of parallel installs and mapping $HOME/snap/foo_bar $HOME/snap/foo ?
[12:40] <cachio> zyga, could you please take a look to https://github.com/snapcore/spread/pull/107
[12:40] <mup> PR spread#107: Use GitHub actions to test spread <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/107>
[12:40] <cachio> zyga, and hi
[12:40] <cmatsuoka> zyga: I have snapd using 10% of CPU and constantly writing on disk for some time, any idea on what is happening there? https://pasteboard.co/JaC0JzY.png
[12:40] <zyga> cachio: ah, right you asked me yesterday
[12:40] <zyga> sure
[12:41] <cachio> zyga, thanks a lot
[12:41] <zyga> cachio: snap changes
[12:41] <mborzecki> cmatsuoka: snap changes?
[12:41] <zyga> I meant cmatsuoka :)
[12:41] <mborzecki> maybe it'd downloading something and rewriting state.json all the time
[12:41] <cmatsuoka> zyga, mborzecki: no changes, no logs
[12:41] <mborzecki> what was that fs tool
[12:41] <zyga> there are _no_ changes
[12:41] <zyga> mborzecki: which one?
[12:41] <zyga> forkstat?
[12:41] <zyga> or iotop?
[12:41] <mborzecki> zyga: fs<something>stat
[12:42] <cmatsuoka> i used iotop and fatrace
[12:42] <cmatsuoka> fatrace interestingly doesn't show anything
[12:42] <mborzecki> fnotifystat
[12:42] <zyga> ah
[12:42] <pstolowski> ijohnson: hi! thanks for looking at services PRs
[12:43] <mborzecki> cmatsuoka: maybe it's the same problem as https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1831629
[12:43] <mup> Bug #1831629: snapd hammers SSD for long periods <amd64> <apport-bug> <disco> <snapd (Ubuntu):Expired> <https://launchpad.net/bugs/1831629>
[12:43] <cmatsuoka> let me see...
[12:43] <zyga> cmatsuoka: run forkstat too
[12:43] <zyga> I wonder if we fail on something
[12:44] <mborzecki> heh almost standup time
[12:44] <cmatsuoka> not much information there but it could be the same thing
[12:45] <zyga> cmatsuoka: maybe join ho and screen share
[12:45] <zyga> I can hop
[12:45] <cmatsuoka> zyga: yeah, going there
[12:46] <mborzecki> standup ho?
[12:57] <mup> PR snapd#8643 closed: wrappers: add RestartServices function and ReloadOrRestart to systemd (3/N) <Services ⚙️> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8643>
[13:17] <mup> PR snapd#8768 closed: tests: fix broken snapd.session agent.socket <Test Robustness> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8768>
[13:22] <mup> PR snapd#8769 opened: dbusutil: move all D-Bus helpers and D-Bus test helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8769>
[13:32] <mup> PR snapd#8710 closed: tests: spread test for preseeding in lxd container (3/3) <Preseeding 🍞> <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8710>
[13:47] <mup> PR snapd#8770 opened: snap/naming: add ParseSecurityTag and friends <Created by zyga> <https://github.com/snapcore/snapd/pull/8770>
[14:05] <pstolowski> zyga: if you have a moment, that's the PR from yesterday: https://github.com/snapcore/snapd/pull/8640
[14:05] <mup> PR #8640: wrappers: pass 'disable' flag to StopServices wrapper (2/N) <Services ⚙️> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8640>
[14:36] <ackk> jdstrand_, hi, around?
[14:48] <zyga> re
[14:48] <zyga> back to reviews
[14:48] <zyga> pstolowski: sure!
[14:50] <zyga> pstolowski: looks good
[14:52] <zyga> pstolowski: review sent
[14:52] <pstolowski> dzięki!
[14:53] <zyga> proszę :)
[14:54] <mvo> 8762 needs a second review
[14:58] <zyga> can someone please look at https://github.com/snapcore/snapd/pull/8769/checks?check_run_id=720464127 and explain what failed in snap-repair?
[14:58] <mup> PR #8769: dbusutil: move all D-Bus helpers and D-Bus test helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8769>
[15:08] <zyga> cachio: that change is somewhat big, I will probably not finish reviewing it today
[15:08] <zyga> cachio: my mild preference would be to split it up into separate cunks
[15:08] <zyga> chunks
[15:08] <zyga> I don't understand why some things are done; I have a few pending questoins
[15:08] <zyga> *questions
[15:09] <cachio> zyga, ok, let me check
[15:10] <zyga> cachio: but please, if you can, open separate PR for the reorg
[15:10] <zyga> as 37 changed files is a bit too much to follow coupled with actions
[15:11] <cachio> zyga, well, most of the things are just moved
[15:12] <cachio> I had to move a test suite
[15:12] <cachio> so all the tests are moved
[15:12] <cachio> not changed
[15:12] <cachio> and it is the same for the prepare in the spread.yaml
[15:12] <zyga> but the reason for that move is not clear from the diff or description alone
[15:13] <cachio> zyga, I think the best is to split in 2
[15:13] <cachio> fist github actions
[15:13] <cachio> then in a second pr
[15:13] <cachio> put all the migration
[15:13] <cachio> zyga, does it make sense?
[15:13] <cachio> I just need to revert a commit for that
[15:13] <zyga> or the other way around, whatever is easier
[15:14] <zyga> the reorg can probably land faster
[15:14] <cachio> sure
[15:14] <cachio> I'll make it
[15:14] <zyga> thanks
[15:17] <mup> PR snapd#8771 opened: bootloader/ubootenv: don't panic with an empty uboot env <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8771>
[15:18] <jdstrand_> ackk: hey, yes
[15:20] <ackk> jdstrand, hi, I have a quesion for you: given snap A and B with a container interaface slot/plug (from the same publisher, if that matters), is it possible to get them autoconected if they're both installed? can it be done through a store assertion?
[15:21] <ackk> jdstrand, no default-provider though, as we don't want to get B automatically installed if A is installed
[15:21] <jdstrand> ackk: by container interface, you mean content interface?
[15:21] <ackk> jdstrand, yes, sorry, muscle memory :)
[15:21] <jdstrand> ackk: the content interface should autoconnect from the same publisher
[15:22] <jdstrand> without needing to create a snap decl
[15:22] <pedronis> it should happen already, unless there's more than one slot with the same content label
[15:23] <ackk> oh, really? I thougth that would only happen for default-provider
[15:23]  * ackk tries
[15:24] <pedronis> default-provider has zero effects on connections
[15:24] <pedronis> it just pulls in the sanp
[15:24] <pedronis> *snap
[15:24] <ackk> I'm not seeing this with maas and maas-test-db
[15:24] <ackk> snap install maas --edge + snap install --channel=2.8 maas-test-db
[15:26] <zyga> ackk: could you paste the relevant plug and slot definitions from the snap.yaml's
[15:26] <zyga> snap.yamls
[15:26] <ackk> https://paste.ubuntu.com/p/s3R9GcqJRK/ are connections I see after installing as above
[15:26] <ogra> wow ... looks like we have some racyness
[15:26] <ogra> https://paste.ubuntu.com/p/jQZsVpQy67/
[15:26] <ackk> zyga, sure, one sec
[15:27] <ogra> (this board has not been booted since about 5 months)
[15:27] <ogra> (later calls to the snap command seem to work again)
[15:27] <ackk> zyga, https://paste.ubuntu.com/p/wX6C3ZVZfs/
[15:27] <ackk> zyga, do names need to match?
[15:28] <zyga> I don't think so
[15:28] <zyga> btw, do you need write? I think read should suffice for sockets
[15:28] <zyga> does it work if you connect manually?
[15:28] <zyga> (can you connect at all, I guess, is the question)
[15:28] <ackk> zyga, readonly doesn't work, no
[15:29] <zyga> I'd be interested in denials later on
[15:29] <ackk> zyga, yes, works fine if I connect it. reason I'm asking is purely to save one extra steps for users
[15:29] <zyga> do you have other provides of "db-socket"?
[15:29] <zyga> (installed)
[15:30] <ackk> no
[15:30] <zyga> do we log anything in snapd.service about tihs?
[15:31] <ackk> zyga, I only see this when installing maas-test-db (with maas installed):
[15:32] <ackk> May 29 15:31:22 maas snapd[368]: api.go:985: Installing snap "maas-test-db" revision unset
[15:32] <zyga> I see
[15:32] <zyga> oh well, someone needs to dig
[15:32] <zyga> could you please ping me on Monday
[15:32] <ackk> zyga, sure, thanks
[15:32] <zyga> I'm wrapping up a branch and I'd like to EOD
[15:32] <zyga> it's probably something silly
[15:32] <zyga> I wonder if we can get better debugging of cases like that
[15:33] <pedronis> ackk: I installed maas --edge and I don't see the slot
[15:33] <pedronis> in the yaml
[15:33] <pedronis> or the plug
[15:33] <cachio> zyga, updated the pr
[15:33] <ackk> weird, lemme see
[15:34] <cachio> zyga, about the version of go used to build spread
[15:34] <zyga> pedronis: I'm preparing the tools reorg pr
[15:34] <pedronis> ackk: did mean 2.8/edge in your instructions?
[15:34] <cachio> we already are builing with this version
[15:35] <ackk> pedronis, I was just testing thatm it seems 2.8/edge does work
[15:35] <cachio> so I just put that version on the actions
[15:35] <ackk> pedronis, weird, we added that a long time ago and both revisions don't seem far off
[15:35] <pedronis> ackk: yea, --edge is 2.7/edge and doesn't have any of that
[15:35] <cachio> zyga, not sure which kind of comment you would add there
[15:35] <zyga> cachio: about the significance of that particular version,
[15:35] <ackk> pedronis, no, 2.7 doesn't, but --edge should be latest/edge which is based on CI. for some reason it must have been behind
[15:35] <ackk> sorry for the noise, it seems it works then
[15:36] <zyga> it's a fixed number, maybe we should test with latest instead?
[15:36] <ackk> zyga, ^
[15:36] <ackk> zyga, pedronis thanks
[15:36] <zyga> ackk: woot :)
[15:36] <pedronis> ackk: no you have a default track, so --edge is 2.7/edge
[15:36] <pedronis> if you want latest you need install --channel=latest/edge
[15:38] <mup> PR snapd#8766 closed: daemon: fix filtering of service-control changes for snap.app <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8766>
[15:41] <ackk> pedronis, ah, right! that always tricks me :)
[15:42] <pedronis> zyga: I would prefer that we land #8759 and #8691 with some final scaffolding in it first though
[15:42] <mup> PR #8759: tests: move *-tool tests to their own suite <Created by pedronis> <https://github.com/snapcore/snapd/pull/8759>
[15:42] <mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
[15:42] <zyga> oh, I forgot about that entirely
[15:42]  * zyga looks now
[15:43] <pedronis> zyga: also we need to add TESTTOOLS to debian/tests/integrationtests
[15:43] <pedronis> TESTSTOOLS
[15:43] <pedronis> or autopkgtests might get broken
[15:44] <zyga> pedronis: good point, I'll check that
[15:45] <zyga> pedronis: any specific reason for [[ ]] over regular [ ] ?
[15:46] <pedronis> it was used already for something
[15:46]  * zyga Hmm, we only use it for the regexp matching behavior.
[15:50] <pedronis> if not super consistent
[15:50] <pedronis> we are not super consistent
[15:50] <pedronis> if [[ -d ./mnt ]]
[15:54] <zyga> pedronis: would you mind if I push a change to convert the additions to [ ] ?
[15:55] <zyga> I really like [[ but I prefer to use it only when ther'es no simpler alternative, mainly to remove the "why is this used" question
[15:55] <pedronis> zyga: yes, mostly because it has consumed already too many spread cycles
[15:55] <pedronis> it can be changed later
[15:55] <zyga> ok
[15:55] <zyga> I'll bundle that in the next PR with tool changes
[15:56] <pedronis> zyga: which changes are you doing in that new PR?
[15:58] <zyga> pedronis: https://github.com/snapcore/snapd/pull/8759/files#r432582187
[15:58] <mup> PR #8759: tests: move *-tool tests to their own suite <Created by pedronis> <https://github.com/snapcore/snapd/pull/8759>
[15:58] <zyga> pedronis: moving tools to tests/lib/tools, adding symlinks to tests/bin, renaming each tool one by one, removing compatibility hacks
[16:01] <zyga> pedronis: that question I linked to above is the only thing I'd like to understand before approving
[16:01] <pedronis> zyga: I answered
[16:02] <pedronis> zyga: cleanup-state is a bit too new to know a final answer
[16:02] <zyga> ok
[16:03] <zyga> +1
[16:03] <mup> PR snapd#8760 closed: systemd: rename actualFsTypeAndMountOptions to hostFsTypeAndMountOptions <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8760>
[16:03] <zyga> let's merge when it's green
[16:03] <pedronis> zyga: related to your wip PR, I'll try to do mimimal things then in #8691, just create the dirs, and change spead.yaml (and integration tests)
[16:03] <mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
[16:04] <pedronis> I still would like for it to land first
[16:04] <zyga> the readme PR?
[16:04] <pedronis> yes
[16:04] <zyga> yeah, LGTM!
[16:04] <zyga> it's a draft
[16:04] <zyga> please open it for review
[16:07] <zyga> with the TODO merged we can chop parts off it in each commit
[16:07] <zyga> maybe mvo can just merge it
[16:07] <zyga> there's no point in testing it
[16:07] <zyga> mvo: ^ could you please merge https://github.com/snapcore/snapd/pull/8691
[16:07] <mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
[16:07] <mvo> zyga: sure
[16:07] <zyga> super
[16:07] <zyga> thanks!
[16:08] <mvo> zyga: should it be promoted to "ready for review" at least?
[16:08] <mvo> zyga: it's still draft
[16:08] <zyga> yeah, I think pedronis should do that
[16:08] <pedronis> mvo: please don't merge it
[16:08] <zyga> oh?
[16:08] <mvo> pedronis: set it to blocked
[16:08] <pedronis> as I said I want to do some things in it
[16:08] <zyga> ah, I missed that
[16:08] <zyga> ok, in that case I'll review it again when it's open
[16:12]  * zyga EODs and goes for a walk
[16:36] <Saviq> humpf
[16:36] <Saviq> https://travis-ci.com/github/MirServer/mir/jobs/341502620#L247
[16:36] <Saviq> All snaps up to date.; try to update snapd and refresh the core snap
[16:41]  * cachio lunch
[16:58] <ijohnson> jdstrand: thanks for the review on #8724, so to be clear you are now requesting I add all of the accesses, changes, etc. requested by you there to block-devices? or should I still be adding a nvme-control interface ?
[16:58] <mup> PR #8724: interfaces/block_devices: add NVMe subsystem devices, support multipath paths <Needs security review> <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8724>
[16:58] <jdstrand> ijohnson: the former
[16:58] <ijohnson> jdstrand: sounds good thanks
[16:58] <jdstrand> ijohnson: but a description change is in order to mention something about controller devices
[16:59] <ijohnson> right
[16:59] <jdstrand> ijohnson: well, maybe not 'description' like with 'snap interface block-devices', but definitely a code comment above the description and a policy comment
[17:00] <ijohnson> sure
[17:01] <jdstrand> ijohnson: the idea is that these controller devices allow manipulating the block devices that we want to expose, so grouping them together makes sense. we don't group partitions since we determined a separate interface (raw-volume) is a nice place to split the policy
[17:01] <ijohnson> jdstrand: yes that all makes sense, I'll try to update that this afternoon I think
[17:02] <jdstrand> (manipulating a raw device (and its controller) is a significantly different operation than manipulating an individual partition)
[17:02] <jdstrand> ijohnson|lunch: cool thanks!
[17:03] <jdstrand> ijohnson|lunch: sorry that it wasn't clear. I had a strong conviction and then convinced myself I was wrong
[17:03] <jdstrand> :)
[17:09] <ijohnson|lunch> jdstrand: haha yes I know the feeling quite well
[17:53] <mup> PR snapd#8771 closed: bootloader/ubootenv: don't panic with an empty uboot env <Simple 😃> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8771>
[17:58] <mup> PR snapd#8762 closed: snap-bootstrap: remove sealed key file on reinstall <Squash-merge> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8762>
[18:04] <mvo> quick eyeball on 8772 would be great
[18:08] <mup> PR snapd#8772 opened: snap-bootstrap: remove sealed key file on reinstall (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8772>
[18:25] <pedronis> mvo: +1
[18:25] <mvo> pedronis: thank you!
[18:26] <pedronis> we are getting mountinfo differences again :/
[18:26] <mvo> oh no
[18:26] <pedronis> 2020-05-29T18:07:04.4844746Z -+0:+1 / /sys/fs/cgroup/unified rw,nosuid,nodev,noexec,relatime shared:+1 - cgroup2 cgroup rw,nsdelegate
[18:26] <pedronis> 2020-05-29T18:07:04.4845221Z ++0:+1 / /sys/fs/cgroup/unified rw,nosuid,nodev,noexec,relatime shared:+1 - cgroup2 cgroup rw
[18:26] <pedronis> on 18.04
[18:27] <mvo> meh, I hope zyga has time to have a look
[18:28] <mup> PR snapd#8772 closed: snap-bootstrap: remove sealed key file on reinstall (2.45) <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8772>
[18:31]  * cachio afk
[19:43] <mup> PR snapd#8759 closed: tests: move *-tool tests to their own suite <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8759>
[19:56] <cmatsuoka> cachio: got a new error in opensuse: https://github.com/snapcore/snapd/pull/8591/checks?check_run_id=721480264
[19:56] <mup> PR #8591: secboot,cmd/snap-bootstrap: add tpm sealing support to secboot <Needs Samuele review> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8591>
[19:56] <cachio> cmatsuoka, checking
[19:57] <pedronis> cmatsuoka: I forgot to mention, I will get to review #8591 on Tuesday
[19:57] <cachio> cmatsuoka, it is new
[19:57] <cachio> I'll research it
[19:57] <cachio> thanks for the info
[19:58] <cmatsuoka> pedronis: ok, thanks
[21:27] <mup> PR snapcraft#3149 opened: elf: search dynamic tags within sections, not segment <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3149>