| mup | PR snapcraft#1929 closed: sources: proper errors for invalid handlers <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1929> | 00:41 |
|---|---|---|
| mup | PR snapcraft#1942 opened: Release changelog for 2.39.2 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1942> | 00:44 |
| elopio | snappy-m-o autopkgtest 1926 xenial:armhf xenial:amd64 xenial:arm64 | 01:05 |
| snappy-m-o | elopio: I've just triggered your test. | 01:05 |
| elopio | snappy-m-o autopkgtest 1942 xenial:armhf xenial:amd64 xenial:arm64 | 01:52 |
| snappy-m-o | elopio: I've just triggered your test. | 01:52 |
| hego555 | yo guys, my snaps seem to not have any internet connection... Spotify says no internet connection and so does Writefull | 03:39 |
| hego555 | i made sure the network plug was enabled | 03:40 |
| sergiusens | snappy-m-o autopkgtest 1943 bionic:amd64 bionic:arm64 bionic:armhf | 04:41 |
| snappy-m-o | sergiusens: I've just triggered your test. | 04:41 |
| mup | PR snapcraft#1943 opened: Release/2.39.2+18.04 (DO NOT MERGE) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1943> | 04:42 |
| mborzecki | morning | 06:07 |
| mborzecki | mvo: morning | 06:24 |
| mvo | hey mborzecki ! good morning | 06:24 |
| mborzecki | mvo: i noticed this in one of the travis jobs: https://paste.ubuntu.com/p/qYKjfqYdxF/ is this the restart on refresh mode thing? | 06:25 |
| mvo | mborzecki: yes - looks like a race, do you have the full log? there should be logging to syslog around this to help tracking this down | 06:27 |
| mborzecki | mvo: https://api.travis-ci.org/v3/job/343470218/log.txt | 06:28 |
| mvo | mborzecki: hm, hm, the log looks ok, the right restart reason and all that. puzzling | 06:35 |
| mborzecki | mvo: maybe the log comes from before the actual test action happened? | 06:38 |
| mvo | mborzecki: yeah, I wonder why | 06:39 |
| mborzecki | mvo: backend calls systemd.Restart(), that's implemented as stop & start | 06:41 |
| mvo | mborzecki: oh, thats an interessting clue, a restart with no restart reason. when is backend calling this? | 06:43 |
| mborzecki | mvo: i believe the path is ifacestate.setupSnapSecurity() -> backend.Setup() -> systemd.Restart() | 06:44 |
| mvo | ta | 06:46 |
| mborzecki | mvo: do you need any help with that issue? | 07:45 |
| mvo | mborzecki: help would be great, I'm still fighting with the 2.31.1 stable release and the oom error and the autopkgtests | 07:46 |
| mborzecki | mvo: oom error? you got me interested now | 07:47 |
| mvo | mborzecki: on bionic/i386 the interfaces-many tests triggers an oom error | 07:47 |
| mvo | mborzecki: its not a new bug, I can reproduce it with 2.29.x too | 07:47 |
| mvo | mborzecki: but its very unclear right now what is causing it | 07:48 |
| mvo | mborzecki: its reliable to reproduce on i386 | 07:48 |
| mborzecki | mvo: is snapd getting killed? | 07:49 |
| mvo | mborzecki: everything is getting killed :) its also strange as htop does not show any user space grwoing like mad. also the swtich from ok(ish) to oom comes very fast | 07:50 |
| mvo | mborzecki: http://paste.ubuntu.com/p/gVgDtTqPBg/ this is the script | 07:50 |
| mvo | mborzecki: I can prepare a tar that includes the two snaps to run this | 07:51 |
| mborzecki | mvo: no need, if they are in tests/lib/snaps i can build them myself | 07:53 |
| mvo | mborzecki: I will do it anyway I think because I want to run it on an amd64 and compare the logs. it seems like th eoom condition is not triggered there | 07:54 |
| mvo | mborzecki: might be kernel, might be udev | 07:54 |
| mvo | mborzecki: each connect seems to take in the range of 12mb | 07:55 |
| mvo | mborzecki: it could be apparmor too, we load profiles on each connect | 07:55 |
| mborzecki | mvo: wow, that's a lot | 07:55 |
| mvo | mborzecki: well, thats what "free" tells me, its not clear (to me yet) where this memory actually goes | 07:55 |
| mborzecki | mvo: i'll try to play with pprof, see if anything comes up | 07:56 |
| mborzecki | mvo: there's a bunch of maps flying around in the code, also we may be collecing some output from processses that we run | 07:57 |
| mvo | mborzecki: my gut feeling is that its external to snapd, we need more data, but afaict this is fine on xenial/i386 | 08:00 |
| mborzecki | mvo: interesting, is ti possible to say, disable apparmor and not call apparmor_parser? | 08:01 |
| mvo | mborzecki: yeah, that might be worth a shot | 08:01 |
| mvo | mborzecki: its puzzling, free telle me I have "479404" used and "784648" free - thats confusing (but memory reporting apparently is) | 08:02 |
| mvo | mborzecki: I also see a lot of kmalloc-8192 in slab-info | 08:03 |
| mvo | mborzecki: the objects there grow from 500 to 5000 | 08:03 |
| mvo | (which is still not that much in total memory size about 40mb) | 08:03 |
| pstolowski | mornings | 08:06 |
| mvo | mborzecki: my current theory is that for some reason "normal" memory runs out on i386. there is plenty of "highmem" free but the normal memory falls below the threshold of 20mb | 08:09 |
| mborzecki | pstolowski: morning | 08:10 |
| mvo | hey pstolowski ! good morning | 08:10 |
| pstolowski | mvo, heya, is this re to the 'killed...' issue on connect from yesterday? | 08:12 |
| mvo | pstolowski: yes | 08:15 |
| pstolowski | interesting | 08:16 |
| mup | PR snapd#4676 closed: timeutil: introduce helpers for checking it time falls inside the schedule <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4676> | 08:17 |
| mborzecki | mvo: hm the test only connects the interfaces, so maybe temporarily linking apparmor_parser to /bin/true would allow to skip this path if that's what you suspect | 08:20 |
| mborzecki | pstolowski: if you're up for reviews https://github.com/snapcore/snapd/pull/4695 needs looking at :) | 08:23 |
| mup | PR #4695: wrappers: generator for systemd OnCalendar schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4695> | 08:23 |
| mborzecki | mvo: xenial i386 vm is updating, meanwhile i'll look at refresh mode thing | 08:26 |
| pstolowski | mborzecki, sure! | 08:26 |
| mborzecki | pstolowski: great, thanks :) | 08:26 |
| mvo | mborzecki: I will write a forum post in a wee bit that summarizes my current findinds | 09:02 |
| sergiusens | snappy-m-o autopkgtest 1942 xenial:armhf xenial:amd64 xenial:arm64 | 09:05 |
| snappy-m-o | sergiusens: I've just triggered your test. | 09:05 |
| Chipaca | sergiusens: morning! (?) | 09:06 |
| sergiusens | Chipaca: intermittent, just woke up to trigger these darn tests :-) | 09:06 |
| sergiusens | snappy-m-o autopkgtest 1943 bionic:amd64 bionic:arm64 bionic:armhf | 09:12 |
| snappy-m-o | sergiusens: I've just triggered your test. | 09:12 |
| mup | PR snapd#4708 opened: overlord/snapstate: use spread in the default refresh schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4708> | 09:31 |
| mborzecki | mvo: so no apparmor no leak? | 09:36 |
| mvo | mborzecki: thats what it looks like to me at least | 09:37 |
| mborzecki | that's interesting observation | 09:39 |
| mborzecki | , udev/seccomp/cgroups is all there right? | 09:39 |
| mvo | mborzecki: yes, I just disabled this one | 09:39 |
| mup | PR snapd#4709 opened: tests: fixes for autopkgtest in bionic <Created by mvo5> <https://github.com/snapcore/snapd/pull/4709> | 09:42 |
| mborzecki | mvo: can you try with something more recent, like 4.15.4? | 09:43 |
| mborzecki | mvo: i mean the kernel ofc | 09:43 |
| mvo | mborzecki: yeah, I am preparing a more automatic thing now | 09:47 |
| mvo | mborzecki: I mean a tarfile so that one can just run ./test.sh | 09:48 |
| mvo | mborzecki: and then I can test on more systems (artful etc) to see when it started | 09:48 |
| mborzecki | mvo: i did not observe any issues on xenial, but that's a really old kernel | 09:49 |
| mvo | mborzecki: interessting | 09:51 |
| mborzecki | mvo: https://paste.ubuntu.com/p/bWVBw4Yp6v/ | 09:53 |
| mborzecki | LowTotal: 858144 kB | 09:53 |
| mborzecki | LowFree: 723696 kB | 09:53 |
| mvo | mborzecki: this is xenial? | 09:53 |
| mborzecki | mvo: yes | 09:54 |
| mvo | mborzecki: it seems to have a different lowmem split | 09:55 |
| mvo | mborzecki: i.e. more available (my system only had ~400mb) | 09:55 |
| mvo | mborzecki: is it also shrinking fast? | 09:55 |
| mvo | mborzecki: same here, no craziness on 16.04-32 | 10:02 |
| seb128 | mvo, hey | 10:03 |
| seb128 | mvo, can you help us? andyrock needs some input on changes he would like to suggest for snapd that he needs for his livepatch work | 10:03 |
| mborzecki | mvo: https://imgur.com/a/xDeVR | 10:04 |
| mvo | seb128: sure, what kind of changes does he have in mind? | 10:04 |
| mborzecki | mvo: the test script stars around 20s mark | 10:04 |
| andyrock | mvo: so we need to login in snapd from the installer. The problem is that we can't talk with the to-be-installed snapd in ubiquity | 10:05 |
| andyrock | mvo: the chroot hack does not work (in a nutshell the chroot is not ready when we need it) | 10:06 |
| mvo | mborzecki: what is the y axis? | 10:06 |
| mborzecki | mvo: kB, LowFree | 10:06 |
| mvo | mborzecki: ta | 10:06 |
| andyrock | mvo: would be possible to have a way to seed the auth state? something like this: https://paste.ubuntu.com/p/sSbKstQ2Sy/ | 10:06 |
| mvo | andyrock: interesting! pedronis, what do you think about the ability to put auth.json into the seed directory and import it on firstboot? this is for the desktop installer use-case | 10:08 |
| pedronis | mvo: I'm a bit missign the context | 10:10 |
| andyrock | pedronis: I've been asked to add snapd login in the installer | 10:11 |
| mvo | pedronis: they allow people to login into the store/snapd in the livecd session. but the snapd that is running in there is not the snapd that is copied to the hardisk. the harddisk snapd will have an empty state.json | 10:11 |
| mvo | pedronis: so the user would have to login again after the system was installed | 10:11 |
| pedronis | what is that auth.json? the one from the homedir? | 10:13 |
| pedronis | or something else | 10:13 |
| andyrock | something else | 10:13 |
| pedronis | the one in the homedir doesn't have all the data | 10:13 |
| andyrock | something we need to take from the livecd state.json | 10:13 |
| andyrock | we can take all under auth: {...} | 10:14 |
| pedronis | no you don't want everything | 10:14 |
| pedronis | because there's device info there | 10:14 |
| andyrock | kk | 10:14 |
| pedronis | and I think we are trying not to make livece session count the same wa | 10:14 |
| pedronis | as full installs | 10:14 |
| andyrock | pedronis: so last-id, users, and macaroon-key? | 10:18 |
| andyrock | or last-id and users are enough? | 10:18 |
| pedronis | andyrock: you need the macaroon-key as well, if you plan to port ~/.snap/auth.json over or the gnome-software equivalent | 10:27 |
| andyrock | kk | 10:27 |
| andyrock | pedronis: so are you willing to accept something like that? | 10:28 |
| pedronis | maybe, is not just my decision | 10:28 |
| pedronis | it needs also to be a bit more paranoid about checking the perms of that file | 10:29 |
| andyrock | kk who else should we ask? | 10:29 |
| pedronis | you need niemeyer +1 as well | 10:31 |
| pedronis | I'm mildly worried that it allows to clone the same creds on a lot of images, it's not your use case but it can be used that way | 10:33 |
| andyrock | pedronis: should we move the discussion the forum? | 10:36 |
| andyrock | *in the | 10:36 |
| pedronis | yes | 10:37 |
| pedronis | you should make a proposal there I suppose | 10:37 |
| === ikey|afk is now known as ikey | ||
| mvo | pedronis, andyrock another option might be to join the standup as a guest | 10:49 |
| zyga_ | o/ | 10:50 |
| zyga_ | I'm sick and I won't be around today | 10:50 |
| zyga_ | I just got off the bed to let you guys know | 10:50 |
| zyga_ | sorry about that :/ | 10:50 |
| mvo | zyga_: get well | 10:50 |
| * mvo hugs zyga_ | 10:50 | |
| zyga_ | thank you, I be back as soon as I can | 10:50 |
| mup | PR snapd#4704 closed: tests: store journal in autopkgtest artiffacts and add 18.04-32 to qemu <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4704> | 10:51 |
| mvo | mborzecki: fwiw, artful seems to show the same behavior | 11:09 |
| magicaltrout | random question, is there a pattern for dealing with migrating configs and stuff on a snap package upgrade? | 11:10 |
| magicaltrout | or do you just bake something into the start script? | 11:11 |
| popey | mvo: I'm told there's a PR in flight somewhere which will enable a snap (like gnome-calculator) to auto-download & install a platform snap (like the gnome one). Do you know what stage that's at? | 11:15 |
| mvo | popey: that is #4103 | 11:15 |
| mup | PR #4103: snapstate: auto install default-providers for content snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4103> | 11:15 |
| mvo | popey: we want to get it in for 2.32, its a bit hard because there is some work to do still but its super important to us | 11:16 |
| popey | mvo: excellent, thanks. | 11:16 |
| popey | Yes, that would be awesome. | 11:16 |
| * pstolowski lunch | 11:32 | |
| mborzecki | mvo: that problem with test-snapd-service endure, the only idea i have atm is that we do journalctl --rotate, but no journalctl --sync, if a test using test-snapd-service was run before that one, we could end up with a log from the previous run | 11:35 |
| mvo | mborzecki: interessting, that sounds like a good theory | 11:36 |
| mborzecki | funnily enough, looking at the source code of journalctl, you cannot use `journalctl --sync --rotate` in a single command, both flags are set to the same variable | 11:37 |
| mup | PR snapd#4710 opened: tests/lib/prepare-restore: sync journal before rotating and vacuuming <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4710> | 11:45 |
| mborzecki | mvo: ^^ a simple fix for now, let's see if this is enough | 11:46 |
| mup | PR snapd#4709 closed: tests: fixes for autopkgtest in bionic <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4709> | 11:46 |
| mvo | mborzecki: \o/ | 11:47 |
| Chipaca | mborzecki: mvo: #4708 gtg | 12:00 |
| mup | PR #4708: overlord/snapstate: use spread in the default refresh schedule <Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4708> | 12:00 |
| mup | PR snapd#4708 closed: overlord/snapstate: use spread in the default refresh schedule <Critical> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4708> | 12:02 |
| mvo | Chipaca, mborzecki thanks, cherry-picked into 2.31.1 | 12:07 |
| cachio | mvo, hey | 12:09 |
| mvo | hey cachio | 12:10 |
| cachio | test-snapd-hello-classic in the store for s390x, stil waiting a review | 12:10 |
| cachio | mvo, updating the kernel in the qemu machine | 12:10 |
| mvo | cachio: aha, cool, I can do that after lunch | 12:10 |
| cachio | mvo, same issue with an old kernel | 12:30 |
| mborzecki | cachio: oom? | 12:30 |
| cachio | mborzecki, yes | 12:31 |
| mborzecki | cachio: how much ram are those vms getting? | 12:32 |
| cachio | mborzecki, well, I could not connect anymore | 12:32 |
| cachio | mborzecki, 3500 MB | 12:32 |
| mborzecki | cachio: tried this today on 16.04 32bit, with -mem 4096 and haven't observed any issues, lowmem did drop a bit though, see ~20s mark https://imgur.com/a/xDeVR | 12:34 |
| cachio | mborzecki, I ran some scripts yesterday and it is like in 18.04 i386 the garbage collections is not done | 12:36 |
| cachio | so you connect disconnect and do stuff and the memory is not release | 12:37 |
| cachio | d | 12:37 |
| mborzecki | cachio: can you try to collect this `while true; do echo "$(date +%s) $(awk '/LowFree/ {print $2}' < /proc/meminfo)"; sleep 1; done` while the test is run and paste is somewhere? | 12:40 |
| cachio | mborzecki, sure | 12:40 |
| cachio | mborzecki, https://paste.ubuntu.com/p/JTBkvh5PqN/ | 13:05 |
| mborzecki | hmm it's really low to begin with | 13:14 |
| Chipaca | jdstrand: ping | 13:21 |
| jdstrand | hey Chipaca | 13:22 |
| Chipaca | jdstrand: pm | 13:22 |
| mvo | jdstrand: hey, https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101 might be interessting for you guys, I suspect it is apparmor related (but maybe not) | 13:23 |
| sergiusens | stgraber: hi there, was wondering if there is a probe command in lxd to figure out that we have been `init'ed` | 13:25 |
| mborzecki | i'm experimenting with `snap set core refrsh.timer=<...>` and it's a bit weird, you see the current setting appear right away in `snap refresh --time` but it becomes effective only after restart or when the current next expires | 13:54 |
| pedronis | mborzecki: shouldn't be like that looking at the code, but it might take 5 minutes to take effect if we are not careful | 13:57 |
| mborzecki | pedronis: how often is autorefresh.Ensure() called? | 13:59 |
| cachio | mvo, mborzecki I ran with this kernel and I for the oom issue too https://paste.ubuntu.com/p/4X9s7jtybd/ | 14:02 |
| pedronis | mborzecki: if nothing is going on, each 5 minutes | 14:02 |
| pedronis | that's where my 5 minutes comes from | 14:02 |
| mup | PR snapd#4710 closed: tests/lib/prepare-restore: sync journal before rotating and vacuuming <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4710> | 14:03 |
| mvo | cachio: oh, interessting. | 14:04 |
| pedronis | mborzecki: it's ensureInterval in overlord/overlord.go, probably worth getting familiar with that bit | 14:04 |
| mborzecki | pedronis: yup, looking at it now | 14:04 |
| pedronis | mborzecki: we have state.EnsureBefore to trigger it earlier, various places use it | 14:05 |
| pedronis | some in taskrunner.go | 14:05 |
| mborzecki | right, i've seen this one before :) | 14:06 |
| === pbek_ is now known as pbek | ||
| cachio | mvo, is it any way to disable apparmor and make the tests work? | 14:07 |
| cachio | mvo, to discard that? | 14:07 |
| cachio | mvo, I'll try just removing it | 14:09 |
| mvo | cachio: I did: "mv /sbin/apparmor_parser /sbin/apparmor_parser.saved" | 14:09 |
| mborzecki | pedronis: there's a funny effect, that once a refresh runs as is successful, next becomes time.Time{}, so when you do `snap refresh --time`, next will be 'n/a' | 14:09 |
| mvo | cachio: cp /bin/true /sbin/apparmor_parser | 14:10 |
| jdstrand | mvo: interesting. As you said, this sounds like a kernel issue since you couldn't reproduce on 4.10 or lower | 14:10 |
| cachio | mvo, you already tried that and it didn't work? | 14:11 |
| jdstrand | mvo: you said 4.10 was not affected. 4.13 (artful) is? why are we only seeing this now? is it just now is when you decided to get to the bottom of artful and bionic issues? | 14:11 |
| mvo | jdstrand: take it with a grain of salt, cachio said he sees it with 4.10 too, I will double check | 14:11 |
| mvo | cachio: that worked for me | 14:11 |
| mvo | cachio: when I moved the apparmor_parser away I did not see the mem leak anymore | 14:11 |
| jdstrand | mvo: how much memory is in the vm? | 14:11 |
| mvo | jdstrand: I think its some factors: the interfaces-many test got added relatively recently, we don't run much on i386 and autopkgtest for 2.30 did not run because we had problems getting this snap accepted into the archive at all | 14:12 |
| mvo | jdstrand: the vm has 1500mb | 14:12 |
| mvo | jdstrand: but it seems like the LowMem is what triggers the oom on i386 which is just 400mb | 14:12 |
| jdstrand | mvo: this is i386 only/ | 14:12 |
| jdstrand | ? | 14:13 |
| mvo | jdstrand: I suspect its amd64 too, it just takes a lot longer as it has the full 1500mb of memory | 14:13 |
| mvo | jdstrand: for some reason its the lowmem on i386 that runs out | 14:13 |
| mvo | jdstrand: the oom-test.tar.gz should have all that is needed to reproduce | 14:13 |
| mvo | jdstrand: let me run it (in a loop) on amd64 to see if it eventually also dies | 14:14 |
| jdstrand | mvo: yes. I'd like to remove snapd from the equation though so I commented in the topic | 14:14 |
| mvo | jdstrand: I see ~15mb per "snap connect" decrease in free memory with 4.13. maybe with 4.10 (and below) the leak is just smaller that is why cachio sees it (because he was looking harder) and I don't (because I was just looking for the oom to trigger) | 14:15 |
| Chipaca | mvo: the interfaces-many test is a bit of a hog, it has so many changes that towards the end it takes seconds to do each one | 14:15 |
| mvo | Chipaca: indeed | 14:16 |
| mvo | jdstrand: I run it now on amd64 in a loop just to see what will happen (bionic with 4.13) | 14:16 |
| mborzecki | mvo: what if you try to reload apparmor profiles in a loop? | 14:16 |
| jdstrand | mvo: note that an apparmor profile does take kernel memory. it should not take that much and it shouldn't lose 15mb with a replace operation | 14:16 |
| mvo | jdstrand: *nod* | 14:17 |
| mborzecki | off to pick up the kids | 14:18 |
| mvo | jdstrand: fwiw, it looks like amd64 is also affect, just takes longer because of the different memory available (1480 vs 390) | 14:26 |
| cachio | mvo, https://paste.ubuntu.com/p/YsCpXvfgNg/ | 14:28 |
| cachio | 56MB free | 14:28 |
| cachio | preparing the suite | 14:28 |
| kalikiana | re | 14:36 |
| sergiusens | snappy-m-o autopkgtest 1942 xenial:armhf | 14:49 |
| snappy-m-o | sergiusens: I've just triggered your test. | 14:49 |
| === rharper` is now known as rharper | ||
| mvo | cachio: yeah, same here, eventually amd64 also runs out of memory | 15:18 |
| cachio | mvo, I am gonna try with an older bionic image | 15:22 |
| mvo | cachio: thank you | 15:23 |
| jdstrand | mvo: https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101/5 | 15:24 |
| jdstrand | oh heh, you already liked it | 15:25 |
| mvo | jdstrand: very much indeed! thanks for the reproducer | 15:25 |
| mvo | cachio: -^ | 15:25 |
| mvo | cachio: looks like jdstrand has an even better reproducer that does not involve snapd, probably easy(ish) to bisect using this | 15:25 |
| brunosfer | Hi guys! I installed bluez in Ubuntu Core Snappy and I'm having this problem: | 15:26 |
| brunosfer | bluez.sdptool browse local | 15:26 |
| brunosfer | Failed to connect to SDP server on FF:FF:FF:00:00:00: No such file or directory | 15:26 |
| jdstrand | mvo: I think for now the test should be disabled on i386 | 15:26 |
| brunosfer | Does anyone knows how can I solve this issue? | 15:26 |
| jdstrand | mvo: the test really only needs to be run on one arch imho | 15:26 |
| mvo | yes+ | 15:27 |
| jdstrand | well | 15:27 |
| jdstrand | the snapd part of the test is only useful on one arch | 15:27 |
| * mvo nods | 15:28 | |
| jdstrand | the fact that it showed an issue on i386 is certainly helpful :) | 15:28 |
| marcoceppi | o/ can anyone help me with this: https://forum.snapcraft.io/t/refreshing-disabled-snap-kubectl-not-supported/4060/11 | 15:38 |
| brunosfer | Hi guys! I installed bluez in Ubuntu Core Snappy and I'm having this problem: $bluez.sdptool browse local Failed to connect to SDP server on FF:FF:FF:00:00:00: No such file or directory | 15:39 |
| brunosfer | Does anyone knows how can I solve this issue? | 15:39 |
| ogra_ | brunosfer, it is probably best to ask this on the forum ... koza can probably help but i think he is not around currently (so he can more easily pick up the question on the forum later) | 15:40 |
| ogra_ | also make sure to describe what HW you run and if all your interfaces are connected properly etc | 15:40 |
| brunosfer | how much later? because I posted that issue since December 17th and so far I'm stuck and nobody replied... | 15:41 |
| ogra_ | brunosfer, where did you post it ? | 15:42 |
| marcoceppi | Chipaca: o/ | 15:42 |
| brunosfer | Everytime I make this question here people redirect me to the forum and it's a dead end... | 15:42 |
| ogra_ | (got a link to the forum post ?) | 15:42 |
| brunosfer | https://forum.snapcraft.io/t/failed-to-connect-to-sdp-server-permission-problem/3085 | 15:42 |
| mvo | hm, hm, today https://forum.snapcraft.io/t/all-revisions-of-snaps-are-mounted-when-they-dont-need-to-be/2294 came up, I wonder if anyone ever looked what is taking >500ms | 15:47 |
| jdstrand | mvo: fyi, jjohansen is aware of a profile replace memory leak and will continue to look into it | 15:48 |
| Chipaca | marcoceppi: o/! | 15:55 |
| Chipaca | marcoceppi: how's things? | 15:55 |
| Chipaca | marcoceppi: so, tell me more about this messed-up snapd you have | 15:55 |
| marcoceppi | great except for my broken snaps :( | 15:55 |
| marcoceppi | I mean, it's my laptop | 15:55 |
| Chipaca | marcoceppi: ok. Can you enabled debug, if you haven't already? | 15:55 |
| Chipaca | enable* | 15:56 |
| marcoceppi | 16.04 full patched, few days ago a new kubectl snap was published and since then it's not been well | 15:56 |
| Chipaca | marcoceppi: that's add SNAPD_DEBUG=1 to /etc/environment and 'systemctl restart snapd' | 15:56 |
| marcoceppi | yeah, restarting snapd hangs | 15:56 |
| Chipaca | niiice | 15:57 |
| Chipaca | marcoceppi: hangs how? | 15:57 |
| mvo | marcoceppi: what exactly is broken? does snapd itself misbehave? or one (or muliple) snaps? | 15:57 |
| marcoceppi | mvo: https://forum.snapcraft.io/t/refreshing-disabled-snap-kubectl-not-supported/4060/11 | 15:57 |
| Chipaca | mvo: https://forum.snapcraft.io/t/refreshing-disabled-snap-kubectl-not-supported/4060/7 | 15:57 |
| marcoceppi | Chipaca: restart command blocks indefinitely | 15:57 |
| Chipaca | haha | 15:57 |
| Chipaca | youch | 15:57 |
| Chipaca | marcoceppi: what does 'journalctl -u snapd' show? | 15:57 |
| marcoceppi | I can straight up kill it | 15:57 |
| marcoceppi | Chipaca: https://paste.ubuntu.com/p/fDhqFCPGkC/ | 15:58 |
| Chipaca | marcoceppi: is that the _end_ of the journal? | 15:59 |
| marcoceppi | yeah, I mean, I just did an -f and it's printing a few more things | 15:59 |
| marcoceppi | like sysctl just SIGKILL'd the proc | 15:59 |
| Chipaca | with the SNAPD_DEBUG, and it hanging, i'd expect lots of stuff | 15:59 |
| Chipaca | nnngh | 15:59 |
| marcoceppi | oh, no, still waiting for it to restart | 15:59 |
| marcoceppi | so it can get SNAPD_DEBUG | 15:59 |
| Chipaca | ok, so just kill it | 16:00 |
| Chipaca | something is bad | 16:00 |
| * marcoceppi nods | 16:00 | |
| Chipaca | and the oom will kill one thread and leave go wondering | 16:00 |
| Chipaca | so when that happens you need to manually kill the whole thing | 16:00 |
| pedronis | kubectl is classic fwiw | 16:00 |
| Chipaca | ack | 16:00 |
| marcoceppi | yes, but lxd isnt pedronis and it has the same problem | 16:01 |
| Chipaca | pedronis: i mean, if it were just the snap misbehaving i'd kick it over to sergio :-) | 16:01 |
| Chipaca | pedronis: but this is snapd doing something weeeird | 16:01 |
| pedronis | but you said it started when you got the new kubectl | 16:01 |
| marcoceppi | that's when I noticed it exhibiting issues, yes | 16:01 |
| Chipaca | marcoceppi: how's the kill-everything-and-start-over going? | 16:01 |
| marcoceppi | it's started | 16:01 |
| marcoceppi | Chipaca: https://paste.ubuntu.com/p/vR9Nky4bhx/ | 16:02 |
| Chipaca | marcoceppi: can you 'curl -s -N -0 --unix-socket /run/snapd.socket http://localhost/v2/changes?select=all | python -m json.tool | pastebinit'? | 16:03 |
| Chipaca | marcoceppi: assuming you have pastebinit, otherwise you know what i mean | 16:03 |
| marcoceppi | that's a mouthful | 16:03 |
| marcoceppi | http://paste.ubuntu.com/p/nRTM6jyyvT/ | 16:04 |
| Chipaca | marcoceppi: can you do a 'sudo du -sh /root/snap/* /home/user/snap/* /var/snap/*' ? | 16:06 |
| Chipaca | (depending on your permissions you might need to tweak that for the glob to expand everywhere) | 16:06 |
| marcoceppi | Chipaca: https://paste.ubuntu.com/p/HNq9hGGm66/ | 16:07 |
| Chipaca | marcoceppi: if you say 'snap watch 481' does it still say it's copying stuff? | 16:08 |
| marcoceppi | yes | 16:08 |
| Chipaca | marcoceppi: that's kubefed, yes? | 16:08 |
| marcoceppi | correct | 16:08 |
| Chipaca | marcoceppi: so my question for you is, how does it take this long to copy 28k of data | 16:08 |
| marcoceppi | well, that's my question for you - isn't it :D | 16:09 |
| marcoceppi | SSD with over 60GB of free space on EXT4 | 16:09 |
| Chipaca | marcoceppi: can you try copying that directory somewhere, by hand? ie 'cp -a /var/snap/kubefed /var/tmp' ? | 16:09 |
| marcoceppi | Chipaca: | 16:10 |
| marcoceppi | time cp -a /var/snap/kubefed /var/tmp/ | 16:10 |
| marcoceppi | real0m0.003s | 16:10 |
| marcoceppi | user0m0.000s | 16:10 |
| marcoceppi | sys0m0.000s | 16:10 |
| marcoceppi | worked without issue | 16:10 |
| cachio | mvo, using an 2 months old bionic image I see the same oom error | 16:11 |
| mvo | cachio: ta | 16:11 |
| Chipaca | marcoceppi: the other one you had in doing was copying the lxd data | 16:11 |
| Chipaca | marcoceppi: that one could take a bit longer, it being 5 gigs | 16:11 |
| mvo | cachio: jdstrand told me the memory leak is something that jjohansen is investigating. maybe he knows (roughly) when this started ? if not we might be able to help bisecting | 16:12 |
| marcoceppi | yeah, but it's been over 24 hours | 16:12 |
| marcoceppi | and LXD was a problem after 24 hours of the kubectl issue | 16:12 |
| marcoceppi | I feel like snapd is unable to perform this action | 16:12 |
| Chipaca | marcoceppi: is there anything new in the logs? | 16:13 |
| marcoceppi | Feb 20 11:03:59 T430 snapd[28114]: 2018/02/20 11:03:59.146915 daemon.go:233: DEBUG: pid=28499;uid=1000;@ GET /v2/changes?select=all 1.369681ms 200 | 16:13 |
| marcoceppi | that is the only new line | 16:13 |
| Chipaca | that's you | 16:13 |
| marcoceppi | yes, I realize that, but wanted to be complete in my reporting | 16:14 |
| Chipaca | yes yes, i was just confirming | 16:14 |
| Chipaca | I don't understand what it thinks it's doing | 16:14 |
| marcoceppi | can I - like delete this change attempt and just start over? | 16:14 |
| marcoceppi | I really /really/ DO not want to lose my lxd containers | 16:15 |
| marcoceppi | but kubectl has no userdata | 16:15 |
| Chipaca | marcoceppi: i mean, you could, but it'd be hairy | 16:15 |
| Chipaca | marcoceppi: can you stop snapd, and start it straced? | 16:15 |
| marcoceppi | you got what I should invoke for snapd to be strace'd? | 16:16 |
| Chipaca | marcoceppi: so, first, systemctl stop snapd.\* | 16:17 |
| cachio | mvo, so, are you preparing 2.31.1 today, or we need to wait until this is fixed? | 16:18 |
| Chipaca | marcoceppi: and then: sudo strace -E SNAPD_DEBUG=1 -f -s 9999 -o /tmp/snapd.trace /usr/lib/snapd/snapd | 16:18 |
| cachio | mvo, or any other fix? | 16:18 |
| pedronis | Chipaca: 5G in versioned data, that's a problem in itself, we though common is for that | 16:20 |
| Chipaca | pedronis: is it versioned? | 16:20 |
| pedronis | well if it's being copied | 16:20 |
| pedronis | we don't copy common data, no? | 16:20 |
| Chipaca | we don't | 16:20 |
| Chipaca | but I don't know if that's what it's doing | 16:20 |
| Chipaca | it says it's copying a 28k directory, also | 16:20 |
| pedronis | ok, ignore me | 16:20 |
| Chipaca | for hours | 16:20 |
| Chipaca | pedronis: no, no, i need ideas :-) | 16:20 |
| Chipaca | pedronis: especially if nothing turns up in the trace | 16:21 |
| pedronis | anyway both these snaps are classic I suppose | 16:21 |
| marcoceppi | Chipaca: so, I can't start snapd manually , says socket is in use but no other proc is really running | 16:21 |
| pedronis | so they could do strange stuff on their own | 16:21 |
| pedronis | fwiw | 16:21 |
| pedronis | though hooks have timeouts | 16:21 |
| pedronis | in theory | 16:21 |
| marcoceppi | Chipaca: nvm, fixed it | 16:21 |
| Chipaca | marcoceppi: what was it? | 16:21 |
| marcoceppi | I have like 100% lack of chill right now, heh | 16:22 |
| marcoceppi | how long do you want me to collect strace data? | 16:22 |
| mvo | cachio: today | 16:22 |
| mvo | cachio: it looks like we need test-snapd-password-manager-consumer for s390x | 16:23 |
| mvo | cachio: I'm just inspecting the s390x autopkgtest failure | 16:23 |
| Chipaca | marcoceppi: a couple of minutes after it says 'Running task 5559 on Doing: Copy snap "kubefed" data' | 16:23 |
| mvo | cachio: but no blocker, I will go ahead with 2.31.1 onw | 16:23 |
| marcoceppi | Chipaca: cool, it's been doing that, I'll let it run a wee bit | 16:23 |
| Chipaca | marcoceppi: you can tail /tmp/snapd.trace if you're anxious (i know i'd be) | 16:24 |
| cachio | mvo, ok, I can't update the snap recipe | 16:25 |
| mvo | cachio: oh, ok. let me check | 16:25 |
| cachio | to generate the snap fo s390x | 16:25 |
| mup | PR snapd#4711 opened: tests: make restore of interfaces-password-manager-service more robust <Created by mvo5> <https://github.com/snapcore/snapd/pull/4711> | 16:26 |
| cachio | mvo, it is yours | 16:26 |
| marcoceppi | Chipaca: Okay 5 mins of strace data since copy message | 16:26 |
| mvo | cachio: *cough* indeed - fixed | 16:26 |
| marcoceppi | Chipaca: https://paste.ubuntu.com/p/4CphPf7stb/ | 16:27 |
| Chipaca | marcoceppi: and /tmp/snapd.trace ? | 16:28 |
| marcoceppi | Chipaca: yeah, let me paste it | 16:28 |
| Chipaca | ah :-) | 16:28 |
| Chipaca | i was worried and perplexed, there | 16:28 |
| marcoceppi | although - heh - I can't get the proc to interrupt | 16:28 |
| marcoceppi | Chipaca: http://paste.ubuntu.com/p/7bCBVTMMTV/ | 16:29 |
| marcoceppi | I hope I didn't crash pastebin | 16:29 |
| Chipaca | marcoceppi: you're probably going to have to sudo killall strace | 16:30 |
| marcoceppi | sure, I'll also gz upload that file | 16:30 |
| Chipaca | can confirm that pastebin is not a happy bunny | 16:30 |
| marcoceppi | Chipaca: http://marcoceppi.com/snapd.trace.gz | 16:32 |
| mup | PR snapcraft#1944 opened: tests: split the plugins tests in the same directory <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1944> | 16:33 |
| cachio | mvo, I see several errors on the arm64 execution for autopkgtest | 16:33 |
| cachio | mvo, should I fix them? | 16:33 |
| marcoceppi | Chipaca: interestingly, I have a bunch of orphaned sync commands like in the paste above | 16:34 |
| mvo | cachio: yeah, but not high priority, it was not green before so it will not be a blocker | 16:34 |
| cachio | mvo, yes, smae for ppc64el and s390x | 16:35 |
| mvo | cachio: the issues on ppc64el and s390x are considered regressions by adt so that is higher priority | 16:35 |
| mvo | cachio: afaict ppc64el is mostly good | 16:35 |
| mvo | cachio: and s390x has some snaps missing, then we need to retrigger and see | 16:35 |
| cachio | ppc64el just 4 errors | 16:36 |
| mvo | cachio: its "funny", s390x was considered working before because we skipped it because it was only a lxd container | 16:36 |
| mvo | cachio: the timezone ones, right? | 16:36 |
| marcoceppi | brb, going to restart | 16:36 |
| mvo | cachio: those are fixed with the systemd in -propsoed | 16:36 |
| cachio | mvo, yes and confinement-classic because the snap was not relased | 16:37 |
| cachio | released | 16:37 |
| mvo | cachio: indeed | 16:37 |
| mvo | cachio: apparently it is possible to retrigger the adt with &trigger=systemd/proposed&trigger=snapd/proposed at the end of the retrigger url - this will cause snapd to be tested with the right systemd version | 16:38 |
| cachio | mvo, perfect | 16:38 |
| pedronis | Chipaca: the copies are cp -av afaict | 16:40 |
| Chipaca | yep, "cp", "-av", "/home/marco/snap/kubectl/303", "/home/marco/snap/kubectl/328" | 16:41 |
| pedronis | so ps should tell use which one is taking forever? | 16:41 |
| mvo | cachio: I uploaded snapd 2.31.1 to the ppa, if all goes well you should have a beta core in ~45min or so | 16:41 |
| cachio | mvo, great, thanks | 16:42 |
| pedronis | mvo: I just noticed that this bit of test mock := testutil.MockCommand(c, "kdialog", "sleep 9999999") seems to leave around the sleep | 16:43 |
| Chipaca | pedronis: it looks like the cp's finished | 16:43 |
| cachio | mvo, we need test-snapd-wayland for arm64 in edge | 16:43 |
| cachio | mvo, could you please share it to me? | 16:44 |
| cachio | tx | 16:44 |
| Chipaca | pedronis: lxd and kubectl at least, looking at the other two | 16:44 |
| marcoceppi | Chipaca: I restarted my machine and everything's fixed | 16:44 |
| Chipaca | marcoceppi: oh no | 16:45 |
| pedronis | for a bit, usually snapd will restart doing what it was doing before | 16:45 |
| marcoceppi | I mean, the changes are all flushed, and the snaps are enabled and the currect current versions | 16:45 |
| marcoceppi | ID Status Spawn Ready Summary | 16:45 |
| marcoceppi | 481 Done 2018-02-17T01:48:48Z 2018-02-20T16:39:28Z | 16:45 |
| marcoceppi | 482 Done 2018-02-19T05:32:01Z 2018-02-20T16:39:45Z Refresh snaps "lxd", "go" | 16:45 |
| marcoceppi | 483 Done 2018-02-20T16:39:41Z 2018-02-20T16:40:23Z Auto-refresh snap "core" | 16:45 |
| marcoceppi | Only problem is debug is stillenabled despite removing the environment line and restart snapd | 16:46 |
| Chipaca | marcoceppi: what's "snap tasks 481"? | 16:46 |
| marcoceppi | that was the first one that got stuck, the kubectl and kubefed one | 16:47 |
| pedronis | Chipaca: we had a bug when you refreshed some exact number of snaps the summary would come out empty | 16:47 |
| Chipaca | ah ok | 16:47 |
| Chipaca | marcoceppi: this wasn't the first time you restarted since this started, right? | 16:47 |
| pedronis | it's fixed, I don't remember what the magic number was | 16:47 |
| marcoceppi | no, this was the first time | 16:48 |
| pedronis | it was a confusion bug around go switch stmt != C switch stmt | 16:48 |
| marcoceppi | I don't like restarting, messes up my state | 16:48 |
| Chipaca | pedronis: heh | 16:48 |
| Chipaca | marcoceppi: fair enough | 16:48 |
| pedronis | Chipaca: a missing fallthough | 16:48 |
| pedronis | or something like that | 16:48 |
| Chipaca | marcoceppi: I hate losing state, and i hate problems that disappear without me learning from them | 16:48 |
| marcoceppi | I suppose I should have done so earlier; either way it seems something about sync getting stuck causing a backup | 16:48 |
| Chipaca | marcoceppi: but, you're fixed, so yay :-) | 16:48 |
| marcoceppi | hah, yes, back to work now | 16:49 |
| Chipaca | marcoceppi: does running 'sync' hang, for you? | 16:49 |
| marcoceppi | not anymore | 16:49 |
| marcoceppi | but I should have tested earlier | 16:49 |
| Chipaca | marcoceppi: was it doing so before the reboot/ | 16:49 |
| Chipaca | ? | 16:49 |
| marcoceppi | did not test that | 16:49 |
| Chipaca | ah | 16:49 |
| Chipaca | if it was, I'd start shopping for SSDs | 16:50 |
| marcoceppi | considering there were sync processes from days ago, I'm inclined to believe that may be the problem | 16:50 |
| Chipaca | but ¯\_(ツ)_/¯ | 16:50 |
| marcoceppi | hum, I don't have any smart errors | 16:51 |
| marcoceppi | but I'll start a disk copy anyways | 16:51 |
| Chipaca | marcoceppi: it might be something weirder, some corner case in the mount handling code that we're tripping up | 16:52 |
| Chipaca | marcoceppi: (we've fixed so many of those already...) | 16:52 |
| Chipaca | marcoceppi: if it ever happens again, jump on here | 16:53 |
| Chipaca | marcoceppi: glad you're unstuck, and good luck | 16:53 |
| marcoceppi | Chipaca: I'll keep an eye out - thanks! | 16:53 |
| marcoceppi | Chipaca: any way to get rid of the debug output? | 16:58 |
| === anewman_ is now known as anewman | ||
| Chipaca | marcoceppi: if should be enough to remove it from /etc/environment and restart | 16:58 |
| marcoceppi | yeah, did that :| | 16:59 |
| Chipaca | marcoceppi: but, note you'll still have it in your shell and stuff | 16:59 |
| marcoceppi | oh, yeah, it's in my shell | 16:59 |
| marcoceppi | DUH | 16:59 |
| Chipaca | marcoceppi: but systemctl shouldn't pass them to the units | 16:59 |
| Chipaca | marcoceppi: but if you're running it by hand because that's cool, then there's why | 16:59 |
| marcoceppi | I mean, it's showing in all my snap commands | 17:00 |
| marcoceppi | but because snap_debug was in my shell | 17:00 |
| marcoceppi | so unset and ready to go! | 17:00 |
| Chipaca | ah, i thought you were seeing it in the journal | 17:00 |
| Chipaca | :-) ok | 17:00 |
| mvo | jdstrand: I noticed something curious - it looks like c1093d46437a33d60d7378b1c6676818655bc359 is not in master currently, I noticed when merging back the changes from 2.31.1 | 17:02 |
| mup | PR snapd#4712 opened: release: version 2.31.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4712> | 17:02 |
| cachio | mvo, in fact I can't see where the test-snapd-wayland code is? do you know? | 17:06 |
| cachio | mvo, I found it | 17:06 |
| cachio | jdstrand, hey, we need the test-snapd-wayland for arm64 | 17:10 |
| cachio | to make autopkgtests pass | 17:11 |
| cachio | jdstrand, could you please create the snap? | 17:11 |
| * kalikiana wrapping up for the day | 17:28 | |
| mvo | cachio: i386/amd64 core 2.31.1 ready in beta | 18:14 |
| mvo | cachio: arm* should be ready in ~1h or so | 18:16 |
| mup | PR snapd#4711 closed: tests: make restore of interfaces-password-manager-service more robust <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4711> | 18:22 |
| mvo | cachio: hrm, hrm, armhf/arm64 does not give me a built slot, maybe the 1h was too optimistic - I keep an eye on things | 18:46 |
| phoenix_firebrd | what version of intel vaapi driver is present in snappy core package in stable channel | 18:50 |
| niemeyer | jdstrand: Looks like the review tools need to learn about the "adapter" field: | 18:54 |
| niemeyer | - unknown fields for app 'jmes': 'adapter' | 18:55 |
| jdstrand | niemeyer: ack, noted. I'll get that fixed | 19:01 |
| niemeyer | jdstrand: Thanks! | 19:02 |
| niemeyer | jdstrand: I just added a note to the original topic, btw: https://forum.snapcraft.io/t/telling-snapcraft-to-skip-generating-wrapper-scripts/1635 | 19:02 |
| jdstrand | thanks | 19:04 |
| niemeyer | jdstrand: Meanwhile, would you mind to unblock the review and let it through.. it's a pretty boring snap otherwise | 19:05 |
| niemeyer | strict, no interfaces, etc | 19:05 |
| jdstrand | yes, I was heading over there | 19:05 |
| niemeyer | Thanks! | 19:05 |
| jdstrand | niemeyer: done. you'll need to release it to a channel | 19:09 |
| niemeyer | jdstrand: Thanks again! | 19:09 |
| jdstrand | np :) | 19:10 |
| mvo | cachio: all arches for 2.31.1 in beta now | 19:43 |
| cachio | great, 32 and 64 bits already running | 19:43 |
| cachio | mvo, no errors so far | 19:43 |
| mvo | cachio: \o/ | 19:43 |
| mvo | cachio: 32bit is 2.31.1? I think I did something wrong with the promotion before but its correct now (sorry for that) | 19:44 |
| cachio | yes, 2.31.1 | 19:45 |
| cmars | I'm trying to use this sockets feature in a snap, doesn't seem to be supported by snapcraft. it is supported yet? https://docs.snapcraft.io/build-snaps/syntax#sockets | 20:45 |
| niemeyer | cmars: It is supported, but not with that syntax.. this documentation is out of date as of a couple of years ago :) | 20:48 |
| cmars | niemeyer: gotcha.. do you have an example of how it's supposed to look? | 20:48 |
| niemeyer | cmars: It took us a while to reimplement support for it, but it's now in.. let me provide you with something you can go forward with.. just a sec | 20:49 |
| cmars | niemeyer: awesome to hear, thanks! | 20:49 |
| niemeyer | cmars: https://github.com/snapcore/snapd/blob/master/tests/lib/snaps/socket-activation/meta/snap.yaml | 20:51 |
| cmars | trying.. | 20:52 |
| cmars | hmm | 20:53 |
| jdstrand | niemeyer: hey, so looking at adapter. this seems to be a snapcraft.yaml thing and not a snap.yaml thing. I don't see anything for processing adapter in snapd. shouldn't snapcraft remove adpater when generating snap.yaml? | 20:54 |
| cmars | snapcraft still doesn't accept it, https://paste.ubuntu.com/p/8FKdbnHmTt/ | 20:54 |
| cmars | i guess i'll open a bug? | 20:54 |
| niemeyer | jdstrand: Waaait | 20:55 |
| niemeyer | jdstrand: Yes! | 20:55 |
| niemeyer | jdstrand: Good catch.. it makes no sense to have this in snap.yaml | 20:55 |
| jdstrand | niemeyer: ok, I'll file a snapcraft bug then and follow up in the forum | 20:55 |
| niemeyer | jdstrand: Thanks! | 20:56 |
| niemeyer | cmars: :/ | 20:56 |
| niemeyer | cmars: It's been there for a few months.. let me find the topic.. | 20:57 |
| niemeyer | cmars: https://forum.snapcraft.io/t/socket-activation-support/2050 | 20:57 |
| niemeyer | cmars: Meanwhile, after you get the snap fully cooked, you can workaround the problem by changing the meta/snap.yaml in prime/ and then packing the snap | 21:09 |
| cmars | niemeyer: interesting, ok, thanks | 21:13 |
| phoenix_firebrd | how to know what version of intel vaapi driver is used in ubuntu snap core in stable channel? | 21:31 |
| popey | phoenix_firebrd: I dont believe we ship vaapi drivers in core | 21:33 |
| phoenix_firebrd | popey: so vlc snap uses driver from the host? | 21:35 |
| popey | yes | 21:36 |
| phoenix_firebrd | popey: in general how can you find the versions of software used in a core snap? | 21:36 |
| popey | it uses whatever the right driver is for the gpu | 21:36 |
| popey | that's a question for someone who works on the core snap I think | 21:36 |
| popey | (not me) | 21:37 |
| popey | (I imagine ogra_ knows) :D | 21:37 |
| popey | the yaml is probably somewhere abouts | 21:37 |
| phoenix_firebrd | popey: I patched my vaapi driver, the normal install of software reflects that, but it has no effect on the snap version of vlc | 21:37 |
| ogra_ | phoenix_firebrd, http://people.canonical.com/~ogra/core-builds/ has links to manifest files for all auto-built core snaps | 21:38 |
| phoenix_firebrd | ogra_: thanks, I will take a look at that | 21:38 |
| ogra_ | and no, i dont think vaapi from the host is used, the vlc snap definitely uses something it ships itself | 21:39 |
| ogra_ | (my laptop has no working vaapi setup yet, i can configure vlc from the snap with the vaapi driver and get accelerated playback) | 21:40 |
| ogra_ | libva info: VA-API version 0.39.0 | 21:42 |
| ogra_ | libva info: va_getDriverName() returns 0 | 21:42 |
| ogra_ | libva info: Trying to open /snap/vlc/158/usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so | 21:42 |
| ogra_ | libva info: Found init function __vaDriverInit_0_39 | 21:42 |
| ogra_ | libva info: va_openDriver() returns 0 | 21:42 |
| ogra_ | [00007f3ced0781c0] avcodec decoder: Using Intel i965 driver for Intel(R) Ivybridge Mobile - 1.7.0 for hardware decoding | 21:42 |
| ogra_ | this pretty clearly points to the in-snap driver ... | 21:43 |
| phoenix_firebrd | ogra_: vainfo from where? | 21:43 |
| ogra_ | thats simply from starting vlc in a terminal | 21:43 |
| popey | oh, it depends :) | 21:44 |
| phoenix_firebrd | ogra_: ok. can you show me a link to the manifist of this package ubuntu-core-libs | 21:44 |
| ogra_ | yeah, probably different on non-intel | 21:44 |
| popey | yeah | 21:44 |
| ogra_ | phoenix_firebrd, no, i have no idea where a manifest for the vlc snap would live | 21:44 |
| ogra_ | phoenix_firebrd, the vaapi lib is included in the vlc snap ... not anywhere in core | 21:45 |
| popey | for intel, yeah, and it builds using the 16.04 archive, so whatever is in 16.04 | 21:45 |
| ogra_ | cant be | 21:45 |
| ogra_ | the vaapi in the archive is broken | 21:45 |
| phoenix_firebrd | ogra_: thats right | 21:46 |
| ogra_ | i assume the vlc snap builds some upstream version | 21:46 |
| popey | (I made that bit of the vlc snap) | 21:46 |
| phoenix_firebrd | ogra_: who maintains the vlc snap, the vlan team or a ubuntu dev? | 21:47 |
| popey | vlc | 21:47 |
| popey | https://github.com/videolan/vlc/blob/master/extras/package/snap/snapcraft.yaml | 21:47 |
| ogra_ | $ snap info vlc|grep publisher | 21:47 |
| ogra_ | publisher: videolan | 21:47 |
| phoenix_firebrd | ogra_: it cant be an upsteam version, you version as you saw is pretty old | 21:47 |
| popey | note the libva stage packages | 21:47 |
| phoenix_firebrd | popey: the latest is version 2.1.0 | 21:47 |
| popey | the latest version of what? | 21:48 |
| phoenix_firebrd | ogra_: may be i show file a bug report to ask them to bump the version | 21:48 |
| popey | What's up with the one it ships? | 21:49 |
| phoenix_firebrd | popey: libva | 21:49 |
| * ogra_ hasnt had any issues with in on ivybridge and kybylake HW | 21:49 | |
| popey | ok, well currently it's using the one from 16.04 | 21:49 |
| phoenix_firebrd | popey: it has bug that when playing a vp9 codec video (4k videos from youtube) shows some corrupted video frames | 21:50 |
| ogra_ | i still dont get why i cant get vaapi to work at all with the archive version while vlc just bundles it and it works ... very weird | 21:50 |
| popey | phoenix_firebrd: interesting, I'd file a bug upstream in vlc | 21:50 |
| ogra_ | yeah | 21:50 |
| phoenix_firebrd | popey: niced | 21:50 |
| popey | thresh: is the maintainer of the vlc snap, maybe they can comment :) | 21:50 |
| phoenix_firebrd | nice | 21:50 |
| ogra_ | note that bumping such a version is quite some work ... (the snap would have to build a newer upstream version at build time) | 21:51 |
| phoenix_firebrd | ogra_: popey let me find the upstream bug report and the official patch , so that we can have some idea | 21:51 |
| ogra_ | note that snaps are currently bound to 16.04 versions of the dependencies they use ... | 21:53 |
| ogra_ | regardless where they are executed | 21:53 |
| ogra_ | (this is about to change in 18.04 at some point but currently it means if you want to patch a dependency it gets kind of awkward) | 21:54 |
| phoenix_firebrd | https://github.com/intel/intel-vaapi-driver/issues/297 | 21:55 |
| phoenix_firebrd | https://github.com/intel/intel-vaapi-driver/commit/9d66570032fb02b1e79a883af7697b035d700a8e | 21:55 |
| phoenix_firebrd | thats the bug report and the next is the patch | 21:56 |
| ogra_ | fun, a one liner | 21:56 |
| phoenix_firebrd | ogra_: what about in the edge channel? | 21:56 |
| phoenix_firebrd | ya | 21:56 |
| ogra_ | that has nothing to do with channels | 21:56 |
| ogra_ | snaps use deb packages ass build dependencies and as runtime deps | 21:56 |
| phoenix_firebrd | ogra_: both stable and edge are 16.04? | 21:57 |
| ogra_ | with the current design thies debs have to be 16.04 ones | 21:57 |
| ogra_ | yes | 21:57 |
| ogra_ | all snaps are 16.04 based currenty | 21:57 |
| phoenix_firebrd | I understand | 21:57 |
| ogra_ | you *can* build your deps from source | 21:57 |
| phoenix_firebrd | you mean for snaps or normal packages? | 21:58 |
| ogra_ | or you can maintain a PPA with backports of newer debs for your dependencies and hack usage of that PPA into your snapcraft.yaml | 21:58 |
| ogra_ | for snaps | 21:58 |
| ogra_ | they usually ship their dependencies ... | 21:58 |
| phoenix_firebrd | ogra_: I did that, but the point is i dont this issue to be present in 18.04 | 21:58 |
| ogra_ | if you read the snapcraft.yaml popey linked above you see "build-packages" and "stage-packages" ... these are typically 16,04 deb packages | 21:59 |
| ogra_ | yes, i understand | 21:59 |
| ogra_ | but the version in the snap is 16.04 ... unless someone backports the fix into the ubuntu archive or the vlc maintainer jumps through some hoops (build vaapi from source or backport the 18.04 version in a PPA and maintain it there ... (and hack the snapcraft.yaml of vlc to use that PPA)) | 22:00 |
| ogra_ | there is no easy solution for this atm ... | 22:01 |
| phoenix_firebrd | ok | 22:01 |
| ogra_ | the design is changing to allow newer dependencies via "base snaps" in the future (then your whole snap can be built against i.e. 18.04 but still run on 14.04 or 16.04) | 22:02 |
| ogra_ | but thats not done yet | 22:02 |
| ogra_ | so for now its a big amount of extra work for the snap packager to include such a patch | 22:02 |
| phoenix_firebrd | ok | 22:03 |
| phoenix_firebrd | what happens in case of a security patch for a dependency? | 22:03 |
| popey | the developer rebuilds the snap | 22:04 |
| popey | (or it's automatic) | 22:04 |
| phoenix_firebrd | if the core snap is rebuilt does the vlc snap for example have to be rebuilt? | 22:05 |
| ogra_ | no | 22:05 |
| phoenix_firebrd | ok | 22:05 |
| phoenix_firebrd | vlc snap is like a static executable? | 22:05 |
| ogra_ | not really :) | 22:06 |
| phoenix_firebrd | ok | 22:06 |
| ogra_ | it is a dynamically linked executable that ships all the libs it is linked against and sets a library path pointing to them | 22:06 |
| phoenix_firebrd | ogra_: understood | 22:07 |
| phoenix_firebrd | ogra_: do you know/guess what version of libva will be shipped during release of 18.04? | 22:08 |
| ogra_ | nope | 22:08 |
| ogra_ | and until there is snap support for 18.04 (beyond the 16.04 base we have today) it will still take some time | 22:09 |
| ogra_ | so for a while snaps will still be 16.04 based ... even in 18.04 ... until the base snap spec is fully implemented | 22:09 |
| ogra_ | (which will likely happen within the 18.10 timeframe) | 22:10 |
| phoenix_firebrd | ogra_: If a snap is strictly confined, is it denied of gpu access?, I read in a forum. Is that true? | 22:11 |
| ogra_ | it needs to define an interface for access | 22:11 |
| popey | https://docs.snapcraft.io/reference/interfaces | 22:11 |
| popey | there's an opengl interface | 22:12 |
| ogra_ | right | 22:12 |
| ogra_ | and an x11 one ... and a wayland one | 22:12 |
| ogra_ | (and various others) | 22:12 |
| phoenix_firebrd | popey: Its like policykit | 22:13 |
| ogra_ | lol | 22:16 |
| phoenix_firebrd | :) | 22:16 |
| ogra_ | thats quite a simplification :) | 22:16 |
| phoenix_firebrd | ogra_: Can a theme be installed to be used for snaps? | 22:18 |
| ogra_ | currently only if you ship it along with your app | 22:18 |
| ogra_ | there is work going on to solve this though ... | 22:18 |
| phoenix_firebrd | ogra_: oh o_O | 22:19 |
| phoenix_firebrd | ok | 22:19 |
| phoenix_firebrd | popey: ogra_ thanks for the support | 22:26 |
| ogra_ | np :) | 22:27 |
| popey | no problem | 22:27 |
| elopio | snappy-m-o autopkgtest 1943 xenial:armhf xenial:amd64 xenial:arm64 | 23:38 |
| snappy-m-o | elopio: I've just triggered your test. | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!