Re: How to package a Git repository
2016-09-09 3:25 GMT-06:00, Florian Weimer : > I would like to build (S)RPMs directly from a Git repository (which > contains the .spec file in the top-level directory). This is for a > CI-style project, with a quick release cycle. > Tito can help you: https://github.com/dgoodwin/tito -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How to package a Git repository
On Fri, Sep 9, 2016 at 5:25 AM, Florian Weimer wrote: > I would like to build (S)RPMs directly from a Git repository (which > contains the .spec file in the top-level directory). This is for a > CI-style project, with a quick release cycle. > > I have a Lua script fragment which generates a proper SRPM with the > mock-scm target in COPR, and which is also compatible with “fedpkg srpm”. > But rpmbuild strips leading path components from Source: and Patch: > references, so this only works if all files are in a single directory. > > Are there any alternatives that work in COPR, EPEL and Fedora proper? > > I think it's strange that I have to put a tarball somewhere just for RPM's > sake if there is no separate upstream, and there are no upstream releases > as a result. It's just an annoyance and yet another step that can go wrong > in various ways. > > Thanks, > Florian > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org There is the --build-in-place option to rpmbuild, which will "Build from locally checked out sources. Sets _builddir to current working directory. Skips handling of -n and untar in the %setup and the deletion of the buildSubdir." This might be helpful, if the current working directory is the root of the git repository. I think it's a relatively new option-- I seem to remember it being added somewhere in the Fedora 23 cycle? Ben Rosser -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How to package a Git repository
On Fri, 2016-09-09 at 16:54 +0200, Igor Gnatenko wrote:
Problem with tito as it doesn't really do proper archive for
build/release and doesn't work properly in many cases:
1. Version is specified in spec -> all builds will be unordered.
Example: Version: 2.0.0 -> 2.0.0-1.git.tree-ish
I don't have any problem with this at all. For my test builds I don't use
tito.release.KojiGitReleaser
but rather tito.release.KojiReleaser which produces builds named like:
builder-6.14-1.git.6.05be4b1.fc24
builder-6.14-1.git.7.40346c1.fc24
builder-6.14-1.git.8.c448a30.fc24
... where the '.6', '.7', '.'8' following represents the number of commits
since the last "tito tag" operation. I only get burned when redo one of those
"steps" with "git commit --fixup" followed later by "git rebase -i
--autosquash". However, by that time I'm finalizing a branch and can live with
a reinstall vs upgrade.
2. Replaces archive. Source: https://.../%{name}-%{version}.tar.gz is
404 as tito creates releases in %{name}-%{version}-X where X is
release. If we are talking about Github, then even you change URL to
proper it still doesn't work because %(auto)setup fails, as github
generates archive in %{name}-%{name}-%{version}-X format.
I'm not 100% sure I follow you here, but I suspect I get away with this because
all my spec's have:
Source0:%{name}-%{version}.tar.gz
Granted, this would never fly in Fedora proper, but for private work it suits
me fine. I otherwise attempt to adhere to FPG as much as possible as it
generally makes life simpler.
X. Requires some files in upstream repo
I'm not sure I follow here either, but as the author and packager for my
projects, I actually prefer that our Git repo has everything needed, spec,
Makefile, etc. right there. The only part that makes me cringe is the fact
that Makefile is duped all over the place. I hate dupes and strive for DRY
because eventually they all need to change.
I would not recommend using tito. I would recommend to have spec in
upstream ONLY for reference, but have proper Fedora ones in our
dist-git.
In my case (but perhaps not Mr. Weimer's) is that I don't have to be proper per
Fedora. FWIW, I found tito to be a godsend for bringing ease to my situation.
That all said, I'm very curious how your rpm-gitoverlay helps exactly. I've
found a solution that works for me, but I hammered out a solution without as
broad an understanding of how Fedora is built as I have now -- and I'm certain
my current understanding is probably woefully lacking. Is rgo something that
could be used with our private Koji setup? My quick glance at the code leads
me it's suited for copr or rpmbuild only.
--
John Florian mailto:john.flor...@dart.biz>>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How to package a Git repository
Problem with tito as it doesn't really do proper archive for
build/release and doesn't work properly in many cases:
1. Version is specified in spec -> all builds will be unordered.
Example: Version: 2.0.0 -> 2.0.0-1.git.tree-ish
2. Replaces archive. Source: https://.../%{name}-%{version}.tar.gz is
404 as tito creates releases in %{name}-%{version}-X where X is
release. If we are talking about Github, then even you change URL to
proper it still doesn't work because %(auto)setup fails, as github
generates archive in %{name}-%{name}-%{version}-X format.
X. Requires some files in upstream repo
I would not recommend using tito. I would recommend to have spec in
upstream ONLY for reference, but have proper Fedora ones in our
dist-git.
On Fri, Sep 9, 2016 at 4:47 PM, John Florian wrote:
> On Fri, 2016-09-09 at 11:25 +0200, Florian Weimer wrote:
>
> I would like to build (S)RPMs directly from a Git repository (which
> contains the .spec file in the top-level directory). This is for a
> CI-style project, with a quick release cycle.
>
> I have a Lua script fragment which generates a proper SRPM with the
> mock-scm target in COPR, and which is also compatible with “fedpkg
> srpm”. But rpmbuild strips leading path components from Source: and
> Patch: references, so this only works if all files are in a single
> directory.
>
> Are there any alternatives that work in COPR, EPEL and Fedora proper?
>
> I think it's strange that I have to put a tarball somewhere just for
> RPM's sake if there is no separate upstream, and there are no upstream
> releases as a result. It's just an annoyance and yet another step that
> can go wrong in various ways.
>
>
> This is my situation with everything I package (privately for my employer).
> I went in circles for a while simply believing I had to be doing something
> wrong until I considered the fact that most people doing packaging are not
> the authors. This all settled in completely when I began recalling the days
> of yore when one would download a tgz, extract, config, make, etc.. Still I
> think it's a shame that this isn't handled better. With very large projects
> it's quite a waste of time to archive just to meet the expected input format
> only to have the process reversed immediately.
>
> That said, I do much as Igor has already mentioned. My build process starts
> with tito but lands in our Koji. I use the following Makefile without any
> changes for each of my projects to facilitate tito's
> tito.release.KojiGitReleaser:
>
> $ cat Makefile
> # Extract NVR from the spec while stripping any macros, specifically the
> # disttag macro.
> name := $(shell awk '/^Name:/{print $$2}' *.spec)
> version := $(shell \
>awk '/^Version:/{print gensub(/%{.*?}/, "", "g", $$2)}' *.spec \
>)
> release := $(shell \
>awk '/^Release:/{print gensub(/%{.*?}/, "", "g", $$2)}' *.spec \
>)
> # The treeish we'll archive is effectively the Git tag that tito created.
> treeish := ${name}-${version}-${release}
>
> # Koji's buildSRPMFromSCM method expects a target named "sources" which
> # ultimately must ensure that a tarball of the package's sources and its
> spec
> # file are present. Our practice is to always keep a spec file in the Git
> # repository, but we must build the tarball on the fly to resemble an
> upstream
> # published work.
> sources:
>git archive \
>--output=${name}-${version}.tar.gz \
>--prefix=${name}-${version}/ \
>${treeish}
>
>
> Hope this helps!
> --
> John Florian
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How to package a Git repository
On Fri, 2016-09-09 at 11:25 +0200, Florian Weimer wrote:
I would like to build (S)RPMs directly from a Git repository (which
contains the .spec file in the top-level directory). This is for a
CI-style project, with a quick release cycle.
I have a Lua script fragment which generates a proper SRPM with the
mock-scm target in COPR, and which is also compatible with “fedpkg
srpm”. But rpmbuild strips leading path components from Source: and
Patch: references, so this only works if all files are in a single
directory.
Are there any alternatives that work in COPR, EPEL and Fedora proper?
I think it's strange that I have to put a tarball somewhere just for
RPM's sake if there is no separate upstream, and there are no upstream
releases as a result. It's just an annoyance and yet another step that
can go wrong in various ways.
This is my situation with everything I package (privately for my employer). I
went in circles for a while simply believing I had to be doing something wrong
until I considered the fact that most people doing packaging are not the
authors. This all settled in completely when I began recalling the days of
yore when one would download a tgz, extract, config, make, etc.. Still I think
it's a shame that this isn't handled better. With very large projects it's
quite a waste of time to archive just to meet the expected input format only to
have the process reversed immediately.
That said, I do much as Igor has already mentioned. My build process starts
with tito but lands in our Koji. I use the following Makefile without any
changes for each of my projects to facilitate tito's
tito.release.KojiGitReleaser:
$ cat Makefile
# Extract NVR from the spec while stripping any macros, specifically the
# disttag macro.
name := $(shell awk '/^Name:/{print $$2}' *.spec)
version := $(shell \
awk '/^Version:/{print gensub(/%{.*?}/, "", "g", $$2)}' *.spec \
)
release := $(shell \
awk '/^Release:/{print gensub(/%{.*?}/, "", "g", $$2)}' *.spec \
)
# The treeish we'll archive is effectively the Git tag that tito created.
treeish := ${name}-${version}-${release}
# Koji's buildSRPMFromSCM method expects a target named "sources" which
# ultimately must ensure that a tarball of the package's sources and its spec
# file are present. Our practice is to always keep a spec file in the Git
# repository, but we must build the tarball on the fly to resemble an upstream
# published work.
sources:
git archive \
--output=${name}-${version}.tar.gz \
--prefix=${name}-${version}/ \
${treeish}
Hope this helps!
--
John Florian mailto:john.flor...@dart.biz>>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How to package a Git repository
In DNF CI we use rpm-gitoverlay[0], but due to RPM we have to prepare archive from git, replace path for %(auto)setup, and some other magic, so you can't use it as is in Fedora. But you can easily use it with COPR as you don't have to follow all guidelines. When I deal with one project I just do: $ rpm-gitoverlay build-package -n libdnf rpm copr --owner ignatenkobrain --project libdnf which does everything for me. [0] https://github.com/ignatenkobrain/rpm-gitoverlay On Fri, Sep 9, 2016 at 11:25 AM, Florian Weimer wrote: > I would like to build (S)RPMs directly from a Git repository (which contains > the .spec file in the top-level directory). This is for a CI-style project, > with a quick release cycle. > > I have a Lua script fragment which generates a proper SRPM with the mock-scm > target in COPR, and which is also compatible with “fedpkg srpm”. But > rpmbuild strips leading path components from Source: and Patch: references, > so this only works if all files are in a single directory. > > Are there any alternatives that work in COPR, EPEL and Fedora proper? > > I think it's strange that I have to put a tarball somewhere just for RPM's > sake if there is no separate upstream, and there are no upstream releases as > a result. It's just an annoyance and yet another step that can go wrong in > various ways. > > Thanks, > Florian > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
How to package a Git repository
I would like to build (S)RPMs directly from a Git repository (which contains the .spec file in the top-level directory). This is for a CI-style project, with a quick release cycle. I have a Lua script fragment which generates a proper SRPM with the mock-scm target in COPR, and which is also compatible with “fedpkg srpm”. But rpmbuild strips leading path components from Source: and Patch: references, so this only works if all files are in a single directory. Are there any alternatives that work in COPR, EPEL and Fedora proper? I think it's strange that I have to put a tarball somewhere just for RPM's sake if there is no separate upstream, and there are no upstream releases as a result. It's just an annoyance and yet another step that can go wrong in various ways. Thanks, Florian -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
