=== chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [04:22] sergiusens: in case you missed it on Telegram, WebDM is now SnapWeb and lives on GitHub: https://github.com/snapcore/snapweb === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:43] Hi. Is it possible for a snap (eg. app) to depend on another snap (eg. lib) or should all dependencies be included as parts? [06:49] there will be library snaps at some point that will aloow content sharing between two snaps ... but that does not exist yet and will very likely be limited to one user (i.e. you wont be able to use my lib snaps, but if you package a whole desktop you can have a shared lib snap for all your desktop snaps) [07:20] ok, so for now I simple bundle everything in one. Got it. Thanks. [07:20] simply* [07:20] yeah === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [08:16] o/ [09:06] zyga: hey, whats the next step for the serial-port PR? [09:07] joc_: I have to review it again; I'm sorry I was pretty busy lately [09:09] zyga: np, thanks === chihchun is now known as chihchun_afk [09:36] Hi, I am trying to build a java application using snapcraft which depends on a package from an external jar file. I am thinking I need to use the copy plugin to move the external jar file to where it can be seen by the ant plugin. Any ideas? [10:48] slangasek: hey, did you commit all the packaging improvements from debian into snap-confine? === chihchun_afk is now known as chihchun [10:54] Hi, I'd like to learn to make snappy packages. Is it also possible to use snappy for things like python libraries? I need a later version of pyvcf then is in the repo so I thought that might be a good test case [10:58] trijntje: no, because libraries are not executable directly, libraries can be represented as snapcraft "parts" and later included in othre snaps === hikiko is now known as hikiko|ln [11:01] zyga: ok, so if I want a library that I can import in my own programs, I need to install them system wide using .deb. But when I make an app that depends on that library I can include it as a snapcraft part [11:02] jdstrand: (sorry for double ping) http://paste.ubuntu.com/17287781/ what do I do about these kinds of things? [11:02] (I have [x11, network, network-bind, unity7, opengl, home]) [11:04] davidcalle, dholbach, hey. Quick question - how often is the gadgets page on d.u.c updated? E.g. if someone uploads a new gadget, it should appear automatically on the page after how long? [11:05] dpm: since we got various requirements that did not fit the current app (eg. indicating official support or not, etc.) the list is back to manual updating since the sprint. [11:06] trijntje: if you want to use it in your programs that are packaged as a snap you don't need the deb [11:08] zyga: I work as a bioinformatician, so I'm usually writing small scripts to do a specific trick, so for me its important I can just put 'import libraryX' and have it work. I usually don't package each and every script I create [11:08] trijntje: you can just use pip for that [11:08] trijntje: pip install --user ... [11:08] trijntje: if you want to package your scripts into a snap you can also use pip packages [11:09] davidcalle, thanks. Can you give me more context on these requirements that caused the updates to be manual? [11:12] zyga: I'm in a bit of a weird spot, since I write a lot of tools, and I have do distribute those to like 5 different users. So I want to do as little manual stuf as possible, but packaging everything 'by the book' also seems overkill [11:13] Right now I try to use as much stuf from the repo as possible, and put my scripts in a simple .deb, which is easiest for the users, but a pain when I need a later version then is in the repo [11:18] trijntje: do a snap then :) [11:18] dpm: I've forwarded you some threads for context. In a nutshell: need to fetch a new type of snaps ("gadget", we are only looking for "oem" right now which is not used in 16 series anymore), identify gadget snaps maintained by Canonical, sort by release, add links in some cases, that don't exist in the store description. [11:19] great, thanks davidcalle [11:20] davidcalle, when you've got a minute, could you also publish the snapcraft 2.10 blog post? We might want to change the title to reflect the actual announcement was last week [11:20] zyga: I'd like to, but not if first I have to snap all python libraries that I want to use. Thats a lot of extra work right? [11:20] dpm: have you seen my comment on it? [11:22] dpm: about gadget snaps, the new type fecthing + sorting by release is merged in trunk, other requirements are blocking. [11:27] trijntje: no, you don't have to snap then [11:27] trijntje: if your libraries are on pypi you can use them directly [11:27] trijntje: add a part that installs your libraries into the snap [11:28] trijntje: (see snapcraft docs for that, I don't remember which plugin it was) [11:28] trijntje: then add another part that puts your scripts into the snap [11:28] trijntje: and expose each script as an app [11:28] zyga: ok, that sounds pretty good. So I just do pip install for myself for development, and use pip for the snappy package as well [11:28] trijntje: there's a way to pass a requirements.txt to your part [11:29] trijntje: I just don't recall the syntax [11:30] dpm, there's also no way to distinguish between supported and unsupported snaps in the store [11:30] dpm, I'll raise this with the store team again [11:30] cool, I'll give that a go. I'd have to spend a bunch of time to build a new .deb for the lib I want anyway, so if I can use pip thats already a big win. And it will work for every python lib ofc ;) [11:38] davidcalle, I've now seen the comment and replied to it. I've made some tweaks to the text and I think it should be good to go. Do you think you could look at publishing it in the next few hours? Thanks! [11:38] davidcalle, as usual, feel free to modify, especially if you have a better suggestion for the title [11:39] dpm: yes, seen it. wfm! Will publish right after lunch. [11:39] * dpm hugs davidcalle === hikiko|ln is now known as hikiko [12:03] has there been any thought on how to handle libexec? Most libs (KDE frameworks anyway) hardcodes it into apps based on the install prefix. Naturally that doesn't work in snappy [12:06] d_ed: some peopple use --prefix=/snap/$SNAP_NAME/current/usr [12:07] d_ed: though sadly it would be best if this was handled upstream, if upsteams integrated with $SNAP [12:07] I've submitted patches in review to load from an env var [12:08] so we can then do KF5_LIBEXEC_DIR=$SNAP/whatever/libexec in the snap launcher [12:09] --prefix=/snap/current is technically broken [12:09] zyga, that prefix doesn't work though, it makes things being mounted in /snap/name/current/snap/name/current... [12:09] iirc there was recently env var support added to snapcraft.yaml ... not sure that got released yet though [12:09] as if you ran an old version you'd hardcode into a different file [12:09] so you dont need to patch, you just define KF5_LIBEXEC_DIR= in your snapcraft.yaml [12:10] well, I need the patch in frameworks to actually look at KF5_LIBEXEC_DIR as it didn't exist yet [12:10] right, but you shouldnt need to patch the snap launcher for it [12:11] yep [12:11] thanks [12:11] seb128: ah, right [12:11] hmmmmm [12:11] * zyga has no idea [12:11] wouldnt a relative prefix work ? [12:12] --prefix=./usr [12:12] and depend on the CWD from where you launch snap? [12:21] ah zyga, I wanted to follow up - last week Jamie mentioned you'd had found some issues with the clock app, but I couldn't trace some of the things you mentioned in the wrapper. Could you remind me of the issues you found and confirm if that's the code you were looking at? -> http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/view/head:/calculator.wrapper [12:21] sorry, I mean *calculator snap, not clock [12:32] dpm: about to publish, but see doc for an alternative title suggestion [12:36] zyga: I have no commit access to snap-confine, so no [12:37] slangasek: can you propose a pull request [12:37] slangasek: I've made a lot of improvements now and lintian is much happier [12:38] zyga: well, I don't have any packaging changes yet for snap-confine because I still only have ubuntu-core-launcher in Debian; so those would need to be rebased [12:38] slangasek: ok [12:38] slangasek: you should now be able to use 1.0.29 as a base for debian [12:39] slangasek: just change packaging to not call --enable-rootfs-is-core-snap [12:39] slangasek: and call --disable-confinement [12:39] slangasek: that will make it work [12:39] ok [12:40] slangasek: we should be able to do non-native packages [12:40] slangasek: I don't know if you want to make that happen [12:41] zyga: so that's just 1.0.29+1 -> 1.0.29+2 for Debian, with the above changes? [12:41] mhm [12:41] yep [12:41] and run some snaps to make sure it all works [12:41] but I think w'ere good [12:41] non-native package would make sense to me, but I wasn't going to insist just yet [12:41] ok [12:42] zyga: so looking at 1.0.29, I don't see --enable-rootfs-is-core-snap set anywhere [12:43] or supported in the code [12:44] popey: so, snappy-debug mentioned what you need: add one of 'firewall-control, network, network-bind, network-manager, unity7, x11' to 'plugs' [12:44] popey: I suggest using plugs: [ network ] [12:45] davidcalle, replied, thanks! [12:45] popey: especially if the application is trying to use the network (which is a safe bet, but only the snap author would know) [12:45] jdstrand: ahh, network-manager and firewall-control were new ones on me [12:45] gotcha [12:47] https://developer.ubuntu.com/en/blog/2016/06/13/Snapcraft-210-zip-files-devmode-and-macaroons/ [12:51] zyga: so yeah, I don't see how to do what you're describing on 1.0.29 [12:52] jdstrand: added all those plugs and it fails in the same way [12:54] slangasek: one sec [12:56] mvo, zyga: do you guys know why snapd is still stuck in -proposed? [12:58] dholbach: its a bit unclear if all the verification is finished, we are discussed this right now with the sru guys [12:59] go go go! :) [12:59] let me know how things go [13:04] mvo: somewhat related, I see snapd 2.0.8+16.10 is still stuck in yakkety-proposed due to new autopkgtest failures [13:04] (these autopkgtest failures also show up on http://people.canonical.com/~ubuntu-archive/pending-sru.html, but I guess we'll ignore them...) [13:05] dholbach, mvo, on http://people.canonical.com/~ubuntu-archive/pending-sru.html snapd has unverified bugs (not all green) [13:05] zyga, ^ too [13:05] yes, including the only bug that is /supposed/ to matter, which is bug #1588052 ;) but they've been tagged v-done now [13:05] bug 1588052 in snapd (Ubuntu Xenial) "[SRU] New stable micro release" [Medium,Fix committed] https://launchpad.net/bugs/1588052 [13:06] oh, but https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1580463 still hasn't been [13:06] Launchpad bug 1580463 in apparmor (Ubuntu Yakkety) "Snap blocks access to system input methods (ibus, fctix, ...)" [Medium,In progress] [13:07] right [13:07] popey: you should've only needed the one plug 'network'. does it fail in exactly the same way? if so, can you uninstall then install again? [13:08] slangasek, mvo, btw the i386 test issue looks like it's bug #1576066 [13:08] bug 1576066 in libseccomp (Ubuntu) "32bit glibc calls old socketcall() syscall, causing seccomp problems" [High,Confirmed] https://launchpad.net/bugs/1576066 [13:08] slangasek, seb128 let me verify that [13:08] (1580463) [13:08] (in a meeting right now) [13:08] jdstrand: yes, it fails in the same way, i completely removed, rebuilt and reinstalled. [13:09] well allowing socketcall should make it work, that's the workaround I was using locally [13:09] jdstrand: not using --devmode btw, should I? [13:09] popey: are you sure it failed in the same way? look at the timestamp-- is it the same as the one in the paste? [13:09] seb128: right; strange, I somehow thought that one was already fixed in 2.0.8 [13:09] jdstrand: http://paste.ubuntu.com/17289635/ looks same to me [13:10] -rw-r--r-- 1 alan alan 90206208 Jun 13 13:51 wine_1.6-git_amd64.snap [13:10] popey: it might be failing cause of something other than the sandbox but showinng you the olddenial [13:10] snap built and installed just before that error [13:10] slangasek, well, the snappy update "fixes" it by allowing socketcall, the real bug to fix is that libseccomp one though [13:10] slangasek, the "fix" is only a workaround [13:10] jdstrand: paste shows time delta between the two reports [13:10] slangasek, I was just pointing in case you didn't see the libseccomp one [13:10] seb128: but 2.0.8 is still failing, so not worked around after all [13:10] oh ok [13:10] I didn't try that [13:10] popey: ok-- can you paste your yaml? [13:11] slangasek, mvo marked the bug verification-done though? [13:11] seb128: the syscall one is fixed in git [13:11] slangasek: falling with a bad syscall? [13:11] jdstrand: sure [13:11] hi, why not allowing "cross compilation" for the "copy" plugin in snapcraft? [13:11] mvo, fixed? like you fixed libseccomp/bug #1576066 [13:11] bug 1576066 in libseccomp (Ubuntu) "32bit glibc calls old socketcall() syscall, causing seccomp problems" [High,Confirmed] https://launchpad.net/bugs/1576066 [13:12] should just be a matter of adding def enable_cross_compilation: pass, no? [13:12] mvo, or "fixed" like you allowed socketcall? [13:12] seb128: yes, we allow this now [13:12] jdstrand: http://termbin.com/nlou my yaml [13:12] allowed socketcall until it can be properly fixed [13:12] k [13:12] seb128: ^ [13:12] so workarounded [13:12] wfm [13:12] jdstrand, mvo, thanks [13:12] oh, sorry, yeah, not "fixed" but "worked-around" [13:12] mvo: the current i386 autopkgtest for 2.0.8 is failing, no messages about syscalls in the log [13:13] popey: you should change that to: plugs [ network, unity7, opengl ] [13:13] ok [13:13] popey: not that it will fix the issue, just fyi [13:13] popey: can you paste /var/lib/snapd/profiles/snap.wine.wine? [13:14] popey: whoops [13:14] /var/lib/snapd/seccomp/profiles/snap.wine.wine [13:14] jdstrand: ok [13:16] ysionneau, well, to do it properly you would have to enable multiarch on the host machine so it can find the foreign arch packages in the archive [13:17] there is a bit more to it [13:17] ogra_: maybe there's something I don't get, I thought "copy" was just "dummy copy files" [13:17] which does not imply compiling anything [13:17] it allows stage-packages [13:18] ogra_: where is the source for the freecad snap? [13:18] mhall119, no idea ... you have to ask the developer :) [13:18] well you mentioned it specifically when talking about translations support in snaps, so I assumed you knew something more about it :-P [13:19] mhall119, i pointed vejmarie to my nethack snapcraft.yaml and he adapted it for his freecad build ... [13:19] jdstrand: http://termbin.com/d8i8 - sorry for the delay - wanted to rebuild with your changed plugs first [13:20] ogra_: anyway, it would be good to allow using copy to just copy files, when you cross compile [13:20] seb128, slangasek: fyi, 1580463 is now verification-done [13:20] jdstrand, thanks [13:21] popey: hmm, so , the policy has recvfrom. Can you run scanlog now, then try to launch the app again and let me know if you get a new entry from scanlog? [13:22] mhall119, https://linuxfr.org/users/vejmarie/journaux/mon-premier-snap-sur-xenial has the snapcraft.yaml [13:22] jdstrand: same, recvfrom [13:22] jdstrand, that's not enough to get ibus to work though, should I open a new bug about that? [13:22] that is strange [13:22] jdstrand: http://paste.ubuntu.com/17289866/ [13:22] seb128: what else is needed? [13:23] thanks ogra_ [13:23] seb128: but to answer your question-- yes, that bug was about policy violations, what you need will not be a bug in the policy [13:23] jdstrand, I need to re-test to make sure, but iirc ibus tries to get the ibus-daemon bus id from ~/.config/ibus [13:23] jdstrand: this might be a factor... /snap/wine/100001/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=8d1c78fd3bb1c66399c240ccb4c0b1e6e64d961e, not stripped [13:23] 32-bit binary [13:23] (I'm on amd64) [13:24] jdstrand, which is not available in the snap (or not under that path in any case) [13:24] seb128: we allow that in the policy, but the snap is going to have to find it somehow. I think the problem is that HOME is set to ~/snap/$SNAP [13:24] right [13:24] which is still an issue to solve [13:24] I guess ibus needs to be patched [13:25] seb128: perhaps before you exec your app, have it do: "cd $HOME/../../" [13:25] ogra_: am I missing something, or are both examples hard-coding en_US as the locale? [13:26] seb128: there are different ways to handle it. what I suggested would be a workaround, but might break the app in a different way (since maybe it need HOME to be ~/snap/$SNAP [13:26] jdstrand, in fact ibus should use the xdg dirs so the env should make it work, let me re-test to make sure it really doesn't [13:26] * jdstrand nods [13:27] popey: that was my next question actually [13:27] heh [13:27] popey: let me run the command in an x86 chroot [13:28] slangasek: I believe the current i386 failure is a different one, I'm trying to reproduce this as we speak (I think its a new one :( [13:34] popey: on i386 it is 'brk' which is in the policy [13:35] popey: are you on yakkety or xenial? [13:36] popey: are you using an ubuntu kernel? [13:36] popey: can you give me the snap? [13:36] basically, it should not have that denial based on the policy [13:37] popey: are you using snap-confine/snap-run and not ubuntu-corelauncher? [13:37] ubuntu-core-launcher* [13:41] popey: actually, nm. I know the issue. it *is* that it is 32 bit and running on amd64. what is happening is that because it is amd64, it is getting the amd64 seccomp translation, but it needs the i386 filter translation. please install in --devmode [13:43] popey: or better-- install 64bit version in the snap [14:07] zyga: sorry, any further guidance on snap-confine? [14:16] slangasek: anything else pending on the snapd 2.0.8 release? anything we can or or need to do? [14:18] ysionneau the copy plugin needs a simple fix if you want to use it with `--target-arch` (look at the tar plugin if you want to create a PR, will gladly accept), a unit test would be nice as well [14:18] mvo: not from my side; I gathered you were talking to infinity about it, was he going to hit the publish button? [14:20] slangasek: I was only talking via ogra_as my proxy :) so no idea what the status is [14:20] ok [14:20] mvo: released [14:20] \o/ [14:21] mvo: I would love to have a version newer than 2.0.2 releasable to yakkety (autopkgtests); among other things it would clean up component-mismatches [14:24] slangasek: I tried to figure out why yakkety fails last week without much success so far, the errors are a bit strange and its exactly the same snapd code as in xenial that is tested, but I give it another go today and tomorrow (sorry that I don't have a better answer currently) [14:25] mvo: no worries, just want to make sure it's still on the list [14:25] thank you! [14:35] jdstrand: I am on xenial, 4.4.0-23-generic [14:35] jdstrand: it's a 32-bit app. the 64-bit version of the snap contains a 32 bit build of the app [14:44] sergiusens < I did the fix locally, but I stopped submitting PR to snapcraft since some test never passes and the PR never gets accepted [14:46] How close/far are you from a stable Snappy base image? [14:47] oparoz, every time we have to answer that question the image gets delayed by 1 day :) [14:47] lol [14:47] Sorry, I thought you were really close :) [14:48] "stable" is still far out ... a "first shot" might be a matter of 1-3 weeks [14:48] Thanks ogra_, that's useful info :) [14:48] (first shot meaning you will not have to re-flash) [14:48] dont take these numbers as official though ... i'm broadly guessing here [14:49] Yeah, that'll be good. Something which can be built by anyone and doesn't require a reflash [14:49] Still useful, I haven't followed the latest development and was just wondering :) [14:51] slangasek: hey [14:51] slangasek: yes, let's talk about it [14:51] slangasek: when you said that this option didn't exist, where did you look? [14:52] slangasek: I suspect you looked at the launchpad tree [14:52] zyga, he just went with his laptop in the backpack [14:52] slangasek: did you see https://github.com/ubuntu-core/snap-confine/releases/tag/1.0.29 [14:52] ogra_: :) [14:52] ogra_: thanks [14:55] popey: https://bugs.launchpad.net/snappy/+bug/1592022 [14:55] Launchpad bug 1592022 in Snappy "32 bit applications on 64 bit system fail due to seccomp" [Undecided,New] [14:57] jdstrand: do you still need the snap? [14:58] popey: no. I can reproduce with /bin/ls [14:58] ok, thanks [14:58] popey: not, my gut says that is not going to be fixed any time soon [14:58] but investigation needs to be had [14:58] ok, will back-burner that one then [14:59] thank you [14:59] popey: if you could find a 64 bit wine, it would work fine [14:59] yeah, I expect so, but it would not be useful :) [14:59] no? [14:59] i believe not, but will test [14:59] why not? [14:59] fyi, Debian has 1.8.2 [15:00] ok, will play more :) [15:25] sergiusens: so how does the translations in nethack work, do you include all the language files in the snap? [15:26] mhall119 I don't know what nehack uses, can't really answer that [15:27] but I would imagine that is a start [15:28] ogra_: have you guys finished working for today? [15:29] sergiusens: ok, I'm just lost reading these launcher scripts trying to figure out what is actually being done :( [15:30] ogra_: ^^ I guess you'd be the one to help with nethack, not sergiusens [15:35] slangasek: autopkgtest on i386 works for me https://github.com/snapcore/snapd/pull/1316 [15:36] slangasek: with that branch, so hopefully (and I know I promised this last time) with the 2.0.9 we have xenial/i386 green [15:44] Has anyone seen a similar error message, or am I doing something wrong? [15:44] - Download snap "ubuntu-clock-app" from channel "stable" (received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/download-snap/vjQhIxU28Zszo6iEjbbrmosRqSpBq4GD_5.snap) [15:45] that was after doing `sudo snap install ubuntu-clock-app` [15:48] actually, it seems I can't install any snaps now :/ [16:04] so, I just published a snap on beta/edge channels. How do I get/install those? [16:05] (has to be beta, as it is devmode) === chihchun is now known as chihchun_afk [16:14] Sweet5hark: snap install --channel=beta ... [16:17] https://bugs.launchpad.net/snappy/+bug/1591664 [16:17] Launchpad bug 1591664 in Snappy "'snap install' should support --beta, --candidate and --edge options" [Medium,In progress] [16:21] pedronis, should that work for snap find too? [16:25] pedronis: thx [16:34] willcooke: snap find only searches stable [16:34] thx noise][ [16:39] hello, i tried to install a snap app on Ubuntu Desktop 1604 then I interruppted installation with Ctrl+C as slow networking. Now I get 'snap: "ubuntu-core" has change in progress' when I tried to install again. How I can resume installation or reset to initial state? [16:45] shuduo: I have gotten this at least three times. It needs a really good bug report. Do you think you can write it? [16:59] qengho: OK. let me do it. [17:00] elopio coming back to the environment fixture, is there a way to clear the complete environment? [17:00] elopio that is what I want [17:02] sergiusens: EnvironmentVariable('PATH', None) [17:09] qengho: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592074 [17:09] Launchpad bug 1592074 in snapd (Ubuntu) "ubuntu-core is change in progress after interrupt "snap install"" [Undecided,New] [17:13] elopio whatabout every other environment variable exported in my running environment? [17:14] elopio do I need to do a for k in os.environ.keys()? [17:14] elopio look at the test and you will understand :-) [17:15] sergiusens: ah, so you want to have no env var. Yes, I would write a new fixture that does os.environ = empty, and resets it in the cleanup. [17:15] sergiusens: https://github.com/testing-cabal/fixtures/blob/master/fixtures/_fixtures/environ.py [17:17] elopio btw, have you taken a look at `pytest`? [17:18] sergiusens: never tried it seriously. Do you want that instead of testtools? [17:21] shuduo: I filed a sister bug report for something similar: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592088 [17:21] Launchpad bug 1592088 in snapd (Ubuntu) "snap command doesn't finish when snapd already gave up" [Undecided,New] [17:30] I'm dumb for asking this before justtryitalready, but I use avahi/zeroconf to advertize that my services exist and where. There can be only one zeroconf daemon listening on port Whatever, so services use dbus or something to ask the zeroconf daemon to advertize on their behalf. How could that work in a snappy world? [17:32] I see someone's packaging Squid, for instance. My cache-needy client could discover that over zeroconf requests. But, I don't know how the squid snap would advertize itself. [17:41] Assume I ship my own zeroconf in case there is no system one. Or something. [17:41] elopio can you look at the gulp PR again? [17:41] elopio I am not saying I want to, just asking what your opinion was [17:41] sergiusens: running through the document now. Give me a few minutes. [19:58] Hey folks! I'd like one of the commands in my snap to call another, but if I just say "foo", it uses the actual binary in $SNAP/bin, and I'd like for it to use the wrapper in /snap/bin/foo. Is it OK to use an absolute path here? [20:00] roadmr, so, snaps are meant to be confined, so generally not easily able to call each other [20:00] beuno: this is the same snap [20:00] oh, so snapname.binary should work [20:01] I think absolute paths are fragile [20:01] beuno: oh, I may be able to hack that... [20:01] beuno: yes, agreed, that's why I'm looking for advice :) [20:02] beuno: the snap is called bar, so it has two binaries in /snap/bin: bar and bar.foo; the thing is that bar.foo should call bar but if I just say bar, it goes to $SNAP/bin. But maybe I can put bar in bar-baz or something so I get the namespacing. OK, hacking! [20:02] roadmr, wouldn't bar.bar work? [20:02] (basically if the command's name is the same as the snap's, it collapses them so it's not bar.bar haha) [20:02] beuno: hm, let me try that [20:03] beuno: no, doesn't work :/ no biggie, let me shuffle my wrappers [20:19] is there a way to get an offline or pdf version of the snappy documentation? I want to learn snap but I'd like to read most of the docs offline [20:27] roadmr beuno instead of calling the exposed binary name call the internal one, that is the guidance I got from jdstrand [20:28] sergiusens: thanks for looking into this! much appreciated, I'll try that [20:28] (I had it working with the external one but let's try with the internal command) [20:29] elopio added an integration test for gulp [20:29] roadmr might work in devmode, but once confined doing the seccomp or apparmor pivot might be hard [20:30] sergiusens: exactly the problem I'm having - only works in devmode :( [20:31] roadmr so calling the internal binary should solve that [20:42] "Parts 'gnuchess' and 'glue' have the following file paths in common" - is there a way to force overwriting the file in common? I want to replace the one that part A creates with one from a "glue" part which is better-customized [20:43] A == gnuchess btw [20:51] Hi everyone. O have a question. I developed an app for my job and I want to snap it. My problem is that when I start my app it does not show the window. I have this problem with some snaps. Can someone point me in the right direction? [21:00] elopio: you around? [21:01] zyga: ok, so your 1.0.29 tag doesn't match the 1.0.29 that was already uploaded to the archive; you might want to do a bit of revision surgery there [21:11] ok, so in --devmode, one of the binaries in my snap does "exec" and calls the other successfully. Without devmode, I don't even see the "exec" call (denied or otherwise) in syslog. Is there some magic needed to allow exec? [21:11] (a plug maybe? none of the ones I see in "snap interfaces" sounds topical) [21:24] slangasek: I moved the tag one commit further to ship tests in the tarball [21:24] slangasek: sorry, you just saw the wrong window there ;) [21:25] zyga: \o/ which plug do I need for a command in my snap to be able to use the setpriority syscall? [21:25] roadmr use the snap, stage and organize keywords [21:26] sergiusens: I'll read up on those :) whee [21:26] * roadmr probably just needs to dive into the docs [21:27] zyga: no... ubuntu-core-launcher 1.0.29 was uploaded to Ubuntu on 10 May, your 1.0.29 doesn't match the "real" 1.0.29 that already exists [21:27] roadmr `snapcraft help plugins` [21:28] sergiusens: oh great! thanks! heh === Aria22|away is now known as Aria22 [21:40] anyone use chef or puppet or similar with core ? [21:44] elopio http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1056/console about this [21:44] elopio would be good if we `set +e` after the tests run (or right before) to not be affected by that error ^ [22:44] so, I have a libreoffice.canonical package uploaded and published to beta and edge channels of the store, but "sudo snap install --devmode --beta libreoffice.canonical" or "sudo snap install --devmode --beta libreoffice" both return that the snap could not be found. any help?