[Help] Packagers wanted.

[sahib]

We're still in need of people who want to package rmlint for popular distributions. The most common problems we get is still trouble during compiling, which might be scary for new users and annoying for experienced users.

In concrete, I'd like to see packages and packagers for the following distributions:

• Ubuntu, Debian, Mint
• OpenSUSE
• Fedora (we have one already at http://copr.fedoraproject.org/coprs/sahib/rmlint/, but I'd like to give it to someone else since I mainly use Arch now again)

There is already an AUR package for Arch by me, although it might be nice to see it move to the main repos.

We would like to have the files that may be needed for packaging in our upstream repo (at pkg/), so they don't get lost when a packager vanishes. There is already a .deb package and a .rpm package (latter one by me), but most of the trouble comes by submitting the package upstream. The new gui is not yet included in those packages.

Versioning note: After realeasing version 2.4.0 (next stable release), we'll try to slow down developement since most features should be implemented by then. We'll (or at least me :smirk:) focus on small additions and bugfixes afterwards. With that, we'll release also smaller public versions like 2.4.2 etc. (even number means stable).

Thanks for any volunteers in advance.

Edit: There is still some time to the next release (~1-2 months), so talk to us here if you need changes in the build system or if questions arise.

[Bfgeshka]

I've made gentoo ebuilds for my overlay here (with instruction): https://github.com/Bfgeshka/octopus

2.2.0: https://github.com/Bfgeshka/octopus/blob/master/app-misc/rmlint/rmlint-2.2.0.ebuild master branch: https://github.com/Bfgeshka/octopus/blob/master/app-misc/rmlint/rmlint-9999.ebuild

I'm not familiar with scons, so for now ebuilds are pretty simple and use default options. Testing is welcome.

[Jormangeud]

Here are the ebuilds from my gentoo overlay: https://github.com/Jormangeud/jrg-overlay/tree/master/app-misc/rmlint

[sahib]

Hi @Bfgeshka and @Jormangeud, thanks for your quick response.

Im not sure yet which one to take. Both look okay-ish to me, but Im no gentoo user. Sorry for forgetting Gentoo on my list btw. I probably assumed that you're capable of building it anyways. :smile:

@Jormangeud: You seem to have two additional patches. One for disabling building the docs (which includes the manpage) and one... which I don't get (when would subprocess.check_output create an AttributeError?). To the first one: Actually, if no sphinx is installed, no docs will be built anyways. Im not sure therefore if this is still needed. There was however a bug that made scons threw up without sphinx.

@Bfgeshka: I tried to cover most options we provide at http://rmlint.readthedocs.org/en/latest/developers.html#buildsystem-helpers.

Out of interest, how hard would it be to push an ebuild to the official list of packages?

[Jormangeud]

If I recall this, the patch was needed as git could not be run in the sandbox of the build system.

The doc patching is just for the possibility of it.

I was thinking about to patch the locales to only wanted languages, but it seemed a bit too much work at that moment, and there are only few translations for now.

I submitted a new ebuild request to Gentoo bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=560390

[somasis]

I used to package rmlint for Exherbo, but with our new multiarch filesystem layout it's basically impossible now because of scons' suckage.

[sahib]

@Somasis: Care to elaborate where the exact problem is? @Jormangeud: Thanks a lot for the ebuld request. I applied the git-rev patch in 9cca9a336064cebb0e61c1c9c6d6f01a26982a08.

[somasis]

@sahib Certainly.

Basically, on Exherbo, we don't have unprefixed toolchain programs. We finished implementing a cross-compiling feature into our package manager, and a filesystem layout which uses paths like /usr/${CHOST}/{bin,lib,include} for architecture-dependent stuff, and /usr/share contains architecture-independent stuff.

scons doesn't account for this, and as such doesn't seem to know that the C compiler exists. We export CC=${CHOST}-cc in the build environment that it runs under, but scons doesn't pick up on it for a reason I can't crack.

[sahib]

@Somasis: I see, that might result in trouble.

You probably tried that yourself, but does pointing scons to the absolute compiler path work? (i.e. CC=/usr/amd64/bin/gcc scons or something). Sidenote: I should mention that our scons file does not pick all environ variables up:

https://github.com/sahib/rmlint/blob/develop/SConstruct#L449

It should however find the compiler if it's in $PATH, but probably not if Exherbo is using a different mechanism Im not aware of.

[somasis]

@sahib Absolute path doesn't seem to work.

[sahib]

Good news: rmlint moved to the [community] repo of Arch: https://www.archlinux.org/packages/community/x86_64/rmlint/

Here's the discussion thread.

[mfossen]

I got rmlint packaged and accepted into the Solus repos (https://solus-project.com/)

The repo link is here: https://git.solus-project.com/packages/rmlint/

And the one file that a person would need to edit (and after editing, submit as a patch on http://dev.solus-project.com) is here: https://git.solus-project.com/packages/rmlint/plain/package.yml

[sahib]

Thank you @mfossen! Well done.

[sahib]

Good news, rmlint is being packaged for debian. It might take some time though, but aren't we used that from Debian? :stuck_out_tongue:

[sahib]

Good news, again! rmlint has been packaged for Debian and was now approved by @xtaran. It awaits the final approval of the FTP team now. To be honest, I have no idea what happens afterwards and how rmlint is installed on Debian after all.

But I guess that's good? :stuck_out_tongue:

[xtaran]

@sahib: What will happen now eventually:

1. FTP Masters will probably approve the package for inclusion in Debian.
2. As soon as that has happened it will come into a (short-lived) queue called incoming as with any package uploaded to Debian.
3. From there two things happen in parallel:
   • Every 6 hours a process called dinstall runs. It will add the source package into Debian's source code APT repository and after dinstall has finished, you can do apt-get source rmlint in Debian Unstable and then get the source package (i.e. upstream tar ball plus packaging).
   • Usually within less than an hour the source package is fed into the build daemon network where it is built on every architecture that Debian offers. You can see the state of these builds at https://buildd.debian.org/rmlint starting from the moment it was passed to the build daemon network. If the build of a binary package was successful it is added to the incoming queue and gets included in Debian Unstable's APT repository by dinstall, too.
4. At the end of each dinstall run, the syncing of the mirrors is triggered. That's a multi-tier process (i.e. primary mirrors will push further to second-tier mirrors which might push it to leaf mirrors) which might take a few hours until all (push-)mirrors are in sync with the master.
5. Normally, if the package has been sitting in Debian Unstable without receiving any "release-critical" bug reports, it migrates to Debian Testing — given all its dependencies and build-dependencies are in Testing, too.
   • This automatic migration is currently suspended as Debian has frozen Testing for the preparation of it's upcoming Stable release dubbed "Debian 9 Stretch". The package will migrate to Testing once Debian 9 Stretch is released (and no release-critical bugs have been reported against the package until then).
6. From the moment, the package migrated to Testing, it is eligible to be uploaded to e.g. the stretch-backports repository so that users of Debian 9 Stretch can used despite it wasn't included in Debian 9 Stretch.
7. Steps 2 to 6 will be repeated for every upload to Debian Unstable. If an upload causes a release-critical bug, only a fixed followup upload might migrate to Testing. Each upload resets the migration perioud.
8. At some point in the future (probably in about two years), Debian will freeze Testing again to prepare the subsequent Stable release dubbed "Debian 10 Buster". As soon as Debian 10 Buster is released, rmlint will be part of a Debian Stable release (again given that the version in Testing at that time has no release-critical bugs).

(Yes, it's a long way to Debian Stable. But only that way we can ensure that a Stable release is as rock-solid as our users expect it. :-)

[sahib]

Thank you a lot for your detailed explanation and also for your packaging work. And also for not getting annoyed by me. :smirk:

Will it for now be easily possible to install it from Debian Unstable for a non Unstable user? If so, what would be the required steps?

[xtaran]

@sahib: We now have already passed steps 1 to 4. rmlint is available in Debian Unstable. Basically, if Carlos' changes to the packaging are merged, people should be able to build the package on any Debian release or derivative locally, given all build-dependencies are available and installed.

As soon as the rmlint package migrated to Debian Tesing (won't happen before late spring/early summer due to the freeze), Carlos can also upload (likely will need a sponsor) a package to Debian Backports so that users of Debian 9 Stretch can easily install it by just adding backports to their sources.list.

If wanted he should probably even be able to upload (likely will need a sponsor) a package to the so called "sloppy backports" (Backports from Testing to Oldstable) for Debian 8 Jessie.

By the way, rmlint built fine on all release architectures (those with white background), but failed on the (non-release-critical) Debian GNU/Hurd. The latter seems to be a widespread and well-known issue. See the GNU Hurd Porting Guidelines for hints on how to solve that.

In general, Debian packagers can fix such issues by patching the upstream source code, but they are encouraged to forward either the issue or the patch to upstream. That's why I'm mentioning it here. But I'll soon file a separate issue for this on GitHub, too.

[flokli]

rmlint has already been packaged in 2013 in https://github.com/NixOS/nixpkgs/pull/605, and GUI support (as an opt-in) is underway in https://github.com/NixOS/nixpkgs/pull/90267.