[04:45] PR snapd#8114 opened: boot: use variables for boot status values [06:26] morning [06:32] https://github.com/snapcore/snapd/pull/8108 needs a 2nd review [06:32] PR #8108: tests/main/interfaces-pulseaudio: use custom pulseaudio script, set kill timeout [06:35] same #8114 [06:35] PR #8114: boot: use variables for boot status values [06:40] quick round trip to school, back in 30 [07:09] re [08:00] morning [08:03] pstolowski: hey [08:05] wow, firefox 73 finally handles hidpi correctly [08:06] PR snapd#8114 closed: boot: use constants for boot status values [08:08] pedronis: hey, thanks for merging 8114, i'll proceed updating 8077 [08:21] mborzecki, hey, do you know if the support for default tracks in snapd is already merged? [08:23] abeato: it is in master, it will be in 2.44 [08:23] abeato: iirc it was, but rather recently, within last 2-3 weeks, pedronis probably has all the details [08:24] pedronis, mborzecki ok, thanks [08:34] PR snapd#8111 closed: tests: add new backend which includes images with tpm support [08:54] jamesh: hi, have you seen the questions in #7588 ? [08:54] PR #7588: cmd/snap: add a "snap routine portal-info" command [08:56] mborzecki: we should probably rename the signature in bootState as well to match what we used now in the implementations [08:56] Hi, anything new about #7927 [08:56] PR #7927: interfaces: x11 allow apparmor on classic [08:56] pedronis: right, good idea [08:57] thx [08:58] PR snapd#8115 opened: overlord/devicestate: fix preseed unit tests on systems not using /snap [08:58] pstolowski: ^^ [09:23] pedronis: sorry. I've been working through some changes on my other branch. I'll answer those q's now. [10:12] What would be preventing my snap from reading files from /usr/share (inside the confinement)? Getting pandoc template errors as it can't read the default templates, which are installed in the snap. [10:21] tomwardill: are you reading them from $SNAP/usr/share or from /usr/share? [10:21] zyga: /usr/share (prebuild application that I can't change) [10:21] tomwardill: then they are not installed in the snap [10:22] tomwardill: are they really in /usr/share from the perspective of the snap? In other words, are they in the base snap used by your application snap? [10:22] zyga: pandoc is apt installed during build [10:22] extracting the squashfs shows the files [10:22] thats $SNAP/usr/share then [10:22] (it's the pandoc templates I'm tyring to read) [10:22] tomwardill: again, then your snap contains those files but the application is not using them [10:23] tomwardill: it is attempting to use files from /usr/share [10:23] tomwardill: I'm trying to explain the crucial difference [10:23] layouts to the rescue? [10:23] yeah [10:23] tomwardill: your application is not the root filesystem of the snap application process [10:23] oh, right, I see. [10:23] a layout can fake $SNAP/usr/share to look like /usr/share to your application [10:23] tomwardill: you can ship and access arbitrary files but they are in a runtime-variable location at $SNAP [10:24] tomwardill: you can use one of the mechanism we have to alleviate that, but it depends on circumstances [10:24] tomwardill: usually layouts are a good first try [10:24] tomwardill: they are documented on the snapcraft website, let me know if you need a link [10:24] I've seen the docs for that, I'll give it a try [10:24] thanks for the help :) [10:25] tomwardill: pleasure :) let me know if it worked in the end :) [10:40] mborzecki: not urgent but I made a suggestion about how to try to close #6708 [10:40] PR #6708: packaging/ubuntu: enable PIE hardening flags <⛔ Blocked> [11:25] cachio: hi, do you know when was the last time centos 7 images were updated? [11:29] Hi, does the snap sandbox prevent dbus activation of services? If I call e.g. notifications service when it isn't running, my snap says "name has no owner" and fails. With a git build running regularly it launches the service and continues [11:32] PR snapd#8116 opened: test/lib/user: add helper lib for doing things for and as a user [11:34] kbroulik: is that on ubuntu? [11:34] yes [11:34] it appears an "Introspect" call to a dbus service isnt allowed? [11:35] kbroulik: right, so there's a known (is it?) problem that the policy allows for a snap app to talk to an 'unconfined' service over dbus, but until the service has actually launched, dbus does not know what context that service would have [11:35] okay [11:35] PR snapd#8117 opened: tests: add preseed test for classic [11:36] mborzecki: also "ListActivatableNames" isnt allowed either, so I cant have my app check for that either [11:36] kbroulik: so the dbus *.service files of your host services need to have `AssumedAppArmorLabel=unconfined` or the service must be already running [11:37] kbroulik: if it's a particular service in ubuntu then maybe you could file a bug, i know that the desktop team added that snippet to some of the portal services upstreams [11:38] it's a weird kde plasma specific [11:38] mborzecki, 1 week ago [11:38] I mean, the service is standard (freedesktop notifications) but plasma does something mental with it [11:38] mborzecki, hi [11:38] you mean LinuxSecurityLabel? [11:38] mborzecki, feb-3 [11:38] kbroulik: no, `AssumedAppArmorLabel=unconfined` [11:39] okay [11:39] mborzecki, I just retrigger again the update [11:39] mborzecki: will this be ignored by others not supporting it? [11:39] kbroulik: afaik for gnome-shell the notification service is part of the shell process, so it's up already before one even starts snap apps [11:39] mborzecki: yeah in plasma it's not, and with recent startup improvements we now start autostart so fast the apps come up before the desktop is fully ready :) [11:40] kbroulik: haha must be fun [11:40] normally it wouldnt be a problem if people stopped using stupid QDBusInterface class [11:40] kbroulik: the key is part of upstream spec, https://dbus.freedesktop.org/doc/dbus-specification.html see `Mediating Activation with AppArmor` [11:40] I looked at that document and Ctrl+F'd for it... :) [11:41] oh well, thanks, I'll discuss it with my fellow devs [11:41] so, that "assumed" means, when you call something anyone can do it but once launched regular policies still apply? [11:41] *when you call when it's not running, I mean [11:42] kbroulik: i'm no expert on this, but yeah, that'd be my guess [11:42] ok I'll give it a go [11:42] thanks very much [11:42] cachio: cool, i got a notification about that https://bugs.centos.org/view.php?id=16441#c36261 so maybe it'll work this time [11:43] mborzecki, yesterday failed because an error with a mirror trying to update [11:43] mborzecki, lets wait a bit to see the results today [11:43] hopefully the systemd error is gone [11:44] cachio: btw. noticed your note in https://github.com/snapcore/snapd/pull/8058 do yout want to discuss that in/after the standup? [11:45] PR #8058: run-checks, travis: allow skipping spread jobs by adding a label <⛔ Blocked> [11:45] (or before whatver's more convenient) [11:45] mborzecki, during [11:45] ok [11:45] we decided that last friday but then I forgot it [11:46] ok, np [11:46] huh google:arch-linux-64:tests/main/static failed ? [11:47] mborzecki: hmm doesnt work in my case.. I believe the "Introspect" call isnt allowed, or does "unconfined" allow any call to that service? [11:48] kbroulik: isn't Introspect part of the org.freedesktop.DBus inteface? [11:48] mborzecki: it's on the org.freedesktop.DBus.Introspectable [11:50] kbroulik: hmm but that would still be a traffic that does to the service, wouldn't it? can you try adding that snippet to *.service locally? [11:50] I added it, to no effect [11:50] I dont see a DENIED introspect call in dmesg either, though [11:50] oof why cant we have nice things :/ [11:51] kbroulik: was dbus reloaded/restarted ? [11:51] ah, yeah the introspect call was denied [11:51] An AppArmor policy prevents this sender from sending this message to this recipien [11:53] mborzecki: I thought that was automatic? I did send a SIGHUP to dbus-daemon though [11:54] "There is no way to cause the D-BUS daemon to reload its configuration file" heh [11:55] mvo: reported as https://bugs.launchpad.net/snapd/+bug/1862761 [11:56] Bug #1862761: core systems using core18 boot base cannot unmount writable cleanly [12:01] kbroulik: systemctl restart --user ? iirc dbus also had inotify on the service directories, so maybe it's already reloaded ? [12:01] kbroulik: this is how your plasma service should look like https://paste.ubuntu.com/p/MsrhGFv9gX/ [12:01] oh, and arch updated glibc to 2.31 and master is thus broken ;P [12:02] PR snapd#8118 opened: tests/main/static: ldd in glibc 2.31 logs to stderr now <⚠ Critical> [12:03] this should fix it ^^ [12:09] mborzecki: heh, well, my system didnt like that at all :D so now I'm going to have to log out [12:09] kbroulik:hah ;) [12:12] mborzecki: yeah think that didnt help. It's probably that Introspect call being denied. *but* since nobody should ever use QDBusInterface: if that is ported away and done properly, ideally we'd just do a GetCapabilities call and see if that works or fails and call it a day [12:12] a call which we do later anyway [12:12] i.e. when using dbus one should never check for services, just call and see what happens [12:13] corba of the desktops [12:15] mborzecki, centos updated [12:15] cachio: thanks! [12:15] lets see now how it works [12:15] zyga: \o/ in a meeting - thank you! [12:15] mborzecki, to you [12:56] * zyga goes to make coffee [12:58] mborzecki: do you think the user helper could become a non-source but execute helper? [12:59] mborzecki: to again put boundaries on dependencies [12:59] mborzecki: it would also make it easier to use from things like retry-tool [13:02] zyga: maybe, depends on how much time we want to put in it tbh [13:02] mborzecki: just add a switch statement at the bottom [13:02] mborzecki: and run the functions you wrote [13:03] mborzecki: then it becomes user stop-session|start-session etc etc [13:17] * zyga breaks for coffee and some food [13:44] hmm https://forum.snapcraft.io/t/updating-the-current-link-in-the-home-directory-does-not-work/15406/7 i think it'd be weird if snapd started updating that randomly [13:44] and certainly there'd be more user drama [13:57] PR snapcraft#2925 closed: project loader: use get_build_base() to assign plugin handler base [13:57] PR snapcraft#2926 opened: plugin handler: process elf files only if base is specified [13:58] ijohnson: https://github.com/snapcore/snapcraft/pull/2926 is the workaround you're looking for :) [13:58] PR snapcraft#2926: plugin handler: process elf files only if base is specified [13:59] * ijohnson didn't know cjp256 knew the ways of the force [13:59] has anybody seens this kind of error: https://api.travis-ci.org/v3/job/648850614/log.txt [13:59] i'm quite adept at force pushes [14:00] ijohnson: ^ [14:00] pedronis: will look after SU [14:01] pedronis: I haven't seen that error [14:01] pedronis: I've seen that "in the wild" on my UC20 test machines [14:05] PR snapd#8119 opened: [RFC] httputil: add NoNetwork(err) helper and spread test [14:09] jdstrand: hello [14:09] jdstrand: I've updated https://github.com/snapcore/snapd/pull/7980 -- would love to know if you can look at the changes [14:10] PR #7980: packaging,snap-confine: stop being setgid root [14:10] jdstrand: there are two more PRs that are ready for review but I'll hold on until you ping me you can do those [14:10] ijohnson: got they impression, they access some snap user data via $HOME/snap//current, which becomes broken when snap gets updated but a given user runs it rarely [14:41] PR snapd#8058 closed: run-checks, travis: allow skipping spread jobs by adding a label [14:41] yay [14:51] PR snapd#8120 opened: cmd/snap-preseed: snapd version check for the target [14:54] PR snapcraft#2918 closed: elf: ensure _GNU_VERSION_R section is of type GNUVerNeedSection [14:58] brb, 2nd coffee and a hunt for a memory card adapter [15:07] jdstrand, hey, there is this new 'primed-stage-packages' section in the manifest generated by snapcraft. This is a list of the packages that were really primed into the snap. Is there any plan to leverage this on review tools and use it instead of 'staged-packages'? [15:07] cjp256, ^^ [15:26] PR snapd#8118 closed: tests/main/static: ldd in glibc 2.31 logs to stderr now <⚠ Critical> [15:30] mvo: I pushed extra test data to https://github.com/snapcore/snapd/pull/8113 after your approval - if you want to re-view please do [15:30] PR #8113: cmd/snap-confine: bring /var/lib/dhcp from host, if present [15:30] mvo: (mount-ns test changes reflecting the new mount) [15:30] zyga: thank you, looking [15:31] zyga: that should be fine [15:35] ijohnson: some comments in #8077, my head goes round with bootState20* things :) [15:35] PR #8077: boot: enable base snap updates in bootstate20 [15:38] mborzecki: thanks, I see I forgot to actually push that revert thanks for doing so :-) [15:38] ijohnson: no problem, reverted it and pushed with some other updates [15:39] mborzecki: thanks will take a look in a little bit, trying to finish review of pstolowski's PR [15:41] mborzecki: will you merge master to #8108 ? [15:41] PR #8108: tests/main/interfaces-pulseaudio: use custom pulseaudio script, set kill timeout [15:41] also should probably get another +1 from somebody other than me as I changed the PR a bit [15:42] ijohnson: right, pushing now [15:42] and off to do some groceries [15:44] thanks mborzecki [15:45] abeato (cc cjp256): there is. the review-tools should be updated soonish [15:46] jdstrand, cool, that's great news [15:46] zyga: ack. for now make sure that whatever is needed for 2.44 is milestoned for that. (7980 is on that list) [15:47] jdstrand: thank you! [15:50] sergiusens, cjp256, jdstrand I was also wondering if there could be an option in snapcraft to inject entries in 'primed-stage-packages'. In snaps that we build based on the deb sources, but recompiling (like network-manager) with patches on top, we would like to still receive CVEs without needing to hack review tools [15:56] * cachio lunch [15:56] abeato: interesting case [15:58] some times we were putting packages in 'stage-packages' but not really priming them . with this change that technique is not going to work anymore [16:03] abeato: the alternative is to allow for reporting of the current stage-packages as a fallback... the solution you are using is quite hackish though [16:04] abeato: did you ask awe about his plan for doing that? I proposed exactly what you were saying to him a long time ago and he said there was a better way, I don't recall the details however [16:04] sergiusens, that's why I'd like a snapcraft option ;) - like report-packages [16:04] abeato: seems like a very specific workaround for a very specific scenario you have [16:06] abeato: why not track the udd (or equivalent) of the source package and get auto builds for those? [16:07] we still keep both in manifest.yaml, at the end of the day, the reporting tool should allow you to toggle that if you want [16:09] sergiusens, that's an alternative... [16:10] pstolowski: I reviewed #8046, is the next one I should look at #8102 ? [16:10] PR #8046: many, tests: integrate all preseed bits and add spread tests [16:10] PR #8102: o/ifacestate: move ResolveDisconnect to ifacestate [16:10] but maybe adding packges for CVE notifications can be useful in other scenarios. not sure... [16:11] ijohnson, hm, I do not think there was an alternative to the staging hack [16:11] ijohnson: thanks! sure that will help too, it's for snap disconnect --forget [16:11] abeato: would rather have a generic "subscription" mechanism for this [16:12] abeato: perhaps I am mis-remembering [16:12] ack pstolowski [16:12] but this is something for the security team to drive [16:12] right [16:13] the thing to keep in mind is that the review-tools don't know that the git source you are using is coming from ubuntu [16:14] so we have to hint it somehow. one way is the review-tools that we currently do. another is to shove something into stage or prime or something [16:14] a different key could be introduced in the manifest.yaml that it could consider [16:14] jdstrand, lately we are using the auto-imported branches. Like [16:14] source: https://git.launchpad.net/ubuntu/+source/network-manager [16:14] source-type: git [16:14] source-branch: applied/1.10.6-2ubuntu1.2 [16:14] would that be manageable from review-tools? [16:15] abeato: that's great! [16:15] abeato: maybe. it kinda feels like the wrong level though [16:15] PR snapcraft#2927 opened: requirements: uprev lxml to 4.5.0 [16:16] abeato: I'll take a look at the nm manifest.yaml and think about it [16:16] jdstrand, ok, note that this is for the 1.10 branch - let me find the link [16:17] jdstrand, https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/snap/snapcraft.yaml?h=snap-1.10 [16:18] jdstrand, also: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/modem-manager/tree/snapcraft.yaml?h=snap-1.10 [16:18] ok, thanks [16:26] jdstrand: hi, have you seen this discussion https://github.com/snapcore/snapd/pull/7588#discussion_r377526563? it's about which interface should offer access to network status when running with portals [16:26] PR #7588: cmd/snap: add a "snap routine portal-info" command [16:27] pstolowski: do you have time to quickly check about the prune issue now? [16:28] pedronis: yes [16:28] let's [16:28] pstolowski: ok, let's use the standup [16:30] pedronis: I see it in my inbox, new today. I haven't read it yet [16:43] * zyga goes for dinner [17:03] pstolowski, pedronis: https://github.com/snapcore/snapd/pull/8102#discussion_r377770429 [17:03] PR #8102: o/ifacestate: move ResolveDisconnect to ifacestate [17:09] PR snapcraft#2921 closed: storeapi: remove exposure of series [17:12] zyga: good question! [17:16] i need to think [17:22] eod, cu [17:29] I will EOD soon but want to inspect one more time this weird bug I found [17:29] mvo: some early ideas on oom [17:30] mvo: snap set system oom-order=snap-a,snap-b,snap-d [17:30] would protect snap-a from oom more than snap-b, snapd-d and other parts of the system [17:30] mvo: (the name should probably oom-protect instead of oom-order but I wanted to imply there's an order) [17:31] mvo: another idea is to provide a privileged interface that allows smart snaps to set up oom protection using any current kernel features [17:31] mvo: the burden and responsibility shifts [17:32] mvo: I'll explore two more ideas tomorrow [17:32] for now I'm off [18:11] pedronis: if you're still around quick question about cleaning the boot variables... is it reasonable to assume in the `commit()` implementation for markSuccessful that it will always be called with both kernel + base snaps markSuccessful() called on the bootStateUpdate ? [18:11] pedronis: if so then the auto-cleaning logic is much simpler and we can get rid of one of the return values from genericMarkSuccessful I think [18:12] ijohnson: yes, in the sense that's controlled by code inside the package, MarkBootSucceful in boot.go [18:12] ok, thanks that simplifies things [18:12] * ijohnson lunches [18:13] ijohnson: please double check the code there matches you expect [18:13] *what you [18:35] pedronis: yes it does match, my question was more about whether the current implementation of MarkBootSuccessful in boot.go can be relied on in bootstate20.go [18:36] ijohnson: yes, they are within the same package, feel free to add comments though if helps somebody doing changes down the lien [18:36] *line [18:37] I'll add comments as to what the assumptions I'm making [18:37] err that was awkwardly phrased ... I'll add comments about it there :-) [19:46] jdstrand: if you want to chat about any of my branches I'm available [19:57] zyga, jdstrand just told me to file this bug and ping you: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1862832 [19:57] Bug #1862832: Latest snapd triggers apparmor denials on 'sendmsg' name=/run/nvidia-xdriver-xxxx [19:57] aha [19:57] looking [19:58] techalchemy: thank you, I'll look at reproducing that back in the office tomorrow [19:59] thanks, I haven't noticed any issues besides the logs [19:59] techalchemy: does the application still operate correctly? [19:59] aha [19:59] the one we were looking at doesn't but that was because I built it with an old version of electron builder and it plugs pulseaudio [20:00] incidentally I looked at the second snap causing the issue and it also still plugs pulseaudio, it seems unlikely that would be the cause but I guess I've seen stranger things [20:01] it's a shame the peer addr is ... whatever it is [20:01] * zyga wonders [20:01] it's the same socket as is mentioned elsewhere in the logs [20:02] (sorry for the highlights) Decoded: var/run/nvidia-xdriver-f8177d9f [20:06] techalchemy: note, the pulseaudio stuff is unrelated to the nvidia stuff. I hadn't seen the logs yet when we were talking about audio, shm, etc [20:06] jdstrand: having you here, do you have an idea what that peer address represents? [20:06] Feb 11 13:59:41 utumno kernel: audit: type=1400 audit(1581447581.792:10272): apparmor="DENIED" operation="sendmsg" profile="snap.pomotroid.pomotroid" pid=1505247 comm="pomotroid" family="unix" sock_type="dgram" protocol=0 requested_mask="send" denied_mask="send" addr=none peer_addr="@7661722F72756E2F6E76696469612D786472697665722D66383137376439660000000000000000000000000000000000000000000000000000000000000000" [20:06] peer="unconfined" [20:06] techalchemy: this is the pulse issue: https://forum.snapcraft.io/t/upcoming-pulseaudio-interface-deprecation/13418/10 [20:06] that's not even a pointer [20:07] zyga: yeah, snap.pomotroid.pomotroid is trying to talk to @var/run/nvidia-xdriver-f8177d9f [20:07] jdstrand, yeah i just noticed that the other snaps causing the issue are also still plugging the pulseaudio slot rather than the new audio-playback slot [20:07] jdstrand: how did you derive @var/run/ from that number? [20:07] is that some base encoding? [20:07] zyga: and is being denied. there is also (in the bug) a non-abstract path in /run [20:07] aha [20:08] zyga: the aa-decode command techalchemy gave [20:08] oh i didn't post the command, woops [20:08] aa-decode @7661722F72756E2F6E76696469612D786472697665722D66383137376439660000000000000000000000000000000000000000000000000000000000000000 [20:08] but, '@' isn't accepted by that command, so you drop it to decode, then prepend it [20:09] zyga: there are nuls in that string so the kernel encoded it [20:09] hmmm [20:09] Jamie Strandboge aa-decode @7661722F72756E2F6E76696469612D786472697665722D66383137376439660000000000000000000000000000000000000000000000000000000000000000 [20:09] er [20:09] aa-decode @7661722F72756E2F6E76696469612D786472697665722D66383137376439660000000000000000000000000000000000000000000000000000000000000000 [20:09] String should only contain hex characters (0-9, a-f, A-F) [20:09] that doesn't work for me on focal? [20:09] zyga: did you read my next sentence? :) [20:09] ah, no [20:10] missed it among the paste [20:10] is this encoding something new? I haven't seen it before [20:10] PR snapcraft#2928 opened: logging: use .warning instead of deprecated .warn [20:10] but this helps a lot [20:10] zyga: did you see the next sentence after that? :) [20:11] zyga: it isn't new to the kernel as the string is determined by userspace [20:12] zyga: so, there are two denials: [20:12] /run/nvidia-xdriver-f8177d9f [20:12] and @var/run/nvidia-xdriver-f8177d9f [20:12]