Debian packaging for Pop!_OS

[mmstick]

Whenever you're ready, I'll package and add this to our Pop repository. This seems like a very useful tool for us.

[svartalf]

You mean CLI app, right?

Do you have any integration process documentation or anything similar worth to read out of curiosity?

[mmstick]

Yes, the CLI application, or any available user-facing binary project. A GTK application would be nice to have, for example.

There's no documentation for the packaging process. We set up cargo packages to create a source tarball that contains an inner vendor tarball, so that the build system can build the Cargo project without Internet access in Launchpad. No work has to be done on your part.

[svartalf]

@mmstick, okay, got it, thank you.

Yet as I was said a couple times before on reddit, CLI application was basically a proof of concept and from my point of view it is not ready to be used everywhere.
First of all, it would be nice to get a community feedback (as in #13, for example), stabilize it a little and move on then.

Any way, this idea sounds amazing :)

[svartalf]

Hey, @mmstick!

I was hoping to release battop for Windows first, but since it is goes to a postponed status too often due to the Windows-specific stuff, I guess it is time to get back to your suggestion about Pop!_OS.
In addition, there was no bug reports for a last few months, so battop can be assumed to be stable enough (or probably it's because no one is using it, which is very likely :) ).

I've published the v0.2.2 release with all fixes available, so nothing should block you now.
Also I still don't know how the build process for Pop!_OS works like, but the release page for each release contains source code (in .tar.gz and .zip), .asc signature and .sha512 hash for each source archive, hope it will help you.

Let me know if you need any help.

[mmstick]

Essentially, we create a debian directory to include along with the sources, which contains extra package metadata and a debian-specific Makefile (debian/rules). We add rules to create a vendored tarball during the clean rule, and use sbuild to build the project in a schroot. sbuild executes the clean rule from the host, then chroots and executes all the rules (incl. the clean rule again). We have a check in the clean rule if is-chroot that ensures that the chroot doesn't attempt to remove and re-vendor, as it doesn't have Internet access.

I'll have the debian packaging ready soon.

[svartalf]

Okay, I understood some of these words :)

What is a source of the "sources" in that case? Are you checking out the "master" branch or using GitHub releases page?
My main concern here is that master' HEAD might not be stable, so either you can checkout to the pre-defined tag or download an archive from the releases page (I intend to create one for each new tag).

[mmstick]

Sources referring to your source code. We just add a debian directory to your repo. We can use tagged commits.

[svartalf]

@mmstick yeah, tagged commits would be the preferred way, otherwise it might break the build with unexpectedly broken master.