| mup | PR snapd#8114 opened: boot: use variables for boot status values <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8114> | 04:45 |
|---|---|---|
| mborzecki | morning | 06:26 |
| 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:32 |
| 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:35 |
| mborzecki | quick round trip to school, back in 30 | 06:40 |
| mborzecki | re | 07:09 |
| pstolowski | morning | 08:00 |
| mborzecki | pstolowski: hey | 08:03 |
| mborzecki | wow, firefox 73 finally handles hidpi correctly | 08:05 |
| 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:06 |
| mborzecki | pedronis: hey, thanks for merging 8114, i'll proceed updating 8077 | 08:08 |
| abeato | mborzecki, hey, do you know if the support for default tracks in snapd is already merged? | 08:21 |
| 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:23 |
| abeato | pedronis, mborzecki ok, thanks | 08:24 |
| 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:34 |
| 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:54 |
| 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:56 |
| pedronis | thx | 08:57 |
| 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: ^^ | 08:58 |
| jamesh | pedronis: sorry. I've been working through some changes on my other branch. I'll answer those q's now. | 09:23 |
| 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:12 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| zyga | tomwardill: pleasure :) let me know if it worked in the end :) | 10:25 |
| 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> | 10:40 |
| mborzecki | cachio: hi, do you know when was the last time centos 7 images were updated? | 11:25 |
| 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:29 |
| 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:32 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| mborzecki | ok, np | 11:46 |
| mborzecki | huh google:arch-linux-64:tests/main/static failed ? | 11:46 |
| 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:47 |
| 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:48 |
| 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:50 |
| 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:51 |
| kbroulik | mborzecki: I thought that was automatic? I did send a SIGHUP to dbus-daemon though | 11:53 |
| kbroulik | "There is no way to cause the D-BUS daemon to reload its configuration file" heh | 11:54 |
| zyga | mvo: reported as https://bugs.launchpad.net/snapd/+bug/1862761 | 11:55 |
| mup | Bug #1862761: core systems using core18 boot base cannot unmount writable cleanly <snapd:New> <https://launchpad.net/bugs/1862761> | 11:56 |
| 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:01 |
| 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:02 |
| mborzecki | this should fix it ^^ | 12:03 |
| 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:09 |
| 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:12 |
| mborzecki | corba of the desktops | 12:13 |
| 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:15 |
| * zyga goes to make coffee | 12:56 | |
| zyga | mborzecki: do you think the user helper could become a non-source but execute helper? | 12:58 |
| 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 | 12:59 |
| 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:02 |
| zyga | mborzecki: then it becomes user stop-session|start-session etc etc | 13:03 |
| * zyga breaks for coffee and some food | 13:17 | |
| 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:44 |
| 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:57 |
| 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:58 |
| * 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 | 13:59 |
| pedronis | ijohnson: ^ | 14:00 |
| ijohnson | pedronis: will look after SU | 14:00 |
| 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:01 |
| 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:05 |
| 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:09 |
| 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:10 |
| 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:41 |
| 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:51 |
| 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:54 |
| zyga | brb, 2nd coffee and a hunt for a memory card adapter | 14:58 |
| 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:07 |
| 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:26 |
| 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:30 |
| mvo | zyga: that should be fine | 15:31 |
| 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:35 |
| 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:38 |
| ijohnson | mborzecki: thanks will take a look in a little bit, trying to finish review of pstolowski's PR | 15:39 |
| 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:41 |
| mborzecki | ijohnson: right, pushing now | 15:42 |
| mborzecki | and off to do some groceries | 15:42 |
| ijohnson | thanks mborzecki | 15:44 |
| jdstrand | abeato (cc cjp256): there is. the review-tools should be updated soonish | 15:45 |
| 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:46 |
| zyga | jdstrand: thank you! | 15:47 |
| 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:50 |
| * cachio lunch | 15:56 | |
| cjp256 | abeato: interesting case | 15:56 |
| 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 | 15:58 |
| 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:03 |
| 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:04 |
| sergiusens | abeato: why not track the udd (or equivalent) of the source package and get auto builds for those? | 16:06 |
| 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:07 |
| abeato | sergiusens, that's an alternative... | 16:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| abeato | jdstrand, https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/snap/snapcraft.yaml?h=snap-1.10 | 16:17 |
| 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:18 |
| 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:26 |
| pedronis | pstolowski: do you have time to quickly check about the prune issue now? | 16:27 |
| pstolowski | pedronis: yes | 16:28 |
| pstolowski | let's | 16:28 |
| pedronis | pstolowski: ok, let's use the standup | 16:28 |
| jdstrand | pedronis: I see it in my inbox, new today. I haven't read it yet | 16:30 |
| * zyga goes for dinner | 16:43 | |
| 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:03 |
| mup | PR snapcraft#2921 closed: storeapi: remove exposure of series <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2921> | 17:09 |
| pstolowski | zyga: good question! | 17:12 |
| pstolowski | i need to think | 17:16 |
| pstolowski | eod, cu | 17:22 |
| 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:29 |
| 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:30 |
| 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:31 |
| zyga | mvo: I'll explore two more ideas tomorrow | 17:32 |
| zyga | for now I'm off | 17:32 |
| 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:11 |
| 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:12 | |
| pedronis | ijohnson: please double check the code there matches you expect | 18:13 |
| pedronis | *what you | 18:13 |
| 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:35 |
| 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:36 |
| 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 :-) | 18:37 |
| zyga | jdstrand: if you want to chat about any of my branches I'm available | 19:46 |
| 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:57 |
| zyga | techalchemy: thank you, I'll look at reproducing that back in the office tomorrow | 19:58 |
| 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 | 19:59 |
| 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:00 |
| 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:01 |
| techalchemy | (sorry for the highlights) <jdstrand> Decoded: var/run/nvidia-xdriver-f8177d9f | 20:02 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| jdstrand | zyga: it isn't new to the kernel as the string is determined by userspace | 20:11 |
| 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:12 |
| 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:13 |
| jdstrand | zyga: I commented in the bug | 20:16 |
| zyga | Thank you | 20:17 |
| zyga | I can check it out tomorrow | 20:18 |
| * cachio afk | 21:09 | |
| 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:01 |
| 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> | 22:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!