=== alazred_ is now known as alazred [07:21] PR snapd#8851 opened: interface/fwupd: add more policies for making fwupd upstream strict [07:31] PR snapd#8852 opened: asserts: introduce new assertion validation-set [07:36] PR snapd#8853 opened: asserts: introduce the concept of sequence-forming assertion types [08:51] PR snapd#8849 closed: tests: fail in setup_reflash_magic() if there is snapd state left === alazred_ is now known as alazred [10:47] PR snapd#8755 closed: tests: fix classic ubuntu core transition auth [11:02] PR snapd#8854 opened: sysconfig/cloudinit: make callers of DisableCloudInit use WritableDefaultsDir [12:38] mwhudson, do you still care for console-conf ? ... https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1881588 [12:38] Bug #1881588: pre-seeding lxd on Core appliances breaks console-conf user creation [12:45] ogra: that's probably one for xnox these days [12:53] ah, i didnt know he took over console-conf [12:54] (specifically for xenian/bionic where it isnt a snap yet) [12:54] *xenial [13:01] ijohnson: standup ? [13:01] ijohnson: huh. mwhudson is still subiquity lead [13:04] ogra: it is related to the previous stuff on forums etc. "there is no way to create system users/groups for a snap to use"? and/or now it is possible, but breaks other pieces of snapd? [13:06] xnox, no it is related to a combination of "pre-seeding lxd in an appliance creates a user" .... and ... "console-conf refuses to create a user if /var/lib/extrausers/passwd containe any entry (instead of just checking the "managed" state of the system)" [13:06] *contains [13:08] there is some hardcoded hackery in snapd or the lxd snap that allows it to create the lxd user on install ... console-conf notes that the extrausers db has a user (even though not the system user) and falls flat on its face [13:09] as ian described in the bug, console-conf should not check the passwd db with blind assumptions but simply check the "managed" state of the system ... that indicates a prope core system-user has been created [13:09] *proper [13:12] ogra: # TODO: use proper snap APIs. [13:12] xnox, TODO for whom ? [13:12] ogra: is the proper snap API to query "managed" state? [13:12] i cant release a bunch of appliance i'm working on because of this [13:12] ogra: that's a code comment right next to parsing of the /var/lib/extrausers/passwd, in console_conf [13:12] oh, yeah [13:12] there is an API [13:12] hah ! [13:13] xnox, https://github.com/snapcore/snapd/wiki/REST-API#get-v2system-info [13:13] ""managed": false," [13:14] ogra: but there is also https://docs.ubuntu.com/core/en/guides/manage-devices/#checking-if-a-system-user-assertion-was-created [13:14] snap known system-user [13:14] ogra: what is that? [13:14] yeah, that too [13:14] the above is the API to query snapd [13:14] ogra: cause console-conf not only needs to know "if there is a system management user already" but also "what it is called" [13:15] right [13:15] the API isndeed only returns the state ... not the usersname [13:15] *username [13:16] https://github.com/snapcore/snapd/wiki/REST-API#get-v2users migth help with that [13:17] right [13:17] but if the system is managed i can simply refrain from running the user module (if it is a module, i havent looked at subiwuity) [13:18] *subiquity ... [13:18] (why does my typing suck so badly today 😞 ) [13:18] xnox: mmm actually maybe you need to be even smarter than snapd, as there could be users created on the system via cloud-init, probs if a user was created by cloud-init console-conf should not run? [13:20] yeah ... along with the fact that cloud-init created users are typically broken for core ... i.e. will not "snap login" the user and thus the system never becomes "managed" [13:21] ogra: well with cloud-init you don't have to provide SSO, so there's not an obvious way to have any user created by cloud-init a "snap user" [13:21] * pedronis break [13:21] right ... c-init is simply not designed for core ... (which is why i have been opposing its inclusion since day one) [13:22] xnox: anyways probably the best way to fix that bug for now is just to check if snap managed is false, then run cloud-init, if there is a system user, then `snap managed` should return true [13:22] it allows you all kinds of awful hacks and people simply never (have to) learn the proper ways [13:22] xnox: (or use the API instead of the cli cmd, etc.) [13:25] alternatively just ignoring the lxd user might be an appropriate quick fix/hack [13:26] (and probably a potential docker one too ... though i think that one is even worse hardcoded in the readonly /etc/passwd for some obscure reason)) [13:27] yay consistency ! [13:28] ogra: was a bug ever filed about the docker user / group being in the base snap's /etc/{passwd,group} ? [13:28] no, i only just remembered it again right now ... and it is indeed there [13:28] ogra: that should probably be assigned to sil2100 or xnox at this point [13:31] (no idea if it exists in core20 though) [13:32] ogra: it exists in core20 [13:32] same as core and core18 [13:32] aha [13:33] actually since core20 hasn't been released yet, perhaps we could just drop it from the base snap now and move it to extrausers 🤔 [13:34] well, it might also help to find out how exactly the lxd user gets there in the first place [13:34] i dont really know if it comes from the lxd snap or snapd [13:34] ogra: that's known it's the lxd snap doing hacks because it can [13:34] ah [13:35] so docker would have to be alloed the same hack [13:35] *allowed [13:35] well [13:35] no, not necessarily, just because lxd gets to be hackish doesn't mean that docker should get to be hackish too [13:35] heh [13:35] anyways this is not the right channel to discuss this [13:38] oh, note that removing a user from passwd is extremely dangerous ... the UID/GID might change underneath you but writable will have dirs using the old numbers [13:39] (this is why the core build scripts have a bunch of pre/post-build md5 sum checks for /etc/passwd and fail hard if anything has changed) [13:40] ogra: hence why I say we should fix it for core20 before it is released :-D [13:40] right, but only there ... else you need to do awful filesystem transitions [13:40] yeah I don't know how to handle other releases, but that's not my problem to fix [13:49] ogra: i agree it's a bug. i'm not sure if fixes in consoleconf alone are enough, or if anything will be needed in snapd too. [13:50] ogra: pasted comments on the bug report, and hope for some advice from snapd team as to which APIs / command-line calls console-conf should use to determine if system is managed or not, and by whom. [13:50] i'm pretty sure fixing console-conf is enough, snapd provides all info it needs [13:50] but yeah, i'll leave it to the snapd team to answer [13:58] ijohnson: hey, fontconfig is biting us again... in really fun ways [13:58] bug 1858636 [13:58] Bug #1858636: snapd generates incomplete fontconfig caches, result in emoji rendering issue in chromium

