[00:06] <mup> PR snapcraft#1924 opened: schema: update version regex <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1924>
[00:15] <mup> PR snapcraft#1836 closed: Update test_export_login.py <codein> <Created by heesen3> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1836>
[00:21] <mup> PR snapcraft#1846 closed: go plugin: remove confusing importpath message <codein> <Created by Nissaar> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1846>
[06:09] <mborzecki> morning
[06:57] <zyga_> good morning
[06:57] <mborzecki> zyga: hey
[06:58] <zyga> man, I was so useless yesterday
[06:58] <zyga> maybe the weather is getting to me :/
[07:06] <zyga> chihchun_afk: I hope we don't make any core snap invalid wrt version validation now
[07:11] <mborzecki> zyga: do you have any ideas about https://github.com/snapcore/snapd/pull/4647#issuecomment-365171068 ?
[07:11] <mup> PR #4647: cmd/snap: fix UX of snap services <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4647>
[07:11] <zyga> good morning niemeyer :)
[07:11] <zyga> Job for snapd.socket canceled.
[07:12] <zyga> hmm, we've seen that countless times
[07:12] <zyga> I don't remember what that is off the top of my head
[07:13] <mborzecki> 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] <mvo> its only 14.04, right?
[07:15] <zyga> I wonder if we can reproduce that on a simpler service
[07:15] <zyga> mvo is it?
[07:16] <mborzecki> mvo: yes
[07:16] <mvo> the job canceled? yes - I only saw it on 14.04 so far
[07:16] <mvo> I think its a bug in the old systemd we use there
[07:16] <zyga> hey mvo :)
[07:18] <zyga> some random bug report
[07:18] <zyga> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768208
[07:18] <zyga> are we still shutting down snapd.service before snapd.socket?
[07:18] <zyga> hmmm
[07:21] <mborzecki> the timers are stopped before the tests?
[07:22] <zyga> I don't recall
[07:23] <zyga> I think we set the schedule (internal one)
[07:23] <zyga> I don't know if we do something about the timers
[07:45] <mup> PR snapd#4653 closed: all: snap versions are now validated <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4653>
[07:54] <mup> PR snapd#4648 closed: debian, snap: only static link libseccomp in snap-seccomp on ubuntu <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4648>
[07:55] <mup> PR snapd#4650 closed: daemon: allow `snapctl get` from any uid <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4650>
[08:00] <mup> PR snapd#4654 opened: tests/lib/prepare: disable snapd.refresh.timer <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4654>
[08:00] <mborzecki> let's see if this makes any difference in the long run
[08:13] <mvo> mborzecki: thank you
[08:17] <kalikiana> sliff
[08:28] <zyga> mborzecki thanks!
[08:40] <mborzecki> 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] <mvo> mborzecki: yeah, definitely, is there any trace in that PR where it hangs?
[08:44] <mvo> mborzecki: we might need to blacklist more
[08:46] <mborzecki> mvo: it stopped in tests/main/snap-run, this line: `snap run --strace test-snapd-tools.echo "hello-world" >stdout 2>stderr`
[08:46] <mborzecki> the next line was kill-timeout reached
[08:46] <mvo> mborzecki: is it killed eventually?
[08:47] <mvo> 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] <mborzecki> it was the only test that failed, so i hope it was killed
[08:47] <mvo> xnox: hey, if you are around I would love to talk about 1749000
[09:10] <mup> PR snapd#4647 closed: cmd/snap: fix UX of snap services <Created by niemeyer> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4647>
[09:15] <mup> PR snapd#4625 closed: daemon: remove redundant UserOK markings from api commands <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4625>
[09:15] <mup> PR snapd#4633 closed:  snap: introduce  timer service data types and validation  <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4633>
[09:16] <mup> PR snapd#4654 closed: tests/lib/prepare: disable snapd.refresh.timer <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4654>
[09:18]  * Chipaca realises he made life harder for himself with #4653
[09:18] <mup> PR #4653: all: snap versions are now validated <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4653>
[09:18]  * Chipaca shakes fist at self
[09:22] <mup> PR snapd#4615 closed: overlord/snapstate/backend: perform cleanup if snap setup fails <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4615>
[09:27] <mborzecki> systemd timers are confusing, our timers are confusing too, ergo probably all timers are confusing
[09:32] <mvo> maybe like make systems? I need to find one I actually not dislike still
[09:32] <Chipaca> 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] <mborzecki> Chipaca: iirc you need n, n+1, n+2 samples to infer anything :)
[09:35] <mborzecki> 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] <mvo> 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] <mvo> mborzecki: eh
[09:36] <mvo> mborzecki: sorry, snapd being available
[09:36] <mvo> mborzecki: systemd of course (freudian slip ;)
[09:43] <mborzecki> 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] <mborzecki> it already ran in the interval and do nothing or let it do its work
[09:45] <mvo> 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] <mvo> mborzecki: I think this is pretty much what you described, right?
[09:46] <mborzecki> mvo: yup
[09:47] <mvo> great
[09:47] <mborzecki> mvo: wonder if we could have like a templated oneshot service that gets activated by the timer
[09:51] <mvo> mborzecki: yeah, that could work
[10:14] <mup> PR snapd#4655 opened: osutil: add and update docstrings <Created by zyga> <https://github.com/snapcore/snapd/pull/4655>
[10:17] <Chipaca> hmmm
[10:17] <Chipaca> there's a failing test on master
[10:18] <mborzecki> Chipaca: which one?
[10:18] <Chipaca> mborzecki: systemKeySuite.TestInterfaceSystemKey in interfaces/
[10:21] <zyga> oh
[10:21] <zyga> Chipaca link?
[10:21] <Chipaca> zyga: on master
[10:21] <mborzecki> Chipaca: looks green to me
[10:21] <Chipaca> zyga: like, on my box, right here
[10:21]  * zyga runs
[10:21] <Chipaca> because the test is looking at _my fstab_
[10:21] <Chipaca> WTF
[10:21] <zyga> Chipaca aah
[10:22] <zyga> missing mocking
[10:22] <Chipaca> *my* fstab
[10:22] <zyga> which test fails?
[10:22] <Chipaca> *mine!*
[10:22]  * Chipaca hugs it to his chest
[10:22] <Chipaca> sshhh, shhh, i won't let the nasty hacker hurt you
[10:22] <Chipaca> zyga: systemKeySuite.TestInterfaceSystemKey
[10:23] <Chipaca> zyga: also, i'll have you know “none /tmp tmpfs” is a perfectly valid fstab entry :-)
[10:23] <zyga> optional options
[10:26] <zyga> Chipaca so what's your fstab like
[10:26] <zyga> I'll fix the parser
[10:26] <zyga> an can you please check if 4656 fixes it for you?
[10:27] <Chipaca> zyga: I'd also rather it didn't look at the real fstab
[10:27] <mup> PR snapd#4656 opened: interfaces: mock away real mountinfo/fstab <Created by zyga> <https://github.com/snapcore/snapd/pull/4656>
[10:27] <Chipaca> ah
[10:27]  * Chipaca fetches zyga
[10:28] <Chipaca> zyga: I can confirm it doesn't fix it
[10:28]  * Chipaca runs it again to make sure
[10:28] <zyga> so what did you add to your fstab, I can test quickly locally to get this to work
[10:30] <Chipaca> uhhhh
[10:30] <Chipaca> zyga: so
[10:30] <Chipaca> zyga: you're doing the mocking wrong
[10:30] <Chipaca> badly wrong in fact
[10:30] <Chipaca> zyga: if you do
[10:30] <Chipaca> 	defer osutil.MockMountInfo("")()
[10:30] <Chipaca> in SetUpTest
[10:31] <zyga> man
[10:31] <zyga> I see now
[10:31] <Chipaca> that'll get un-mocked at the exit of SetUpTest
[10:31] <zyga> :D
[10:31] <Chipaca> :-)
[10:32] <zyga> sorry :
[10:32] <zyga> :)
[10:33] <zyga> Chipaca force pushed
[10:34] <Chipaca> zyga: mucho bettero
[10:37] <Chipaca> zyga: I miss python's ability to make callable lists
[10:38] <Chipaca> but only sometimes
[10:38] <zyga> callable lists?
[10:38] <Chipaca> zyga: you can pop a __call__ on anything
[10:38] <zyga> as in class funky(list) def __call__(self, *args, **kwargs): for fn in self: fn(*args, **kwargs)
[10:39] <Chipaca> zyga: yep
[10:39] <Chipaca> zyga: or return [i(*a, **kw) for i in self]
[10:43] <mup> PR snapd#4521 closed: many: move /lib/udev/snappy-app-dev to /usr/lib/snapd/snappy-app-dev <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4521>
[10:43] <mvo> hm, 4491 needs a second review pretty please
[10:43] <zyga> Chipaca one more for you 4657
[10:44] <zyga> mvo I'll do it
[10:44] <mup> PR snapd#4657 opened: osutil: parse mount entries without options field <Created by zyga> <https://github.com/snapcore/snapd/pull/4657>
[10:44] <Chipaca> zyga: welll.....
[10:45] <zyga> yes?
[10:45]  * Chipaca tries
[10:45] <Chipaca> ah
[10:46]  * Chipaca tries harder
[10:46] <Chipaca> zyga: let me get an example that breaks
[10:50] <Chipaca> zyga: nothing, 's fine
[10:50] <Chipaca> zyga: :-) good
[10:58] <Chipaca> zyga: #4656 green
[10:58] <mup> PR #4656: interfaces: mock away real mountinfo/fstab <Created by zyga> <https://github.com/snapcore/snapd/pull/4656>
[10:59] <mup> PR snapd#4656 closed: interfaces: mock away real mountinfo/fstab <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4656>
[11:09] <zyga> ok  	github.com/snapcore/snapd/x11	0.004s
[11:12] <Chipaca> zyga: can all tests be that fast? kthx
[11:13] <Chipaca> zyga: are there cases where ParseMountEntry fails but you still need to use the (partial) MountEntry it returns?
[11:14] <zyga> no, I don't think so
[11:14] <zyga> we only read stuff we wrote (which has a fixed format) and when we read /etc/fstab
[11:14] <zyga> but when we read fstab we AFAIR ignore errors
[11:15] <Chipaca> ignore errors -> if it fails you still use the returned MountEntry?
[11:17] <zyga> no
[11:17] <zyga> I mean if we cannot determine if you're on NFS we just assume you are not and carry on
[11:33] <Chipaca> mvo: have you seen #1747272?
[11:33] <mup> Bug #1747272: Polkit dialogs of snapd are not translatable <l10n> <patch> <Ubuntu Translations:New> <snapd (Ubuntu):In Progress by gunnarhj> <https://launchpad.net/bugs/1747272>
[11:33] <mup> PR snapd#4657 closed: osutil: parse mount entries without options field <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4657>
[11:33] <Chipaca> mvo: it has a patch ;-)
[11:51] <zyga> mvo reviewed 4491
[11:51] <mup> PR snapd#4655 closed: osutil: add and update docstrings <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4655>
[12:06] <mup> PR snapd#4658 opened: many: don't allow layout construction to silently fail <Created by zyga> <https://github.com/snapcore/snapd/pull/4658>
[12:19]  * kalikiana going for a short break
[12:21] <popey> mborzecki: heya! What's the plan for updating snapd in opensuse? (I may have missed a conversation about this previously, sorry).
[12:21] <popey> (it's outdated and causes some modern snaps to not function)
[12:34] <Son_Goku> popey, there's an openSUSE guy working on rebasing snapd based on the Fedora packaging
[12:34] <Son_Goku> I'm helping him with it
[12:36] <popey> <3 thanks Son_Goku
[12:36] <popey> that's great to hear
[12:36] <zyga> Son_Goku what is his name?
[12:37] <Son_Goku> 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] <zyga> Son_Goku please send him here, it will be easier to coordinate
[12:37] <popey> feel free to poke me if there is anything to test, we have copious vms here
[12:37] <Son_Goku> zyga: he has been here before
[12:37] <Son_Goku> you should already know him
[12:37] <zyga> sorry, I don't recall
[12:37] <Son_Goku> hurricanehrndz
[12:38] <zyga> thank you
[12:39] <zyga> I invited him here
[12:39] <Son_Goku> he's already been here...
[12:39] <mvo> Chipaca: thanks for the pointer to the dialogs
[12:42] <Son_Goku> popey: will do
[12:50] <mup> PR snapd#4659 opened: snap: improve the version validator's error messages <Created by chipaca> <https://github.com/snapcore/snapd/pull/4659>
[12:50] <Chipaca> ^ RFC PR about snap version validation error messaging
[13:05] <mup> PR snapd#4660 opened: systemd: update comment on SocketsTarget <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4660>
[13:05] <mborzecki> trivial PR ^^
[13:10] <GunnarHj> 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] <mup> Bug #1747272: Polkit dialogs of snapd are not translatable <l10n> <patch> <Ubuntu Translations:New> <snapd (Ubuntu):In Progress by gunnarhj> <https://launchpad.net/bugs/1747272>
[13:10] <zyga> hey
[13:10] <zyga> GunnarHj I think mvo here worked on an alternative patch
[13:10] <zyga> GunnarHj I myself haven't touched thay yet
[13:10] <zyga> *that
[13:11] <mborzecki> zyga: close enough? https://4.bp.blogspot.com/-NrtzlHIkl24/Vb5EXABEWbI/AAAAAAAAmeM/4qeOSmXcrp8/s1600/deadmau5-lamborghini-puracan-huracan-nyanborghini.jpg
[13:11] <zyga> I think the idea is to really link dynamically by default and do special magic where we need to
[13:11] <GunnarHj> zyga: Ah, great! mvo ^ ?
[13:11] <zyga> mborzecki nyan cat!
[13:12] <zyga> hmm
[13:12] <zyga> interesting failure
[13:12] <zyga> + test-snapd-tools.env. execl failed: Permission denied
[13:13] <zyga> [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] <zyga> mvo ^ is this what I think it is
[13:13] <zyga> fallout of that branch you merged a moment ago?
[13:13] <mvo> zyga: I don't know (yet)
[13:14] <zyga>     /usr/lib/snapd/snappy-app-dev ixr, # drop
[13:14] <zyga> we have this rule
[13:14] <mvo> zyga: oh, right
[13:14] <zyga> but it feels like this was not what was on disk
[13:16] <zyga> https://github.com/snapcore/snapd/pull/4658
[13:16] <mup> PR #4658: many: don't allow layout construction to silently fail <Created by zyga> <https://github.com/snapcore/snapd/pull/4658>
[13:18]  * Chipaca gives zyga a quick intro course to advance mathematics concepts such as "1 != 0"
[13:18] <Chipaca> :-D
[13:19] <zyga> Chipaca what? :D
[13:20] <Chipaca> zyga: https://github.com/snapcore/snapd/pull/4659#discussion_r167858672
[13:20] <mup> PR #4659: snap: improve the version validator's error messages <Created by chipaca> <https://github.com/snapcore/snapd/pull/4659>
[13:20] <zyga> hh
[13:20] <zyga> d'oh :)
[13:20] <zyga> thanks for pointing that out
[13:21] <Chipaca> :-)
[13:21] <Chipaca> 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] <mvo> jdstrand: when you have a moment, a re-review of 4652 would be great, should be super easy (much smaller now)
[13:22] <Chipaca> zyga: "which character violated the regular expression" returns a universe
[13:24]  * zyga breaks for quick lunch
[13:24] <zyga> mvo let's trace that error in 30 min
[13:26] <mvo> zyga: yeah, I think there is more broken in master right now
[13:29]  * kalikiana lunch
[13:57] <jdstrand> 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] <jdstrand> 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] <zyga> jdstrand yes, that branch landed
[13:59] <jdstrand> my branch landed?
[13:59] <zyga> and we have issues now
[13:59]  * jdstrand needs to check email :)
[13:59] <zyga> no, that's the mv branch
[13:59] <zyga> sorry, not the rewrite branch
[13:59] <jdstrand> ok
[13:59] <jdstrand> yes, will, if you move it, you definitely need to adjust the snap-confine profile
[14:00] <mvo> jdstrand: my branch that just puts it into a different place landed
[14:00] <mvo> jdstrand: this is to fix a bug with core18
[14:00] <jdstrand> snappy-app-dev is called by udev during hotplug/unplug events and by snap-confine for device cgroups wrt interface connections
[14:00] <mvo> jdstrand: the rewrite is (AFAICT) orthogonal
[14:00] <zyga> jdstrand we adjusted the profile too but something is broken still
[14:01] <jdstrand> mvo: yes, it would be orthogonal, but there was talk of incorporating the move, so I was confused for a sec
[14:01] <jdstrand> where's the PR?
[14:01] <jdstrand> or rather, where is the failing test?
[14:02] <mvo> jdstrand: aha, ok
[14:03] <zyga> jdstrand https://github.com/snapcore/snapd/pull/4658
[14:03] <mup> PR #4658: many: don't allow layout construction to silently fail <Created by zyga> <https://github.com/snapcore/snapd/pull/4658>
[14:03] <zyga> the last commit fails on this now
[14:03] <zyga> (have a look at the PR as well)
[14:08] <jdstrand> so, it seems there is an issues applying the changed profile
[14:08] <jdstrand> in the testsuite
[14:09] <jdstrand> 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] <jdstrand> zyga: did you maybe pull in the change to move the binary but not the change to the profile?
[14:10] <zyga> no, I didn't do anything actually, this branch is unrelated
[14:10] <jdstrand> I don't know how all this landed
[14:10] <zyga> and we simply merged master elswehre
[14:11] <zyga> I meant "merged to master elsewhere"
[14:11] <zyga> I'm checking if this is reproducible now
[14:11] <jdstrand> well, there is a testsuite issue with generating snap-confine.apparmor
[14:12] <jdstrand> snap-confine.apparmor is not getting cached somehow, is it? is snap-confine.apparmor.in being used on every spread run?
[14:13] <zyga> we now create and destroy machines for each spread run, I doubt there is something stale there
[14:13] <jdstrand> 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] <zyga> the push runs on a fresh machine
[14:14] <zyga> the whole build / install / test cycle is followed
[14:14] <jdstrand> zyga: right, but *perhaps* snap-confine.apparmor is on the host and being preferred over regenerating it from snap-confine.apparmor.in
[14:14] <jdstrand> I don't know, just trying to think through where it could break down
[14:14] <zyga> 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] <zyga> hmm
[14:15] <zyga> one idea is that we compute the reexec profile from something stale / old
[14:15] <zyga> but ... not sure how
[14:15] <jdstrand> 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] <zyga> I ran spread again locally, let's see if I can hit this
[14:15] <zyga> if that were (simply) true it would fail for any profile modification and we ran into those
[14:16] <jdstrand> zyga: a package reinstall could complicate things too, yes
[14:16] <zyga> in any case, I'm looking, not sure what the fault is yet
[14:16] <jdstrand> zyga: eg, you generate the profile, load it, then (re?)install the package
[14:16] <zyga> yep, that's what roughly happens
[14:16] <zyga> we build snapd, install that package
[14:16] <zyga> repackage core to include that new snapd
[14:16] <zyga> and then go
[14:16] <zyga> and repackaged snapd conta
[14:16] <zyga> oh
[14:16] <zyga> :D
[14:17] <zyga> maybe we don't replace this binary correctly
[14:17] <jdstrand> the binary is using /usr/lib/snapd-snap-confine
[14:17] <jdstrand> but the profile isn't allowing it
[14:17] <zyga> hmm
[14:17] <jdstrand> so there is something happening where they didn't end up in sync in the testsuite
[14:21] <mborzecki> i'm off to pick up the kids
[14:22] <zyga> jdstrand reproduced
[14:22] <ikey> boy or girl? congrats either way
[14:22]  * ikey walks out
[14:22]  * Chipaca hugs ikey 
[14:23] <ikey> ^^
[14:23] <zyga> http://paste.ubuntu.com/p/v9rPYyH44b/
[14:23] <zyga> [  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] <zyga>     /lib/udev/snappy-app-dev ixr, # drop
[14:24] <zyga> this is the rule on disk (in /etc/apparmor.d/snap.core.4060.usr.lib.snapd.snap-confine)
[14:24] <zyga> jdstrand I think I get it
[14:25] <zyga> linode:ubuntu-16.04-32 /snap/core/current# find -name snappy-app-dev
[14:25] <zyga> ./lib/udev/snappy-app-dev
[14:25] <zyga> ./usr/lib/snapd/snappy-app-dev
[14:25] <zyga> the repackaged core snap has this inside:     /usr/lib/snapd/snappy-app-dev ixr, # drop
[14:27] <zyga> *hmm*
[14:29] <zyga> one more idea
[14:30] <zyga> jdstrand the preserved project state contains the stale profile
[14:31] <zyga> jdstrand the tarball we create in tests
[14:31] <zyga> snapd-state.tar.gz
[14:31] <zyga> then snapd doesn't regenerate the profile
[14:31] <zyga> I'll look at fixing this
[14:35]  * kalikiana re
[14:41] <zyga> https://securelist.com/zero-day-vulnerability-in-telegram/83800/ <- interesting
[14:42] <jdstrand> zyga: cool, nice find
[14:42] <jdstrand> zyga: this will help anyone touching the snap-confine profile :)
[14:49] <mvo> zyga: thanks for finding this!
[14:55] <mup> PR snapd#4660 closed: systemd: update comment on SocketsTarget <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4660>
[15:00] <ogra_> jdstrand, https://forum.snapcraft.io/t/bin-sync-not-allowed/3988/1
[15:03] <Nissaar> 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] <zyga> Error: Command failed: git merge-base master HEAD
[15:04] <zyga> you need to put git inside your snap
[15:04] <Nissaar> uhmmm how ?
[15:05] <ogra_> add a build-packages entry
[15:05] <ogra_> and add git to it
[15:05] <Nissaar> in 'parts' section ?
[15:05] <ogra_> yes
[15:05] <ogra_> https://github.com/snapcrafters has a ton of example snaps you can steal from :)
[15:07] <Nissaar> like this https://paste.ubuntu.com/p/jRzqwK96rk/ ?
[15:19] <jdstrand> ogra_: yes, I saw. responded
[15:19] <ogra_> yeah, i saw too, thanks !
[15:40] <mup> PR snapd#4652 closed: tests: fix spread test failures on 18.04 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4652>
[15:44] <mup> PR snapd#4491 closed: snap: allow options for --strace, e.g. `snap run --strace="-tt"` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4491>
[15:46] <Nissaar> https://paste.ubuntu.com/p/vqFY5HVxDZ/ this is my new yaml
[15:46] <Nissaar> https://paste.ubuntu.com/p/mXwf4N2C8D/
[15:47] <Nissaar> the error is the same
[15:48] <Nissaar> i have added stage-packages: [git]] to the yaml
[15:48] <mup> PR snapd#4661 opened: snap: improve `snap run` comments/naming <Created by mvo5> <https://github.com/snapcore/snapd/pull/4661>
[16:03] <ogra_> Nissaar, and the snap did build fine ? no errors or anything ? (how did you create it before using "snap run" )
[16:04] <ogra_> (you should theroetically not actually need build-packages: [ git ], snapcraft should care for it on its own when building)
[16:06] <Nissaar> ogra: https://docs.snapcraft.io/build-snaps/node
[16:06] <Nissaar> https://paste.ubuntu.com/p/vqFY5HVxDZ/
[16:06] <ogra_> and there were no errors when you did build it ?
[16:07] <Nissaar> used the example form the 1st link to edit the snapcraft.yaml in the 2nd one
[16:07] <ogra_> yeah, the snapcraft.yaml looks basically sane (at least to build a proper node based snap from it)
[16:09] <ogra_> do you have a log of the build ?
[16:12] <Nissaar> ogra_: https://paste.ubuntu.com/p/25zR3JDhHY/
[16:12] <Nissaar> here it is
[16:13] <ogra_> ah, it seems that your snap actually uses git internally at runtime
[16:13] <ogra_> change "build-packages:" to "stage-packages:"
[16:13] <ogra_> re-build and it should finr git
[16:13] <ogra_> *find
[16:14] <Nissaar> im on it
[16:16] <greyback> zyga: gentle reminder you've been asked a question in my PR: https://github.com/snapcore/snapd/pull/4545
[16:16] <mup> PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545>
[16:17] <zyga> greyback ack, I didn't notice. that
[16:17] <greyback> no worries
[16:17] <zyga> I'll finish fixing master and then switch to this
[16:21] <mup> PR snapd#4662 opened: tests: removing packages which are not needed anymore to generate random data <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4662>
[16:59] <zyga> mvo, almost done with that fixx
[17:10]  * kalikiana out for the day
[17:14] <jdstrand> ogra_: hey, so twice I've seen the bbb refresh the core snap in the background and drop to a uboot shell. If I type 'reset' it boots. have you seen this?
[17:14] <ogra_> nope
[17:14] <ogra_> any errors ?
[17:14] <jdstrand> when? before the uboot? no
[17:15] <ogra_> well, yeah, on serial typically
[17:15] <jdstrand> I connected serial to type 'reset'
[17:15] <ogra_> "in" uboot ...
[17:15] <jdstrand> there was nothing before the prompt
[17:15] <ogra_> yeah, i guess serial wont show you the backlog
[17:16] <jdstrand> I'm refreshing the core snap and will reboot with serial connected
[17:16] <jdstrand> it'll probably work fine
[17:16] <ogra_> if there was an error it would show between u-boot starting and the showing of the prompt
[17:16]  * jdstrand nods
[17:19] <jdstrand> ogra_: yep booted fine. that's what happened in december
[17:19] <ogra_> it is very likely that the refresh failed somehow ... what i can do is to force CONFIG_RESET_TO_RETRY and "CONFIG_BOOT_RETRY_TIME  5" in the uboot build, that way it would auto-reboot after 5 sec on the uboot prompt
[17:19] <jdstrand> ogra_: I guess I'll continue to keep an eye on it
[17:20] <jdstrand> ogra_: that would be good
[17:20] <ogra_> ... but that makes development really annoying since it will *always* reboot after 5sec ... even if you are interacting with the prompt
[17:20] <jdstrand> ogra_: cuase it looked like th refresh did fail. when I 'reset' I went into an old core
[17:20] <jdstrand> ogra_: 60 seconds would've been fine in this case
[17:20] <zyga> mvo it turned out larger but I'm sure you will like it :)
[17:21] <zyga> jdstrand and you too ;)
[17:21] <zyga> :-)
[17:21] <ogra_> (the question is if there are actually people developing on that level)
[17:21] <jdstrand> I use this as a little armhf build machine
[17:21] <jdstrand> and I went to login to it and it was down
[17:21] <jdstrand> (actually, I knew it was down cause of nagios ;)
[17:21] <ogra_> yeah, 60sec sounds mildly sahe
[17:21] <ogra_> *sane
[17:21] <jdstrand> ogra_: 300? :)
[17:22] <ogra_> haha
[17:22] <jdstrand> I really don't care much. if I could ssh in and debug after noticing it went down and reboot, that would work for me
[17:22] <jdstrand> this happened in the middle of the night
[17:22] <ogra_> for actual bootloader development people can defintely just turn it off and rebuild the gadget
[17:22] <jdstrand> anyway, whatever timeout you think is good wfm
[17:23] <ogra_> (the option that is)
[17:23] <ogra_> yeah, i''ll add that
[17:23] <jdstrand> thanks!
[17:23] <ogra_> you will need a fresh install though
[17:23] <ogra_> since we still dont have gadget upgrades :P
[17:23] <ogra_> (or do we and i missed that ?)
[17:24] <jdstrand> really? I thought we just didn't on rpi2 (and I thought that was because of lack of promotion due to the underlying issues...)(
[17:24] <jdstrand> I have no idea tbh
[17:24] <jdstrand> ogra_: I'm still on r1
[17:25] <jdstrand> that's all there seems to be
[17:25] <ogra_> me neither ... since i moved to CE i'm to busy with actual customer stuff to follow this
[17:25]  * jdstrand shrugs
[17:25] <jdstrand> heh
[17:25] <jdstrand> well, if you upload the gadget to the store, I can try. if it blows up, I'll regenerate
[17:25] <jdstrand> zyga: cool!
[17:26] <ogra_> jdstrand, i'll let you know ... (not tonight anymore though ... )
[17:27] <jdstrand> ogra_: sure. thanks again :)
[17:27] <ogra_> well, thanks for reporting :)
[17:29] <jdstrand> :)
[17:38] <Chipaca> hrmph, just realised we can't go with our usuall "Noun verbed" for the 'check-snapshot' verb
[17:38] <Chipaca> maybe the verb is wrong, or english is terrible :-)
[17:39] <Chipaca> "Snapshot 42 checked." leaves you going "...and? what do I _have_, doctor?!?"
[17:40] <Chipaca> "your blood results came back" "..." "sit down" "...?" "cuppa tea?" <dies> "no sugar then"
[17:41] <kyrofa> Should that be "verify" instead?
[17:41] <kyrofa> The meaning of "check" is indeed overloaded
[17:41] <kyrofa> Or rather, you could be checking something for numerous reasons
[17:41] <ogra_> depends on the $$$ really
[17:43] <Chipaca> kyrofa: "verified" has the same problem: it tells you the verification finished, not that the snapshot was ok
[17:45] <kyrofa> Hmm
[17:45] <Chipaca> maybe it's the nature of the beast, and i just need to print "checked and passed" or sth
[17:48] <kyrofa> Chipaca, what are you actually checking?
[17:48] <Chipaca> kyrofa: my current account
[17:48] <Chipaca> no, er
[17:48] <Chipaca> kyrofa: it's like md5sum -c
[17:49] <kyrofa> Chipaca, validated?
[17:49] <Chipaca> kyrofa: if it's not valid i don't even open it
[17:49] <Chipaca> :-)
[17:49] <kyrofa> English is stupid
[17:49] <Chipaca> if it's not valid, as in the zipfile is corrupt, or the index is corrupt, or doesn't match _its_ hash, the snapshot isn't even listed
[17:50] <Chipaca> bah, there is something called 'valid' in this context, but it's more subtle, snapshots that aren't valid in the above sense are just not snapshots at all
[17:51] <Chipaca> ej
[17:51] <Chipaca> kyrofa: don't worry, i'm more ranting than anything
[17:51] <Chipaca> or sharing the pain
[17:51] <Chipaca> not strictly looking for solutions at this time
[17:51] <Chipaca> (there are 110+ comments on the PR i'm working through, and this one is not one of them)
[17:52] <mup> PR snapd#4663 opened: interfaces/builtin: allow MM to access login1 <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/4663>
[18:44] <Chipaca> zyga: you around?
[18:44] <zyga> yep
[18:44] <Chipaca> zyga: are you running something newer than 16.04 there?
[18:44] <zyga> yep
[18:45] <zyga> 17.10
[18:45] <zyga> I have 18.04 as well
[18:45] <Chipaca> zyga: can you check if on a terminal there, 😀 shows up (1) double wide, and (2) counted as narrow?
[18:46] <Chipaca> zyga: as opposed to 明 which should show up as double-wide and counted as double-wide
[18:47] <zyga> one sec
[18:47] <zyga> actually
[18:47] <zyga> how do I check?
[18:47]  * nacc was wondering the same thing
[18:47] <zyga> Chipaca I can show you and you can tell me
[18:47] <Chipaca> zyga: paste it in the terminal and write an 'a'
[18:48] <zyga> Chipaca in standup
[18:48] <Chipaca> going ;-)
[18:54] <jdstrand> davidcalle: hey, ping re https://docs.snapcraft.io/deprecation-notices/dn5
[18:56] <Chipaca> so, everything is terrible in 16.04 but it gets better :)
[18:56] <Chipaca> oh, zyga, was that 18.04 or 17.10?
[18:56] <zyga> 17.10
[18:56] <Chipaca> perfect
[18:57] <Chipaca> zyga: I can _probably_ detect it at least for gnome terminal using $VTE_VERSION but I'm not at all sure I want to :-)
[18:59] <zyga> mvo I pushed the rework to 4658
[18:59] <zyga> if it passes I will propose it separately
[18:59] <Chipaca> …
[18:59] <zyga> jdstrand the rework includes use of ensure-dir-state to write and load the apparmor profile for snap-confine in core
[18:59] <Chipaca> i can use escape sequences to find out
[19:00] <Chipaca> did i want to know this
[19:00] <zyga> Chipaca you can talk to the tty
[19:00] <Chipaca> exactly
[19:00] <zyga> as in, you can talk to the terminal emulator
[19:00] <zyga> and ask it stuff
[19:00] <Chipaca> yes
[19:00] <zyga> not sure how much gnome vte implemented there
[19:00] <Chipaca> including "how wide did you think this thing was
[19:00] <Chipaca> "
[19:00] <zyga> well, you can just get the cursor position
[19:00] <Chipaca> yes, but reading that back is a nightmare
[19:00] <zyga> why so?
[19:01] <zyga> mvo, jdstrand: the new interesting bit is https://github.com/snapcore/snapd/pull/4658/files#diff-57dc34ab6f4bf9730b356d0439daa0fdR170
[19:01] <mup> PR #4658: many: don't allow layout construction to silently fail <Created by zyga> <https://github.com/snapcore/snapd/pull/4658>
[19:01] <Chipaca> zyga: termios black magic
[19:01] <zyga> mvo and the function immediately below that
[19:01] <zyga> Chipaca screw termios
[19:01] <zyga> hold on
[19:01] <zyga> https://invisible-island.net/xterm/ctlseqs/ctlseqs.pdf
[19:02] <zyga> (I really like that pdf)
[19:02] <Chipaca> zyga: i know the control sequences
[19:03] <Chipaca> zyga: but to read what it echoes back, which doesn't include a newline, you need to set the terminal into raw mode + unbuffered or whatever it is, then echo the char, then read it, then set it back to cooked
[19:04] <Chipaca> that's the termios bit i'd rather avoid
[19:04] <Chipaca> anyway, i'll stop distracting you -- i'm not working and you are :-)
[19:20] <mup> Bug #1749276 opened: Interface request: dvb <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1749276>
[20:00] <mup> PR snapd#4664 opened: interfaces/apparmor: ensure snap-confine profile for reexec is current <Created by zyga> <https://github.com/snapcore/snapd/pull/4664>
[20:00] <zyga> mvo, jdstrand: https://github.com/snapcore/snapd/pull/4664
[20:00] <mup> PR #4664: interfaces/apparmor: ensure snap-confine profile for reexec is current <Created by zyga> <https://github.com/snapcore/snapd/pull/4664>
[20:00] <zyga> this is the bit I cherry-picked out of 4658
[20:00] <zyga> I'll break now, ttyl
[20:10] <mvo> zyga: thank you
[20:16]  * Chipaca wanders off to figure out dinner
[20:16] <mup> PR snapd#4661 closed: snap: improve `snap run` comments/naming <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4661>
[20:21] <cachio> niemeyer, hey, could you please take a look to this https://github.com/snapcore/spread/pull/50 ?
[20:21] <mup> PR spread#50: Adding repeat option again <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/50>
[21:10] <zyga> cachio. linde is belly up
[21:10] <zyga> *linode
[22:41] <cachio> zyga, yes, I am trying to reproduce those errors
[22:41] <cachio> and fix them
[22:43] <zyga> cachio this is linode failing
[22:43] <zyga> what can you do?
[22:44] <cachio> zyga, ahh, I am researching this error https://travis-ci.org/snapcore/snapd/builds/341118599#L2993
[22:44] <cachio> it made fail like 5 or 6 builds today
[22:46] <zyga> cachio that is not what I was talking about
[22:46] <zyga> linode fails on API requests
[22:46] <zyga> this bug is fixed in my PR
[22:46] <zyga> https://github.com/snapcore/snapd/pull/4664
[22:46] <mup> PR #4664: interfaces/apparmor: ensure snap-confine profile for reexec is current <Created by zyga> <https://github.com/snapcore/snapd/pull/4664>
[22:47] <cachio> zyga, great, I'll review it
[22:47] <cachio> zyga, which error are you talking about, some networking problem?
[22:48] <zyga> cannot create new VMs
[22:48] <zyga> linode doesn't work :.
[22:48] <zyga> :/.
[22:48] <cachio> zyga, ouch
[22:48] <zyga> I restarted that branch a few times and it timed out at 49 minutes