Ubuntu Snap - create working snap package

[mwozny123]

I've created initial Snap - ubuntu new packaging system:
https://en.wikipedia.org/wiki/Snappy_(package_manager)

After build such package can be distributed across different systems (no mater which kernel version, libraries etc) they have installed. So theoretically once build should run forever.
So thing like #7 shouldn't happen anymore;)

It's in the pull request:
#10

But there's a problem with make file.
As far as I understood there's a missing "install" section in Makefile:

(...)
make install DESTDIR=/home/marcin/evdev-snap/parts/evdevshift/install
make: *** No rule to make target 'install'.  Stop.
Command '['/bin/sh', '/tmp/tmpgyvyw_hj', 'make', 'install', 'DESTDIR=/home/marcin/evdev-snap/parts/evdevshift/install']' returned non-zero exit status 2   

could you add "install" to Makefile?

[uglyDwarf]

Will take a look at it - I'm not sure the install target is the only thing that is missing (uninstall, dist, ...)...
Technically speaking, I could plug in the autotools, so the package build system would be taken care of.
Kind regards,
Michal

PS. Should you wander why autotools and not CMake - I don't like CMake due to missing configure --help like functionality... I still remember spending like an hour looking for switches to build OpenCV on Mac without CUDA and friends...

[mwozny123]

Yes, such tools are good as long as developer still cares about library changes, and updates the application.

On Arch Linux Pkgbuild I've seen a lot of programs that after couple updates of depended library simply doesn't work.

Here could be the same, after 6-7 releases of Ubuntu, when (again) new version of "flex" or "bison" comes up and (again) completely changes the way it should be invoked (or major change inside used by evdevshift method) you might not have time, or want to again (let say for the 10th time) adjust evdevshift to library change, so it simply might not longer work.
It just happens too often in Arch Pkgbuild.

With snap package users still should have working application as the dependency is build into the package.
Of course this has some drawbacks: package use more disk space as it also contains dependency, dependency update relay on the developer, so if not updated security might be lower ; but I think in long term view it provides working (!) application, independent of library changes and developer.

I would be glad for updating Makefile.
Thanks
Marcin

[uglyDwarf]

Hello,
don't get me wrong, I'm not against having the snappy (or any other) package available. The problem I saw is, that Makefiles can get very complicated and using autotools is the most straightforward way to have it right...
I just checked in the changes - usual ./configure && make && make install triplet should work just fine.
And if you check the sources (configure.ac and Makefile.am) you'll see that it is not that complicated...
Kind regards,

Michal

PS. One more nice thing is, that now we have ./configure && make distcheck as a way to generate source package and check if it works - I find it very handy...

[uglyDwarf]

Hello,
I just merged the snap package stuff; I cleaned it up a bit (no need for bison/flex in the package) so now it is quite lean and mean ;)
What do you think?

Kind regards,
Michal

[mwozny123]

I didn't quite get what you mean by 'no need for bison/flex in the package' is it about the Snap package or that evdevshift no longer needed requires those dependecies?
Snaps intention is to provide all of the dependencies inside (just like docker).

I hope you didn't think that I ways saying that the "snap" is the one and only package that should be build;)
My intention was to say that from user perspective it's good to have one such package, event not the newest version. Maybe snap, maybe flatpack, but as I'm currently running ubuntu I prefer snap, maybe later I'll create a flatpack.

With snap you can build package using "make && make install", "./configure && make",or many other building software methods.
I adapted snap build file to new build method - it's in the pull request #12 . Can you review and merge?

I don't know what are your intentions but if you would have build build packages service you could add packaging to snap just by running "snapcraft && snapcraft clean" inside folder with 'snapcraft.yaml' and it will generate snap package.

Current snap package still misses access to hardware device (so it's useless), hope I could figure it out but it doesn't look simple : https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/#h.4pkwvbfmqz4q

As problem with building snap is solved, but snap is not ready I'll rename the issue title

[uglyDwarf]

Hello,
what I did was removing the stage package entry - what it did was adding bison/flex to the package; but that is not necessary, both are build time dependencies, but none of them is needed to run the resulting binary... But for some reason the change didn't make it back to the repository... Now you should see it...

Will take a look at that hardware access...

Kind regards,

Michal

[mwozny123]

How you are using hardware devices?
Is it only rw access needed to /dev/input/event* ?

[mwozny123]

I was looking for snap integration with hardware and I found here's a conception of slots
but we need access hardware, so this one wouldn't be useful here.

Snap provides interfaces to communication with hw:
hardware-observe - Can query hardware information from the system.
kernel-module-control - Can insert kernel modules. This interface gives privileged access to the device.
system-observe - Can query system status information which gives privileged read access to all processes on the system.

@uglyDwarf how are you creating device? are you using kernel modules? If not I'm afraid snap wouldn't be able to create new device:(

[uglyDwarf]

This might get a bit complicated - the new device is created using the /dev/uinput; the problem is, that I didn't see it mention in the document (quickly skimming through it); I'm going to read it more thoroughly and see what can be done... Also none of the interfaces seem to be what we need.
Anyway, given the fact, that evdevshift have pretty much no dependencies, we can easily create a simple tarball to be extracted anywhere and can run from there...
Kind regards,
Michal

[mwozny123]

Runnable tarball wouldn't be that bad. But I'll try to find it out in ubuntu snap team;)

[mwozny123]

Snap currently doesn't have required feature:
https://bugs.launchpad.net/snappy/+bug/1622639/
closing this issue.