[01:40] Issue snapcraft#1816 opened: snapcraft update won't fetch from `SNAPCRAFT_PARTS_URI` [06:37] morning [06:46] mvo: hey [06:46] hey mborzecki [06:46] mborzecki: how are you? [06:47] what did I miss [06:47] good, thank you [06:47] hm the test infra is basically failing most of the time [06:47] :( [06:47] sucks [06:47] mborzecki: what about your matrix idea? was that discussed? [06:47] maybe not infra, the travis jobs are mostly failing [06:48] any pattern emerging in the failures? or all random? [06:48] 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] 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] l, [06:49] ok [06:49] and i've seen the fuse thing [06:49] i actually have a log somewhere, let me post that quickly [06:50] 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] (your matrix idea for per-distro runs in travis) [06:51] yeah, we can try that [06:52] 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] heh [06:53] thanks for fixing it [06:53] 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] PR #4404: data/selinux: allow messages from policykit [06:55] there's a PR from tyler, #4396 it'd be good to merge it once the tests are green [06:55] PR #4396: snap: use the -no-fragments mksquashfs option [07:01] mvo: https://paste.ubuntu.com/26213459/ line 9420 [07:01] i think it's from your PR btw [07:04] mborzecki: looking [07:17] 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] jdstrand: is 4406 something we should pull into the release/2.30 branch (in case there is a 2.30.1?) [07:25] 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] 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] kalikiana: maybe you have an idea -^ ? [07:29] PR snapd#4406 closed: interfaces/dbus: adjust slot policy for listen, accept and accept4 syscalls [07:45] morning [07:47] mvo: leo is on hols. kyle knows about ros [07:48] 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] mvo: they pull in packages from pip, which might've changed [07:53] * mvo nods [08:05] mborzecki: can you have a look at 4408 please? [08:06] mvo: looking [08:09] mborzecki: I guess the only interessting bit for you is the PKGBUILD change for arch [08:16] PR snapd#4408 closed: release: snapd 2.30 [08:28] mvo: i'll add a bit more debugging to the fuse interfaces problem [08:29] ta [08:39] PR snapd#4409 opened: tests/main/interfaces-fuse_support: dump more debugging information [08:48] mvo: have you seen anything like this https://api.travis-ci.org/v3/job/317950947/log.txt ? [08:51] 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] mborzecki: do you happen to know if this is reproducible ? [08:52] mborzecki: or is it a one-off thing? [08:53] 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] i'll try to run debian-sid-64 suite on linode manually, see what comes up [08:54] mborzecki: sounds good [09:48] PR snapd#4410 opened: tests: make journalctl check wait a bit for output [10:01] mvo: looks like we were looking into the same snapd-reexec test [10:05] mborzecki: yeah, my "fix" is very naive, but maybe it helps [10:06] mvo: i'm thinkgin we should probably disable all rate limit in journald as well [10:06] mborzecki: +1 for that [10:12] mborzecki: heh, my PR is breaking on interfaces-fuse_support [10:13] mborzecki: two pids [10:13] hahah [10:13] and #4409 has some extra debugs for that [10:13] PR #4409: tests/main/interfaces-fuse_support: dump more debugging information [10:13] mborzecki: but you added some debug already, right? so I should probably just merge it [10:13] mborzecki: aha, great [10:13] * mvo waits to see what else fails [10:24] 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] sergiusens: thanks and good morning [10:24] kalikiana hey I assigned a new task for you [10:24] 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] 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] there are also snapd tests in there where we install what we build [10:26] 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] sergiusens: Yup, saw it. It's on my list [10:42] mvo: can you review #4409? the build is green, so we could merge it if the change is ok [10:42] PR #4409: tests/main/interfaces-fuse_support: dump more debugging information [10:43] mborzecki: sure, nice to see its green [10:44] gnar gnar, something about reexec-ing breaks in a live session [10:44] PR snapd#4409 closed: tests/main/interfaces-fuse_support: dump more debugging information [10:45] mvo: thanks [10:45] * kalikiana coffee break [10:49] did a new core snap get released recently? [10:50] PR snapd#4411 opened: tests/lib/prepare-restore: disable rate limiting in journald [11:01] mwhudson: not recently, why? [11:02] mvo: ah, red herring i think [11:02] it's late and i'm confused :) [11:02] mwhudson: puh, ok :) [11:49] * kalikiana starting at the same code for too long without finding the problem, going for a break [12:20] PR snapd#4412 opened: tests/main/postrm-purge: stop snapd before purge and reinstall the package in restore [12:22] mvo: ^^ think this test might have left the worker in a broken state [12:26] Hellos! [12:30] niemeyer: hey [12:33] PR snapcraft#1817 opened: grammar: support strings [12:37] hey niemeyer [12:37] mvo is `environment` an ordered dict? [12:38] wondering if I can get away with that and not do variable replacements in snapcraft [12:38] 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] any comments on https://forum.snapcraft.io/t/interacting-with-dbus-daemons-app-container-feature/3245 would be appreciated [12:44] kalikiana: Hey [12:44] kalikiana: Happy to talk today after the meeting, or in the forum if you'd prefer that [12:45] mvo: if you're respinning it, sure. if you're not, it can wait if it has to [12:46] do you want me to create a 2.30 PR? [12:47] 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] 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] Okay. Thanks! [12:59] mborzecki: oh, nice [13:00] sergiusens: yeah, env should be ordered iirc [13:11] PR snapd#4412 closed: tests/main/postrm-purge: stop snapd before purge and reinstall the package in restore [13:23] 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] PR snapcraft#1807: tests: run test_cleanbuild in LXD on Travis [13:24] 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] PR snapd#4413 opened: tests/main/postrm-purge: stop snapd before purge [13:49] 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] mvo: https://paste.ubuntu.com/26215262/ empty cmdline? [14:01] sergiusens: that should work [14:01] sergiusens: I think there is even a test for this, I can look [14:01] sergiusens: but it will only resolve things top-down [14:01] mvo oh, this is great news! I will try it out; probably next year as this year is running low on time [14:01] so FOO=my-arch\nBAR=$FOO/x will work but not the other way around [14:02] mborzecki: that sounds like a race, I bet /proc/28456 does not exit anymore [14:02] mborzecki: at the point this runs [14:02] or it's a kernel thread :/ [14:03] but that shouldn't match the regex [14:04] oh, w8, not, there's no such file or directory, uhh i'm staring at the logs for too long [14:05] mborzecki: :) [14:05] mborzecki: no worries [14:27] PR snapd#4414 opened: tests/main/interfaces-fuse_support: workaround multiple matching processes [14:38] mvo, I lost the machine where I reproduced the error, I'll trying to reproduce it again and share that to you [14:39] cachio__: thank you [14:43] re [14:49] PR snapcraft#1818 opened: meta: create XDG_RUNTIME_DIR in wrappers [15:12] PR snapd#4391 closed: travis, run-checks: split travis job into build matrix [15:12] PR snapd#4393 closed: travis: separate unit tests into separate build matrix jobs [15:20] mvo: can you take a look at #4413 and #4414 later on? [15:20] PR #4413: tests/main/postrm-purge: stop snapd before purge [15:20] PR #4414: tests/main/interfaces-fuse_support: workaround multiple matching processes [15:29] snappy-m-o autopkgtest 1815 xenial:armhf [15:29] sergiusens: I've just triggered your test. [15:30] mborzecki: ssure [15:46] Issue snapcraft#1819 opened: Detect and clear executable stack binaries [15:46] mvo: Is there a way to install local .deb files with apt-get so it resolves dependencies? [15:46] mvo: It was possible with apt-rpm, but I don't recall if that ever got ported over [15:46] niemeyer apt install ./ [15:47] but the deb has to be in cwd [15:47] Sweet [15:57] niemeyer: what sergiusens said, it should not be needed to be in cwd, but apt expects an absolute path [16:02] mvo oh, abs path; I had issues with not working out of cwd in the past [16:04] 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] PR snapcraft#1820 opened: Update test_lxd.py [16:29] mvo, sergiusens: Brilliant, it worked fine, thanks! [16:33] niemeyer: ping [16:34] kalikiana: pong [16:39] niemeyer: I'll be eod'ing in 30min - can we have a quick chat still about the arch stuff? [16:40] kalikiana: I'm having a call (or trying to) with JamieBennett right now, but soon maybe [16:41] ok [16:41] btw re: arch i believe nvidia stuff is wonky there [16:41] im terrified that i might actually have to install arch [16:41] ._. [16:43] kalikiana: Jamie is having network issues and I have 8 minutes before he's ready.. want to have a quick chat? [16:44] niemeyer: yes! [16:53] ikey: I think we're talking about different things. I meant arch as in architecture( grammar in snapcraft) [16:54] like "on amd64 to armhf:" syntax [16:55] i saw arch and twitched. :p [16:59] :-D [17:16] * kalikiana wrapping up for eod in ~15min - trying to finish one more test case before heading out [17:20] PR snapd#4415 opened: Set debian-sid-64 system as manual [17:36] Alright, time to call it a day [17:36] o/ === Guest9132 is now known as daniellimws [18:31] i broke delta service: https://hastebin.com/jixayuxoki.sql [18:31] * ikey nukes deltas and uploads the old fashioned way [18:35] ikey, yeah, how dare you remove the 1 required positional argument [18:36] ikr? lol [19:00] ikey interesting [19:01] 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] 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] did this happen recently? [20:13] thomi not an emergency, happened today; I think, ikey can confirm [20:14] yeah no emergency [20:14] just nuked the deltas and went full upload [20:17] hmm, this is the second report of upload deltas breaking in the last week. [20:18] 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] PR snapcraft#1786 closed: lxd: always install squashfuse [22:00] PR snapd#4415 closed: Set debian-sid-64 system as manual [22:26] snappy-m-o autopkgtest 1815 xenial:armhf [22:26] sergiusens: I've just triggered your test.