[01:54] PR snapd#3416 closed: tests: fix for test interfaces-openvswitch === chihchun_afk is now known as chihchun === JanC_ is now known as JanC === chihchun is now known as chihchun_afk [07:02] PR snapd#3468 opened: debian: add missing Type=notify in 14.04 packaging [07:09] PR snapd#3458 closed: tests: check that locale-control is not present on core === koza|away is now known as koza === chihchun_afk is now known as chihchun [07:24] PR snapd#3454 closed: spread: add fedora snap bin dir to global PATH [07:25] mvo: thanks! [07:25] PR snapd#3452 closed: tests/main: check for confinement in a few more interface tests [07:26] PR snapd#3451 closed: tests/main: use dir abstraction in a few more test cases [07:27] good morning [07:28] PR snapd#3443 closed: Unity7 interface grows gtk2/3 settings and user's specific ini [07:30] fgimenez: if you de-conflict 3391 I am happy to merge it [07:30] morphis: my pleasure, thanks for working on this! [07:31] mvo: sure thx! on it [07:31] mvo: np, more to come :-) [07:31] PR snapd#3405 closed: tests: fix for upgrade test when it is repeated [07:31] morphis: 3222 has a conflict and test failures (probably unrelated) - could you merge master and de-conflict, hopefully this can go in then :) [07:31] fgimenez: no rush :) [07:34] mvo: yeah will start working on these PRs in a bit [07:37] morphis: ta [07:39] mvo: snapd#3391 is ready thx :) btw when you have some time (not urgent) it would be great to create these test snaps under the shared account in prod: https://code.launchpad.net/~snappy-dev/+snap/test-snapd-system-observe-consumer https://code.launchpad.net/~snappy-dev/+snap/test-snapd-autopilot-consumer https://code.launchpad.net/~snappy-dev/+snap/test-snapd-upower-observe-provider [07:39] PR snapd#3391: tests: reboot after upgrading to snapd on the -proposed pocket [08:54] I'm working on a MuseScore snap: https://github.com/pachulo/musescore-snap and trying to get the MuseScore devs to make it "official": any tips on doing it? [09:00] pachulo, dont they have some "how to contribute" doc on their website ? i'd try to follow it (make a PR on github etc) [09:02] I've already did something like this: https://github.com/musescore/MuseScore/pull/3204 [09:02] PR musescore/MuseScore#3204: Add snap package [09:03] well, then wait for answer :) [09:07] should I recommend them to use https://build.snapcraft.io/ to create the snaps? [09:07] ogra: [09:08] well, thats up to them but yes, show them the possible ways of making use of your code :) [09:14] does it makes sense to have different snapcraft.yaml for the different channels all in the master branch of the project? [09:15] pachulo: I would kepe them in separate branches, not sure what the actual difference between those is though [09:16] * Chipaca ~> coffee [09:26] PR snapd#3465 closed: hooks: re-org of some hooks types [09:45] Pharaoh_Atem: `zypper si -d` doesn't help for local srpm's, it only works with packages listed in the archive [09:51] ogra, hi, do you know how can I force generation of core file on program crash, in UC16? [09:52] abeato, you should be able to do the same stuff apport does i think [09:52] (iirc it pokes around in sysfs to make file dumps happen) [09:52] ogra, ok, will check, thanks [10:00] mvo, is 2.27 already in candidate? or latest changes (including androidboot) are only in edge? [10:04] abeato: only in edge, we have no pushed 2.26 out, some small issue in specific revert cases still [10:05] mvo, got it, thanks [10:23] mvo: fgimenez: hi, have we found out more about those revert problems? is still related to profiles or something else? [10:26] hi pedronis, the core-revert test now shows the problem with the changes at snapd#3466, this is syslog of the testbed after the failure http://paste.ubuntu.com/24815993/ looks like the problem is related to "hsearch_r failed for NETLINK_KOBJECT_UEVENT: No such process" after the revert [10:26] PR snapd#3466: tests: extend core-revert test to cover bluez issues [10:26] ok, profiles, thanks [10:50] is it possible to upload a snap for different archs in the webui of the store? [10:53] pachulo: i think yes, the store will automatically detect the arch [10:54] but if I want to upload the snap for x86 & for amd64? [10:58] then the store simply generates a revision per arch ... it check the meta/snap.yaml inside your snap [11:00] ah, ok, different revisions per arch [11:00] that makes sense [11:01] and how do you make the snap availabe in the stable channel? In the webui I can only pusblish to "beta" and/or "edge" [11:04] id your snap confinement: strict and grade: stable ? [11:05] s/id/is/ [11:05] only stable snaps with strict confinement can go into stable [11:06] ok [11:07] thanks for the info ogra ! [11:07] np :) [11:20] Mornings [11:24] PR snapd#3469 opened: many: add "release.BuildStamp" to identify the current build [11:36] oops, i done goofed [11:36] * Chipaca fixes [12:02] mvo: ogra we are still getting errors with the new kernel snaps published to beta due to missing /dev/ram* https://travis-ci.org/snapcore/spread-cron/builds/241982348 should we change the tests to stop using them? the related bug recently expired bug #1677622 [12:02] Bug #1677622: missing ramdisks in latest amd64 kernel snap [12:06] fgimenez, well, that seems to be a userspace tool issue if i read ppisati's comment correctly [12:07] you could just run mknod before mkfs [12:09] thanks ogra, i'll try that with beta's kernel [12:10] fgimenez, i also think it might be realted to https://github.com/snapcore/snapd/pull/3010 [12:10] PR snapd#3010: snap: skip /dev/ram from auto-import assertions to make it less noisy [12:11] (i suspect the mount attemmpt makes the kernel actually create the device (just y theory though)) [12:11] s/y/a/ [12:14] ogra: not sure, we noticed the problem before snapd#3010 was proposed, the first errors are from 2017-03-15 https://travis-ci.org/snapcore/spread-cron/builds/211518618#L668 [12:14] PR snapd#3010: snap: skip /dev/ram from auto-import assertions to make it less noisy [12:14] hmm, k [12:18] https://launchpad.net/ubuntu/+source/snapd/2.23.1 landed on 2017-03-14 [12:18] quite some changes in there [12:19] and https://launchpad.net/ubuntu/+source/linux/4.4.0-67.88 went into beta on the 15th [12:19] also not a small changeset [12:59] PR snapd#3470 opened: interfaces/builtin: sync connected slot and permanent slot snippet [13:30] PR snapd#3471 opened: snap: make `snap run` look at the system-key for security profiles [13:54] mvo: i didn't receive yet the test snaps emails, should i have them already? [13:56] fgimenez: you should, let me double check [13:56] mvo: thx! [13:57] fgimenez: probably primary email vs not primary sso email again, sorry for that [13:58] mvo: np :) already received, thank you! === chihchun is now known as chihchun_afk [14:03] noise][: hey, fyi, https://dashboard.snapcraft.io/dev/snaps/7807/rev/1/ says 'manifest not available' [14:04] jdstrand: you are getting an err on the page? [14:05] noise][: https://dashboard.snapcraft.io/dev/snaps/7809/ too [14:05] noise][: sorry, if I go to Overview, then review capabilities [14:05] Manifest (snap.yaml) [14:05] manifest not available [14:05] ah, i see [14:06] weird - can you file a bug on https://bugs.launchpad.net/snapstore and i'll get someone to take a look ASAP [14:06] sure [14:09] noise][: https://bugs.launchpad.net/snapstore/+bug/1697459 [14:09] Bug #1697459: Manifest (snap.yaml): manifest not available [14:10] * zyga lunch and small break [14:26] re [14:56] zyga, mvo, Pharaoh_Atem: https://github.com/snapcore/snapd/pull/3449 is ready for another review and merge :-) [14:56] PR snapd#3449: tests/lib: generalize RPM build support [14:58] morphis: why are you not using `dnf builddep` or `zypper si`? [15:06] Pharaoh_Atem: as zypper si doesn't work [15:06] it works only for packages coming from the archive [15:06] and with that I couldn't find a good abstraction and left the comming thing in I had before [15:06] you gave it the full path of the RPM, not just the rpm name? [15:06] correct [15:07] it complains about not being able to find that package [15:07] wow, that's... dumb [15:07] giving it just a name works fine [15:08] if you find a better way on suse I am all ears but want to get this in as I have a lot more on my plate at the moment [15:08] can you pull all the deps into an array, ignore the ones that are rpmlib() ones, and then just pass that as an arg to zypper install / dnf install? [15:09] because the way you're doing it now is really slow [15:10] jdstrand: it looks like we need to revert http://paste.ubuntu.com/24841683/ this is using new symbols and things break on revert- this is 17389627 - it looks dangerous though. what is your opinion here? instead of reverting we could hold a stable release back until the seccomp-bpf branch is finished and lands. [15:15] PR snapd#3463 closed: client, daemon: expose service commands (start, stop, etc) [15:17] Pharaoh_Atem: that is what I am doing right now [15:17] ah, I see where you're passing the array [15:18] I missed that [15:18] :-) [15:19] then the only piece left is that spurious --nocheck on rpmbuild -bs [15:20] let me drop that [15:20] actually why doesn't rpm complain if it is there and not used? [15:21] Pharaoh_Atem: done [15:26] mvo: which stable would we hold back? [15:28] jdstrand: 2.25 is currently in candidate but never progressed to stable because when 2.24.1 -> 2.25 -> 2.24.1 reverts happen some snaps (like network-manager) fail to start because of seccomp symbols [15:29] jdstrand: and we found during testing that the above commit is also problematic [15:29] that whole PR has a bunch of new symbols [15:30] I've started looking at the bpf PR [15:30] I don't know what kind of timeframe you are looking for at this point [15:31] I'd be inclined to wait for the bpf at this point [15:34] mvo: ^ [15:37] jdstrand: ok, that is something to discuss I think, I can't make this decision alone, but I have the same feeling, it feels like whack-a-mole currently and the risk is that we break things. seccomp-bpf I can pick-up again and its pretty safe [15:37] jdstrand: but I definitely want your input if all things I do there are sound :) [15:38] mvo: I will be looking at the PR in depth [15:39] mvo: note I already commented on it regarding missing tests [15:39] jdstrand: tests about the >= etc syntax? those should be ported in a different way, let me look for the link [15:40] mvo: so all the reverts are making me uneasy because there is risk in getting the revert wrong and getting the unrevert wrong in the future [15:41] jdstrand: https://github.com/snapcore/snapd/pull/3431/files#diff-be7cfe1e5aff69d70d80b1c2cabcaaccR148 is the testing, it uses a bpf.VM and gives it the same inputs as the kernel would give it. is your concern that you want sometimg more integration-ish? or am I missing someting in those tests that I overlooked? [15:41] PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code [15:41] mvo: the tests I commented on were cmd/snap-confine/tests. the will definitely need to be ported in a different way, but the PR doesn't show them [15:41] jdstrand: yeah, I agree, I don't feel good about those reverts either. [15:43] mvo: I suspect that the porting will be done in two ways: syntax checks in TestCompile and functional tests to spread [15:43] jdstrand: aha, I see, something more integration test-ish then, I make that a priority in my morning. it should be unit tested now but you are right, integration type tests in this style are missing [15:44] mvo: where the spread tests will consist of rewriting the seccomp filter [15:44] * mvo nods [15:44] mvo: it's more than just integration though. there are a ton of syntax tests. eg test_restrictions_working_args_socket [15:45] they won't be hard to port or anything, just saying more is needed in TestCompile [15:45] in addition to integration/spread tests [15:47] jdstrand: thank you, indeed, I will work on it in my morning. it looks straightfoward to port to TestCompile fortunately [15:48] mvo: yes. there are relatively few things that need to go to spread otoh [15:49] mvo: thanks for taking care of that [15:49] jdstrand: yeah, thanks a lot for your feedback [15:49] np [15:49] more will be coming :) [15:59] jdstrand: thank you. I updated the forum thread on the 2.25 issue, feel free to jump in and add your opinion [16:00] ok [16:12] Bug #1697492 opened: systemd fails to run /lib/systemd/system-sleep/wpasupplicant script when wpa-supplicant is installed [16:13] abeato, urgh ... we have a wpa-supplicant snap ? [16:14] ogra, we do... was needed for some wowlan stuff in caracalla [16:14] abeato, i doubt that can work, given that we have a wpa-supplicant in the core snap too [16:15] unless you block that or make it unexecutable somehow [16:16] ogra, it does, mostly, see https://github.com/snapcore/core-build/blob/master/config/lib/systemd/system/wpa_supplicant.service.d/snap.conf , that is how the one in core is blocked [16:16] ah, i remember landing that, yeah [16:17] but that only blocks execution, you still have all the files and scripts in the rootfs [16:17] thats a really tricky bug [16:17] we cant just hack the default script [16:17] yeah, it is quite ugly thing [16:18] I agree... [16:18] I'm not sure how this could be solved, maybe the path should have been to add patches to wpa-s in xenial instead [16:20] well, if you think that coulld solve the need for a snap ... xenial is there, SRUs are always possible :) [16:22] sure... I'll think about that and leave the bug there open for the moment [16:23] abeato, hmm, i wonder what happens if you ship a /writable/system-data/lib/systemd/system-sleep/wpasupplicant in your gadget snap [16:23] (if that gets copied into place etc) [16:23] might be possible to override the default file from the gadget that way [16:23] ogra, good idea, will give that a try [16:24] i know we allow copying a bunch of things ... mot sure if /lib is included in that though ... (the ubuntu-image source might know :) ) [16:33] PR snapd#3472 opened: interfaces, tests: add mising dbus abstraction to system-observe and extend spread test [17:22] Chipaca, are you working in a store related change? is it something that could be addressed https://travis-ci.org/snapcore/snapd/builds/241920749#L2050 ? [17:29] PR snapd#3473 opened: tests: fix create-key by generating entropy in case the current it is not enough === cachio_ is now known as cachio_afk [18:13] mvo: Still here? [18:25] Is this an issue with the kubelet snap or snappy itself? https://errors.ubuntu.com/problem/19272ebc18709d4407dba0438a536d56bb143069 [18:26] bdmurray, https://forum.snapcraft.io/t/test-failures-with-cannot-create-lock-directory-run-snapd-lock/390 [18:26] cachio_afk: Some feedback on 3437 [18:26] PR snapd#3437 closed: tests: apt autoclean [18:30] ogra: ah, thanks [18:33] ogra@bbb:~$ sudo classic [18:33] cannot open cookie file /var/lib/snapd/cookie/snap.classic [18:34] hmm, whats that ? that wasnt there yesterday, since todays core refresh i seem to get it everywherre [18:34] (i end up just fine in the classic shell after the message) [18:54] morphis: snapd#3222 is good to go assuming one trivial tweak mentioned there [18:54] PR snapd#3222: many: fix test cases to work with different DistroLibExecDir [18:58] PR snapd#3461 closed: debian: add missing "make -C data/systemd clean" [19:37] niemeyer: thanks, will fix that tomorrow! [19:37] morphis: Thank you! Glad to see that one in [19:42] niemeyer: lets see how friendly travis is tomorrow to me :-) [19:43] morphis: I've heard things have been improving much there [19:53] niemeyer: yeah they did :-) === elfgoh_ is now known as elfgoh === blr_ is now known as blr === cachio_afk is now known as cachio [21:38] hi everyone! [21:43] niemeyer, please when you have a minute could you take a look to the PR 3473? [21:50] cachio: Will do [21:50] tc [21:50] tx [21:59] Does anyone know how to fix python path issues? I'm experiencing the same problems from this post https://askubuntu.com/questions/906199/how-to-setup-pythonpath-for-a-snap-package [22:00] Basically my python package is in the site packages directory, but I am getting the error that my command cannot find my package [22:44] cachio do you have any experience dealing with python path issues? [22:48] ssbash: so the wrapper script doesn't set PYTHONPATH at all (should be viewable from the shell session, i think) [22:50] i checked the shell session, this is what it returns https://paste.ubuntu.com/24844778/ [22:51] ssbash, let me see [22:52] here is the error message http://paste.ubuntu.com/24844781/ [22:53] also here is the snapcraft.yaml http://paste.ubuntu.com/24844790/ [22:54] ssbash: so i think the issue is site-packages vs. dist-packages, but i'm not sure why [22:54] env PYTHONPATH variable seems to be correct as I have specificed in the .yaml file. However my python script is still not picking up on the package. [22:55] ok, how could I move the install location of my package to a dist-package? [22:55] ssbash: it's strange, i think the python plugin should be handling that for you [22:55] It's automatically moved to site-packages, since I use setup.py to build [22:56] ssbash: i wonder if the python2.7 site.py needs to be udpated [22:56] ssbash, what do you have in the requirements.txt? [22:56] ssbash: again, not something you should have to do, either way [22:58] I'm not sure what you mean by the python 2.7 site.py? I've specified the python plugin that this is a pyhton 3.5 project. Also here is my requirements.txt http://paste.ubuntu.com/24844809/ [23:02] ssbash, did you try creating a wrapper and setting up the pythonpath on there? [23:03] like a virtualenv? I'm confused what you mean by wrapper [23:06] ssbash, I mean a bash script able to call the python module [23:06] ssbash, let me take a look to the lib to see why it is givving that error [23:07] or try to do that form the shell itself (spin up the interpreter from your snap shell) [23:07] ssbash: i just was thinking through how site-packages works normally [23:10] cachio: this is the command wrapper that snapcraft created. #!/bin/sh export PATH="$SNAP/usr/sbin:$SNAP/usr/bin:$SNAP/sbin:$SNAP/bin:$PATH" export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$SNAP/lib:$SNAP/usr/lib:$SNAP/lib/x86_64-linux-gnu:$SNAP/usr/lib/x86_64-linux-gnu" export LD_LIBRARY_PATH="$SNAP/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH" export LD_LIBRARY_PATH=$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH exec "$SNAP/usr/bin/python3" "$SNAP/bin/wr [23:11] whoops http://paste.ubuntu.com/24844868/ [23:11] I dont see any mention of the python path in the wrapper [23:13] ssbash, no [23:13] ssbash, did you check the project was correctly downloaded¡? [23:14] ssbash, I am talking about wraticus [23:14] oh, yes I've check that the entire package and sub packages have been downloaded in site-packages. [23:17] ssbash, what I have done with good results is to create a wrapper script where I setup all the veriables that I need and also I make the call the to command [23:17] let me check for an example [23:19] ssbash, there is some doc on https://snapcraft.io/docs/build-snaps/metadata [23:19] section Using wrappers [23:20] ssbash, does it work for you? [23:21] I'm still a bit confused. how could I specific the python path in the wrapper without hard coding a path? [23:23] you can do, export PYTHONPATH=PYTHONPATH:blablabbla [23:23] PYTHONPATH: $PYTHONPATH:$SNAP/lib/python3.5/site-packages would that be work?\ [23:23] and then exec "$SNAP/usr/bin/python3" "$SNAP/bin/wraticus.py" "$@" [23:24] ok and then point the command to this new wrapper executable [23:24] yes [23:24] ok ill give it a try [23:47] cachio I added the wrapper command. python still isnt able to find wraticus. [23:59] ssbash, can you share the wrapper?