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 <john.florian@xxxxxxxx> 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 <john.florian@xxxxxxxx> > > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx > -- -Igor Gnatenko -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
