[08:33] <mup> PR snapd#8221 opened: ovelord/snapstate: update only system wide fonts cache <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8221>
[10:09] <mup> Bug #1866168 opened: Calls to org.freedesktop.DBus.Introspectable get blocked by AppArmor <Snappy:New> <https://launchpad.net/bugs/1866168>
[10:45] <mup> PR snapd#8222 opened: wrappers: import /etc/environment in all services <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8222>
[12:10] <mup> Bug #1866168 changed: Calls to org.freedesktop.DBus.Introspectable get blocked by AppArmor <snapd:New> <https://launchpad.net/bugs/1866168>
[12:56] <zyga> jdstrand: FYI, I noticed we have failures on opensuse that are not captured by spread (though IIRC the systems were disabled recently)
[12:56] <zyga> https://build.opensuse.org/package/live_build_log/system:snappy/snapd/openSUSE_Tumbleweed/x86_64
[12:56] <zyga> all related to seccomp
[12:57] <jdstrand> zyga: did they update libseccomp or golang seccomp? if so, sounds like there might be a regression
[12:58] <zyga> jdstrand: they might have, I left all non-ubuntu systems back home
[12:58] <zyga> jdstrand: I'll file a bug to track this down next week
[12:58] <zyga> jdstrand: just FYI in case this shows up in ubuntu
[12:58] <jdstrand> cool, thanks
[12:59] <jdstrand> iirc, they did but a new release
[12:59] <jdstrand> (or are about to...)
[12:59]  * jdstrand -> meeting
[13:00] <zyga> oh
[13:00] <zyga> oh boy
[13:02] <jdstrand> zyga: https://github.com/seccomp/libseccomp/commit/fcb1395979f784387984e34752c07a5e8530c023
[13:02] <zyga> hmm
[13:02] <zyga> thanks
[13:03] <zyga> doesn't seem like what we're seeing
[13:03] <zyga> perhaps it's the kernel too?
[13:19] <zyga> jdstrand: we should eventually look at enabling the binary tree optimizer https://github.com/seccomp/libseccomp/commit/a3732b32b8e67a5c466a625f0e1e0d0bfde5ee0b
[13:37] <ackk> hi, isn't "snap stop --disable ${SNAP_INSTANCE_NAME" supposed to stop all services for the snap?
[13:39] <zyga> ackk: what are you seeing happen?
[13:40] <zyga> (if that's grammatically correct)
[13:46] <mborzecki> zyga: wonder how different that optimizer is from the patches we've tried in https://forum.snapcraft.io/t/concerns-about-performance/12194/8 is it the same patch?
[13:51] <ackk> zyga, I'm testing a change in the maas snap to split services. I have a "install" hook which ends with that stop command, but then I see: https://paste.ubuntu.com/p/H6V2vXKGCn/
[13:51] <ackk> zyga, right after install
[14:00] <jdstrand> zyga: can you have someone add a meeting link for the compression meeting?
[14:00] <jdstrand> ijohnson: ^
[14:01] <jdstrand> roadmr: ^
[14:01] <ackk> zyga, side question, I assume there's no way (yet) to tell snapd not to autostart services on install?
[14:02] <ijohnson> jdstrand: ack
[14:03] <roadmr> jdstrand: yes, a sec
[14:04] <jdstrand> I'm in
[14:04] <jdstrand> thanks
[14:05] <roadmr> jdstrand: O_o
[14:06] <roadmr> jdstrand: still waiting for others to arrive (snapd folks)
[14:11] <roadmr> I am apparently an idiot :)
[14:24] <jdstrand> heh
[14:31] <mup> PR snapcraft#2961 opened: build providers: remove over use of -i in sudo <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2961>
[15:07] <zyga> ackk: this is a question to ijohnson
[15:07] <ijohnson> ackk whats the problem
[15:07] <zyga> jdstrand: oh, sorry, I missed your ping
[15:07] <ijohnson> also I'm at a sprint so intermittently available
[15:12] <ackk> ijohnson, so my first question is whether this is the correct status (from snap info) when the install hooks runs "snap stop --disable $SNAP_INSTANCE_NAME" at the end: https://paste.ubuntu.com/p/H6V2vXKGCn/
[15:12] <ackk> ijohnson, some services are actually running
[15:12] <ackk> ijohnson, side question was whether it's possible to prevent them from starting up at all at snap install (I know it wasn't, just wondering if there's any progress in that direction)
[15:13] <ijohnson> ackk: yes it is possible to stop services from starting at all
[15:13] <ijohnson> ackk: what you do is call `snapctl stop --disable` exactly like you're doing during the _install_ hook specifically
[15:13] <ijohnson> ackk: the install hook runs before any services are started
[15:14] <ijohnson> ackk: also note that the install hook does not run on refresh, for that you need to use the post-refresh hook
[15:14] <ackk> ijohnson, I'm doing that in the install hook
[15:14] <ijohnson> ackk: are you testing this with the snap already installed ?
[15:15] <ijohnson> the thing I am currently checking on for you is whether you can disable all services with just the snap name
[15:15] <ackk> ijohnson, no, first install
[15:15] <ijohnson> I don't remember if that works or is supposed to work
[15:17] <ackk> ijohnson, I'm pretty sure services used to be started by default before install hook runs. but running stop --disable used to work stopping there
[15:17] <ackk> not sure why it's not working in this case
[15:17] <ijohnson> ackk: I don't think it has ever been the case that services were started before the install hook
[15:17] <ijohnson> ackk: perhaps you're thinking of the configure hook?
[15:19] <zyga> ijohnson, ackk: just thinking about what you guys are discussing, I wonder if there's anything we could learn from systemd presets that could be, somehow, represented in snapd
[15:19] <ijohnson> ackk: AFAICT I don't think `snapctl stop --disable $SNAP_INSTANCE_NAME` should work, I think it always has to be `snapctl stop --disable $SNAP_INSTANCE_NAME.$SVC_NAME`
[15:20] <zyga> even if there's just one preset and that preset is "the service is disabled"
[15:20] <zyga> having a way to express that with a common language might be useful
[15:21] <ackk> ijohnson, it used to work, we are using it elsewhere
[15:21] <ijohnson> ackk: can you show me an example ?
[15:21] <ackk> ijohnson, and indeed if you look at the paste services are all disabled
[15:21] <ijohnson> of where it used to work ?
[15:21] <ackk> ijohnson, just some of them aren't stopped
[15:21] <ijohnson> I am confused how it could work
[15:22] <ackk> ijohnson, why wouldn't it?
[15:22] <ackk> snapctl runs those commands at the end of the hook
[15:22] <ijohnson> ackk: because the install task is and always has been ordered before the start-snap-services task
[15:22] <ijohnson> this is internal to snapd
[15:25] <ijohnson> ackk: so I have tested and actually what you have with `snapctl stop --disable $SNAP_NAME` should work fine, indeed it does in my very simple example snap
[15:26] <ijohnson> ackk: so since you say this isn't working, can you file a bug on bugs.launchpad.net/snapd ? I need to start another meeting shortly and will not be able to debug this much more with you unfortunately
[15:27] <ackk> ijohnson, sure, I'll try to get more info and then file it
[15:27] <ackk> ijohnson, thanks
[15:41] <ijohnson> zyga: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1861177
[15:42] <mup> Bug #1861177: seccomp_rule_add is very slow <patch> <server-next> <snapd:Triaged by anonymouse67> <libseccomp (Ubuntu):Triaged> <https://launchpad.net/bugs/1861177>
[15:44] <jdstrand> ijohnson: hey, do you have different numbers tacked onto anonymouse dependent on the site login? :)
[15:45] <jdstrand> anonymouse64, anonymouse67...
[15:45]  * jdstrand is going to map these out
[15:47] <ijohnson> jdstrand: yes, it's a long story
[15:48] <ijohnson> I am both of those
[15:48] <jdstrand> ijohnson: I've yet to meet anonymouse65. I've heard great things about that guy
[15:48] <jdstrand> :)
[15:49] <ijohnson> haha :-)
[16:14] <mup> PR snapcraft#2961 closed: build providers: remove over use of -i in sudo <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2961>
[16:19] <mup> PR snapd#8223 opened: interfaces/u2f: Add Titan USB-C key <Created by stgraber> <https://github.com/snapcore/snapd/pull/8223>
[17:37] <JuJUBee> I installed a snap application in an LTSP environment.  My user home dir is /home/admin.  My students are /homes/username  I can run the snap app but they cannot.
[17:38] <zyga> JuJUBee: this is a known limitation
[17:38] <zyga> JuJUBee: such home directories are sadly not supported
[17:44] <JuJUBee> zyga, does https://forum.snapcraft.io/t/how-can-i-use-snap-when-i-dont-use-home-user/3352/2  suggest otherwise?
[17:45] <zyga> JuJUBee: no, it's not, it talks about certain things that we could eventually do; today if you want a user to use snaps their home directory must really be (as in directory inode) in /home
[17:45] <zyga> you can bind mount it or mount it there
[17:45] <zyga> but it cannot be a symlink
[17:46] <zyga> the rest about HOMEDIRS is irrelevant for /homes (note the plural) because /homes is invisible from the point of view of a snap application
[17:47] <zyga> it's a long thread but I generally know what happens at runtime and I can only summarize that /homes/$LOGNAME is not supported
[18:09] <JuJUBee> zyga, so should I just mount the disk that is /homes on /home instead?
[18:09] <zyga> JuJUBee: yes
[18:09] <zyga> JuJUBee: can you also leave me a message as to why you chose this layout
[18:09] <zyga> we will try to support arbitrary home directories better
[18:09] <zyga> but understanding the use cases helps
[18:10] <JuJUBee> zyga, where would you like me to leave it?  pm?
[18:10] <zyga> JuJUBee: just here
[18:10] <zyga> I'm getting dinner in 5 minutes
[18:10] <zyga> so I won't respond
[18:10] <zyga> but I'm online 24/7 so I will read it and respond later, if you are available
[18:12]  * zyga is AFK
[18:14] <JuJUBee> zyga, OK, so I usually keep my users on a separate volume so upgrades are easier.  I used to use local_homes for the local admin account and /home for my users but it was easier to use /home during the install and mount the extra volume on /homes after the fact.