Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add spec file needed to build rpms #111

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

muayyad-alsadi
Copy link

@muayyad-alsadi muayyad-alsadi commented Aug 15, 2016

fixes #110

URL: https://github.com/Yelp/dumb-init
Source0: https://github.com/Yelp/dumb-init/archive/v1.1.3.tar.gz

BuildRequires: vim-common
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this build-depend on vim-common?

@chriskuehl
Copy link
Contributor

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?

@muayyad-alsadi
Copy link
Author

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 <[email protected]> - 1.1.3-1
- initial packaging

@muayyad-alsadi
Copy link
Author

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.

@muayyad-alsadi
Copy link
Author

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.

@muayyad-alsadi
Copy link
Author

URL: https://github.com/Yelp/dumb-init
Source0: https://github.com/Yelp/dumb-init/archive/v%{version}.tar.gz

BuildRequires: vim-common
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

still curious why this depends on vim-common? (GitHub buried my original comment, it seems)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

still curious why this depends on vim-common? (GitHub buried my original comment, it seems)

because I have a line that runs make VERSION.h (although it's commented out) which calls /bin/xdd which belongs to vim-common

[root@localhost ~]# rpm -qf /bin/xxd
vim-common-7.4.1868-1.fc24.x86_64

You can make it depend on /bin/xxd as filename if you wish
You can comment both out (so that the one who is building un-released version would enable both again)

@muayyad-alsadi
Copy link
Author

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).

@asottile
Copy link
Contributor

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

On Aug 18, 2016 10:19 AM, "Muayyad Alsadi" [email protected] 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
.

@chriskuehl
Copy link
Contributor

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 :)

@chriskuehl
Copy link
Contributor

chriskuehl commented Aug 24, 2016

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?

@muayyad-alsadi
Copy link
Author

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.

@samrocketman
Copy link

@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

@muayyad-alsadi
Copy link
Author

@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

@chriskuehl
Copy link
Contributor

@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.

@mator
Copy link

mator commented May 6, 2022

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 <[email protected]> - 1.2.5-1
+- update
+
 * Wed Aug 17 2016 Muayyad Alsadi <[email protected]> - 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.

Copy link

@mator mator left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@@ -0,0 +1,59 @@
Name: dumb-init
Version: 1.1.3
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please update to current version

%license LICENSE
%doc README.md

%changelog
Copy link

@mator mator May 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please update changelog to current version

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

A sample spec file to build dumb-init as an RPM
5 participants