Debianize

[Elbandi]

This commit adds the required files to build for ubuntu/debian. Tested(=builded) on ubuntu bionic LTS and focal LTS, they already have new rust. Unfortunately debian havent new rust, it cannot build with main packages. (but you can install rust packages from focal)

[boydjohnson]

I'm just an onlooker with an opinion, but I don't think this PR is the best approach. It would require users to build the binary each time they install the package. A better approach is using cargo deb to build a deb binary package. Then there would be no dependency on cargo and rustc.

[extrawurst]

@boydjohnson this PR seems abandoned anyway. Would you be up to work on a PR to add deb creation to the pipeline?

[boydjohnson]

Yeah, I will create a PR this week that modifies the .github/workflows/cd.yml file, Cargo.toml, and possibly Makefile to create a binary deb on github actions.

[Elbandi]

This is the debian package build guide: https://wiki.debian.org/HowToPackageForDebian My PR follows this standard.

Debian/ubuntu releases isnt a bleeding edge distro. They pick up a stable release from github, and build the source and puts the package to repo.

If you want build a package for every commit, there is solution for do that in "debian way" (eg: create a new changelog entry from commit messages at build step).

[boydjohnson]

I think you are right, @Elbandi. I will test building a deb source and binary from this PR.

I had only had use with cargo-deb.

[boydjohnson]

Hi @Elbandi I was able to build a deb binary using dpkg-buildpackage -b --no-sign -r=fakeroot. I did this on Ubuntu. I successfully installed the deb on Debian (Bullseye) and Ubuntu (Bionic) (host machine).

This looks good to me. Let me know what I can do to help.

[Elbandi]

here is a sample: https://github.com/dmx-systems/dmx-build-deb/blob/cf0e0292c67d601b9a1404763c5a4756fd9d6b6c/.gitlab-ci.yml#L162-L164 this creates a new changelog entry, and build the debian package. but you can tweak with git describe --tags the build version. etc.etc

[boydjohnson]

@extrawurst I gave bad information in

I'm just an onlooker with an opinion, but I don't think this PR is the best approach. It would require users to build the binary each time they install the package. A better approach is using cargo deb to build a deb binary package. Then there would be no dependency on cargo and rustc.

Specifically that cargo deb is the better approach. This PR makes it possible to build debian source and debian binary packages. From reading at the debian wiki link up above, this is the only way that we could get it included in an official apt repository.

[extrawurst]

@boydjohnson I am not sure I can follow. does this mean your PR is obsolete? i can't merge this one either so we are back to square one.

[boydjohnson]

@extrawurst If this PR built deb packages in github actions would you be willing to merge it?

[extrawurst]

@boydjohnson yes we need this to be part of CI and CD - also its would be great to document how to update for new release (like by now we are already at 0.19 where in the PR it is still 0.17.1

[boydjohnson]

@Elbandi Would you be willing to do the work of adding building the deb to both github actions workflows?

Also, since @extrawurst is listed as the maintainer, he would have to provide a gpg key to sign the source. @extrawurst, do you have a gpg key and are you comfortable signing the source?

[extrawurst]

@boydjohnson can you elaborate what exactly needs to be signed? I never signed any commit in here, I guess you are not talking about that, right? what do I need to gpg-sign and why?

[extrawurst]

I am sorry I am such a noob when it comes to deb. feel free to take this conversation to discord (link on readme) to simplify teaching me

[boydjohnson]

No problem, @extrawurst. Yeah, so as maintainer of the debian package, you would sign the source so that people could verify that it is what you say it is. The key would probably be a secret that you added to github and would be used in the github actions to sign. Let's see what @Elbandi says.

[Elbandi]

I rebased the branch to the latest release, and started to play with GH build. but there are some mysterious errors and segfaults. only ubuntu amd64 builds work :( i need to work on it... https://github.com/Elbandi/gitui/actions/runs/1551533874

[tmpgnh]

@Elbandi you need help with this? I'm using a Debian/bookworm and was able to debuild your branch with no problems (well, a single lintian error on the chlog file, maybe false positive).

[extrawurst]

setting to draft for the time being

[semioticrobotic]

Just wanted to express my desire to see this implemented! I need to move to Pop!_OS and would love to have gitui in the upstream repositories on Ubuntu Jammy.

[williamdes]

Just wanted to express my desire to see this implemented! I need to move to Pop!_OS and would love to have gitui in the upstream repositories on Ubuntu Jammy.

You should file a RFP: https://wiki.debian.org/RFP For that you will need to send an email to submit, here is an example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030845;msg=5

[Elbandi]

@williamdes i checked your suggestions, and you have (almost) right. My goal was to make a package to everyone can use (and build) on yet supported systems, not only for bandnew bleedingedge versions: strech on debian (in 2021 was supported...), and bionic LTS on ubuntu.

[DartMitai]

I just installed Debian 12 and by the apt install gui command it finds nothing does it make sense to wait or is it abandoned?

[williamdes]

I just installed Debian 12 and by the apt install gui command it finds nothing does it make sense to wait or is it abandoned?

It makes sense, this package never did enter Debian You probably need to build the apt from this PR

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity half a year. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.