Skip to content

Add rpkg/copr support #69

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion configure.ac
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
AC_INIT([rt-app], [m4_esyscmd_s([git describe --tags HEAD])], [[email protected], [email protected]])
AC_INIT([rt-app], [1.0], [[email protected], [email protected]])
Copy link
Member

Choose a reason for hiding this comment

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

Adding rpkg/copr is a good idea
but is there a way to keep both mechanism running correctly ?
It was convenient to get the sha1 for intermediate build to know which version a rt-app binary is based

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So, I'm pretty new to the rpkg/copr thing, but AFAIU the problem with calling git describe is that rpkg creates a temporary out-of-git-tree copy of the source to build them and create rpms. So git describe doesn't work in this case.
Now, I'm not sure if this is a problem for rpkg local only (I used that before creating the project on copr to test the build process) or also if copr would have problems with that.

In any case, I was wondering if we shouldn't actually "standardize" the release process. We are still at v1.0 and lot of stuff changed and was added after that?

Copy link
Member

Choose a reason for hiding this comment

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

Yes. We might need to tag a new version
And more generally speaking release some "stable" version more often

May be it's worth checking what the other package are doing in this area. Imean in order to get some details about sha1 when want to use "dev" branch
Ca, we consider that the rpkg/copr will be used only with tagged version ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ca, we consider that the rpkg/copr will be used only with tagged version ?

Makes sense to me.

So we could

  1. create a devel branch out of current master
  2. apply the patch removing git describe only in master
  3. tag master as.. 1.1 or 2.0 (updating configure.ac accordingly)
  4. use master for copr (and a debian equivalent in the future?)
  5. point people to devel for further development and merge in master feature by feature

Do you think it might actually work? :-)

Copy link
Member

Choose a reason for hiding this comment

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

yes that's seems to be a good way of working

Copy link
Contributor

Choose a reason for hiding this comment

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

In the past I've got a chance to use the "gitflow" branching model described here:

https://nvie.com/posts/a-successful-git-branching-model/

and I've found it quite useful. IMO it's pretty close to what @jlelli suggests and I think it could fit for an improved release process for rt-app.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nice! Yes this should work.
@vingu-linaro we might act on this by creating a PR that modifies README or points to a doc that states how development and release will be done from now on. Can do that.
Once we have that I can rebase this accordingly...
OK?

Copy link
Member

Choose a reason for hiding this comment

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

looks good for me

AC_COPYRIGHT([Copyright (C) 2009 Giacomo Bagnoli <[email protected]>
Copyright (C) 2016 Juri Lelli <[email protected]>
Copyright (C) 2016 Vincent Guittot <[email protected]>])
Expand Down
67 changes: 67 additions & 0 deletions rt-app.spec.rpkg
Original file line number Diff line number Diff line change
@@ -0,0 +1,67 @@
# vim: syntax=spec

Name: {{{ git_dir_name }}}

Version: 1.0

Release: 1%{?dist}

Summary: rt-app: simulate system load.

License: GPLv2

URL: http://github.com/scheduler-tools/rt-app

VCS: {{{ git_dir_vcs }}}

# git_dir_pack macro places the repository content (the source files) into a tarball
# and returns its filename. The tarball will be used to build the rpm.
Source: {{{ git_dir_pack }}}

Buildrequires: autoconf
Buildrequires: automake
Buildrequires: libtool
Buildrequires: json-c-devel

Requires: json-c

# More detailed description of the package
%description
rt-app is a test application that starts multiple periodic threads in order to simulate a real-time periodic load.

# Python permits the !/usr/bin/python shebang for scripts that are cross
# compatible between python2 and python3, but Fedora 28 does not. Fedora
# wants us to choose python3 for cross-compatible scripts. Since we want
# to support python2 and python3 users, exclude our scripts from Fedora 28's
# RPM build check, so that we don't get a bunch of build warnings.
#
# Taken from: https://github.com/zfsonlinux/zfs/issues/7360
#
%global __brp_mangle_shebangs_exclude_from workgen

# The following four sections already describe the rpm build process itself.
# prep will extract the tarball defined as Source above and descend into it.
%prep
{{{ git_dir_setup_macro }}}

# This will invoke `make` command in the directory with the extracted sources.
%build
autoreconf --install --symlink || exit 1
./configure --with-deadline
make

# This will copy the files generated by the `make` command above into
# the installable rpm package.
%install
make install DESTDIR=%{buildroot}

# This lists all the files that are included in the rpm package and that
# are going to be installed into target system where the rpm is installed.
%files
/usr/local/bin/rt-app
/usr/local/bin/workgen

# Finally, changes from the latest release of your application are generated from
# your project's Git history. It will be empty until you make first annotated Git tag.
%changelog
{{{ git_dir_changelog }}}