| mup | Issue snapcraft#1982 closed: Update snaps_tests to use the testing tools from tests.integration <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1982> | 01:16 |
|---|---|---|
| mup | PR snapcraft#2096 closed: tests: don't use os_release and repo from snapcraft <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2096> | 01:16 |
| === epod is now known as luk3yx | ||
| mup | PR snapd#5082 opened: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5082> | 03:32 |
| mborzecki | morning | 04:57 |
| zyga | Good morning | 05:15 |
| zyga | Man, after all the rain last night the plants and flowers outside smell like in some deep forest :-) | 05:16 |
| zyga | Only if it was a few degrees warmer | 05:16 |
| zyga | How are you doing? | 05:16 |
| mborzecki | zyga: it's spring after all :) but yeah everything is in the crazy growth phase, i expect i'll be less than entertained when mowing the lawn this weekend | 05:25 |
| zyga | We don’t have one to mow, maybe rent some sheep :-) | 05:29 |
| mborzecki | sheep, i like mutton :) | 05:32 |
| mborzecki | mvo: morning | 05:33 |
| mvo | hey mborzecki ! | 05:33 |
| mvo | mborzecki: how are you? | 05:33 |
| mvo | mborzecki: and how is snapd, any urgencies or fires? | 05:34 |
| mborzecki | mvo: no fires afaik, zyga anything on-fire on your plate? :) | 05:34 |
| zyga | Just hot breakfast | 05:35 |
| zyga | Welcome back mvo | 05:35 |
| zyga | There is one issue but not widespread and yet to be understood or reproduced | 05:36 |
| mvo | zyga: no fires> I like that! | 05:36 |
| mvo | zyga: which issue is that, do you have more details? | 05:36 |
| zyga | Yeah, just not at my pc yet | 05:37 |
| zyga | Apparmor profiles sometimes go away on boot for some apps | 05:37 |
| mvo | zyga: heh, no worries | 05:37 |
| mvo | zyga: oh, this one - from sergio, right? | 05:37 |
| zyga | Yes | 05:37 |
| mborzecki | mvo: 2.32 branch builds are failing on travis, there was a recurring issue allocating certain machines in linode | 05:38 |
| mvo | mborzecki: ok, slightly unfortunate, lets hope we can put 2.32 to rest. with 2.33 it will all be gce based and great and all that | 05:39 |
| * zyga done with kids, now dog and then just work :) | 06:37 | |
| mvo | mborzecki: did you notice the spread error of 5080? it looks real | 06:37 |
| mborzecki | mvo: yes, i need to adjust the test, we're showing 'system' now in snap interface output | 06:38 |
| mvo | mborzecki: cool, just wanted to make sure its known | 06:38 |
| zyga | #5081 is interesting and short and will open the path for the three fixes to layouts I have pending in case | 06:38 |
| mup | PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081> | 06:38 |
| zyga | in case anyone wants to look :) | 06:38 |
| jamesh | zyga: fwiw, I've got a follow-up PR for the user-mounts branch, that extends the use of Secure.BindMount to file bind mounts too: https://github.com/snapcore/snapd/pull/5082 | 06:40 |
| mup | PR #5082: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5082> | 06:40 |
| zyga | jamesh: ack, I saw | 06:44 |
| zyga | I am waiting for a review from Gustavo who expressed interest but I would love to merge your branch ASAP | 06:44 |
| kalikiana | good morning | 07:09 |
| pstolowski | mornings | 07:11 |
| pstolowski | hey kalikiana | 07:12 |
| zyga | good morning kalikiana | 07:14 |
| kalikiana | o/ | 07:16 |
| mvo | zyga: if you don't have something ready I will look into the mountinfo issue (1763266) now | 07:31 |
| zyga | mvo: the mountinfo with # | 07:31 |
| zyga | mvo: if you want to, I planned to look at that after layout permission issue I found yesterday evening | 07:32 |
| mvo | zyga: this mountinfo has a superblock options with a space | 07:33 |
| zyga | oh | 07:33 |
| zyga | do you have a sample? | 07:33 |
| mvo | zyga: but yeah, looks like a nice morning task | 07:33 |
| mvo | zyga: sure, its in the bug, one sec | 07:33 |
| zyga | we handle spaces because they should be escaped | 07:33 |
| zyga | (so not really spaces) | 07:33 |
| mvo | 28 1 8:4 / / rw,relatime shared:1 - bcachefs /dev/nvme0n1p6:/dev/sda4:/dev/sdb4 rw,errors=continue,background_compression=zstd,foreground_target=ssd,background_target=rotational,promote_target=invalid group 2,fix_errors | 07:33 |
| zyga | uh | 07:33 |
| zyga | looks like a kernel bug :/ | 07:33 |
| mvo | zyga: the superblock options (promote_target=..) has spaces | 07:33 |
| zyga | normally all spaces are escaped | 07:34 |
| zyga | but this has to be done everywhere correctly | 07:34 |
| zyga | looks like not here :/ | 07:34 |
| zyga | (I mean normally in the kernel) | 07:34 |
| mvo | zyga: should we add a workaround or ask the kernel folks to fix it? | 07:35 |
| zyga | double check the spec | 07:35 |
| zyga | and add a workaround, we need to work on the kernels as they are | 07:35 |
| zyga | I'd also send a patch to the kernel after confirming this is wrong | 07:35 |
| mvo | zyga: fair enough, I have a look | 07:38 |
| mvo | zyga: do you mean Documentation/proc.txt when you say "spec"? or is there more of a spec than this file? | 07:44 |
| zyga | this and the man page | 07:44 |
| * mvo nods | 07:46 | |
| mborzecki | hm played a bit with systemd-bootchard to check if we could somehow use it to debug some of the issues with slow startup, but i don't understand why it's discarding samples for some of the processes | 07:52 |
| mborzecki | and not only processes from a snap, just regular processes too | 07:53 |
| Chipaca | mborzecki: how are you using it? | 08:09 |
| Chipaca | mborzecki: and how is it different from 'systemd-analyze plot' | 08:09 |
| mborzecki | Chipaca: i've patched it to support filering by uid (--uid=123) and only sample new processes (--new), basically what i did is run systemd-bootchar from command line, start some snaps, view the graph ;) | 08:11 |
| Chipaca | mborzecki: interesting | 08:13 |
| zyga | mvo: remember we have a 2nd parser in C | 08:16 |
| mvo | zyga: I do | 08:24 |
| mvo | zyga: but I concluded its a kernel bug | 08:24 |
| zyga | yes | 08:24 |
| zyga | I agree | 08:24 |
| zyga | what happens because of the bug? | 08:24 |
| zyga | how do we misbehave? | 08:24 |
| mvo | zyga: he says it does not start but Ithink we fixed this | 08:25 |
| mvo | zyga: it may still have problems when snap-confine runs though | 08:25 |
| zyga | Ubuntu 4.15.0+bcachefs.git20180404.42e79d6-1-generic 4.15.15 | 08:25 |
| zyga | interesting, it's a custom build | 08:25 |
| mvo | zyga: yeah, bcachefs is not upstream yet | 08:27 |
| zyga | huh? I used it a few years ago and it was all in the archive | 08:28 |
| zyga | maybe it was DKMS | 08:28 |
| zyga | I don't remember | 08:28 |
| mvo | zyga: I did a apt search bcache and did not find a dkms, also downloaded our kernel tree (deb) and greped but maybe I missed something? | 08:29 |
| zyga | mvo: does "/var has 'other' write 41777" ring any bells | 08:58 |
| zyga | it's not in our tree | 08:59 |
| mvo | zyga: does not ring a well, where do you see this? | 09:00 |
| Chipaca | zyga: cmd/snap-confine/seccomp-support.c:die("%s has 'other' write %o", path, stat_buf.st_mode); | 09:00 |
| zyga | mvo: when I run "true" | 09:00 |
| zyga | via snap run stack | 09:00 |
| zyga | oh! | 09:00 |
| * zyga has poor grep skills somehow | 09:01 | |
| zyga | thank you chipaca | 09:01 |
| Chipaca | zyga: :) | 09:01 |
| zyga | I grepped through bash and dash | 09:01 |
| * Chipaca is having a good dady so far | 09:01 | |
| Chipaca | day* | 09:01 |
| * Chipaca jinxed it | 09:01 | |
| pstolowski | zyga: wow, that layout fix PR has grown quite a bit | 09:09 |
| zyga | it's my working branch | 09:09 |
| zyga | I chop bits and propose them separately | 09:09 |
| zyga | I'm working on the third fix | 09:09 |
| zyga | in reality it's not that long but there are several places that use a helper so tests changed | 09:09 |
| pstolowski | i see; yes I see a lot of tests | 09:09 |
| mvo | btw, did we figure out why `snap try` is/was so slow for cachio? | 09:12 |
| zyga | mvo: not that I know of | 09:16 |
| * mvo nods | 09:17 | |
| mup | PR snapd#5083 opened: image: support refreshing soft-expired user macaroons in tooling <Created by pedronis> <https://github.com/snapcore/snapd/pull/5083> | 09:43 |
| pedronis | mvo: hi, welcome back | 09:44 |
| mvo | hey pedronis - good morning! | 09:44 |
| zyga | Chipaca: super trivial for you https://github.com/snapcore/snapd/pull/5084 | 09:52 |
| mup | PR #5084: osutil,interfaces: use uint32 for uid, gid <Created by zyga> <https://github.com/snapcore/snapd/pull/5084> | 09:52 |
| mup | PR snapd#5084 opened: osutil,interfaces: use uint32 for uid, gid <Created by zyga> <https://github.com/snapcore/snapd/pull/5084> | 09:52 |
| pedronis | mvo: was your comment a +1 or a question? if it was a question I tried to answer | 09:59 |
| mvo | pedronis: its a compliment, its pretty cool that this can be added now in such a trivial way | 09:59 |
| pedronis | well, I wouldn't call it trivial, it's kind of obscure, but until we know the roadmap a bit unclear how much to spend improving this | 10:00 |
| mvo | pedronis: thinking about it, a small comment in the type toolingAuthContext might be good, something like "// ... is used to support refreshing of soft-expired user macaroons" | 10:00 |
| mvo | pedronis: yes, fair point | 10:01 |
| mup | Bug #1760841 changed: snapd does not parse /etc/fstab properly when using mhddfs <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1760841> | 10:01 |
| pedronis | mvo: pushed, can you look again | 10:04 |
| pedronis | rewrapped the comment now | 10:05 |
| pedronis | also | 10:06 |
| willcooke | zyga, remember the bug from a week or two back where classic snaps were killing the Wayland session? I've just tested the new mesa and it works, but the problem seems to have been resolved by something else in the last couple of weeks. Could be a new xwayland, but we don't think so. Anyway - the problem is resolved in my testing. | 10:13 |
| zyga | willcooke: is this released now? popey has his session being killed by snaps very often lately | 10:13 |
| zyga | willcooke: I will try again on my system | 10:13 |
| zyga | thank you for letting me know | 10:13 |
| zyga | and is this only in bionic or also in xenial? | 10:13 |
| popey | I'm getting my session killed when snap connects the opengl interface | 10:14 |
| popey | hasn't happened since I updated to latest nvidia driver, fingers crossed | 10:14 |
| popey | and I'm not using wayland | 10:14 |
| willcooke | zyga, this is on my 18.04 machine (no Wayland by deafult on 16.04). I just installed and upgraded (no proposed) and rebooted, logged in to the wayland session and made a Skype call. | 10:20 |
| willcooke | If you can still crash it, could you try this ppa? https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging | 10:20 |
| zyga | I will try my bionic machine first | 10:21 |
| Chipaca | any chance of a second review of #4983 ? | 10:32 |
| mup | PR #4983: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4983> | 10:32 |
| zyga | me | 10:33 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#5085 opened: many: fix false negatives reported by vet <Created by zyga> <https://github.com/snapcore/snapd/pull/5085> | 10:37 |
| mup | PR snapd#5086 opened: osutil,interfaces,cmd: use less hardcoded strings <Created by zyga> <https://github.com/snapcore/snapd/pull/5086> | 10:44 |
| thresh | I'm having a weird (?) confinement issue I think? /home/thresh/snap/vlc/common/.cache is no longer writable by the vlc snap? | 10:44 |
| thresh | kf5.kservice.sycoca: ERROR writing database "/home/thresh/snap/vlc/common/.cache/ksycoca5_en_NtlNTj_f3j_omvvKHGdLzPa9Q1A=" . Disk full? | 10:44 |
| zyga | thresh: dimes | grep DENIED | 10:45 |
| zyga | dmesg* | 10:45 |
| thresh | don't see anything for that particular filepath | 10:47 |
| thresh | however | 10:47 |
| thresh | [197467.950484] audit: type=1400 audit(1524566792.497:2281): apparmor="DENIED" operation="link" profile="snap.vlc.vlc" name="/run/user/1000/snap.vlc/vlcRTFlpM.11.slave-socket" pid=17509 comm="vlc" requested_mask="l" denied_mask="l" fsuid=1000 ouid=1000 target="/run/user/1000/snap.vlc/#5640602" | 10:47 |
| zyga | this is a separate issue, snaps cannot create sockets in /run without an interface | 10:48 |
| thresh | that's on Debian Testing, snapd 2.30-5+b1 | 10:48 |
| thresh | oh ok, let me take a look which interface that is | 10:48 |
| zyga | mvo: ^^^ | 10:48 |
| zyga | mvo: we need to hug debian | 10:48 |
| zyga | thresh: 3.30 is very old, we are now at 2.32.5 with a ton of bug-fixes | 10:48 |
| zyga | thresh: we need to update debian | 10:49 |
| thresh | o ok | 10:49 |
| mup | PR snapd#5087 opened: many: fix various issues reported by shellcheck <Created by zyga> <https://github.com/snapcore/snapd/pull/5087> | 10:51 |
| thresh | should I file a bug so it won't be forgotten? | 10:52 |
| thresh | (and where) | 10:52 |
| zyga | thresh: yes, sure on launchpad.net/snapd | 10:52 |
| thresh | speaking about /run, what's the interface name should I use? I browsed https://docs.snapcraft.io/reference/interfaces and didnt find much relevant | 10:53 |
| thresh | I guess I can manually backport snapd to Debian locally just to try it out too | 10:53 |
| zyga | thresh: it looks like some sort of IPC for vlc itself | 10:53 |
| zyga | I don't know | 10:53 |
| zyga | do you know what is that socked used for? | 10:54 |
| thresh | the one in the apparmor denial, I don't | 10:54 |
| thresh | the ksysoca thingie is KDE stuff, happens when a file dialog is starting up under Plasma | 10:55 |
| thresh | I suspet they might be related, since they happen at the same time | 10:55 |
| thresh | +c | 10:55 |
| Chipaca | of course running an exec.Command from a pinned thread doesn't work in 1.6 :'( | 10:56 |
| Chipaca | works just fine in 1.10 | 10:56 |
| Chipaca | darn it | 10:56 |
| Chipaca | mvo: mborzecki: does snapd as packaged depend on sudo? | 11:02 |
| mborzecki | Chipaca: don't think so | 11:02 |
| mborzecki | Chipaca: runuser? | 11:03 |
| Chipaca | mborzecki: is that everywhere we support? | 11:03 |
| mborzecki | Chipaca: it's in util-linux, so maybe, worth checking | 11:04 |
| Chipaca | mborzecki: and does it take a numeric id | 11:05 |
| * Chipaca tries that | 11:05 | |
| pedronis | Chipaca: I'm still blocking #4790, right ? I need to re-review | 11:06 |
| mup | PR #4790: jsonutil/puritan: introducing puritan.String & etc <Created by chipaca> <https://github.com/snapcore/snapd/pull/4790> | 11:06 |
| Chipaca | ¯\_(ツ)_/¯ | 11:06 |
| pedronis | too many open PRs | 11:07 |
| zyga | Chipaca: reviewed 4983 | 11:07 |
| Chipaca | mborzecki: mvo: OTOH snapshots adds a dependency on 'tar', so maybe adding a dependency on sudo isn't too onerous | 11:07 |
| zyga | Chipaca: wanna read "chopTree" PR? :) | 11:10 |
| zyga | I really need it out to do more fixes for layouts | 11:10 |
| === pstolowski is now known as pstolowski|lunch | ||
| zyga | mvo: I sent some trivial cleanup PRs for issues reported by run-checks --static | 11:15 |
| mup | PR snapcraft#2104 opened: many: allow building in containers with no version in project <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2104> | 11:16 |
| mvo | zyga: cool, thank you | 11:18 |
| mvo | Chipaca: no need (on debian/ubuntu) to add a dependency to tar, tar is essential already | 11:20 |
| mvo | Chipaca: sudo otoh is something we should depend on | 11:21 |
| mvo | Chipaca: if there wasn't the "apt-get upgrade" issue | 11:21 |
| Chipaca | mvo: and is util-linux essential? | 11:22 |
| mvo | Chipaca: yes | 11:22 |
| Chipaca | siiigh | 11:22 |
| mvo | Chipaca: why? | 11:22 |
| Chipaca | I'll use runuser then | 11:22 |
| Chipaca | mvo: because runuser doesn't take numeric ids | 11:22 |
| mvo | Chipaca: essential is good | 11:22 |
| Chipaca | mvo: so I need to pass the username | 11:23 |
| mvo | Chipaca: aha, I see, you need sudo for sudo --user ? | 11:23 |
| Chipaca | mvo: nah, i can use runuser | 11:23 |
| Chipaca | it's just that i'd prefer not to :-) | 11:23 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | mvo: just me being grumpy | 11:23 |
| mvo | Chipaca: ok :) | 11:26 |
| ackk | mvo, hi, is the SSL certs setup different in a snap? I added a self-signed cert to the chain and a curl on the host works, but an app in the snap fails fails to check the certificate | 11:29 |
| zyga | ackk: hey | 11:32 |
| zyga | ackk: where are the certificates stored? | 11:32 |
| ackk | zyga, well I added it to /etc/ssl/certs and run update-ca-certificates , so it should be listed there | 11:33 |
| zyga | I see | 11:33 |
| zyga | ackk: we don't allow host certificates to be seen by snap applications | 11:33 |
| zyga | ackk: they only see those that are shipped by the core snap | 11:33 |
| ackk | zyga, and where are those? | 11:33 |
| zyga | in /snap/core/current/etc/ssl | 11:34 |
| ackk | zyga, also, how is that done? if I snap run --shell and list /etc/ssl/certs I do see my cert there | 11:34 |
| zyga | I mean, the same location | 11:34 |
| zyga | just baked as read-only in the core snap | 11:34 |
| ackk | zyga, so if I list /etc/ssl/certs from a snap shell should I see the dir in core? | 11:36 |
| zyga | yes | 11:36 |
| zyga | you will | 11:36 |
| ackk | zyga, I don't seem to | 11:37 |
| zyga | and what do you see? | 11:37 |
| ackk | ack@maas:/home/ack/canonical/src/maas$ ls -la /etc/ssl/certs/ | grep ext-au | 11:37 |
| ackk | lrwxrwxrwx 1 root root 12 Apr 24 09:58 8135fe7f.0 -> ext-auth.pem | 11:37 |
| mup | PR #24: Renamed .bzrignore to .gitignore. Added .coverage. Removed the ./ in front of ignored paths <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapd/pull/24> | 11:37 |
| ackk | lrwxrwxrwx 1 root root 12 Apr 24 09:58 a35f5088.0 -> ext-auth.pem | 11:37 |
| ackk | -rw-r--r-- 1 root root 1159 Apr 24 09:17 ext-auth.pem | 11:37 |
| ackk | zyga, ^ those are my certs | 11:37 |
| ackk | zyga, (from snap run --shell maas) | 11:37 |
| zyga | ah, is this a base18 thing? | 11:37 |
| ackk | yeah | 11:37 |
| zyga | ls | 11:37 |
| ackk | core18 :) | 11:37 |
| pedronis | then is undefined | 11:38 |
| zyga | it should behave the same | 11:38 |
| zyga | but... | 11:38 |
| zyga | ackk: what is /etc/ssl on your host? | 11:38 |
| zyga | is it a symlink? | 11:38 |
| ackk | zyga, you mean outside of the snap? no, it's a dir | 11:39 |
| zyga | hmm | 11:39 |
| ackk | but it seems core18 doesn't have its own /etc/ssl | 11:39 |
| zyga | yeah | 11:39 |
| zyga | aha? | 11:39 |
| ackk | yeah, it's not there | 11:39 |
| zyga | in that case we don't hide it | 11:39 |
| zyga | it should be your host's /etc/ssl | 11:39 |
| zyga | sorry that this is confusing | 11:39 |
| zyga | if I could change one thing we did years ago | 11:40 |
| zyga | I'd make /etc an artificial fs maintained by snapd | 11:40 |
| ackk | zyga, ok, so it it indeed the one of the actual system, but for some reason it seems apps are not getting certs from there | 11:42 |
| zyga | ackk: no idea how SSL stack works | 11:42 |
| pedronis | anyway the current behavior of core18 is likely not what we want | 11:43 |
| ackk | zyga, ok, thanks for confirming the filesystem layout | 11:43 |
| zyga | yes, I agree | 11:43 |
| zyga | though the issue of SSL certs being a bit odd is still a valid one | 11:43 |
| zyga | it's unclear how they work | 11:43 |
| zyga | and definitely not documented that it is what we want | 11:43 |
| pedronis | we have had requests to add certs | 11:44 |
| zyga | yes, I recall | 11:44 |
| pedronis | so really we want something that is the union of various things | 11:44 |
| pedronis | I fear | 11:44 |
| zyga | I mean we should be consistent and not unexpected | 11:44 |
| zyga | and documented | 11:44 |
| pedronis | just offering what's in the host in not what we want though | 11:44 |
| pedronis | or at least not as default | 11:44 |
| zyga | yes, I think we want to look at /etc | 11:45 |
| zyga | to be ready for 20 | 11:45 |
| zyga | since 18 is a bit too soon | 11:45 |
| ackk | zyga, pedronis fwiw I see a weird behavior, if I pass --ca-directory=/etc/ssl/certs to wget it works | 11:45 |
| zyga | can you strace it | 11:46 |
| ackk | but that should be the default (and indeed it works without outside the snap) | 11:46 |
| zyga | to see where it goes normally | 11:46 |
| ackk | zyga, not inside the snap | 11:46 |
| zyga | it probably follows some config/symlinks or other magic | 11:46 |
| zyga | ackk: snap run --strace ;D | 11:46 |
| ackk | ooh | 11:46 |
| ackk | zyga, but how do i run wget i the snap from snap run? | 11:46 |
| zyga | just hack a command that has what you want to run | 11:47 |
| zyga | snap run --stace maas.justesting | 11:47 |
| zyga | --strace :) | 11:47 |
| ackk | oh | 11:47 |
| ackk | zyga, can I manually add a wrapper in a snap try snap and execute it ? :) | 11:47 |
| zyga | yeah | 11:48 |
| ackk | ah, nice | 11:48 |
| * Chipaca -> lunch | 11:48 | |
| ackk | zyga, how do i do that? I created the wrapper file, and added a /snap/bin/maas.wget symlink but it doesn't work | 11:52 |
| zyga | unpack your snap, add a command and snap try it | 11:52 |
| ackk | zyga, do I need to add the command to some manifest? | 11:53 |
| zyga | ackk: yes, to meta/snap.yaml | 11:54 |
| ackk | aah, thanks | 11:56 |
| ackk | zyga, I'm getting this error: cannot change profile for the next exec call: No such file or directory | 11:57 |
| zyga | did you "snap try" after creating the new entry or before it? | 11:57 |
| zyga | snap try should fix it (again) | 11:58 |
| ackk | zyga, even if it's already mounted? | 11:59 |
| zyga | yes | 11:59 |
| ackk | ah, TIL you can do that | 11:59 |
| ackk | I thought bad things would happen | 11:59 |
| mup | PR snapd#5088 opened: tests: checking interfaces declaring the specific interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5088> | 12:00 |
| ackk | zyga, ah, now I can snap run the command, but --strace just reports exit statu 1 | 12:01 |
| ackk | zyga, https://paste.ubuntu.com/p/kR8pwb6gSt/ | 12:02 |
| zyga | hmmm, no idea :/ | 12:03 |
| ackk | ok, thanks | 12:03 |
| mborzecki | off to pick up the kids | 12:12 |
| jdstrand | thresh (cc zyga): that socket denial is actually a 'file' rule for 'l'ock. we allow that in the default template. there might be a bug. can you file it either in the forum or at https://bugs.launchpad.net/apparmor/+filebug? | 12:15 |
| zyga | oh | 12:15 |
| zyga | hey jdstrand :) | 12:15 |
| thresh | jdstrand, I can do it - which information should I include on the launchpad? | 12:16 |
| jdstrand | thresh: please include the denial and the output of: grep '/run/user' /var/lib/snapd/apparmor/profiles/snap.vlc.vlc. then attach grep '/run/user' /var/lib/snapd/apparmor/profiles/snap.vlc.vlc | 12:22 |
| jdstrand | whoops | 12:22 |
| jdstrand | thresh: then attach /var/lib/snapd/apparmor/profiles/snap.vlc.vlc | 12:22 |
| jdstrand | hey zyga :) | 12:23 |
| jdstrand | thresh: oh, and the output of 'snap version' and 'cat /proc/version' | 12:23 |
| zyga | jdstrand: I'm working on three layout issues, two are fixed and third is in progress (just some gardening needed and tests) | 12:24 |
| jdstrand | yeah. I know you need 5081 | 12:24 |
| jdstrand | (and cool) | 12:24 |
| zyga | jdstrand: it would help if you could look at 5081 | 12:24 |
| zyga | yes :) | 12:24 |
| zyga | but no rush, maybe someone else will review it before | 12:24 |
| zyga | I need to garden some testing helpers and add syscall.Lstat | 12:25 |
| zyga | jdstrand: the third bug was that the mimic would not retain the ownership and permissions of the original directory | 12:25 |
| * jdstrand nods | 12:25 | |
| thresh | woah, any idea what went wrong with firefox here: http://thre.sh/stuff/2018-04-24-152506_1523x1011_scrot.png | 12:26 |
| thresh | 59.0.2-1, refreshed in March .. : | 12:26 |
| thresh | :| | 12:26 |
| zyga | jdstrand: fortunately tmpfs can be mounted that way but adding that one extra Lstat call makes a lot of noise | 12:27 |
| thresh | libreoffice does not start now, too | 12:28 |
| jdstrand | thresh: are these snaps? | 12:29 |
| thresh | jdstrand, yes | 12:29 |
| jdstrand | (firefox and libreoffice) | 12:29 |
| jdstrand | thresh: do you have security denials? | 12:29 |
| thresh | I do not have that in dmesg | 12:30 |
| thresh | snap run libreoffice reports "No fonts could be found on the system." | 12:30 |
| jdstrand | thresh: fyi, normally looking at journalctl will give you a complete picture (eg, dbus denials are not logged in dmesg) | 12:30 |
| jdstrand | s/dbus/some dbus/ | 12:31 |
| thresh | nothing new with sudo journalctl --folow and then snap run libreoffice | 12:32 |
| jdstrand | thresh: I'm not sure what that issue would be (others in the channel can comment). it could be either the snaps, something changed on the system underneath them (eg, a dist-upgrade) or a bug in making the fonts available | 12:32 |
| jdstrand | thresh: did you run a dist-upgrade? | 12:33 |
| thresh | I did that a couple days back, but I've re-logged in since then | 12:33 |
| thresh | maybe it's time for a reboot | 12:34 |
| thresh | let me check if non-snapped GTK sotware works | 12:34 |
| jdstrand | since it happened to two different snaps, I would suggest looking at snapd then. zyga can you think of why thresh has snaps that can no longer find fonts? | 12:34 |
| thresh | well, thunderbird (non-snapped) works fine | 12:35 |
| thresh | I'm on core 16-2.32.5, rev 4486 | 12:36 |
| zyga | thresh: what is your host? xenial? | 12:37 |
| zyga | jdstrand: mount profiles are optional so if we fail to mount fonts we don't stop | 12:38 |
| zyga | thresh: can you please run this: | 12:38 |
| zyga | thresh: sudo /usr/lib/snapd/snap-discard-ns firefox | 12:38 |
| zyga | (quit all firefox processes before) | 12:38 |
| zyga | thresh: SNAP_CONFINE_DEBUG=1 snap run firefox | 12:39 |
| zyga | thresh: and attach the output please | 12:39 |
| thresh | zyga, debian 9, testing | 12:39 |
| thresh | err | 12:39 |
| thresh | s/ 9// | 12:39 |
| zyga | debian sid? | 12:40 |
| zyga | did you rebuild snapd form source then? | 12:40 |
| thresh | debian buster | 12:40 |
| thresh | I can no longer reproduce after a reboot, sorry | 12:40 |
| thresh | no, I havent rebuild snapd | 12:40 |
| zyga | I see | 12:40 |
| thresh | snapd version is 2.30-5+b1, snap list core core 16-2.32.5 4486 stable canonical core | 12:41 |
| zyga | is snapd on debian at 2.32.5? | 12:41 |
| zyga | aha | 12:41 |
| zyga | ok | 12:41 |
| zyga | so just Sid is wrong | 12:41 |
| thresh | I *did* have a weird issue with fonts on VLC too, but then it magically started working | 12:41 |
| thresh | so will do that reporting next time I experience that, good to know - thank you | 12:42 |
| thresh | I think Sid has the same snapd as per https://packages.debian.org/search?keywords=snapd | 12:42 |
| mup | PR snapd#5089 opened: tests: adding google-sru backend replacing linode-sur <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5089> | 12:47 |
| === pstolowski|lunch is now known as pstolowski | ||
| thresh | uhm, now that's confusing | 12:58 |
| thresh | thresh@coal ~ $ snap version | 12:58 |
| thresh | snap 2.32.5 | 12:58 |
| thresh | snapd 2.32.5 | 12:58 |
| thresh | dpkg -l snapd reports 2.30, though | 12:58 |
| zyga | thresh: that's deliberate | 12:59 |
| pedronis | you have reexec turned on | 12:59 |
| thresh | thank you | 13:02 |
| mup | PR snapd#5071 closed: tests: replace snap try when possible to speedup tests execution <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5071> | 13:07 |
| mup | PR snapd#5090 opened: cmd/snap-update-ns: poke hokes when creating source paths for layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/5090> | 13:14 |
| zyga | jdstrand: I opened a reasonably simple PR for the 2nd layout issue I found, it's now isolated from issues 1 and 3 | 13:16 |
| thresh | jdstrand, regarding vlc apparmor issue; the problem is, I'm shipping parts of KDE (kio, to be exact), so users' look and feel would be fine under K (think themed Qt) | 13:25 |
| thresh | so I'm not really sure this belongs in an upstream vlc apparmor policy | 13:25 |
| thresh | maybe I'm missing some plug | 13:26 |
| jdstrand | zyga: ack. note I'm still work on sprint stuff | 13:35 |
| zyga | jdstrand: ack | 13:35 |
| zyga | that's fin | 13:35 |
| zyga | fine | 13:35 |
| jdstrand | thresh: well, the issue with vlc is that you are seeing a lock denial and the policy has a rule to allow it | 13:36 |
| jdstrand | thresh: so there might be a bug in the parser or the kernel | 13:36 |
| jdstrand | thresh: please report it so it can be investigated | 13:36 |
| thresh | jdstrand, allright. | 13:38 |
| thresh | grep '/run/user' /var/lib/snapd/apparmor/profiles/snap.vlc.vlc is nada, btw, there is no /run in that file whatsoever | 13:39 |
| Chipaca | mvo: was https://github.com/snapcore/snapd/pull/4750#issuecomment-369862204 meant to be a +1? | 13:41 |
| mup | PR #4750: store: getStructFields now take pointers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4750> | 13:41 |
| cachio | mborzecki, zyga, please could you take a look to https://github.com/snapcore/spread-images/pull/10 again? | 13:41 |
| mup | PR spread-images#10: New task to add debian-sid as a gce image <Created by sergiocazzolato> <https://github.com/snapcore/spread-images/pull/10> | 13:41 |
| cachio | thanks | 13:41 |
| jdstrand | thresh: oh, well, then that isn't an apparmor bug. can you paste the profile somewhere? eg, http://paste.debian.net/ | 13:42 |
| mborzecki | cachio: just finished going though it :) | 13:42 |
| thresh | jdstrand, there you go http://paste.debian.net/1021796/ | 13:46 |
| jdstrand | thresh: so, that profile indicates forced devmode and the lockfile should be handled by /** rwlkm. please file the bug. you can just paste the profile in the bug rather than attach it (since it is small; also leave out the grep for /run) | 13:48 |
| jdstrand | thresh: really, show the denial and then everything in the paste :) | 13:49 |
| cachio | mborzecki, tx | 13:50 |
| thresh | jdstrand, a bug against apparmor then? | 13:51 |
| mup | PR snapd#5091 opened: many: hold refresh when on metered connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5091> | 13:54 |
| jdstrand | thresh: yes please | 13:54 |
| thresh | uhm, that's weird, I never assumed it was devmode | 14:05 |
| thresh | wonder why snap info vlc doesnt tell thatn then | 14:05 |
| thresh | welp, snap install vlc --beta --devmode now shows it as "devmode" in snap info vlc; however I still see security policies applied | 14:06 |
| thresh | heheh | 14:06 |
| thresh | and snap install vlc --beta --jailmode results in error: cannot install "vlc": this system cannot honour the jailmode flag | 14:07 |
| mvo | Chipaca: that was a thank you for the extra explaination. I will reply to the PR but I'm really sitting on the fence about this one, it does not fell (to me and my ignorance) that we win much with the change. but let me read it again | 14:10 |
| niemeyer | Chipaca: I'm off the call, and still have time left before my next activity.. please let me know when you're back | 14:18 |
| Chipaca | niemeyer: i'mback | 14:22 |
| zyga | cachio: after lunch, but sure :) | 14:22 |
| cachio | zyga, tx | 14:23 |
| niemeyer | mvo, Chipaca: Provided a small comment there too | 14:24 |
| niemeyer | Chipaca: Cool, back to the standup? | 14:24 |
| Chipaca | niemeyer: sure | 14:24 |
| niemeyer | (sorry for the noise, it's still here) | 14:24 |
| pedronis | mvo: your addition to the 5s topic, we discussed also the maing of stop vs stop --disable for sockets and timers, which is probably something that work should take into consideration | 14:40 |
| pedronis | s/maing/meaning/ | 14:40 |
| * cachio lunch | 14:42 | |
| pedronis | mvo: I can add something myself if that's ok | 14:43 |
| mup | PR snapcraft#2084 closed: Osx travis <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2084> | 14:44 |
| pedronis | Chipaca: I wondered who would be the first to use Simple ironically ;) | 14:47 |
| * zyga is back from school/dog/lunch break | 14:49 | |
| mvo | pedronis: sure, just add | 14:52 |
| pedronis | mvo: done | 14:52 |
| mvo | pedronis: sorry for the delay, was in a meeting | 14:52 |
| mvo | pedronis: thank you | 14:52 |
| zyga | cachio: https://github.com/snapcore/snapd/pull/5088 has issues in one interface test | 14:53 |
| mup | PR #5088: tests: checking interfaces declaring the specific interface <Simple> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5088> | 14:53 |
| zyga | cachio: https://github.com/snapcore/snapd/pull/5089 needs a trivial fix | 14:54 |
| mup | PR #5089: tests: adding google-sru backend replacing linode-sur <Simple> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5089> | 14:54 |
| mup | PR snapd#5083 closed: image: support refreshing soft-expired user macaroons in tooling <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5083> | 14:55 |
| Chipaca | pedronis: I wonder why you wondered | 14:55 |
| Chipaca | I blame zyga | 14:55 |
| zyga | I blame zyga too | 14:56 |
| Chipaca | zyga: this is about #5066 | 14:56 |
| mup | PR #5066: overlord/snapshotstate/backend: introducing the snapshot backend <Simple> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5066> | 14:56 |
| zyga | haha | 14:57 |
| zyga | well, I didn't do _that_ :D | 14:57 |
| Chipaca | zyga: simple means it's got no poles | 14:57 |
| Chipaca | zyga: right? | 14:57 |
| zyga | no poles or no slavs? | 14:57 |
| Chipaca | zyga: it's hard to tell if you're running with the joke or thought i meant Poles, over IRC. Just to be clear: I meant no zeros in the complex plane, which are called poles | 14:58 |
| Chipaca | bah. 1/f etc etc | 14:59 |
| zyga | oh, I didn't run with that joke, I must have intersected with the real plane earlier | 14:59 |
| Chipaca | zyga: https://en.wikipedia.org/wiki/Zeros_and_poles#/media/File:Gamma_abs_3D.png | 15:00 |
| Chipaca | zyga: dem poles | 15:00 |
| zyga | Chipaca: now I will be reading wikipedia for the next hour! | 15:01 |
| Chipaca | psh. amateur. | 15:01 |
| mup | PR snapcraft#2102 closed: tests: use a common cache for the integration tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2102> | 15:05 |
| mup | PR snapd#5059 closed: tests: add pending shutdown detection <Go! Go! Go!> <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5059> | 15:09 |
| kyrofa | Chipaca, if I run `snap watch --last=refresh`, it sounds like that will _not_ cover automatic refreshes, right? | 15:09 |
| kyrofa | (since auto-refresh is also an item) | 15:10 |
| Chipaca | kyrofa: do you have an auto-refresh change there? | 15:11 |
| Chipaca | kyrofa: I'd have to go look through code to answer with confidence (and i'd rather not given my current stack) | 15:12 |
| Chipaca | kyrofa: if you do, curl -s --unix-socket /run/snapd.socket http://localhost/v2/changes?select=all | jq '.result[].kind' | 15:12 |
| kyrofa | Chipaca, yeah there's an auto-refresh there | 15:13 |
| kyrofa | It's done, though | 15:13 |
| Chipaca | kyrofa: then that's the one you want to wait on, if you're looking at the same issue kalikiana was looking at | 15:13 |
| Chipaca | kyrofa: if it's Done, then watch will return immediately | 15:14 |
| kyrofa | Chipaca, ah, you're familiar with that issue? Yeah, kalikiana is using --last=refresh, my question is whether it should actually be --last=auto-refresh | 15:15 |
| Chipaca | kyrofa: yeah probably | 15:15 |
| Chipaca | kyrofa: it'll be harder to test for :-( | 15:15 |
| Chipaca | but yes | 15:15 |
| Chipaca | the situation as described was with an auto-refresh ongoing | 15:15 |
| kyrofa | No reason we can't do both, but in a realistic scenario, I think the auto-refresh is the real problem | 15:15 |
| kyrofa | Indeed | 15:15 |
| Chipaca | as long as you ignore the error, yes | 15:16 |
| Chipaca | (watch will error if there is no change of that kind) | 15:16 |
| kyrofa | Oh, good to know | 15:16 |
| Chipaca | kyrofa: try 'snap watch --last=potato' | 15:17 |
| * Chipaca hopes he hasn't made anybody nervous with that | 15:17 | |
| kyrofa | Chipaca, it worked! | 15:20 |
| kyrofa | (kidding) | 15:20 |
| Chipaca | kyrofa: by the way, what was the reason for the validation error you were getting yesterday? | 15:20 |
| kyrofa | Chipaca, the app command wasn't pointing at an existing file | 15:20 |
| Chipaca | kyrofa: did you read that in the log? | 15:21 |
| kyrofa | Chipaca, no, after zyga mentioned that apps were validated I just took a closer look. I had fixed it by the time you mentioned it was actually logged | 15:21 |
| Chipaca | aw, ok | 15:22 |
| Chipaca | kyrofa: I'll probably be adding a '(details in the log)' or something to help people find that info | 15:22 |
| Chipaca | not any time soon though | 15:22 |
| * Chipaca 's plate is full | 15:22 | |
| kyrofa | Chipaca, how quickly after first boot do you think snapd would try to autorefresh? | 15:29 |
| kyrofa | Immediately? | 15:29 |
| kyrofa | Or is there a delay or some sort? | 15:30 |
| mvo | kyrofa: with the current snapd there is a delay of ~2h iirc | 15:30 |
| Chipaca | there's a hold off of 2h i think, and then a random window | 15:30 |
| Chipaca | kyrofa: see 'snap refresh --time' | 15:30 |
| kyrofa | Can I hack around that for a test? Convince it to autorefresh? | 15:30 |
| kyrofa | Oh, handy | 15:31 |
| Chipaca | kyrofa: I think you should be able to give it a window small enough to be useful in a test, yes | 15:32 |
| Chipaca | I never remember the syntax for it though | 15:32 |
| kyrofa | Oh right, THAT feature, yeah let me look it up | 15:32 |
| kalikiana | Chipaca: kyrofa It was my understanding `snap watch --last=refresh` covers automatic refresh. Is that indeed not the case? | 15:36 |
| Chipaca | kalikiana: watch is fairly dumb and snap-side only, and it's a simple match on the change kind | 15:37 |
| kalikiana | Hum | 15:37 |
| kalikiana | Okay | 15:37 |
| Chipaca | kalikiana: code is in cmd/snap/last.go if you want to look | 15:38 |
| mup | PR snapd#5087 closed: many: fix various issues reported by shellcheck <Simple> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5087> | 15:52 |
| mup | PR snapd#5092 opened: snap: do not use overly short timeout in `snap {start,stop,restart}` <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5092> | 15:59 |
| pedronis | Chipaca: I reviewed #4790 | 16:07 |
| mup | PR #4790: jsonutil/puritan: introducing puritan.String & etc <Created by chipaca> <https://github.com/snapcore/snapd/pull/4790> | 16:07 |
| pedronis | Chipaca: it needs a different summary when merged | 16:07 |
| Chipaca | pedronis: ack, thanks | 16:08 |
| Chipaca | i'll probbaly get to it tomorrow | 16:08 |
| === pstolowski is now known as pstolowski|afk | ||
| mup | PR snapd#5084 closed: osutil,interfaces: use uint32 for uid, gid <Simple> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5084> | 16:18 |
| * kalikiana eod | 16:18 | |
| zyga | willcooke: sorry for the late response, I just logged into a fully up to date 18.04 wayland session and yes, Skype still kills it | 16:35 |
| willcooke | zyga, interesting. Did you try the canonica-x ppa too? | 16:35 |
| zyga | willcooke: this is on a thinkpad t470 with just intel graphics | 16:35 |
| zyga | gnome-shell segvfault https://www.irccloud.com/pastebin/I8gILg4y/ | 16:36 |
| zyga | no, I haven't | 16:36 |
| zyga | I'm about to, just looking fot that PPA name | 16:36 |
| willcooke | https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging | 16:36 |
| zyga | thank you | 16:37 |
| willcooke | yw! | 16:37 |
| * ogra_ guesses the times are over weher you could just blame microsoft and be done ... | 16:39 | |
| ogra_ | *where | 16:39 |
| ogra_ | slangasek, when you initially created the pc-gadget, you didnt include a GPL boilerplate ... was that an oversight or is it actually not needed to include it (asking because of https://forum.snapcraft.io/t/gadget-snap-licenses/ ) | 16:44 |
| ogra_ | (not that anybody bothered to include it later either ... ) | 16:45 |
| zyga | willcooke: crashed | 16:46 |
| zyga | so no change | 16:46 |
| zyga | let me know if anyone on your team needs any hands-on time with this | 16:46 |
| willcooke | k, that sucks. | 16:46 |
| willcooke | zyga, would you mind commenting on here please? https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1754693 | 16:49 |
| mup | Bug #1754693: Xwayland crashed with SIGABRT in st_renderbuffer_delete() <amd64> <apport-crash> <bionic> <reproducible> <ubuntu> <wayland-session> <mesa (Ubuntu):Confirmed> <https://launchpad.net/bugs/1754693> | 16:49 |
| zyga | not at all, one sec | 16:50 |
| slangasek | ogra_: I think at the time we were creating those gadget snaps it wasn't clear what the convention was for including license information; but the fact that it wasn't there at all, definitely an oversight | 16:52 |
| ogra_ | slangasek, ok, thanks .. just wanted to make sure it wasnt on purpose ... (because bootloaders are special or whatnot) | 16:53 |
| slangasek | ogra_: bootloaders are not magically immune to copyright law ;-) | 16:54 |
| ogra_ | yeah, i thought so ... :) | 16:54 |
| kyrofa | roadmr, I'm having trouble logging in with snapcraft, is there a problem? | 17:07 |
| roadmr | there is | 17:07 |
| kyrofa | I see a "Snap downloads interruption" but everything is green | 17:07 |
| roadmr | kyrofa: at the very top of the page there's an announcement | 17:07 |
| kyrofa | Right, that's what I'm talking about | 17:08 |
| roadmr | I don't understand then. | 17:08 |
| noise][ | that shouldn't be affecting login though | 17:09 |
| ogra_ | oh, is that the reason why i'm bombed with store mails recently ? | 17:11 |
| ogra_ | Launchpad uploaded this snap package to the store, but the store failed to | 17:11 |
| ogra_ | scan it: | 17:11 |
| ogra_ | __all__: The upload does not appear to be a valid package. | 17:11 |
| roadmr | kyrofa, noise][ : I did see some sluggishness with unrelated store API accesses, that *might* have caused snapcraft login to barf | 17:11 |
| ogra_ | the 4th now in 20min | 17:11 |
| roadmr | ogra_: yes, that would be the store being unable to download the snap for scanning | 17:11 |
| nessita | kyrofa, what's the error you are getting? | 17:11 |
| ogra_ | ah, k | 17:11 |
| kyrofa | nessita, 504 | 17:12 |
| roadmr | ogra_: if any of your snaps end up in a wedged state and you can't wrangle them out yourself, let me know. We should have fixed that, this is a trial by fire for our fix :D | 17:12 |
| kyrofa | Took a long time to discharge, and now it's getting 504s on /dev/api/account | 17:12 |
| ogra_ | roadmr, fun fact ... nit even remotely "my snaps" :) thats snapcraft itself (i seem to be a collaborator for whatever reason) | 17:13 |
| ogra_ | *not even | 17:13 |
| roadmr | ogra_: oh fun :) | 17:13 |
| kyrofa | ogra_, yeah it's owned by snappy-dev or whatever that group is | 17:17 |
| ogra_ | yeah | 17:17 |
| nessita | kyrofa, just calling snapcraft login? | 17:18 |
| kyrofa | nessita, after entering my login info and 2fa, yeah | 17:18 |
| kyrofa | Also happening with exported logins on travis | 17:19 |
| nessita | kyrofa, ok so many that was the dashboard API for when getting the account details | 17:19 |
| nessita | roadmr, ^ | 17:19 |
| mup | PR snapcraft#2104 closed: many: allow building in containers with no version in project <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2104> | 17:21 |
| roadmr | righto | 17:21 |
| mup | Bug #1766667 opened: commands in a container cannot write to inherited filehandles such as stdout <Snappy:New> <https://launchpad.net/bugs/1766667> | 17:21 |
| * cachio afk | 17:44 | |
| zyga | mvo: does 5092 mean we need a .6? | 18:31 |
| zyga | I'm about to EOD so I won't review it today | 18:31 |
| zyga | but I was curious | 18:31 |
| kyrofa | roadmr, nessita any progress? I still can't login, blocking work | 18:31 |
| nessita | kyrofa, see is-outage, there is a network issue in the datacenter | 18:37 |
| kyrofa | Do we have any communication around this? Tweets, forum posts? | 18:44 |
| roadmr | kyrofa: our procedure calls for updating status.snapcraft.io (which we did, the announcement at the top), and post something sticky in the forum (we didn't, apologies - the procedure we have is newish) | 19:02 |
| roadmr | kyrofa: we hadn't been asked to tweet about it :) if you were to look at twitter, where would you look? | 19:02 |
| roadmr | (which account I mean - to e.g. decide if we use an existing one or create a new one) | 19:02 |
| roadmr | kyrofa, nessita : as for the "everything is normal" thing on status.snapcraft.io - the thing is that we use an external provider for this | 19:02 |
| kyrofa | snapcraftio, but snapcraftstatus or something would be even better | 19:03 |
| roadmr | and they consider a service green if it responds to a small subset of queries, even if slowly (as is the case now) | 19:03 |
| kyrofa | roadmr, I'm getting 504s, that's not slow, that's timeout | 19:03 |
| roadmr | they are more lenient than our clients :) so that's why the dots all show green. Our IR will have an action to check if we can tighten those times | 19:03 |
| roadmr | kyrofa: right - the monitoring service does NOT do "snapcraft login" so it wouldn't hit the code path that's timing out for you | 19:04 |
| roadmr | kyrofa: so you would prefer a dedicated twitter account that only posts when the status changes? and not something buried in snapcraftio's normal feed? | 19:06 |
| kyrofa | roadmr, I think of this as the ideal: https://twitter.com/githubstatus | 19:06 |
| nessita | sorry for the missing post, that was my bad, here it is https://forum.snapcraft.io/t/slow-snap-store-downloads-and-slow-sso-interactions/5121 | 19:06 |
| kyrofa | roadmr, but that's just me, give it some thought | 19:06 |
| roadmr | thanks for the ideas! | 19:07 |
| kyrofa | Whatever the deal is with the dashboard, something's not right. That's all I wanted to say | 19:07 |
| kyrofa | s/dashboard/status thing/ | 19:07 |
| kyrofa | nessita, should that be sticky? | 19:13 |
| nessita | kyrofa, I'm not sure what sticky is in the forum, sorry | 19:13 |
| roadmr | nessita: noise][ can make the post sticky if you point him to it | 19:14 |
| roadmr | (means it'll appear at the top until unstickied) | 19:15 |
| noise][ | done | 19:15 |
| nessita | thanks | 19:15 |
| thresh | how are apparmor policies apply to binaries other than the main snap entrypoint running under the same namespace? | 19:48 |
| kyrofa | thresh, depends on how the binaries are being run. By the "main entrypoint" ? | 19:51 |
| kyrofa | If so, its confinement is inherited | 19:51 |
| thresh | so what I do is I run snap run vlc, then Qt (which VLC is linked to ) I guess forks some KDE-related processes | 19:52 |
| thresh | I'm looking at what's hapenning with VLC beta snap on 18.04, and it's the same issue as I have on Debian, apparmor denials | 19:52 |
| kyrofa | thresh, what does that KDE-related process do? | 19:53 |
| kyrofa | This KDE-related thing must be something you're shipping in VLC? Do you need to (i.e. is it required?) | 19:55 |
| thresh | correct, that's something I ship in VLC snap. I need it for VLC to look nice under KDE (e.g. use Open File dialogs relevant to the platform it's launched on). | 19:55 |
| thresh | as Qt shipped in Xenial is too bad with that, and I don't get any theming (well, only the default windows 95 one) on any platform except Unity. | 19:56 |
| kyrofa | thresh, ah, the windows 95 one. Isn't minimalist "in" these days? | 19:57 |
| kyrofa | thresh, do you get these denials on xenial as well? Or just 18.04 and debian? | 19:58 |
| thresh | the apparmor messages on 18.04 are http://thre.sh/stuff/snaps/apparmor-issues/messages.txt | 19:58 |
| thresh | I'm yet to test xenial, don't have it on my virtualbox yet | 19:58 |
| kyrofa | thresh, this utility must be dbus-based? | 20:00 |
| kyrofa | thresh, what is it called? I suspect we need an interface covering it | 20:00 |
| kyrofa | Like xdg-open | 20:00 |
| kyrofa | jdstrand, will know far more | 20:01 |
| kyrofa | Darn hexchat. Minus the comma | 20:01 |
| thresh | I have no idea | 20:09 |
| thresh | thanks kyrofa, I guess my usecase is really weird | 20:14 |
| thresh | but then I wonder what other Qt5 apps do when they want to look nice everywhere | 20:14 |
| kyrofa | thresh, yeah great question. There must be similar functionlity for gtk, no? | 20:15 |
| kyrofa | thresh, I can't pretend to be much of a desktop dev though | 20:15 |
| kyrofa | kenvandine, are you around? | 20:15 |
| kyrofa | (as much as I'd love to be sometimes... I miss qt) | 20:15 |
| kenvandine | kyrofa, yup | 20:15 |
| kenvandine | kyrofa, lol | 20:15 |
| * kenvandine reads | 20:16 | |
| kyrofa | kenvandine, yeah starting around 12:48 | 20:17 |
| thresh | https://forum.snapcraft.io/t/how-do-people-build-qt-gui-applications-snaps/3714/4 says there is no good way, except using newer Qt5 than shipped in Xenial, which I do now | 20:18 |
| kenvandine | thresh, so what's your question? How to get better looking toolkit provided dialogs like the file picker? | 20:21 |
| thresh | well, it all stems from there, yes. | 20:21 |
| kenvandine | thresh, and you're bundling qt5 right? | 20:23 |
| kenvandine | how's kde involved at all? | 20:23 |
| thresh | the problem is, when I use newer Qt5 - from KDE Neon, built for 16.04, since I can not build VLC on anything newer that might have newer nicer Qt5, weird things are happening when running in snap. | 20:23 |
| thresh | I am. And to be able to utilize KDE support in newer Qt5, I also bundle some K* packages. | 20:24 |
| thresh | without all that, I don't even get icons on VLC interface when running on anything else than Unity. | 20:24 |
| kenvandine | probably better to ask greyback | 20:24 |
| kenvandine | greyback, ^^ | 20:24 |
| kenvandine | thresh, and you use desktop-qt5 right? | 20:25 |
| kenvandine | from the snapcraft-desktop-helpers | 20:25 |
| thresh | yes. | 20:25 |
| kenvandine | maybe that's trying to exec some k* process internally, and of course snap doesn't allow exec | 20:26 |
| kenvandine | [ 1858.294589] audit: type=1400 audit(1524599246.290:314): apparmor="DENIED" operation="link" info="Failed name lookup - deleted entry" error=-2 profile="snap.vlc.vlc" name="/run/user/1000/snap.vlc/#34" pid=8907 comm="vlc" requested_mask="l" denied_mask="l" fsuid=1000 ouid=1000 | 20:26 |
| kenvandine | that's probably the most curious thing | 20:26 |
| thresh | it seems like it does exec it yes, but I *do* see output from ksysoca and friends, so they are launched (but probably are confined so they cant open much?) | 20:27 |
| kenvandine | yeah | 20:27 |
| kenvandine | ultimately this is what xdg-desktop-portal is for | 20:27 |
| thresh | 12:15:41 < thresh> kf5.kservice.sycoca: ERROR writing database "/home/thresh/snap/vlc/common/.cache/ksycoca5_ru_ukOlKAnKObXkPNxFifGg50oJz9A=" . Disk full? | 20:28 |
| kenvandine | but we aren't quite there yet | 20:28 |
| thresh | 12:16:26 < thresh> and Couldn't write "/home/thresh/snap/vlc/273/.config/kdeglobals" . Disk full? | 20:28 |
| jdstrand | thresh: I forwarded the bug to jjohansen, who is apparmor upstream. on Debian and Ubuntu 18.04, they both have the 4.15 kernel. they also have the new apparmor userspace | 20:28 |
| thresh | stuff like that | 20:28 |
| jdstrand | thresh: so I suggest putting more info into the bug. it feels like a regression in lock rules | 20:28 |
| thresh | thanks jdstrand! | 20:28 |
| jdstrand | thresh: more info if you find new things | 20:29 |
| jdstrand | that is | 20:29 |
| jdstrand | jjohansen: fyi, http://thre.sh/stuff/snaps/apparmor-issues/messages.txt for more locking issues. I'm told that is with 4.15 from bionic | 20:29 |
| thresh | I've attached that to the bugreport on launchpad, too | 20:29 |
| jdstrand | jjohansen: s/locking/lock rule/ | 20:29 |
| jdstrand | thresh: cool, thanks | 20:30 |
| thresh | kenvandine, oh yeah, I'll be more than happy if I wouldnt have to shipp all that since it's not exactly VLC domain :) | 20:30 |
| kenvandine | thresh, we're close :) | 20:30 |
| jdstrand | jjohansen: actually, thresh already attached that to the bug, so nothing new here it sounds like | 20:31 |
| jdstrand | jjohansen: what is interesting is that, aiui, the 18.04 4.15 kernel is of course a strict profile, where the Debian 4.15 kernel has that wide open 'devmode' profile | 20:32 |
| jdstrand | jjohansen: ('aiui' because I've not verified myself any of this) | 20:32 |
| thresh | jfyi just tried keepassxc, and it doesnt even show any labels on my KDE, so yeah.. | 20:35 |
| thresh | thanks everyone, I appreciate it | 20:36 |
| thresh | good night | 20:36 |
| Chipaca | mwhudson: moin | 21:05 |
| Chipaca | mwhudson: https://pastebin.ubuntu.com/p/7fx8cCKp36/ with go < 1.10 seems to point to a bug in Go, but 1.10 has changes in the area that seem to fix it (maybe by chance; haven't looked in detail). Do you think it's worth reporting? | 21:08 |
| jbicha | kenvandine: I installed the gnome-characters 3.28 snap https://paste.debian.net/1021881/ is that a bug that it suggests I connect to the gnome-3-26-1604 snap? | 21:25 |
| jbicha | and the gnome-3-28-1804 snap description says it's built using xenial | 21:29 |
| mwhudson | Chipaca: national holiday today | 21:50 |
| Chipaca | mwhudson: :-) enjoy | 21:50 |
| === devil is now known as Guest92578 | ||
| kenvandine | jbicha, not a bug, that is built against gnome-3-26-1604 | 22:50 |
| kenvandine | jbicha, oh, you installed the beta | 22:52 |
| kenvandine | the console output from the helpers needs to be made more generic, we won't be able to know which platform you need | 22:53 |
| kenvandine | jbicha, we aren't quite ready to use the stuff based on 1804 :( | 22:53 |
| jbicha | how come it can't know which platform is needed? | 22:53 |
| kenvandine | the shell script won't know | 22:53 |
| kenvandine | not without querying snap | 22:54 |
| kenvandine | and that would slow down startup time | 22:54 |
| jbicha | but wouldn't it only need to do if the snap failed to launch normally? | 22:54 |
| kenvandine | maybe we can grep generated yaml in $SNAP/meta/ | 22:54 |
| kenvandine | true, only if the mount point is empty | 22:55 |
| kenvandine | we'll do that | 22:55 |
| jbicha | do you want a bug filed somewhere? | 22:55 |
| kenvandine | https://github.com/ubuntu/snapcraft-desktop-helpers | 22:55 |
| kenvandine | jbicha, please do | 22:55 |
| kenvandine | with auto-connecting and auto-downloading we should actually never see that message :) | 22:56 |
| kenvandine | real soon now | 22:56 |
| jbicha | https://paste.debian.net/1021889/ strange response from snap | 22:58 |
| kenvandine | jbicha, that's very odd | 22:58 |
| kenvandine | jbicha, gnome-logs from beta won't work btw :) | 22:59 |
| kenvandine | it crashes... | 22:59 |
| kenvandine | core18 doesn't provide log-observe | 22:59 |
| kenvandine | is my current theory | 22:59 |
| jbicha | um, gnome-logs 3.28 actually runs here… | 22:59 |
| kenvandine | from candidate it will | 22:59 |
| kenvandine | not from beta | 23:00 |
| jbicha | they're the same thing right now I think? | 23:00 |
| kenvandine | oh | 23:00 |
| kenvandine | ok, maybe i never pushed the broken one :) | 23:00 |
| kenvandine | it must be the one using gnome-3-26-1604 | 23:00 |
| jbicha | that makes sense because I didn't even connect anything this time | 23:01 |
| kenvandine | that is an odd message from snapd though | 23:01 |
| kenvandine | i need to run though | 23:01 |
| kenvandine | later! | 23:01 |
| mup | Issue snapcraft#2037 closed: core refresh in container build breaks build <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/2037> | 23:26 |
| mup | PR snapcraft#2098 closed: lxd: wait for on-going refreshes to finish <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2098> | 23:26 |
| mup | Issue snapcraft#1919 closed: Add Always support when sending errors <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1919> | 23:29 |
| mup | PR snapcraft#2101 closed: errors: implement an always option to send to sentry <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2101> | 23:29 |
| mup | PR snapcraft#2103 closed: package: make use of snapcraftctl snapcraft features <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2103> | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