[13:58] ijohnson: a snap refresh will break the cache on the host for debs [13:58] kenvandine: do you mean a refresh to any snap version or a specific snap version ? [13:59] any snap [13:59] oh that seems ... bad ... [13:59] seb128 just reproduced this with a refresh of core [13:59] * ijohnson reads the bug [13:59] ijohnson, https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1858636/comments/37 [13:59] Bug #1858636: snapd generates incomplete fontconfig caches, result in emoji rendering issue in chromium

[13:59] has steps [13:59] it screws the cache [13:59] seb128: that's reproducible in a fresh focal VM for example ? [14:00] which means fonts are missing from snap and debs [14:00] ijohnson, yes, those steps I just tried on an autopkgtest cloud instance [14:00] (I had it created to test something else just poked there) [14:02] thanks folks I will have a look here [14:02] ijohnson, thanks! [14:02] ijohnson: thanks! [14:05] hmm it seems that the focal releases zsync file doesn't work [14:11] ijohnson, I don't think it's specific to focal and you trying on your normal system should work fine [14:12] ijohnson, hey, how would you define the difference between plugs and slots? Because from an implementation pov, they are in the end quite symmetrical - would you say that the difference is mostly conceptual? [14:13] man it is busy today in here [14:13] lol [14:13] nw, was just a random question [14:13] abeato: uh I guess what's the answer you're looking for ? something to give to a customer or your own philosophical musinsgs? [14:14] ijohnson, more the second [14:14] abeato: yes it is mostly conceptual, but the idea reallly is that a slot is "providing" something that the plug consumes, for example with the docker interface, the slot is providing access to the docker socket [14:15] seb128: when I run your final command fc-cat I see a bunch of "Unable to load the cache" messages, I presume that is your bug? [14:15] kenvandine: ^ [14:15] ijohnson, no [14:15] seb128: I ran the commands how do I tell if my fontconfig was broken [14:15] that's just the cat command not being targetted [14:16] as I wrote [14:16] https://www.irccloud.com/pastebin/8FEZ1pvX/ [14:16] you should have an entry [14:16] "NotoColorEmoji.ttf" 0 "Noto Color Emoji:familylang=en:style=Regular:stylelang=en:fullname=Noto Color ... [14:16] seb128: that's what I see [14:16] right [14:16] it's buggy [14:16] try now to do dpkg-reconfigure fontconfig [14:16] and try again see if it lists a result [14:17] ah yes I see now [14:17] that's the difference [14:17] after the dpkg-reconfigure I see NotoColorEmoji in the grep output [14:17] ok [14:17] somehow snap does the cache refresh in a way that misses out that installed font [14:17] hmm [14:18] I need to think on this, but I'm wondering if this is reproducible with any core snap refresh or if it specifically is something new [14:18] ijohnson, ok, that what my intuition too - I was curious because in the end you can provide same permissions to either plug or socket. And I noticed that you can even connect the same plug to two different "slot providers" [14:18] ijohnson, the report is from january so it's not "new" as in recent [14:19] seb128: kenvandine: because we did land some changes recently to the fontconfig handling but AIUI that was supposed to be for just non-ubuntu distros like arch that were broken [14:19] abeato: yes plugs can be connected to many slots, i.e. see gpio pins. what ends up being unique is the _connection_ not itself [14:19] *connection itself [14:19] right [14:19] ijohnson, thanks for the insight [14:22] ijohnson, does snap log somewhere the output of the fontconfig cache refresh? [14:22] seb128: right so I can see this with an empty /var/cache/fontconfig and edge core snap, refreshing to stable core snap will regenerate the cache, but not in a way that picks up that NotoColorEmoji font, so it is not something that is introducted between 2.45 and master right now [14:22] it doesn't create a /var/log/fontconfig.log [14:24] ijohnson, I will let you poke at it since you are able to trigger the issue, otherwise my comments are probably just going to slow you down/interrupt, but let me know if I can help in some way [14:24] seb128: no we don't save the log anywhere [14:24] would be useful to do :) [14:37] PR snapcraft#3169 opened: package-repositories: allow empty component list [15:07] PR snapcraft#3170 opened: pluginhandler: no update cache for the build step [15:37] PR snapcraft#3167 closed: unit tests: move to pytest [15:58] wh owns the expect snap ? i cant remember if it was chipaca, zyga or mvo who initially created it ... https://forum.snapcraft.io/t/expect-snap-not-living-up-to-expectations/18142 [15:58] *who [15:59] ogra: seems to be ~snappy-dev https://launchpad.net/~snappy-dev/+snap/expect [16:00] oh my ... snappy-hub ! [16:00] i thought that was dead since 2017 ! [16:00] haha apparently not [16:00] and it was done by federico ! who is long gone [16:03] PR snapd#8855 opened: cmd,many: move Version and bits related to snapd tools to snapdtool, merge cmdutil === pedronis_ is now known as pedronis [16:07] that was fun (#8855), not entirely [16:07] PR #8855: cmd,many: move Version and bits related to snapd tools to snapdtool, merge cmdutil [16:30] pedronis: seems a unit test failure on that PR [16:34] no, something about mkversion.sh [16:35] let's see if it works better now [16:35] pedronis: the unit test says it can't create a dir [16:35] anyways I'm sure you can debug it [16:35] heh [16:36] why are fonts so hard [16:36] the spread test we have has a working font package that shows up in the cache but we now have some font packages which do not show up in the cache we generate === ijohnson is now known as ijohnson|lunch [17:50] ijohnson|lunch: I fixed it, there's some weirdness on centos now though that seems unrelated === ijohnson|lunch is now known as ijohnson [17:52] pedronis: yeah I've seen that on centos [17:52] seems a package probelm [17:53] *missing package [18:34] PR snapd#8856 opened: tests/main/install-fontconfig-cache-gen: for bionic, focal use broken font [18:34] PR snapd#8857 opened: tests/lib/prepare: increase the size of the uc16/uc18 partitions [18:36] tianon: o/ do you have a minute to chat about the docker snap on UC? [18:40] Issue core20#72 opened: move docker user/group to extrausers === mpontillo_ is now known as mpontillo [19:46] kenvandine: hey, fyi, https://github.com/snapcore/snapd/pull/8699#pullrequestreview-429340871 [19:46] PR #8699: interfaces/desktop-launch: support confined snaps launching other snaps [19:47] kenvandine: I'm not sure alan signed up for a spread test, but it is needed. not sure if you want to reach out for someone from your team to do it in a followup [19:47] jdstrand: yeah, that is probably something jamesh could help with [19:47] kenvandine: I mean, he hasn't said 'no' yet, just thought I'd mention it so two weeks from now it isn't blocked on that [19:48] indeed [19:48] jdstrand: thanks [19:51] kenvandine: thanks! :) [20:29] hi jdstrand ! I got a system-files request to access /proc/sys/fs/file-nr, I get the feeling tht might be best covered by another interface, got any ideas? [20:30] if not, is it ok to grant system-files read-only? [21:02] roadmr: it doesn't exist in an interface, but file-max is in the default template. we should add it to there [21:02] roadmr: feel free to issue it read only. I've taken a todo to update the default template [21:03] thanks jdstrand [21:03] np [21:03] I'll allow it then! cheers! [21:03] emitorino: fyi ^