/srv/irclogs.ubuntu.com/2020/05/29/#snappy.txt

=== KindTwo is now known as KindOne
mborzeckimorning05:17
mupPR 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>05:30
=== franke is now known as Guest56840
mborzeckiquick errand06:03
mupPR 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:25
mvozyga: 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=71353465906:30
mupPR #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
mupPR 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:30
pedronismborzecki: mvo: hi, #8763 needs to be ported to master?  (I didn't notice it was target at 2.45 only)06:41
mupPR #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:41
mvopedronis: I think there were two, let me quickly check (one for master, one for 2.45)06:43
mvopedronis: oh, you are right, let's fix this :(06:44
pedronismvo: does the test in #8762 works?06:47
mupPR #8762: snap-bootstrap: remove sealed key file on reinstall <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>06:47
mvopedronis: 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
pedronisah, good06:48
mupPR snapd#8765 opened: gadget: make ext4 filesystems with or without metadata checksum (master) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8765>06:50
pedronismvo: btw the comment in the description was wrong, given that the note mentions reboot, I don't think it's just a creation-time issue06:53
zygaGood morning06:54
mborzeckire06:55
mborzeckimvo: pedronis: zyga: hey06:55
pedronismvo: and sorry for the many rounds of comments on #8762, I wasn't concetrating properly last night06:55
mupPR #8762: snap-bootstrap: remove sealed key file on reinstall <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>06:55
mvopedronis: thank you for the comments, the opposite - my stuff was not coherent enough :( but I will push an updated version soon that is hopefully good07:01
pstolowskimorning07:02
mvogood morning pstolowski07:04
zygamvo: I need to look, I think it's not really that but leftover from package upgrade, trying to reproduce now07:17
zygaofftopic, I was thinking, that 8GB pi may be just able to run run spread with qemu backend07:18
mvozyga: finally a arm spread runner?07:33
zygamvo: we'll see, but I think given the low cost and 8GB of ram, might be possible07:33
mborzeckizyga: do ou know what's the status of kvm and virtio-* on aarch64?07:37
mborzeckii would guess it's a major factor for making the tests run smoothly07:37
pstolowskii'd appreciate a second review for #8710, test only07:38
mupPR #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:38
mborzeckipstolowski: i can take a look07:39
pstolowskimborzecki: thanks!07:39
zygamborzecki: not really, I think 32 bit kvm was removed but 64 bit should be ok07:45
pstolowskimvo: 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 uc2007:52
mvopstolowski: I need to look again, but iirc the simulation of firstboot is slightly diffreent on uc2007:55
pedroniswe need to think08:01
pedronispstolowski: can you explain what you mean with similar but for nested?08:02
pedronisthose tests are not nested08:02
pstolowskipedronis: i'm repacking the gadget,  but not cheating about firstboot (booting for real)08:03
pstolowski*i mean08:03
pedronispstolowski: 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 overrides08:05
pedronispstolowski: about options.yaml see seed/internal/options20.go08:10
mborzeckimvo: can you merge https://github.com/snapcore/snapd/pull/8271 ? the failure on 19.10 is unratelated to the change08:12
mupPR #8271: interfaces: add hugepages-control <Needs security review> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8271>08:12
mvomborzecki: sure08:12
pstolowskipedronis: thanks for pointers, that helps!08:13
mvomborzecki: does it have two +1 ?08:13
mvomborzecki: nevermind, I have a look08:13
mborzeckimvo: ah no ;) jdstrand_ gave +1, but i can't cause i pushed some changes there08:14
mupPR snapd#8271 closed: interfaces: add hugepages-control <Needs security review> <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8271>08:16
pstolowskipedronis: do you have a moment to talk about sysconfig changes?08:20
pedronispstolowski: yes08:20
pstolowskipedronis: ok, coming to standup ho08:23
mborzeckimup is asleep?08:28
mborzeckifairly simple fix in daemon: https://github.com/snapcore/snapd/pull/876608:28
mupPR #8766: daemon: fix filtering of service-control changes for snap.app <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8766>08:28
mupPR snapd#8766 opened: daemon: fix filtering of service-control changes for snap.app <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8766>08:31
abeatomborzecki, hey, thanks for taking care of the hugepages PR - I should really have done those changes, but got trapped with other things08:36
zygamvo: I spent some time looking at the log you referenced and it does seem like something is randomly failing in that test08:37
mborzeckiabeato: hey, np, we're here to help land things too :)08:41
mvozyga: thanks, yeah, it looks like 19.10 and 20.04 are a bit more unhappy today than earlier this week :/08:54
zygaI'll try to do something about that :)08:55
zygacall in 5, let me prepare08:55
mupPR snapd#8767 opened: snap: refactor download code for testing/extending <Created by mvo5> <https://github.com/snapcore/snapd/pull/8767>08:56
zygaah08:59
* zyga is dummy08:59
zygathat's not today :008:59
zygaok :)08:59
zygaback to original task09:00
zygajournal logs don't show failures from snapd-session-agent09:22
zygabut09:22
zygamvo: this is the failure09:22
zygaMay 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:22
zygaI suspect those are branches without https://github.com/snapcore/snapd/pull/8753 but let me verify09:23
mupPR #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:23
zygahmm, no, that patch is present09:24
zygacurious09:24
zygalet's dig deeper09:24
zygahmm09:25
zygaactually09:25
zygajust reading the error message09:25
zygait seems to suggest the problem is not daemon-reload09:25
zygabut the fact that the socket needs restarting as wel09:25
zyga*well09:25
zygathat might be it09:26
zygawe'll know soon09:26
mvozyga: thanks!09:26
mupPR 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
mupPR 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:31
pedronismvo: oops, there was confusion, my proposal was to replace the second line of the comment, not all of it09:41
pedronisin #878209:41
mvopedronis: oh, sorry. let me fix that09:41
pedronisheh09:41
pedronis#876209:41
mupPR #8762: snap-bootstrap: remove sealed key file on reinstall <Squash-merge> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>09:41
mvopedronis: updated again09:44
pedronisthanks09:45
zygapedronis: nitpick, can we call $TESTTOOLS $TESTTOOLS instead?09:50
zygaer09:50
zygaTESTSTOOLS -> TESTTOOLS09:50
zygathe  env vra09:50
zyga*var09:50
pedroniswe have TESTSLIB not TESTLIB09:53
zygathe var mimicks path09:53
zygabut the name sounds bad if you think about it09:53
zygaboth plural09:53
pedronisI'm worried about TESTSLIB TESTTOOLS09:54
zygathat they differ?09:54
zygatest libs would be better for english var09:54
zygathe path can stay as is09:54
zygaTESTLIBS09:54
zygaTESTTOOLS09:54
pedronisplural in programming are always trouble09:55
pedronisas I said I'm more worried about consistency than english here09:55
zygawe can do both ;)09:55
zygaI mean we can rename both while we are at it09:55
zyga$TESTTOOLS/foo reads better than $TESTSTOOLS/foo09:56
pedronisI don't  know, not a fan of TESTLIBS09:56
pedroniszyga: I fear TESTSLIB and TESTSTOOLS, anyway my nature we shouldn't need to use the latter that much10:01
pedroniss/my nature/by nature/10:01
zyganot sure what you mean by feal10:01
zygafear *10:01
pedronisI mean, that we go with those10:01
pedronismvo: I re-reviewed #876210:02
mupPR #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:02
pedronisanyway 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 changes10:04
mvopedronis: thanks! so your suggestion is to run the same tests as for the install case in the reinstall case?10:05
pedronismvo: either that because it seems cheap (at least code wise), or to at least run a small subset related to the encrypted partition10:05
mvopedronis: yeah, it makes sense10:06
mvopedronis: do you prefer duplication of the code or should I move it into a helper like with "prepare.sh" ?10:06
pedronismvo: sorry, you don't need to duplicate code10:07
pedronisyou can just reduce the scope of the if, no?10:08
zygapedronis: it's a test bug, I fixed it just now10:08
zygapedronis: (user service stuff)10:08
mvopedronis: aha, nice10:08
mvopedronis: yeah, I think this will work10:08
pedroniszyga: I doubt is just a test bug10:08
zygaapart from the known TODO, I think it is10:08
zygathe TODO being that removing snapd doesn't properly clean up user session services10:09
zygayou'll see in a moment10:10
pedroniszyga: 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 session10:10
zygawhat kind of state are you referring to?10:11
pedroniswe are going to ask to do it things with services in the session but the session, might be just starting up10:13
pedroniswe don't know if the session overall in in a steady state10:14
zygaI 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 perform10:15
pedronisI understand that10:15
pedronisbut the existence of the socket is not here nor there10:16
mborzeckimvo: can we land https://github.com/snapcore/snapd/pull/8520 ? the failure on 20.04 is the user service again10:16
pedronisin terms of a barrier related to the state of other services10:16
mupPR #8520: data: fix shellcheck warnings in snapd.sh.in <Simple πŸ˜ƒ> <Created by jelovac> <https://github.com/snapcore/snapd/pull/8520>10:16
zygapedronis: 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 describing10:17
zygaour 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 away10:17
zygaand oddly enough installing a new definition of the socket is not sufficient10:18
mupPR 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:21
zygaI also wonder if this is not the same problem we had with pulseaudio, without realizing it10:23
zygait's just there are so few tests that touch it it may not be triggered often10:23
pedroniszyga: btw, related question, does the refresh-awareness tracking for services also works for user services?10:39
zygayes10:39
zygafortunately :)10:39
mborzeckianyone tried the liferea snap? the font cache from the host is not mounted inside the snap, but i still get boxes10:40
mborzeckiall i get is https://i.imgur.com/rNFMezE.png10:42
zygahmmm10:42
zygamborzecki: nsenter and poke around10:42
zygawonder if there's something more going on10:42
zygaat some point fontconfig will figure out how to IPC the boxes around10:42
mborzeckihm i mounted a tmpfs over /usr/share/fonts in the mount ns of a snap and there's no more boxes10:47
zygawhat's in /usr/share/fonts?10:47
zygamaybe a read only cache?10:47
zygamborzecki, pedronis: please check this out https://github.com/snapcore/snapd/pull/876810:47
mupPR #8768: tests: fix broken snapd.session agent.socket <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>10:47
mborzeckiwhat if the fontconfig from gnome runtime is jsut buggy?10:48
zygais there any configuration in /usr/share/fonts that is read by fontconfig?10:48
mborzeckizyga: there shouldn't be, i have a tmpfs on /etc/fonts and /usr/share/fonts10:49
zygaI mean10:49
zygabefore you do the tmpfs10:49
zygabefore you hide stuff there10:50
zygawhat do you see if you find /usr/share/fonts10:50
zygamborzecki: alternatively strace and explore10:50
mborzeckijust fonts in directories10:50
zygaor ltrace10:51
zygaso are you saying those fonts cannot be rendered?10:51
mborzeckizyga: yeah, either boxes or segfaults again10:51
zygahmmm10:51
zygawhat kind of fonts do you have there10:51
mupPR snapd#8768 opened: tests: fix broken snapd.session agent.socket <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>10:51
zygamaybe bisect10:51
zygaand see which file triggers it10:52
zygaI think there must be something more than that10:52
mborzeckinothign special, looks like i need 18.04 desktop vm10:52
zygamaybe some font has a special hint bytecode that is disabled in arch10:52
zygaand then without a build option that crashes10:52
mborzeckizyga: but fontconfig is from the snap, if it can't handle arbitrary fonts the all hope is lost ;P10:53
zygaahhh10:53
zygainteresting10:53
zygayeah10:53
zygabut I think bisecting is the way to go10:53
zygahow many files do you have there?10:53
pedroniszyga: is tests cleanup meant to be on the PATH?10:54
zygamborzecki: or maybe another idea: are there any duplicates?10:54
pedroniszyga: sorry, tests.cleanup10:54
zygapedronis: I don't think so, it's only going to be used in prepare-restore in two places10:54
pedroniszyga: then it shouldn't have the tests. prefix10:54
zygait's not something I expect to see in any task.yaml10:54
zygaoh? I misread the readme then10:54
zygayeah, I see the fragment now10:54
zyga"commands that expect to be on PATH should follow more speicfic naming conventions"10:55
zygaI'll correct that, it's just a draft :)10:55
zygaso just $TESTSTOOLS/clenaup?10:55
zyga*cleanup10:55
pedronisor state-cleanup10:55
zygaok10:55
zygawe should think about session services more10:55
zygaI think without handling the remove story we should be very careful10:56
zygamborzecki: what do you think about the agent socket10:58
zygaI think this is actually a property of any unit10:58
zygait's just sockets seem worse as "hey, it's there, let me talk to it"10:59
zygaand for non-session stuff we do stop services and sockets so it's not something we've seen before10:59
mvopedronis: I reworked 8762, test is much nicer now and shares a ton. silly me for not thinking about this earlier :)10:59
mborzeckizyga: hmm making /usr/share/fonts/adobe-source-code-pro available inside the snap causes boxes and segfaults :P11:05
zygaawesome11:06
zyganow put that font on a 18.04 vm11:06
zygawhat's the base of the snap you tried?11:06
zygamaybe strace/gdb the app11:06
zygaand get fontconfig-dbg11:06
mborzeckizyga: funny, i don't even use any of that fonts11:06
mupPR 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:06
mborzeckizyga: the backtrace is the same as before https://forum.snapcraft.io/t/gimp-and-glimpse-editor-snaps-segfault-on-arch/1710011:07
zygawhere's the backtrace?11:08
zygathat's just some log11:08
zygatime to take Bit out for a walk11:12
zygaback in a bit11:12
mborzeckizyga: SourceCodeVariable-Roman.otf this font is causing a problem11:12
mborzeckiwodner what's so special about it11:12
zygamborzecki: developers and their fancy pantsy fonts ;)11:12
zygamborzecki: yeah, it's curious11:12
zygaif you can reporduce the crash outside of snaps11:12
zygawe should report those11:12
mborzeckizyga: but i'm not even using this font11:12
zygaand even debug and fix them, if possible11:13
zygamborzecki: so what, it's there11:13
zygait gets scanned11:13
mborzeckiglimpse-editor and gimp segfault, probably because the load up all info about fonts11:13
zygayeah11:13
ogratry inkscape11:13
mborzeckiapps that aren't so interested get boxes?11:13
ografrom the edge channel11:13
zygamborzecki: maybe boxes are for another reason11:13
zygathe cache is corrupted11:13
ograit has this new fancy font handling hack11:13
mborzeckiogra: oh, right11:13
zygatry generating the cache11:13
zygaand see if that crashes11:13
ogratry inkscape first to see if the hack works !11:14
zygamvo: please check this out11:14
zygahttps://github.com/snapcore/snapd/pull/876811:14
mupPR #8768: tests: fix broken snapd.session agent.socket <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>11:14
zyganow really afk11:14
mborzeckiyeah, inkscape edge works11:14
ograawesome11:14
ograit throws some font.conf errors on startup though ... (unknown options) ... but i see it working in zoom as well11:15
mupBug #1881276 opened: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>11:25
pstolowskipedronis: i've updated #8567, let me know if this is what you had in mind. image_linux became slightly ugly11:26
mupPR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>11:26
mborzeckimvo: can you take a look at https://github.com/snapcore/snapd/pull/8766 ?11:29
mupPR #8766: daemon: fix filtering of service-control changes for snap.app <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8766>11:29
mupBug #1881276 changed: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>11:31
ijohnsonmorning folks11:34
mupBug #1881276 opened: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>11:37
mupBug #1881276 changed: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>11:43
mupBug #1881276 opened: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>11:46
mborzeckizyga: so the same font works in ubuntu, even in the same snap on ubuntu11:49
mborzeckii've mounted tmpfs over the fonts cache and /etc/fonts11:49
mborzeckiand it still works, wtf??11:49
zygaHmmmmm11:58
zygaDrop font cache11:58
zygaDoes it crash?11:58
mborzeckino12:04
mborzeckiit's dropped already12:04
mborzeckino /var/cache/fontconfig, no /etc/fonts12:04
ograand ~/.local/fonts ... etc ?12:05
ogra(iirc the desktop launchers pick these up too)12:06
pedronispstolowski: I reviewed #856712:06
mupPR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>12:06
pstolowskipedronis: thanks12:07
pedronisthank you12:07
mborzeckiheh, wiped ~/.cache/fontconfig/ and it's working now12:10
mborzeckidamn, i don't see how we can make it work if there's even a slightest bit of fontconfig cache being shared12:10
ijohnsonmborzecki: 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.Names12:12
mupPR 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:12
mborzeckiijohnson: i clarified in a comment there, what meant by `names` in the comment is inst.Names12:14
mborzeckiijohnson: anyways, i rephrased the comment, please check if it makes sense now12:14
ijohnsonmborzecki: ahhhhh sorry I'm a bit slow this morning it seems12:14
* ijohnson looks now12:14
ijohnsonthank you makes sense now12:14
mborzeckicool12:15
zygamborzecki: so which part of our code makes your ~/.cache/fontconfig available to the snap?12:17
zygamborzecki, mvo: please review https://github.com/snapcore/snapd/pull/8768 to unbreak master12:18
mupPR #8768: tests: fix broken snapd.session agent.socket <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>12:18
mborzeckizyga: desktop-launch copies over the cache from $HOME/.cache/fontconfig, it works because the snap uses `home`12:21
mborzeckizyga: so outside of our control apaprently12:21
zygamborzecki: wait, cannot we block the cache somehow?12:21
zygawe could also add a user mount namespace directory to mask ~/.cache/fontconfig12:21
zygamake it empty12:21
zygaright?12:22
mborzeckizyga: sounds like slippery slope12:22
zygawhy?12:22
mborzeckifeels too fiddly12:22
mborzeckiit's probably ok as some temporar fix12:23
zygabut that's not a good answer :) on one hand side we have crashes and boxes12:23
mborzeckibut it'd really prefer to have the right fix12:23
zygaon the other "feels too fiddly"?12:23
zygasure, what's the right fix?12:23
zyga(I'm with you on that)12:23
zygaI would love to know if it's a specific font12:24
zygaor just any cache12:24
mborzeckizyga: didn't we discuss that? have snaps build their own cache during install, find a way to share that maybe witht the gnome content snap12:24
zygamborzecki: we did discuss that but I think we ought to fix the crashes without requiring all snaps to rebuild12:24
pedronismborzecki: we discusses something like that platform snaps taking care of this for snaps that use them, or possibly individual snaps12:33
pedronis*discussed12:33
mborzeckizyga: hmm, w8, we can't really expand $HOME in user mounts, can we?12:36
zygamborzecki: so, not yet but I kind of wrote a patch for that12:36
mborzeckixD12:36
zyganot sure if you noticed a QFG1 themed tweet a few weekends ago12:36
zygaI added support for all the goodies required to have ~ available12:36
zygatoday is too late but I can post them next week with some cleanups12:37
mborzeckii recall i had a patch for $HOME too at some point, but for some reason we didn't do it12:39
zygait was somewhat fiddly12:39
zygaanyway, I will post it later12:39
mborzeckiperhaps it was aroudn the time of parallel installs and mapping $HOME/snap/foo_bar $HOME/snap/foo ?12:39
cachiozyga, could you please take a look to https://github.com/snapcore/spread/pull/10712:40
mupPR spread#107: Use GitHub actions to test spread <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/107>12:40
cachiozyga, and hi12:40
cmatsuokazyga: 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.png12:40
zygacachio: ah, right you asked me yesterday12:40
zygasure12:40
cachiozyga, thanks a lot12:41
zygacachio: snap changes12:41
mborzeckicmatsuoka: snap changes?12:41
zygaI meant cmatsuoka :)12:41
mborzeckimaybe it'd downloading something and rewriting state.json all the time12:41
cmatsuokazyga, mborzecki: no changes, no logs12:41
mborzeckiwhat was that fs tool12:41
zygathere are _no_ changes12:41
zygamborzecki: which one?12:41
zygaforkstat?12:41
zygaor iotop?12:41
mborzeckizyga: fs<something>stat12:41
cmatsuokai used iotop and fatrace12:42
cmatsuokafatrace interestingly doesn't show anything12:42
mborzeckifnotifystat12:42
zygaah12:42
pstolowskiijohnson: hi! thanks for looking at services PRs12:42
mborzeckicmatsuoka: maybe it's the same problem as https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/183162912:43
mupBug #1831629: snapd hammers SSD for long periods <amd64> <apport-bug> <disco> <snapd (Ubuntu):Expired> <https://launchpad.net/bugs/1831629>12:43
cmatsuokalet me see...12:43
zygacmatsuoka: run forkstat too12:43
zygaI wonder if we fail on something12:43
mborzeckiheh almost standup time12:44
cmatsuokanot much information there but it could be the same thing12:44
zygacmatsuoka: maybe join ho and screen share12:45
zygaI can hop12:45
cmatsuokazyga: yeah, going there12:45
mborzeckistandup ho?12:46
mupPR 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>12:57
mupPR 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:17
mupPR 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:22
mupPR 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:32
mupPR snapd#8770 opened: snap/naming: add ParseSecurityTag and friends <Created by zyga> <https://github.com/snapcore/snapd/pull/8770>13:47
pstolowskizyga: if you have a moment, that's the PR from yesterday: https://github.com/snapcore/snapd/pull/864014:05
mupPR #8640: wrappers: pass 'disable' flag to StopServices wrapper (2/N) <Services βš™οΈ> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8640>14:05
ackkjdstrand_, hi, around?14:36
zygare14:48
zygaback to reviews14:48
zygapstolowski: sure!14:48
zygapstolowski: looks good14:50
zygapstolowski: review sent14:52
pstolowskidziΔ™ki!14:52
zygaproszΔ™ :)14:53
mvo8762 needs a second review14:54
zygacan 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
mupPR #8769: dbusutil: move all D-Bus helpers and D-Bus test helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8769>14:58
zygacachio: that change is somewhat big, I will probably not finish reviewing it today15:08
zygacachio: my mild preference would be to split it up into separate cunks15:08
zygachunks15:08
zygaI don't understand why some things are done; I have a few pending questoins15:08
zyga*questions15:08
cachiozyga, ok, let me check15:09
zygacachio: but please, if you can, open separate PR for the reorg15:10
zygaas 37 changed files is a bit too much to follow coupled with actions15:10
cachiozyga, well, most of the things are just moved15:11
cachioI had to move a test suite15:12
cachioso all the tests are moved15:12
cachionot changed15:12
cachioand it is the same for the prepare in the spread.yaml15:12
zygabut the reason for that move is not clear from the diff or description alone15:12
cachiozyga, I think the best is to split in 215:13
cachiofist github actions15:13
cachiothen in a second pr15:13
cachioput all the migration15:13
cachiozyga, does it make sense?15:13
cachioI just need to revert a commit for that15:13
zygaor the other way around, whatever is easier15:13
zygathe reorg can probably land faster15:14
cachiosure15:14
cachioI'll make it15:14
zygathanks15:14
mupPR 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:17
jdstrand_ackk: hey, yes15:18
=== jdstrand_ is now known as jdstrand
ackkjdstrand, 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:20
ackkjdstrand, no default-provider though, as we don't want to get B automatically installed if A is installed15:21
jdstrandackk: by container interface, you mean content interface?15:21
ackkjdstrand, yes, sorry, muscle memory :)15:21
jdstrandackk: the content interface should autoconnect from the same publisher15:21
jdstrandwithout needing to create a snap decl15:22
pedronisit should happen already, unless there's more than one slot with the same content label15:22
ackkoh, really? I thougth that would only happen for default-provider15:23
* ackk tries15:23
pedronisdefault-provider has zero effects on connections15:24
pedronisit just pulls in the sanp15:24
pedronis*snap15:24
ackkI'm not seeing this with maas and maas-test-db15:24
ackksnap install maas --edge + snap install --channel=2.8 maas-test-db15:24
zygaackk: could you paste the relevant plug and slot definitions from the snap.yaml's15:26
zygasnap.yamls15:26
ackkhttps://paste.ubuntu.com/p/s3R9GcqJRK/ are connections I see after installing as above15:26
ograwow ... looks like we have some racyness15:26
ograhttps://paste.ubuntu.com/p/jQZsVpQy67/15:26
ackkzyga, sure, one sec15:26
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
ackkzyga, https://paste.ubuntu.com/p/wX6C3ZVZfs/15:27
ackkzyga, do names need to match?15:27
zygaI don't think so15:28
zygabtw, do you need write? I think read should suffice for sockets15:28
zygadoes it work if you connect manually?15:28
zyga(can you connect at all, I guess, is the question)15:28
ackkzyga, readonly doesn't work, no15:28
zygaI'd be interested in denials later on15:29
ackkzyga, yes, works fine if I connect it. reason I'm asking is purely to save one extra steps for users15:29
zygado you have other provides of "db-socket"?15:29
zyga(installed)15:29
ackkno15:30
zygado we log anything in snapd.service about tihs?15:30
ackkzyga, I only see this when installing maas-test-db (with maas installed):15:31
ackkMay 29 15:31:22 maas snapd[368]: api.go:985: Installing snap "maas-test-db" revision unset15:32
zygaI see15:32
zygaoh well, someone needs to dig15:32
zygacould you please ping me on Monday15:32
ackkzyga, sure, thanks15:32
zygaI'm wrapping up a branch and I'd like to EOD15:32
zygait's probably something silly15:32
zygaI wonder if we can get better debugging of cases like that15:32
pedronisackk: I installed maas --edge and I don't see the slot15:33
pedronisin the yaml15:33
pedronisor the plug15:33
cachiozyga, updated the pr15:33
ackkweird, lemme see15:33
cachiozyga, about the version of go used to build spread15:34
zygapedronis: I'm preparing the tools reorg pr15:34
pedronisackk: did mean 2.8/edge in your instructions?15:34
cachiowe already are builing with this version15:34
ackkpedronis, I was just testing thatm it seems 2.8/edge does work15:35
cachioso I just put that version on the actions15:35
ackkpedronis, weird, we added that a long time ago and both revisions don't seem far off15:35
pedronisackk: yea, --edge is 2.7/edge and doesn't have any of that15:35
cachiozyga, not sure which kind of comment you would add there15:35
zygacachio: about the significance of that particular version,15:35
ackkpedronis, no, 2.7 doesn't, but --edge should be latest/edge which is based on CI. for some reason it must have been behind15:35
ackksorry for the noise, it seems it works then15:35
zygait's a fixed number, maybe we should test with latest instead?15:36
ackkzyga, ^15:36
ackkzyga, pedronis thanks15:36
zygaackk: woot :)15:36
pedronisackk: no you have a default track, so --edge is 2.7/edge15:36
pedronisif you want latest you need install --channel=latest/edge15:36
mupPR 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:38
ackkpedronis, ah, right! that always tricks me :)15:41
pedroniszyga: I would prefer that we land #8759 and #8691 with some final scaffolding in it first though15:42
mupPR #8759: tests: move *-tool tests to their own suite <Created by pedronis> <https://github.com/snapcore/snapd/pull/8759>15:42
mupPR #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
zygaoh, I forgot about that entirely15:42
* zyga looks now15:42
pedroniszyga: also we need to add TESTTOOLS to debian/tests/integrationtests15:43
pedronisTESTSTOOLS15:43
pedronisor autopkgtests might get broken15:43
zygapedronis: good point, I'll check that15:44
zygapedronis: any specific reason for [[ ]] over regular [ ] ?15:45
pedronisit was used already for something15:46
* zyga Hmm, we only use it for the regexp matching behavior.15:46
pedronisif not super consistent15:50
pedroniswe are not super consistent15:50
pedronisif [[ -d ./mnt ]]15:50
zygapedronis: would you mind if I push a change to convert the additions to [ ] ?15:54
zygaI really like [[ but I prefer to use it only when ther'es no simpler alternative, mainly to remove the "why is this used" question15:55
pedroniszyga: yes, mostly because it has consumed already too many spread cycles15:55
pedronisit can be changed later15:55
zygaok15:55
zygaI'll bundle that in the next PR with tool changes15:55
pedroniszyga: which changes are you doing in that new PR?15:56
zygapedronis: https://github.com/snapcore/snapd/pull/8759/files#r43258218715:58
mupPR #8759: tests: move *-tool tests to their own suite <Created by pedronis> <https://github.com/snapcore/snapd/pull/8759>15:58
zygapedronis: moving tools to tests/lib/tools, adding symlinks to tests/bin, renaming each tool one by one, removing compatibility hacks15:58
zygapedronis: that question I linked to above is the only thing I'd like to understand before approving16:01
pedroniszyga: I answered16:01
pedroniszyga: cleanup-state is a bit too new to know a final answer16:02
zygaok16:02
zyga+116:03
mupPR snapd#8760 closed: systemd: rename actualFsTypeAndMountOptions to hostFsTypeAndMountOptions <Simple πŸ˜ƒ> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8760>16:03
zygalet's merge when it's green16:03
pedroniszyga: 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
mupPR #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:03
pedronisI still would like for it to land first16:04
zygathe readme PR?16:04
pedronisyes16:04
zygayeah, LGTM!16:04
zygait's a draft16:04
zygaplease open it for review16:04
zygawith the TODO merged we can chop parts off it in each commit16:07
zygamaybe mvo can just merge it16:07
zygathere's no point in testing it16:07
zygamvo: ^ could you please merge https://github.com/snapcore/snapd/pull/869116:07
mupPR #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
mvozyga: sure16:07
zygasuper16:07
zygathanks!16:07
mvozyga: should it be promoted to "ready for review" at least?16:08
mvozyga: it's still draft16:08
zygayeah, I think pedronis should do that16:08
pedronismvo: please don't merge it16:08
zygaoh?16:08
mvopedronis: set it to blocked16:08
pedronisas I said I want to do some things in it16:08
zygaah, I missed that16:08
zygaok, in that case I'll review it again when it's open16:08
* zyga EODs and goes for a walk16:12
Saviqhumpf16:36
Saviqhttps://travis-ci.com/github/MirServer/mir/jobs/341502620#L24716:36
SaviqAll snaps up to date.; try to update snapd and refresh the core snap16:36
* cachio lunch16:41
ijohnsonjdstrand: 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
mupPR #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
jdstrandijohnson: the former16:58
ijohnsonjdstrand: sounds good thanks16:58
jdstrandijohnson: but a description change is in order to mention something about controller devices16:58
ijohnsonright16:59
jdstrandijohnson: well, maybe not 'description' like with 'snap interface block-devices', but definitely a code comment above the description and a policy comment16:59
ijohnsonsure17:00
jdstrandijohnson: 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 policy17:01
ijohnsonjdstrand: yes that all makes sense, I'll try to update that this afternoon I think17:01
=== ijohnson is now known as ijohnson|lunch
jdstrand(manipulating a raw device (and its controller) is a significantly different operation than manipulating an individual partition)17:02
jdstrandijohnson|lunch: cool thanks!17:02
jdstrandijohnson|lunch: sorry that it wasn't clear. I had a strong conviction and then convinced myself I was wrong17:03
jdstrand:)17:03
ijohnson|lunchjdstrand: haha yes I know the feeling quite well17:09
=== benfrancis4 is now known as benfrancis
mupPR 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:53
mupPR 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>17:58
mvoquick eyeball on 8772 would be great18:04
mupPR snapd#8772 opened: snap-bootstrap: remove sealed key file on reinstall (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8772>18:08
=== KindTwo is now known as KindOne
pedronismvo: +118:25
mvopedronis: thank you!18:25
pedroniswe are getting mountinfo differences again :/18:26
mvooh no18:26
pedronis2020-05-29T18:07:04.4844746Z -+0:+1 / /sys/fs/cgroup/unified rw,nosuid,nodev,noexec,relatime shared:+1 - cgroup2 cgroup rw,nsdelegate18:26
pedronis2020-05-29T18:07:04.4845221Z ++0:+1 / /sys/fs/cgroup/unified rw,nosuid,nodev,noexec,relatime shared:+1 - cgroup2 cgroup rw18:26
pedronison 18.0418:26
mvomeh, I hope zyga has time to have a look18:27
=== ijohnson|lunch is now known as ijohnson
mupPR 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:28
* cachio afk18:31
mupPR 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:43
cmatsuokacachio: got a new error in opensuse: https://github.com/snapcore/snapd/pull/8591/checks?check_run_id=72148026419:56
mupPR #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
cachiocmatsuoka, checking19:56
pedroniscmatsuoka: I forgot to mention, I will get to review #8591 on Tuesday19:57
cachiocmatsuoka, it is new19:57
cachioI'll research it19:57
cachiothanks for the info19:57
cmatsuokapedronis: ok, thanks19:58
mupPR snapcraft#3149 opened: elf: search dynamic tags within sections, not segment <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3149>21:27

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!