| genii | Is pulseaudio now snap only install? | 00:05 |
|---|---|---|
| cjwatson | pulseaudio is still in Ubuntu. The snap seems pretty out of date. | 00:08 |
| cjwatson | (still in Ubuntu as a .deb, I mean) | 00:08 |
| genii | cjwatson: Thanks. Looks like an update to 7.5 was reverted to 7.4, causing issues in apt/dpkg | 00:40 |
| Kyoku | is there a way to do full disk encryption on ubuntu core for Pi4 without paying $30,000 for a smart start plugin? | 01:02 |
| === diddledan6 is now known as diddledan | ||
| mup | PR snapcraft#2658 closed: candidate testing <do-not-merge> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2658> | 02:12 |
| mup | PR snapcraft#2873 opened: candidate testing <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2873> | 02:12 |
| mborzecki | morning | 06:24 |
| mup | PR snapd#7988 closed: snap: remove "host" output from `snap version` <⚠ Critical> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7988> | 07:08 |
| mborzecki | mvo: morning | 07:37 |
| mborzecki | mvo: can you cherry pick #7988 to 2.43? | 07:37 |
| mup | PR #7988: snap: remove "host" output from `snap version` <⚠ Critical> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7988> | 07:37 |
| mvo | mborzecki: good morning! | 07:42 |
| mvo | mborzecki: yes, will do now | 07:42 |
| mvo | mborzecki: do you know if we need anything else for .1 ? | 07:42 |
| mborzecki | mvo: hmm, selinux policy would be nice | 07:42 |
| mvo | mborzecki: yeah, could you please tag as 2.43? | 07:43 |
| mborzecki | mvo: https://github.com/snapcore/snapd/pull/7978 want me to open a PR with backport? | 07:43 |
| mup | PR #7978: data/selinux, test/main/selinux-clean: update the test to cover more scenarios <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7978> | 07:43 |
| zyga | good morning | 07:43 |
| mvo | mborzecki: backport is fine, if its small I can cherry-pick | 07:43 |
| mvo | zyga: good morning | 07:43 |
| zyga | mvo: .1 release coming for that snap version output changeW? | 07:43 |
| mvo | zyga: yes, anything from you we need for .1 ? | 07:43 |
| zyga | no, sorry | 07:44 |
| zyga | I'll try to do better today | 07:44 |
| mvo | zyga: that's fine | 07:44 |
| mvo | zyga: no worries | 07:44 |
| mvo | mborzecki: it's just three commits, if they apply cleanly I will just cherry pick them | 07:44 |
| mborzecki | mvo: yeah, that should be fine | 07:44 |
| mvo | mborzecki: yeah, no conflicts, done | 07:45 |
| mborzecki | mvo: cool, thank you! | 07:45 |
| mvo | mborzecki: thank you ! | 07:46 |
| mvo | mborzecki: I will wait for pawel and samuele to double check if they think we need to add anything and then proceed with the release of .1 | 07:46 |
| mup | PR snapd#7981 closed: snap-bootstrap: create encrypted partition <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7981> | 07:52 |
| zyga | https://github.com/snapcore/snapd/pull/7974#issuecomment-574050904 is the weirdest python review I ever made | 07:58 |
| mup | PR #7974: many: run black formatter on all python files <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7974> | 07:58 |
| * zyga reviews indirect download PR | 08:01 | |
| pstolowski | mornings | 08:02 |
| zyga | hey pawel | 08:12 |
| zyga | pstolowski: it's coming today | 08:12 |
| zyga | pstolowski: :) | 08:12 |
| pstolowski | zyga: yay :) | 08:13 |
| mvo | hey pstolowski ! good morning! anything you can think of we need/should include in 2.43.1 ? | 08:16 |
| pstolowski | mvo: hey, nothing from me | 08:18 |
| mvo | ta | 08:19 |
| mborzecki | errand, back in 1h or so | 08:41 |
| zyga | brb | 08:54 |
| pedronis | mvo: hi, I commented on #7989 | 08:56 |
| mup | PR #7989: devicestate: do not allow remodel between core20 models <Created by mvo5> <https://github.com/snapcore/snapd/pull/7989> | 08:56 |
| pedronis | mborzecki: mvo: #7990 is missing some end of doc comment sentence . | 08:56 |
| mup | PR #7990: many: misc tweaks <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7990> | 08:57 |
| mvo | pedronis: thank you | 08:59 |
| mvo | pedronis: makes sense | 09:00 |
| zyga | back | 09:05 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/7977#pullrequestreview-341982749 | 09:27 |
| mup | PR #7977: snap: add (hidden) `snap download --indirect` option to download via snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/7977> | 09:27 |
| zyga | mvo: not sure if I'm right, otherwise +1 | 09:28 |
| zyga | mvo: though I want to check one more thing that landed before | 09:28 |
| zyga | mvo: as it is realted | 09:28 |
| zyga | *related | 09:28 |
| zyga | checked out, ok | 09:29 |
| mvo | zyga: aha, nice one. I need to double check but I think you are right | 09:34 |
| mvo | zyga: \o/ | 09:34 |
| mborzecki | re | 09:34 |
| * zyga reviews the SnapAction PR next | 09:34 | |
| zyga | mvo: just for reference, I checked if the remote download API cannot be used to abuse snapd to write to arbitrary files | 09:35 |
| zyga | mvo: but I'm happy to see it is not that | 09:35 |
| zyga | mvo: the API is just streaming the file via snapd, correct? | 09:35 |
| zyga | (that's how I understood the api_download.go code) | 09:35 |
| mvo | zyga: correct, in this regard there is no change to the old download code, the old code would connect to the download server directly, the new code connects to snapd for the download | 09:37 |
| zyga | mvo: right, I was specifically looking for how the write to disk is done | 09:37 |
| zyga | mvo: it is done via snap download running as user, which is what was important to me | 09:37 |
| zyga | mvo: and specifically there is no path that snapd writes to that could be used to attack anything | 09:38 |
| Chipaca | mvo: could we create a test-snapd- snap to test default tracks? | 09:38 |
| mvo | zyga: correct | 09:39 |
| mvo | Chipaca: yes | 09:39 |
| Chipaca | mvo: in the snaps@ account an' everything? | 09:39 |
| mvo | Chipaca: please create it under your account for now and then share with me/cachio - I need to create/use the new snapd-testing store account but I have not yet :( probably this is a good time to do that but I don't want to block you | 09:40 |
| Chipaca | mvo: ok | 09:41 |
| pedronis | Chipaca: share it with me too | 09:45 |
| zyga | Chipaca: https://github.com/snapcore/snapd/pull/7984#pullrequestreview-342411978 | 10:14 |
| mup | PR #7984: store, overlord/snapstate, etc: SnapAction now returns a []…Result <Created by chipaca> <https://github.com/snapcore/snapd/pull/7984> | 10:14 |
| Chipaca | zyga: ack | 10:15 |
| Chipaca | i'll do it in a followup when i switch to the new snap | 10:15 |
| pstolowski | oh well, we have a bug | 10:17 |
| zyga | pstolowski: oh? | 10:17 |
| pstolowski | snap connections and snap interfaces reports connections for missing slots/plugs (e.g. after refreshing to a snap that doesn't have a plug/slot anymore). the repo doesn't have such plug/slot anymore, but api reads "conns" and doesn't intersect with repo (or snap.yaml data) | 10:20 |
| zyga | I think we knew about this | 10:20 |
| zyga | it's reported AFAIK | 10:20 |
| pstolowski | hmm maybe you're right. i think issues around that had a few incarnations | 10:20 |
| pstolowski | fwtw it's just the list of connections affected; security profiles are generated from repo data so they're fine | 10:21 |
| pstolowski | anyway.. i'll look at fixing it | 10:23 |
| zyga | pstolowski: do you have an idea on how the fix should look like? | 10:24 |
| pstolowski | zyga: quick/rough one:L maybe collectConnections() in the daemon should (or ifaceMgr.ConnectionStates() one level deeper) intersect conns with repo | 10:28 |
| pstolowski | i'll look at details later. i stumbled on it accidently when working on spread test for snap disconnect --forget | 10:29 |
| zyga | pstolowski: I'll give it some thought and get back to you | 10:32 |
| mborzecki | Chipaca: hmm hmm https://forum.snapcraft.io/t/596-523-hours-left-0-bytes-sec/15033/7 IDK what to say ;) | 10:37 |
| Chipaca | mborzecki: moved it to the cafe | 10:38 |
| mborzecki | Chipaca: thx | 10:38 |
| pstolowski | zyga: thanks | 10:40 |
| pedronis | pstolowski: hi, I did a pass on #7982 | 10:41 |
| mup | PR #7982: o/snapstate, wrappers: enable services on start <Complex> <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7982> | 10:41 |
| pstolowski | pedronis: ty | 10:42 |
| mborzecki | quick errand | 10:44 |
| pedronis | Chipaca: hi, it seems 7984 can be merged | 10:48 |
| Chipaca | pedronis: yep | 10:48 |
| Chipaca | pedronis: was waiting for a nod on the next one; don't want to merge it if I then need to change the refactor | 10:48 |
| Chipaca | pedronis: but I guess I have that | 10:49 |
| pedronis | pstolowski: mborzecki: we need to remember to try to s/GetType/Type/ at some point before .44 | 10:49 |
| Chipaca | as your comments were about the details, not about the guts of it | 10:49 |
| Chipaca | so, yeah, merging | 10:49 |
| pedronis | Chipaca: one non-blocking question is whether it would make logic sense to move EffectiveChannel to SAR as well or not | 10:50 |
| mup | PR snapd#7984 closed: store, overlord/snapstate, etc: SnapAction now returns a []…Result <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7984> | 10:50 |
| Chipaca | pedronis: the followup (7986) is red because the snap i use to test isn't in i386, so i decided to create our own snap now | 10:50 |
| Chipaca | pedronis: (i had planned to that sometime anyway, which is why i put it in a variable :) ) | 10:51 |
| pstolowski | pedronis: right | 10:51 |
| Chipaca | pedronis: right | 10:51 |
| mup | PR snapd#7990 closed: many: misc tweaks <Simple 😃> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7990> | 10:51 |
| zyga | pstolowski: https://forum.snapcraft.io/t/opera-requests-auto-connect-to-gnome-3-28-1804-interface/14505/14 | 11:02 |
| zyga | pstolowski: can you snap install `opera-developer` it looks like we have a serious autoconnect issue | 11:02 |
| zyga | I just want to double check that it's equally broken on Ubuntu for you | 11:02 |
| zyga | looking at what's going on now | 11:03 |
| pstolowski | zyga: will do in a sec | 11:03 |
| zyga | pstolowski: I think it's caused by the snap declaration | 11:05 |
| pstolowski | zyga: confirmed, gnome-3-28 content plug is not autoconnected | 11:08 |
| zyga | pstolowski: check my response on the forun | 11:08 |
| zyga | pstolowski: I don't recall how that part works | 11:08 |
| zyga | pstolowski: if we have a snap declaration with plugs/content/allow-auto-connection entry | 11:09 |
| zyga | pstolowski: does it mean _only_ that entry is auto-connected | 11:09 |
| zyga | pstolowski: or does it mean that defaults apply but those are extras? | 11:09 |
| pedronis | zyga: yes, if the snap has a content thing like that then it will not use the slot one | 11:09 |
| zyga | pedronis: what do you mean by "it will not use the slot one"? | 11:09 |
| pedronis | I mean that the slot side snap-declaration on gnome-* will not be used | 11:10 |
| pedronis | the only content auto-connection they wil get is the one they are allowing in their declaration | 11:10 |
| pedronis | there is n merging | 11:10 |
| pedronis | there is no merging | 11:10 |
| zyga | mhm | 11:10 |
| zyga | so there are two bugs here | 11:11 |
| zyga | 1) the declaration for opera-developer needs fixing | 11:11 |
| zyga | 2) this is not discoverable much | 11:11 |
| pedronis | discoverable what? | 11:11 |
| pedronis | they asked somebody in the store for that declaration | 11:11 |
| zyga | pedronis: snap install did not respect auto-connection that otherwise normally happens | 11:11 |
| zyga | pedronis: and didn't say anything about why | 11:12 |
| pedronis | why would it? the declaration asked for this | 11:12 |
| pedronis | is not something the user can fix | 11:12 |
| zyga | pedronis: why would it? because the developer defined a plug and a default provider | 11:12 |
| mborzecki | re | 11:12 |
| zyga | and we used additional data to ignore that | 11:12 |
| zyga | I think this warrants a message | 11:12 |
| pedronis | zyga: data that they asked for | 11:12 |
| zyga | and I think the existence of that thread agrees | 11:12 |
| pedronis | anyway user != developer | 11:13 |
| zyga | pedronis: if I have a snap and I say I want to connect to a default provider snapd should 1) connect to it 2) tell me why it doesn't | 11:13 |
| pedronis | I wonder what is that snap | 11:13 |
| zyga | anything else is silent behavior that defies request | 11:13 |
| pedronis | this is not a typical scenario | 11:14 |
| zyga | no but I think my point stands | 11:14 |
| pedronis | I wonder if they were early adopter of something | 11:14 |
| zyga | we should say "not connecting despite default provider because snap-declaration data <reference> says not to" | 11:14 |
| zyga | pedronis: I would also argue that part of no-merging is also a bug / surprising | 11:15 |
| zyga | I know it's the design, since I've been to that meeting | 11:15 |
| zyga | but it's surprising | 11:15 |
| pedronis | zyga: we will not change that | 11:15 |
| zyga | pedronis: I think the only thing that really needs to be changed in snapd is to make this more discoverable | 11:16 |
| pedronis | anyway they are connecting to chromium-ffmpeg | 11:16 |
| pedronis | that's what that connect is | 11:16 |
| zyga | so that it doesn't require a snapd developer to debug each time | 11:16 |
| pedronis | but now they need something else to connect to gnome as well | 11:16 |
| zyga | pedronis: and if they didn't need ffmpeg they would get the connection to gnome-* by default | 11:17 |
| zyga | pedronis: I know you said we're not doing merging but I think you can see how that is surprising | 11:17 |
| pedronis | zyga: the correct solution is probably to move that decl on the chromium-ffmpeg side | 11:19 |
| pedronis | zyga: we publish chromium-ffmpeg it seems, it should have a policy of what snaps can use it (any snaps, some publishers, don't know) | 11:30 |
| pedronis | zyga: to be clear my impression is that this is particularly brittle because content is essentially a completely different interface for each value of the content label | 11:34 |
| pedronis | but is still a single interface for a our logic | 11:35 |
| zyga | pedronis: I agree entirely | 11:41 |
| zyga | re | 11:41 |
| * zyga was upstairs to help with Lucy | 11:41 | |
| zyga | pedronis: can you comment on the thread with your preference please | 11:41 |
| zyga | pedronis: I've advised jdstrand to issue a declaration for opera-* snaps | 11:41 |
| mborzecki | pedronis: updated #7972 | 11:45 |
| mup | PR #7972: overlord/snapstate, wrappers: undo of snapd on core <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7972> | 11:45 |
| pedronis | zyga: btw jdstrand is off this week | 11:46 |
| pedronis | zyga: I need to check something, but my preference would be for chromium-ffmpeg to control access to itself | 11:46 |
| pedronis | we probably need desktop input on that | 11:47 |
| zyga | pedronis: yes, as a tweak to assertions it would be preferable O(1) vs O(N) solution | 11:49 |
| zyga | man, my hand :/ | 11:49 |
| zyga | my wrist hurts so badly today, I was wrestling with Janek over weekend and I think I hurt myself | 11:49 |
| zyga | (Janek = son) | 11:49 |
| zyga | it was so-so yesterday but today it just hurts to do anything | 11:49 |
| zyga | it's my right hand so I don't use it as often but man, so annoying | 11:50 |
| mvo | pedronis: I updated 7989 based on your suggestion | 11:51 |
| cachio | mvo, hello | 11:51 |
| mvo | cachio: good morning | 11:51 |
| cachio | mvo, any idea if there is any special configuration for qemu to run core20 images? I see this log trying to start the image https://paste.ubuntu.com/p/QKJw2fPmXt/ | 11:52 |
| mvo | cachio: anything I should add to 2.43.1 before the release? | 11:52 |
| mvo | cachio: looking | 11:52 |
| cachio | mvo, no | 11:52 |
| cachio | tests for 2.43 ran almost with almost 100% of pass rate | 11:52 |
| mvo | cachio: the pastebin lookslike something is not quite right with the image, do you have a link to the work-in-progress PR of yours? then I can poke a bit how ubuntu-image and qemu are called | 11:53 |
| mvo | cachio: e.g. the qemu needs -bios /usr/share/OVMF/... | 11:54 |
| cachio | mvo, this is the branch https://github.com/sergiocazzolato/snapd/tree/tests-enable-nested-on-core20 | 11:54 |
| cachio | mvo, I'll try that | 11:55 |
| mvo | cachio: /usr/share/OVMF/OVMF_CODE.ms.fd to be precise, but I think it depends on the version of ubuntu where that file is :/ | 11:55 |
| ogra | mvo, did you see https://forum.snapcraft.io/t/how-to-use-camera-in-ubuntu-core18/14971/5 ? seems the start_x parameter does not work for the core18 pi installs | 11:56 |
| cachio | mvo, thanks for the info, I'll try and debug | 11:57 |
| mvo | ogra. meh, I have not, looking | 12:00 |
| mvo | cachio: yeah, I suspect that might be it | 12:00 |
| ogra | i wonder if there is some pattern match falling over the underscore ? | 12:00 |
| mvo | cachio: or at least this must be tweaked too, maybe there is more | 12:00 |
| mvo | ogra: I don't think we support "_" in the config, I wonder if start-x=1 will help | 12:01 |
| mvo | ogra: but this should behave the same on uc16 and uc18, if not I'm puzzled | 12:01 |
| * mvo also has not read the whole thread yet, it seems to be quite long | 12:01 | |
| ogra | ogra@pi4:~$ snap set system pi-config.start-x=1 | 12:02 |
| ogra | ogra@pi4:~$ | 12:02 |
| ogra | ogra@pi4:~$ snap set system pi-config.start_x=1 | 12:02 |
| ogra | error: cannot perform the following tasks: | 12:02 |
| ogra | - Run configure hook of "core" snap (invalid option name: "start_x") | 12:02 |
| ogra | ogra@pi4:~$ | 12:02 |
| ogra | yeah, its the underscore | 12:02 |
| pedronis | zyga: afaict only opera is connecting to chromium-ffmpeg | 12:02 |
| pedronis | all their various snaps: opera, opera-beta, opera-developer | 12:03 |
| zyga | pedronis: still, I think it makes sense to do what you said about the assertions | 12:04 |
| pedronis | yes | 12:04 |
| mup | PR snapcraft#2874 opened: LP-1661626 : Symlink $XDG_RUNTIME_DIR/../dconf/user <Created by MarcusTomlinson> <https://github.com/snapcore/snapcraft/pull/2874> | 12:04 |
| pedronis | zyga: I added something to thread and pinged kenvandine there | 12:09 |
| zyga | pedronis: thank you! :) | 12:09 |
| * Chipaca steps out for a bit | 12:28 | |
| mborzecki | pedronis: started adding https://github.com/snapcore/snapd/pull/7991#pullrequestreview-342491713 to ian's PR | 12:33 |
| mup | PR #7991: boot: add HasModeenv to Device <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7991> | 12:33 |
| mborzecki | quick errand, back in 20 or so | 12:33 |
| cachio | mvo, hey, I see these errors starting the core20 image https://paste.ubuntu.com/p/FJfZdsNVrM/ | 13:09 |
| cachio | these 3 services cannot be started | 13:09 |
| cachio | correctly | 13:10 |
| cachio | mvo, do you know if any other configuration is needed for qemu? | 13:11 |
| mvo | cachio: the e2scrub_reap service is known, the other two are not | 13:25 |
| mborzecki | re | 13:28 |
| zyga | Chipaca: could you please split https://forum.snapcraft.io/t/snapd-2-36-snap-confine-logic-walkthrough/7843/4 into a new topic | 13:41 |
| zyga | "cannot fsck volume mounted on /var/snap" | 13:41 |
| zyga | Chipaca: last two messages there please | 13:41 |
| Chipaca | zyga: title? | 13:41 |
| zyga | "cannot fsck volume mounted on /var/snap" | 13:41 |
| Chipaca | zyga: in snapd? | 13:42 |
| zyga | yes please | 13:42 |
| zyga | thank you! | 13:42 |
| Chipaca | zyga: done | 13:42 |
| zyga | super :) | 13:42 |
| Chipaca | gosh, almost standup time already | 13:46 |
| Chipaca | where did my morning go | 13:46 |
| zyga | right? :) | 13:50 |
| mup | PR snapd#7993 opened: devicestate: enable encryption based on model grade <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7993> | 13:52 |
| zyga | mvo: is .1 out? | 13:54 |
| mvo | zyga: not yet, one question (if 7879 can be included pending for pedronis first) | 13:56 |
| mvo | zyga: why, do you have something? | 13:56 |
| zyga | mvo: I have a 1 liner fix | 13:56 |
| zyga | mvo: for a small bug | 13:56 |
| zyga | yeah | 13:56 |
| mvo | zyga: please push it then | 13:56 |
| zyga | yup one sec | 13:56 |
| mvo | zyga: and we can decide. thank you | 13:56 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/7994 | 13:58 |
| mup | PR #7994: cmd/snap-discard-ns: fix pattern for .info files <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7994> | 13:58 |
| mup | PR snapd#7994 opened: cmd/snap-discard-ns: fix pattern for .info files <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7994> | 13:58 |
| * Chipaca sneaks in a risk level "mauve" | 14:04 | |
| kenvandine | oSoMoN: can you please respond to the question about chromium-ffmpeg in https://forum.snapcraft.io/t/opera-requests-auto-connect-to-gnome-3-28-1804-interface/14505/19 | 14:22 |
| oSoMoN | sure | 14:28 |
| mborzecki | ijohnson: looking at https://pastebin.ubuntu.com/p/568vkDFB7P/ from you standup | 14:33 |
| ijohnson | zyga: thanks for that python0 patch, I commited it to the PR :-) | 14:33 |
| ijohnson | hopefully the tests are happy again on this | 14:33 |
| zyga | ijohnson: my pleasure :) | 14:34 |
| ijohnson | mborzecki: nice thanks | 14:34 |
| zyga | ijohnson: I only know because I made the python0 snap | 14:34 |
| ijohnson | mborzecki: that one at least is easier cause you have a backtrace from SIGQUIT the other ones are just "timed out" :-( | 14:34 |
| mborzecki | ijohnson: looks like a deadlock, between the snippet at standby_test.go:135 and m.Stop() | 14:34 |
| ijohnson | zyga: :-) programming archeology indeed | 14:35 |
| mborzecki | ijohnson: there's no channel cleaneup, none of the ch{1,2} are closed, so if the we're stuck in querying the opinions, stop will hang | 14:35 |
| ijohnson | mborzecki: ah good find | 14:36 |
| * zyga breaks for lunch | 14:40 | |
| === ricab is now known as ricab|lunch | ||
| pedronis | oSoMoN: sorry, I mean are we genereally comfortable with any snap using chromium-ffmep? | 14:48 |
| oSoMoN | pedronis, the typical use case is third-party browser snaps, but I don't see why other snaps couldn't connect to it if they wanted to | 14:49 |
| pedronis | oSoMoN: I'm trying to remove the step where they need to ask for auto-connection, because as opera shows it's likely to get wrong, because all content conection nees to take care holistically | 14:49 |
| pedronis | *needs to be taken care holistically | 14:50 |
| pstolowski | degville, ijohnson re snapctl start & --enable (if I got Graham's remarks right), it seems that snacptl start --help is not listing enable even though it's in the code; seems that the command descriptions are not set up correctly (i haven't investigated if it works as expected) | 14:51 |
| degville | pstolowski: thank you! that's exactly what I was looking for. | 14:52 |
| pstolowski | degville: snap start --help works as expected | 14:52 |
| pedronis | oSoMoN: I have tried to ask this in the forum | 14:52 |
| degville | pstolowski: thanks! | 14:53 |
| * cachio lunch and bank | 14:55 | |
| oSoMoN | pedronis, that would certainly be better for third-party browser snaps | 14:57 |
| ijohnson | degville: pstolowski: yes sorry got distracted, shall I still find you the relevant code snippet? | 15:03 |
| * ijohnson was busy reading about how old python 0.9.1 is | 15:04 | |
| pstolowski | haha | 15:04 |
| pstolowski | ijohnson: i looked at ctlcmd/start.go and it seems wrong as far as help is concerned. but maybe i misunderstand what the issue was | 15:05 |
| pstolowski | ijohnson: the flag itself should work, i'm talking only about help | 15:05 |
| ijohnson | pstolowski: yes the help message there does need to be updated | 15:05 |
| ijohnson | degville: as for finding where snapctl is implemented, were you able to sort through the code? snapctl specifically is a bit weird in that really the command options are stored inside the code for the snapd binary and not in the code for the snapctl binary | 15:08 |
| degville | ijohnson: yes, thank you! I've got it now - I've got enough to update the docs. | 15:08 |
| ijohnson | degville: great glad to hear it | 15:09 |
| pedronis | oSoMoN: if you answer on the forum we can take it from there | 15:11 |
| ijohnson | also zyga did you have any thoughts on having black run on all the python code in the snapd repo? | 15:17 |
| zyga | ijohnson: we should do it | 15:17 |
| zyga | :) | 15:17 |
| zyga | I regard black as a good thing | 15:17 |
| ijohnson | should we do it as part of run-checks or like spread-shellcheck do you think ? | 15:17 |
| ijohnson | personally, I wouldn't really be happy if to contribute to snapd (a Go project) I needed to standup python tools just to run checks | 15:18 |
| ijohnson | so I'm leaning towards having a spread test which checks all the formatting in the python code | 15:18 |
| zyga | ijohnson: I would not go there | 15:18 |
| zyga | ijohnson: it's not ultra-relevant and any kind of enforced format things ended up sucking IMO | 15:19 |
| ijohnson | zyga: ok fair enough | 15:19 |
| pedronis | ijohnson: I reviewed #7992, it seems to be missing unit tests afaict | 15:23 |
| mup | PR #7992: bootloader: add ExtractedRunKernelImageBootloader interface, implement in grub <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7992> | 15:23 |
| ijohnson | pedronis: did you mean unit tests of the grub methods? | 15:24 |
| ijohnson | yes I think I am missing those now that you mention it | 15:24 |
| pedronis | yes | 15:24 |
| ijohnson | sorry I will add those today | 15:24 |
| pedronis | there seem to be a buglet as well | 15:25 |
| pedronis | which hopefully those will find :) | 15:25 |
| ijohnson | pedronis: yes :-) | 15:26 |
| ijohnson | pedronis: also regarding "." do you just mean in comments that are for doc-comments on exported methods or do you mean everywhere I should use "." ? | 15:26 |
| pedronis | ijohnson: my POV on that is doc comment for exported things, I don't have a strict pattern for internal comments, it depends | 15:27 |
| ijohnson | pedronis: ok IMHO I don't think it's needed for internal comments so I will just add to exported doc-comments then | 15:28 |
| ijohnson | pedronis: do you want me to open the third PR for you to use for context now (even though it has still at least one bug) ? | 15:28 |
| pedronis | ijohnson: as you prefer, this one looks good to me, except the missing tests etc | 15:29 |
| ijohnson | pedronis: ok I wasn't sure if you were able to review the design of that interface without seeing it used in other places | 15:29 |
| pedronis | ijohnson: well I proposed that design, so I have I sense how I imagine it used | 15:30 |
| ijohnson | yes :-) | 15:30 |
| pedronis | my imagination might be wrong, but it doesn't really affect the PR in itself | 15:31 |
| pedronis | mborzecki: there's a preexisting bug in readModeenvImpl | 15:35 |
| mborzecki | pedronis: hm? | 15:35 |
| pedronis | mborzecki: modeenvPath := filepath.Join(rootdir, dirs.SnapModeenvFile) doesn't make sense | 15:35 |
| pedronis | dirs stuff has already a rootdir in it, we need a SnapModenvFileUnder helper instead | 15:36 |
| pedronis | same approach as SnapStateFileUnder(rootdir string) for example | 15:36 |
| mborzecki | hah | 15:36 |
| mborzecki | right | 15:36 |
| pedronis | mborzecki: can you look into this when you have moment | 15:37 |
| mborzecki | pedronis: yes, sure | 15:37 |
| pedronis | thx | 15:37 |
| pedronis | mborzecki: thansk for the changes to 7991, I made one more nitpick comment that relates to this. | 15:40 |
| ijohnson | mvo: I noticed https://forum.snapcraft.io/t/the-snapd-roadmap/1973 is a bit out of date now for 2.43 estimates? | 15:44 |
| mvo | ijohnson: yes, I need to update it, hopefully later today | 15:50 |
| ijohnson | great, thanks | 15:51 |
| ijohnson | pedronis: as I'm updating the doc-comments on those grub methods it occured to me that currently EnableKernel() and EnableTryKernel() don't check that the kernel snap referenced there exists, do you think we should error out if an incorrect kernel snap is passed to those things? | 15:52 |
| pedronis | also the only topic there will not make 2.43, but I doubt is the only thing we did in 2.43 | 15:52 |
| === pedronis_ is now known as pedronis | ||
| pedronis | ijohnson: that makes sense, OTOH Disable should probably be ok even the symlink is not there | 15:53 |
| ijohnson | pedronis: ack, and yes agreed about Disable() | 15:53 |
| === ricab|lunch is now known as ricab | ||
| mup | PR snapd#7995 opened: debian: check embedded keys for snap-{bootstrap,preseed} too <Created by mvo5> <https://github.com/snapcore/snapd/pull/7995> | 15:58 |
| pedronis | I added some obvious things based on the trello column | 16:04 |
| zyga | mborzecki: hey | 16:15 |
| zyga | I saw this denial just now | 16:15 |
| zyga | type=AVC msg=audit(01/14/20 15:50:55.249:2747) : avc: denied { mounton } for pid=25654 comm=snap-update-ns path=/usr/lib/fontconfig/cache dev="sda1" ino=26841099 scontext=system_u:system_r:snappy_mount_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=dir permissive=1 | 16:15 |
| zyga | does this ring a bell? | 16:15 |
| zyga | there were a few others | 16:15 |
| zyga | https://www.irccloud.com/pastebin/Jgba6EB1/ | 16:15 |
| mborzecki | zyga: this in tests or a live desktop system? | 16:19 |
| mborzecki | zyga: oh, and is it updated? the labeling bug https://bugzilla.redhat.com/show_bug.cgi?id=1659905 was fixed in july | 16:21 |
| zyga | mborzecki: that's from spread | 16:22 |
| zyga | mborzecki: it's the unstable suite so maybe it's expected but I wanted to ask you first | 16:22 |
| mborzecki | zyga: centos then? | 16:22 |
| zyga | centos 7, yep | 16:22 |
| mborzecki | zyga: hmmm, it's s-u-n, probably setting u desktop iface mounts right? maybe we should allow that | 16:24 |
| zyga | mborzecki: I presume so | 16:24 |
| mborzecki | zyga: i suppose the policy won't get updated on centos7 :/ | 16:25 |
| zyga | why? because it's a separate package? | 16:25 |
| mborzecki | zyga: because selinux-policy-targeted should be fixed to label /usr/lib/fontconfig/cache as fonts_cache_t like it does in F29+, rather than lib_t | 16:26 |
| zyga | mborzecki: and it won't be or ... I don't follow, sorry | 16:27 |
| mborzecki | zyga: i can file a bug, but hype seems to be about centos8 now :) | 16:28 |
| zyga | aha | 16:28 |
| zyga | I see | 16:28 |
| zyga | thanks, I just wanted to check | 16:28 |
| mup | PR snapd#7989 closed: devicestate: do not allow remodel between core20 models <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7989> | 16:41 |
| pedronis | mborzecki: thanks for the changes to 7991 | 16:43 |
| pedronis | ijohnson: I think #7991 can be merged if you are ok with the changes in it | 16:44 |
| mup | PR #7991: boot: add HasModeenv to Device <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7991> | 16:44 |
| ijohnson | pedronis: ok, let me look I think it's probably fine but give me a minute | 16:44 |
| pedronis | ijohnson: np, feel free to tweak/merge at your pace | 16:44 |
| mup | PR snapd#7996 opened: overlord/standby: fix possible deadlock in standby test <Simple 😃> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7996> | 16:55 |
| mborzecki | ijohnson: ^^ | 16:56 |
| zyga | mborzecki: for .1 as well? | 16:58 |
| ijohnson | thanks mborzecki | 17:00 |
| mborzecki | that failing tests/core18/snapd-failover test makes me think we need to improve logging | 17:03 |
| * zyga EODs and goes to do homework | 17:13 | |
| zyga | mvo: https://github.com/snapcore/snapd/pull/7994 needs a 2nd review but is otherwise ready | 17:14 |
| mup | PR #7994: cmd/snap-discard-ns: fix pattern for .info files <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7994> | 17:14 |
| oSoMoN | jdstrand, may I ask you to comment on the proposal in bug #1859643 (adding a personal-files plug on $HOME/.pki/nssdb) ? | 17:23 |
| mup | Bug #1859643: [snap] cannot use shared NSS db <snap> <chromium-browser (Ubuntu):Triaged by osomon> <https://launchpad.net/bugs/1859643> | 17:23 |
| pedronis | oSoMoN: jdstrand is off this whole week | 17:26 |
| oSoMoN | ah, thanks | 17:27 |
| oSoMoN | I'll make a note to ask him again next week | 17:27 |
| Chipaca | woo, #7986 is green | 17:30 |
| mup | PR #7986: store, o/snapstate: send default-tracks header, use RedirectChannel <Created by chipaca> <https://github.com/snapcore/snapd/pull/7986> | 17:30 |
| Chipaca | (needing another review, hint hint) | 17:30 |
| mvo | zyga looked at some test timeout right now, will try to look at it right after this | 17:46 |
| Chipaca | EOD for me | 18:03 |
| Chipaca | 👋 | 18:03 |
| pedronis | ijohnson: something seems very unhappy in your HasModeenv branch, not sure why given it's no used yet | 18:09 |
| ijohnson | pedronis: thanks for the ping, looking now | 18:09 |
| ijohnson | though I'm about to head off for lunch so might be after your EOD that I get to the bottom of it | 18:09 |
| pedronis | ijohnson: devicestate tests are unhappy | 18:10 |
| ijohnson | pedronis: ah actually I know why this is happening, but I didn't think it would be caused until my next PR (where I have a fix for this) | 18:11 |
| ijohnson | pedronis: it seems I will need to bring that fix in | 18:11 |
| ijohnson | pedronis: not sure why it's caused by the modeenv branch, but the issue is that essentially the snap mapper (i.e. system -> core|snapd) doesn't get reset properly between the uc20 boot tests and uc16 ones | 18:12 |
| pedronis | interesting | 18:13 |
| ijohnson | the fix is to explicitly mock the snap mapper in devicestate in the test setup, adding a cleanup for the restore function | 18:13 |
| pedronis | it doesn't seem the problem though, it happens even running just one test | 18:16 |
| pedronis | ijohnson: it's Maciej last change actually | 18:21 |
| ijohnson | pedronis: oh well then it's not what I ran into then | 18:22 |
| ijohnson | pedronis: because what I ran into with my future changes was only a problem for multiple tests, not single ones | 18:22 |
| pedronis | yea, no, it's something related to faking Modeenv reading | 18:22 |
| * cachio afk | 18:24 | |
| ijohnson | pedronis: ok, I'll take care of it after my lunch if you haven't fixed it already | 18:24 |
| === ijohnson is now known as ijohnson|lunch | ||
| pedronis | ijohnson: I'm trying to fix it | 18:24 |
| ijohnson|lunch | pedronis: ok thanks | 18:24 |
| cachio | pedronis, hey, do you know if core20 supports cloud config to setup a user | 18:25 |
| cachio | I use cloud-init for core18 on nested vms | 18:25 |
| cachio | but I think what is failing on core20 is that the user is not being created properly | 18:26 |
| pedronis | cachio: not yet | 18:26 |
| pedronis | I think | 18:26 |
| pedronis | there's extra work to be done for it to work | 18:27 |
| cachio | pedronis, a user assertion could work? | 18:27 |
| pedronis | those maybe works | 18:27 |
| cachio | pedronis, ok, I'll try that, thanks!! | 18:27 |
| pedronis | done | 18:35 |
| pedronis | ijohnson|lunch: pushed something (analogous as what we do in bootloader.Find) | 18:36 |
| mup | PR snapd#7997 opened: overlord: increase settle timeout for slow machines <Created by mvo5> <https://github.com/snapcore/snapd/pull/7997> | 18:37 |
| mup | PR snapd#7998 opened: httputil: use shorter timeout in TestRetryRequestTimeoutHandling <Created by mvo5> <https://github.com/snapcore/snapd/pull/7998> | 18:39 |
| mup | PR snapd#7999 opened: devicestate: allow encryption regardless of grade <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7999> | 18:50 |
| === ijohnson|lunch is now known as ijohnson | ||
| ijohnson | pedronis: looks good to me, am I good to merge when green again? | 18:59 |
| ijohnson | I guess I hadn't totally understood the relationship between the various dirs.Snap___ variables and dirs.GlobalRootDir | 18:59 |
| pedronis | ijohnson: well it was simple and implicit, until because of UC20 we need to use them sometimes with rootdirs that are not "/" or the mocked value | 19:00 |
| ijohnson | right with the /run/mnt/ubuntu-boot and such | 19:01 |
| pedronis | to be clear we could also make the *Under functions more magic | 19:01 |
| pedronis | it wouldn't still cover 100% of the situations though | 19:02 |
| pedronis | so not sure | 19:02 |
| pedronis | it's mostly boot, bootloader that need to care | 19:02 |
| pedronis | ijohnson: but yes, feel free to merge if it gets green | 19:06 |
| ijohnson | pedronis: ack | 19:09 |
| mup | PR snapd#7991 closed: boot: add HasModeenv to Device <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7991> | 19:20 |
| mup | PR snapd#7994 closed: cmd/snap-discard-ns: fix pattern for .info files <Bug> <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7994> | 19:24 |
| mup | PR snapd#7996 closed: overlord/standby: fix possible deadlock in standby test <Simple 😃> <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7996> | 19:25 |
| mup | PR snapd#8000 opened: release: 2.43.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8000> | 19:34 |
| mvo | cachio: with a bit of luck I can give you 2.43.1 in beta tonight (well, my night :) | 19:37 |
| cachio | mvo, perfecto | 19:38 |
| cachio | I'll monitor the execution once it starts | 19:38 |
| mvo | cachio: thank you! just released and baby-sit the build for core now | 19:39 |
| cachio | mvo, nice, you can enjoy your night now :) | 19:39 |
| mvo | cachio: almost :) need to trigger the core-beta snap build once the ppa finished building :) but then I will enojoy the night! | 19:40 |
| ijohnson | cachio: where can I get a version of spread that can boot uc20 images with the PR's that Michael opened? do I just have to build it locally? I seem to remember you telling me about "spread2" that has all the patches we needed | 20:24 |
| cmatsuoka | ijohnson: I built it locally, not sure if it's available pre-built | 20:26 |
| ijohnson | cmatsuoka: sure fair enough. is it just https://github.com/snapcore/spread/pull/96 and https://github.com/snapcore/spread/pull/95 that need to be built into spread to boot uc20 ? | 20:27 |
| mup | PR spread#96: spread: add support for system specific "flags" and use in qemu <Created by mvo5> <https://github.com/snapcore/spread/pull/96> | 20:27 |
| mup | PR spread#95: spread: add support to define a custom bios with the qemu backend <Created by mvo5> <https://github.com/snapcore/spread/pull/95> | 20:27 |
| cachio | ijohnson, which PR? | 20:28 |
| cachio | 95? | 20:28 |
| ijohnson | cachio: the PR's I just mentioned, 95 and 96 I think ? | 20:28 |
| ijohnson | I don't know which PR's are fully needed | 20:29 |
| cachio | ijohnson, there is no spread with that | 20:29 |
| ijohnson | cachio: do I need those PR's to be able to boot uc20 with the ovmf/uefi stuff with the qemu backend? | 20:30 |
| cachio | ijohnson, I think just the 95 | 20:31 |
| cachio | you can just build it | 20:31 |
| ijohnson | cachio: ok I will build locally with 95 then | 20:31 |
| cachio | and use it | 20:31 |
| ijohnson | thanks | 20:31 |
| cachio | ijohnson, np | 20:31 |
| cmatsuoka | ijohnson: yes, I used those | 20:50 |
| cmatsuoka | ijohnson: one is to use ovmf, and the other is to use virtio? you'll need both, otherwise the system will take 2 minutes to boot | 20:52 |
| ijohnson | cmatsuoka: thanks yeah I built it with both of those patches | 21:22 |
| mup | PR snapcraft#2875 opened: WIP: split debug information <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2875> | 22:30 |
| mup | PR snapcraft#2239 closed: WIP: pluginhandler: after building a part, separate debug info from executables and strip them <Created by jhenstridge> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2239> | 22:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!