[00:06] PR snapcraft#1924 opened: schema: update version regex [00:15] PR snapcraft#1836 closed: Update test_export_login.py [00:21] PR snapcraft#1846 closed: go plugin: remove confusing importpath message === ahoneybun_ is now known as ahoneybun [06:09] morning [06:57] good morning === zyga_ is now known as zyga [06:57] zyga: hey [06:58] man, I was so useless yesterday [06:58] maybe the weather is getting to me :/ [07:06] chihchun_afk: I hope we don't make any core snap invalid wrt version validation now [07:11] zyga: do you have any ideas about https://github.com/snapcore/snapd/pull/4647#issuecomment-365171068 ? [07:11] PR #4647: cmd/snap: fix UX of snap services [07:11] good morning niemeyer :) [07:11] Job for snapd.socket canceled. [07:12] hmm, we've seen that countless times [07:12] I don't remember what that is off the top of my head [07:13] zyga: right, i suspect that's somewhat related to snapd going down with sigpipe, getting restarted automatically and us trying to stop snapd.service and snapd.socket [07:15] its only 14.04, right? [07:15] I wonder if we can reproduce that on a simpler service [07:15] mvo is it? [07:16] mvo: yes [07:16] the job canceled? yes - I only saw it on 14.04 so far [07:16] I think its a bug in the old systemd we use there [07:16] hey mvo :) [07:18] some random bug report [07:18] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768208 [07:18] are we still shutting down snapd.service before snapd.socket? [07:18] hmmm [07:21] the timers are stopped before the tests? [07:22] I don't recall [07:23] I think we set the schedule (internal one) [07:23] I don't know if we do something about the timers [07:45] PR snapd#4653 closed: all: snap versions are now validated [07:54] PR snapd#4648 closed: debian, snap: only static link libseccomp in snap-seccomp on ubuntu [07:55] PR snapd#4650 closed: daemon: allow `snapctl get` from any uid [08:00] PR snapd#4654 opened: tests/lib/prepare: disable snapd.refresh.timer [08:00] let's see if this makes any difference in the long run [08:13] mborzecki: thank you [08:17] sliff [08:28] mborzecki thanks! [08:40] mvo: we need to keep an eye on the strace spread tests, i saw it reaching kill-timeout in john's pr, maybe there's some syscall, that we haven't accounted for, that's causing issues [08:44] mborzecki: yeah, definitely, is there any trace in that PR where it hangs? [08:44] mborzecki: we might need to blacklist more [08:46] mvo: it stopped in tests/main/snap-run, this line: `snap run --strace test-snapd-tools.echo "hello-world" >stdout 2>stderr` [08:46] the next line was kill-timeout reached [08:46] mborzecki: is it killed eventually? [08:47] mborzecki: hm, do we get debug output on kill? if so we need to add the last lines of stderr. if not we need to talk to gustavo [08:47] it was the only test that failed, so i hope it was killed [08:47] xnox: hey, if you are around I would love to talk about 1749000 [09:10] PR snapd#4647 closed: cmd/snap: fix UX of snap services [09:15] PR snapd#4625 closed: daemon: remove redundant UserOK markings from api commands [09:15] PR snapd#4633 closed: snap: introduce timer service data types and validation [09:16] PR snapd#4654 closed: tests/lib/prepare: disable snapd.refresh.timer [09:18] * Chipaca realises he made life harder for himself with #4653 [09:18] PR #4653: all: snap versions are now validated [09:18] * Chipaca shakes fist at self [09:22] PR snapd#4615 closed: overlord/snapstate/backend: perform cleanup if snap setup fails [09:27] systemd timers are confusing, our timers are confusing too, ergo probably all timers are confusing [09:32] maybe like make systems? I need to find one I actually not dislike still [09:32] mborzecki: no no, you need to find a random timer, base a timer on it, and if you can prove it's confusing just from that, you've got the 1 case and the n+1 case and you can deduce the all-of-em case [09:33] * Chipaca can feel his maths prof glaring at him right now [09:33] Chipaca: iirc you need n, n+1, n+2 samples to infer anything :) [09:35] anyways, looks like the timer services will be a mix of systemd (to fire a timer helper regularly) and snapd (to keep the state) :/ and that makes me a bit uneasy [09:36] mborzecki: yeah, I am not sure we should rely on systemd available. we don't do that in e.g. snap run as well (made a concious effort to not depend on a running snapd there) [09:36] mborzecki: eh [09:36] mborzecki: sorry, snapd being available [09:36] mborzecki: systemd of course (freudian slip ;) [09:43] mvo: on one hand systemd can activate timers on regular intervals, but it's timer syntax is limited, eg. our 10:00-12:00 means 'happens once between 10am and 12am', once/between part cannot be expressed in systemd.time syntax, their events happen at specific time, eg. 10:00, as a workaround we could translate our timer to multiple oncalendar events every eg. 10minutes, then when running the service check if [09:43] it already ran in the interval and do nothing or let it do its work [09:45] mborzecki: yeah, I think we need a helper (not necessarily snapd) and we write a systemd timer that runs e.g. every 10min, passes the time string to the helper and the helper keeps the state when to fire [09:46] mborzecki: I think this is pretty much what you described, right? [09:46] mvo: yup [09:47] great [09:47] mvo: wonder if we could have like a templated oneshot service that gets activated by the timer [09:51] mborzecki: yeah, that could work [10:14] PR snapd#4655 opened: osutil: add and update docstrings [10:17] hmmm [10:17] there's a failing test on master [10:18] Chipaca: which one? [10:18] mborzecki: systemKeySuite.TestInterfaceSystemKey in interfaces/ [10:21] oh [10:21] Chipaca link? [10:21] zyga: on master [10:21] Chipaca: looks green to me [10:21] zyga: like, on my box, right here [10:21] * zyga runs [10:21] because the test is looking at _my fstab_ [10:21] WTF [10:21] Chipaca aah [10:22] missing mocking [10:22] *my* fstab [10:22] which test fails? [10:22] *mine!* [10:22] * Chipaca hugs it to his chest [10:22] sshhh, shhh, i won't let the nasty hacker hurt you [10:22] zyga: systemKeySuite.TestInterfaceSystemKey [10:23] zyga: also, i'll have you know “none /tmp tmpfs” is a perfectly valid fstab entry :-) [10:23] optional options [10:26] Chipaca so what's your fstab like [10:26] I'll fix the parser [10:26] an can you please check if 4656 fixes it for you? [10:27] zyga: I'd also rather it didn't look at the real fstab [10:27] PR snapd#4656 opened: interfaces: mock away real mountinfo/fstab [10:27] ah [10:27] * Chipaca fetches zyga [10:28] zyga: I can confirm it doesn't fix it [10:28] * Chipaca runs it again to make sure [10:28] so what did you add to your fstab, I can test quickly locally to get this to work [10:30] uhhhh [10:30] zyga: so [10:30] zyga: you're doing the mocking wrong [10:30] badly wrong in fact [10:30] zyga: if you do [10:30] defer osutil.MockMountInfo("")() [10:30] in SetUpTest [10:31] man [10:31] I see now [10:31] that'll get un-mocked at the exit of SetUpTest [10:31] :D [10:31] :-) [10:32] sorry : [10:32] :) [10:33] Chipaca force pushed [10:34] zyga: mucho bettero [10:37] zyga: I miss python's ability to make callable lists [10:38] but only sometimes [10:38] callable lists? [10:38] zyga: you can pop a __call__ on anything [10:38] as in class funky(list) def __call__(self, *args, **kwargs): for fn in self: fn(*args, **kwargs) [10:39] zyga: yep [10:39] zyga: or return [i(*a, **kw) for i in self] [10:43] PR snapd#4521 closed: many: move /lib/udev/snappy-app-dev to /usr/lib/snapd/snappy-app-dev [10:43] hm, 4491 needs a second review pretty please [10:43] Chipaca one more for you 4657 [10:44] mvo I'll do it [10:44] PR snapd#4657 opened: osutil: parse mount entries without options field [10:44] zyga: welll..... [10:45] yes? [10:45] * Chipaca tries [10:45] ah [10:46] * Chipaca tries harder [10:46] zyga: let me get an example that breaks [10:50] zyga: nothing, 's fine [10:50] zyga: :-) good [10:58] zyga: #4656 green [10:58] PR #4656: interfaces: mock away real mountinfo/fstab [10:59] PR snapd#4656 closed: interfaces: mock away real mountinfo/fstab [11:09] ok github.com/snapcore/snapd/x11 0.004s [11:12] zyga: can all tests be that fast? kthx [11:13] zyga: are there cases where ParseMountEntry fails but you still need to use the (partial) MountEntry it returns? [11:14] no, I don't think so [11:14] we only read stuff we wrote (which has a fixed format) and when we read /etc/fstab [11:14] but when we read fstab we AFAIR ignore errors [11:15] ignore errors -> if it fails you still use the returned MountEntry? [11:17] no [11:17] I mean if we cannot determine if you're on NFS we just assume you are not and carry on [11:33] mvo: have you seen #1747272? [11:33] Bug #1747272: Polkit dialogs of snapd are not translatable [11:33] PR snapd#4657 closed: osutil: parse mount entries without options field [11:33] mvo: it has a patch ;-) [11:51] mvo reviewed 4491 [11:51] PR snapd#4655 closed: osutil: add and update docstrings [12:06] PR snapd#4658 opened: many: don't allow layout construction to silently fail [12:19] * kalikiana going for a short break [12:21] mborzecki: heya! What's the plan for updating snapd in opensuse? (I may have missed a conversation about this previously, sorry). [12:21] (it's outdated and causes some modern snaps to not function) [12:34] popey, there's an openSUSE guy working on rebasing snapd based on the Fedora packaging [12:34] I'm helping him with it [12:36] <3 thanks Son_Goku [12:36] that's great to hear [12:36] Son_Goku what is his name? [12:37] popey: a big part of the problem is that the current snapd packaging doesn't comply fully with guidelines to get into Factory (the main entrypoint for the SUSE distribution) [12:37] Son_Goku please send him here, it will be easier to coordinate [12:37] feel free to poke me if there is anything to test, we have copious vms here [12:37] zyga: he has been here before [12:37] you should already know him [12:37] sorry, I don't recall [12:37] hurricanehrndz [12:38] thank you [12:39] I invited him here [12:39] he's already been here... [12:39] Chipaca: thanks for the pointer to the dialogs [12:42] popey: will do [12:50] PR snapd#4659 opened: snap: improve the version validator's error messages [12:50] ^ RFC PR about snap version validation error messaging [13:05] PR snapd#4660 opened: systemd: update comment on SocketsTarget [13:05] trivial PR ^^ [13:10] Hi zyga, do you have some time for bug #1747272? I have attached two alternative patches, showing the idea for a solution, but I'm not able to test it properly (don't know how to build snapd). [13:10] Bug #1747272: Polkit dialogs of snapd are not translatable [13:10] hey [13:10] GunnarHj I think mvo here worked on an alternative patch [13:10] GunnarHj I myself haven't touched thay yet [13:10] *that [13:11] zyga: close enough? https://4.bp.blogspot.com/-NrtzlHIkl24/Vb5EXABEWbI/AAAAAAAAmeM/4qeOSmXcrp8/s1600/deadmau5-lamborghini-puracan-huracan-nyanborghini.jpg [13:11] I think the idea is to really link dynamically by default and do special magic where we need to [13:11] zyga: Ah, great! mvo ^ ? [13:11] mborzecki nyan cat! [13:12] hmm [13:12] interesting failure [13:12] + test-snapd-tools.env. execl failed: Permission denied [13:13] [Tue Feb 13 13:03:14 2018] audit: type=1400 audit(1518526994.091:78435): apparmor="DENIED" operation="exec" profile="/snap/core/4060/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snappy-app-dev" pid=4025 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 [13:13] mvo ^ is this what I think it is [13:13] fallout of that branch you merged a moment ago? [13:13] zyga: I don't know (yet) [13:14] /usr/lib/snapd/snappy-app-dev ixr, # drop [13:14] we have this rule [13:14] zyga: oh, right [13:14] but it feels like this was not what was on disk [13:16] https://github.com/snapcore/snapd/pull/4658 [13:16] PR #4658: many: don't allow layout construction to silently fail [13:18] * Chipaca gives zyga a quick intro course to advance mathematics concepts such as "1 != 0" [13:18] :-D [13:19] Chipaca what? :D [13:20] zyga: https://github.com/snapcore/snapd/pull/4659#discussion_r167858672 [13:20] PR #4659: snap: improve the version validator's error messages [13:20] hh [13:20] d'oh :) [13:20] thanks for pointing that out [13:21] :-) [13:21] TBH the "you can slice this way, you can slice that way, but you can't slice both ways at once" catches me out quite often [13:21] jdstrand: when you have a moment, a re-review of 4652 would be great, should be super easy (much smaller now) [13:22] zyga: "which character violated the regular expression" returns a universe [13:24] * zyga breaks for quick lunch [13:24] mvo let's trace that error in 30 min [13:26] zyga: yeah, I think there is more broken in master right now [13:29] * kalikiana lunch [13:57] mvo: done. fyi, tyhicks and I aren't super excited by the upstream dbus change and will review if it can be improved. I don't know what will happen there, so just fyi [13:59] zyga, mvo: re /usr/lib/snapd/snappy-app-dev: what's going on there-- that sounds like it would've come from my go rewrite branch (that I've been unable to circle back to, but will eventually) [13:59] jdstrand yes, that branch landed [13:59] my branch landed? [13:59] and we have issues now [13:59] * jdstrand needs to check email :) [13:59] no, that's the mv branch [13:59] sorry, not the rewrite branch [13:59] ok [13:59] yes, will, if you move it, you definitely need to adjust the snap-confine profile [14:00] jdstrand: my branch that just puts it into a different place landed [14:00] jdstrand: this is to fix a bug with core18 [14:00] snappy-app-dev is called by udev during hotplug/unplug events and by snap-confine for device cgroups wrt interface connections [14:00] jdstrand: the rewrite is (AFAICT) orthogonal [14:00] jdstrand we adjusted the profile too but something is broken still [14:01] mvo: yes, it would be orthogonal, but there was talk of incorporating the move, so I was confused for a sec [14:01] where's the PR? [14:01] or rather, where is the failing test? [14:02] jdstrand: aha, ok [14:03] jdstrand https://github.com/snapcore/snapd/pull/4658 [14:03] PR #4658: many: don't allow layout construction to silently fail [14:03] the last commit fails on this now [14:03] (have a look at the PR as well) [14:08] so, it seems there is an issues applying the changed profile [14:08] in the testsuite [14:09] profile="/snap/core/4060/usr/lib/snapd/snap-confine": that needs to have the new '/usr/lib/snapd/snappy-app-dev ixr,', but for some reason it doesn't [14:10] zyga: did you maybe pull in the change to move the binary but not the change to the profile? [14:10] no, I didn't do anything actually, this branch is unrelated [14:10] I don't know how all this landed [14:10] and we simply merged master elswehre [14:11] I meant "merged to master elsewhere" [14:11] I'm checking if this is reproducible now [14:11] well, there is a testsuite issue with generating snap-confine.apparmor [14:12] snap-confine.apparmor is not getting cached somehow, is it? is snap-confine.apparmor.in being used on every spread run? [14:13] we now create and destroy machines for each spread run, I doubt there is something stale there [14:13] I didn't phrase tha well. when spread pushes the code to the node, is snap-confine.apparmor being regenerated at the right time from snap-confine.apparmor.in? [14:13] the push runs on a fresh machine [14:14] the whole build / install / test cycle is followed [14:14] zyga: right, but *perhaps* snap-confine.apparmor is on the host and being preferred over regenerating it from snap-confine.apparmor.in [14:14] I don't know, just trying to think through where it could break down [14:14] well, it _may_ be but we reinstall the package (which loads the profile) and then you can see this is the profile from reexec [14:14] hmm [14:15] one idea is that we compute the reexec profile from something stale / old [14:15] but ... not sure how [14:15] zyga: but that line of thought is, you have snap-confine.apparmor, you pull from master something that changes snap-confine.apparmor.in, you run spread, snap-confine.apparmor isn't regenerated [14:15] I ran spread again locally, let's see if I can hit this [14:15] if that were (simply) true it would fail for any profile modification and we ran into those [14:16] zyga: a package reinstall could complicate things too, yes [14:16] in any case, I'm looking, not sure what the fault is yet [14:16] zyga: eg, you generate the profile, load it, then (re?)install the package [14:16] yep, that's what roughly happens [14:16] we build snapd, install that package [14:16] repackage core to include that new snapd [14:16] and then go [14:16] and repackaged snapd conta [14:16] oh [14:16] :D [14:17] maybe we don't replace this binary correctly [14:17] the binary is using /usr/lib/snapd-snap-confine [14:17] but the profile isn't allowing it [14:17] hmm [14:17] so there is something happening where they didn't end up in sync in the testsuite [14:21] i'm off to pick up the kids [14:22] jdstrand reproduced [14:22] boy or girl? congrats either way [14:22] * ikey walks out [14:22] * Chipaca hugs ikey [14:23] ^^ [14:23] http://paste.ubuntu.com/p/v9rPYyH44b/ [14:23] [ 477.039513] audit: type=1400 audit(1518531578.798:45): apparmor="DENIED" operation="exec" profile="/snap/core/4060/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snappy-app-dev" pid=13872 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 [14:23] /lib/udev/snappy-app-dev ixr, # drop [14:24] this is the rule on disk (in /etc/apparmor.d/snap.core.4060.usr.lib.snapd.snap-confine) [14:24] jdstrand I think I get it [14:25] linode:ubuntu-16.04-32 /snap/core/current# find -name snappy-app-dev [14:25] ./lib/udev/snappy-app-dev [14:25] ./usr/lib/snapd/snappy-app-dev [14:25] the repackaged core snap has this inside: /usr/lib/snapd/snappy-app-dev ixr, # drop [14:27] *hmm* [14:29] one more idea [14:30] jdstrand the preserved project state contains the stale profile [14:31] jdstrand the tarball we create in tests [14:31] snapd-state.tar.gz [14:31] then snapd doesn't regenerate the profile [14:31] I'll look at fixing this [14:35] * kalikiana re [14:41] https://securelist.com/zero-day-vulnerability-in-telegram/83800/ <- interesting [14:42] zyga: cool, nice find [14:42] zyga: this will help anyone touching the snap-confine profile :) [14:49] zyga: thanks for finding this! [14:55] PR snapd#4660 closed: systemd: update comment on SocketsTarget [15:00] jdstrand, https://forum.snapcraft.io/t/bin-sync-not-allowed/3988/1 [15:03] im packaging the nodejs snap 'POKEMON SHOWDOWN', here is the .aml file and the issue im facing: https://paste.ubuntu.com/p/PjV9tgDr24/ [15:04] Error: Command failed: git merge-base master HEAD [15:04] you need to put git inside your snap [15:04] uhmmm how ? [15:05] add a build-packages entry [15:05] and add git to it [15:05] in 'parts' section ? [15:05] yes [15:05] https://github.com/snapcrafters has a ton of example snaps you can steal from :) [15:07] like this https://paste.ubuntu.com/p/jRzqwK96rk/ ? [15:19] ogra_: yes, I saw. responded [15:19] yeah, i saw too, thanks ! [15:40] PR snapd#4652 closed: tests: fix spread test failures on 18.04