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