mup | PR snapcraft#1924 opened: schema: update version regex <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1924> | 00:06 |
---|---|---|
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:15 |
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> | 00:21 |
=== ahoneybun_ is now known as ahoneybun | ||
mborzecki | morning | 06:09 |
zyga_ | good morning | 06:57 |
=== zyga_ is now known as zyga | ||
mborzecki | zyga: hey | 06:57 |
zyga | man, I was so useless yesterday | 06:58 |
zyga | maybe the weather is getting to me :/ | 06:58 |
zyga | chihchun_afk: I hope we don't make any core snap invalid wrt version validation now | 07:06 |
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:11 |
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:12 |
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:13 |
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:15 |
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:16 |
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:18 |
mborzecki | the timers are stopped before the tests? | 07:21 |
zyga | I don't recall | 07:22 |
zyga | I think we set the schedule (internal one) | 07:23 |
zyga | I don't know if we do something about the timers | 07:23 |
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:45 |
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:54 |
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> | 07:55 |
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:00 |
mvo | mborzecki: thank you | 08:13 |
kalikiana | sliff | 08:17 |
zyga | mborzecki thanks! | 08:28 |
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:40 |
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:44 |
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:46 |
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 | 08:47 |
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:10 |
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:15 |
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:16 |
* 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:18 | |
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:22 |
mborzecki | systemd timers are confusing, our timers are confusing too, ergo probably all timers are confusing | 09:27 |
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:32 |
* 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:33 |
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:35 |
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:36 |
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:43 |
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:45 |
mvo | mborzecki: I think this is pretty much what you described, right? | 09:46 |
mborzecki | mvo: yup | 09:46 |
mvo | great | 09:47 |
mborzecki | mvo: wonder if we could have like a templated oneshot service that gets activated by the timer | 09:47 |
mvo | mborzecki: yeah, that could work | 09:51 |
mup | PR snapd#4655 opened: osutil: add and update docstrings <Created by zyga> <https://github.com/snapcore/snapd/pull/4655> | 10:14 |
Chipaca | hmmm | 10:17 |
Chipaca | there's a failing test on master | 10:17 |
mborzecki | Chipaca: which one? | 10:18 |
Chipaca | mborzecki: systemKeySuite.TestInterfaceSystemKey in interfaces/ | 10:18 |
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:21 |
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:22 |
Chipaca | zyga: also, i'll have you know “none /tmp tmpfs” is a perfectly valid fstab entry :-) | 10:23 |
zyga | optional options | 10:23 |
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:26 |
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:27 | |
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:28 |
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:30 |
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:31 |
zyga | sorry : | 10:32 |
zyga | :) | 10:32 |
zyga | Chipaca force pushed | 10:33 |
Chipaca | zyga: mucho bettero | 10:34 |
Chipaca | zyga: I miss python's ability to make callable lists | 10:37 |
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:38 |
Chipaca | zyga: yep | 10:39 |
Chipaca | zyga: or return [i(*a, **kw) for i in self] | 10:39 |
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:43 |
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:44 |
zyga | yes? | 10:45 |
* Chipaca tries | 10:45 | |
Chipaca | ah | 10:45 |
* Chipaca tries harder | 10:46 | |
Chipaca | zyga: let me get an example that breaks | 10:46 |
Chipaca | zyga: nothing, 's fine | 10:50 |
Chipaca | zyga: :-) good | 10:50 |
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:58 |
mup | PR snapd#4656 closed: interfaces: mock away real mountinfo/fstab <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4656> | 10:59 |
zyga | ok github.com/snapcore/snapd/x110.004s | 11:09 |
Chipaca | zyga: can all tests be that fast? kthx | 11:12 |
Chipaca | zyga: are there cases where ParseMountEntry fails but you still need to use the (partial) MountEntry it returns? | 11:13 |
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:14 |
Chipaca | ignore errors -> if it fails you still use the returned MountEntry? | 11:15 |
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:17 |
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:33 |
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> | 11:51 |
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:06 |
* kalikiana going for a short break | 12:19 | |
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:21 |
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:34 |
popey | <3 thanks Son_Goku | 12:36 |
popey | that's great to hear | 12:36 |
zyga | Son_Goku what is his name? | 12:36 |
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:37 |
zyga | thank you | 12:38 |
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:39 |
Son_Goku | popey: will do | 12:42 |
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 | 12:50 |
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:05 |
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:10 |
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:11 |
zyga | hmm | 13:12 |
zyga | interesting failure | 13:12 |
zyga | + test-snapd-tools.env. execl failed: Permission denied | 13:12 |
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:13 |
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:14 |
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:16 |
* Chipaca gives zyga a quick intro course to advance mathematics concepts such as "1 != 0" | 13:18 | |
Chipaca | :-D | 13:18 |
zyga | Chipaca what? :D | 13:19 |
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:20 |
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:21 |
Chipaca | zyga: "which character violated the regular expression" returns a universe | 13:22 |
* zyga breaks for quick lunch | 13:24 | |
zyga | mvo let's trace that error in 30 min | 13:24 |
mvo | zyga: yeah, I think there is more broken in master right now | 13:26 |
* kalikiana lunch | 13:29 | |
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:57 |
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 | 13:59 |
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:00 |
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:01 |
mvo | jdstrand: aha, ok | 14:02 |
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:03 |
jdstrand | so, it seems there is an issues applying the changed profile | 14:08 |
jdstrand | in the testsuite | 14:08 |
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:09 |
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:10 |
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:11 |
jdstrand | snap-confine.apparmor is not getting cached somehow, is it? is snap-confine.apparmor.in being used on every spread run? | 14:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
mborzecki | i'm off to pick up the kids | 14:21 |
zyga | jdstrand reproduced | 14:22 |
ikey | boy or girl? congrats either way | 14:22 |
* ikey walks out | 14:22 | |
* Chipaca hugs ikey | 14:22 | |
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:23 |
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:24 |
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:25 |
zyga | *hmm* | 14:27 |
zyga | one more idea | 14:29 |
zyga | jdstrand the preserved project state contains the stale profile | 14:30 |
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:31 |
* kalikiana re | 14:35 | |
zyga | https://securelist.com/zero-day-vulnerability-in-telegram/83800/ <- interesting | 14:41 |
jdstrand | zyga: cool, nice find | 14:42 |
jdstrand | zyga: this will help anyone touching the snap-confine profile :) | 14:42 |
mvo | zyga: thanks for finding this! | 14:49 |
mup | PR snapd#4660 closed: systemd: update comment on SocketsTarget <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4660> | 14:55 |
ogra_ | jdstrand, https://forum.snapcraft.io/t/bin-sync-not-allowed/3988/1 | 15:00 |
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:03 |
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:04 |
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:05 |
Nissaar | like this https://paste.ubuntu.com/p/jRzqwK96rk/ ? | 15:07 |
jdstrand | ogra_: yes, I saw. responded | 15:19 |
ogra_ | yeah, i saw too, thanks ! | 15:19 |
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:40 |
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:44 |
Nissaar | https://paste.ubuntu.com/p/vqFY5HVxDZ/ this is my new yaml | 15:46 |
Nissaar | https://paste.ubuntu.com/p/mXwf4N2C8D/ | 15:46 |
Nissaar | the error is the same | 15:47 |
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> | 15:48 |
ogra_ | Nissaar, and the snap did build fine ? no errors or anything ? (how did you create it before using "snap run" ) | 16:03 |
ogra_ | (you should theroetically not actually need build-packages: [ git ], snapcraft should care for it on its own when building) | 16:04 |
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:06 |
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:07 |
ogra_ | do you have a log of the build ? | 16:09 |
Nissaar | ogra_: https://paste.ubuntu.com/p/25zR3JDhHY/ | 16:12 |
Nissaar | here it is | 16:12 |
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:13 |
Nissaar | im on it | 16:14 |
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:16 |
=== nacc_ is now known as nacc | ||
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:17 |
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:21 |
zyga | mvo, almost done with that fixx | 16:59 |
* kalikiana out for the day | 17:10 | |
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:14 |
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:15 |
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:16 | |
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:19 |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
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:25 |
ogra_ | jdstrand, i'll let you know ... (not tonight anymore though ... ) | 17:26 |
jdstrand | ogra_: sure. thanks again :) | 17:27 |
ogra_ | well, thanks for reporting :) | 17:27 |
jdstrand | :) | 17:29 |
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:38 |
Chipaca | "Snapshot 42 checked." leaves you going "...and? what do I _have_, doctor?!?" | 17:39 |
Chipaca | "your blood results came back" "..." "sit down" "...?" "cuppa tea?" <dies> "no sugar then" | 17:40 |
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:41 |
Chipaca | kyrofa: "verified" has the same problem: it tells you the verification finished, not that the snapshot was ok | 17:43 |
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:45 |
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:48 |
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:49 |
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:50 |
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:51 |
mup | PR snapd#4663 opened: interfaces/builtin: allow MM to access login1 <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/4663> | 17:52 |
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:44 |
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:45 |
Chipaca | zyga: as opposed to 明 which should show up as double-wide and counted as double-wide | 18:46 |
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:47 |
zyga | Chipaca in standup | 18:48 |
Chipaca | going ;-) | 18:48 |
jdstrand | davidcalle: hey, ping re https://docs.snapcraft.io/deprecation-notices/dn5 | 18:54 |
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:56 |
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:57 |
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 | 18:59 |
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:00 |
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:01 |
zyga | (I really like that pdf) | 19:02 |
Chipaca | zyga: i know the control sequences | 19:02 |
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:03 |
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:04 |
mup | Bug #1749276 opened: Interface request: dvb <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1749276> | 19:20 |
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:00 |
mvo | zyga: thank you | 20:10 |
* 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:16 |
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> | 20:21 |
=== ikey is now known as ikey|afk | ||
zyga | cachio. linde is belly up | 21:10 |
zyga | *linode | 21:10 |
cachio | zyga, yes, I am trying to reproduce those errors | 22:41 |
cachio | and fix them | 22:41 |
zyga | cachio this is linode failing | 22:43 |
zyga | what can you do? | 22:43 |
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:44 |
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:46 |
cachio | zyga, great, I'll review it | 22:47 |
cachio | zyga, which error are you talking about, some networking problem? | 22:47 |
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 | 22:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!