[00:01] wililupy: you can do that at the kernel level [00:03] SamYaple: You have a link to a document/howto to configure this? [00:04] ta [00:04] moment [00:05] wililupy: http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re46.html [00:08] SamYaple: Thanks. I'll research this and see if it works. [00:09] i use it to isolate cores for dpdk myself, but its there to basically block the default scheduling unless you specifically set the process to run on that core === chihchun_afk is now known as chihchun [06:20] PR snapcraft#1802 opened: metadata: extract metadata from appstream [06:45] is it possible to reload instead of restart when upgrading a snap package? [06:45] for example when the package is nginx web server [07:02] morning [07:09] Hello, I am trying to build the 1.31 target on top of xenial base and I am hitting following error : /usr/bin/ld: cannot find -lsnapd-qt [07:09] (snapd-glib) [07:10] https://paste.kde.org/p9aqhbib5 is relevant part [08:03] snappy morning, folks [08:06] hey kalikiana, good morning! [08:17] bencc: /win 7 [08:17] oops sorry, ignore [08:37] * kalikiana coffee [08:41] sergiusens, hi, can https://github.com/snapcore/snapcraft/pull/1617 be merged now that the snapd change is in 2.30? [08:41] PR snapcraft#1617: Add options to configure applications socket activation [08:44] PR snapd#4390 opened: tests: change interfaces-fuse_support to be debug friendly [08:44] mvo: there's a conflict in #4103 [08:44] PR #4103: snapstate: auto install default-providers for content snaps [08:47] mborzecki: thanks, I fix it [08:50] btw. our tests could be used as a source of entropy for /dev/random [08:52] https://paste.ubuntu.com/26168835/, tar: /var/lib/snapd: file changed as we read it [09:00] pstolowski mvo, would you fancy reviewing #4373 ? [09:00] PR #4373: snap: app startup after/before validation [09:01] mborzecki: where do you see that tar issue? [09:03] mborzecki: we need to figure out what is causing this, it happens very sporadically. is this 14.04? or a different release/distro? [09:05] mvo: https://github.com/snapcore/snapd/pull/4285#partial-pull-merging [09:05] PR #4285: tests, spread: add Arch Linux to CI systems [09:10] mvo: i think we need to add some logging to spread [09:10] specifically, log the label of the node that the task is running on [09:18] mborzecki, sure [09:26] diddledan: seen https://github.com/snapcrafters/corebird/issues/20 ? Suspect it might be wayland issue? [09:35] mvo: do you know if we require CONFIG_USER_NS ? [09:37] Hi. Is there some snaps api that allows me to restart my snaps? Same with systemctl restart... [09:39] sborovkov: snap restart [09:42] sborovkov: systemctl restart snap.. should do the trick as well, eg. systemctl restart snap.lxd.daemon [09:43] yeah but I meant with permissions. Something I can call from my own python code. [09:43] inside the snap [09:44] I want to be able to restart some of my own services if some health check failed for instance [09:45] sborovkov, yes, it's coming with new snapd release. snaps can call snapctl start/stop/restart ... for own services [09:45] nice [09:45] thanks [09:46] sborovkov, this should become available at any moment now with 2.30.x === __chip__ is now known as Chipaca [10:00] mvo: do spread tests pass sometimes? I'm getting timeouts all the time [10:02] pedronis: linode, or the tests themselves? [10:03] Chipaca: travis timeouts, tests taking 49mins+ [10:03] aw :-( [10:07] pedronis: for snapcraft we had to restructure and split the test suite more than once to get around those timeouts [10:07] it'd be impossible to run in one go [10:08] pedronis: they do pass sometimes but things are not going well currently [10:08] Although I'd like to think it has one benefit, which is that we can retry individual steps, it is somewhat forced [10:08] pedronis: let me check if I can see anything [10:08] mborzecki: I don't know about CONFIG_USER_NS, sorry [10:09] (where we really means elopio) [10:09] mvo: we could split travis into subjobs [10:09] mvo: this is what we've got now https://github.com/snapcore/snapcraft/blob/master/.travis.yml [10:09] mborzecki: yeah, that might help [10:10] kalikiana: aha, interessting [10:10] mvo: pack each distro into a separate job [10:11] * mvo looks at the logs why things are so slow [10:14] mvo: i can look into splitig travis jobs if you're busy [10:19] we had more jobs at some point but Gustavo argued against that, so far we have just usually thrown more machines at the problem [10:24] kalikiana morning. Mind dedicating some time to review snapcraft#1793 ? [10:24] PR snapcraft#1793: project: refactor storeapi [10:25] pedronis mvo you could also rearchitecture spread so it calls back to github through a webhook with pass/fail and keep travis as the triggering mechanism only [10:26] or even trigger it through a webhook [10:26] if you do that, we will migrate to spread completely :-) [10:27] more machines when you can only run 5 instances at a time is not really going to scale [10:27] popey not sure you saw, but snapcraft#1801 would solve the docker problem [10:27] PR snapcraft#1801: lifecycle: detect docker to auto setup core [10:28] sergiusens: it was less that the issue exists, and more that we have hidden magic environment variables that are undocumented that concerned me [10:29] sergiusens: morning! I'm in the middle of a branch merge. Will check it in a few minutes when that's sorted [10:30] PR snapd#4391 opened: travis, run-checks: split travis job into build matrix [10:31] little experiment ^^ [10:32] PR snapd#4392 opened: many: refresh with appropriate creds [10:45] mborzecki: heh :) [10:45] mborzecki: the unit test job takes a long time, the other ones are really fast [10:46] mborzecki: but I would like to understand better why we are so slow [10:46] mborzecki: definitely an interessting PR [10:48] mvo: the upside is that if one distro fails whatever reason, you don't have to restart everything [10:48] and we tend to fail on the little things like this one https://paste.ubuntu.com/26169351/ [10:48] mborzecki: the other upside is that we know exactly what distro caused the timeout [10:48] mborzecki: I like it [11:01] mborzecki: *if* we move to this model, we need to adjust the number of parallel travis runs we allow. currently it is limited to three runs because we need so many machines. if we go matrix we can increase this limit quite a bit [11:12] * kalikiana short coffee break [11:16] mvo: 14.04 pushing it to 46 minutes with 13 tests still left [11:17] mvo: ideally, if unit tests are taking too long, we could split them into a separate job [11:36] mborzecki: yeah, the unit tests are interessting, they take ~10min but we want to run them in spread so that we validate the unit tests on each arch/release [11:39] mborzecki: also interessting to get the pre-distro/release breakout of the times [11:39] mvo: what i meant is that tests/unit could be put on a job run by spread, separately from other tests under tests/main or tests/regressions [11:39] mborzecki: before that was difficult to get [11:40] mborzecki: yeah, worth a shot for sure [11:40] mborzecki: do you think you could do a separate PR so that we can see the results? [11:41] sure [11:41] mborzecki: thank you [11:42] mborzecki: also the output is much easier to read (i.e. failures easier to find). I like this more and more :) [11:52] mvo, hey, I'll be 5 minutes late today [11:56] cachio: no worries [11:56] mvo: is there a way to exclude tests in spread command line? [11:59] mborzecki: not afaik, but imho there should be [12:00] mborzecki: you need to list them all ( spread $( spread list linode: | grep -v yadda ) ) [12:00] -list, not list [12:02] i'd like to run all jobs for linode:ubunt-16.04-64 but exclude tests/unit, ideally something like `spread linode:ubuntu-16.04-64 -tests/unit` [12:02] * Chipaca nods [12:03] mborzecki: but, if it's that level, you could iterate one level down [12:03] mborzecki: i mean, there's three things at that level [12:03] oh, maybe some more [12:08] mborzecki: linode:ubuntu-16.04-64:tests/{main,completion,upgrade,regression}/... should do it [12:08] Chipaca: thanks [12:08] ¯\_(ツ)_/¯ [12:09] mborzecki: i charge in reviews of gnarly code with obfuscated names [12:11] sergiusens, hi, did you see my message above? [12:12] ackk yeah, is 2.30 widespread already? [12:13] sergiusens, IDK that [12:13] ackk according to this, it seems to have only been tagged, https://forum.snapcraft.io/t/2-30-release-cycle-started/2997 [12:15] sergiusens, I see. although until that feature lands in snapcraft it's hardly going to be testable in pre-releases [12:21] ackk it should be by building from the branch; this is what I am worried about and it has already happened... if during testing something proves need changes and we release a snapcraft.yaml with what is now considered broken we need to keep that feature forever [12:22] I see [12:22] I understand that testing the feature using some build system might be a bit more complex, but it is not untestable entirely [12:35] PR snapd#4393 opened: travis: separate unit tests into separate build matrix jobs [12:57] Can I get a hand with running snapd's unit tests? Under artful, running ./run-checks --unit fails (this issue: https://forum.snapcraft.io/t/snap-seccomp-fails-tests-on-artful-is-it/2263/4) [12:57] mvo: #4393 should be running with unit tests in a separate job [12:57] PR #4393: travis: separate unit tests into separate build matrix jobs [12:58] mborzecki: cool, looking [12:58] If I run tests in a xenial chroot, I fail with a different error: http://pastebin.ubuntu.com/26169908/ [12:59] how are people running these tests? [12:59] greyback: usually just ./run-check - that should pull in things, let me look at the poastine [12:59] greyback: and we have a meeting now, so we will be a bit slow replying [13:01] greyback: make sure you have these dependencies installed https://github.com/snapcore/snapd/blob/master/tests/lib/pkgdb.sh#L347 [13:02] mvo: ack. I've always used ./run-check first, that does grab dependencies. But fails at same place in the unit tests [13:03] greyback: guessing here: did you 'sudo apt-get build-dep snapd'? [13:03] jdstrand: yep [13:04] greyback: do you have libc6-dev-i386 installed? [13:05] $ dpkg -S /usr/include/sys/cdefs.h [13:05] libc6-dev-i386: /usr/include/sys/cdefs.h [13:05] jdstrand: no, just the amd64 version. I'll try the i386 but will be mystified if it works [13:06] greyback: I installed gcc-multilib and it pulled in a few things [13:06] greyback: ./packaging/ubuntu-16.04/changelog: - snap-seccomp: run secondary-arch tests via gcc-multilib [13:07] jdstrand: aha ok. The dependency grabber will need updating to reflect that [13:07] greyback: if 'apt-get build-dep snapd' isn't getting you there, look in packaging/ubuntu-/debian/control and see if there are missing build deps that you need to install [13:08] greyback: I think the dep grabber is mostly about go deps. I'll let mvo comment further on all of this, but hopefully you are unblocked [13:08] jdstrand: I think I am, tests have progressed beyond the usual error point [13:08] thanks for that [13:09] cool [13:10] greyback: so, apt-get build-dep is quite handy and can usually get you there, the problem is it doesn't know about new changes to debian/control that might not be reflected in the archive for the deb-src lines you have configured [13:10] jdstrand: sure, I know that, I just trusted the run-checks script to pull in its dependencies [13:10] jdstrand: greyback “apt build-dep ./” works [13:11] oh, that's handy [13:11] Chipaca: oh taht's handy [13:11] Chipaca: hehe [13:11] * mvo wrote that some years ago :-D [13:11] jdstrand: greyback: hug mvo for that one [13:11] * greyback hat-tips mvo [13:11] * jdstrand hugs mvo for that one [13:11] :) [13:11] * mvo hugs greyback and jdstrand [13:13] greyback: re run-checks> yeah, it doesn't do that I suspect because it doesn't use sudo for things [13:14] greyback: run-checks could certainly be made friendlier though [13:15] or the README could say: be sure to have all the distro dependencies installed. For example, on Ubuntu run 'sudo apt-get build-dep ./' :) [13:15] jdstrand: +1 [13:17] mvo: actually, that brings up a question I have. I had trouble building trusty the other day. I moved debian/ aside and copied packaging/ubuntu-14.04 to debian/, but it still didn't work. what should I do? [13:17] mvo: now that I say that, I didn't do 'apt-get build-dep ./' in the chroot [13:17] just the dpkg-buildpackage [13:17] * jdstrand tries [13:18] I see it is a symlink [13:18] anyway, I'll play and reask [13:18] jdstrand: thanks, let me know how it goes [13:22] hmm, trusty's apt-get doesn't seem to like that [13:22] jdstrand: yeah, its old and crufty. try gdebi ./debian/control [13:25] elopio did you see my comment from yesterday about the integration tests not running from the snapcraft snap? [13:31] sergiusens: good morning! hey is there still time to fix bugs for snapcraft 2.37 before it goes out to stable? [13:32] roadmr what is the problem? [13:32] roadmr 2.37 is already released, if there is a blocker it will just not go to stable and to stay in beta/candidate instead [13:33] that said, there is still time to make it into 2.38 :-) [13:33] sergiusens: interesting... https://bugs.launchpad.net/snapcraft/+bug/1737571 is the problem (I want a poop emoji in my description dammit!) [13:33] Bug #1737571: stack trace when description or summary contain non-ascii characters [13:33] interesting that popey has not discovered that ;-) [13:34] sergiusens: I bet he uses only snoflake emojis, which mysteriously work fine [13:36] * kalikiana time for lunch! hopefully including a massive salad [13:39] hmmmmmmmm [13:39] * Chipaca needs to open a snap in a context where it's not been validated yet [13:40] but! but, i don't need to do anything dangerous with it -- it's only open in the sense that i call snap.Open() on it -- i then just need to look at its contents, a la listdir [13:42] Chipaca: hm, will you call unsquashfs -ls on it? [13:42] mvo: yes, or (*os.File).Readdir if it's a snapdir [13:43] Chipaca: *nod* [13:43] mvo: should I add knowledge of what's safe and what's unsafe to snap containers? [13:43] Chipaca: my gut feeling is yes [13:44] mine as well [13:44] but it does feel like a separate branch [13:44] mvo: I'm in an up to date trusty schroot. I ran gdebi ./debian/control then DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage and it fails. it seems like GOPATH/etc isn't setup right, but I would've expected debian/rules to do that... [13:44] jdstrand: did you ./generate-packaging-dir? [13:44] Chipaca: I am also a tiny bit uneasy about unsquashfs on untrusted content as its C and the snap comes from a user and snapd will validate it as root. or will we do the validation enitrely in snap itself at first? [13:45] Chipaca: no, I updated the symlink manually [13:45] let me try that [13:45] mvo: gnome-software would have to do it separately if it were client-side [13:45] same thing [13:45] jdstrand: yeah all that does is update the symlink [13:45] :-/ [13:45] jdstrand: did you add proposed and the ppa? [13:46] no [13:46] * jdstrand does that [13:46] jdstrand: look in tests/lib/prepare-restore.sh, if you look for ppa you'll find yourself in a 14.04 bloock [13:46] Chipaca: indeed, good point [13:46] mvo: but, agreed [13:47] mvo: in which case i can only do this check rather late (post validation) [13:47] Chipaca: tricky, I wonder if we could confine it? [13:47] Chipaca: \o/ [13:47] Chipaca: thats fine then [13:47] mvo: OTOH I can do it earlier for local files [13:47] so that should get rid of the most egregious whoopsies [13:48] Chipaca: sounds good [13:48] k [13:49] jdstrand: I don't know how much of that is necessary (i'm sure it was at some point), but i know that with all that it builds [13:49] (as i was going over that repeatedly last week) [13:56] jdstrand: re trusty> one slightly tricky thing is that you need the go-deps in vendor/ to build the package and for that you need the GOPATH so that govendor can update your vendor/ subdir [13:56] jdstrand: does that make sense? [13:57] jdstrand: this makes building a deb from git slightly harder as it expects to be in a valid GOPAHT [14:01] Chipaca: where do you need to open a snap? we are very careful about where we do that or not? [14:01] pedronis: yes, we are [14:01] Chipaca: I don't see the win or opening an unvalidated snap to check if the exec bits are right [14:02] we should assume the store the did job no? so if we are late it's wrong well too bad (it should be rare) [14:02] pedronis: it's late enough that it ends up in errors.u.c [14:02] pedronis: but, i can run it earlier for local snaps [14:02] Chipaca: do we really send to errors.u.c for local snap? [14:02] maybe that is the problem [14:02] pedronis: so that's good enough (that's what i concluded from the discussion with mvo) [14:02] pedronis: yes we do [14:03] seems wrong [14:03] we should stop to do that [14:03] pedronis: perhaps :-) [14:03] i'm trying to not branch this branch any further though :-) [14:03] i'll look into that next, then [14:05] PR snapd#4386 closed: release: 2.30.rc3 [14:12] popey: is there a snap in the store you know of with the wrong permissions bug? [14:20] no, it's a private snap [14:20] PR snapd#4394 opened: snap: give the snap.Container interface a Walk method [14:20] ok i split the checker into the walker (^^) and the snapstate thing that uses this. Still adding tests to the latter, and it splits cleanly. [14:20] popey: ah well, nm [14:27] Chipaca, mvo: ok, so the issue seemed to be that I didn't have the trusty build directory down in GOPATH and I needed to run 'govendor sync'. I was surprised that I needed to do that-- I was thinking it would act like 'apt-get source snapd ; cd snapd-* ; dpkg-buildpackage" [14:27] jdstrand: unfortunately not from a git checkout as we do not store all the vendor/ deps in git [14:27] ah [14:28] jdstrand: the go devs are aware how nasty it is that go needs this faffing around and intend to fix it someday [14:28] they haven't said if that comes before or after generics :-) [14:28] mvo: so the fact that I ran govendor sync within a trusty chroot (but shared HOME), is that going to mess with my normal xenial schroot builds (that uses the same GOPATH in HOME)? [14:32] I think I'll just make a note to rm -rf $GOPATH/pkg and govendor sync after to be 100% sure [14:35] @popey Hey! mind taking a look at https://github.com/snapcrafters/android-studio/pull/9 ? [14:35] PR snapcrafters/android-studio#9: Ship packages required to run emulator [14:35] jdstrand: it should not mess up your pkgdir because it should only install into ./vendor [14:36] mvo: ah, good to know [14:36] jdstrand: ps GOPATH is a path... "${GOPATH%%:*}/pkg" if you're putting that in a script [14:37] Chipaca: ack [14:38] re [14:40] popey flexiondotorg where is the repo for vscode? [14:40] or the snapcraft.yaml that makes the vscode of today a thing [14:40] https://code.launchpad.net/~flexiondotorg/+junk/snap-vscode [14:41] New version pushed to edge yesterday, [14:41] PR snapd#4395 opened: update HACKING.md for distro build dependencies [14:41] mvo, greyback: fyi, ^ [14:41] om26er: looking [14:42] I didn't do anything for trusty there [14:42] just the apt-get build-dep ./ bit [14:43] jdstrand: apt-get doesn't have build-dep ./ [14:43] jdstrand: that's apt [14:43] it worked here [14:43] … oh [14:43] * Chipaca looks [14:43] I just tested it in a xenial chroot [14:43] * jdstrand tries again [14:43] dang [14:43] yes, it works with apt-get [14:43] wichcraft [14:44] heh [14:45] jdstrand: thanks for this [14:49] mvo: fyi, I passed along 'apt-get build-dep ./'. that is super cool :) [14:49] it's the little things in life... [14:49] flexiondotorg oh, launchpad, that's why I couldn't find it :-) [14:49] flexiondotorg I want to test getting rid of your LD_LIBRARY_PATHS in there [14:49] with the latest snapcraft in beta [14:50] jdstrand: thanks! [14:50] OK, So if I push the current edge to stable we cam play in edge? [14:50] We'll also need to feed this back up to the ISVs creating classic snaps, right? [15:10] sergiusens: I think we lost somewhere the SNAPCRAFT_FROM_INSTALLED=1 env var. Do you want to add it in your PR, or should I do one just for that? [15:11] elopio might have been lost since that refactor, please create a PR, also remove the installation of requirements.txt and all the apt dependencies [15:12] unless they are needed to satisfy requirements-devel for the test runner [15:12] sergiusens: ah, no, not true. It's just hardcoded a little deep: https://github.com/snapcore/snapcraft/blob/master/tools/travis/run_lxd_container.sh#L56 [15:22] sergiusens: from the log of your execution: snapcraft 2.37+git5.65eb587 installed. That's the right commit. And the call that fails is ['snapcraft', '-d', 'prime'] [15:23] we are not installing the sources anytime. And the container doesn't have the snapcraft deb preinstalled. [15:23] are you sure the only way this could fail is if snapcraft is not being run from the snap built from the pr? [15:41] jdstrand: if you have a moment for 4381 that would be great. its hopefully super trivial to review [15:45] mvo: done [15:45] jdstrand: ta [15:46] PR snapd#4381 closed: interfaces: add /proc/partitions to system-observe [15:48] elopio http://pastebin.ubuntu.com/26170868/, I will add that to the debug line, if it False, we are certainly not running from the snap [15:55] Bug #1636540 changed: please support creating pipes via mknod [16:10] Bug #1617275 changed: the home interface doesn't allow access to $HOME/snap-confine [16:22] Bug #1725208 changed: missing interface to exec cc [16:25] Bug #1612759 changed: fchown system call is blocked by seccomp under confinement [16:28] Bug #1636229 changed: getpwnam() and parsing /etc/passwd gives wrong value for HOME to snaps [16:34] oh my, just fixed all the ifacestate tests for autoconnect changes hoping that's mostly it, but snapstate tests have 10x more failures :/. fun [16:39] hmm is there known outage of the store services? my `snapcraft push` times out after trying to process the delta for 60s) [16:43] * Saviq clears cache to force a full upload [16:48] hi [16:48] daniellimws: hi [16:49] roadmr: hey, I'm looking at bug #1737571. Sergio said you might be working on it, is that true? I don't want to duplicate your work :) [16:49] Bug #1737571: stack trace when description or summary contain non-ascii characters [16:49] Hey there daniellimws, thanks for joining! [16:49] thanks for inviting :) [16:50] sergiusens, elopio there's your man ^ [16:52] elopio: oh no :) I just filed it [16:53] elopio: I filed it because we found it while tinkering with metadata but I think it's something unrelated, because it happens when building a snap with weird chars in the snapcraft.yaml [16:53] elopio: there was also a unicode-related bug in the store (https://bugs.launchpad.net/snapstore/+bug/1737566) but we have a fix for that [16:53] elopio: so tl;dr not really working on it, sorry :( if you could that'd be swell [16:56] roadmr: I will try to fix it this week. [16:56] thanks elopio! [16:56] daniellimws: hey, I am wondering if you are ready for a new task, I have one that might interest you [16:56] yea i think my current one should be done soon [16:56] snapd#4394 is green, if anybody is looking for something to poke at [16:56] PR #4394: snap: give the snap.Container interface a Walk method [16:56] the problem is that it's abandoned, and I don't know how to recover it. kyrofa do you know? [16:56] running the test cases now [16:57] *running them locally [16:57] elopio, huh. Let me look [16:57] kyrofa: https://codein.withgoogle.com/dashboard/task-instances/6180198217154560/ [16:57] mvo, we have 2.30 in candidate [16:57] ah i wanted to work on this but couldnt find it [16:58] well, actually it's better that it's blocked. That way nobody can take it while we review your current PR [16:58] Dangit this codein site is so annoying... it keeps taking my primary account, and doesn't support switching. sergiusens I think that's why google has been broken for us lately [16:58] elopio: haha that's great. and I still have a beginner task to spare [16:58] daniellimws: here's the description: http://paste.ubuntu.com/26171261/ Please let me know if it sounds fun to you [16:59] sergiusens: who's our travel authorizer? Mark? [16:59] elopio: i recall there was also a task about snapcraft stats, but its not there now. Has anyone done it? [17:00] daniellimws: yes, the one about stats is done: https://github.com/elopio/random-scripts/pull/1 [17:00] PR elopio/random-scripts#1: Add gathering data from github [17:00] elopio, we can add another instance easily [17:00] elopio, but you're right, let's wait until daniellimws is ready [17:06] kyrofa: sergiusens: elopio: shared the minutes. I decided to go for fairly verbose in a couple of sections, which I hope you find useful, though if you think it's too much detail just let me know what you'd prefer [17:08] hey daniellimws! [17:09] I see you already saw my comments on #1793 - I'm wrapping up for the day, but I'll give it another look in the morning (for me it's dinner time) [17:09] PR #1793: asserts: initial support to generate/sign snap-build assertions [17:09] bah [17:09] I meant snapcraft#1793 [17:09] PR snapcraft#1793: project: refactor storeapi [17:10]