[06:05] morning [06:13] good morning :) [06:14] mborzecki: I pushed missing patches from master into https://github.com/snapcore/snapd/pull/6235 [06:14] PR #6235: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors (2.36) [06:14] the reference is https://github.com/snapcore/snapd/pull/6233 [06:14] PR #6233: overlord: don't write system key if security setup fails [06:14] oh, and it's green now [06:14] there are a few extra lines of diff [06:15] because that branch combines another small patch from master [06:15] namely https://github.com/snapcore/snapd/pull/6235/commits/cbc6e3e029e36e2d120a3dbb2edad39f689da479 [06:15] PR #6235: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors (2.36) [06:15] I think it's good to go :) [06:19] mborzecki: I think we can merge https://github.com/snapcore/snapd/pull/6248 [06:19] PR #6248: tests/lib/reset: restore context of removed snapd directories [06:20] PR snapd#6248 closed: tests/lib/reset: restore context of removed snapd directories [06:21] a pair of simple looking conflicts on https://github.com/snapcore/snapd/pull/6238 [06:21] PR #6238: [RFC] many: add minimal SELinux support, refactor the policy [06:22] mborzecki: did you pick that keyboard? :) [06:22] zyga: no, not yet [06:23] mborzecki: pawel has apparently moved his work onto the new machine [06:23] expectedly, because it's the quietest and fastest machine he has now [06:23] I'm curious if you will experiment with vmware as well :) [06:24] PR snapd#6256 closed: snap: add new `snap run --trace-exec` call (2.36) [06:34] mborzecki: I resolved conflicts on https://github.com/snapcore/snapd/pull/6193/files [06:34] PR #6193: spread: drop Fedora 27, add Fedora 29 <⛔ Blocked> [06:34] though I made F29 manual so this can land [06:34] it should pass with just F28 [06:52] Quick school run [07:28] Re [07:50] PR snapd#6258 opened: WIP: interfaces: support D-Bus activation [07:58] and back now [07:58] jamesh: hey :) [07:58] hi zyga [07:59] I will try to review all branches this week [07:59] but we have a backlog and limited capacity [08:00] zyga: no problem. I'm still working on the dbus activation one: the PR is more for CI feedback [08:00] (that's why I marked it WIP) [08:00] * zyga loves to see :: targets used in makefiles === pstolowski|afk is now known as pstolowski [08:06] mornings [08:08] pstolowski: hey [08:11] hey pawel :) [08:22] https://github.com/snapcore/snapd/pull/6257 is green [08:22] PR #6257: testutils: split checkers, tweak tests [08:22] and very long :-) [08:24] nvidia physix is BSD now [08:24] that's impressive [08:24] wonder if nvidia will have a change of strategy for their other software [08:25] mborzecki: hey [08:25] mborzecki: I think we should do something about that snapd.mk PR [08:26] did that land? [08:26] I would like to resurrect it, make minimal modifications as discussed (move variable generation back to .spec file and have snapd.mk include vars.mk) [08:26] and land it [08:26] looking at the PR from james, there will be new files, new things to look at [08:28] uh oh [08:28] The job exceeded the maximum log length, and has been terminated. [08:28] travis now kills jobs that log too much [08:28] perhaps we should tweak spread to log less stuff [08:28] and definitely make rpm builds quieter [08:29] zyga: yeah, 2.36 branch is failing atm because of this i think [08:30] one other thing I would silence is the package name selection [08:30] that is, mapping from ubuntu names to other names [08:30] zyga: or sort of, something else fails, but travis terminates the job :) [08:30] that's extremely verbose [08:30] set +too-much-gibberish-x [08:50] trying some simple changes to reduce the log size now [08:54] mborzecki: do you know if it is possible to query the state of "set" settings? [08:55] zyga: snap get ? [08:55] snap get -d [08:55] no no [08:55] I mean in shell [08:55] set -x vs set +x [08:55] aah [08:55] there's nothing I can find quickly [08:59] zyga: set -o should do the trick [08:59] ah, neat, thanks! [09:00] zyga: xtrace is apparently the option [09:00] yes [09:00] and even supported by zsh :) [09:02] quick patch for reduced verbosity https://www.irccloud.com/pastebin/o15U1EqK/ [09:06] PR snapd#6259 opened: tests: reduce verbosity around package installation <⚠ Critical> [09:06] mborzecki, pstolowski: ^ [09:07] ok [09:08] mborzecki: do you want to discuss the connections API? [09:08] just looking at some random part of trace log [09:08] I would love to have [09:08] snap debug is-connected [09:08] snap debug connected-slots SNAP:PLUG [09:08] snap debug connected-plugs SNAP:SLOT [09:09] snap debug connecte-snaps SNAP: [09:09] (typos aside, you get the idea) [09:09] mhm [09:09] ideally all fuelled by a new API call [09:10] perhaps those could also be visible via snapctl [09:10] pstolowski: ^ do we have something like that for snapctl today? [09:11] zyga: no, unfortunately not [09:11] we might expose it in both places eventually [09:11] feels like something useful to snap developers [09:12] mborzecki: the general idea feels like [09:12] mborzecki: connections [09:12] interface optionally limits to interface type [09:12] string optionally filters by name of plug/slot [09:13] snap:plug and snap:slot can be empty or partially empty [09:13] (perhaps string is useless actually) [09:13] flags can alter the set of returned data (e.g. attributes) or visible things (e.g. show disconnected things as well as connected, for hotplug) [09:13] it seems it could power all the commands mentioned above [09:14] all of the options would probably be packed into a query structure [09:14] we might also have a flag for controling core/gadget connections [09:14] (e.g. skip them or include them) [09:15] so that the client code can stop having to special case "system/snapd/core/ubuntu-core" [09:17] zyga: let's have a chat ~11, 1115? [09:17] sure [09:22] #6193 is green [09:22] PR #6193: spread: drop Fedora 27, add Fedora 29 <⛔ Blocked> [09:32] merge it [09:32] we will solve the 29 blocked aspect separately [09:34] zyga: looking at 6257 [09:34] zyga: about fontconfig again, desktop interface mount of /var/cache/fontconfig is probably a problem [09:34] mmm [09:34] but that only applies to strictly confined apps [09:35] isn't the problem you experienced only affecting classic confined apps? [09:38] zyga: i'm still bit worried that we're generating that cache in a location that does not match distro choice, with the way things are set up now it should work, we're going to make /var/cache/fontconfig ourselves after all [09:38] mborzecki: yes [09:39] maybe we should really build a cache in /var/cache/snapd/fontconfig [09:39] zyga: righ, but the the classic snaps that use libfontconfig from core will end up poking /var/cache/fontconfig ;) [09:40] yes [09:40] tradeoffs everywhere [09:40] but for those we have no way out [09:40] until we can attack mount namespaces for classic confined software [09:41] mhm [09:42] mborzecki: updated https://github.com/snapcore/snapd/pull/6251 [09:42] PR #6251: cmd/snap-confine: refactor calling snapd tools into helper module [09:42] #6180 is green and needs (re)reviews [09:42] PR #6180: snap/info: bind global plugs/slots to implicit hooks [09:47] zyga: pstolowski: can you take a look https://github.com/snapcore/snapd/pull/6193 and +1 ? [09:47] PR #6193: spread: drop Fedora 27, add Fedora 29 [09:48] k [09:50] mborzecki: aha [09:51] pstolowski: and this one needs a 2nd review too: https://github.com/snapcore/snapd/pull/6246 super simple :) [09:51] PR #6246: spread: show AVC audits when debugging, start auditd on Fedora [09:52] PR snapd#6193 closed: spread: drop Fedora 27, add Fedora 29 [09:52] mborzecki: replied on https://github.com/snapcore/snapd/pull/6251 [09:52] PR #6251: cmd/snap-confine: refactor calling snapd tools into helper module [09:53] PR snapd#6246 closed: spread: show AVC audits when debugging, start auditd on Fedora [09:53] anyone knowledgeable of assertions left around? https://forum.snapcraft.io/t/cant-install-or-refresh-snaps-on-arch-linux/8690 the device is seeded, however there is no model assertion even though data.auth.model is already set to generic-classic [09:53] hmmm [09:53] I guess we just have to man up and read that code [09:54] pstolowski: on https://github.com/snapcore/snapd/pull/6257, shall I update all headers to 2018? [09:54] PR #6257: testutils: split checkers, tweak tests [09:55] zyga: i'd use this opportunity [09:55] sure [10:00] pstolowski: done :) [10:00] ty ! [10:04] suprising how travis jobs are succeeding now [10:04] pstolowski: this is not super urgent but it needs a 2nd review https://github.com/snapcore/snapd/pull/6244 [10:04] PR #6244: release: detect too old apparmor_parser [10:05] a much simpler variant of this went into 2.36 [10:05] this one is just tidier and less noisy [10:08] PR snapd#6090 closed: Granted 'account_control' access to /home/** [10:10] pstolowski, mborzecki: what do you guys think about https://github.com/snapcore/snapd/pull/6250 [10:10] PR #6250: data: set KillMode=process for snapd [10:11] PR snapd#6200 closed: tests: fix for tests test-*-cgroup [10:11] perhaps cherry pick the detector I suggested and LGTM? [10:11] I'm sure mvo can iterate on top [10:11] but feels like the right thing to do [10:19] zyga: do apparmor_parser and snap-seccomp lock profiles? any risk of having profiles messed up if new instances start writing profiles while old ones are still running? [10:20] (but in general yes, i think that's the right step what this PR proposes) [10:20] they don't lock profiles because they don't have to AFAIK: [10:20] snap-seccomp writes a new file with atomic move [10:21] snapd writes source profiles with atomic move [10:21] ah, good then [10:21] apparmor_parser loads profiles into the kernel, kernel is the point of mutual exclusion [10:21] snap-confine loads profiles from disk only at startup [10:21] that holds the lock but that's not really a factor [10:21] seccomp profiles persist until process death [10:22] apparmor profiles are changed dynamically [10:22] uhh reached asserts db trying to find out what's going on [10:22] and? [10:25] got lost :) [10:25] back to devicemgr [10:31] i bet that device serial is set on that guy's machine, but it's unclear why that'd be the case and the model assertion would not be present [10:33] feels like we could use some commands to show stuff [10:33] more than "snap known" [10:33] which feels like a debug command, not an end-user thing [10:33] super unpleasant user command if anything :) [10:34] https://www.irccloud.com/pastebin/xNFfHNva/ [10:34] hmmm [10:34] something really broken there :) [10:34] looking [10:34] nice [10:35] note that it uses dpkg on centos [10:35] heh right [10:35] snapd-xdg-open? i don't recall this in rpm [10:36] tests/upgrade/snapd-xdg-open/task.yaml [10:36] it runs on centos [10:36] but is clearly specific to ubuntu [10:36] is that a new task? [10:36] nope [10:36] look at it [10:36] wonder why the error never surfaced? [10:36] haha so how did it not fail before? [10:36] exactly [10:36] set -e is easy to lose [10:37] well [10:37] it failed now [10:37] I really wonder what I changed [10:38] I don't quite understand some of the logic in the pkgdb.sh [10:46] mborzecki: removed cloexec handling in https://github.com/snapcore/snapd/pull/6251 [10:46] PR #6251: cmd/snap-confine: refactor calling snapd tools into helper module [10:47] zyga: what was it? [10:47] mborzecki: will to fix that centos issue or shall I? [10:47] mborzecki: with cloexec? [10:47] mborzecki: just my debug wrappers [10:47] mhm [10:47] aah [10:47] shell scripts? [10:47] I didn't realise this is needed for scripts but not for programs [10:47] yep [10:47] yup, they mention that in the manpage [10:47] I test this way locally [10:48] yeah, in the BUGS section below :) [10:48] I missed that [10:54] PR snapd#6235 closed: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors (2.36) [10:57] mborzecki, pstolowski: my main feature branch that can land https://github.com/snapcore/snapd/pull/6149 [10:57] PR #6149: cmd/snap-confine: capture initialized per-user mount ns [10:57] I will have follow ups and tests once the feature snapd side is ready [10:58] zyga: k, will take a look [10:58] thank you! [11:00] mborzecki: I have a debug shell on centos 7 with that dpkg-query script [11:00] no idea why it would ever pass before [11:01] heh [11:01] disabled it, pushed [11:01] magic [11:01] btw. i'm playing with spread on fedora 29 [11:01] DEBUG: running snap-device-helper add snap_test-snapd-udev-input-subsystem_slot /sys/class/mem/null 1:3 [11:01] execl failed: No such file or directory [11:01] do you know my main issues with spread on fedora 29 [11:01] right [11:01] snap-device-helper is a script, wtf? [11:01] I know about htis [11:01] *this [11:01] yes [11:01] but that's not the main problem [11:01] the problem is that we must never repackage core or snapd snaps [11:01] with stuff we've built on a random distro [11:01] that's a bad test [11:01] bad logic [11:02] and not representative of what ever happens in production [11:02] locally built snapd package gets injected into core snap [11:02] yes, wanted to reach that point and inspect what happens exactly [11:02] so libc from 2019 will be in a 2016 system [11:02] I mean, progs linked to 2019 will be in a 2016 system [11:02] what is wrong is that rpm helpers change the #!/ line [11:03] look at the shebang line in the source and in that system that is broken [11:03] the short term resolution: [11:03] stop repackaging core / snapd anywhere outside of 16.04 [11:03] we can perhaps repackage snap-exec [11:03] but nothing more [11:07] woot, rpm learned some new tricks [11:27] mborzecki: mkosi got a huge static typing boost [11:28] https://github.com/systemd/mkosi/pull/300 [11:28] PR systemd/mkosi#300: Modify so that `flake8` and `mypy` are happy [11:31] hm still got mixed feelings about python and type hints [11:38] really? that's like 99% of the error checking there :) [11:41] PR snapd#6260 opened: spread, tests: use audit checkpoints when dumping audit log [11:41] simple one ^^ [11:41] zyga: it's just the type enforce part is missing [11:42] mborzecki: no need [11:42] mypy checks that it is true :) [11:42] if mypy says it's ok, the types match [11:42] reality is somewhat different as sometimes there are bugs in mypy and sometimes there are cases that are valid but the type system cannot express it [11:42] but really, apart from changing python in py4 [11:43] this is the best way to write python now [11:52] eh [11:52] untangling the mess in config manager [11:52] sucks [11:53] cyclic import mess, that is [11:53] hah :) [11:54] I will never finish user mounts this way [12:03] I think I got it [12:03] I will propose a small branch with just the tweak to config [12:06] PR snapd#6261 opened: tests/lib/prepare: make sure that SELinux context of repacked core snap is controlled [12:06] another simple PR ^^ [12:06] this time not dropping xattrs [12:07] eh [12:07] more cyclic shit [12:07] I hate this part of golang [12:08] LGTM with capitalisation of sentences [12:10] mborzecki: hmm [12:10] does set -o [12:10] does that set something in practice [12:10] because i have a feeling that that patch actually uncovered real bugs [12:10] zyga, hey [12:10] error: Failed build dependencies: [12:10] compiler(go-compiler) is needed by snapd-1337.2.36.2-0.el7.x86_64 [12:10] I get this error on centos 7.6 [12:10] −o Write the current settings of the options to standard output in [12:10] an unspecified format. [12:11] cachio: ehey [12:11] cachio: hmm interesting [12:11] zyga, I made sure go is instlaled [12:11] mborzecki: https://www.irccloud.com/pastebin/3I0NnCO5/ [12:11] mborzecki, yes [12:11] cachio: I don't follow EPEL work so no idea [12:11] mborzecki, do you? [12:11] right [12:11] ? [12:12] cachio: any chance i could use the image? [12:12] I have a debug session already openned [12:12] mborzecki, do you want to use it? [12:12] mborzecki: my guess is that sourcing some of our packages nukes set -e [12:12] and this is now changed _somehow_ [12:13] mborzecki, otherwise the image name is test-centos-1 [12:13] sourcing vs executing [12:13] sourcing is evil [12:13] cachio: yes, i'll try to build snapd there, i recall chasing down something similar [12:14] zyga: hence, 'evil sourcerer' :) [12:14] haha [12:14] we should really stop doing that [12:15]

408 Request Time-out