[08:33] PR snapd#8221 opened: ovelord/snapstate: update only system wide fonts cache [10:09] Bug #1866168 opened: Calls to org.freedesktop.DBus.Introspectable get blocked by AppArmor [10:45] PR snapd#8222 opened: wrappers: import /etc/environment in all services [12:10] Bug #1866168 changed: Calls to org.freedesktop.DBus.Introspectable get blocked by AppArmor [12:56] jdstrand: FYI, I noticed we have failures on opensuse that are not captured by spread (though IIRC the systems were disabled recently) [12:56] https://build.opensuse.org/package/live_build_log/system:snappy/snapd/openSUSE_Tumbleweed/x86_64 [12:56] all related to seccomp [12:57] zyga: did they update libseccomp or golang seccomp? if so, sounds like there might be a regression [12:58] jdstrand: they might have, I left all non-ubuntu systems back home [12:58] jdstrand: I'll file a bug to track this down next week [12:58] jdstrand: just FYI in case this shows up in ubuntu [12:58] cool, thanks [12:59] iirc, they did but a new release [12:59] (or are about to...) [12:59] * jdstrand -> meeting [13:00] oh [13:00] oh boy [13:02] zyga: https://github.com/seccomp/libseccomp/commit/fcb1395979f784387984e34752c07a5e8530c023 [13:02] hmm [13:02] thanks [13:03] doesn't seem like what we're seeing [13:03] perhaps it's the kernel too? [13:19] jdstrand: we should eventually look at enabling the binary tree optimizer https://github.com/seccomp/libseccomp/commit/a3732b32b8e67a5c466a625f0e1e0d0bfde5ee0b [13:37] hi, isn't "snap stop --disable ${SNAP_INSTANCE_NAME" supposed to stop all services for the snap? [13:39] ackk: what are you seeing happen? [13:40] (if that's grammatically correct) [13:46] 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] 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] zyga, right after install [14:00] zyga: can you have someone add a meeting link for the compression meeting? [14:00] ijohnson: ^ [14:01] roadmr: ^ [14:01] zyga, side question, I assume there's no way (yet) to tell snapd not to autostart services on install? [14:02] jdstrand: ack [14:03] jdstrand: yes, a sec [14:04] I'm in [14:04] thanks [14:05] jdstrand: O_o [14:06] jdstrand: still waiting for others to arrive (snapd folks) [14:11] I am apparently an idiot :) [14:24] heh [14:31] PR snapcraft#2961 opened: build providers: remove over use of -i in sudo [15:07] ackk: this is a question to ijohnson [15:07] ackk whats the problem [15:07] jdstrand: oh, sorry, I missed your ping [15:07] also I'm at a sprint so intermittently available [15:12] 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] ijohnson, some services are actually running [15:12] 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] ackk: yes it is possible to stop services from starting at all [15:13] ackk: what you do is call `snapctl stop --disable` exactly like you're doing during the _install_ hook specifically [15:13] ackk: the install hook runs before any services are started [15:14] ackk: also note that the install hook does not run on refresh, for that you need to use the post-refresh hook [15:14] ijohnson, I'm doing that in the install hook [15:14] ackk: are you testing this with the snap already installed ? [15:15] the thing I am currently checking on for you is whether you can disable all services with just the snap name [15:15] ijohnson, no, first install [15:15] I don't remember if that works or is supposed to work [15:17] 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] not sure why it's not working in this case [15:17] ackk: I don't think it has ever been the case that services were started before the install hook [15:17] ackk: perhaps you're thinking of the configure hook? [15:19] 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] 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] even if there's just one preset and that preset is "the service is disabled" [15:20] having a way to express that with a common language might be useful [15:21] ijohnson, it used to work, we are using it elsewhere [15:21] ackk: can you show me an example ? [15:21] ijohnson, and indeed if you look at the paste services are all disabled [15:21] of where it used to work ? [15:21] ijohnson, just some of them aren't stopped [15:21] I am confused how it could work [15:22] ijohnson, why wouldn't it? [15:22] snapctl runs those commands at the end of the hook [15:22] ackk: because the install task is and always has been ordered before the start-snap-services task [15:22] this is internal to snapd [15:25] 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] 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] ijohnson, sure, I'll try to get more info and then file it [15:27] ijohnson, thanks [15:41] zyga: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1861177 [15:42] Bug #1861177: seccomp_rule_add is very slow

[15:44] ijohnson: hey, do you have different numbers tacked onto anonymouse dependent on the site login? :) [15:45] anonymouse64, anonymouse67... [15:45] * jdstrand is going to map these out [15:47] jdstrand: yes, it's a long story [15:48] I am both of those [15:48] ijohnson: I've yet to meet anonymouse65. I've heard great things about that guy [15:48] :) [15:49] haha :-) [16:14] PR snapcraft#2961 closed: build providers: remove over use of -i in sudo [16:19] PR snapd#8223 opened: interfaces/u2f: Add Titan USB-C key [17:37] 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] JuJUBee: this is a known limitation [17:38] JuJUBee: such home directories are sadly not supported [17:44] zyga, does https://forum.snapcraft.io/t/how-can-i-use-snap-when-i-dont-use-home-user/3352/2 suggest otherwise? [17:45] 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] you can bind mount it or mount it there [17:45] but it cannot be a symlink [17:46] 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] 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] zyga, so should I just mount the disk that is /homes on /home instead? [18:09] JuJUBee: yes [18:09] JuJUBee: can you also leave me a message as to why you chose this layout [18:09] we will try to support arbitrary home directories better [18:09] but understanding the use cases helps [18:10] zyga, where would you like me to leave it? pm? [18:10] JuJUBee: just here [18:10] I'm getting dinner in 5 minutes [18:10] so I won't respond [18:10] 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] 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.