[00:20] PR snapd#4869 closed: cmd/snap-update-ns: use x-snapd.{synthetic,needed-by} in practice [01:37] PR snapcraft#2010 opened: Release/2.40+18.04 === chihchun_afk is now known as chihchun [06:12] morning [06:13] morning [06:37] PR snapd#4864 closed: daemon: support 'system' as nickname of the core snap [06:38] PR snapd#4841 closed: snap/pack, cmd/snap: add `snap pack --check-skeleton` [06:51] good morning [06:52] quick breakfast and brb [06:52] any of you fellows use a intel gpu? [06:54] phoenix_firebrd: probably most of us [06:58] 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? [07:01] yes, sure [07:02] can you give me an example URL? === chihchun is now known as chihchun_afk [07:07] zyga: any youtube video is fine [07:07] any? [07:07] aren't they encoded in different formats [07:07] zyga: as far as i know all the youtube videos are displayed using vp9/webm format in the latest browsers by default [07:08] I mean, I'd love to help but I want to make the test meaningful [07:08] hey zyga ! good morning [07:08] hey :-) [07:08] zyga: do you have youtube-dl [07:08] no, I don't believe I do [07:09] zyga: try this as an example https://www.youtube.com/watch?v=D6tC1pyrsTM [07:09] let me try to get a video and play it [07:10] 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:12] phoenix_firebrd: which channel of vlc do you want to tets [07:13] *test [07:13] zyga: normal [07:13] stable? ok [07:13] zyga: I think it contains vlc verion 3.0.1 [07:14] zyga: ok === chihchun_afk is now known as chihchun [07:19] phoenix_firebrd: I'll let you know once the download finishes [07:20] zyga: ok [07:33] mvo: what shall we do with 4765 [07:34] PR snapd#4874 opened: tests: a bunch of test fixes for s390x from looking at the autopkgtest logs [07:35] PR snapd#4872 closed: tests: add workaround for s390x failure [07:39] 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] looking [07:40] oh [07:40] no, looks like a bug [07:40] nice catch! [07:40] please tag the fix with 2.32 as well [07:40] ok [07:42] PR snapd#4863 closed: snap: don't create empty Change with "Hold" state on disconnect (2.32) [07:44] 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:46] zyga: #4875 [07:46] PR #4875: cmd/snap-confine: fix ptrace rule with snap-confine peer [07:46] PR snapd#4875 opened: cmd/snap-confine: fix ptrace rule with snap-confine peer [07:47] thank you === phoenix_firebrd is now known as phoenix_firebrd_ [07:48] mborzecki: approved [07:48] man, we will have a lot of back ports to do [07:48] hopefully those are single patch fixes :) [07:49] 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:52] phoenix_firebrd_: hey === phoenix_firebrd_ is now known as phoenix_firebrd [07:52] so I think it doesn't work [07:52] [00007f7608001ca0] glconv_vaapi_x11 gl error: vaInitialize: unknown libva error [07:52] libva info: VA-API version 0.39.0 [07:52] libva info: va_getDriverName() returns 1 [07:52] libva error: va_getDriverName() failed with operation failed,driver_name=i965 [07:52] [00007f7608001ca0] glconv_vaapi_drm gl error: vaInitialize: operation failed [07:53] this is on a i5 skylake chip [07:53] zyga: hi [07:53] the video plays but using significant amount of CPU === chihchun is now known as chihchun_afk [07:54] zyga: I think skylake supports hybrid decoding of vp9 [07:54] zyga: can you paste the profiles list? [07:54] what profiles? [07:54] zyga: the rest of the livainfo [07:54] zyga: vainfo i mean [07:54] one sec [07:55] https://www.irccloud.com/pastebin/ZuZnIbE4/ [07:55] note that this is vainfo outside of the snap [07:56] zyga: are you on 18.04? [07:56] yes [07:56] zyga: ah [07:56] zyga: https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1756380 [07:56] Bug #1756380: vaapi VP9 hardware decoding not working anymore in bionic [07:56] zyga: vp9 profiles are absent for supported hardware in 18.04 [07:57] phoenix_firebrd: but shouldn't this matter in snaps [07:57] is this a kernel side issue or a userspace issue [07:57] zyga: i mean just in case of the vainfo you gave from outside of snap [07:57] right [07:58] did you see the erros from libva I posted earlier [07:58] when starting up vlc [07:58] zyga: ya [07:59] zyga: is there a way to update the i965-va-driver package in snap to 2.1.0? [07:59] only by rebuilding the snap [07:59] mborzecki: ^ FYI, one of the things we could eventually support is pluggable va drivers === pstolowski|afk is now known as pstolowski [08:00] Mornings! [08:01] 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] I don't understand the issue so I cannot say [08:01] zyga: by driver i mean the one used in the snap core i guess === chihchun_afk is now known as chihchun [08:02] phoenix_firebrd: are you asking what is needed to stop shipping libva in a particular snap, like vlc? [08:03] 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] 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:04] phoenix_firebrd: I don't know anything about libva, I cannot help with that [08:04] phoenix_firebrd: perhaps vlc folks who make the snap can say more [08:04] I can help with snapd side of the problem [08:04] zyga: if you want to update the display drivers what snap will you update? core or vlc or both? [08:04] phoenix_firebrd: vlc [08:05] phoenix_firebrd: the core doesn't ship any [08:05] zyga: so you mean different media player snaps can ship with different version of drivers ? [08:05] not really drivers, drivers are in the kernel [08:05] of userspace libraries, yes [08:06] zyga: This list of packages used to compile a snap is called manifest right? [08:06] PR snapd#4876 opened: packaging: recommend "gnupg" instead of "gnupg1 | gnupg" [08:06] phoenix_firebrd: snap may be built entirely from source (except from the toolchain perhaps) so the word package is perhaps misleading [08:07] I don't know how vlc snap is built, for example, I didn't look at it that closely [08:07] 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:08] a quick look at vlc snap tells me they're building a lot from scratch at least, as they have Qt 5.10 [08:09] zyga: how I see what are the contents of the core snap [08:09] phoenix_firebrd: just look at it? it's usually mounted in /snap/core/current/ [08:10] but the intel driver they have is from 2016 [08:11] good morning [08:11] o/ Mirv [08:12] 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] kalikiana: o/ :) [08:14] zyga: by the looks of it, plain makefile stuff (even though I'm doing some templates inside) is way faster than autotools [08:14] the actual build part is comparable, the largest win is not running configure [08:15] mborzecki: yeah, that is very typical [08:16] 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:17] phoenix_firebrd: well, I told you that [08:17] phoenix_firebrd: run "snap info vlc" [08:17] and see the contact URL [08:20] zyga: ok, let me check [08:26] zyga: thank you so much for the support [08:26] thank you for using snaps :-) [08:35] Ok, I think I have a nice way to fix the bug with layouts leaking thing to the host [08:49] `ERROR: Conflicting profiles for /snap/core/4278/usr/lib/snapd/snap-confine^mount-namespace-capture-helper defined in two files:` this something new? [08:51] full log https://paste.ubuntu.com/p/xCzYR4Ztpv/ [08:52] is snapd 2.32+18.04~pre5 known to be broken? [08:52] after dist-upgrading today, all my snaps are marked broken [08:52] rebooting seems to "fix" them, but then they won't start === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [09:00] mborzecki: I saw that once yesterday [09:01] mborzecki: looks like atomic file write left some stuff behind [09:01] oSoMoN: yes [09:01] zyga, want me to file a bug report or start a thread on the forum to gather information on the issue? [09:02] zyga: just saw it in 4875, restarted the build to see if it's something random [09:09] 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:10] PR snapcraft#2011 opened: tests: run tests on Trusty on Travis [09:10] mwhudson: yes, I don't have particular opinions, is this something snapd needs to do or the installer could do? [09:10] pedronis: how could the installer do it? [09:10] i'm all for not changing snapd at this point of the cycle [09:11] mwhudson: move refresh.hold from 2h to 60 days ? [09:11] pedronis: oh just execute snap set core refresh.hold 60d? [09:11] well now+60d [09:11] but yes [09:12] would that be enough? [09:12] oh ok then that sounds easy :) [09:12] 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:13] to be precise you can set anywhere in the future [09:13] but after 60 days is not respecte [09:13] d [09:13] haha [09:13] pedronis: i had another awful hack in mind, which was to install core and subiquity unasserted [09:13] but this sounds better than that [09:14] pedronis: which version of snapd has refresh.hold support? [09:14] 2.32 [09:15] ok [09:15] and that's not in bionic because i uploaded go 1.10 but well [09:15] well our plan is to have in bionic in the images [09:15] oh no it is in bionic now [09:15] awesome [09:16] it has issues it seems though (but unrelated to this) [09:17] pedronis: thanks [09:17] * mwhudson goes to bed === phoenix_firebrd is now known as phoenix_firebrd_ [09:40] mwhudson: it is in bionic now [09:41] 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] hmm, why is connecting to interfaces so slow all of a sudden [09:42] Chipaca: I noticed this as well [09:42] ok, I'll dig [09:42] mvo: do we still not have auto-prereqs? [09:43] Chipaca: 2.32 should have them [09:44] 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] mvo: 2.32~pre4+git612.2003af8~ubuntu16.04.1 isn't working for me === phoenix_firebrd_ is now known as phoenix_firebrd [09:44] that is, "snap install evince" resulted in no gnome platform snap [09:44] in related news: does someone know why master is broken? it seems ~200 tasks are aborted [09:47] Chipaca: I look once the current fire is out [09:47] Chipaca: but I see the same here, slightly sad [09:47] mvo: k [09:48] kalikiana, hey, have you ever seen this snapcraft error when cross-compiling: https://paste.ubuntu.com/p/z4BW75yhXB/ ? (edge channel) [09:50] abeato: Hmm no I think that's new to me [09:50] abeato: Did this break recently? [09:51] kalikiana, well, it used to work last week [09:51] Also on edge? [09:52] yes [09:53] artful fyi [09:54] kalikiana, stable works [09:54] a regression in edge then [09:55] Yeah, looks like it :-/ === phoenix_firebrd is now known as phoenix_firebrd_ [09:55] abeato: Can you file a bug, please? [09:55] kalikiana, yup [09:58] PR snapd#4877 opened: snap-confine: fallback to /lib/udev/snappy-app-dev if the core is older [09:59] mvo: looking [09:59] kalikiana, https://bugs.launchpad.net/snapcraft/+bug/1757094 [09:59] Bug #1757094: snapcraft in edge channel (2.39.2+git46.c22d7e2) fails to cross-compile kernel [10:00] +1 :) [10:02] zyga: yay, thank you [10:02] zyga: now we just need to unbreak master [10:02] zyga: and *hopefully* the world is a happy place again [10:02] is master broken? [10:02] zyga: yeah, next PR comming that tests my theory on the why [10:02] oh, ok [10:03] PR snapd#4878 opened: tests: disable 18.04 spread tests in google for now [10:03] zyga: it looks like its a test problem with the google 18.04 [10:03] I didn't see any issues [10:03] but I'm still on an older branch from yesterday [10:03] zyga: no worries, only spread not our code [10:03] zyga: also - "make fmt" on bionic produces some different output than "make fmt" on older releases it seems [10:04] zyga: not a great morning so far, too many fires [10:04] yes [10:04] I noticed [10:04] this is why it's no longer enforced [10:04] when things quited down I will reindent with something saner [10:04] or see if I can coerce newer indent [10:12] abeato: Thanks! [10:13] abeato: Can you link the snap you're building there? [10:14] that might be tricky [10:15] (customer kernel) [10:16] kalikiana, that ^ [10:16] Hmm okay. [10:16] Chipaca: turns out the problem with evince is that there is on `content: ` line in the interface, I'm looking if we should use default here [10:21] mvo: we have code that sets defaults [10:21] but probably is not called for this case [10:21] bit fragile to duplicate it though [10:27] pedronis: yeah, I'm poking a bit to see if there is a nice way [10:30] mvo: i think oSoMoN and/or kalikiana could land a fix meanwhiles :-) [10:31] Chipaca: yeah, fix is trivial, just adding "content: " on both the evince plug and the gnome-3-26-1604 slot [10:33] mvo: ‘content: like a river’ [10:33] (http://www.azquotes.com/quote/1262712) [10:33] 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] (which would set the defaults) [10:34] I was remembering the old code, but in the new world this should happen somewhere in snap/ === phoenix_firebrd_ is now known as phoenix_firebrd [10:36] mvo: I finally have good progress on the (I named it) trespassing bug [10:36] I'll get a coffee and finish it soon [10:37] Chipaca: nice and poetic [10:37] pedronis: hm, that might be it [10:39] pedronis: it looks like nowday "interfaces.BeforePrpareSlot" must have been called [10:42] mmh [10:42] pedronis: interfaces.SanitizePlugsSlots calls this, so you are right I think, somewhere there is a sanitation missing [10:44] mvo: it's called by the ReadInfo* but not by just parsing [10:44] mvo: I think you added code to details.go in store that calls parsing of yaml but not that [10:45] pedronis: indeed, that sounds like the culprit [10:45] mvo: otoh it seems to be called only for installed snaps [10:46] atm [10:46] mvo: Chipaca: it's all a bit confusing: ReadInfoFromSnapFiles calls Validate bot not SanitizePlugsSlots and ReadInfo calls SanitizePlugsSlots but not Validate [10:47] pstolowski: ^ [10:47] what was the thinking there? [10:47] pedronis: yes just looking. seems to be my oversight in the refactoring :( [10:47] 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:48] I know why we don't validate already installed snaps [10:48] the assumption is that is done once [10:48] before [10:48] but SanitizePlugsSlots has side effects we always need [10:48] for values of always [10:50] pedronis: yeah, I wonder if nowdays it should be "annotatePlugsSlots" or something, its doing much more than to sanitize [10:53] PR snapcraft#2011 closed: tests: run tests on Trusty on Travis [10:53] 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:54] pstolowski: it calls BeforePrepareSlot for each interface [10:54] pstolowski: for the content interface this adds some defaults (like when content: is missing it adds an implicit "content: ") === phoenix_firebrd is now known as phoenix_firebrd_ === phoenix_firebrd_ is now known as phoenix_firebrd [10:56] 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] 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] pedronis: http://paste.ubuntu.com/p/2NjMYChFzR/ <- this might be what we need, i.e. run this always [10:57] 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] 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:58] pedronis: ReadInfo() would still get sanitization via infoFromSnapYamlWithSideInfo [10:59] 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] seems orthogonal right now [10:59] pedronis: orthogonal to what? === phoenix_firebrd is now known as phoenix_firebrd_ [11:00] sorry, I was answering my question: I mean the jobs Validate does and SanitizePlugsSlots do [11:00] they don't seem to depend on each other [11:00] (atm) [11:00] pedronis: yeah, validate is doing something else right now indeed [11:01] 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:02] 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] 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] mvo: ok [11:02] pstolowski: yeah, I think this invariant is currently not honored [11:03] mvo: right, my bad :( [11:03] pstolowski: when you create a snap.Info via InfoFromSnapYaml() [11:03] pstolowski: no worries [11:03] mvo: I can take this bug [11:03] 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:04] 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] pstolowski: (john discovered this bug). if you have any question, just let me know [11:05] * mvo goes back to unbreaking bionic [11:05] mvo: yes, that fix looks sensible as long as this is indeed the central (or only) place that needs this [11:06] mvo: ok, i'll work on this right away; is this some kind of a blocker atm? [11:06] pstolowski: its not terrible but nice to have [11:07] pstolowski: 2.32 will have the install of content providers so if we can unbug it, that would be great [11:07] 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:08] ack, will be aiming at that [11:08] thanks pstolowski ! [11:11] 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] mvo: sure, thanks for catching & sorry for the trouble /o\ [11:15] pstolowski: no worries [11:20] PR snapd#4878 closed: tests: disable 18.04 spread tests in google for now [11:21] PR snapd#4879 opened: tests: revert "tests: disable 18.04 spread tests in google for now" [11:26] 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:27] cachio: feel free to ignore armhf until the new autopkgtest roll out comes into place [11:27] sergiusens, nice, thanks [11:28] PR snapd#4880 opened: [RFC] cmd, data: plain make [11:28] zyga: plain make ^^ [11:28] oh,cool [11:28] mborzecki: queued for after standup === phoenix_firebrd_ is now known as phoenix_firebrd [11:38] mborzecki: nice speedup [11:39] mborzecki: hard to grasp how auto* is so inefficient, speed 6x [11:39] all the perl/sed/coreutils invocations add up [11:42] i'm looking into why #4875 fails, also #4871 failed in a way that's sort of similar [11:42] PR #4875: cmd/snap-confine: fix ptrace rule with snap-confine peer [11:42] PR #4871: cmd/snap-confine: fix Archlinux compatibility [11:42] it looks as if when updating snap-confine apparmor profile, some temp files are left behind [11:43] mvo: zyga: any ideas how that could be possible? [11:43] no, [11:43] we just write it using atomic thing [11:43] 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:44] phoenix_firebrd: no, it's their snap and their bug reports [11:45] mborzecki: looking [11:45] 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:46] mborzecki: do you have a link to the failure log or a pastebin of it? [11:46] yes [11:46] mvo: https://paste.ubuntu.com/p/xCzYR4Ztpv/ [11:46] ta [11:46] mborzecki: but I don't know why it would stay behind now [11:47] zyga: that is ensureDirState, right? that is used all over the place so should be well tested [11:47] yes [11:47] and the actual writing is done by atomic thing AFAIR [11:47] so I doubt it's something newly broken there [11:48] or its a race [11:48] i.e. we write things at the same time when the profile is loaded? [11:48] hmmmm [11:48] perhaps [11:48] but who would load it? [11:48] (a long shoot) [11:48] I have no idea :) [11:48] apparmor loads that profile [11:48] but we start after apparmor [11:48] then snapd reloads that profile [11:48] but _exactly_ that profile (not everything else) [11:48] the error is weird btw, [11:49] ah [11:49] + aa-enforce /etc/apparmor.d/usr.lib.snapd.snap-confine.real [11:49] this is aa-enforce doing things [11:49] it's just a test thing, we never touch that from snapd [11:49] so something goes wrong [11:49] and then much later we run aa-enfroce [11:49]