[04:45] <mup> PR snapd#8114 opened: boot: use variables for boot status values <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8114>
[06:26] <mborzecki> morning
[06:32] <mborzecki> https://github.com/snapcore/snapd/pull/8108 needs a 2nd review
[06:32] <mup> PR #8108: tests/main/interfaces-pulseaudio: use custom pulseaudio script, set kill timeout <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8108>
[06:35] <mborzecki> same #8114
[06:35] <mup> PR #8114: boot: use variables for boot status values <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8114>
[06:40] <mborzecki> quick round trip to school, back in 30
[07:09] <mborzecki> re
[08:00] <pstolowski> morning
[08:03] <mborzecki> pstolowski: hey
[08:05] <mborzecki> wow, firefox 73 finally handles hidpi correctly
[08:06] <mup> PR snapd#8114 closed: boot: use constants for boot status values <Simple 😃> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8114>
[08:08] <mborzecki> pedronis: hey, thanks for merging 8114, i'll proceed updating 8077
[08:21] <abeato> mborzecki, hey, do you know if the support for default tracks in snapd is already merged?
[08:23] <pedronis> abeato: it is in master, it will be in 2.44
[08:23] <mborzecki> abeato: iirc it was, but rather recently, within last 2-3 weeks, pedronis probably has all the details
[08:24] <abeato> pedronis, mborzecki ok, thanks
[08:34] <mup> PR snapd#8111 closed: tests: add new backend which includes images with tpm support <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8111>
[08:54] <pedronis> jamesh: hi, have you seen the questions in #7588 ?
[08:54] <mup> PR #7588: cmd/snap: add a "snap routine portal-info" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7588>
[08:56] <pedronis> mborzecki: we should probably rename the signature in bootState as well to match what we used now in the implementations
[08:56] <sdhd-sascha> Hi, anything new about #7927
[08:56] <mup> PR #7927: interfaces: x11 allow apparmor on classic <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7927>
[08:56] <mborzecki> pedronis: right, good idea
[08:57] <pedronis> thx
[08:58] <mup> PR snapd#8115 opened: overlord/devicestate: fix preseed unit tests on systems not using /snap <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8115>
[08:58] <mborzecki> pstolowski: ^^
[09:23] <jamesh> pedronis: sorry.  I've been working through some changes on my other branch.  I'll answer those q's now.
[10:12] <tomwardill> 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] <zyga> tomwardill: are you reading them from $SNAP/usr/share or from /usr/share?
[10:21] <tomwardill> zyga: /usr/share (prebuild application that I can't change)
[10:21] <zyga> tomwardill: then they are not installed in the snap
[10:22] <zyga> 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] <tomwardill> zyga: pandoc is apt installed during build
[10:22] <tomwardill> extracting the squashfs shows the files
[10:22] <ogra> thats $SNAP/usr/share then
[10:22] <tomwardill> (it's the pandoc templates I'm tyring to read)
[10:22] <zyga> tomwardill: again, then your snap contains those files but the application is not using them
[10:23] <zyga> tomwardill: it is attempting to use files from /usr/share
[10:23] <zyga> tomwardill: I'm trying to explain the crucial difference
[10:23] <mborzecki> layouts to the rescue?
[10:23] <ogra> yeah
[10:23] <zyga> tomwardill: your application is not the root filesystem of the snap application process
[10:23] <tomwardill> oh, right, I see.
[10:23] <ogra> a layout can fake $SNAP/usr/share to look like /usr/share to your application
[10:23] <zyga> tomwardill: you can ship and access arbitrary files but they are in a runtime-variable location at $SNAP
[10:24] <zyga> tomwardill: you can use one of the mechanism we have to alleviate that, but it depends on circumstances
[10:24] <zyga> tomwardill: usually layouts are a good first try
[10:24] <zyga> tomwardill: they are documented on the snapcraft website, let me know if you need a link
[10:24] <tomwardill> I've seen the docs for that, I'll give it a try
[10:24] <tomwardill> thanks for the help :)
[10:25] <zyga> tomwardill: pleasure :) let me know if it worked in the end :)
[10:40] <pedronis> mborzecki: not urgent but I made a suggestion about how to try to close #6708
[10:40] <mup> PR #6708: packaging/ubuntu: enable PIE hardening flags <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>
[11:25] <mborzecki> cachio: hi, do you know when was the last time centos 7 images were updated?
[11:29] <kbroulik> 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] <mup> PR snapd#8116 opened: test/lib/user: add helper lib for doing things for and as a user <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8116>
[11:34] <mborzecki> kbroulik: is that on ubuntu?
[11:34] <kbroulik> yes
[11:34] <kbroulik> it appears an "Introspect" call to a dbus service isnt allowed?
[11:35] <mborzecki> 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] <kbroulik> okay
[11:35] <mup> PR snapd#8117 opened: tests: add preseed test for classic <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8117>
[11:36] <kbroulik> mborzecki: also "ListActivatableNames" isnt allowed either, so I cant have my app check for that either
[11:36] <mborzecki> kbroulik: so the dbus *.service files of your host services need to have `AssumedAppArmorLabel=unconfined` or the service must be already running
[11:37] <mborzecki> 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] <kbroulik> it's a weird kde plasma specific
[11:38] <cachio> mborzecki, 1 week ago
[11:38] <kbroulik> I mean, the service is standard (freedesktop notifications) but plasma does something mental with it
[11:38] <cachio> mborzecki, hi
[11:38] <kbroulik> you mean LinuxSecurityLabel?
[11:38] <cachio> mborzecki, feb-3
[11:38] <mborzecki> kbroulik: no, `AssumedAppArmorLabel=unconfined`
[11:39] <kbroulik> okay
[11:39] <cachio> mborzecki, I just retrigger again the update
[11:39] <kbroulik> mborzecki: will this be ignored by others not supporting it?
[11:39] <mborzecki> 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] <kbroulik> 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] <mborzecki> kbroulik: haha must be fun
[11:40] <kbroulik> normally it wouldnt be a problem if people stopped using stupid QDBusInterface class
[11:40] <mborzecki> kbroulik: the key is part of upstream spec, https://dbus.freedesktop.org/doc/dbus-specification.html see `Mediating Activation with AppArmor`
[11:40] <kbroulik> I looked at that document and Ctrl+F'd for it... :)
[11:41] <kbroulik> oh well, thanks, I'll discuss it with my fellow devs
[11:41] <kbroulik> so, that "assumed" means, when you call something anyone can do it but once launched regular policies still apply?
[11:41] <kbroulik> *when you call when it's not running, I mean
[11:42] <mborzecki> kbroulik: i'm no expert on this, but yeah, that'd be my guess
[11:42] <kbroulik> ok I'll give it a go
[11:42] <kbroulik> thanks very much
[11:42] <mborzecki> 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] <cachio> mborzecki, yesterday failed because an error with a mirror trying to update
[11:43] <cachio> mborzecki, lets wait a bit to see the results today
[11:43] <cachio> hopefully the systemd error is gone
[11:44] <mborzecki> 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] <mup> PR #8058: run-checks, travis: allow skipping spread jobs by adding a label <Skip spread> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8058>
[11:45] <mborzecki> (or before whatver's more convenient)
[11:45] <cachio> mborzecki, during
[11:45] <mborzecki> ok
[11:45] <cachio> we decided that last friday but then I forgot it
[11:46] <mborzecki> ok, np
[11:46] <mborzecki> huh google:arch-linux-64:tests/main/static failed ?
[11:47] <kbroulik> 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] <mborzecki> kbroulik: isn't Introspect part of the org.freedesktop.DBus inteface?
[11:48] <kbroulik> mborzecki: it's on the org.freedesktop.DBus.Introspectable
[11:50] <mborzecki> 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] <kbroulik> I added it, to no effect
[11:50] <kbroulik> I dont see a DENIED introspect call in dmesg either, though
[11:50] <kbroulik> oof why cant we have nice things :/
[11:51] <mborzecki> kbroulik: was dbus reloaded/restarted ?
[11:51] <kbroulik> ah, yeah the introspect call was denied
[11:51] <kbroulik> An AppArmor policy prevents this sender from sending this message to this recipien
[11:53] <kbroulik> mborzecki: I thought that was automatic? I did send a SIGHUP to dbus-daemon though
[11:54] <kbroulik> "There is no way to cause the D-BUS daemon to reload its configuration file" heh
[11:55] <zyga> mvo: reported as https://bugs.launchpad.net/snapd/+bug/1862761
[11:56] <mup> Bug #1862761: core systems using core18 boot base cannot unmount writable cleanly <snapd:New> <https://launchpad.net/bugs/1862761>
[12:01] <mborzecki> kbroulik: systemctl restart --user ? iirc dbus also had inotify on the service directories, so maybe it's already reloaded ?
[12:01] <mborzecki> kbroulik: this is how your plasma service should look like https://paste.ubuntu.com/p/MsrhGFv9gX/
[12:01] <mborzecki> oh, and arch updated glibc to 2.31 and master is thus broken ;P
[12:02] <mup> PR snapd#8118 opened: tests/main/static: ldd in glibc 2.31 logs to stderr now <Simple 😃> <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8118>
[12:03] <mborzecki> this should fix it ^^
[12:09] <kbroulik> mborzecki: heh, well, my system didnt like that at all :D so now I'm going to have to log out
[12:09] <mborzecki> kbroulik:hah ;)
[12:12] <kbroulik> 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] <kbroulik> a call which we do later anyway
[12:12] <kbroulik> i.e. when using dbus one should never check for services, just call and see what happens
[12:13] <mborzecki> corba of the desktops
[12:15] <cachio> mborzecki, centos updated
[12:15] <mborzecki> cachio: thanks!
[12:15] <cachio> lets see now how it works
[12:15] <mvo> zyga: \o/ in a meeting - thank you!
[12:15] <cachio> mborzecki, to you
[12:56]  * zyga goes to make coffee
[12:58] <zyga> mborzecki: do you think the user helper could become a non-source but execute helper?
[12:59] <zyga> mborzecki: to again put boundaries on dependencies
[12:59] <zyga> mborzecki: it would also make it easier to use from things like retry-tool
[13:02] <mborzecki> zyga: maybe, depends on how much time we want to put in it tbh
[13:02] <zyga> mborzecki: just add a switch statement at the bottom
[13:02] <zyga> mborzecki: and run the functions you wrote
[13:03] <zyga> mborzecki: then it becomes user stop-session|start-session etc etc
[13:17]  * zyga breaks for coffee and some food
[13:44] <mborzecki> 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] <mborzecki> and certainly there'd be more user drama
[13:57] <mup> PR snapcraft#2925 closed: project loader: use get_build_base() to assign plugin handler base <Created by cjp256> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2925>
[13:57] <mup> PR snapcraft#2926 opened: plugin handler: process elf files only if base is specified <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2926>
[13:58] <cjp256> ijohnson: https://github.com/snapcore/snapcraft/pull/2926 is the workaround you're looking for :)
[13:58] <mup> PR snapcraft#2926: plugin handler: process elf files only if base is specified <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2926>
[13:59]  * ijohnson didn't know cjp256 knew the ways of the force
[13:59] <pedronis> has anybody seens this kind of error: https://api.travis-ci.org/v3/job/648850614/log.txt
[13:59] <cjp256> i'm quite adept at force pushes
[14:00] <pedronis> ijohnson: ^
[14:00] <ijohnson> pedronis: will look after SU
[14:01] <zyga> pedronis: I haven't seen that error
[14:01] <ijohnson> pedronis: I've seen that "in the wild" on my UC20 test machines
[14:05] <mup> PR snapd#8119 opened: [RFC] httputil: add NoNetwork(err) helper and spread test <Created by mvo5> <https://github.com/snapcore/snapd/pull/8119>
[14:09] <zyga> jdstrand: hello
[14:09] <zyga> jdstrand: I've updated https://github.com/snapcore/snapd/pull/7980 -- would love to know if you can look at the changes
[14:10] <mup> PR #7980: packaging,snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7980>
[14:10] <zyga> 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] <mborzecki> ijohnson: got they impression, they access some snap user data via $HOME/snap/<name>/current, which becomes broken when snap gets updated but a given user runs it rarely
[14:41] <mup> PR snapd#8058 closed: run-checks, travis: allow skipping spread jobs by adding a label <Skip spread> <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8058>
[14:41] <mborzecki> yay
[14:51] <mup> PR snapd#8120 opened: cmd/snap-preseed: snapd version check for the target <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8120>
[14:54] <mup> PR snapcraft#2918 closed: elf: ensure _GNU_VERSION_R section is of type GNUVerNeedSection <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2918>
[14:58] <zyga> brb, 2nd coffee and a hunt for a memory card adapter
[15:07] <abeato> 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] <abeato> cjp256, ^^
[15:26] <mup> PR snapd#8118 closed: tests/main/static: ldd in glibc 2.31 logs to stderr now <Simple 😃> <⚠ Critical> <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8118>
[15:30] <zyga> 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] <mup> PR #8113: cmd/snap-confine: bring /var/lib/dhcp from host, if present <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8113>
[15:30] <zyga> mvo: (mount-ns test changes reflecting the new mount)
[15:30] <mvo> zyga: thank you, looking
[15:31] <mvo> zyga: that should be fine
[15:35] <mborzecki> ijohnson: some comments in #8077, my head goes round with bootState20* things :)
[15:35] <mup> PR #8077: boot: enable base snap updates in bootstate20 <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8077>
[15:38] <ijohnson> mborzecki: thanks, I see I forgot to actually push that revert thanks for doing so :-)
[15:38] <mborzecki> ijohnson: no problem, reverted it and pushed with some other updates
[15:39] <ijohnson> mborzecki: thanks will take a look in a little bit, trying to finish review of pstolowski's PR
[15:41] <ijohnson> mborzecki: will you merge master to #8108 ?
[15:41] <mup> PR #8108: tests/main/interfaces-pulseaudio: use custom pulseaudio script, set kill timeout <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8108>
[15:41] <ijohnson> also should probably get another +1 from somebody other than me as I changed the PR a bit
[15:42] <mborzecki> ijohnson: right, pushing now
[15:42] <mborzecki> and off to do some groceries
[15:44] <ijohnson> thanks mborzecki
[15:45] <jdstrand> abeato (cc cjp256): there is. the review-tools should be updated soonish
[15:46] <abeato> jdstrand, cool, that's great news
[15:46] <jdstrand> zyga: ack. for now make sure that whatever is needed for 2.44 is milestoned for that. (7980 is on that list)
[15:47] <zyga> jdstrand: thank you!
[15:50] <abeato> 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] <cjp256> abeato: interesting case
[15:58] <abeato> 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] <sergiusens> 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] <ijohnson> 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] <abeato> sergiusens, that's why I'd like a snapcraft option ;) - like report-packages
[16:04] <sergiusens> abeato: seems like a very specific workaround for a very specific scenario you have
[16:06] <sergiusens> abeato: why not track the udd (or equivalent) of the source package and get auto builds for those?
[16:07] <sergiusens> 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] <abeato> sergiusens, that's an alternative...
[16:10] <ijohnson> pstolowski: I reviewed #8046, is the next one I should look at #8102 ?
[16:10] <mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
[16:10] <mup> PR #8102: o/ifacestate: move ResolveDisconnect to ifacestate <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8102>
[16:10] <abeato> but maybe adding packges for CVE notifications can be useful in other scenarios. not sure...
[16:11] <abeato> ijohnson, hm, I do not think there was an alternative to the staging hack
[16:11] <pstolowski> ijohnson: thanks! sure that will help too, it's for snap disconnect --forget
[16:11] <sergiusens> abeato: would rather have a generic "subscription" mechanism for this
[16:12] <ijohnson> abeato: perhaps I am mis-remembering
[16:12] <ijohnson> ack pstolowski
[16:12] <sergiusens> but this is something for the security team to drive
[16:12] <abeato> right
[16:13] <jdstrand> 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] <jdstrand> 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] <jdstrand> a different key could be introduced in the manifest.yaml that it could consider
[16:14] <abeato> jdstrand, lately we are using the auto-imported branches. Like
[16:14] <abeato>     source: https://git.launchpad.net/ubuntu/+source/network-manager
[16:14] <abeato>     source-type: git
[16:14] <abeato>     source-branch: applied/1.10.6-2ubuntu1.2
[16:14] <abeato> would that be manageable from review-tools?
[16:15] <jdstrand> abeato: that's great!
[16:15] <jdstrand> abeato: maybe. it kinda feels like the wrong level though
[16:15] <mup> PR snapcraft#2927 opened: requirements: uprev lxml to 4.5.0 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2927>
[16:16] <jdstrand> abeato: I'll take a look at the nm manifest.yaml and think about it
[16:16] <abeato> jdstrand, ok, note that this is for the 1.10 branch - let me find the link
[16:17] <abeato> jdstrand, https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/snap/snapcraft.yaml?h=snap-1.10
[16:18] <abeato> jdstrand, also: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/modem-manager/tree/snapcraft.yaml?h=snap-1.10
[16:18] <jdstrand> ok, thanks
[16:26] <pedronis> 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] <mup> PR #7588: cmd/snap: add a "snap routine portal-info" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7588>
[16:27] <pedronis> pstolowski: do you have time to quickly check about the prune issue now?
[16:28] <pstolowski> pedronis: yes
[16:28] <pstolowski> let's
[16:28] <pedronis> pstolowski: ok, let's use the standup
[16:30] <jdstrand> pedronis: I see it in my inbox, new today. I haven't read it yet
[16:43]  * zyga goes for dinner 
[17:03] <zyga> pstolowski, pedronis: https://github.com/snapcore/snapd/pull/8102#discussion_r377770429
[17:03] <mup> PR #8102: o/ifacestate: move ResolveDisconnect to ifacestate <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8102>
[17:09] <mup> PR snapcraft#2921 closed: storeapi: remove exposure of series <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2921>
[17:12] <pstolowski> zyga: good question!
[17:16] <pstolowski> i need to think
[17:22] <pstolowski> eod, cu
[17:29] <zyga> I will EOD soon but want to inspect one more time this weird bug I found
[17:29] <zyga> mvo: some early ideas on oom
[17:30] <zyga> mvo: snap set system oom-order=snap-a,snap-b,snap-d
[17:30] <zyga> would protect snap-a from oom more than snap-b, snapd-d and other parts of the system
[17:30] <zyga> mvo: (the name should probably oom-protect instead of oom-order but I wanted to imply there's an order)
[17:31] <zyga> 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] <zyga> mvo: the burden and responsibility shifts
[17:32] <zyga> mvo: I'll explore two more ideas tomorrow
[17:32] <zyga> for now I'm off
[18:11] <ijohnson> 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] <ijohnson> 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] <pedronis> ijohnson: yes, in the sense that's controlled by code inside the package, MarkBootSucceful in boot.go
[18:12] <ijohnson> ok, thanks that simplifies things
[18:12]  * ijohnson lunches
[18:13] <pedronis> ijohnson: please double check the code there matches you expect
[18:13] <pedronis> *what you
[18:35] <ijohnson> 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] <pedronis> ijohnson: yes, they are within the same package, feel free to add comments though if helps somebody doing changes down the lien
[18:36] <pedronis> *line
[18:37] <ijohnson> I'll add comments as to what the assumptions I'm making
[18:37] <ijohnson> err that was awkwardly phrased ... I'll add comments about it there :-)
[19:46] <zyga> jdstrand: if you want to chat about any of my branches I'm available
[19:57] <techalchemy> zyga, jdstrand just told me to file this bug and ping you: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1862832
[19:57] <mup> Bug #1862832: Latest snapd triggers apparmor denials on 'sendmsg' name=/run/nvidia-xdriver-xxxx <snapd (Ubuntu):New> <https://launchpad.net/bugs/1862832>
[19:57] <zyga> aha
[19:57] <zyga> looking
[19:58] <zyga> techalchemy: thank you, I'll look at reproducing that back in the office tomorrow
[19:59] <techalchemy> thanks, I haven't noticed any issues besides the logs
[19:59] <zyga> techalchemy: does the application still operate correctly?
[19:59] <zyga> aha
[19:59] <techalchemy> 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] <techalchemy> 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] <zyga> it's a shame the peer addr is ... whatever it is
[20:01]  * zyga wonders
[20:01] <techalchemy> it's the same socket as is mentioned elsewhere in the logs
[20:02] <techalchemy> (sorry for the highlights) <jdstrand> Decoded: var/run/nvidia-xdriver-f8177d9f
[20:06] <jdstrand> 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] <zyga> jdstrand: having you here, do you have an idea what that peer address represents?
[20:06] <zyga> 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] <zyga> peer="unconfined"
[20:06] <jdstrand> techalchemy: this is the pulse issue: https://forum.snapcraft.io/t/upcoming-pulseaudio-interface-deprecation/13418/10
[20:06] <zyga> that's not even a pointer
[20:07] <jdstrand> zyga: yeah, snap.pomotroid.pomotroid is trying to talk to @var/run/nvidia-xdriver-f8177d9f
[20:07] <techalchemy> 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] <zyga> jdstrand: how did you derive @var/run/ from that number?
[20:07] <zyga> is that some base encoding?
[20:07] <jdstrand> zyga: and is being denied. there is also (in the bug) a non-abstract path in /run
[20:07] <zyga> aha
[20:08] <jdstrand> zyga: the aa-decode command techalchemy gave
[20:08] <techalchemy> oh i didn't post the command, woops
[20:08] <jdstrand> aa-decode @7661722F72756E2F6E76696469612D786472697665722D66383137376439660000000000000000000000000000000000000000000000000000000000000000
[20:08] <jdstrand> but, '@' isn't accepted by that command, so you drop it to decode, then prepend it
[20:09] <jdstrand> zyga: there are nuls in that string so the kernel encoded it
[20:09] <zyga> hmmm
[20:09] <zyga>  Jamie Strandboge aa-decode @7661722F72756E2F6E76696469612D786472697665722D66383137376439660000000000000000000000000000000000000000000000000000000000000000
[20:09] <zyga> er
[20:09] <zyga> aa-decode @7661722F72756E2F6E76696469612D786472697665722D66383137376439660000000000000000000000000000000000000000000000000000000000000000
[20:09] <zyga> String should only contain hex characters (0-9, a-f, A-F)
[20:09] <zyga> that doesn't work for me on focal?
[20:09] <jdstrand> zyga: did you read my next sentence? :)
[20:09] <zyga> ah, no
[20:10] <zyga> missed it among the paste
[20:10] <zyga> is this encoding something new? I haven't seen it before
[20:10] <mup> PR snapcraft#2928 opened: logging: use .warning instead of deprecated .warn <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2928>
[20:10] <zyga> but this helps a lot
[20:10] <jdstrand> zyga: did you see the next sentence after that? :)
[20:11] <jdstrand> zyga: it isn't new to the kernel as the string is determined by userspace
[20:12] <jdstrand> zyga: so, there are two denials:
[20:12] <jdstrand> /run/nvidia-xdriver-f8177d9f
[20:12] <jdstrand> and @var/run/nvidia-xdriver-f8177d9f
[20:12] <jdstrand> zyga: and only after upgrading to focal. it seems something changed in the nvidia driver?
[20:13] <jdstrand> zyga: I asked techalchemy to ping you since I don't have nvidia hardware and I suspect there is more to this than just adjusting the two denials (there might not be...)
[20:13] <techalchemy> yes, all of my nvidia packages were reinstalled i believe
[20:16] <jdstrand> zyga: I commented in the bug
[20:17] <zyga> Thank you
[20:18] <zyga> I can check it out tomorrow
[21:09]  * cachio afk
[22:01] <mup> PR snapcraft#2929 opened: elf: fixes for corrupt shared objects and semi-resolved path components from ldd <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2929>
[22:52] <mup> PR snapcraft#2930 opened: extensions: Handle case when user-dirs.dirs exits but not user-dirs.locale <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/2930>