| mup | PR snapd#4869 closed: cmd/snap-update-ns: use x-snapd.{synthetic,needed-by} in practice <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4869> | 00:20 |
|---|---|---|
| mup | PR snapcraft#2010 opened: Release/2.40+18.04 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2010> | 01:37 |
| === chihchun_afk is now known as chihchun | ||
| mborzecki | morning | 06:12 |
| phoenix_firebrd | morning | 06:13 |
| mup | PR snapd#4864 closed: daemon: support 'system' as nickname of the core snap <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4864> | 06:37 |
| mup | PR snapd#4841 closed: snap/pack, cmd/snap: add `snap pack --check-skeleton` <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4841> | 06:38 |
| zyga | good morning | 06:51 |
| zyga | quick breakfast and brb | 06:52 |
| phoenix_firebrd | any of you fellows use a intel gpu? | 06:52 |
| zyga | phoenix_firebrd: probably most of us | 06:54 |
| phoenix_firebrd | zyga: When you find time can you check If you are able to play a VP9 encoded file(ex: videos from youtube) using the vlc snap with hardware acceleration enable and using vaapi for hardware acceleration? | 06:58 |
| zyga | yes, sure | 07:01 |
| zyga | can you give me an example URL? | 07:02 |
| === chihchun is now known as chihchun_afk | ||
| phoenix_firebrd | zyga: any youtube video is fine | 07:07 |
| zyga | any? | 07:07 |
| zyga | aren't they encoded in different formats | 07:07 |
| phoenix_firebrd | zyga: as far as i know all the youtube videos are displayed using vp9/webm format in the latest browsers by default | 07:07 |
| zyga | I mean, I'd love to help but I want to make the test meaningful | 07:08 |
| mvo | hey zyga ! good morning | 07:08 |
| zyga | hey :-) | 07:08 |
| phoenix_firebrd | zyga: do you have youtube-dl | 07:08 |
| zyga | no, I don't believe I do | 07:08 |
| phoenix_firebrd | zyga: try this as an example https://www.youtube.com/watch?v=D6tC1pyrsTM | 07:09 |
| zyga | let me try to get a video and play it | 07:09 |
| phoenix_firebrd | zyga: takecare, youtube-dl by default downloads the highest quality video and the above video is a 4k video and take a lot of size | 07:10 |
| zyga | phoenix_firebrd: which channel of vlc do you want to tets | 07:12 |
| zyga | *test | 07:13 |
| phoenix_firebrd | zyga: normal | 07:13 |
| zyga | stable? ok | 07:13 |
| phoenix_firebrd | zyga: I think it contains vlc verion 3.0.1 | 07:13 |
| phoenix_firebrd | zyga: ok | 07:14 |
| === chihchun_afk is now known as chihchun | ||
| zyga | phoenix_firebrd: I'll let you know once the download finishes | 07:19 |
| phoenix_firebrd | zyga: ok | 07:20 |
| zyga | mvo: what shall we do with 4765 | 07:33 |
| mup | PR snapd#4874 opened: tests: a bunch of test fixes for s390x from looking at the autopkgtest logs <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4874> | 07:34 |
| mup | PR snapd#4872 closed: tests: add workaround for s390x failure <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4872> | 07:35 |
| mborzecki | zyga: is this line correct? https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/snap-confine.apparmor.in#L367 the current autotools setup configured with --libexecdir=/usr/lib/snapd | 07:39 |
| zyga | looking | 07:39 |
| zyga | oh | 07:40 |
| zyga | no, looks like a bug | 07:40 |
| zyga | nice catch! | 07:40 |
| zyga | please tag the fix with 2.32 as well | 07:40 |
| mborzecki | ok | 07:40 |
| mup | PR snapd#4863 closed: snap: don't create empty Change with "Hold" state on disconnect (2.32) <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4863> | 07:42 |
| zyga | jjohansen: I'm running your kernel today, so far no issues, I will periodically run the script that finds dangling symlinks and report back | 07:44 |
| mborzecki | zyga: #4875 | 07:46 |
| mup | PR #4875: cmd/snap-confine: fix ptrace rule with snap-confine peer <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4875> | 07:46 |
| mup | PR snapd#4875 opened: cmd/snap-confine: fix ptrace rule with snap-confine peer <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4875> | 07:46 |
| zyga | thank you | 07:47 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| zyga | mborzecki: approved | 07:48 |
| zyga | man, we will have a lot of back ports to do | 07:48 |
| mborzecki | hopefully those are single patch fixes :) | 07:48 |
| zyga | mvo: I failed to fix the last bug yesterday, it's not that I don't know what to do it is just _how_ to do it | 07:49 |
| zyga | phoenix_firebrd_: hey | 07:52 |
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| zyga | so I think it doesn't work | 07:52 |
| zyga | [00007f7608001ca0] glconv_vaapi_x11 gl error: vaInitialize: unknown libva error | 07:52 |
| zyga | libva info: VA-API version 0.39.0 | 07:52 |
| zyga | libva info: va_getDriverName() returns 1 | 07:52 |
| zyga | libva error: va_getDriverName() failed with operation failed,driver_name=i965 | 07:52 |
| zyga | [00007f7608001ca0] glconv_vaapi_drm gl error: vaInitialize: operation failed | 07:52 |
| zyga | this is on a i5 skylake chip | 07:53 |
| phoenix_firebrd | zyga: hi | 07:53 |
| zyga | the video plays but using significant amount of CPU | 07:53 |
| === chihchun is now known as chihchun_afk | ||
| phoenix_firebrd | zyga: I think skylake supports hybrid decoding of vp9 | 07:54 |
| phoenix_firebrd | zyga: can you paste the profiles list? | 07:54 |
| zyga | what profiles? | 07:54 |
| phoenix_firebrd | zyga: the rest of the livainfo | 07:54 |
| phoenix_firebrd | zyga: vainfo i mean | 07:54 |
| zyga | one sec | 07:54 |
| zyga | https://www.irccloud.com/pastebin/ZuZnIbE4/ | 07:55 |
| zyga | note that this is vainfo outside of the snap | 07:55 |
| phoenix_firebrd | zyga: are you on 18.04? | 07:56 |
| zyga | yes | 07:56 |
| phoenix_firebrd | zyga: ah | 07:56 |
| phoenix_firebrd | zyga: https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1756380 | 07:56 |
| mup | Bug #1756380: vaapi VP9 hardware decoding not working anymore in bionic <intel-vaapi-driver (Ubuntu):Confirmed> <libva (Ubuntu):Invalid> <https://launchpad.net/bugs/1756380> | 07:56 |
| phoenix_firebrd | zyga: vp9 profiles are absent for supported hardware in 18.04 | 07:56 |
| zyga | phoenix_firebrd: but shouldn't this matter in snaps | 07:57 |
| zyga | is this a kernel side issue or a userspace issue | 07:57 |
| phoenix_firebrd | zyga: i mean just in case of the vainfo you gave from outside of snap | 07:57 |
| zyga | right | 07:57 |
| zyga | did you see the erros from libva I posted earlier | 07:58 |
| zyga | when starting up vlc | 07:58 |
| phoenix_firebrd | zyga: ya | 07:58 |
| phoenix_firebrd | zyga: is there a way to update the i965-va-driver package in snap to 2.1.0? | 07:59 |
| zyga | only by rebuilding the snap | 07:59 |
| zyga | mborzecki: ^ FYI, one of the things we could eventually support is pluggable va drivers | 07:59 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | Mornings! | 08:00 |
| phoenix_firebrd | zyga: what are the steps that has to be done to fix this driver bug issue so that it does not show up in the vlc snap | 08:01 |
| zyga | I don't understand the issue so I cannot say | 08:01 |
| phoenix_firebrd | zyga: by driver i mean the one used in the snap core i guess | 08:01 |
| === chihchun_afk is now known as chihchun | ||
| zyga | phoenix_firebrd: are you asking what is needed to stop shipping libva in a particular snap, like vlc? | 08:02 |
| Mirv | I think it would be nice to consider whether the version in bionic archives could be upgraded or cherry pick fixed, but that's outside of snappy realm | 08:03 |
| phoenix_firebrd | zyga: If you know that the intel vaapi driver is buggy and that causes vlc snap to display corrupted frames while playback, how do you fix that | 08:03 |
| zyga | phoenix_firebrd: I don't know anything about libva, I cannot help with that | 08:04 |
| zyga | phoenix_firebrd: perhaps vlc folks who make the snap can say more | 08:04 |
| zyga | I can help with snapd side of the problem | 08:04 |
| phoenix_firebrd | zyga: if you want to update the display drivers what snap will you update? core or vlc or both? | 08:04 |
| zyga | phoenix_firebrd: vlc | 08:04 |
| zyga | phoenix_firebrd: the core doesn't ship any | 08:05 |
| phoenix_firebrd | zyga: so you mean different media player snaps can ship with different version of drivers ? | 08:05 |
| zyga | not really drivers, drivers are in the kernel | 08:05 |
| zyga | of userspace libraries, yes | 08:05 |
| phoenix_firebrd | zyga: This list of packages used to compile a snap is called manifest right? | 08:06 |
| mup | PR snapd#4876 opened: packaging: recommend "gnupg" instead of "gnupg1 | gnupg" <Created by mvo5> <https://github.com/snapcore/snapd/pull/4876> | 08:06 |
| zyga | phoenix_firebrd: snap may be built entirely from source (except from the toolchain perhaps) so the word package is perhaps misleading | 08:06 |
| zyga | I don't know how vlc snap is built, for example, I didn't look at it that closely | 08:07 |
| zyga | phoenix_firebrd: so it's possible to both reuse binary builds from a distribution and to build latest and greates of everything from source | 08:07 |
| Mirv | a quick look at vlc snap tells me they're building a lot from scratch at least, as they have Qt 5.10 | 08:08 |
| phoenix_firebrd | zyga: how I see what are the contents of the core snap | 08:09 |
| zyga | phoenix_firebrd: just look at it? it's usually mounted in /snap/core/current/ | 08:09 |
| Mirv | but the intel driver they have is from 2016 | 08:10 |
| kalikiana | good morning | 08:11 |
| kalikiana | o/ Mirv | 08:11 |
| Mirv | right, they are basically using unmodified 16.04 LTS version of i965-va-driver, not building it themselves. since they're already building the whole Qt, it sounds to me they could be interested in building some of this too | 08:12 |
| Mirv | kalikiana: o/ :) | 08:12 |
| mborzecki | zyga: by the looks of it, plain makefile stuff (even though I'm doing some templates inside) is way faster than autotools | 08:14 |
| mborzecki | the actual build part is comparable, the largest win is not running configure | 08:14 |
| zyga | mborzecki: yeah, that is very typical | 08:15 |
| phoenix_firebrd | zyga: I just found that the intel vaapi driver is shipped with the vlc snap and not with core snap. Where to file a bug on a vlc snap ? | 08:16 |
| zyga | phoenix_firebrd: well, I told you that | 08:17 |
| zyga | phoenix_firebrd: run "snap info vlc" | 08:17 |
| zyga | and see the contact URL | 08:17 |
| phoenix_firebrd | zyga: ok, let me check | 08:20 |
| phoenix_firebrd | zyga: thank you so much for the support | 08:26 |
| zyga | thank you for using snaps :-) | 08:26 |
| zyga | Ok, I think I have a nice way to fix the bug with layouts leaking thing to the host | 08:35 |
| mborzecki | `ERROR: Conflicting profiles for /snap/core/4278/usr/lib/snapd/snap-confine^mount-namespace-capture-helper defined in two files:` this something new? | 08:49 |
| mborzecki | full log https://paste.ubuntu.com/p/xCzYR4Ztpv/ | 08:51 |
| oSoMoN | is snapd 2.32+18.04~pre5 known to be broken? | 08:52 |
| oSoMoN | after dist-upgrading today, all my snaps are marked broken | 08:52 |
| oSoMoN | rebooting seems to "fix" them, but then they won't start | 08:52 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| zyga | mborzecki: I saw that once yesterday | 09:00 |
| zyga | mborzecki: looks like atomic file write left some stuff behind | 09:01 |
| zyga | oSoMoN: yes | 09:01 |
| oSoMoN | zyga, want me to file a bug report or start a thread on the forum to gather information on the issue? | 09:01 |
| mborzecki | zyga: just saw it in 4875, restarted the build to see if it's something random | 09:02 |
| mwhudson | pedronis: hi did you see this? https://forum.snapcraft.io/t/avoiding-snap-refresh-in-live-sessions-i-e-installers/4468/4 | 09:09 |
| * mwhudson is not really here | 09:09 | |
| mup | PR snapcraft#2011 opened: tests: run tests on Trusty on Travis <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2011> | 09:10 |
| pedronis | mwhudson: yes, I don't have particular opinions, is this something snapd needs to do or the installer could do? | 09:10 |
| mwhudson | pedronis: how could the installer do it? | 09:10 |
| mwhudson | i'm all for not changing snapd at this point of the cycle | 09:10 |
| pedronis | mwhudson: move refresh.hold from 2h to 60 days ? | 09:11 |
| mwhudson | pedronis: oh just execute snap set core refresh.hold 60d? | 09:11 |
| pedronis | well now+60d | 09:11 |
| pedronis | but yes | 09:11 |
| pedronis | would that be enough? | 09:12 |
| mwhudson | oh ok then that sounds easy :) | 09:12 |
| mwhudson | i think if people boot the installer and then don't do anything for 60 days, i think i'm ok with things breaking | 09:12 |
| pedronis | to be precise you can set anywhere in the future | 09:13 |
| pedronis | but after 60 days is not respecte | 09:13 |
| pedronis | d | 09:13 |
| mwhudson | haha | 09:13 |
| mwhudson | pedronis: i had another awful hack in mind, which was to install core and subiquity unasserted | 09:13 |
| mwhudson | but this sounds better than that | 09:13 |
| mwhudson | pedronis: which version of snapd has refresh.hold support? | 09:14 |
| pedronis | 2.32 | 09:14 |
| mwhudson | ok | 09:15 |
| mwhudson | and that's not in bionic because i uploaded go 1.10 but well | 09:15 |
| pedronis | well our plan is to have in bionic in the images | 09:15 |
| mwhudson | oh no it is in bionic now | 09:15 |
| mwhudson | awesome | 09:15 |
| pedronis | it has issues it seems though (but unrelated to this) | 09:16 |
| mwhudson | pedronis: thanks | 09:17 |
| * mwhudson goes to bed | 09:17 | |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| mvo | mwhudson: it is in bionic now | 09:40 |
| mvo | mwhudson: I mean 2.32 is in bionic, we asked to ingore the s390x failures for now as this only affects the covermode=atomic right now | 09:41 |
| Chipaca | hmm, why is connecting to interfaces so slow all of a sudden | 09:41 |
| mvo | Chipaca: I noticed this as well | 09:42 |
| Chipaca | ok, I'll dig | 09:42 |
| Chipaca | mvo: do we still not have auto-prereqs? | 09:42 |
| mvo | Chipaca: 2.32 should have them | 09:43 |
| mvo | Chipaca: is that not working for you? iirc we do not pull in new prereq on refresh, that is a missing feature/bug | 09:44 |
| Chipaca | mvo: 2.32~pre4+git612.2003af8~ubuntu16.04.1 isn't working for me | 09:44 |
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| Chipaca | that is, "snap install evince" resulted in no gnome platform snap | 09:44 |
| mvo | in related news: does someone know why master is broken? it seems ~200 tasks are aborted | 09:44 |
| mvo | Chipaca: I look once the current fire is out | 09:47 |
| mvo | Chipaca: but I see the same here, slightly sad | 09:47 |
| Chipaca | mvo: k | 09:47 |
| abeato | kalikiana, hey, have you ever seen this snapcraft error when cross-compiling: https://paste.ubuntu.com/p/z4BW75yhXB/ ? (edge channel) | 09:48 |
| kalikiana | abeato: Hmm no I think that's new to me | 09:50 |
| kalikiana | abeato: Did this break recently? | 09:50 |
| abeato | kalikiana, well, it used to work last week | 09:51 |
| kalikiana | Also on edge? | 09:51 |
| abeato | yes | 09:52 |
| abeato | artful fyi | 09:53 |
| abeato | kalikiana, stable works | 09:54 |
| abeato | a regression in edge then | 09:54 |
| kalikiana | Yeah, looks like it :-/ | 09:55 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| kalikiana | abeato: Can you file a bug, please? | 09:55 |
| abeato | kalikiana, yup | 09:55 |
| mup | PR snapd#4877 opened: snap-confine: fallback to /lib/udev/snappy-app-dev if the core is older <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4877> | 09:58 |
| zyga | mvo: looking | 09:59 |
| abeato | kalikiana, https://bugs.launchpad.net/snapcraft/+bug/1757094 | 09:59 |
| mup | Bug #1757094: snapcraft in edge channel (2.39.2+git46.c22d7e2) fails to cross-compile kernel <Snapcraft:New> <https://launchpad.net/bugs/1757094> | 09:59 |
| zyga | +1 :) | 10:00 |
| mvo | zyga: yay, thank you | 10:02 |
| mvo | zyga: now we just need to unbreak master | 10:02 |
| mvo | zyga: and *hopefully* the world is a happy place again | 10:02 |
| zyga | is master broken? | 10:02 |
| mvo | zyga: yeah, next PR comming that tests my theory on the why | 10:02 |
| zyga | oh, ok | 10:02 |
| mup | PR snapd#4878 opened: tests: disable 18.04 spread tests in google for now <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4878> | 10:03 |
| mvo | zyga: it looks like its a test problem with the google 18.04 | 10:03 |
| zyga | I didn't see any issues | 10:03 |
| zyga | but I'm still on an older branch from yesterday | 10:03 |
| mvo | zyga: no worries, only spread not our code | 10:03 |
| mvo | zyga: also - "make fmt" on bionic produces some different output than "make fmt" on older releases it seems | 10:03 |
| mvo | zyga: not a great morning so far, too many fires | 10:04 |
| zyga | yes | 10:04 |
| zyga | I noticed | 10:04 |
| zyga | this is why it's no longer enforced | 10:04 |
| zyga | when things quited down I will reindent with something saner | 10:04 |
| zyga | or see if I can coerce newer indent | 10:04 |
| kalikiana | abeato: Thanks! | 10:12 |
| kalikiana | abeato: Can you link the snap you're building there? | 10:13 |
| ogra_ | that might be tricky | 10:14 |
| ogra_ | (customer kernel) | 10:15 |
| abeato | kalikiana, that ^ | 10:16 |
| kalikiana | Hmm okay. | 10:16 |
| mvo | Chipaca: turns out the problem with evince is that there is on `content: <tag>` line in the interface, I'm looking if we should use default here | 10:16 |
| pedronis | mvo: we have code that sets defaults | 10:21 |
| pedronis | but probably is not called for this case | 10:21 |
| pedronis | bit fragile to duplicate it though | 10:21 |
| mvo | pedronis: yeah, I'm poking a bit to see if there is a nice way | 10:27 |
| Chipaca | mvo: i think oSoMoN and/or kalikiana could land a fix meanwhiles :-) | 10:30 |
| mvo | Chipaca: yeah, fix is trivial, just adding "content: <some-string>" on both the evince plug and the gnome-3-26-1604 slot | 10:31 |
| Chipaca | mvo: ‘content: like a river’ | 10:33 |
| Chipaca | (http://www.azquotes.com/quote/1262712) | 10:33 |
| pedronis | mvo: mmh, it's it not done much earlier, I suppose the issue is that we read the snap yaml but don't validate it | 10:33 |
| pedronis | (which would set the defaults) | 10:33 |
| pedronis | I was remembering the old code, but in the new world this should happen somewhere in snap/ | 10:34 |
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| zyga | mvo: I finally have good progress on the (I named it) trespassing bug | 10:36 |
| zyga | I'll get a coffee and finish it soon | 10:36 |
| mvo | Chipaca: nice and poetic | 10:37 |
| mvo | pedronis: hm, that might be it | 10:37 |
| mvo | pedronis: it looks like nowday "interfaces.BeforePrpareSlot" must have been called | 10:39 |
| pedronis | mmh | 10:42 |
| mvo | pedronis: interfaces.SanitizePlugsSlots calls this, so you are right I think, somewhere there is a sanitation missing | 10:42 |
| pedronis | mvo: it's called by the ReadInfo* but not by just parsing | 10:44 |
| pedronis | mvo: I think you added code to details.go in store that calls parsing of yaml but not that | 10:44 |
| mvo | pedronis: indeed, that sounds like the culprit | 10:45 |
| pedronis | mvo: otoh it seems to be called only for installed snaps | 10:45 |
| pedronis | atm | 10:46 |
| pedronis | mvo: Chipaca: it's all a bit confusing: ReadInfoFromSnapFiles calls Validate bot not SanitizePlugsSlots and ReadInfo calls SanitizePlugsSlots but not Validate | 10:46 |
| pedronis | pstolowski: ^ | 10:47 |
| pedronis | what was the thinking there? | 10:47 |
| pstolowski | pedronis: yes just looking. seems to be my oversight in the refactoring :( | 10:47 |
| mvo | pedronis: I'm still looking but afaict store/details.go calls InfoFromSnapYaml() which does not sanitzze, I wonder if we can/should do it there because that is used by the various bits afaict | 10:47 |
| pedronis | I know why we don't validate already installed snaps | 10:48 |
| pedronis | the assumption is that is done once | 10:48 |
| pedronis | before | 10:48 |
| pedronis | but SanitizePlugsSlots has side effects we always need | 10:48 |
| pedronis | for values of always | 10:48 |
| mvo | pedronis: yeah, I wonder if nowdays it should be "annotatePlugsSlots" or something, its doing much more than to sanitize | 10:50 |
| mup | PR snapcraft#2011 closed: tests: run tests on Trusty on Travis <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/2011> | 10:53 |
| pstolowski | mvo: what do you mean with more? afair the only difference with old implementation is the fact that it collects invalid ones in BadInterfaces | 10:53 |
| mvo | pstolowski: it calls BeforePrepareSlot for each interface | 10:54 |
| mvo | pstolowski: for the content interface this adds some defaults (like when content: is missing it adds an implicit "content: <slot-name>") | 10:54 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| mvo | kenvandine: could you please update evince so that default-provider is just a snap name? right now it is "gnome-3-..:gnome-3-..." | 10:56 |
| pstolowski | mvo: I see. BeforePepare* is the old Sanitize*, we were doing that before, it's just that we don't call SanitizePlugSlots now when we should after the code was moved around | 10:56 |
| mvo | pedronis: http://paste.ubuntu.com/p/2NjMYChFzR/ <- this might be what we need, i.e. run this always | 10:56 |
| mvo | pstolowski: yeah, it was just a idle though that the name is not fully conveying what is happening (but I guess one could argue that part of the sanitize is that missing fields are updated with sensible defaults) | 10:57 |
| pedronis | it's reasonable, I don't know if there is some assumption that that code does that would explode if we don't Validate first though | 10:57 |
| mvo | pedronis: ReadInfo() would still get sanitization via infoFromSnapYamlWithSideInfo | 10:58 |
| mvo | pedronis: all tests explode because we are not prepared for this in the tests, so there is some work here :) and of course I need to double check with pstolowski that this is sensible | 10:59 |
| pedronis | seems orthogonal right now | 10:59 |
| mvo | pedronis: orthogonal to what? | 10:59 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| pedronis | sorry, I was answering my question: I mean the jobs Validate does and SanitizePlugsSlots do | 11:00 |
| pedronis | they don't seem to depend on each other | 11:00 |
| pedronis | (atm) | 11:00 |
| mvo | pedronis: yeah, validate is doing something else right now indeed | 11:00 |
| mvo | Chipaca, pedronis fwiw, I tested the evince with the updated location for the SanitizePlug and the content is installed (well, would be installed if default-provider was a snap name ;) but that is a problem of the snap and easy to fix there) | 11:01 |
| mvo | pedronis I think I will prepare a PR with the change and test updates and let pstolowski and you double check, sounds reasonable? | 11:02 |
| pstolowski | mvo: the original invariant was (and still is) that every snap.Info that we create and return has all the plugs and slots sanitized and we don't expose broken ones via this struct | 11:02 |
| pedronis | mvo: ok | 11:02 |
| mvo | pstolowski: yeah, I think this invariant is currently not honored | 11:02 |
| pstolowski | mvo: right, my bad :( | 11:03 |
| mvo | pstolowski: when you create a snap.Info via InfoFromSnapYaml() | 11:03 |
| mvo | pstolowski: no worries | 11:03 |
| pstolowski | mvo: I can take this bug | 11:03 |
| mvo | pstolowski: http://paste.ubuntu.com/p/2NjMYChFzR/ is probably what we want plus test updates, if you can take it that would be great | 11:03 |
| mvo | pstolowski: the real world test is to snap install evince, it should pull in the gnome-3-... content snap but it does not right now because the defaults are not set | 11:04 |
| mvo | pstolowski: (john discovered this bug). if you have any question, just let me know | 11:04 |
| * mvo goes back to unbreaking bionic | 11:05 | |
| pstolowski | mvo: yes, that fix looks sensible as long as this is indeed the central (or only) place that needs this | 11:05 |
| pstolowski | mvo: ok, i'll work on this right away; is this some kind of a blocker atm? | 11:06 |
| mvo | pstolowski: its not terrible but nice to have | 11:06 |
| mvo | pstolowski: 2.32 will have the install of content providers so if we can unbug it, that would be great | 11:07 |
| mvo | pstolowski: I mean, its not terrible urgent (no need to skip lunch over it) but ideally we should fix it today if we can | 11:07 |
| pstolowski | ack, will be aiming at that | 11:08 |
| mvo | thanks pstolowski ! | 11:08 |
| pstolowski | pedronis: one question re your comment "what happens on update with old tasks that had the previous thing?" to the interface hooks; that's a valid concern and I think we need to make sure update conflicts with these hooks (there is already some code for connect/disconnect conflict on update, but I need to check if it would do that). does that sound sensible? | 11:11 |
| pstolowski | mvo: sure, thanks for catching & sorry for the trouble /o\ | 11:11 |
| mvo | pstolowski: no worries | 11:15 |
| mup | PR snapd#4878 closed: tests: disable 18.04 spread tests in google for now <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4878> | 11:20 |
| mup | PR snapd#4879 opened: tests: revert "tests: disable 18.04 spread tests in google for now" <Created by mvo5> <https://github.com/snapcore/snapd/pull/4879> | 11:21 |
| cachio | sergiusens, hey, I've seen some errors on autopkgtests https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/s/snapcraft/20180319_163043_7404b@/log.gz | 11:26 |
| sergiusens | cachio: feel free to ignore armhf until the new autopkgtest roll out comes into place | 11:27 |
| cachio | sergiusens, nice, thanks | 11:27 |
| mup | PR snapd#4880 opened: [RFC] cmd, data: plain make <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4880> | 11:28 |
| mborzecki | zyga: plain make ^^ | 11:28 |
| zyga | oh,cool | 11:28 |
| zyga | mborzecki: queued for after standup | 11:28 |
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| mvo | mborzecki: nice speedup | 11:38 |
| mvo | mborzecki: hard to grasp how auto* is so inefficient, speed 6x | 11:39 |
| mborzecki | all the perl/sed/coreutils invocations add up | 11:39 |
| mborzecki | i'm looking into why #4875 fails, also #4871 failed in a way that's sort of similar | 11:42 |
| mup | PR #4875: cmd/snap-confine: fix ptrace rule with snap-confine peer <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4875> | 11:42 |
| mup | PR #4871: cmd/snap-confine: fix Archlinux compatibility <Created by Erick555> <https://github.com/snapcore/snapd/pull/4871> | 11:42 |
| mborzecki | it looks as if when updating snap-confine apparmor profile, some temp files are left behind | 11:42 |
| mborzecki | mvo: zyga: any ideas how that could be possible? | 11:43 |
| zyga | no, | 11:43 |
| zyga | we just write it using atomic thing | 11:43 |
| phoenix_firebrd | zyga: I checked the vlc snap info, it shows a url to a general support page. I checked the vlc support page, I shows a general bug reporting page, not anything specific to snaps, also on searching for existing bugs, there was not a single snap related bug report. So is there a specific place dedicated for vlc snap bugs? | 11:43 |
| zyga | phoenix_firebrd: no, it's their snap and their bug reports | 11:44 |
| mvo | mborzecki: looking | 11:45 |
| mborzecki | zyga: hm it looks like a temp file made by us though, /etc/apparmor.d/snap.core.4278.usr.lib.snapd.snap-confine.gVv662JKQnGl the suffix is 12 chars, the same as we use | 11:45 |
| mvo | mborzecki: do you have a link to the failure log or a pastebin of it? | 11:46 |
| zyga | yes | 11:46 |
| mborzecki | mvo: https://paste.ubuntu.com/p/xCzYR4Ztpv/ | 11:46 |
| mvo | ta | 11:46 |
| zyga | mborzecki: but I don't know why it would stay behind now | 11:46 |
| mvo | zyga: that is ensureDirState, right? that is used all over the place so should be well tested | 11:47 |
| zyga | yes | 11:47 |
| zyga | and the actual writing is done by atomic thing AFAIR | 11:47 |
| zyga | so I doubt it's something newly broken there | 11:47 |
| mvo | or its a race | 11:48 |
| mvo | i.e. we write things at the same time when the profile is loaded? | 11:48 |
| zyga | hmmmm | 11:48 |
| zyga | perhaps | 11:48 |
| zyga | but who would load it? | 11:48 |
| mvo | (a long shoot) | 11:48 |
| mvo | I have no idea :) | 11:48 |
| zyga | apparmor loads that profile | 11:48 |
| zyga | but we start after apparmor | 11:48 |
| zyga | then snapd reloads that profile | 11:48 |
| zyga | but _exactly_ that profile (not everything else) | 11:48 |
| zyga | the error is weird btw, | 11:48 |
| zyga | ah | 11:49 |
| zyga | + aa-enforce /etc/apparmor.d/usr.lib.snapd.snap-confine.real | 11:49 |
| zyga | this is aa-enforce doing things | 11:49 |
| zyga | it's just a test thing, we never touch that from snapd | 11:49 |
| zyga | so something goes wrong | 11:49 |
| zyga | and then much later we run aa-enfroce | 11:49 |
| zyga | *aa-enforce | 11:49 |
| zyga | and that looks for system-wide consistency for some reason | 11:49 |
| phoenix_firebrd | zyga: so a bug in vlc snap has to be reported in the regular vlc bug reporting channel? | 11:50 |
| zyga | phoenix_firebrd: yes, snaps don't have packagers in the same sense as other linux packages, typically upstreams package and ship the snap | 11:50 |
| mborzecki | zyga: mvo: just ran this test through spread and it was all good | 11:51 |
| zyga | yeah, I saw this once yesterday | 11:51 |
| mvo | zyga: maybe we need to run aa-enforce checks in each restore to catch the offender? | 11:51 |
| mborzecki | do we touch those profiles while installing the package? | 11:51 |
| zyga | and it's first time I ever saw it | 11:51 |
| phoenix_firebrd | ok | 11:51 |
| zyga | mvo: I think that's what happened here | 11:51 |
| zyga | or maybe I'm wrong | 11:51 |
| mvo | zyga: I think this makes sense - but what is calling aa-enforce? | 11:52 |
| zyga | I think it's one of the tests actually | 11:52 |
| mborzecki | mvo: the test does | 11:53 |
| zyga | mvo: main/snap-confine | 11:53 |
| zyga | mvo: one idea | 11:53 |
| zyga | mvo: somehow we stop snapd at the wrong time | 11:53 |
| zyga | and we have this in the state tarball | 11:53 |
| zyga | it would be good if someone managed to reproduce this with -debug | 11:54 |
| mborzecki | zyga: running it now with the same seed as the tests | 11:55 |
| zyga | NB: I doubt it's deterministic anyway | 11:55 |
| zyga | but let's see | 11:55 |
| phoenix_firebrd | zyga: can you point me to a place, where there is a complete documentation about snaps and the related process | 11:55 |
| zyga | phoenix_firebrd: ha, I wish we had one, we are doing most of the work on forum.snapcraft.io and on a new (test URL) site at https://snapdocs.labix.org/ | 11:57 |
| phoenix_firebrd | zyga: If i am doing "sudo snap install vlc " in ubuntu, from where does the vlc snap gets fetched? | 12:01 |
| zyga | phoenix_firebrd: from the snap store | 12:03 |
| === pstolowski is now known as pstolowski|lunch | ||
| phoenix_firebrd | zyga: snapstore.com? | 12:05 |
| zyga | no | 12:05 |
| zyga | it's a service at... | 12:05 |
| zyga | https://api.snapcraft.io/ AFAIR | 12:06 |
| zyga | the actual package download is from a CDN | 12:06 |
| phoenix_firebrd | zyga: so in case of vlc, Vlc snap gets created and uploaded to the snap store by the vlc maintainers and then we fetch from it during install? | 12:06 |
| zyga | yes | 12:07 |
| zyga | exactly that | 12:07 |
| phoenix_firebrd | zyga: cdn of course | 12:07 |
| zyga | mvo: I'm testing the fix for trespassing bug now, looks good for 2.32 from layout POV today | 12:09 |
| phoenix_firebrd | zyga: I guess I have to create a vlc account and file a bug with them. I think I will windup today with this. Thank you. | 12:09 |
| zyga | I will need to backport all the things that were labelled as 2.32 and only merged to master | 12:09 |
| zyga | phoenix_firebrd: thank you! I think you can also shoot them an email somewhere but I have never tried reporting VLC bugs directly | 12:09 |
| phoenix_firebrd | zyga: I am thinking of collection preliminary information by directly talking to some devs in vlc irc channel, if one exists and then will email and/or file a bug report | 12:11 |
| zyga | yeah, that's a good idea | 12:11 |
| === JanC_ is now known as JanC | ||
| cachio | niemeyer, change in spread already updated | 12:17 |
| zyga | aww, drat | 12:18 |
| * zyga tinks | 12:19 | |
| zyga | thinks | 12:19 |
| pedronis | pstolowski|lunch: my question was more about the older version of the same hooks? did we partially support hook already in stable? | 12:23 |
| === phoenix_firebrd is now known as n | ||
| === n is now known as phoenix_firebrd | ||
| cachio | mvo, hey | 12:35 |
| cachio | I am pushing a fix for bionic | 12:35 |
| mup | PR snapd#4881 opened: tests: make tests run with specific bionic release avoiding take the last one <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4881> | 12:38 |
| zyga | jdstrand: man, fixing the "trespassing" bug (where we write to real /etc is really hard) | 12:52 |
| zyga | it requires some fair amount of changes | 12:52 |
| Chipaca | mvo: fwiw, https://forum.snapcraft.io/t/auto-connection-for-gnome-3-24-content-interface/1379/79 | 12:56 |
| === pstolowski|lunch is now known as pstolowski | ||
| zyga | jdstrand: my approach was to interact with the secureMk* family of functions | 12:57 |
| zyga | and before calling open(..., O_CREAT,...) or mkdirat() or symlinkat() check that fstatfs reports that we are on a tmpfs | 12:58 |
| zyga | this is not perfect but it is a close approximation to "is this a mimic" | 12:58 |
| zyga | if something is a tmpfs we just carry on | 12:59 |
| zyga | if it's not a tmpfs we check if the path we are attempting to make looks legitemately | 12:59 |
| mborzecki | zyga: https://paste.ubuntu.com/p/tQg4GVfMK5/ | 12:59 |
| zyga | brb | 13:00 |
| zyga | mvo: I will be a moment late to the standup | 13:00 |
| phoenix_firebrd | zyga: I spoke to a vlc dev, they say that the one-line-patch to fix the driver bug, has to be backported to 16.04 by ubuntu, they will then re-release an update vlc snap with the updated driver. | 13:05 |
| phoenix_firebrd | zyga: how likely ubuntu will backport a patch to 16.04? | 13:06 |
| zyga | phoenix_firebrd: not sure but they don't have to wait for that, they can just build the right version of the driver from source and put that in the snap | 13:06 |
| phoenix_firebrd | zyga: I guess their policy stops them. | 13:07 |
| phoenix_firebrd | zyga: they say they use the stuff from 16.04 to target the 16.04 core i guess | 13:08 |
| phoenix_firebrd | zyga: like for example the va-api version 2 uses libva2 which cannot be installed in 17.10, because of the dependency issue | 13:09 |
| phoenix_firebrd | zyga: do you know how long it will take for the ubuntu core snap to migrate to 18.04? | 13:10 |
| ogra_ | it wont, the design will change | 13:11 |
| ogra_ | (you wuill be able to simply declare 16 or 18 in your snaps snapcraft.yaml and it will work on either of them, pulling in what it needs) | 13:11 |
| ogra_ | but thats probably a thing that will still take til ... well.. october ? | 13:12 |
| phoenix_firebrd | ogra_: this October ? | 13:12 |
| ogra_ | no, october in 7 years | 13:12 |
| ogra_ | :P | 13:12 |
| ogra_ | (indeed this october :) ) | 13:12 |
| zyga | phoenix_firebrd: ubuntu core16 and core18 will exist in parallel | 13:13 |
| zyga | phoenix_firebrd: so vlc snap maintainers can hop onto the 18 one when they feel like it and when it is ready | 13:13 |
| zyga | it won't be a "hard" change | 13:13 |
| zyga | snaps will use base they want and will switch whenever they want | 13:13 |
| kenvandine | mvo, oh, all of our snaps do that | 13:13 |
| kenvandine | mvo, so it should just be the snap name? | 13:14 |
| phoenix_firebrd | ogra_: :) | 13:15 |
| phoenix_firebrd | zyga: ok | 13:15 |
| kenvandine | mvo, the documentation says to use the name and slot | 13:17 |
| kenvandine | default-provider (plug): name and slot of preferred providing snap (<SNAP>:<SLOT>) | 13:17 |
| mborzecki | zyga: temp files do not seem to come from snapd-state.tar.gz https://paste.ubuntu.com/p/D8qf6j6CwY/ | 13:20 |
| mvo | kenvandine: thank you, I'm in a meeting right now, I will review the docs | 13:23 |
| mvo | kenvandine: please do nothing for now, I will look in a bit | 13:23 |
| kenvandine | mvo, ok, thx! | 13:24 |
| jdstrand | mvo, zyga: looking at backscroll from last week, https://github.com/snapcore/snapd/pull/4822 would kill boot speed, especially on armhf. I'm glad you figured out another way | 13:32 |
| mup | PR #4822: interfaces/apparmor: skip apparmor cache <Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4822> | 13:32 |
| oSoMoN | mvo, zyga: how is that bionic fix coming along? | 13:38 |
| mvo | oSoMoN: fix is reviewed we are waiting for tests | 13:39 |
| oSoMoN | mvo, excellent, thanks! | 13:40 |
| mvo | jdstrand: thanks, yes, we never wanted to do this for real :) | 13:40 |
| oSoMoN | mvo, do the autopkgtests for snapd exercise installing and running real-world snaps? | 13:40 |
| zyga | jdstrand: yes, that was a RFC really, to see what the problem is | 13:42 |
| zyga | oSoMoN: mvo is handling that | 13:42 |
| * jdstrand hugs mvo and zyga | 13:43 | |
| mvo | oSoMoN: yes | 13:43 |
| mvo | oSoMoN: well, depends on what you mean by real-world :) it does run lxd and a bunch of small snaps, it does not run chromium or firefox | 13:44 |
| zyga | jdstrand: btw, did you see my apparmor parser wrapper | 13:44 |
| zyga | with more control over caching? | 13:44 |
| jdstrand | zyga: not yet. is it a PR? | 13:45 |
| oSoMoN | mvo, ack, thanks | 13:46 |
| zyga | jdstrand: it was but got closed (it was another RFC, let me show that to you quickly) | 13:46 |
| mvo | oSoMoN: this particular problem is caused by bionic being ahead of core | 13:47 |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/4827/files | 13:47 |
| mup | PR #4827: cmd/snap-apparmor-parser: add a prototype apparmor parser <Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4827> | 13:47 |
| mvo | oSoMoN: if you switch your core to "beta" (snap refresh --beta core) you are good again too | 13:47 |
| zyga | I grew it slightly to handle removing later but this version shows the general idea | 13:47 |
| zyga | (I was also saving both the source file and the binary file) | 13:47 |
| zyga | (source after preprocessing) | 13:47 |
| jdstrand | mvo: you mentioned in backscroll that https://bugs.launchpad.net/snappy/+bug/1460152 needed love. that (and a regression fix for it) was committed to upstream apparmor in 2015 | 13:51 |
| mup | Bug #1460152: apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates) <patch> <Snappy:Fix Released by mvo> <Snappy 15.04:Fix Released by mvo> <apparmor (Ubuntu):Fix Released> <https://launchpad.net/bugs/1460152> | 13:51 |
| jdstrand | mvo: if it is continuing to not do what we want, then I think a new bug is in order | 13:51 |
| zyga | cachio: you want apparmor-profiles package | 13:51 |
| mborzecki | zyga: cachio: fwiw. apparmor is disabled in snap-confine for opensuse https://github.com/snapcore/snapd/blob/master/packaging/opensuse-42.2/snapd.spec#L126 | 13:53 |
| zyga | mborzecki: yes, but it could be enabled now | 13:54 |
| mborzecki | let's try it :) | 13:54 |
| jdstrand | zyga: before committing https://github.com/snapcore/snapd/pull/4827, we should talk to jjohansen | 13:54 |
| mup | PR #4827: cmd/snap-apparmor-parser: add a prototype apparmor parser <Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4827> | 13:54 |
| zyga | jdstrand: it's closed, we're not going to commit that AFAIK | 13:54 |
| mvo | mborzecki: I'm with you in the hunt for the snap-confine.XXXX leftover profiles now | 14:00 |
| mvo | mborzecki: as this blocks my PR too | 14:00 |
| jdstrand | mvo, zyga: is the cache drama from last week resolved due to removing the system key OR? | 14:01 |
| jdstrand | PR? | 14:01 |
| zyga | jdstrand: yes, it's the system key | 14:01 |
| * jdstrand is trying to wade through the discussion and the various PRs | 14:02 | |
| zyga | we change things that end up in system key behind snapd's back | 14:02 |
| zyga | (we repackage core) | 14:02 |
| zyga | so revision was not sufficient | 14:02 |
| jdstrand | right | 14:02 |
| zyga | and we simply remove the system key as a workaround (this only affects test) | 14:02 |
| jdstrand | https://github.com/snapcore/snapd/pull/4842 is still open btw (and out of date) | 14:02 |
| mup | PR #4842: interfaces: make hash of apparmor profile for snap-confine in core part of the system-key <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4842> | 14:02 |
| zyga | jdstrand: I think that was another RFC | 14:03 |
| mvo | jdstrand: it is resolved in the sense that things work now and we also have an idea how we could make it more robust (by adding a hash of the current snap-confine profile from core into the system-key). but I think there is a bug lurking there somewhere in the apparmor cache handling still :/ | 14:03 |
| zyga | the one that we decided on was merged | 14:03 |
| mvo | jdstrand: unfortunately I don't have much better feedback than: "it does not work" :/ sorry for that | 14:04 |
| jdstrand | mvo: if you figure it when 'it does not work', please file a bug and me or jjohansen can take a look at it | 14:04 |
| jdstrand | mvo: there is a lot going on between apparmor cache, system key, ensure dir, reexec, etc | 14:05 |
| pedronis | #4873 is the delay classic reg PR | 14:05 |
| mup | PR #4873: many: delay classic registration until first store interaction <Created by pedronis> <https://github.com/snapcore/snapd/pull/4873> | 14:05 |
| mborzecki | mvo: any idea where this could be coming from? the code in intefaces/apparmor does not seem to be doing anything wrong | 14:08 |
| mup | PR snapd#4842 closed: interfaces: make hash of apparmor profile for snap-confine in core part of the system-key <Blocked> <Created by mvo5> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/4842> | 14:12 |
| mup | PR snapd#4781 closed: wrappers: refactor desktop file sanitizer to support autostart files <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4781> | 14:14 |
| mup | PR snapd#4882 opened: snap: make `snap run` look at the system-key for security profiles <Created by mvo5> <https://github.com/snapcore/snapd/pull/4882> | 14:17 |
| mvo | mborzecki: yeah, its confusing. it just uses EnsureDirState() and that uses AtomicWrite and defer .Cancel() | 14:17 |
| zyga | mvo: ha, interesting | 14:20 |
| mborzecki | mvo: when core is refreshed, when does snapd restart to reexec into the new one? | 14:23 |
| mvo | mborzecki: thats slightly complicated, iirc in overlord/snapstate and in the link-snap handler there | 14:25 |
| zyga | mvo: I need to take a break | 14:25 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| mup | PR snapd#4883 opened: debian: undo snap.mount system unit removal <Created by mvo5> <https://github.com/snapcore/snapd/pull/4883> | 14:29 |
| mup | PR snapd#4884 opened: debian: run snap.mount upgrade fixup *before* debhelper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4884> | 14:32 |
| === dgadomski_ is now known as dgadomski | ||
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| niemeyer | zyga: Didn't we have a snap for gcloud or something? | 14:42 |
| niemeyer | cachio: ^ | 14:42 |
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| cachio | zyga, mmm, I think zyga created it | 14:44 |
| popey | We're working on that. | 14:44 |
| cachio | niemeyer, I have the google clud sdk snap that zyga created | 14:44 |
| niemeyer | cachio: What's the snap name? | 14:45 |
| cachio | niemeyer, it is not in the store | 14:45 |
| niemeyer | I see | 14:45 |
| cachio | niemeyer, he copied the snap in a usb | 14:45 |
| niemeyer | Is it super secret? :) | 14:46 |
| popey | No, but don't put it in the store please. | 14:46 |
| cachio | niemeyer, I don't think so | 14:46 |
| cachio | niemeyer, should we upload it to the store? | 14:46 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| cachio | niemeyer, zyga is it ok if we move the tests execution from opensuse 42.2 to 42.3 for each PR? | 14:51 |
| morphis | mvo: I am currently seeing problems with snap removal in LXD containers, is that a thing which was meant to work? | 14:51 |
| zyga | Yes, i think so | 14:51 |
| morphis | mvo: it smells like snapd tries to unmount the snap via mount where `fusermount -u` would be right | 14:52 |
| zyga | It is s point update | 14:52 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| zyga | Morphis: we don’t unmount | 14:52 |
| zyga | It is done by systemd | 14:53 |
| morphis | zyga: someone does it, however a `snap remove ..` hangs forever | 14:53 |
| zyga | I think the fix was not released yet | 14:54 |
| zyga | You need 2.32 den | 14:54 |
| morphis | zyga: ++ snap remove lxd | 14:54 |
| morphis | 2018-03-20T14:41:12Z ERROR cannot remove snap file "lxd", will retry in 3 mins: [stop snap-lxd-6162.mount] failed with exit status 1: Job for snap-lxd-6162.mount failed. See "systemctl status snap-lxd-6162.mount" and "journalctl -xe" for details. | 14:54 |
| morphis | that is what I get | 14:55 |
| morphis | zyga: is this https://bugs.launchpad.net/snapd/+bug/1712930 ? | 14:56 |
| mup | Bug #1712930: snap-confine: mounts happen in the wrong order <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1712930> | 14:56 |
| zyga | Yes | 14:58 |
| morphis | so 2.31 should have the fix, right? | 14:59 |
| mvo | kenvandine: https://forum.snapcraft.io/t/the-content-interface/1074 has the correct description for the content interface. where did you see the incorrect description? asking so that we can get this fixed :) | 15:05 |
| morphis | zyga: so is there already a timeline for when 2.31 gets SRUed into xenial or should this be fixed (without a reboot) with just a new core snap? | 15:08 |
| kenvandine | mvo, https://docs.snapcraft.io/reference/interfaces | 15:09 |
| kenvandine | mvo, it says "default-provider (plug): name and slot of preferred providing snap (<SNAP>:<SLOT>)" | 15:09 |
| mvo | thanks kenvandine | 15:09 |
| kenvandine | mvo, so that means all of our GNOME snaps are wrong :( | 15:10 |
| mvo | kenvandine: well, I need to talk to niemeyer but we could simply support you by adding coding to split on the ":" and just throw that part away | 15:10 |
| kenvandine | mvo, which are the official docs? the forum or docs.snapcraft.io? | 15:10 |
| zyga | morphis: for this bug we need 3.32 and I don’t know about timelines | 15:11 |
| mborzecki | off to prep lunch for the kids | 15:11 |
| morphis | zyga: you mean a new deb or a new core snap with 2.32? | 15:11 |
| zyga | New deb | 15:11 |
| zyga | Then the container inside can work | 15:12 |
| zyga | I mean then snapd inside the container can work | 15:12 |
| mvo | kenvandine: well, there is a bit of a debate about this but the forum docs tend to be more up-to-date and more accurate | 15:13 |
| morphis | zyga: ok, sounds like this is long away with the deb of snapd being still at 2.29 in xenial | 15:13 |
| === chihchun is now known as chihchun_afk | ||
| zyga | Oh | 15:14 |
| kenvandine | mvo, hmmm... ok, we need to kill docs.snapcraft.io then | 15:14 |
| zyga | Good point | 15:14 |
| * zyga needs to stop sitting for back pain to go away | 15:14 | |
| mvo | kenvandine: this is a ongoing discussion how to best deal with the docs, niemeyer is leading this discussion | 15:15 |
| mvo | davidcalle: what is the best way to ask for a small fix onhttps://docs.snapcraft.io/reference/interfaces ? we need to tweak the "default-provider" line so that it says that the default provider is just a snap name | 15:16 |
| mvo | mborzecki: when I tried to reproduce the snap-confine "ERROR: Conflicting profiles for /snap/core/4278/usr/lib/snapd/snap-confine^mount-namespace-capture-helper defined in two files:" in qemu (run in isolation) this did not work - did you managed to reproduce it? | 15:19 |
| davidcalle | mvo, hey, I'm not handling this anymore, but I'd say a PR on https://github.com/canonical-docs/snappy-docs/blob/master/reference/interfaces.md | 15:20 |
| mup | PR snapd#4885 opened: Specify charset in po/snappy.pot <Created by gunnarhj> <https://github.com/snapcore/snapd/pull/4885> | 15:24 |
| mborzecki | mvo: yes, i reproduced it twice using #4875 | 15:26 |
| mup | PR #4875: cmd/snap-confine: fix ptrace rule with snap-confine peer <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4875> | 15:26 |
| mborzecki | but didn't happen on the 3rd run when i had more ideas what to check :/ | 15:27 |
| nacc | niemeyer: there's some mention of the core snap and vlc in LP: #1756380 about the vaapi driver used by vlc | 15:34 |
| mup | Bug #1756380: vaapi VP9 hardware decoding not working anymore in bionic <intel-vaapi-driver (Ubuntu):Fix Released> <libva (Ubuntu):Invalid> <https://launchpad.net/bugs/1756380> | 15:34 |
| nacc | niemeyer: dunno if you can help confirm it, that user was a bit problematic on irc | 15:34 |
| niemeyer | mvo, kenvandine: We have a agreement to go ahead and replace docs.snapcraft.io to documentation based on the forum, resembling snapdocs.labix.org | 15:39 |
| niemeyer | nacc: I don't know details about that one, but I see a message in the bug itself saying it has been fixed elsewhere | 15:41 |
| nacc | niemeyer: yeah, i just wasn't sure if the user was full of it :) | 15:41 |
| niemeyer | davidcalle,mvo,kenvandine: We need to finish moving (and polishing on the way) this content over to the forum.. I'm hoping to come back to it once 18.04 and the review queue is a bit more under control | 15:43 |
| kenvandine | niemeyer, thx | 15:43 |
| kenvandine | snapdocs looks nice | 15:43 |
| niemeyer | mvo: About the splitting of default-provider, I think we had agreed to do that before in conversations.. we just forgot to come back into it | 15:46 |
| niemeyer | mvo: The issue was precisely one of practical consequences of people using it already more than it being technically important | 15:47 |
| niemeyer | I didn't realize it was in docs | 15:47 |
| niemeyer | That explains why people use it.. I thought it was just a copy & paste from terminal | 15:47 |
| niemeyer | kenvandine: There's a lot to do still, but it's slowly getting into shape | 15:50 |
| zyga | jdstrand: hey, this is the bugfix for the case when snapd would write to /etc directly (without a mimic) https://github.com/snapcore/snapd/compare/master...zyga:fix/trespassing?expand=1 | 15:54 |
| zyga | I'll propose a merge soon but I want to do a clean run first | 15:55 |
| cyphermox | ogra_: did you have a chance to verify https://bugs.launchpad.net/netplan/+bug/1741910 ? | 15:55 |
| mup | Bug #1741910: ath6kl_sdio does not support unbinding <verification-needed-xenial> <netplan:Fix Committed by cyphermox> <nplan (Ubuntu):Fix Released> <nplan (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1741910> | 15:55 |
| zyga | I need to lay down for now | 15:58 |
| zyga | mvo: ^ that is (fingers crossed) my last thing for 2.32 | 15:58 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/4882#pullrequestreview-105420120 | 16:07 |
| mup | PR #4882: snap: make `snap run` look at the system-key for security profiles <Created by mvo5> <https://github.com/snapcore/snapd/pull/4882> | 16:07 |
| mvo | niemeyer: thanks, I will work on the splitting for content provider (cc kenvandine) | 16:08 |
| kenvandine | mvo, thx | 16:08 |
| mvo | zyga: I think its not only for reboot, on classic if snapd got updated and you restart the daemon its the same problem, no? | 16:11 |
| niemeyer | mvo: Thank you! | 16:11 |
| mvo | zyga: I mean, system-key may change even without a reboot | 16:11 |
| zyga | mvo: no because in such case snapd will regenerate the profile on core snap refresh | 16:11 |
| zyga | mvo: so before we are in the new core the profiles will be ready | 16:12 |
| zyga | mvo: this IMO strictly for core | 16:12 |
| zyga | mvo: on classic restarting snapd will complete without system reboot and the phase 2 profile generation handles that part | 16:12 |
| zyga | mvo: and then the profiles are ready and we proceed to activating the core snap revision | 16:12 |
| mvo | zyga: there is still a race here on phase 2, no? I mean, snapd gets refreshed, for some reason network-manager is restarted during that time, won't that be the same as in the reboot scenario? | 16:15 |
| zyga | mvo: that depends on one thing: if the new core is active and has the updated current symlink | 16:15 |
| zyga | if we do that after security (and AFAIR we do) | 16:15 |
| zyga | then it's not racy | 16:15 |
| zyga | jdstrand: hey, not urgent as we have thick smoke and some fires now but please enqueue this: https://github.com/snapcore/snapd/pull/4868 | 16:18 |
| mup | PR #4868: [WIP] secure bind mount implementation for use with user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868> | 16:18 |
| zyga | jdstrand: jamesh wrote an interation of the secure mount idea | 16:18 |
| mup | PR snapd#4886 opened: tests: adding opensuse-42.3 to google <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4886> | 16:27 |
| pedronis | zyga: mvo: phase2 security setup is after link-snap (it cannot be before by necessity) | 16:31 |
| zyga | pedronis: hmm, could we do that after we mount but before we rewrite current? | 16:32 |
| pedronis | we can do a lot of stuff | 16:32 |
| mborzecki | wow, snap apps really core dump on arch with nvidia drivers | 16:32 |
| pedronis | but is not trivial with the current task definition | 16:32 |
| pedronis | s | 16:32 |
| pedronis | it does phase1: setup-profiles link-snap restarts phase2: setup-profiles again | 16:33 |
| Chipaca | niemeyer: given my comment about the things doing print via io.Writer in cmd/snap, ok to merge #4858? | 16:34 |
| mup | PR #4858: strutil, cmd/snap: drop strutil.WordWrap, first pass at replacement <Created by chipaca> <https://github.com/snapcore/snapd/pull/4858> | 16:34 |
| niemeyer | Chipaca: Looking | 16:34 |
| mvo | cachio: is there anything atypical about the google machines? any strange mount options or filesystem layouts? I ask because we see strange failures in the snap-confine test | 16:34 |
| niemeyer | Chipaca: If we have other bad patterns, we should change them indeed, but let's please not add more of them | 16:35 |
| zyga | mvo: do you have an example? | 16:35 |
| niemeyer | Chipaca: Your PR doesn't need to fix all, though | 16:35 |
| niemeyer | Chipaca: It's trivial to do that by just making the type concrete | 16:35 |
| niemeyer | Chipaca: If it's memory, that is | 16:35 |
| * Chipaca changes it all to *os.File | 16:35 | |
| Chipaca | :-D | 16:35 |
| niemeyer | Chipaca: Yeah, that's the point ;) | 16:36 |
| mvo | zyga, cachio these errors http://paste.ubuntu.com/p/DNWCbQRDqs/ | 16:36 |
| zyga | ah, those | 16:36 |
| Chipaca | niemeyer: do you also expect the code to check the returned error? | 16:36 |
| * zyga keeps trying to reproduce those | 16:36 | |
| niemeyer | Chipaca: Not if it's bytes.Buffer | 16:36 |
| Chipaca | niemeyer: when it's an io.Writer | 16:36 |
| niemeyer | Chipaca: Passing those around with no error checking is fine | 16:36 |
| cachio | mvo, where did you see that? | 16:36 |
| niemeyer | Chipaca: If it's io.Writer, something is necessarily broken.. the single point of io.Writer is to allow any io.Writer, but we cannot do that and ignore errors without it being a bug | 16:37 |
| Chipaca | niemeyer: we fmt.Fprintf all over the place without checking error returns | 16:37 |
| Chipaca | niemeyer: are you saying we need to check every error returned from fmt.Fprint? | 16:38 |
| niemeyer | Chipaca: That's okay when you are the call site, and you know that it's okay to ignore the error | 16:38 |
| Chipaca | ah | 16:38 |
| niemeyer | Chipaca: It's not okay when that's inside a function that has no context about what the io.Writer is | 16:38 |
| Chipaca | niemeyer: ok, i think i understood | 16:38 |
| Chipaca | I guess I'll get to do the fix sometime later this week then | 16:39 |
| niemeyer | Chipaca: The cheapest fix for this particular case would be simply to make the type concrete | 16:39 |
| niemeyer | Chipaca: Since it's really all in memory AFAICS | 16:39 |
| mup | PR snapcraft#2012 opened: pluginhandler: only do elf checking and patching for type app <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2012> | 16:40 |
| Chipaca | niemeyer: you mean because it's going into a tabwriter? | 16:41 |
| niemeyer | Chipaca: Is that the io.Writer? If so, my point is moot.. | 16:42 |
| Chipaca | right now it is, but it could just be the terminal | 16:42 |
| niemeyer | Chipaca: In that case the easiest would be to just return the error from these functions.. and let the call site decide to ignore it or not | 16:42 |
| Chipaca | (the description cuts the tabbing anyway) | 16:43 |
| Chipaca | niemeyer: k | 16:43 |
| Chipaca | niemeyer: pedronis: also note i addressed the issues in #4790 | 16:45 |
| mup | PR #4790: jsonutil/puritan: introducing puritan.String & etc <Created by chipaca> <https://github.com/snapcore/snapd/pull/4790> | 16:45 |
| * Chipaca goes back to snapshots | 16:45 | |
| mup | PR snapcraft#2013 opened: tests: run tests on Trusty on Travis <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2013> | 16:46 |
| mup | PR snapd#4887 opened: snapstate: add compat mode for default-provider <Created by mvo5> <https://github.com/snapcore/snapd/pull/4887> | 16:50 |
| mvo | niemeyer: -^ (cc kenvandine ) | 16:51 |
| mvo | niemeyer: and thank you for your input on this! | 16:51 |
| zyga | mvo: question about this pr | 16:52 |
| zyga | will this be any problem on reverts? | 16:52 |
| zyga | or is the :ifname part totally irrelevant and was never used | 16:52 |
| niemeyer | Chipaca: Thanks, approved, with a note | 16:53 |
| jdstrand | zyga: ack (i was already there) | 16:54 |
| niemeyer | mvo: Thanks! | 16:55 |
| niemeyer | mvo: LGTM | 16:55 |
| niemeyer | zyga: Yes, it's irrelevant | 16:55 |
| zyga | ack, +1 then | 16:55 |
| niemeyer | We may actually use this some day, but not today | 16:55 |
| jdstrand | s/i/it/ | 16:55 |
| niemeyer | zyga: The only reasonable thing to have there is the actual slot of the default provider.. if people put random content it may eventually stop working indeed | 16:56 |
| niemeyer | but not a problem we need to worry about today | 16:56 |
| mborzecki | hm glxinfo from inside the snap segfaults too | 16:57 |
| Chipaca | zyga: did you say we had an implenetation of OpenAt already? | 16:57 |
| zyga | Chipaca: we have something that's very similar in secureMkPrefix | 16:57 |
| Chipaca | zyga: ah, ok, then I'll leave it for later | 16:58 |
| mborzecki | anyone intimately familiar with glvnd? | 17:00 |
| zyga | not intimately | 17:02 |
| zyga | but I read the source of it once | 17:02 |
| zyga | but ask in #ubuntu-desktop maybe | 17:02 |
| zyga | and ask around upstream | 17:03 |
| mborzecki | zyga: i'm looking into why snaps segfault on arch with nvidia, apparently even glxinfo segfaults, bt points to glvnd: https://forum.snapcraft.io/t/nvidia-proprietary-driver-no-h-w-acceleration-in-chromium-and-firefox-stack-mashing-problem-also/4532/8 | 17:03 |
| mvo | a review for 4874 would be great, should be easy | 17:03 |
| mup | PR snapd#4843 closed: interfaces/builtin: let MM change qmi device attributes <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4843> | 17:03 |
| zyga | mborzecki: did you manage to get a backtrace? | 17:03 |
| zyga | mvo: doing that now | 17:04 |
| mup | PR snapd#4876 closed: packaging: recommend "gnupg" instead of "gnupg1 | gnupg" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4876> | 17:04 |
| zyga | mvo: I tweaked spread.yaml to break if there's a snap-confine profile with some garbage in the filename | 17:04 |
| zyga | and I'm running this in a main/ loop | 17:04 |
| mup | PR snapd#4883 closed: debian: undo snap.mount system unit removal <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4883> | 17:05 |
| mvo | zyga: ta | 17:05 |
| pstolowski | mvo: the sanitize changes are more annoying than I thought (due to the tests)... i'm almost there | 17:07 |
| mvo | pstolowski: yeah, I feared it might be. thanks for pushing it through | 17:07 |
| pstolowski | mvo: amazing for 1 line fix :D | 17:07 |
| mup | PR snapd#4888 opened: snap-confine: fallback to /lib/udev/snappy-app-dev if the core is older <Created by mvo5> <https://github.com/snapcore/snapd/pull/4888> | 17:07 |
| * kalikiana wrapping up for today | 17:10 | |
| zyga | mvo: let's keep (2.23) in the PR name if we can, some things will get confusing very quickly | 17:11 |
| mborzecki | zyga: temporarily disabled aslr, bt https://paste.ubuntu.com/p/TwRRRVZHYs/ strace https://paste.ubuntu.com/p/QdsZHM2rnz/ | 17:12 |
| zyga | mborzecki: can you list all the files in the nvidia and libglvnd files | 17:16 |
| zyga | er | 17:16 |
| zyga | packages | 17:16 |
| zyga | and compare that to what is visible in /var/lib/snapd/lib/gl | 17:16 |
| zyga | (as symlinks) | 17:16 |
| mup | PR snapd#4874 closed: tests: a bunch of test fixes for s390x from looking at the autopkgtest logs <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4874> | 17:16 |
| zyga | mborzecki: is it possible that libglvnd is compiled with newer libc than the snap | 17:17 |
| zyga | and that causes the incompatibility? | 17:17 |
| zyga | I long suspect this will bite us | 17:17 |
| zyga | and that we need to ship libglvnd and all the other userspace drivers in separate overlay/content snaps | 17:17 |
| mborzecki | zyga: well, it's possible, it's symlinked from hostfs atm | 17:17 |
| mvo | zyga: +1 | 17:17 |
| mvo | pstolowski: heh, indeed | 17:17 |
| zyga | yes, I know it is :( | 17:17 |
| zyga | mborzecki as a hack: | 17:18 |
| zyga | mborzecki: grab xenial chroot | 17:18 |
| zyga | compile libglvd | 17:18 |
| zyga | and drop it into that namespace instead of those symlinks | 17:18 |
| zyga | just libgldv | 17:18 |
| zyga | the only parts of userspace from hostfs you can use are the binary driver from nvidia | 17:18 |
| zyga | all the other parts compile on xenial chroot | 17:19 |
| zyga | if that fixes the issue we will have our answer | 17:19 |
| Pharaoh_Atem | zyga: you guys know glvnd hasn't been working correctly with snapd forever now, right? | 17:19 |
| zyga | Pharaoh_Atem: ish, yes | 17:20 |
| mborzecki | Pharaoh_Atem: i didn't :P | 17:20 |
| Pharaoh_Atem | it's been an issue in Fedora for a while | 17:20 |
| zyga | it has been working in the past to some extent | 17:20 |
| Pharaoh_Atem | it only works with Mesa drivers | 17:20 |
| zyga | but it's a perpetual todo | 17:20 |
| Pharaoh_Atem | well, now that it's in Ubuntu 18.04, now hopefully it'll get fixed :P | 17:20 |
| zyga | Pharaoh_Atem: this reminds me of the run towards 16.04 | 17:21 |
| zyga | I don't miss that | 17:21 |
| Pharaoh_Atem | mborzecki: at one point or another, I've had reports on almost every single snapd update about it | 17:22 |
| Pharaoh_Atem | but there's nothing I could do about it as I have zero nvidia hardware to debug with | 17:22 |
| zyga | I suspect it may require non-trivial work | 17:23 |
| Pharaoh_Atem | no kidding | 17:25 |
| popey | zyga: can someone please triage bug 1756793 so it has the right assignment and priority? Otherwise it outwardly looks like we're not on top of it | 17:38 |
| mup | Bug #1756793: Can't run snaps on Ubuntu 18.04 <amd64> <apport-bug> <bionic> <package-from-proposed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1756793> | 17:38 |
| gQuigs | trying to snap sosreport - and stuck at it needing a file to exist: /etc/sos.conf. It needs to be a classic snap. Is there a way to have this file created? - https://github.com/sosreport/sos | 17:38 |
| zyga | popey: it's already fixed but we need new package out | 17:38 |
| zyga | popey: we debugged this earlier today | 17:39 |
| zyga | I'll update the bug report | 17:39 |
| popey | (this should also be on the bug) | 17:39 |
| zyga | done now, I was not aware of the bug report before | 17:39 |
| popey | I just rebooted on advice of the bug - closing down all my currently running apps - and now I've rebooted I have an unusable workstation - none of the snaps I use launch | 17:39 |
| zyga | popey: refresh to beta please | 17:41 |
| zyga | that's sufficient AFAIK | 17:41 |
| popey | zyga: that worked. might want to let people on the bug know that's a valid workaround until the package lands. | 17:44 |
| zyga | done | 17:45 |
| popey | Thanks | 17:45 |
| zyga | and I'm sorry, I did see this bug before | 17:45 |
| popey | I appreciate there's like 3 threads on the forum and a bug. | 17:46 |
| popey | Our direction from the top is to file and update bugs. So that's why I'm poking :) | 17:46 |
| mup | PR snapd#4889 opened: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889> | 17:49 |
| zyga | mvo: I pushed and opened the trespassing PR | 17:49 |
| zyga | and I need to leave now | 17:49 |
| Chipaca | pedronis: do you know if there's an easy way (and if it's sane) to add an already-done task to a taskset, just to have a place to Logf() ? | 17:49 |
| zyga | my laptop is looping through all of master | 17:49 |
| zyga | er main | 17:49 |
| zyga | hopefully something will come up | 17:49 |
| pedronis | Chipaca: ? | 17:50 |
| pedronis | I'm not sure I even parse the question | 17:50 |
| pedronis | Chipaca: what are you trying to do? | 17:52 |
| * pedronis needs to go have dinner | 17:53 | |
| niemeyer | Need to step out for a while.. will be back later today | 17:59 |
| mup | PR snapcraft#2014 opened: integration tests: snap tests shouldn't be arch-specific <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2014> | 18:32 |
| Chipaca | pedronis: sorry, was preparing dinner myself =) | 18:33 |
| Chipaca | pedronis: my issue is that I have a list of non-fatal errors produced at the start of any of the exported snapshotstate taskset-returning public functions | 18:34 |
| Chipaca | and I thought I could log them | 18:34 |
| Chipaca | there, against the task | 18:34 |
| Chipaca | or I could return them all the way out to daemon and up | 18:34 |
| Chipaca | the latter might be easier, as it's a rather unique case, hm | 18:35 |
| pedronis | Chipaca: you can return both a taskset and a error | 18:35 |
| pedronis | if the caller can deal | 18:35 |
| Chipaca | yeah | 18:35 |
| pedronis | logging them on the task is weird | 18:36 |
| Chipaca | they're just informative so yeah | 18:36 |
| Chipaca | pedronis: go have dinner :-) thanks | 18:36 |
| pedronis | I'm back | 18:36 |
| Chipaca | ah! ok | 18:36 |
| Chipaca | it'll be a map[string]error, but, yeah | 18:36 |
| Chipaca | it's not an error in doing the thing, it's an error in listing the snapshots | 18:36 |
| Chipaca | which i was previously ignoring but at the sprint we decided to talk about | 18:37 |
| Chipaca | i mean, to alert the user about | 18:37 |
| mvo | zyga: thank oyu | 18:38 |
| mvo | zyga: once bionic is happy again I will look | 18:38 |
| mup | PR snapd#4887 closed: snapstate: add compat mode for default-provider <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4887> | 18:40 |
| mup | PR snapd#4888 closed: snap-confine: fallback to /lib/udev/snappy-app-dev if the core is older (2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4888> | 18:40 |
| mup | PR snapcraft#2015 opened: docs: add execstack to HACKING.md's list of deb deps <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2015> | 18:44 |
| mup | PR snapcraft#2015 closed: docs: add execstack to HACKING.md's list of deb deps <docs> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2015> | 18:47 |
| mup | PR snapcraft#2016 opened: demos: use realpath in command entry for java-hello-world <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2016> | 18:50 |
| kyrofa | Hey stgraber, I'm kind of pushing the limits here, but I installed lxd on my rpi2 with Ubuntu Core on it, but can't get snaps to mount within a container, even with squashfuse installed. Any chance you've tried snaps in LXD on armhf? | 19:29 |
| mup | PR snapcraft#2012 closed: pluginhandler: only do elf checking and patching for type app <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2012> | 19:29 |
| stgraber | kyrofa: what kernel are you using? | 19:29 |
| kyrofa | stgraber, 4.4.0-1030-raspi2 | 19:30 |
| stgraber | is that an official ubuntu kernel? if not, you won't have unpriv fuse as that's not upstream | 19:30 |
| kyrofa | stgraber, I assume so, it's our reference Ubuntu Core image for the rpi | 19:31 |
| stgraber | kyrofa: cat /sys/module/fuse/parameters/userns_mounts | 19:31 |
| kyrofa | stgraber, N | 19:31 |
| stgraber | try echo "Y" into it | 19:31 |
| mvo | niemeyer: your opinion on 4882 would be great | 19:32 |
| stgraber | should be Y by default on Ubuntu kernels though... it is on my 4.4.0-116-generic here (armhf) | 19:32 |
| mup | PR snapcraft#2017 opened: many: optimize retrieval of the linker version <bug> <enhancement> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2017> | 19:32 |
| kyrofa | stgraber, ha! Works | 19:32 |
| kyrofa | Think that's a bug, then? | 19:32 |
| stgraber | well, I don't know, that setting was changed a while back | 19:33 |
| stgraber | and you're running a super outdated kernel | 19:33 |
| stgraber | current 4.4.0 for raspi2 is -1085 | 19:33 |
| stgraber | and you've got -1030 so you're months if not over a year out of date | 19:33 |
| kyrofa | ppisati, any chance you're around? | 19:34 |
| kyrofa | Probably not. stgraber I'll chase that one down, thanks for your help :) | 19:35 |
| stgraber | kyrofa: your kernel dates back from Nov 2016 :) | 19:36 |
| stgraber | kyrofa: so yeah, don't run that | 19:36 |
| jdstrand | kyrofa: what is snapcraft-pr? | 19:43 |
| jdstrand | kyrofa: and hi! :) | 19:43 |
| kyrofa | jdstrand, hey! snapcraft-pr is essentially a set of shell scripts that sets up a venv for a given snapcraft pull request and then runs that snapcraft. Basically, it's me automating what I have to do several times a day | 19:46 |
| jdstrand | kyrofa: is it useful for more than just you? you've requested classic confinement... perhaps request it formally? | 19:46 |
| kyrofa | jdstrand, maybe, but it's pretty developer-focused. Ideally build.snapcraft.io would just build snaps of each PR, which would probably make this tool unnecessary | 19:50 |
| jdstrand | kyrofa: I'm not sure how to proceed with that... I have a process I'm supposed to follow. I mean, technically I can add it, but based on this, it seems like a discussion in the forum might prompt improvements that make the snap unnecessary | 19:55 |
| kyrofa | jdstrand, follow your process, you can reject it without incurring my wrath | 19:59 |
| === pstolowski is now known as pstolowski|afk | ||
| mup | PR snapd#4890 opened: snap: Call SanitizePlugsSlots from InfoFromSnapYaml <Created by stolowski> <https://github.com/snapcore/snapd/pull/4890> | 20:26 |
| pstolowski|afk | mvo: ^ | 20:26 |
| zyga | re | 20:28 |
| zyga | I got /usr/lib/go-1.6/pkg/tool/linux_amd64/link: running gcc failed: fork/exec /usr/bin/gcc: cannot allocate memory | 20:28 |
| zyga | that's fun but unexpected | 20:29 |
| zyga | restarted loop | 20:29 |
| cwayne | mvo: hi, so should we be on the lookout for a new core in beta soonish then? | 20:35 |
| Saviq | cachio: hey, did you guys do something to spread so that it started launching i686 images on google? | 20:38 |
| Saviq | how can I request amd64 ones? | 20:38 |
| Saviq | cachio: https://travis-ci.org/MirServer/mir/jobs/356038699 | 20:39 |
| vidal72[m] | on beta/edge core snap channel every app tries to read /proc/sys/kernel/seccomp/actions_avail on startup which is blocked by apparmor. Is it known issue? | 20:40 |
| vidal72[m] | another thing: is it possible to permanently unplug snap form slot? After update everything is coming back to defaults | 20:58 |
| zyga | vidal72[m]: hey, yes' that is a known issue | 21:02 |
| zyga | vidal72[m]: I was planning on fixing it | 21:02 |
| zyga | vidal72[m]: but if you want to take a bite at the code, look at release/seccomp.go | 21:02 |
| zyga | vidal72[m]: and make the initialization there lazy (on first real use) | 21:02 |
| zyga | vidal72[m]: that will fix the issue | 21:02 |
| zyga | vidal72[m]: the auto-reconnect bug is fixed in edge now (and in master) | 21:03 |
| zyga | vidal72[m]: I believe pstolowski|afk can tell you more about that tomorrow | 21:03 |
| zyga | vidal72[m]: but if you build snapd from git you should no longer see that behavior | 21:03 |
| zyga | cachio: some tests are leaking "snap userd" processes | 21:04 |
| zyga | and those pile up in -reuse VMs | 21:04 |
| zyga | also plenty of dbus-daemon | 21:04 |
| zyga | specifically plenty of usr/bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session | 21:05 |
| vidal72[m] | so snapd-git and core --edge are both needed? | 21:05 |
| mup | PR snapcraft#2014 closed: integration tests: snap tests shouldn't be arch-specific <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2014> | 21:06 |
| zyga | vidal72[m]: technically no, it depends if reexec is enabled | 21:06 |
| zyga | vidal72[m]: on some distributions, for instance on debian stable, snapd in the package re-exec itself from the core snap | 21:07 |
| zyga | vidal72[m]: this is not yet avialable everywhere as some strings are attached | 21:07 |
| zyga | vidal72[m]: and on arch for instance it is disabled | 21:07 |
| zyga | vidal72[m]: (in general the snapd build in the core snap must be compatible with the distribution and we still have a few compile-time choices in the C code) | 21:07 |
| zyga | vidal72[m]: if you take snapd from git you should be ok | 21:07 |
| * zyga restarted his test loop and resumes being mostly AFK | 21:08 | |
| mup | PR snapd#4816 closed: tests: move xenial i386 to google backend <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4816> | 21:11 |
| cachio | Saviq, you should call it like we do https://github.com/snapcore/snapd/blob/master/spread.yaml#L54 | 21:13 |
| cachio | Saviq, take a look to that file, we are configuring the machines for google there | 21:14 |
| cachio | zygan which testS? | 21:14 |
| cachio | zyga, which testS? | 21:14 |
| Saviq | cachio: ack | 21:15 |
| cachio | Saviq, fedora should be working now with the new spread | 21:16 |
| Saviq | cachio: do I need to ask for a drive size or does it default to a bigger one? | 21:16 |
| cachio | Saviq, the default is 10 gb | 21:16 |
| cachio | as it was in linode | 21:17 |
| Saviq | ack | 21:19 |
| * cachio afk | 21:21 | |
| pedronis | zyga: do we have a list of directories that are prohibited in layouts? I thought we planned to have one | 21:21 |
| zyga | pedronis: one sec | 21:28 |
| zyga | pedronis: https://github.com/snapcore/snapd/blob/master/snap/validate.go#L660 | 21:30 |
| zyga | pedronis: those places are off limits | 21:30 |
| zyga | pedronis: are you thinking about store-side validation? | 21:30 |
| pedronis | zyga: no, I'm thinking about your new branch and the tmpfs check | 21:30 |
| zyga | cachio: I don't know which test, I observed this by running all of main in a -reuse loop in qemu all day | 21:30 |
| pedronis | for example run is a tmpfs | 21:31 |
| zyga | pedronis: ah | 21:31 |
| pedronis | but is in the prohibited list | 21:31 |
| zyga | pedronis: yes, that's safe because it's disallowed there | 21:31 |
| zyga | pedronis: as I wrote in the comment it is not perfect, ideally we'd allow only mimics and well-known places (/tmp) | 21:31 |
| zyga | oh, I see real failures in that PR | 21:32 |
| zyga | drat, I need to look at that | 21:32 |
| vidal72[m] | zyga: I have core --edge and curent snapd-git. I did snap revert <app>, disconnected slot, snap refresh <app> and slot is connected again | 21:35 |
| zyga | hmmm | 21:35 |
| zyga | revert does some things that can cause this to go back | 21:35 |
| zyga | revert is really "I liked previs revision better" | 21:35 |
| zyga | if you install a snap | 21:36 |
| zyga | disconnect something | 21:36 |
| zyga | and then refresh (not revet) to another revision | 21:36 |
| zyga | it should not auto-connect | 21:36 |
| zyga | s/previs/previous/ | 21:36 |
| pedronis | zyga: I left a comment in the PR | 21:37 |
| zyga | thank you | 21:38 |
| vidal72[m] | zyga: I made changes after revert, not before and updated with refresh | 21:38 |
| zyga | hmm, in that case you want to talk to pstolowski|afk tomorrow | 21:39 |
| zyga | it smells like a bug | 21:39 |
| vidal72[m] | zyga: ok, thx | 21:40 |
| pedronis | zyga: the fix not to re-autoconnect is still up for review | 21:40 |
| pedronis | is not landed even | 21:40 |
| zyga | ohh | 21:40 |
| zyga | I see, I must have read it and assumed it is merged | 21:40 |
| zyga | vidal72[m]: ^ | 21:41 |
| zyga | vidal72[m]: you can perhaps review the code to learn more about how this works | 21:41 |
| zyga | vidal72[m]: https://github.com/snapcore/snapd/pull/4551 | 21:41 |
| mup | PR #4551: ifacestate: do not auto-connect manually disconnected interfaces <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4551> | 21:41 |
| vidal72[m] | zyga: pedronis ok, thx for info | 21:42 |
| vidal72[m] | zyga: when we talk about PR...as PR my was approved what happens next? | 21:44 |
| zyga | vidal72[m]: it will get merged | 21:45 |
| zyga | vidal72[m]: it's just that now we have a bit of a fire to put out | 21:45 |
| zyga | vidal72[m]: with bad bionic package and overdue release | 21:45 |
| zyga | vidal72[m]: and important bugs surfacing | 21:45 |
| zyga | all at the same time | 21:45 |
| vidal72[m] | zyga: ok, no pressure from me :) | 21:46 |
| pedronis | zyga: do we protect about trying to mount with layout to /var/lib/snapd/hostfs | 21:55 |
| pedronis | or below? | 21:55 |
| zyga | those things are mounted as slave so none of those matter | 21:55 |
| zyga | if you mount something there it won't show up in the host | 21:55 |
| zyga | still, I think it's something we could forbit explicitly | 21:58 |
| mup | PR snapcraft#2016 closed: demos: use realpath in command entry for java-hello-world <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2016> | 22:03 |
| mvo | pstolowski|afk: woah, thank you! that was a long day for you, appreciated | 22:07 |
| mvo | cwayne: new beta tomorrow, there is a bit of a discussion how to best fix this right now | 22:08 |
| cwayne | mvo: ack, thanks. no rush just wanted to make sure we werent holding you guys up | 22:09 |
| mvo | cwayne: heh, thank you! | 22:09 |
| === ikey is now known as ikey|zzz | ||
| niemeyer | cachio: ping | 22:20 |
| cachio | yes | 22:21 |
| cachio | niemeyer, the change is pushed | 22:22 |
| niemeyer | cachio: Thanks for that | 22:22 |
| cachio | and i386 is merged | 22:22 |
| niemeyer | cachio: The placeholder should remain as %q there | 22:22 |
| niemeyer | cachio: It's just the variable that needed changing | 22:22 |
| niemeyer | cachio: This is a parsing error.. %q tells us what exactly was being parsed | 22:22 |
| niemeyer | %s won't.. at least not clearly | 22:23 |
| cachio | niemeyer, ok, just 1 min | 22:23 |
| cachio | niemeyer, done | 22:24 |
| niemeyer | cachio: Thanks! | 22:25 |
| cachio | niemeyer, with this change debian-9 should be ready to be merged | 22:25 |
| niemeyer | cachio: I'm merging and releasing.. just a sec | 22:25 |
| cachio | niemeyer, sure | 22:25 |
| niemeyer | cachio: It's in, thank you! | 22:31 |
| niemeyer | cachio: Let me release it.. | 22:32 |
| cachio | niemeyer, great!!!! thanks for reviewing that | 22:32 |
| niemeyer | cachio: My pleasure, and thanks for the change. It's a nice tweak. | 22:32 |
| niemeyer | cachio: Travis release is up | 22:33 |
| cachio | niemeyer, great | 22:35 |
| cachio | niemeyer, re triggering jobs | 22:35 |
| niemeyer | cachio: Snap is up too, btw | 23:17 |
| vidal72[m] | is snapd in debian stretch usable? (2.21 version is quite dated) | 23:43 |
| mwhudson | jdstrand: ayt? | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!