Add it on AUR packages for easy update upgrade?

[nekr0z]

Add it on AUR packages for easy update upgrade?

[nekr0z]

Now that there's code in place for general packaging, someone should figure out list of dependencies for Arch and persuade @n3vu0r to package his systemd/udev/makefile magic so we can depend on that. Building an Arch package shouldn't be a big problem then.

[nekr0z]

Packaging matebook-applet if made properly (and I see no reason to do otherwise) would require post-installation hooks for all the permissions to be generated correctly. Honestly, I don't know how to do it (yet), and that's why I have not attempted any packaging so far.

That being said, pull requests in that direction are most welcome. Ideally, the build.go script that is already in the repo should build packages for various distros given the corresponding arguments.

[n3vu0r]

I wanted to setup Arch/Debian dual boot anyway for the latest mesa package, so I can try to pack for AUR as well.

---

In case this is about general packaging, first feedback on the Debian package:

$ lintian matebook-applet_1.3.2-1-g2cb55bb_amd64.deb
E: matebook-applet: unstripped-binary-or-object usr/bin/matebook-applet
W: matebook-applet: hardening-no-pie usr/bin/matebook-applet
E: matebook-applet: missing-dependency-on-libc needed by usr/bin/matebook-applet
E: matebook-applet: debian-changelog-file-missing-or-wrong-name
E: matebook-applet: no-copyright-file
E: matebook-applet: extended-description-is-empty
W: matebook-applet: priority-extra-is-replaced-by-priority-optional
W: matebook-applet: binary-without-manpage usr/bin/matebook-applet

A description of each error/warning tag can be found here.

[nekr0z]

In case this is about general packaging, first feedback on the Debian package:

Oh, I didn't even attempt to run it through lintian. And a good thing I didn't, too! ;)))

IMO, if lintian is the only one having issues with the package, job's done good. Let's make sure we're on the same page here.

"Proper" Debian packaging (as in "fit to be included in main Debian repositories") is an awful lot of hassle. I would even say it's more hassle than writing the applet in the first place. I'm not up to it. Debianization of source packages, using Debian build chain to build binary packages - no, that's a whole big endeavor in and of itself. If however someone feels the need and has powers to do it, I'd welcome any effort and do my best to help.

What I'm shooting for here is a "good enough" .deb package that can be installed and used with no hassle and is not too problematic to build for every release. That's mostly done.

So, from my point of view, #9 is indeed a valid issue, libc6 dependency - sure, in master already, but things like unstripped binary complains (and on Go code, mind you)? No, thank you, jumping through those hoops is way beyond my aim. And no, I'm not doing changelogs unless I find a way to autogenerate them from git history (which is a proper changelog anyway).

This is why I opted for packaging using fpm instead of Debian toolchain.

[nekr0z]

Before I release and automate all this stuff, could someone having more experience with Arch than me (which should be easy since mine is only half an hour in a VM) please have a look at this PKGBUILD, give it a test and point out the problems?

Also @n3vu0r, any developments regarding your stuff for Arch?

[n3vu0r]

@nekr0z Nothing so far, but I still want a Arch/Debian multi-boot. With half an hour, we have almost the same experience with Arch ;)

[nekr0z]

Looks like someone has done it for us. Yay, and good job whoever that person is, and I'm closing this issue.