[07:21] <mup> PR snapd#8851 opened: interface/fwupd: add more policies for making fwupd upstream strict <Created by woodrow-shen> <https://github.com/snapcore/snapd/pull/8851>
[07:31] <mup> PR snapd#8852 opened: asserts: introduce new assertion validation-set <Created by pedronis> <https://github.com/snapcore/snapd/pull/8852>
[07:36] <mup> PR snapd#8853 opened: asserts: introduce the concept of sequence-forming assertion types <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8853>
[08:51] <mup> PR snapd#8849 closed: tests: fail in setup_reflash_magic() if there is snapd state left <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8849>
[10:47] <mup> PR snapd#8755 closed: tests: fix classic ubuntu core transition auth <Simple 😃> <Created by sergiocazzolato> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8755>
[11:02] <mup> PR snapd#8854 opened: sysconfig/cloudinit: make callers of DisableCloudInit use WritableDefaultsDir <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8854>
[12:38] <ogra> mwhudson, do you still care for console-conf ? ... https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1881588
[12:38] <mup> Bug #1881588: pre-seeding lxd on Core appliances breaks console-conf user creation <snapd:Invalid> <subiquity (Ubuntu):New> <subiquity (Ubuntu Xenial):New> <subiquity (Ubuntu Bionic):New> <https://launchpad.net/bugs/1881588>
[12:45] <ijohnson> ogra: that's probably one for xnox these days
[12:53] <ogra> ah, i didnt know he took over console-conf
[12:54] <ogra> (specifically for xenian/bionic where it isnt a snap yet)
[12:54] <ogra> *xenial
[13:01] <pedronis> ijohnson: standup ?
[13:01] <xnox> ijohnson:  huh. mwhudson is still subiquity lead
[13:04] <xnox> 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] <ogra> 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] <ogra> *contains
[13:08] <ogra> 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] <ogra> 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] <ogra> *proper
[13:12] <xnox> ogra:  # TODO: use proper snap APIs.
[13:12] <ogra> xnox, TODO for whom ?
[13:12] <xnox> ogra:  is the proper snap API to query "managed" state?
[13:12] <ogra> i cant release a bunch of appliance i'm working on because of this
[13:12] <xnox> ogra:  that's a code comment right next to parsing of the /var/lib/extrausers/passwd, in console_conf
[13:12] <ogra> oh, yeah
[13:12] <ogra> there is an API
[13:12] <ogra> hah !
[13:13] <ogra> xnox, https://github.com/snapcore/snapd/wiki/REST-API#get-v2system-info
[13:13] <ogra> ""managed": false,"
[13:14] <xnox> ogra:  but there is also https://docs.ubuntu.com/core/en/guides/manage-devices/#checking-if-a-system-user-assertion-was-created
[13:14] <xnox> snap known system-user
[13:14] <xnox> ogra:  what is that?
[13:14] <ogra> yeah, that too
[13:14] <ogra> the above is the API to query snapd
[13:14] <xnox> 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] <ogra> right
[13:15] <ogra> the API isndeed only returns the state ... not the usersname
[13:15] <ogra> *username
[13:16] <ogra> https://github.com/snapcore/snapd/wiki/REST-API#get-v2users migth help with that
[13:17] <xnox> right
[13:17] <ogra> 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] <ogra> *subiquity ...
[13:18] <ogra> (why does my typing suck so badly today 😞 )
[13:18] <ijohnson> 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] <ogra> 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] <ijohnson> 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] <ogra> right ... c-init is simply not designed for core ... (which is why i have been opposing its inclusion since day one)
[13:22] <ijohnson> 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] <ogra> it allows you all kinds of awful hacks and people simply never (have to) learn the proper ways
[13:22] <ijohnson> xnox: (or use the API instead of the cli cmd, etc.)
[13:25] <ogra> alternatively just ignoring the lxd user might be an appropriate quick fix/hack
[13:26] <ogra> (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] <ogra> yay consistency !
[13:28] <ijohnson> ogra: was a bug ever filed about the docker user / group being in the base snap's /etc/{passwd,group} ?
[13:28] <ogra> no, i only just remembered it again right now ... and it is indeed there
[13:28] <ijohnson> ogra: that should probably be assigned to sil2100 or xnox at this point
[13:31] <ogra> (no idea if it exists in core20 though)
[13:32] <ijohnson> ogra: it exists in core20
[13:32] <ijohnson> same as core and core18
[13:32] <ogra> aha
[13:33] <ijohnson> 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] <ogra> well, it might also help to find out how exactly the lxd user gets there in the first place
[13:34] <ogra> i dont really know if it comes from the lxd snap or snapd
[13:34] <ijohnson> ogra: that's known it's the lxd snap doing hacks because it can
[13:34] <ogra> ah
[13:35] <ogra> so docker would have to be alloed the same hack
[13:35] <ogra> *allowed
[13:35] <ijohnson> well
[13:35] <ijohnson> no, not necessarily, just because lxd gets to be hackish doesn't mean that docker should get to be hackish too
[13:35] <ogra> heh
[13:35] <ijohnson> anyways this is not the right channel to discuss this
[13:38] <ogra> 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] <ogra> (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] <ijohnson> ogra: hence why I say we should fix it for core20 before it is released :-D
[13:40] <ogra> right, but only there ... else you need to do awful filesystem transitions
[13:40] <ijohnson> yeah I don't know how to handle other releases, but that's not my problem to fix
[13:49] <xnox> 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] <xnox> 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] <ogra> i'm pretty sure fixing console-conf is enough, snapd provides all info it needs
[13:50] <ogra> but yeah, i'll leave it to the snapd team to answer
[13:58] <kenvandine> ijohnson: hey, fontconfig is biting us again... in really fun ways
[13:58] <kenvandine> bug 1858636
[13:58] <mup> Bug #1858636: snapd generates incomplete fontconfig caches, result in emoji rendering issue in chromium <apport-collected> <eoan> <focal> <rls-ff-incoming> <snap> <wayland-session> <chromium-browser (Ubuntu):Confirmed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1858636>
[13:58] <kenvandine> ijohnson: a snap refresh will break the cache on the host for debs
[13:58] <ijohnson> kenvandine: do you mean a refresh to any snap version or a specific snap version ?
[13:59] <kenvandine> any snap
[13:59] <ijohnson> oh that seems ... bad ...
[13:59] <kenvandine> seb128 just reproduced this with a refresh of core
[13:59]  * ijohnson reads the bug
[13:59] <seb128> ijohnson, https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1858636/comments/37
[13:59] <mup> Bug #1858636: snapd generates incomplete fontconfig caches, result in emoji rendering issue in chromium <apport-collected> <eoan> <focal> <rls-ff-incoming> <snap> <wayland-session> <chromium-browser (Ubuntu):Confirmed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1858636>
[13:59] <seb128> has steps
[13:59] <seb128> it screws the cache
[13:59] <ijohnson> seb128: that's reproducible in a fresh focal VM for example ?
[14:00] <seb128> which means fonts are missing from snap and debs
[14:00] <seb128> ijohnson, yes, those steps I just tried on an autopkgtest cloud instance
[14:00] <seb128> (I had it created to test something else just poked there)
[14:02] <ijohnson> thanks folks I will have a look here
[14:02] <seb128> ijohnson, thanks!
[14:02] <kenvandine> ijohnson: thanks!
[14:05] <ijohnson> hmm it seems that the focal releases zsync file doesn't work
[14:11] <seb128> ijohnson, I don't think it's specific to focal and you trying on your normal system should work fine
[14:12] <abeato> 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] <ijohnson> man it is busy today in here
[14:13] <abeato> lol
[14:13] <abeato> nw, was just a random question
[14:13] <ijohnson> 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] <abeato> ijohnson, more the second
[14:14] <ijohnson> 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] <ijohnson> 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] <ijohnson> kenvandine: ^
[14:15] <seb128> ijohnson, no
[14:15] <ijohnson> seb128: I ran the commands how do I tell if my fontconfig was broken
[14:15] <seb128> that's just the cat command not being targetted
[14:16] <seb128> as I wrote
[14:16] <ijohnson> https://www.irccloud.com/pastebin/8FEZ1pvX/
[14:16] <seb128> you should have an entry
[14:16] <seb128> "NotoColorEmoji.ttf" 0 "Noto Color Emoji:familylang=en:style=Regular:stylelang=en:fullname=Noto Color ...
[14:16] <ijohnson> seb128: that's what I see
[14:16] <seb128> right
[14:16] <seb128> it's buggy
[14:16] <seb128> try now to do dpkg-reconfigure fontconfig
[14:16] <seb128> and try again see if it lists a result
[14:17] <ijohnson> ah yes I see now
[14:17] <seb128> that's the difference
[14:17] <ijohnson> after the dpkg-reconfigure I see NotoColorEmoji in the grep output
[14:17] <ijohnson> ok
[14:17] <seb128> somehow snap does the cache refresh in a way that misses out that installed font
[14:17] <ijohnson> hmm
[14:18] <ijohnson> 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] <abeato> 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] <seb128> ijohnson, the report is from january so it's not "new" as in recent
[14:19] <ijohnson> 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] <ijohnson> 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] <ijohnson> *connection itself
[14:19] <abeato> right
[14:19] <abeato> ijohnson, thanks for the insight
[14:22] <seb128> ijohnson, does snap log somewhere the output of the fontconfig cache refresh?
[14:22] <ijohnson> 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] <seb128> it doesn't create a /var/log/fontconfig.log
[14:24] <seb128> 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] <ijohnson> seb128: no we don't save the log anywhere
[14:24] <seb128> would be useful to do :)
[14:37] <mup> PR snapcraft#3169 opened: package-repositories: allow empty component list <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3169>
[15:07] <mup> PR snapcraft#3170 opened: pluginhandler: no update cache for the build step <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3170>
[15:37] <mup> PR snapcraft#3167 closed: unit tests: move to pytest <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3167>
[15:58] <ogra> 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] <ogra> *who
[15:59] <ijohnson> ogra: seems to be ~snappy-dev https://launchpad.net/~snappy-dev/+snap/expect
[16:00] <ogra> oh my ... snappy-hub !
[16:00] <ogra> i thought that was dead since 2017 !
[16:00] <ijohnson> haha apparently not
[16:00] <ogra> and it was done by federico ! who is long gone
[16:03] <mup> PR snapd#8855 opened: cmd,many: move Version and bits related to snapd tools to snapdtool, merge cmdutil <Created by pedronis> <https://github.com/snapcore/snapd/pull/8855>
[16:07] <pedronis> that was fun (#8855), not entirely
[16:07] <mup> PR #8855: cmd,many: move Version and bits related to snapd tools to snapdtool, merge cmdutil <Cleanup :broom:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8855>
[16:30] <ijohnson> pedronis: seems a unit test failure on that PR
[16:34] <pedronis> no, something about mkversion.sh
[16:35] <pedronis> let's see if it works better now
[16:35] <ijohnson> pedronis: the unit test says it can't create a dir
[16:35] <ijohnson> anyways I'm sure you can debug it
[16:35] <pedronis> heh
[16:36] <ijohnson> why are fonts so hard
[16:36] <ijohnson> 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
[17:50] <pedronis> ijohnson|lunch: I fixed it, there's some weirdness on centos now though that seems unrelated
[17:52] <ijohnson> pedronis: yeah I've seen that on centos
[17:52] <ijohnson> seems a package probelm
[17:53] <ijohnson> *missing package
[18:34] <mup> PR snapd#8856 opened: tests/main/install-fontconfig-cache-gen: for bionic, focal use broken font <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8856>
[18:34] <mup> PR snapd#8857 opened: tests/lib/prepare: increase the size of the uc16/uc18 partitions <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8857>
[18:36] <ijohnson> tianon: o/ do you have a minute to chat about the docker snap on UC?
[18:40] <mup> Issue core20#72 opened: move docker user/group to extrausers <Created by anonymouse64> <https://github.com/snapcore/core20/issues/72>
[19:46] <jdstrand> kenvandine: hey, fyi, https://github.com/snapcore/snapd/pull/8699#pullrequestreview-429340871
[19:46] <mup> PR #8699: interfaces/desktop-launch: support confined snaps launching other snaps <Needs Samuele review> <Needs security review> <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/8699>
[19:47] <jdstrand> 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] <kenvandine> jdstrand: yeah, that is probably something jamesh could help with
[19:47] <jdstrand> 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] <kenvandine> indeed
[19:48] <kenvandine> jdstrand: thanks
[19:51] <jdstrand> kenvandine: thanks! :)
[20:29] <roadmr> 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] <roadmr> if not, is it ok to grant system-files read-only?
[21:02] <jdstrand> roadmr: it doesn't exist in an interface, but file-max is in the default template. we should add it to there
[21:02] <jdstrand> roadmr: feel free to issue it read only. I've taken a todo to update the default template
[21:03] <roadmr> thanks jdstrand
[21:03] <jdstrand> np
[21:03] <roadmr> I'll allow it then! cheers!
[21:03] <jdstrand> emitorino: fyi ^