Given that its a script I don’t see how it can create a seg fault.
One of the apps it cause could but I added an exit as the second line in the file and it was still segfaulting.
snapcraft --version
snapcraft, version 2.39.1+git5.688588a
I’m not sure it’s snap that dumps the core, normally you’d see a panic backtrace when such thing happens. Can you add set -x to getcert script see where it fails exactly?
coredumpctl should be able ot show you more about the coredumps.
the bracket in the dash we a cut/paste bug, the actual dash file is fine.
I’ve just rebuilt using snapcraft stable and I’m still getting the core dump.
I’ve added the -x into the dash file but I’m still getting zero output except the core dump message.
I have to say that it feels like the executable that snapcraft generates is causing the core dump .
I ran snapcraft try prime --devmode
Modified the getcert script so it just exits on line 2 and then ran: pi-gation.getcert
Not really, given you cant “just build” on 17.10 (this would get all the wrong dependencies).
Snap packages run on top of the core snap, the core snap is based on 16.04, libs and binaries you use in your snap need to be linked against the 16.04 set of binaries in the core snap.
If you do not build all your included dependencies from source you have to use snapcraft cleanbuild on any non 16.04 system (which will automatically build in a 16.04 container). If you don’t, you get libs linked against the wrong OS environment …
If there is a bug, it is in the documentation not making that clear to you …
I tried cleanbuid but the round trip times were too long as you have to do a full build each time (as I understand it).
During development I want to do a snap try so I can test/experiment and then only build parts that have changed.
snap development is slow enough as it is (too many times you need to clean a part to get it to build again after a snapcraft.yaml change) without requiring a full build on each iteration.
Or am I missing some technique that makes using lxd faster?
yes, you do, like you do when building without cleanbuild to avoid tainted results … the point is that you can very easily mess up your build host and your snap when not using it …
doing development is probably fine to do without cleanbuild (if you fully trust all the involved build systems to not trash your host), but your last step before building an actual snap you want to give to others or use in production should always be a cleanbuild.
There are a few points above that would be worth clarifying. I’ve put these in a topic about common questions for cross-distro building.
Also, below there are some more comments on specific points in the conversation above.
@ogra That’s a very unhelpful way to put it. People must necessarily be able to “just build” on Ubuntu 17.10 and anywhere else they want, Ubuntu or otherwise. Anything preventing that is a serious bug that must be fixed.
@ogra That’s an unfortunate side effect, and @bsutton is absolutely right in being displeased. Snapcraft has an amazing amount of caching precisely to make development comfortable. It makes no sense for the same project to both do that and then claim that’s not a good thing. It is a good thing, and we need to fix cleanbuild.
Speaking of caching:
@bsutton The caching behavior of snapcraft is somewhat unfriendly still. Since we discussed this two years ago, it has improved somewhat, but it’s still not as good as it needs to be, and that bug remains open.
When an application implements caching, it needs to be almost entirely transparent, otherwise it exchanges user boredom time when redoing the operation again by user confusion and focused time when trying to understand why things are broken, which is a lot more expensive.
In practice, snapcraft needs to learn to invalidate its caching when things change, and redo the work automatically.
niemeyer,
thanks for helping clear a few issues up.
the SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft
option sounds like it might be the right way to go as it sounds like it delivers on the ‘implied’ snap promise of build anywhere, deploy anywhere.
I must say that as a newbie to snap its been a bit of a battle.
The documentation is rather sparse and spread out all over the place.
I should perhaps note (whilst trying not to upset anyone) that the core documentation needs to be edited by a native english speaker. There are large amounts of grammatically obscure sentences.
If I can give the team one message.
Make the doco better.
The one saving grace is that the community has been really helpful with all my questions.