[03:09] <mup> PR snapd#7900 opened: tests: do reset of tests during restore and add checks to validate the fs <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7900>
[06:20] <mup> PR snapd#7901 opened: run-checks: check multiline string blocks in restore/prepare/execute sections of spread tests <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7901>
[06:39] <mborzecki> morning
[07:18] <zyga> mborzecki: hello
[07:18] <mborzecki> zyga: hey
[07:34] <mborzecki> zyga: #7901 trivial PR
[07:34] <mup> PR #7901: run-checks: check multiline string blocks in restore/prepare/execute sections of spread tests <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7901>
[08:03] <zyga> mborzecki: thank you and done :-)
[08:03] <mborzecki> zyga: yay :) thx
[08:08] <pstolowski> good morning
[08:08] <mborzecki> pstolowski: hey
[08:14] <mvo> hey pstolowski and mborzecki
[08:14] <mborzecki> mvo:  hey
[08:18] <mvo> sdhd-sascha: 7881 looks like it can land. did you sign the CLA already?
[08:19] <sdhd-sascha> Good morning
[08:19] <sdhd-sascha> mvo: i think i have signed it on launchpad and on some homepage. Not sure if it was the same
[08:21] <mvo> sdhd-sascha: cool, thank you
[08:26] <mup> PR snapd#7881 closed: intrefaces: login-session-control - added missing dbus commands <Created by sd-hd> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7881>
[08:26] <mvo> 7858 looks like an easy win, just needs a second review
[08:28] <mup> PR snapd#7901 closed: run-checks: check multiline string blocks in restore/prepare/execute sections of spread tests <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7901>
[08:44] <zyga> hey mvo
[08:45] <mvo> hey zyga
[08:45] <zyga> sorry for starting late, I had some things at home that needed my time
[08:45] <mvo> thanks mborzecki for the 7899 review!
[08:45] <zyga> I need to work a little over weekend
[08:45] <zyga> and catch up
[08:46] <mborzecki> mvo: np, did't want to commit that whitespace change since travis is already running, we can clean it up when doing some later changes
[08:47] <mvo> mborzecki: yeah, I would prefer to land and fix in one of the followups
[08:50] <mborzecki> mvo: maybe you have permissions to push to https://github.com/snapcore/snapd/pull/7896
[08:50] <mup> PR #7896: interfaces/wayland: Add access to Xwayland's shm files <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7896>
[08:51] <mvo> mborzecki: I have the same issue, look like only Alan can do this :/
[08:51] <mup> PR snapcraft#2797 closed: meson plugin: add support for core20 <Created by sd-hd> <Closed by sd-hd> <https://github.com/snapcore/snapcraft/pull/2797>
[08:52] <mborzecki> oh, well, we'll just have to wait then
[09:02] <mup> PR snapd#7899 closed: many: pass consistently boot.Device state to boot methods <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7899>
[09:05] <Saviq> mborzecki: hey, re: the qemu-img AppArmor denial, does this change look sane https://paste.ubuntu.com/p/k8Shd4WyCP/ (where %3…%4 is the full path to qemu-img) ?
[09:05] <Saviq> should we have "m" for all the executables we want to run?
[09:05] <Saviq> (and why isn't this required on Ubuntu ¿?)
[09:22] <mborzecki> Saviq: does it work on debian with apparmor?
[09:22] <zyga> mborzecki: we don't use apparmor on debian
[09:22] <mborzecki> Saviq: or opensuse for that matter
[09:24] <mborzecki> zyga: it's multipass, and it's classic, from what i can tell, it'll try to use aapparmor when aa_is_enabled returns it's on
[09:25] <zyga> ah
[09:25] <zyga> that's interesting
[09:25] <zyga> more confined than snaps :)
[09:25] <zyga> Saviq: on debian all file rules work the same
[09:29] <mborzecki> zyga: this is what I got on arch yday: https://github.com/CanonicalLtd/multipass/issues/1223
[09:30] <mborzecki> zyga: unclear why it's trying to map qemu-img for reading when there's supposed to be ixr permissions
[09:32] <zyga> looking
[09:32] <zyga> after some kernel version "m" became required as well
[09:34] <pedronis> mvo: thanks for landing my PRs, hope they weren't too confusing ...
[09:38] <mup> PR snapd#7889 closed: overlord,o/snapstate: make sure we never leave config behind <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7889>
[09:38] <pstolowski> pedronis: hi, #7658 is ready for you re-review if you have a moment
[09:38] <mup> PR #7658: cmd/snap-preseed: add snap-preseed executable <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
[09:40] <pedronis> pstolowski: thx, saw that
[09:40] <mvo> pedronis: no, great stuff, I'm in the weeds of uc20 right now
[09:41] <mborzecki> Saviq: ok, got something that works https://paste.ubuntu.com/p/mV9fR5M3hf/
[09:41] <mborzecki> Saviq: and looks like stderr may not be redirected when you're running qemu-img
[09:42] <mborzecki> Saviq: /snap is a symlink on arch & fedora
[09:46] <mborzecki> Saviq: ok, added a note too
[09:46] <pedronis> I created the Done 2.44 lane
[09:47] <Saviq> mborzecki: thanks!
[09:51] <mup> PR core20#16 opened: bootstrap from locally build snapd snaps too <Created by mvo5> <https://github.com/snapcore/core20/pull/16>
[09:57] <mup> PR snapd#7893 closed: daemon,snap: remove screenshot deprecation notice <Created by robert-ancell> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7893>
[10:10] <sdhd-sascha> Why does the x11 interface has no support to access: @/tmp/.X11-unix/X[0-9]*
[10:10] <sdhd-sascha> In the plug-case
[10:10] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/7658#pullrequestreview-331769593
[10:10] <zyga> sdhd-sascha: looking
[10:10] <mup> PR #7658: cmd/snap-preseed: add snap-preseed executable <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
[10:11] <sdhd-sascha> zyga: i see, there is access to Xauthority. But sway's source want to access the socket.
[10:11] <zyga> sdhd-sascha: did you look at abstractions/X?
[10:11] <pstolowski> zyga: thanks!
[10:11] <sdhd-sascha> zyga: wait
[10:11] <zyga> sdhd-sascha: there are include rules in that snippet
[10:11] <zyga> sdhd-sascha: those go to /etc/apparmor.d/abstractions/X
[10:11] <zyga> I suspect it is handled there
[10:12] <zyga> pstolowski: description of https://github.com/snapcore/snapd/pull/7658 seems out of date, it sets SNAPD_PRESEED, not SNAPD_PREBAKE_IMAGE
[10:12] <mup> PR #7658: cmd/snap-preseed: add snap-preseed executable <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
[10:17] <pedronis> pstolowski: I made a countercomment to zyga comment about the help.
[10:20] <zyga> pedronis: the long description will never capture everything that is done by the implementation, nor should it, it should just be comprehensible
[10:21] <zyga> there are better places to capture details, like man pages for example
[10:21] <zyga> pedronis: but that's a minor point, I didn't block or intend to block over that
[10:26] <pedronis> I made a middle ground suggestion
[10:27] <mborzecki> pedronis: this could use your input too https://bugs.launchpad.net/snapd/+bug/1856063
[10:27] <mup> Bug #1856063: snap set refresh.hold immediately triggers a refresh when set <snapd:Confirmed> <https://launchpad.net/bugs/1856063>
[10:27] <mborzecki> pedronis: perhaps we should also set up automatic 2h refresh.hold for core devices too
[10:28] <pedronis> mborzecki: no but open to other options
[10:28] <pedronis> mborzecki: it's by design that core images try to refresh as soon as possible
[10:30] <pedronis> mborzecki: multipass images are a bit of a odd case, because of how they tend to be used
[10:30] <mborzecki> pedronis: maybe something we could do from cloud-init level?
[10:31] <pedronis> maybe
[10:34] <pedronis> mborzecki: anyway I put some guardrails comment in the bug
[10:34] <mborzecki> pedronis: cool, thanks!
[10:43] <pedronis> me just noticed a different papercut
[10:54] <sdhd-sascha> zyga: ah, and there it is again.
[10:54] <sdhd-sascha> Before i start to hack 'snapd', a RFC could be nice. I need to split X11 into a X11-provider and a X11-consumer. To make things work.
[10:54] <zyga> sdhd-sascha: why?
[10:54] <zyga> sdhd-sascha: provider is the slot, consumer is the plug
[10:55] <zyga> sdhd-sascha: they have separate properties
[10:55] <sdhd-sascha> zyga: sway can run under X11, then the abstraction/X is enough
[10:55] <sdhd-sascha> but currently it creates a X11 socket...
[10:55] <sdhd-sascha> so i need the slot permissions, too
[10:55] <zyga> sdhd-sascha: if it creates an x11 socket in a common path it needs to have an x11 slot
[10:55] <zyga> sdhd-sascha: but is it a generic x11 server?
[10:55] <sdhd-sascha> yes, but both didn't work
[10:55] <sdhd-sascha> it's Xwayland inside X
[10:56] <zyga> sdhd-sascha: should it make sense to connect an app to sway instead of to the system x11 slot?
[10:56] <sdhd-sascha> inside sway
[10:56] <sdhd-sascha> i run on a system, without any gui
[10:56] <sdhd-sascha> i have no system x11 slot there
[10:56] <sdhd-sascha> sway snap is the only desktop
[10:56] <zyga> sdhd-sascha: I don't know the answers to my questions but I just want to highlight that splitting any interface into a -provide and -consumer is bad idea because it is already part of the existing design
[10:56] <zyga> sdhd-sascha: then you just should have an x11 slot IMO
[10:57] <ogra> you should probably talk to the guys in #mir-server ;)
[10:57] <ogra> (the mir-kiosk snap supports XWayland (in fact all apps use i3wm by default for fullscreen)
[10:57] <sdhd-sascha> Well, i can look if the slot permission are good enough to work as plug too
[10:57] <ogra> )
[11:04] <mup> PR snapd#7902 opened: o/hookstate/ctlcmd: fix command name in snapctl -h <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7902>
[11:04] <pedronis> that's the papercut fix
[11:07] <sdhd-sascha> Hey, if the slot permission is not enough. Then i could change to allow same names of slot and plug. E.g. allow X11 as slot and X11 as plug in the same snap. Or ?
[11:09] <sdhd-sascha> ogra: thanks, i joined to #mir-server
[11:09] <pedronis> pstolowski: thx for the review, I just noticed this randomly
[11:11] <mborzecki> https://bugs.launchpad.net/snapd/+bug/1856073 is interesting, systemd records the state of failed service unit and keeps it around even after the unit is gone, imo it's kind of useful, and don't think we should do anything about that
[11:11] <pstolowski> yw
[11:11] <mup> Bug #1856073: Failed service state recorded by systemd even after snap removal <snapd:Confirmed> <https://launchpad.net/bugs/1856073>
[11:15] <pedronis> mborzecki: when does it forget though? next boot? never?  or are we missing a daemon-reload?
[11:16] <mborzecki> pedronis: when one runs reset-failed or next boot (maybe reexec too)
[11:16] <pedronis> ok
[11:17] <pedronis> mborzecki: yea, I agree we shouldn't go to out of our ways to change this, unless it creates problems if you reinstall the snapd or if it was a missing daemon-reload
[11:17] <pedronis> s/snapd/snap/
[11:27] <zyga> mborzecki: it is useful, we can look at why snap install failed because services failed to start :)
[11:28] <zyga> pedronis: there's a command to explicitly forget
[11:28] <zyga> pedronis: otherwise it forgets on reboot, it's only in memory
[11:43] <Saviq> zyga: is /var/lib/snapd stable across distros?
[11:44] <Saviq> (for the /snap symlink)
[11:45] <zyga> Saviq: yes
[11:45] <zyga> Saviq: (thank god :D
[11:46] <Saviq> indeed
[11:46] <zyga> Saviq: not sure how it relates to /snap symlink, do you mean the /var/lib/snapd/snap symlink?
[11:46] <zyga> (the one that points there)
[11:46] <mborzecki> zyga: we haven't checked hannah montana linux though ;)
[11:46] <zyga> Saviq: then indeed that is stable :)
[11:46] <Saviq> zyga: I mean /snap → /var/lib/snapd/snap, yes
[11:46] <zyga> Saviq: that's 100% stable
[11:47] <zyga> mborzecki: :-)
[11:47] <zyga> mborzecki: cannot wait for a distro /apps and /system
[11:47] <mborzecki> zyga: don't you have one right now? :P
[11:47] <mborzecki> not exacly linux though
[11:48] <zyga> mborzecki: no, it's /Applications ;-) and it can be localized
[11:48] <zyga> (but without changing the filesystem)
[11:54] <zyga> jdstrand: (just FYI) https://github.com/snapcore/snapd/pull/7875#discussion_r357611665
[11:54] <mup> PR #7875: interfaces: refactor path() from raw-volume into utils with comments for old <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7875>
[11:55] <zyga> degville: I don't know if you ever worked with i18n in software, if you did it's old news, if you didn't you may find that interesting
[11:57] <degville> zyga: thanks for the link - I did, briefly, when I was writing my own stuff, never from a real docs perspective.
[11:58] <degville> and that was with Qt, which had a very set way of doing things.
[12:12] <zyga> brb, need to get coffee and warm up
[12:12] <zyga> I'm so cold this week :/
[12:14] <pokk> zyga: it's been around 0 and raining here for a month, not to mention that the sun barely comes up at all :| I hate this time a year
[12:15] <ogra> zyga, you should move to spain !
[12:24] <zyga> pokk: indoors? :) ?
[12:24] <zyga> pokk: my office is not insulated very well so it's ... very fresh in the morning
[12:25] <pokk> zyga: nah, we're used to cold weather so indoors it's decently warm. I'd much prefer -20 over this to be honest
[12:25] <zyga> pokk: where are you based if I may ask?
[12:26] <zyga> pokk: here it's around 3-7C during daytime and -1-ish at night
[12:28] <pokk> zyga: Sweden
[12:29] <zyga> pokk: ah, I guess you don't build uninsulated anything, unlike us here
[12:30] <mup> PR snapd#7903 opened: overlord,boot: follow ups to #7889 and #7899 <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7903>
[12:31] <mup> PR snapd#7902 closed: o/hookstate/ctlcmd: fix command name in snapctl -h <Simple 😃> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7902>
[12:33] <pstolowski> pedronis: hey, i may need to discuss with you some aspects of services once again, it shouldn't take long. do you have a moment today?
[12:34] <zyga> pedronis: that follow-up is just extra test, right?
[12:34] <zyga> pedronis: looks good, just wanted to make sure I understand it
[12:36] <pedronis> zyga: yes, just doing the thing people ask to improve the test
[12:36] <zyga> understood
[12:36] <zyga> thanks
[12:39] <pedronis> pstolowski: maybe just after standup
[12:39] <pstolowski> pedronis: great
[12:44] <pedronis> mborzecki: 7903 is probably for you when you have a moment (it's not urgent and it's small)
[12:48] <pokk> zyga: no, not really. Especially not the more newly built houses. We can take -30C without much problem here
[12:48] <pedronis> degville: how should I submit comments for the glossary ?
[12:49] <degville> pedronis: would it help if I paste it into a gdoc? or you can make the edits yourself, or leave a comment on the posts. Whichever is easiest for you.
[12:50] <pedronis> degville: I just skimmed for now, I'll know more when I have done a good read through, I'll let you know (probably actually not today)
[12:50] <pedronis> degville: thanks for it btw
[12:51] <degville> pedronis: no problem, thanks!
[12:51] <degville> I'm still adding things.
[12:52] <pedronis> degville: a quick thing though, I think you go the description of core and core16 reversed, core is the one that includes snapd
[12:52] <pedronis> s/you go/you got/
[12:52] <degville> pedronis: oops, thanks!! I'll fix that now.
[12:52] <pedronis> core16 doesn't carry it and is not stable/done yet, that part is correct
[13:01] <zyga> brb
[13:08] <om26er> Hi! Is sergiusens off today (or is it the timezone difference he is not online ?)
[13:09] <om26er> I need to talk about https://github.com/snapcore/snapcraft/pull/2843 and know if that change is acceptable in principle
[13:09] <mup> PR snapcraft#2843: snap: only ship .pyc files, strip shared objects <Created by om26er> <https://github.com/snapcore/snapcraft/pull/2843>
[13:09] <zyga> re
[13:10] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/7875 is close and needs a small amount of iteration from you to land
[13:10] <mup> PR #7875: interfaces: refactor path() from raw-volume into utils with comments for old <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7875>
[13:12] <pedronis> om26er: he is off until next year, maybe cjp256 can help
[13:19] <cjp256> om26er: it's an interesting one! it was in my queue to look at more closely today, but it's something sergiusens will certainly be opinionated about.  :D
[13:22] <mup> PR snapd#7896 closed: interfaces/wayland: Add access to Xwayland's shm files <Created by AlanGriffiths> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7896>
[13:28] <om26er> cjp256 cool, we could have something similar for the python plugin as well, that will likely reduce the size of python based snaps
[13:30] <ogra> om26er, while that is really cool, it should be handled via a snapcraft.yaml option though
[13:31] <om26er> ogra I was writing a message to you to get your opinion as you had wrote on the forum about a similar topic
[13:31] <om26er> ;-)
[13:32] <ogra> i love the approach ... but as i said, it shuld be configurable ...
[13:34] <om26er> ogra the above proposed change is only for Snapcraft package itself. I will investigate into the python plugin and figure out how to do that for it, so other snaps could use that feature as well
[13:34] <ogra> (you might want to build an "arch all" python snap that only ships .py files by default ... i.e. the exact opposite)
[13:34] <ogra> ah,  thought it was for the plugin actually
[13:34] <ogra> *I thought
[13:39] <cjp256> i agree
[13:39] <cjp256> ogra: i would have guessed the pyc was platform independent?  is that not the case?
[13:40] <ogra> dunno, can you run a pyc file compiled on armhf on an amd64 machine ? i never tried
[13:41] <ogra> specially if it comes to HW related stuff like talking to sensors etc i suspect there are many arch specifics in the backend
[13:41] <ogra> *especially
[13:41] <om26er> pyc are platform independent...
[13:42] <ogra> k
[13:44]  * om26er is working on a story on how he reduced a snap size by more than 60%
[13:44] <om26er> stripped shared objects, only shipped pyc files and by using Python 3.6 from core18
[13:44] <cjp256> i left my comments in the PR, but generalized stripping should be a flag soon enough (it's on my todo list).  and I think it would be interesting to provide a flag for the *.py code, under circumstances we know it'd be OK
[13:46] <om26er> for the last it was only a matter of adding /snap/core18/current/usr/bin to PATH.
[13:46] <om26er> wonder if snaps are mounted at a different mount point on other distros ?
[13:47] <cjp256> what was core18 added to path for?
[13:47] <om26er> thanks cjp256, I will take a look
[13:48] <om26er> cjp256 to reuse python3 from there instead of shipping a copy with my snap (saves 7mbs)
[13:48] <cjp256> ah, well that's where I think you might run into problems if shipping only pyc
[13:49] <cjp256> if core18 updates with a patched python that's somehow incompatible with the separately shipped pyc?
[13:49] <ogra> om26er, other distros might use some dir under /var/lib instead of /snap ...
[13:50] <ogra> /snap is very ubuntu specific
[13:54] <mup> PR snapd#7904 opened: snapcraft.yaml: add type, build-base and adopt-info, rm builddeb plugin <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7904>
[13:55] <om26er> will figure out a solution for that, likely by looking at $SNAP and finding core18 directory relative to that
[13:56] <om26er> @cjp256 that's indeed a challenge but I am hoping python in core won't have any API breaking changes, though I need to read a bit more into this to get an idea of how probably a failure is
[14:12] <Saviq> mborzecki: would you please try https://github.com/CanonicalLtd/multipass/pull/1228#issuecomment-565418688 out when you have a moment?
[14:12] <mup> PR CanonicalLtd/multipass#1228: [utils] resolve symlinks to snap directories (Fixes #1223) <Created by Saviq> <https://github.com/CanonicalLtd/multipass/pull/1228>
[14:12] <Saviq> zyga, if you have something like Debian or Fedora on hand, that would be great, too ↑
[14:13] <mborzecki> Saviq: nice, you collect the build artifacts!
[14:15] <Saviq> mborzecki: yeah, it was just too tiring to have to rebuild locally all the time :)
[14:15] <Saviq> you're welcome to some code https://github.com/CanonicalLtd/multipass/blob/master/tools/report_build.py :)
[14:16] <Saviq> pretty simple to use, too https://github.com/CanonicalLtd/multipass/blob/master/.travis.yml#L139
[14:37] <mup> PR snapd#7903 closed: overlord,boot: follow ups to #7889 and #7899 <Simple 😃> <Created by pedronis> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7903>
[14:44] <ijohnson> pstolowski: do you want me to just push to your snapcraft.yaml branch then? I think the only thing my branch has that yours doesn't is removal of the x-builddeb plugin
[14:45] <pstolowski> ijohnson: nope, it's fine, go ahead with yours (minus type:)
[14:45] <ijohnson> pstolowski: ack thanks, I think I might take a few of your changes to the tests though that I missed when writing it yesterday
[14:45] <ijohnson> thanks!
[14:46] <pstolowski> ijohnson: fyi, my branch incorporated some old changes from cmatsuoka, so it's really a team effort ;)
[14:47] <ijohnson> :-)
[14:47] <ijohnson> I will credit both of you in my commit message
[14:49] <ijohnson> sil2100: hey I was wondering about the UC images we have on cdimage, I'm wondering specifically what's the difference between http://cdimage.ubuntu.com/ubuntu-core/18/current/ and http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/ ? the former seems regularly updated, but the latter hasn't been updated since august
[14:49] <ijohnson> (also let me know if you're the wrong person to ask about this)
[14:51]  * cachio lunch
[14:55] <mborzecki> Saviq: looking good, i was able to launch an instance
[14:56] <Saviq> mborzecki: cool, can you try a mount, too, please?
[14:58] <mborzecki> Saviq: mount failed: Error enabling mount support in 'lasting-mara' but nothing in dmesg, so probably not AA related
[14:58] <mborzecki> Saviq: any way to get some info why it failed?
[14:58] <Saviq> mborzecki: journal for snap.multipass*
[14:58] <Saviq> It try again with -vvv
[14:58] <Saviq> *Or
[14:59] <mborzecki> Saviq: https://paste.ubuntu.com/p/5M9QQsCZyQ/
[14:59] <mborzecki> oh, and i need sshfs?
[15:01] <sil2100> ijohnson: hey, so the ones in the main directory are dailies built against edge, while all the others are built per given channel
[15:01] <Saviq> mborzecki: in the instance, that is installed automagically, and also it should have continue regardless of the profile failing to load, since we skip AA on that…
[15:01] <Saviq> so fix is incomplete
[15:01] <mborzecki> Saviq: what follows is: gru 13 15:58:45 galeon multipassd[897299]: Failed to install 'sshfs', error message: ''
[15:01]  * Saviq just got a fedora VM so should be able to repro
[15:02] <sil2100> ijohnson: so the stable/ ones are built with stable snaps, and we currently only build those before every point-release actually
[15:02] <Saviq> mborzecki: ah, so that's the real problem… wonder why, can you try `sudo apt install sshfs` inside the instance?
[15:02] <sil2100> ijohnson: we have daily images built against edge (so the ones in /) and against beta (so the ones in /beta)
[15:02] <mborzecki> Saviq: ah, i've launched ubuntu core, let me try the regular distro
[15:03] <Saviq> mborzecki: right, that would be it, oof
[15:03] <Saviq> (we're working on a static sshfs snap to work on Core, too)
[15:04] <Saviq> https://snapcraft.io/install/multipass/fedora this is so awesome :D
[15:04] <mborzecki> Saviq: hmm some trouble when stopping the vm https://paste.ubuntu.com/p/ktdPWR7XCX/
[15:05] <Saviq> mborzecki: it stopped, didn't it? ;P
[15:05]  * Saviq will try to stop Core
[15:08] <mborzecki> Saviq: you want  /{,var/lib/snapd/}snap/core18/*/{,usr/}lib/@{multiarch}/{,**/}*.so* rm, in those profiles instead of {,/var/lib/snapd/}/snap
[15:08] <mborzecki> Saviq: otherwise the parser complains
[15:09] <Saviq> mborzecki: aha, /me fixes
[15:09] <Saviq> probably why it failed to load
[15:12] <Saviq> error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
[15:12] <Saviq>        /tmp/sanity-mountpoint-875787176: unknown filesystem type 'squashfs'.
[15:12] <Saviq> hrmf
[15:17] <mborzecki> Saviq: multipass mount $PWD/spread-mini saving-chamois:~/foo kind of worked (despite apparmor), but I got an unexpected path in the vm, basically $HOME/~/foo :)
[15:19] <Saviq> mborzecki: well, it did what you asked it to do ;P
[15:20] <mborzecki> Saviq: heh, right, presumptions about rsync/ssh like path handling
[15:21] <Saviq> mborzecki: please file an issue if you can (I can, too), we should fix
[15:27] <mborzecki> Saviq: there you go: https://github.com/CanonicalLtd/multipass/issues/1230
[15:27] <Saviq> mborzecki: 👋
[15:28] <Saviq> not trivial since we'll need to resolve this inside the instance
[15:32] <mvo> sil2100: do you think you could look at https://github.com/snapcore/core20/pull/16 ?
[15:32] <mup> PR core20#16: bootstrap from locally build snapd snaps too <Created by mvo5> <https://github.com/snapcore/core20/pull/16>
[15:32] <mvo> sil2100: this would unblock uc20 image creation
[15:35] <mup> PR snapd#7905 opened: snap-bootstrap: actually parse snapd_recovery label <Created by xnox> <https://github.com/snapcore/snapd/pull/7905>
[15:48] <mup> PR core20#17 opened: Drop encoding digits in units and code paths.  <Created by xnox> <https://github.com/snapcore/core20/pull/17>
[15:53] <ijohnson> sil2100: would it be a lot of work to build the current/stable images everytime there's a stable updated to any of the included snaps for core images? i.e. for UC18, rebuild on core18, snapd, (and pc or pc-kernel on the 18/stable tracks) ?
[16:09] <sil2100> mvo: looking!
[16:09] <sil2100> mvo: btw. uc20 dailies are now up
[16:09] <sil2100> http://cdimage.ubuntu.com/ubuntu-core/20/
[16:10] <mvo> sil2100: thank you!
[16:10] <mvo> sil2100: nice
[16:12] <sil2100> ijohnson: hmm, well, we don't have such automation right now, we did plan on adding something like that at one point, but nothing available yet
[16:12] <sil2100> ijohnson: it's certainly possible
[16:13] <sil2100> Just needs cycle for someone to sit down on it
[16:17] <mup> PR pc-amd64-gadget#26 opened: Use the correct name for the recovery_system label <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/26>
[16:23] <pstolowski> zyga, pedronis updated #7658
[16:23] <mup> PR #7658: cmd/snap-preseed: add snap-preseed executable <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
[16:23] <pedronis> pstolowski: thx
[16:24] <cachio> ijohnson, hey, you already commented on this one https://bugs.launchpad.net/snapd/+bug/1855155
[16:24] <mup> Bug #1855155: snap install hangs if internet is disconnected exactly right after err upload starts <snapd:New> <https://launchpad.net/bugs/1855155>
[16:24] <cachio> ijohnson, any priority to set?
[16:27] <ijohnson> cachio: sure I'll set the priority, it's low I think
[16:27] <cachio> nice,
[16:28] <cachio> I'll update it in that case
[16:36] <ijohnson> sil2100: it's not critical by any means, just would be nice to have since that's what multipass uses to boot images from and they are always out of date so you boot a new UC VM and it immediately needs to reboot twice for snap updates
[16:40] <mup> PR snapcraft#2844 opened: Add punctuation rule for comments <Created by hellsworth> <https://github.com/snapcore/snapcraft/pull/2844>
[17:00] <zyga> pstolowski: ack, looking
[17:09] <zyga> cachio: hey
[17:10] <zyga> cachio: wanted to share a sneak peak
[17:10] <zyga> https://www.irccloud.com/pastebin/Km7d1ouy/
[17:10] <cachio> zyga, looking
[17:11] <cachio> zyga, what is that?
[17:11] <zyga> https://www.irccloud.com/pastebin/KfXWwBsb/
[17:11] <zyga> cachio: iteration on the leak detector, generalized
[17:11] <cachio> zyga, nice
[17:12] <cachio> zyga, is there a PR with it?
[17:12] <zyga> cachio: the tool doesn't know anything about mountinfo, it has pluggable invariant helpers that can check anything
[17:13] <zyga> cachio: not yet, I'll make one soon but the tool grew a little since I started and I have some more tests to write
[17:13] <zyga> cachio: I may start a new mini-project for it so that it is easier to iterate separately from snapd
[17:13] <zyga> cachio: (snapd can have a snapshot that we are happy with)
[17:13] <cachio> zyga, nice
[17:14] <zyga> cachio: it's also nice interactively, show-event can invoke the pager automatically, there's tab completion, it's robust in case of corrupt data, etc
[17:14] <zyga> cachio: event log is really cool, just give me a sec to collect one from snapd run
[17:14] <cachio> zyga, which project is that?
[17:15] <zyga> cachio: I haven't made one yet
[17:15] <cachio> a personal is gonna be?
[17:15] <zyga> cachio: it's essentially on my laptop for the past two days
[17:15] <cachio> ahh
[17:15] <zyga> cachio: I think so, it's easier this way
[17:15] <cachio> zyga, when you have something to share just ping me, I'd like to use it
[17:16] <cachio> at least to play a bit
[17:16] <zyga> cachio: I'd love to plug your package leak detector
[17:16] <zyga> cachio: yeah, I'll make sure to push whatever I have by EOD today
[17:16] <cachio> zyga, great, thanks!!
[17:16] <zyga> :)
[17:20] <cachio> mvo, if you have 5 minutes, could you take a look to this one? 7851
[17:21] <cachio> so we can merge it within 2.43
[17:30] <zyga> cachio: event log from a partial run
[17:30] <zyga> https://www.irccloud.com/pastebin/0jxLFhu1/
[17:31] <zyga> the -- messages show changing attributes
[17:32] <cachio> zyga, nice
[17:32] <cachio> this + -show-output you have the whole picture
[17:34] <zyga> show-output?
[17:34] <zyga> as in output from the test?
[17:34] <cachio> no
[17:34] <cachio> this is something that spread2 provides
[17:34] <zyga> aha
[17:34] <zyga> cool
[17:34] <zyga> what does it do?
[17:35] <cachio> with all the details of hte execution in the remote host
[17:35] <cachio> the output got from ssh
[17:35] <cachio> displayed on real time
[17:36] <zyga> I see, that's cool
[17:36] <cachio> I use it a lot for debug
[18:09] <zyga> https://www.irccloud.com/pastebin/YnJQbOAR/
[18:09] <zyga> cachio: ^
[18:09] <zyga> events from this failed run https://www.irccloud.com/pastebin/TnEbAUhC/
[18:10] <cachio> zyga, nice, same outoput than the pr
[18:10] <cachio> some tests failing
[18:12] <cachio> zyga, did you test is in a board?
[18:12] <zyga> cachio: no, not yet
[18:13] <zyga> cachio: I'm testing it in a side project with spread
[18:13] <zyga> cachio: and in snapd
[18:13] <zyga> cachio: though on a board it would be even more cool as the test history accumulates and you can see what past test may have done more clearly
[18:14] <cachio> zyga, how do you set the invariants to validate?
[18:14] <zyga> cachio: there are several ways, the image can ship them in a few locations (/usr, /usr/local, /run)
[18:14] <zyga> cachio: there's also awareness of $SPREAD_PATH so the project can ship some more
[18:15] <zyga> cachio: in particular $SPREAD_PATH/tests/lib/testbed-invariants is looked at as well
[18:15] <zyga> cachio: any executable file there is used
[18:15] <cachio> zyga, nice
[18:15] <zyga> cachio: there's a priority where /run overrides, project which overrides os system
[18:16] <zyga> cachio: there's a simple protocol where a tool is invoked with an option that points it where to store data
[18:16] <cachio> cool
[18:16] <zyga> cachio: and a few commands to implement (status, set-baseline, has-baseline, compare) and expected behaviuor (either return a status code or print something to stdout)
[18:17] <zyga> cachio: earlier I wrote a few such tools but all in one monster shell script and I abandoned that
[18:17] <zyga> cachio: now each can be written in any language
[18:17] <cachio> zyga, hehehe
[18:17] <zyga> cachio: and testbed-tool itself is in python
[18:18] <zyga> cachio: the one used here, mountinfo, is a small shell wrapper around mountinfo-tool
[18:18] <cachio> zyga, would be nice to integrate it on our tests in some way
[18:18] <zyga> cachio: I integrated it with our spread startup logic in a branch of snapd
[18:18] <zyga> cachio: it hooks into the right spots
[18:18] <zyga> cachio: tests are entirely unaffected
[18:19] <zyga> cachio: tests _can_ hook into this as well, if there's a particular reason
[18:19] <zyga> cachio: e.g. a test may want to say it will do something "persistent" like re-package the core snap or modify the disk image or whatever
[18:19] <cachio> zyga, nice, well it is an easy way to check invariants
[18:20] <zyga> cachio: you might have noticed that the test log is carried over the re-imaging we do in ubuntu-core-* targets
[18:20] <zyga> cachio: so you see what happened in ubuntu-classic and what happened after booting into the core image
[18:21] <cachio> nice
[18:21] <cachio> that's really useful
[18:21] <cachio> now that we are going to create uc20
[18:21] <cachio> tests
[18:21] <zyga> yeah
[18:21] <zyga> :)
[18:22] <zyga> not ready for prime time yet but it's close
[18:23] <cachio> zyga, hehehe
[18:23] <zyga> cachio: the log format is also human readable but supports fancy features like timestamps, custom key=value attributes and more
[18:23] <zyga> cachio: and in emergency you can even echo >> to it
[18:23] <zyga> cachio: and the log viewer handles that
[18:25] <cachio> wow
[18:26] <cachio> the fact it shows the timestamp is really nice
[18:28] <zyga> cachio: I only format the hours/minutes but since we have everything we can detect time rollback, huge jumps and adjust the display accordingly
[19:14] <mup> PR snapd#7092 closed: packaging: use snapd type and snapcraft 3.x <⛔ Blocked> <Created by stolowski> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7092>
[21:07] <mvo> cachio: re 7851> sorry, didn't managed to review thta yet
[21:07] <cachio> mvo, np
[21:07] <cachio> next monday
[21:07] <cachio> enjoy your weelend
[21:07] <mvo> cachio: yeah, thank you! you too
[21:24] <mup> PR pc-amd64-gadget#26 closed: Use the correct name for the recovery_system label <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/26>
[22:53]  * zyga EODs