| SamYaple | wililupy: you can do that at the kernel level | 00:01 |
|---|---|---|
| wililupy | SamYaple: You have a link to a document/howto to configure this? | 00:03 |
| SamYaple | ta | 00:04 |
| SamYaple | moment | 00:04 |
| SamYaple | wililupy: http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re46.html | 00:05 |
| wililupy | SamYaple: Thanks. I'll research this and see if it works. | 00:08 |
| SamYaple | 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 | 00:09 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapcraft#1802 opened: metadata: extract metadata from appstream <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1802> | 06:20 |
| bencc | is it possible to reload instead of restart when upgrading a snap package? | 06:45 |
| bencc | for example when the package is nginx web server | 06:45 |
| mborzecki | morning | 07:02 |
| bshah | 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 |
| bshah | (snapd-glib) | 07:09 |
| bshah | https://paste.kde.org/p9aqhbib5 is relevant part | 07:10 |
| kalikiana | snappy morning, folks | 08:03 |
| mvo | hey kalikiana, good morning! | 08:06 |
| SamYaple | bencc: /win 7 | 08:17 |
| SamYaple | oops sorry, ignore | 08:17 |
| * kalikiana coffee | 08:37 | |
| ackk | sergiusens, hi, can https://github.com/snapcore/snapcraft/pull/1617 be merged now that the snapd change is in 2.30? | 08:41 |
| mup | PR snapcraft#1617: Add options to configure applications socket activation <Created by albertodonato> <https://github.com/snapcore/snapcraft/pull/1617> | 08:41 |
| mup | PR snapd#4390 opened: tests: change interfaces-fuse_support to be debug friendly <Created by mvo5> <https://github.com/snapcore/snapd/pull/4390> | 08:44 |
| mborzecki | mvo: there's a conflict in #4103 | 08:44 |
| mup | PR #4103: snapstate: auto install default-providers for content snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4103> | 08:44 |
| mvo | mborzecki: thanks, I fix it | 08:47 |
| mborzecki | btw. our tests could be used as a source of entropy for /dev/random | 08:50 |
| mborzecki | https://paste.ubuntu.com/26168835/, tar: /var/lib/snapd: file changed as we read it | 08:52 |
| mborzecki | pstolowski mvo, would you fancy reviewing #4373 ? | 09:00 |
| mup | PR #4373: snap: app startup after/before validation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4373> | 09:00 |
| mvo | mborzecki: where do you see that tar issue? | 09:01 |
| mvo | mborzecki: we need to figure out what is causing this, it happens very sporadically. is this 14.04? or a different release/distro? | 09:03 |
| mborzecki | mvo: https://github.com/snapcore/snapd/pull/4285#partial-pull-merging | 09:05 |
| mup | PR #4285: tests, spread: add Arch Linux to CI systems <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4285> | 09:05 |
| mborzecki | mvo: i think we need to add some logging to spread | 09:10 |
| mborzecki | specifically, log the label of the node that the task is running on | 09:10 |
| pstolowski | mborzecki, sure | 09:18 |
| popey | diddledan: seen https://github.com/snapcrafters/corebird/issues/20 ? Suspect it might be wayland issue? | 09:26 |
| mborzecki | mvo: do you know if we require CONFIG_USER_NS ? | 09:35 |
| sborovkov | Hi. Is there some snaps api that allows me to restart my snaps? Same with systemctl restart... | 09:37 |
| mborzecki | sborovkov: snap restart <service-name> | 09:39 |
| mborzecki | sborovkov: systemctl restart snap.<snapname>.<app> should do the trick as well, eg. systemctl restart snap.lxd.daemon | 09:42 |
| sborovkov | yeah but I meant with permissions. Something I can call from my own python code. | 09:43 |
| sborovkov | inside the snap | 09:43 |
| sborovkov | I want to be able to restart some of my own services if some health check failed for instance | 09:44 |
| pstolowski | sborovkov, yes, it's coming with new snapd release. snaps can call snapctl start/stop/restart ... for own services | 09:45 |
| sborovkov | nice | 09:45 |
| sborovkov | thanks | 09:45 |
| pstolowski | sborovkov, this should become available at any moment now with 2.30.x | 09:46 |
| === __chip__ is now known as Chipaca | ||
| pedronis | mvo: do spread tests pass sometimes? I'm getting timeouts all the time | 10:00 |
| Chipaca | pedronis: linode, or the tests themselves? | 10:02 |
| pedronis | Chipaca: travis timeouts, tests taking 49mins+ | 10:03 |
| Chipaca | aw :-( | 10:03 |
| kalikiana | pedronis: for snapcraft we had to restructure and split the test suite more than once to get around those timeouts | 10:07 |
| kalikiana | it'd be impossible to run in one go | 10:07 |
| mvo | pedronis: they do pass sometimes but things are not going well currently | 10:08 |
| kalikiana | Although I'd like to think it has one benefit, which is that we can retry individual steps, it is somewhat forced | 10:08 |
| mvo | pedronis: let me check if I can see anything | 10:08 |
| mvo | mborzecki: I don't know about CONFIG_USER_NS, sorry | 10:08 |
| kalikiana | (where we really means elopio) | 10:09 |
| mborzecki | mvo: we could split travis into subjobs | 10:09 |
| kalikiana | mvo: this is what we've got now https://github.com/snapcore/snapcraft/blob/master/.travis.yml | 10:09 |
| mvo | mborzecki: yeah, that might help | 10:09 |
| mvo | kalikiana: aha, interessting | 10:10 |
| mborzecki | mvo: pack each distro into a separate job | 10:10 |
| * mvo looks at the logs why things are so slow | 10:11 | |
| mborzecki | mvo: i can look into splitig travis jobs if you're busy | 10:14 |
| pedronis | 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:19 |
| sergiusens | kalikiana morning. Mind dedicating some time to review snapcraft#1793 ? | 10:24 |
| mup | PR snapcraft#1793: project: refactor storeapi <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1793> | 10:24 |
| sergiusens | 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:25 |
| sergiusens | or even trigger it through a webhook | 10:26 |
| sergiusens | if you do that, we will migrate to spread completely :-) | 10:26 |
| sergiusens | more machines when you can only run 5 instances at a time is not really going to scale | 10:27 |
| sergiusens | popey not sure you saw, but snapcraft#1801 would solve the docker problem | 10:27 |
| mup | PR snapcraft#1801: lifecycle: detect docker to auto setup core <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1801> | 10:27 |
| popey | sergiusens: it was less that the issue exists, and more that we have hidden magic environment variables that are undocumented that concerned me | 10:28 |
| kalikiana | sergiusens: morning! I'm in the middle of a branch merge. Will check it in a few minutes when that's sorted | 10:29 |
| mup | PR snapd#4391 opened: travis, run-checks: split travis job into build matrix <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4391> | 10:30 |
| mborzecki | little experiment ^^ | 10:31 |
| mup | PR snapd#4392 opened: many: refresh with appropriate creds <Created by pedronis> <https://github.com/snapcore/snapd/pull/4392> | 10:32 |
| mvo | mborzecki: heh :) | 10:45 |
| mvo | mborzecki: the unit test job takes a long time, the other ones are really fast | 10:45 |
| mvo | mborzecki: but I would like to understand better why we are so slow | 10:46 |
| mvo | mborzecki: definitely an interessting PR | 10:46 |
| mborzecki | mvo: the upside is that if one distro fails whatever reason, you don't have to restart everything | 10:48 |
| mborzecki | and we tend to fail on the little things like this one https://paste.ubuntu.com/26169351/ | 10:48 |
| mvo | mborzecki: the other upside is that we know exactly what distro caused the timeout | 10:48 |
| mvo | mborzecki: I like it | 10:48 |
| mvo | 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:01 |
| * kalikiana short coffee break | 11:12 | |
| mborzecki | mvo: 14.04 pushing it to 46 minutes with 13 tests still left | 11:16 |
| mborzecki | mvo: ideally, if unit tests are taking too long, we could split them into a separate job | 11:17 |
| mvo | 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:36 |
| mvo | mborzecki: also interessting to get the pre-distro/release breakout of the times | 11:39 |
| mborzecki | 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 |
| mvo | mborzecki: before that was difficult to get | 11:39 |
| mvo | mborzecki: yeah, worth a shot for sure | 11:40 |
| mvo | mborzecki: do you think you could do a separate PR so that we can see the results? | 11:40 |
| mborzecki | sure | 11:41 |
| mvo | mborzecki: thank you | 11:41 |
| mvo | mborzecki: also the output is much easier to read (i.e. failures easier to find). I like this more and more :) | 11:42 |
| cachio | mvo, hey, I'll be 5 minutes late today | 11:52 |
| mvo | cachio: no worries | 11:56 |
| mborzecki | mvo: is there a way to exclude tests in spread command line? | 11:56 |
| Chipaca | mborzecki: not afaik, but imho there should be | 11:59 |
| Chipaca | mborzecki: you need to list them all ( spread $( spread list linode: | grep -v yadda ) ) | 12:00 |
| Chipaca | -list, not list | 12:00 |
| mborzecki | 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:02 | |
| Chipaca | mborzecki: but, if it's that level, you could iterate one level down | 12:03 |
| Chipaca | mborzecki: i mean, there's three things at that level | 12:03 |
| Chipaca | oh, maybe some more | 12:03 |
| Chipaca | mborzecki: linode:ubuntu-16.04-64:tests/{main,completion,upgrade,regression}/... should do it | 12:08 |
| mborzecki | Chipaca: thanks | 12:08 |
| Chipaca | ¯\_(ツ)_/¯ | 12:08 |
| Chipaca | mborzecki: i charge in reviews of gnarly code with obfuscated names | 12:09 |
| ackk | sergiusens, hi, did you see my message above? | 12:11 |
| sergiusens | ackk yeah, is 2.30 widespread already? | 12:12 |
| ackk | sergiusens, IDK that | 12:13 |
| sergiusens | ackk according to this, it seems to have only been tagged, https://forum.snapcraft.io/t/2-30-release-cycle-started/2997 | 12:13 |
| ackk | sergiusens, I see. although until that feature lands in snapcraft it's hardly going to be testable in pre-releases | 12:15 |
| sergiusens | 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:21 |
| ackk | I see | 12:22 |
| sergiusens | I understand that testing the feature using some build system might be a bit more complex, but it is not untestable entirely | 12:22 |
| mup | PR snapd#4393 opened: travis: separate unit tests into separate build matrix jobs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4393> | 12:35 |
| greyback | 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 |
| mborzecki | mvo: #4393 should be running with unit tests in a separate job | 12:57 |
| mup | PR #4393: travis: separate unit tests into separate build matrix jobs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4393> | 12:57 |
| mvo | mborzecki: cool, looking | 12:58 |
| greyback | If I run tests in a xenial chroot, I fail with a different error: http://pastebin.ubuntu.com/26169908/ | 12:58 |
| greyback | how are people running these tests? | 12:59 |
| mvo | greyback: usually just ./run-check - that should pull in things, let me look at the poastine | 12:59 |
| mvo | greyback: and we have a meeting now, so we will be a bit slow replying | 12:59 |
| mborzecki | greyback: make sure you have these dependencies installed https://github.com/snapcore/snapd/blob/master/tests/lib/pkgdb.sh#L347 | 13:01 |
| greyback | mvo: ack. I've always used ./run-check first, that does grab dependencies. But fails at same place in the unit tests | 13:02 |
| jdstrand | greyback: guessing here: did you 'sudo apt-get build-dep snapd'? | 13:03 |
| greyback | jdstrand: yep | 13:03 |
| jdstrand | greyback: do you have libc6-dev-i386 installed? | 13:04 |
| jdstrand | $ dpkg -S /usr/include/sys/cdefs.h | 13:05 |
| jdstrand | libc6-dev-i386: /usr/include/sys/cdefs.h | 13:05 |
| greyback | jdstrand: no, just the amd64 version. I'll try the i386 but will be mystified if it works | 13:05 |
| jdstrand | greyback: I installed gcc-multilib and it pulled in a few things | 13:06 |
| jdstrand | greyback: ./packaging/ubuntu-16.04/changelog: - snap-seccomp: run secondary-arch tests via gcc-multilib | 13:06 |
| greyback | jdstrand: aha ok. The dependency grabber will need updating to reflect that | 13:07 |
| jdstrand | greyback: if 'apt-get build-dep snapd' isn't getting you there, look in packaging/ubuntu-<your version>/debian/control and see if there are missing build deps that you need to install | 13:07 |
| jdstrand | 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 |
| greyback | jdstrand: I think I am, tests have progressed beyond the usual error point | 13:08 |
| greyback | thanks for that | 13:08 |
| jdstrand | cool | 13:09 |
| jdstrand | 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 |
| greyback | jdstrand: sure, I know that, I just trusted the run-checks script to pull in its dependencies | 13:10 |
| Chipaca | jdstrand: greyback “apt build-dep ./” works | 13:10 |
| jdstrand | oh, that's handy | 13:11 |
| greyback | Chipaca: oh taht's handy | 13:11 |
| jdstrand | Chipaca: hehe | 13:11 |
| * mvo wrote that some years ago :-D | 13:11 | |
| Chipaca | jdstrand: greyback: hug mvo for that one | 13:11 |
| * greyback hat-tips mvo | 13:11 | |
| * jdstrand hugs mvo for that one | 13:11 | |
| jdstrand | :) | 13:11 |
| * mvo hugs greyback and jdstrand | 13:11 | |
| jdstrand | greyback: re run-checks> yeah, it doesn't do that I suspect because it doesn't use sudo for things | 13:13 |
| jdstrand | greyback: run-checks could certainly be made friendlier though | 13:14 |
| jdstrand | 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 |
| mvo | jdstrand: +1 | 13:15 |
| jdstrand | 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 |
| jdstrand | mvo: now that I say that, I didn't do 'apt-get build-dep ./' in the chroot | 13:17 |
| jdstrand | just the dpkg-buildpackage | 13:17 |
| * jdstrand tries | 13:17 | |
| jdstrand | I see it is a symlink | 13:18 |
| jdstrand | anyway, I'll play and reask | 13:18 |
| mvo | jdstrand: thanks, let me know how it goes | 13:18 |
| jdstrand | hmm, trusty's apt-get doesn't seem to like that | 13:22 |
| mvo | jdstrand: yeah, its old and crufty. try gdebi ./debian/control | 13:22 |
| sergiusens | elopio did you see my comment from yesterday about the integration tests not running from the snapcraft snap? | 13:25 |
| roadmr | sergiusens: good morning! hey is there still time to fix bugs for snapcraft 2.37 before it goes out to stable? | 13:31 |
| sergiusens | roadmr what is the problem? | 13:32 |
| sergiusens | 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:32 |
| sergiusens | that said, there is still time to make it into 2.38 :-) | 13:33 |
| roadmr | sergiusens: interesting... https://bugs.launchpad.net/snapcraft/+bug/1737571 is the problem (I want a poop emoji in my description dammit!) | 13:33 |
| mup | Bug #1737571: stack trace when description or summary contain non-ascii characters <Snapcraft:New> <https://launchpad.net/bugs/1737571> | 13:33 |
| sergiusens | interesting that popey has not discovered that ;-) | 13:33 |
| roadmr | sergiusens: I bet he uses only snoflake emojis, which mysteriously work fine | 13:34 |
| * kalikiana time for lunch! hopefully including a massive salad | 13:36 | |
| Chipaca | hmmmmmmmm | 13:39 |
| * Chipaca needs to open a snap in a context where it's not been validated yet | 13:39 | |
| Chipaca | 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:40 |
| mvo | Chipaca: hm, will you call unsquashfs -ls on it? | 13:42 |
| Chipaca | mvo: yes, or (*os.File).Readdir if it's a snapdir | 13:42 |
| mvo | Chipaca: *nod* | 13:43 |
| Chipaca | mvo: should I add knowledge of what's safe and what's unsafe to snap containers? | 13:43 |
| mvo | Chipaca: my gut feeling is yes | 13:43 |
| Chipaca | mine as well | 13:44 |
| Chipaca | but it does feel like a separate branch | 13:44 |
| jdstrand | 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 |
| Chipaca | jdstrand: did you ./generate-packaging-dir? | 13:44 |
| mvo | 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:44 |
| jdstrand | Chipaca: no, I updated the symlink manually | 13:45 |
| jdstrand | let me try that | 13:45 |
| Chipaca | mvo: gnome-software would have to do it separately if it were client-side | 13:45 |
| jdstrand | same thing | 13:45 |
| Chipaca | jdstrand: yeah all that does is update the symlink | 13:45 |
| Chipaca | :-/ | 13:45 |
| Chipaca | jdstrand: did you add proposed and the ppa? | 13:45 |
| jdstrand | no | 13:46 |
| * jdstrand does that | 13:46 | |
| Chipaca | jdstrand: look in tests/lib/prepare-restore.sh, if you look for ppa you'll find yourself in a 14.04 bloock | 13:46 |
| mvo | Chipaca: indeed, good point | 13:46 |
| Chipaca | mvo: but, agreed | 13:46 |
| Chipaca | mvo: in which case i can only do this check rather late (post validation) | 13:47 |
| mvo | Chipaca: tricky, I wonder if we could confine it? | 13:47 |
| mvo | Chipaca: \o/ | 13:47 |
| mvo | Chipaca: thats fine then | 13:47 |
| Chipaca | mvo: OTOH I can do it earlier for local files | 13:47 |
| Chipaca | so that should get rid of the most egregious whoopsies | 13:47 |
| mvo | Chipaca: sounds good | 13:48 |
| Chipaca | k | 13:48 |
| Chipaca | 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 |
| Chipaca | (as i was going over that repeatedly last week) | 13:49 |
| mvo | 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 |
| mvo | jdstrand: does that make sense? | 13:56 |
| mvo | jdstrand: this makes building a deb from git slightly harder as it expects to be in a valid GOPAHT | 13:57 |
| pedronis | Chipaca: where do you need to open a snap? we are very careful about where we do that or not? | 14:01 |
| Chipaca | pedronis: yes, we are | 14:01 |
| pedronis | Chipaca: I don't see the win or opening an unvalidated snap to check if the exec bits are right | 14:01 |
| pedronis | 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 |
| Chipaca | pedronis: it's late enough that it ends up in errors.u.c | 14:02 |
| Chipaca | pedronis: but, i can run it earlier for local snaps | 14:02 |
| pedronis | Chipaca: do we really send to errors.u.c for local snap? | 14:02 |
| pedronis | maybe that is the problem | 14:02 |
| Chipaca | pedronis: so that's good enough (that's what i concluded from the discussion with mvo) | 14:02 |
| Chipaca | pedronis: yes we do | 14:02 |
| pedronis | seems wrong | 14:03 |
| pedronis | we should stop to do that | 14:03 |
| Chipaca | pedronis: perhaps :-) | 14:03 |
| Chipaca | i'm trying to not branch this branch any further though :-) | 14:03 |
| Chipaca | i'll look into that next, then | 14:03 |
| mup | PR snapd#4386 closed: release: 2.30.rc3 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4386> | 14:05 |
| Chipaca | popey: is there a snap in the store you know of with the wrong permissions bug? | 14:12 |
| popey | no, it's a private snap | 14:20 |
| mup | PR snapd#4394 opened: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394> | 14:20 |
| Chipaca | 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 |
| Chipaca | popey: ah well, nm | 14:20 |
| jdstrand | 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 |
| mvo | jdstrand: unfortunately not from a git checkout as we do not store all the vendor/ deps in git | 14:27 |
| jdstrand | ah | 14:27 |
| Chipaca | jdstrand: the go devs are aware how nasty it is that go needs this faffing around and intend to fix it someday | 14:28 |
| Chipaca | they haven't said if that comes before or after generics :-) | 14:28 |
| jdstrand | 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:28 |
| jdstrand | I think I'll just make a note to rm -rf $GOPATH/pkg and govendor sync after to be 100% sure | 14:32 |
| om26er | @popey Hey! mind taking a look at https://github.com/snapcrafters/android-studio/pull/9 ? | 14:35 |
| mup | PR snapcrafters/android-studio#9: Ship packages required to run emulator <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/9> | 14:35 |
| mvo | jdstrand: it should not mess up your pkgdir because it should only install into ./vendor | 14:35 |
| jdstrand | mvo: ah, good to know | 14:36 |
| Chipaca | jdstrand: ps GOPATH is a path... "${GOPATH%%:*}/pkg" if you're putting that in a script | 14:36 |
| jdstrand | Chipaca: ack | 14:37 |
| kalikiana | re | 14:38 |
| sergiusens | popey flexiondotorg where is the repo for vscode? | 14:40 |
| sergiusens | or the snapcraft.yaml that makes the vscode of today a thing | 14:40 |
| flexiondotorg | https://code.launchpad.net/~flexiondotorg/+junk/snap-vscode | 14:40 |
| flexiondotorg | New version pushed to edge yesterday, | 14:41 |
| mup | PR snapd#4395 opened: update HACKING.md for distro build dependencies <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4395> | 14:41 |
| jdstrand | mvo, greyback: fyi, ^ | 14:41 |
| popey | om26er: looking | 14:41 |
| jdstrand | I didn't do anything for trusty there | 14:42 |
| jdstrand | just the apt-get build-dep ./ bit | 14:42 |
| Chipaca | jdstrand: apt-get doesn't have build-dep ./ | 14:43 |
| Chipaca | jdstrand: that's apt | 14:43 |
| jdstrand | it worked here | 14:43 |
| Chipaca | … oh | 14:43 |
| * Chipaca looks | 14:43 | |
| jdstrand | I just tested it in a xenial chroot | 14:43 |
| * jdstrand tries again | 14:43 | |
| Chipaca | dang | 14:43 |
| Chipaca | yes, it works with apt-get | 14:43 |
| Chipaca | wichcraft | 14:43 |
| jdstrand | heh | 14:44 |
| mvo | jdstrand: thanks for this | 14:45 |
| jdstrand | mvo: fyi, I passed along 'apt-get build-dep ./'. that is super cool :) | 14:49 |
| jdstrand | it's the little things in life... | 14:49 |
| sergiusens | flexiondotorg oh, launchpad, that's why I couldn't find it :-) | 14:49 |
| sergiusens | flexiondotorg I want to test getting rid of your LD_LIBRARY_PATHS in there | 14:49 |
| sergiusens | with the latest snapcraft in beta | 14:49 |
| mvo | jdstrand: thanks! | 14:50 |
| flexiondotorg | OK, So if I push the current edge to stable we cam play in edge? | 14:50 |
| flexiondotorg | We'll also need to feed this back up to the ISVs creating classic snaps, right? | 14:50 |
| elopio | 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:10 |
| sergiusens | 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:11 |
| sergiusens | unless they are needed to satisfy requirements-devel for the test runner | 15:12 |
| elopio | 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:12 |
| elopio | 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:22 |
| elopio | we are not installing the sources anytime. And the container doesn't have the snapcraft deb preinstalled. | 15:23 |
| elopio | are you sure the only way this could fail is if snapcraft is not being run from the snap built from the pr? | 15:23 |
| mvo | jdstrand: if you have a moment for 4381 that would be great. its hopefully super trivial to review | 15:41 |
| jdstrand | mvo: done | 15:45 |
| mvo | jdstrand: ta | 15:45 |
| mup | PR snapd#4381 closed: interfaces: add /proc/partitions to system-observe <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4381> | 15:46 |
| sergiusens | 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:48 |
| mup | Bug #1636540 changed: please support creating pipes via mknod <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1636540> | 15:55 |
| mup | Bug #1617275 changed: the home interface doesn't allow access to $HOME/snap-confine <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1617275> | 16:10 |
| mup | Bug #1725208 changed: missing interface to exec cc <snapd-interface> <Snappy:Won't Fix> <https://launchpad.net/bugs/1725208> | 16:22 |
| mup | Bug #1612759 changed: fchown system call is blocked by seccomp under confinement <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1612759> | 16:25 |
| mup | Bug #1636229 changed: getpwnam() and parsing /etc/passwd gives wrong value for HOME to snaps <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1636229> | 16:28 |
| pstolowski | 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:34 |
| Saviq | hmm is there known outage of the store services? my `snapcraft push` times out after trying to process the delta for 60s) | 16:39 |
| * Saviq clears cache to force a full upload | 16:43 | |
| daniellimws | hi | 16:48 |
| Chipaca | daniellimws: hi | 16:48 |
| elopio | 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 |
| mup | Bug #1737571: stack trace when description or summary contain non-ascii characters <Snapcraft:New> <https://launchpad.net/bugs/1737571> | 16:49 |
| kyrofa | Hey there daniellimws, thanks for joining! | 16:49 |
| daniellimws | thanks for inviting :) | 16:49 |
| kyrofa | sergiusens, elopio there's your man ^ | 16:50 |
| roadmr | elopio: oh no :) I just filed it | 16:52 |
| roadmr | 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 |
| roadmr | 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 |
| roadmr | elopio: so tl;dr not really working on it, sorry :( if you could that'd be swell | 16:53 |
| elopio | roadmr: I will try to fix it this week. | 16:56 |
| roadmr | thanks elopio! | 16:56 |
| elopio | daniellimws: hey, I am wondering if you are ready for a new task, I have one that might interest you | 16:56 |
| daniellimws | yea i think my current one should be done soon | 16:56 |
| Chipaca | snapd#4394 is green, if anybody is looking for something to poke at | 16:56 |
| mup | PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394> | 16:56 |
| elopio | the problem is that it's abandoned, and I don't know how to recover it. kyrofa do you know? | 16:56 |
| daniellimws | running the test cases now | 16:56 |
| daniellimws | *running them locally | 16:57 |
| kyrofa | elopio, huh. Let me look | 16:57 |
| elopio | kyrofa: https://codein.withgoogle.com/dashboard/task-instances/6180198217154560/ | 16:57 |
| cachio | mvo, we have 2.30 in candidate | 16:57 |
| daniellimws | ah i wanted to work on this but couldnt find it | 16:57 |
| elopio | well, actually it's better that it's blocked. That way nobody can take it while we review your current PR | 16:58 |
| kyrofa | 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 |
| daniellimws | elopio: haha that's great. and I still have a beginner task to spare | 16:58 |
| elopio | daniellimws: here's the description: http://paste.ubuntu.com/26171261/ Please let me know if it sounds fun to you | 16:58 |
| elopio | sergiusens: who's our travel authorizer? Mark? | 16:59 |
| daniellimws | elopio: i recall there was also a task about snapcraft stats, but its not there now. Has anyone done it? | 16:59 |
| elopio | daniellimws: yes, the one about stats is done: https://github.com/elopio/random-scripts/pull/1 | 17:00 |
| mup | PR elopio/random-scripts#1: Add gathering data from github <Created by DeniskaMazur> <https://github.com/elopio/random-scripts/pull/1> | 17:00 |
| kyrofa | elopio, we can add another instance easily | 17:00 |
| kyrofa | elopio, but you're right, let's wait until daniellimws is ready | 17:00 |
| kalikiana | 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:06 |
| kalikiana | hey daniellimws! | 17:08 |
| kalikiana | 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 |
| mup | PR #1793: asserts: initial support to generate/sign snap-build assertions <Created by caio1982> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1793> | 17:09 |
| kalikiana | bah | 17:09 |
| kalikiana | I meant snapcraft#1793 | 17:09 |
| mup | PR snapcraft#1793: project: refactor storeapi <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1793> | 17:09 |
| daniellimws | kalikiana alright thanks. I'll push soon once I fix all the test errors. | 17:10 |
| kalikiana | daniellimws: Awesome! | 17:11 |
| * kalikiana out for today, o/ | 17:16 | |
| mvo | cachio: yay! thank you | 17:35 |
| cachio | mvo, yaw | 17:36 |
| sergiusens | elopio https://travis-ci.org/snapcore/snapcraft/jobs/315458083 -> "snapcraft from snap: False; so patchelf set to 'patchelf'" | 18:14 |
| sergiusens | elopio kyrofa the fact that the 'snapcraft-parser' tests work at all is telling me that it is running from the venv | 18:21 |
| elopio | sergiusens: the things is to find where is that venv being set up | 18:22 |
| elopio | sergiusens: can you add which snapcraft to that debug execution? | 18:25 |
| sergiusens | elopio it is horrible | 18:33 |
| sergiusens | I just pushed a fix | 18:33 |
| sergiusens | to make this deterministic | 18:33 |
| sergiusens | kyrofa will be there in a bit | 18:33 |
| kyrofa | Okay | 18:33 |
| mup | PR snapcraft#1803 opened: ci: correctly run from snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1803> | 18:34 |
| wililupy | If I want to add isolcpus=2,3 to the grub CMDLINE value "the correct way" how do I do that? | 18:44 |
| wililupy | I modified the /boot/grub/grub.cfg and added the line in the set cmdline variable and it works, but I fear that if there is an update to the device it will revert back to original settings and would like this permanent across grub-update(s). | 18:55 |
| mvo | wililupy: you can test this via "snap refresh --candidate core" for example, currently grub.cfg should be safe iirc. I think longer term we want to add support for grub.cfg settings via the "snap set core " configuraton options | 18:56 |
| wililupy | mvo. I"ll give that a test, but that sounds amazing! | 18:57 |
| mvo | wililupy: if things look good you can "snap refresh --stable core" to get back to the stable core | 19:00 |
| mvo | wililupy: you could also try to update the gadget and the kernel just to be on the safe side | 19:01 |
| wililupy | mvo: cool I'll give it a shot and see. I'll keep you posted. | 19:02 |
| mvo | thanks | 19:03 |
| wililupy | mvo so updating core snap keeps the grub config, so that good. Testing kernel and gadget next. | 19:04 |
| mvo | wililupy: yeah, iirc it should work until we implement gadget assert updates but then we will also implement a core config options for that I think. feel free to open a topic on forum.snapcraft.io about your use-case, then we can discuss how to best implement grub.cfg manipulation via snap set | 19:10 |
| wililupy | mvo cool. I will take it to the forum :) | 19:10 |
| kyrofa | Is it just me, or does my rpi2 take a LOT longer to boot and start running services if it's not connected to a network? | 19:18 |
| kyrofa | Does it have a 60 second IP address timeout or something? | 19:18 |
| cachio | mvo, I am working in a test for system-trace interface, I was wondering if it is ok to use the bcc snap for that or it should be better to create a test one | 19:19 |
| cachio | mvo, what do you think? | 19:19 |
| mvo | cachio: I think its ok to use bcc, we nowdays send a header to the store when a snap is under testing | 19:25 |
| cachio | mvo, great | 19:25 |
| cachio | tx | 19:26 |
| mvo | cachio: I need to double check if that is also true for e.g. external: tests that where we don't build snapd ourself, but even then we can probably do something. and worst case we just fork bcc | 19:26 |
| mvo | cachio: could you talk to apw tomorrow/in the next days about snapd 2.29.4.2 for -updates? afaict all remaing autopkgtest issues are some network hickups or similar | 19:27 |
| cachio | mvo, sure | 19:27 |
| cachio | I'll see that tomorrow | 19:28 |
| mvo | cachio: thank you! yeah, thats fine | 19:28 |
| cachio | mvo, anjoy your vacations | 19:28 |
| cachio | enjoy | 19:28 |
| mvo | cachio: thank you, appreciated! I will be a around a little bit longer, I want to finish my current task but then I do look forward to take a break :) | 19:29 |
| kyrofa | cachio, have you noticed Core taking longer to come up without network? | 19:36 |
| cachio | kyrofa, the one in candidate? | 19:37 |
| cachio | kyrofa, I'll check that, where sis you see that? | 19:37 |
| kyrofa | No, I guess I'm using stable these days | 19:37 |
| cachio | kyrofa, ok, I'll check it | 19:38 |
| kyrofa | cachio, I'm running a rpi2 based on the edge image, but refreshed core to stable after an update got hung up | 19:38 |
| cachio | kyrofa, ok, I don't use edge image, I'll try to reproduce it | 19:41 |
| cachio | kyrofa, the hung was after the reboot? or before? | 19:41 |
| kyrofa | cachio, I wrote about the hung update here (although this was a while ago, I doubt it's related to the fact that the boot seems to take longer when it has no network): https://forum.snapcraft.io/t/raspberry-pi-2-edge-core-snap-seems-broken/3061/4 | 19:42 |
| cachio | kyrofa, in this change -> Setup snap "core" (3443) security profiles (phase 2) | 19:44 |
| cachio | it usually takes like 5~10 minutes | 19:44 |
| cachio | kyrofa, how long did it take when you raised that issue? do you remember that? | 19:45 |
| kyrofa | Really? Ouch, I probably didn't give it enough time then. I needed my interface connected! | 19:45 |
| kyrofa | 5-10 minutes of downtime for an automatic refresh that prevents me from doing anything is too much | 19:46 |
| bencc | is it possible to reload a snap on upgrade instead of restart | 19:47 |
| bencc | useful for nginx web server in a snap to keep connections | 19:47 |
| Chipaca | bencc: i presume nginx is smart about that sort of thing? but sadly no, that would imply one revision of a snap doing ipc with another revision of the same snap | 19:48 |
| cachio | kyrofa, agree, it is too much | 19:53 |
| cachio | kyrofa, you can manually reboot it as workaround | 19:53 |
| kyrofa | cachio, which, as it happens, is exactly what I did! Haha | 19:53 |
| cachio | kyrofa, hehe, I do the same | 19:53 |
| kyrofa | cachio, how can a reboot make 5-10 minutes of work not necessary? | 19:53 |
| kyrofa | What's happening there? | 19:53 |
| cachio | kyrofa, the reboot is scheduled for 10 minutes after the refresh is done | 19:54 |
| cachio | kyrofa, during that time the setup is done | 19:56 |
| mup | PR snapcraft#1804 opened: meta: split the meta module <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1804> | 20:41 |
| === Eleventh_Doctor is now known as Pharaoh_Atem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!