=== alazred_ is now known as alazred | ||
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:21 |
---|---|---|
mup | PR snapd#8852 opened: asserts: introduce new assertion validation-set <Created by pedronis> <https://github.com/snapcore/snapd/pull/8852> | 07:31 |
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> | 07:36 |
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> | 08:51 |
=== alazred_ is now known as alazred | ||
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> | 10:47 |
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> | 11:02 |
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:38 |
ijohnson | ogra: that's probably one for xnox these days | 12:45 |
ogra | ah, i didnt know he took over console-conf | 12:53 |
ogra | (specifically for xenian/bionic where it isnt a snap yet) | 12:54 |
ogra | *xenial | 12:54 |
pedronis | ijohnson: standup ? | 13:01 |
xnox | ijohnson: huh. mwhudson is still subiquity lead | 13:01 |
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:04 |
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:06 |
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:08 |
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:09 |
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:12 |
ogra | xnox, https://github.com/snapcore/snapd/wiki/REST-API#get-v2system-info | 13:13 |
ogra | ""managed": false," | 13:13 |
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:14 |
ogra | right | 13:15 |
ogra | the API isndeed only returns the state ... not the usersname | 13:15 |
ogra | *username | 13:15 |
ogra | https://github.com/snapcore/snapd/wiki/REST-API#get-v2users migth help with that | 13:16 |
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:17 |
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:18 |
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:20 |
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:21 |
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:22 |
ogra | alternatively just ignoring the lxd user might be an appropriate quick fix/hack | 13:25 |
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:26 |
ogra | yay consistency ! | 13:27 |
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:28 |
ogra | (no idea if it exists in core20 though) | 13:31 |
ijohnson | ogra: it exists in core20 | 13:32 |
ijohnson | same as core and core18 | 13:32 |
ogra | aha | 13:32 |
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:33 |
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:34 |
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:35 |
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:38 |
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:39 |
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:40 |
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:49 |
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:50 |
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:58 |
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 ? | 13:59 |
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:00 |
ijohnson | thanks folks I will have a look here | 14:02 |
seb128 | ijohnson, thanks! | 14:02 |
kenvandine | ijohnson: thanks! | 14:02 |
ijohnson | hmm it seems that the focal releases zsync file doesn't work | 14:05 |
seb128 | ijohnson, I don't think it's specific to focal and you trying on your normal system should work fine | 14:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:22 |
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:24 |
mup | PR snapcraft#3169 opened: package-repositories: allow empty component list <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3169> | 14:37 |
mup | PR snapcraft#3170 opened: pluginhandler: no update cache for the build step <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3170> | 15:07 |
mup | PR snapcraft#3167 closed: unit tests: move to pytest <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3167> | 15:37 |
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:58 |
ijohnson | ogra: seems to be ~snappy-dev https://launchpad.net/~snappy-dev/+snap/expect | 15:59 |
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:00 |
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:03 |
=== pedronis_ is now known as pedronis | ||
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:07 |
ijohnson | pedronis: seems a unit test failure on that PR | 16:30 |
pedronis | no, something about mkversion.sh | 16:34 |
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:35 |
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 | 16:36 |
=== ijohnson is now known as ijohnson|lunch | ||
pedronis | ijohnson|lunch: I fixed it, there's some weirdness on centos now though that seems unrelated | 17:50 |
=== ijohnson|lunch is now known as ijohnson | ||
ijohnson | pedronis: yeah I've seen that on centos | 17:52 |
ijohnson | seems a package probelm | 17:52 |
ijohnson | *missing package | 17:53 |
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:34 |
ijohnson | tianon: o/ do you have a minute to chat about the docker snap on UC? | 18:36 |
mup | Issue core20#72 opened: move docker user/group to extrausers <Created by anonymouse64> <https://github.com/snapcore/core20/issues/72> | 18:40 |
=== mpontillo_ is now known as mpontillo | ||
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:46 |
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:47 |
kenvandine | indeed | 19:48 |
kenvandine | jdstrand: thanks | 19:48 |
jdstrand | kenvandine: thanks! :) | 19:51 |
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:29 |
roadmr | if not, is it ok to grant system-files read-only? | 20:30 |
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:02 |
roadmr | thanks jdstrand | 21:03 |
jdstrand | np | 21:03 |
roadmr | I'll allow it then! cheers! | 21:03 |
jdstrand | emitorino: fyi ^ | 21:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!