Thanks for sending this in! We don't know very much about RPM packaging, so if anyone viewing this has comments or can review it better than we can, that'd be much appreciated :)

Could you also update CONTRIBUTING.md and add any new instructions for us when we make a new release? I'm guessing it's as simple as just bumping the URL/version number/changelog in this file.

Would it be useful for us to post built RPMs to GitHub releases as well, like we do for the Debian packages?

I'm trying to use Copr service to offer secure RPMS builds directly for latest fedora and CentOS.

you just need to update a single line which is Version: 1.1.3 to lets say Version: 1.1.4 and add log entry at the end of the file to be something like

%changelog
* Thu Sep 15 2016 First Name <youremail> - 1.1.4-1
- update to upstream 1.1.4

* Mon Aug 15 2016 alsadi <alsadi@gmail.com> - 1.1.3-1
- initial packaging

build is done using

rpmbuild -ba dumb-init.spec 

regarding quality of this file, it can be reviewed using rpmlint and I've tested it and validated it

$ rpmlint dumb-init-1.1.3-1.fc24.src.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
$ rpmlint dumb-init-1.1.3-1.fc24.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

I'm guessing it's as simple as just bumping the URL/version number/changelog in this file.

no need to update the url, I made it to read the version from second line %{version}

Would it be useful for us to post built RPMs to GitHub releases as well, like we do for the Debian packages?

Yes they are ready from here

https://copr.fedorainfracloud.org/coprs/alsadi/dumb-init/

If you merge it, I can make the build system points to your github repo and provide build directly from there.

I guess fedora/centos people would prefer yum repo rather than downloading the rpm file. so you might need to point them to my copr or create your own copr repo.

here is the direct rpm link if you like

https://copr-be.cloud.fedoraproject.org/results/alsadi/dumb-init/epel-7-x86_64/00441463-dumb-init/dumb-init-1.1.3-1.el7.centos.x86_64.rpm

so if anyone viewing this has comments or can review it better than we can, that'd be much appreciated :)

I guess we have got around 5 fedora developers reviewing this, and things are going well.

Do you have headless-test (that can run when build machine is offline and can't reach network or a without running docker daemon) to be conducted during the build process to validate the build.

My guess is there is no such tests, because your tests in the Makefile use docker (which imply root and network to fetch images).

I believe make test is the target you're looking for for "headless" tests.

On Aug 18, 2016 10:19 AM, "Muayyad Alsadi" notifications@github.com wrote:

so if anyone viewing this has comments or can review it better than we
can, that'd be much appreciated :)

I guess we have got around 5 fedora developers reviewing this, and things
are going well.

Do you have headless-test (that can run when build machine is offline and
can't reach network or a without running docker daemon) to be conducted
during the build process to validate the build.

My guess is there is no such tests, because your tests in the Makefile
use docker (which imply root and network to fetch images).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#111 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABugn5FawzTPXzcAYPdvg4KITv-KzMlpks5qhBWCgaJpZM4JkLy8
.

For others' reference, here's the Fedora ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1367033

Let us know when you think this is ready-to-go. It seems okay to me, but I don't know enough about RPM packaging to do a thorough review. We're happy to take your / the Fedora developers' word for it :)

Also, to expand on @asottile's comment, make test should do what you want, though it runs tox and so will download some packages from PyPI.

If that's not acceptable because there's no internet at all, you can do what Debian does to run tests during the build:

override_dh_auto_test:
    PATH=.:$$PATH py.test tests/

You'd need to install the test dependencies beforehand, though. The test dependencies the Debian maintainer is installing are:

    ,python
    ,python-mock
    ,python-pytest

I assume there are equivalent packages in RPM land?

I have another branch for activating testing build.

please merge this one as is.

here is the other branch

https://github.com/muayyad-alsadi/dumb-init/tree/rpm-spec-with-check
muayyad-alsadi@f424845

I'll open another issue regarding the tests.

@chriskuehl are you against building RPM and DEB packages from the gradle nebula ospackage plugin? I realize this isn't a Java project but it uses a Java library to build both DEB and RPM packages. The advantage to this is you can be on a DEB system and build RPM packages with the same amount of effort (i.e. almost no effort).

https://github.com/nebula-plugins/gradle-ospackage-plugin

@samrocketman yes, I'm against using tools other than the best tool ever.

in fedora the best tool is mock (not even rpmbuild, because mock creates an empty OS tree then validate your build dependencies, whereas rpmbuild use your host, which you might have random things installed)

the most easy way might be is to use docker to start a fedora/centos container
then use that container to type

rpmbuild -bs dumb-init.spec

this would build a .src.rpm file which you can upload to build systems like copr

@samrocketman I don't think we want to change the Debian packaging too much, since we use a version of this internally too.

I'm guessing it might be easier to just set up additional RPM packaging? Pretty much all a system package has to do is provide the binary at /usr/bin/dumb-init (or similar) and optionally the manpage.

We don't know much about RPM packaging, though, so I'm definitely open to recommendations on the best way to approach that. I'm happy to add a simple step to our release process (e.g. uploading RPMs in addition to the debs) if that would help consumers of dumb-init. We already build the Debian packages in a debian:jessie container, we could presumably do the same for RPM with whatever build system/container is best.

LGTM

just checked with my rpm build environment (OracleLinux8), works for me (with changes to latest version of package sources):

[mator@ol8 rpmbuild]$ diff -u SPECS/dumb-init.spec-PR SPECS/dumb-init.spec
--- SPECS/dumb-init.spec-PR     2022-05-06 13:23:28.698712524 +0300
+++ SPECS/dumb-init.spec        2022-05-06 13:16:22.284257053 +0300
@@ -1,6 +1,6 @@
 Name:           dumb-init
-Version:        1.1.3
-Release:        7%{?dist}
+Version:        1.2.5
+Release:        1%{?dist}
 Summary:        Entry-point for containers that proxies signals

 License:        MIT
@@ -42,6 +42,9 @@
 %doc README.md

 %changelog
+* Fri May  6 2022 Anatoly Pugachev <matorola@gmail.com> - 1.2.5-1
+- update
+
 * Wed Aug 17 2016 Muayyad Alsadi <alsadi@gmail.com> - 1.1.3-7
 - let manpage automatically marked as document

[mator@ol8 rpmbuild]$ rpmbuild -bb SPECS/dumb-init.spec
...
Wrote: /home/mator/rpmbuild/RPMS/x86_64/dumb-init-1.2.5-1.el8.x86_64.rpm
...

[mator@ol8 rpmbuild]$ rpmlint /home/mator/rpmbuild/RPMS/x86_64/dumb-init-1.2.5-1.el8.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

[mator@ol8 rpmbuild]$ rpm -qpl /home/mator/rpmbuild/RPMS/x86_64/dumb-init-1.2.5-1.el8.x86_64.rpm
/usr/bin/dumb-init
/usr/lib/.build-id
/usr/lib/.build-id/a8
/usr/lib/.build-id/a8/cf089decee302808f7e8fc2cefb04bb45a1a89
/usr/share/doc/dumb-init
/usr/share/doc/dumb-init/README.md
/usr/share/licenses/dumb-init
/usr/share/licenses/dumb-init/LICENSE
/usr/share/man/man1/dumb-init.1.gz

Anything else needs to be done for this PR to be merged? Thanks.