=== ben_r_ is now known as ben_r === ben_r_ is now known as ben_r [01:39] I am getting “cannot communicate with server” issue when trying to install. Anyone knows how to resolve this issue? snapd seems to be running [01:39] sudo snap install --dangerous cwr_0.1_amd64.snap [01:39] error: cannot communicate with server: Post http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused [01:54] ses__: what does "sudo systemctl status snapd.service" show? [01:55] thomi: http://pastebin.ubuntu.com/23855366/ [01:56] https://wompwompwomp.com/ :( [01:57] hmmm [01:57] thomi: seems missing some text http://pastebin.ubuntu.com/23855373/ [01:57] in any case, "Active: inactive (dead) (Result: exit-code) since Mon 2017-01-23 17:31:11 PST; 24min ago" doesn't sound healthy [01:58] I'm trying to recall where the logs are [02:01] ses__: I don't suppose you recently ran snapd from source, and now are trying to run the system version? [02:04] thomi: no [02:04] thomi: I restarted the machine but still having the issue [02:04] hmmm - I'm not a snapd dev, and I'm not sure how to help you any more. I've encountered a similar issue once myself after running snapd from source. Since that doesn't match the situation you're in, I'm not sure what else to suggest [02:05] This timezone isn't great for catching the snapd devs - you might want to consider mailing the snapcraft mailing list [02:05] thomi: thanks [02:05] thomi: what time are they usually here? Timezone? [02:07] I believe they're mostly Europe/US - vague, I realise, sorry :D [02:24] Hello, I'm traying to setup a snap store based on https://github.com/noise/snapstore but i'm getting this error: error: cannot communicate with server: Post http://localhost/v2/snaps/foobar25: EOF when I try to install a package. Any ideas ? [02:31] azubieta_: there a few things to be aware of… first, there's a branch "metadata_tests" that I have yet to merge that updates support for the newer API endpoints [02:32] noise: oh! so i must use the code from that branch instead ? [02:33] however, even with that, newer snapd versions will not install local snaps from that store because they will lack the assertions to verify their authenticity. snapd allows you to snap install foo.snap —dangerous from a local file (sideloading) but does not allow it for a remote store install [02:34] we have started discussing how to allow for different trust chains so your own store deployment can be trusted but we don't have firm plans or timeline for that currently [02:34] noise: i would like to create a fulle functional, snapd compatible and opensource snap store, but according to what you say they don't allow it [02:35] noise: besides your work is there another opensource project that i could check ? [02:36] that's correct for right now - we will allow that but at the moment you would need to work around the assertions check by doing a download and install separately [02:36] ok [02:38] i.e nothing is stopping a solution that fetches the snap files from a server and then does "snap install —dangerous", but we aim to support alternate stores directly in snapd === chihchun_afk is now known as chihchun [08:05] PR snapd#2666 closed: interfaces: add ability to set system time zone to timeserver_control interface [08:05] PR snapd#2679 opened: Ubuntu/14.04 [08:05] PR snapd#2585 closed: debian: move systemd files out of ./debian and into ./data/systemd [08:14] good morning === hikiko_ is now known as hikiko === faenil is now known as faenil_ [10:33] Mornings [10:38] PR snapd#2666 closed: interfaces: add ability to set system time zone to timeserver_control interface [10:38] PR snapd#2679 opened: Ubuntu/14.04 [10:38] PR snapd#2585 closed: debian: move systemd files out of ./debian and into ./data/systemd === chihchun is now known as chihchun_afk [11:36] Hi! What endpoint does snap info call ? === hikiko is now known as hikiko|ln === mardy_ is now known as mardy === hikiko|ln is now known as hikiko [12:32] om26er: hey [12:32] om26er: I think that's a question for chipaca [12:32] om26er: I bet it also depends on the version of snapd as that area saw some development [12:34] zyga: Ok, will ask him, I needed information about available revisions of snaps from different channel, I could use grep for that but was looking if there was cleaner way I could achieve that [12:37] you called? [12:38] Chipaca: hey [12:38] 12:36 < om26er> Hi! What endpoint does snap info call ? [12:38] :-) [12:38] om26er, if you want info directly from the store you can always use something like : curl -s https://search.apps.ubuntu.com/api/v1/snaps/details/?channel= -H 'X-Ubuntu-Series: 16' -H 'X-Ubuntu-Architecture: ' [12:38] om26er, why do you ask? [12:39] Chipaca: I need to get available revisions for a snap in different channels [12:40] om26er, what for? [12:41] Chipaca: for CI purpose whenever something is merged in snapweb master, it gets pushed to edge channel automatically, I need to check if the newly pushed snap is published before trying to install it and run tests on top of that. [12:41] om26er, doesn't snapcraft already give you that info? [12:42] or are these things disconnected? the pushing and the checking i mean [12:42] om26er, the store is still working on exposing this information, so right now for 'snap info' i'm doing a separate (rather arcane) query just for that [12:43] om26er, hitting /v2/find?name=foo on snapd will get you the channel map, if that's what you need [12:43] Chipaca: I haven't looked at the output of snapcraft push, if it returns that result, we can probably use that as well. [12:43] yes, snapcraft push returns the channel map [12:44] from SCA [12:44] snapd talks to CPI [12:44] if you've already got snapcraft talking to SCA, that's better for this than having snapd talk to CPI for it [12:45] om26er, let me kknow if that's covered what you need please [12:46] om26er, please ACK so I can move on from this [12:47] Chipaca: yes, one of our script uploads to the store through snapcraft, so will get the output from there. [12:47] Chipaca: thanks for the info [12:47] np [12:50] jibel: yeah, just tried, that endpoint seems to work as well. [13:57] so ive got my snap working on 16.04 with a systemd script, 14.04 is throwing this error at me though http://paste.ubuntu.com/23857838/ [13:57] do i have to define anything differently to get my systemd scripts working for 14.04 in a snap env? [14:29] sergiusens: what's the proper way for a snapcraft test case to handle downloading a source file? [14:43] mhall119: unit test or integration test? === chihchun_afk is now known as chihchun [15:00] elopio: integration I would think? [15:04] mhall119: for integration, you can probably put your source in people.ubuntu.com, write a real snapcraft.yaml that uses it, and call the pull command in the test. [15:04] ok, cool, thanks elopio [15:06] mhall119: there is an ftp you can use as a guide in snapcraft/integration_tests/snaps [15:06] elopio: just found that one [15:12] mhall119, for the unit test we create files on the fly === chihchun is now known as chihchun_afk [16:51] Is there a way to prevent the snap name prefix from being added to a snap command? For example, I have a snap with the name "cni-loopback" and the command "loopback". The generated command is "cni-loopback.loopback". Is there a way to make the command name simply "loopback"? (without renaming my snap to loopback) [16:53] ryebot, support was recently added for command aliases [16:53] ryebot, which essentially allows you to promote prefixed commands into the non-prefixed domain [16:53] kyrofa: excellent, I can google now, thank you :) [16:54] ryebot, https://github.com/snapcore/snapcraft/blob/master/integration_tests/snaps/alias/snapcraft.yaml [16:54] there is an example [16:54] ryebot, note that it requires snapd v2.20 or later [16:54] ogra_ kyrofa: you guys rock, thanks for the help! [16:55] Any time :) [16:56] (sometimes we also roll ;) ) [16:56] When we eat too much [16:56] haha [16:57] XD [17:01] niemeyer, hey, I was trying to import spread tests in our grafana instance, and I was wondering if should be make spread to export test results in a well know format so it is easy to import from anywhere? [17:01] niemeyer, I can add a mp if you think it would be a good idea [17:02] cachio: Yeah, that sounds nice for sure [17:02] cachio: I suggest doing that as a small function which is run at the very end of the runner's life cycle [17:03] cachio: We already have a stats type and value at hand, so it should be super easy to just take that as an argument and generate a file in a well known format based on an option which the runner already has easy access to [17:04] niemeyer, ok, make sense, any preference with the output format? [17:05] cachio: Are there a few options which grafana can already interpret, or is that manual anyway? [17:05] niemeyer, the we run a tranlator to export it to grafana [17:06] we already have for pyunit for example [17:07] niemeyer, so I need then either to send from travis to grafana the resutls, or to import it from jenkins and send it to grafana [17:08] niemeyer, should be easier if we could send directly from travis to grafana which is a production service hosted in prodstack [17:10] cachio: If you need to manually parse and translate into grafana anyway, then I wouldn't worry about changing spread, at least I wouldn't begin there [17:16] niemeyer, I already have the translation from xunit pyunit into grafana schema [17:16] cachio: Yeah, xunit is probably a good choice [17:17] niemeyer, ok, i'll implement that [17:24] niemeyer, are you already sending spred results to any canonical service? [17:24] cachio: Nope.. [17:45] ogra_: alecu: following up on the post to the snapcraft ML about GFX on pi3... [17:46] it seems the latest snapd is no longer autoconnecting the mir-libs interface? at least that's what I'm seeing with ogra_'s latest image from http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ [17:46] AlbertA, it does for me [17:47] i have to manually connect the mir interface, but mir-libs is autoconnected [17:47] ogra_: alecu: mir-kiosk:mir-libs is autoconnected for you? and which snap version are you running? [17:47] snap list [17:47] Name Version Rev Developer Notes [17:47] core 16.04.1 970 canonical - [17:47] mir-kiosk 0.1 20 canonical - [17:47] mir-libs 0.1 20 canonical - [17:47] pi2-kernel 4.4.0-1040-47 26 canonical - [17:47] ogra@localhost:~$ snap version [17:47] snap 2.21+ppa215.5a5f1500-1 [17:47] pi3 16.04-0.5 14 canonical - [17:48] ogra_: oh but without --devmode ? [17:48] yep ... worked for me (i dont have any mir stuff on the current image though) [17:48] gimme a moment [17:49] I found it odd that devmode is gone after disabling and reenabling a snap [17:49] Finishing lunch, I'll try it in a few minutes [17:49] might be a feature ... not sure ... [17:50] alecu: so in an any case, you can connect it manually - snap connect mir-kiosk:mir-libs mir-libs:mir-libs...then have to workaround a snap content i/f bug [17:50] zyga, niemeyer ^^^ if you dis/enable a snap devmode gets dropped, is that wanted ? [17:50] AlbertA, hmm, right, not connected here either now [17:51] do: snap disable mir-kiosk; sudo /usr/lib/snapd/snap-discard-ns mir-kiosk; snap enable mir-kiosk [17:52] ogra_: ok, I'll read the content i/f docs.. maybe something changed now [17:52] well, the namespace stuff landed and the gadget grew support for gpio interfaces in core [17:52] neither should have caused an issue though [17:53] ogra_: yeah well just thinking maybe I'm missing a field or something when specifying the content i/f plug now [17:53] ogra@localhost:~$ snap interfaces|grep mir [17:53] :network mir-kiosk-apps,pulseaudio [17:53] :opengl mir-kiosk,mir-kiosk-apps,unity8-session [17:53] mir-kiosk:mir mir-kiosk-apps [17:53] mir-libs:mir-libs mir-kiosk-apps [17:53] - mir-kiosk:mir-libs [17:54] so mir-kiosk-apps autoconnect [17:54] mir-kiosk doesnt [17:54] huh.... interesting. [17:55] I'll take a look at that, I did change the snapcraft.yaml last time [17:55] ah [17:56] I'll revert that change and republish [18:03] Will we ever see the promised snapped firefox? [18:11] Blu2, I expect so, but it's not being done by us [18:13] alecu: ogra_: ok a new revision of mir-kiosk was just pushed (rev 22 for armhf) that autoconnects fine [18:13] to mir-libs [18:13] Wonderful [18:14] kyrofa, I know, I was hoping somebody knew something about it here :) [18:15] Blu2, not me anyway. That's all mozilla [18:15] AlbertA, thanks ! [18:21] kyrofa, I thought they may be here in this chat [18:21] Blu2, fair enough, they may be :) [18:28] I am having issue communicating with the server during installation snapd seems to be running okay but have some issue. Anyone knows how to resolve this issue https://pastebin.ubuntu.com/23859088/ [18:29] ses__, that doesnt seem to be running [18:29] Jan 24 09:02:11 me-vm systemd[1]: snapd.service: Start request repeated too quickly. [18:29] Jan 24 09:02:11 me-vm systemd[1]: Failed to start Snappy daemon. [18:30] ogra_: https://pastebin.ubuntu.com/23859105/ [18:32] well, systemd disagrees ... and you should also not see two snapd processes ... looks more like something hangs or respawns very fast [18:32] if you do the ps -A again i bet you see new pids [18:32] what are you running this on ? is that a native ubuntu install ? [18:33] I see the same pids [18:33] 16.04 [18:33] using a normal ubuntu kernel ? (uname -a ? ) [18:33] apt install [18:33] Linux me-vm 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux [18:33] looks ok [18:34] does snap list work ? [18:34] (if so, which core snap is installed ? ) [18:35] No it doesn’t work [18:35] Cannot communicate with the server [18:35] right ... [18:36] ls -l /snap/*core [18:36] does that return anything ? [18:36] ogra_: yes. I see “1357 current” dirs [18:37] thats ok too [18:37] i wonder why it doesnt start ... [18:37] anything in syslog ? [18:38] ogra_: there is something in syslog. Any key words I search for? [18:42] ogra_: (as for devmode being dropped, probably not but not sure (I wish we would write design down) [18:42] ) [18:42] I hate when I drop ) [18:42] ogra_: maybe this is relevant https://pastebin.canonical.com/176943/ [18:45] zyga, btw, ses__ is the third person in 4 days that has a non-starting snapd [18:46] ogra_: !!!! [18:46] ogra_: can you tell me more? [18:46] ses__, hmm, do you have livepatch installed ? [18:46] ogra_: yes, there was other people having the same issue last night in this channel. [18:48] ogra_: I didn’t install livepatch [18:48] ses__, ah, no, i was confused by the kernel messages in the paste [18:48] zyga, any idea ? https://pastebin.canonical.com/176943/ [18:49] ogra_: but I installed snapd yesterday [18:49] ses__, and you didnt have snapd installed before ? [18:49] ogra_: first time installing it on a new machine [18:50] (you seemingly have /snap/ubuntu-core there instead of /snap/core ... that kind of indicates an older install ) [18:50] (new installs should always get the core snap installed, not ubuntu-core anymore) [18:51] looking [18:51] bloody hell 2fa [18:51] heh [18:51] yeah [18:52] snapd[18866]: error: cannot patch system state from level 3 to 4: cannot get snap state for "cwr": [18:52] seems the most relevant bit [18:52] ogra_: AlbertA: with the latest mir-kiosk, I get the black screen and (laggy!) pointer on the raspi2. But, when I try to start the mir-kiosk-apps all of mir freezes on the second frame, just like what I saw yesterday on the raspi3 [18:52] ok logged in [18:52] alecu, disconnect/connect ? [18:52] that bug is fixed in master I think [18:53] alecu, i usually need to do that once for the -apps [18:53] and I think it was released in 2.21 [18:53] ogra_: after a disconnect and connect, yes. [18:53] zyga, "released" [18:53] zyga, us normal users all have 2.20 still [18:53] upstream release [18:53] blame the SRU process [18:53] 2.20.1ubuntu1 to be precise [18:53] what can I do? [18:53] dunno [18:53] ogra_: sorry, after a disable and enable of the snap package. Will try disconnect [18:54] zyga, trust your colleagues i was told :P [18:54] anyway that shows trying to use snapd before upgrading snapd [18:54] ogra_: I trust all of my colleagues [18:54] alecu, yeah, that needs both ... disable, disconnect, connect, enable [18:55] let's see when we can make it available to everyone [18:55] alecu, like the mir wiki describes [18:55] and at some point the content interface will just woork ;) [18:56] if you have the pointer on black screen mir itself is definitely running fine [18:57] my kodi snap is sadly currently broken (i tried to build the latest master which has the mir patches but also broken kodi ... ) ... so dont bother with that [19:01] ogra_: is there anything I can now to go around this issue? [19:01] ses__, do you have many snaps installed already ? [19:01] i'd try to purge snapd and install it again [19:01] perhaps that helps ... [19:02] (but thats just ut of desparation ... ) [19:02] ogra_: should I also uninstall snap? [19:02] i know it works on all my xenial installs over here [19:02] snap is a commmand shipped by the snapd package [19:02] so purging snapd should be enough [19:02] and then just install t again [19:03] then try something from the store ... like snap install htop ... that should pull in the core snap alongside [19:03] once you knwo it works, you can start plying with your local snap that you tried to install before [19:04] ogra_: ok, will do “sudo apt-get remove --purge snapd” [19:04] sudo apt purge snapd ... less typing ;) [19:04] (same thing though) [19:07] alecu: you will need --devmode [19:07] alecu: I'm seeing some new syscalls with this driver, so I'll need to update the mir interface [19:08] AlbertA: devmode for mir-libs, mir-kiosk and mir-kiosk-apps ? [19:08] alecu: mir-kiosk and mir-kiosk-apps yeah [19:09] the interesting part is that ps shows miral-kiosk as defunct but yet it still runs... [19:11] magic ;) [19:12] (also known as "the zombie apocalypse is near") === faenil_ is now known as faenil [19:22] AlbertA: ogra_: after installing both -kiosk and -kiosk-apps with devmode, it all seems to be working ok on the raspi 2. [19:22] thanks a lot!!! [19:24] alecu, "ok" = greater than a single frame? [19:24] kyrofa: I get plenty of frames now :-) [19:24] no end in sight [19:24] alecu, I really wanted to reply to your email and say "stop moving the mouse!" [19:24] lol :-) [19:25] alecu, nice to see you around by the way! [19:40] alecu, awesome ... sorry that you had such a bumpy ride [19:43] it's the early days of the raspi image... totally understandable. [19:51] kyrofa: I'm hitting some issue with the aliases, any idea what I might be doing wrong? https://gist.github.com/wwwtyro/aa34ccb81f6928f2bda37b32c7a00c1f [19:52] ryebot, I know you need to enable them somehow (it's not done automatically without an assertion that happens store-side) [19:53] ryebot, `snap alias` perhaps? [19:53] ah, okay [19:53] so it might not work if installed locally? [19:53] ryebot, not work == not automatically enabled? Yes [19:54] kyrofa: gotcha, thanks. seems to work! [19:54] thanks again! [19:54] ryebot, excellent! Of course [19:55] jdstrand, how does one request aliases to be automatically granted? Is it all manual right now, or is there a process for it? [19:56] kyrofa: it's manual [20:03] jdstrand, is there anyone familiar with systemd wrt 14.04 snaps? [20:03] jdstrand, trying to figure out why my snap is failing to install [20:04] ses__, did you get anywhere with reinstalling snapd ? [20:04] stokachu: tvoss spearheaded the effort and I think slangasek may have poked at systemd, but perhaps ask your question here and maybe someone will know [20:05] jdstrand, thanks [20:05] it was basically this email https://lists.ubuntu.com/archives/snapcraft/2017-January/002706.html [20:05] it just seems to not find a systemd service file [20:05] ogra_: I am trying it now. Distracted by other tasks [20:05] ah, no worries [20:05] Main PID: 1548 (code=dumped, signal=SEGV) [20:06] * ogra_ grins about stokachu's last paragraph in the mail ... getting rid of maintainer scripts are one of the reasons we started snaps :) [20:06] there is no snap.conjure-up.bridge.service in /etc/systemd/system [20:06] but that does exist in 16.04 [20:07] stokachu: if I had to guess, thinking it is a series 16 built snap with 14.04 libraries thing. this is probably related to the asciinema thread and friends that sergiusens is working on [20:07] stokachu: if a service fails to start it fails the install and cleans up after itself [20:07] ah the email from mark? [20:07] o/ [20:07] jdstrand, yea my snap never got installed b/c it hits that systemd error [20:08] stokachu: that whole thread, yeah-- there are complexities with series 16 built stuff on a 14.04 system that aiui, aren't being handled all the time [20:08] ok yea, this looks like my systemd service file never makes it onto the system [20:08] jdstrand: the issue mostly evolves around snaps using classic confinement, though [20:08] tvoss, yea this is classic [20:08] stokachu: you might try turning that into a command (comment out 'daemon: ...', then install, then do 'snap run --shell conjure-up.bridge' and see if you can't debug better [20:09] stokachu: how do you try to install the service file? [20:09] tvoss, https://github.com/conjure-up/conjure-up-snap/blob/master/snapcraft.yaml#L16-L20 [20:09] jdstrand, ok i can try that [20:10] stokachu: do you have a snap handy for testing? [20:10] what if i run snapcraft on the 14.04 system and build from there? [20:10] tvoss, yea one sec [20:10] tvoss, actually you can do sudo snap install conjure-up --classic --edge [20:10] it's the same one i do for xenial that works [20:11] err snap download i guess [20:11] stokachu: I'm not sure snapcraft is available for 14.04 yet (but I'm not tracking that work) [20:11] stokachu: let me clean up my testing environment [20:11] stokachu, as it stands, snapcraft doesn't run on trusty [20:11] (it has xenial-only deps) [20:11] jdstrand, kyrofa ah ok [20:11] didnt know if that would make a difference [20:12] tvoss, is the core snap on trusty the same as on xenial (i.e. is it still really xenial?) [20:12] Err, series 16 I guess [20:12] kyrofa: yup, it's a series 16 core [20:13] tvoss, so we don't anticipate libc symbol issues if we build on xenial and run on trusty? [20:13] I hit that back in the day, but it may have been before we actually had a core snap. Everything blurs together [20:14] kyrofa: curious, with the lxc stuff, is snapcraft needed inside the container or can snapcraft from outside drive commands inside? [20:14] err, lxd* [20:14] kyrofa: the assumption is to redirect everything to the core snap, and not pull in ABI from the host. classic is the exception here [20:14] tvoss, indeed, okay, makes sense [20:15] jdstrand, good question. I think the biggest requirement for it to be on the system is fetching stage packages [20:15] It also uses the container's sources.list by default for build-packages [20:16] jdstrand, yea that asciinema thread is pretty much the same thing im hitting too it seems [20:16] ogra_: I was able to install htop. I guess it is working but having issue installing my own snap “Mount snap "cwr" (unset) (snap "cwr" requires consent to use classic confinement)” [20:16] ses__, sounds like you want --classic in your snap install command [20:17] jdstrand, basically, every time snapcraft execs something else, we'd need to check to see if we need to exec in a container or on the host [20:18] jdstrand, and how that happens depends on what command is being run. For fetching stage packages we use the python3 apt API, so that's a big one [20:18] kyrofa: I don't know if this is at all helpful, but if the stage packages were broken out into a freestanding script, xenial host could copy stage-package script to trusty container, fetch stuff, then go from there. I suspect wanting lxd to build different series is interesting, but 14.04 is clearly the exception. series 18 would have snapcraft [20:19] well, python3-apt should be in trusty [20:19] jdstrand, yeah, but how do you use it if you're not in the container? [20:20] it isn't terribly interesting so long as we have series 16 core on trusty though I think [20:20] so sergiusens mentioned having a python3 part, is that something I could do as a workaround for this issue? [20:21] kyrofa: I figures start the conteriner, lxc push it, lxc exec it, etc [20:21] kyrofa: but, I'm not saying you should do it. you guys have given this way more thought than I :) [20:21] jdstrand, ah sorry, I was referring to python3-apt being in trusty, not the script [20:22] jdstrand, yeah I think it really comes down to "snapcraft wasn't written that way." Not to say we won't get there eventually, it's just a question of the shortest path [20:22] stokachu: so start of the bridge service fails, with the executable segfaulting. For that, the snap is removed immediately [20:23] stokachu: and thus no service file :) [20:24] tvoss, so should i do jdstrand's suggestion and try to run it as a script? [20:24] stokachu: yup, that would be a good first step [20:24] ogra_: used —classic but got “error: cannot find signatures with metadata for snap cwr_0.1_amd64.snap" ? [20:24] ok lemme try that [20:26] ogra_: snapcraft.yaml https://pastebin.canonical.com/176952/ [20:27] tvoss, jdstrand: so doing snap run --shell conjure-up.bridge starts my interface and applies the iptables rules [20:28] ses__, you need --dangerous as well [20:29] ses__, http://pastebin.ubuntu.com/ is your non-2fa-protected friend [20:29] stokachu: hmmm, that's funky [20:29] stokachu: hmm. did you have to snap connect anything? [20:29] stokachu: would you mind trying to call conjure-up without snap run? [20:30] jdstrand, nah as long as lxd is installed on the host [20:30] http://paste.ubuntu.com/23859714/ [20:30] thats from journalctl [20:30] lemme try running conjure-up [20:30] oh duh, its classic [20:30] kyrofa: sorry url autocomplete [20:30] ses__: use --dangerous for your cannot find signatures error [20:30] conjure-up [20:30] Segmentation fault (core dumped) [20:31] :( [20:32] jdstrand: ^ [20:32] Jan 24 20:30:50 darthbawlz kernel: [24152.656439] traps: conjure-up[3152] general protection ip:7f26c316a1ee sp:7ffe79c932e0 error:0 in libc-2.23.so[7f26c3027000+1bf000] [20:32] is in my syslog [20:34] libc-2.23.so is xenial's libc. trusty's is libc-2.19 [20:35] im guessing that gets pulled in during snapcraft build [20:35] I don't have the details, but I remember that there were issues on xenial when snaps tried to use a shipped libc instead of the system one [20:36] if I were to guess, I'd guess this is the same issue. I think this is the thread I was mentioning before with the dynamic linker, etc [20:36] I've not looked in the issue. others in this channel I believe are actively looking at it [20:37] ok, sounds like a decision needs to be made whether to use the system's libs in a classic snap? [20:39] strace shows this open("/snap/core/current/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 [20:40] stokachu: the only thing I can suggest otoh is adjust LD_LIBRARY_PATH or running your command with /lib/x86_64-linux-gnu/ld-2.19.so $SNAP/bin/your.executable ... [20:40] actually [20:41] you would want to do /snap/core/current/lib/x86_64-linux-gnu/ld-2.23.so ... [20:41] still segfaults it seems [20:41] anyway, I suspect with effort, you'd be able to use the right set of libraries then take that into a wrapper script for your command [20:42] jdstrand, ok, but this is something that can be dealt with in snapcraft at some point? [20:42] stokachu: that is what the thread is about [20:42] ok, thanks, at least it's a known issue [20:43] and, aiui, people are trying to figure out how to make this work well for people. it is rough now [20:43] jdstrand, all good, it works fine on xenial. having trusty is just icing on the cake [20:44] jdstrand, tvoss thanks for looking into it [20:47] stokachu: np. keep an eye on that thread and the other related threads on the snapcraft list and hopefully it'll get resolved soon [20:47] jdstrand, sounds good, will do [20:49]