Add support for snap packaging (via snapcraft)

[3v1n0]

This adds the ability of packaging this app using snap packages (see http://snapcraft.io/) that are used by Ubuntu.

This allows also to set openAL settings without breaking the default user settings.

Improved also the way this app looks for .wav files, by looking in the binary path (not fully reliable in all the OSes, but it's an improvement that allows to avoid passing the wav path from the snap wrapper script).

[Natureshadow]

This adds the ability of packaging this app using snap packages (see
http://snapcraft.io/) that are used by Ubuntu.

Huh? Packaging stuff does not belong upstream. You don't include debian/, do you?

Besides, Ubuntu has dpkg as well.

-nik

[zevv]

Hi Marco,

Thanks for packaging up, but I'm not sure though if I want to collect
all the various dist packaging stuff in the repo. I once allowed that
with another project, but in the end it added a lot of administrative
hassle which was not really for the good of the project.

I know that for debian it's not common to add the packaging stuff to
upstream, that's generally managed elsewhere. I'm not at all familiar
with Snap though.

I'd be happy to add any references to packages to the documentation, if
that would help you?

• On 2016-10-28 20:57:07 +0200, Marco Trevisan wrote:

This adds the ability of packaging this app using snap packages (see http://snapcraft.io/) that are used by Ubuntu.

This allows also to set openAL settings without breaking the default user settings.

Improved also the way this app looks for .wav files, by looking in the binary path (not fully reliable in all the OSes, but it's an improvement that allows to avoid passing the wav path from the snap wrapper script).
You can view, comment on, or merge this pull request online at:

#29

-- Commit Summary --

• Try to locate wav files using the binary path
• snapcraft.yaml: allow to generate a snap
• snapcraft.yaml: add needed plugs to be strict
• bucke-snap.run: add wrapper to setup openal settings
• snapcraft.yaml: add license information

-- File Changes --

A buckle-snap.run (8)
M main.c (17)
A snapcraft.yaml (52)

-- Patch Links --

https://github.com/zevv/bucklespring/pull/29.patch
https://github.com/zevv/bucklespring/pull/29.diff

This adds the ability of packaging this app using snap packages (see
[1]http://snapcraft.io/) that are used by Ubuntu.

This allows also to set openAL settings without breaking the default user
settings.

Improved also the way this app looks for .wav files, by looking in the
binary path (not fully reliable in all the OSes, but it's an improvement
that allows to avoid passing the wav path from the snap wrapper script).

---

You can view, comment on, or merge this pull request online at:

  [2]#29

Commit Summary

 * Try to locate wav files using the binary path
 * snapcraft.yaml: allow to generate a snap
 * snapcraft.yaml: add needed plugs to be strict
 * bucke-snap.run: add wrapper to setup openal settings
 * snapcraft.yaml: add license information

File Changes

 * A [3]buckle-snap.run (8)
 * M [4]main.c (17)
 * A [5]snapcraft.yaml (52)

Patch Links:

 * [6]https://github.com/zevv/bucklespring/pull/29.patch
 * [7]https://github.com/zevv/bucklespring/pull/29.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, [8]view it on GitHub, or [9]mute the thread.

Reverse link: [10]unknown

References

Visible links

1. http://snapcraft.io/
2. Add support for snap packaging (via snapcraft) #29
3. https://github.com/zevv/bucklespring/pull/29/files#diff-0
4. https://github.com/zevv/bucklespring/pull/29/files#diff-1
5. https://github.com/zevv/bucklespring/pull/29/files#diff-2
6. https://github.com/zevv/bucklespring/pull/29.patch
7. https://github.com/zevv/bucklespring/pull/29.diff
8. Add support for snap packaging (via snapcraft) #29
9. https://github.com/notifications/unsubscribe-auth/AC3OP_uOQQmRbwsextvvUGvW083Vuozmks5q4kWDgaJpZM4KjwAl
   1. Add support for snap packaging (via snapcraft) #29

:wq
^X^Cy^K^X^C^C^C^C

[Natureshadow]

Ah, oh, that was a pull request, not a commit mail…

[3v1n0]

Huh? Packaging stuff does not belong upstream. You don't include debian/, do you?
Besides, Ubuntu has dpkg as well.

Snaps are meant to be managed directly by upstream that can easily push them in the Ubuntu store when they want to release without having to worry about someone else to manage this part.

Also snaps are supported by multiple other distros, other than Ubuntu.

And this is different from dpkg as it's confined and secured. Also it's now and will be the preferred way to distribute software for Ubuntu.

I know that for debian it's not common to add the packaging stuff to upstream, that's generally managed elsewhere. I'm not at all familiar with Snap though.

Yeah, the same can be done easily with snaps, as the source of a snapcraft.yaml can also be a git repository like this, but as said above snaps are meant to be managed directly by upstream projects, as you can decide when to release to different channels without having the distro to care about this, and without the risk of breaking anything.

I'd be happy to add any references to packages to the documentation, if that would help you?

Yeah, I've submitted the package already to the ubuntu snap store, however it's something you could also manage directly without having others to handle it.

In any case, if you're not interested in this you can link the snap (once available in the store) and I'll do a different project for managing only the snapcraft.yaml. While I could propose a branch containing only the this commit.

Let me know...

[3v1n0]

Hey, any update on this?

If you don't want to keep this upstream, just let me know so that I can just propose the unrelated bits and keep the snapcraft.yaml stuff somewhere else.

[zevv]

Hi Marco,

I'll look into it this weekend, thanks

[zevv]

Marco,

Sorry, but I'm not too happy adding a lot of new files just for the sake of supporting snap packaging. I can merge your changes in main.c though to try to find the samples relative to the binary path, would that help you out?

[3v1n0]

Sorry, but I'm not too happy adding a lot of new files just for the sake of supporting snap packaging. I can merge your changes in main.c though to try to find the samples relative to the binary path, would that help you out?

No problem... I'll move the snap stuff in a different repo (if you want it under your umbrella, just let me know), while I'll propose only that change.

FYI the snap package is already available in the store though: https://uappexplorer.com/app/bucklespring.3v1n0

Cheers

[3v1n0]

@zevv, any interest in revisiting this?

The snap has some popularity, maybe you might want to handle that alone?
The changes needed should be really minimal at this point.

Let me know.