[01:40] <mup> Issue snapcraft#1816 opened: snapcraft update won't fetch from `SNAPCRAFT_PARTS_URI` <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1816>
[06:37] <mborzecki> morning
[06:46] <mborzecki> mvo: hey
[06:46] <mvo> hey mborzecki
[06:46] <mvo> mborzecki: how are you?
[06:47] <mvo> what did I miss
[06:47] <mborzecki> good, thank you
[06:47] <mborzecki> hm the test infra is basically failing most of the time
[06:47] <mvo> :(
[06:47] <mvo> sucks
[06:47] <mvo> mborzecki: what about your matrix idea? was that discussed?
[06:47] <mborzecki> maybe not infra, the travis jobs are mostly failing
[06:48] <mvo> any pattern emerging in the failures? or all random?
[06:48] <mborzecki> looks mostly random, i've seen the bug when we try to rm -rf /var/lib/snapd and we get device or resoruce busy
[06:49] <mborzecki> also the bug when we tar some content under /var/lib/snap (or /snap?) and tar complains that the contents got changed while it was working
[06:49] <mvo> l,
[06:49] <mvo> ok
[06:49] <mborzecki> and i've seen the fuse thing
[06:49] <mborzecki> i actually have a log somewhere, let me post that quickly
[06:50] <mvo> hrm, hrm, sounds like a good focus for the rest of the week then, trying to stabelize things again. I'm also keen to discuss the matrix idea with gustavo
[06:50] <mvo> (your matrix idea for per-distro runs in travis)
[06:51] <mborzecki> yeah, we can try that
[06:52] <mborzecki> other than that, there was a silly thing with featured snaps in `snap search --section=database`, the output changed and the tests started failing, the test got fixed
[06:53] <mvo> heh
[06:53] <mvo> thanks for fixing it
[06:53] <mborzecki> also there was a thing with selinux on fedora, dbus silently dropping reply messages from polkit to snapd due to selinux policy, i have a PR open #4404, but i've restarted the travis job like 5 times already, no success
[06:53] <mup> PR #4404: data/selinux: allow messages from policykit <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4404>
[06:55] <mborzecki> there's a PR from tyler, #4396 it'd be good to merge it once the tests are green
[06:55] <mup> PR #4396: snap: use the -no-fragments mksquashfs option <Created by tyhicks> <https://github.com/snapcore/snapd/pull/4396>
[07:01] <mborzecki> mvo: https://paste.ubuntu.com/26213459/ line 9420
[07:01] <mborzecki> i think it's from your PR btw
[07:04] <mvo> mborzecki: looking
[07:17] <mvo> mborzecki: interessting, lots of PIDs hanging around, but that should give us some ideas for a fix hopefully, or at least how to debug further
[07:20] <mvo> jdstrand: is 4406 something we should pull into the release/2.30 branch (in case there is a 2.30.1?)
[07:25] <mvo> elopio: hey, if you are around, do you have an idea about the regressions in http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#snapd for snapcraft? afaict it fails with snapcraft.internal.errors.SnapcraftPartConflictError: Parts 'python-part' and 'catkin-part' have the following file paths in common which have different contents"
[07:26] <mvo> elopio: but it passed on "2017-11-23 21:29:41 UTC" in autopkgtest. did the part change out-of-band? i.e. does it come from an external resource?
[07:26] <mvo> kalikiana: maybe you have an idea -^ ?
[07:29] <mup> PR snapd#4406 closed: interfaces/dbus: adjust slot policy for listen, accept and accept4 syscalls <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4406>
[07:45] <kalikiana> morning
[07:47] <kalikiana> mvo: leo is on hols. kyle knows about ros
[07:48] <mvo> kalikiana: a bit of a meta question is if these parts change outside of the deb - I guess the answer is yes? which would explain why things worked ~4 weeks ago and stopped today(?)
[07:51] <kalikiana> mvo: they pull in packages from pip, which might've changed
[07:53]  * mvo nods
[08:05] <mvo> mborzecki: can you have a look at 4408 please?
[08:06] <mborzecki> mvo: looking
[08:09] <mvo> mborzecki: I guess the only interessting bit for you is the PKGBUILD change for arch
[08:16] <mup> PR snapd#4408 closed: release: snapd 2.30 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4408>
[08:28] <mborzecki> mvo: i'll add a bit more debugging to the fuse interfaces problem
[08:29] <mvo> ta
[08:39] <mup> PR snapd#4409 opened: tests/main/interfaces-fuse_support: dump more debugging information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4409>
[08:48] <mborzecki> mvo: have you seen anything like this https://api.travis-ci.org/v3/job/317950947/log.txt ?
[08:51] <mvo> mborzecki: you mean "internal error, please report: running "test-snapd-tools.echo" failed: cannot find installed snap "test-snapd-tools" at revision 6" ? and friends? I saw it this morning, have not seen it before. its slightly strange
[08:52] <mvo> mborzecki: do you happen to know if this is reproducible ?
[08:52] <mvo> mborzecki: or is it a one-off thing?
[08:53] <mborzecki> don't know, i've restarted this build a couple of times already, each time it's failing with somethig, but i have not coollected the logs from each run
[08:54] <mborzecki> i'll try to run debian-sid-64 suite on linode manually, see what comes up
[08:54] <mvo> mborzecki: sounds good
[09:48] <mup> PR snapd#4410 opened: tests: make journalctl check wait a bit for output <Created by mvo5> <https://github.com/snapcore/snapd/pull/4410>
[10:01] <mborzecki> mvo: looks like we were looking into the same snapd-reexec test
[10:05] <mvo> mborzecki: yeah, my "fix" is very naive, but maybe it helps
[10:06] <mborzecki> mvo: i'm thinkgin we should probably disable all rate limit in journald as well
[10:06] <mvo> mborzecki: +1 for that
[10:12] <mvo> mborzecki: heh, my PR is breaking on interfaces-fuse_support
[10:13] <mvo> mborzecki: two pids
[10:13] <mborzecki> hahah
[10:13] <mborzecki> and #4409 has some extra debugs for that
[10:13] <mup> PR #4409: tests/main/interfaces-fuse_support: dump more debugging information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4409>
[10:13] <mvo> mborzecki: but you added some debug already, right? so I should probably just merge it
[10:13] <mvo> mborzecki: aha, great
[10:13]  * mvo waits to see what else fails
[10:24] <sergiusens> mvo that regression you mention in the tests is something kyrofa fixed/looked at, I don't recall right now though. It is not about pip, but ros uses its own archive
[10:24]  * sergiusens waves
[10:24] <mvo> sergiusens: thanks and good morning
[10:24] <sergiusens> kalikiana hey I assigned a new task for you
[10:24] <mvo> sergiusens: the important part (to me) is that its not caused by snapd :) so I will ask the sru team to ignore this failure
[10:25] <sergiusens> mvo no it is not :-) You should only worry really bad if any of the ones using build-snaps or lxd/cleanbuild fail :-)
[10:25] <sergiusens> there are also snapd tests in there where we install what we build
[10:26] <sergiusens> it would be great if we could add filters to adt depending on the rev dep being tested to only run what is relevant :-)
[10:26] <kalikiana> sergiusens: Yup, saw it.  It's on my list
[10:42] <mborzecki> mvo: can you review #4409? the build is green, so we could merge it if the change is ok
[10:42] <mup> PR #4409: tests/main/interfaces-fuse_support: dump more debugging information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4409>
[10:43] <mvo> mborzecki: sure, nice to see its green
[10:44] <mwhudson> gnar gnar, something about reexec-ing breaks in a live session
[10:44] <mup> PR snapd#4409 closed: tests/main/interfaces-fuse_support: dump more debugging information <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4409>
[10:45] <mborzecki> mvo: thanks
[10:45]  * kalikiana coffee break
[10:49] <mwhudson> did a new core snap get released recently?
[10:50] <mup> PR snapd#4411 opened: tests/lib/prepare-restore: disable rate limiting in journald <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4411>
[11:01] <mvo> mwhudson: not recently, why?
[11:02] <mwhudson> mvo: ah, red herring i think
[11:02] <mwhudson> it's late and i'm confused :)
[11:02] <mvo> mwhudson: puh, ok :)
[11:49]  * kalikiana starting at the same code for too long without finding the problem, going for a break
[12:20] <mup> PR snapd#4412 opened: tests/main/postrm-purge: stop snapd before purge and reinstall the package in restore <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4412>
[12:22] <mborzecki> mvo: ^^ think this test might have left the worker in a broken state
[12:26] <niemeyer> Hellos!
[12:30] <mborzecki> niemeyer: hey
[12:33] <mup> PR snapcraft#1817 opened: grammar: support strings <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1817>
[12:37] <kalikiana> hey niemeyer
[12:37] <sergiusens> mvo is `environment` an ordered dict?
[12:38] <sergiusens> wondering if I can get away with that and not do variable replacements in snapcraft
[12:38] <sergiusens> it is not a big problem if it is not (aside from ordered it would need to apply the entries in a stepped manner too)
[12:38] <jamesh> any comments on https://forum.snapcraft.io/t/interacting-with-dbus-daemons-app-container-feature/3245 would be appreciated
[12:44] <niemeyer> kalikiana: Hey
[12:44] <niemeyer> kalikiana: Happy to talk today after the meeting, or in the forum if you'd prefer that
[12:45] <jdstrand> mvo: if you're respinning it, sure. if you're not, it can wait if it has to
[12:46] <jdstrand> do you want me to create a 2.30 PR?
[12:47] <kalikiana> niemeyer: Cool! I'd say have a look at the forum first, and see if it's clear enough. If more context is needed we can have a quick hangout about it
[12:49] <niemeyer> kalikiana: Okay, let me look into the forum and respond first.. we can have a call later today if there's still a need
[12:49] <kalikiana> Okay. Thanks!
[12:59] <mvo> mborzecki: oh, nice
[13:00] <mvo> sergiusens: yeah, env should be ordered iirc
[13:11] <mup> PR snapd#4412 closed: tests/main/postrm-purge: stop snapd before purge and reinstall the package in restore <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4412>
[13:23] <kalikiana> sergiusens: FYI I added more details to snapcraft#1807 wrt patchelf; I'm running the tests locally to verify if test_container_builds also passes
[13:23] <mup> PR snapcraft#1807: tests: run test_cleanbuild in LXD on Travis <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1807>
[13:24] <kalikiana> will be going for lunch in ~10, let's see if the tests can pass before I leave
[13:37]  * kalikiana will go have lunch, back in ~1 hour
[13:38] <mup> PR snapd#4413 opened: tests/main/postrm-purge: stop snapd before purge <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4413>
[13:49] <sergiusens> mvo but is each processed individually and applied? As in, if I have FOO=my-arch and the next entry is LD_LIBRARY_PATH=$SNAP/lib/$FOO, will that work?
[14:01] <mborzecki> mvo: https://paste.ubuntu.com/26215262/ empty cmdline?
[14:01] <mvo> sergiusens: that should work
[14:01] <mvo> sergiusens: I think there is even a test for this, I can look
[14:01] <mvo> sergiusens: but it will only resolve things top-down
[14:01] <sergiusens> mvo oh, this is great news! I will try it out; probably next year as this year is running low on time
[14:01] <mvo> so FOO=my-arch\nBAR=$FOO/x will work but not the other way around
[14:02] <mvo> mborzecki: that sounds like a race, I bet /proc/28456 does not exit anymore
[14:02] <mvo> mborzecki: at the point this runs
[14:02] <mborzecki> or it's a kernel thread :/
[14:03] <mborzecki> but that shouldn't match the regex
[14:04] <mborzecki> oh, w8, not, there's no such file or directory, uhh i'm staring at the logs for too long
[14:05] <mvo> mborzecki: :)
[14:05] <mvo> mborzecki: no worries
[14:27] <mup> PR snapd#4414 opened: tests/main/interfaces-fuse_support: workaround multiple matching processes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4414>
[14:38] <cachio__> mvo, I lost the machine where I reproduced the error, I'll trying to reproduce it again and share that to you
[14:39] <mvo> cachio__: thank you
[14:43] <kalikiana> re
[14:49] <mup> PR snapcraft#1818 opened: meta: create XDG_RUNTIME_DIR in wrappers <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1818>
[15:12] <mup> PR snapd#4391 closed: travis, run-checks: split travis job into build matrix <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4391>
[15:12] <mup> PR snapd#4393 closed: travis: separate unit tests into separate build matrix jobs <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4393>
[15:20] <mborzecki> mvo: can you take a look at #4413 and #4414 later on?
[15:20] <mup> PR #4413: tests/main/postrm-purge: stop snapd before purge <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4413>
[15:20] <mup> PR #4414: tests/main/interfaces-fuse_support: workaround multiple matching processes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4414>
[15:29] <sergiusens> snappy-m-o autopkgtest 1815 xenial:armhf
[15:29] <snappy-m-o> sergiusens: I've just triggered your test.
[15:30] <mvo> mborzecki: ssure
[15:46] <mup> Issue snapcraft#1819 opened: Detect and clear executable stack binaries <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1819>
[15:46] <niemeyer> mvo: Is there a way to install local .deb files with apt-get so it resolves dependencies?
[15:46] <niemeyer> mvo: It was possible with apt-rpm, but I don't recall if that ever got ported over
[15:46] <sergiusens> niemeyer apt install ./<deb>
[15:47] <sergiusens> but the deb has to be in cwd
[15:47] <niemeyer> Sweet
[15:57] <mvo> niemeyer: what sergiusens said, it should not be needed to be in cwd, but apt expects an absolute path
[16:02] <sergiusens> mvo oh, abs path; I had issues with not working out of cwd in the past
[16:04] <mvo> sergiusens: hm, that might be a bug, the rule is basicly it needs to look like a path so that it is distinguishable (in principle) from a deb from the archive
[16:19] <mup> PR snapcraft#1820 opened: Update test_lxd.py <Created by heesen3> <https://github.com/snapcore/snapcraft/pull/1820>
[16:29] <niemeyer> mvo, sergiusens: Brilliant, it worked fine, thanks!
[16:33] <kalikiana> niemeyer: ping
[16:34] <niemeyer> kalikiana: pong
[16:39] <kalikiana> niemeyer: I'll be eod'ing in 30min - can we have a quick chat still about the arch stuff?
[16:40] <niemeyer> kalikiana: I'm having a call (or trying to) with JamieBennett right now, but soon maybe
[16:41] <kalikiana> ok
[16:41] <ikey> btw re: arch i believe nvidia stuff is wonky there
[16:41] <ikey> im terrified that i might actually have to install arch
[16:41] <ikey> ._.
[16:43] <niemeyer> kalikiana: Jamie is having network issues and I have 8 minutes before he's ready.. want to have a quick chat?
[16:44] <kalikiana> niemeyer: yes!
[16:53] <kalikiana> ikey: I think we're talking about different things. I meant arch as in architecture( grammar in snapcraft)
[16:54] <kalikiana> like "on amd64 to armhf:" syntax
[16:55] <ikey> i saw arch and twitched. :p
[16:59] <kalikiana> :-D
[17:16]  * kalikiana wrapping up for eod in ~15min - trying to finish one more test case before heading out
[17:20] <mup> PR snapd#4415 opened: Set debian-sid-64 system as manual <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4415>
[17:36] <kalikiana> Alright, time to call it a day
[17:36] <kalikiana> o/
[18:31] <ikey> i broke delta service: https://hastebin.com/jixayuxoki.sql
[18:31]  * ikey nukes deltas and uploads the old fashioned way
[18:35] <kyrofa> ikey, yeah, how dare you remove the 1 required positional argument
[18:36] <ikey> ikr? lol
[19:00] <sergiusens> ikey interesting
[19:01] <sergiusens> thomi whose in charge of deltas these days https://hastebin.com/jixayuxoki.sql (on one side I want to understand the error on the other update snapcraft to handle the error message better)
[19:04] <thomi> sergiusens: blr is the person you want for upload deltas, but if it's an emergency I can probably do some digging for you
[19:04] <thomi> did this happen recently?
[20:13] <sergiusens> thomi not an emergency, happened today; I think, ikey can confirm
[20:14] <ikey> yeah no emergency
[20:14] <ikey> just nuked the deltas and went full upload
[20:17] <thomi> hmm, this is the second report of upload deltas breaking in the last week.
[20:18] <thomi> I know blr looked in to the last report, but I don't know what he found (he's on holiday ATM, so I can't ask him)
[21:11] <mup> PR snapcraft#1786 closed: lxd: always install squashfuse <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1786>
[22:00] <mup> PR snapd#4415 closed: Set debian-sid-64 system as manual <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4415>
[22:26] <sergiusens> snappy-m-o autopkgtest 1815 xenial:armhf
[22:26] <snappy-m-o> sergiusens: I've just triggered your test.