– permit extraction of multiple archives in a single specfile
– %forgemeta, %forgesetup, %forgeautosetup: add a “-z <number>” switch to
select a specific set of rpm variables
(for example forgeurl<number> and version<number>)
– %forgemeta, %forgesetup: add a “-a” switch to process all sets in one go
(makes no sense in forgeautosetup, as you need so select specific patches)
– %forgemeta: deprecate the “-u” switch, use “-z” it’s better
(“-u” was awkward and mainly used by the %gometa macro. %gometa will now
call the lua code directly)
– %forgesetup: use “-v” for verbose processing, be quiet by default, drop “-q”
(align with %forgemeta, %forgeautosetup and %autosetup)
– %forgesetup, %forgeautosetup: only pass flags that make sense to
%setup/%autosetup; reorder to match what works in el7
– factor out complex or common lua code in separate lua modules, to allow:
– code reuse in other macros without cut and pasting
– direct lua routine invocation from other macros without going through a
rpm macro
– rpm syntax errors that point to a line in an actual lua file
– %forgemeta: refactor the logic to drop as much forge-specific code as
possible, use a single logic flow with tables of constants
– %forgemeta: export more computed info in rpm variables, such as the
%{_builddir} subdirectory an archive was extracted to (lifesaver when
processing multiple archives)
– %forgemeta: prepend secondary distprefixes with .S, to make clear they do
not apply to the main archive
– %forgemeta: add versionx to secondary distprefixes, if relevant
– %forgemeta: make tar.bz2 the default archive format
Caveats:
– forge services implement full-release downloads via tags. However the actual
syntax of such tags is not standardised. If the macro does not guess the
correct tag an upstream uses for a specific release, you will need to
set the tag value explicitly.
– GitHub lets upstreams move their projects to new URLs, keeping the old URL
active. It all works transparently *except* the top directory inside
generated archives always matches the new project name (even when accessed
by compatibility URLs, and even for releases that antedate the renaming).
Therefore, if macro processing of a GitHub archive suddenly fails, start by
checking if upstream didn’t rename itself.
Multicall usage example (with “-a”)
– to process a specific bloc in one of the macros use “-z <suffix>”
– suffix 0 and no suffix are synonyms
– therefore, calling the macros without “-a” or “-z” just works for the
general use case when you have a single archive to process
– caveat: forge services implement full-release
%<--
%global forgeurl0 https://gitlab.com/osslugaru/lugaru
Version: 1.2
%global forgeurl1 https://gitlab.com/osslugaru/lugaru
%global tag1 1.1
%global forgeurl2 https://gitlab.com/osslugaru/lugaru
%global commit2 68488b0a11df90dca703c67e5592b93c6a269957
%global forgeurl3 https://gitlab.com/osslugaru/lugaru
%global branch3 v1.1
%global forgeurl4 https://github.com/google/trillian
%global version4 1.0.8
%global forgeurl5 https://github.com/kubernetes/apiextensions-apiserver
%global version5 1.9.6
%global tag5 kubernetes-%{version5}
%global forgeurl6 https://github.com/jdbranham/grafana-diagram
%global version6 1.3
%global commit6 440689793ab6da82019c5ee43b49438dfef976d5
%global forgeurl7 https://github.com/rethinkdb/rethinkdb-go
%global version7 1.4.2
%global branch7 v1
%global forgeurl8 https://code.googlesource.com/gocloud
%global version8 0.20.0
%global forgeurl9 https://code.googlesource.com/gocloud
%global tag9 v0.27.0
%global forgeurl10 https://code.googlesource.com/google-api-go-client
%global commit10 24928b980e6919be4c72647aacd53ebcbb8c4bab
%global version10 0
%global forgeurl11 https://code.googlesource.com/google-api-go-client
%global branch11 dartman
%global forgeurl12 https://bitbucket.org/nielsenb/pdfocr
%global version12 0.3.0
%global commit12 4f5750d202d33267094621630836f1215a5efa66
%global forgeurl13 https://bitbucket.org/nielsenb/pdfocr
%global version13 0.1.4
%global tag13 v0.1.4
%global commit13 c0359843a3420769940e12019ebd68891a053bd8
%global forgeurl14 https://bitbucket.org/creachadair/shell
%global commit14 3dcd505a7ca5845388111724cc2e094581e92cc6
%global forgeurl15 https://bitbucket.org/kirbyvisp/vdjpuzzle2/
%global branch15 js-edits
%global commit15 36a3850eb4a04c05e0f7e29e7d0c196f373eb672
%forgemeta -ia
Name: testing
Release: 1%{?dist}
Summary: A test package
URL: %{forgeurl}
License: Public domain
Source0: %{forgesource0}
Source1: %{forgesource1}
Source2: %{forgesource2}
Source3: %{forgesource3}
Source4: %{forgesource4}
Source5: %{forgesource5}
Source6: %{forgesource6}
Source7: %{forgesource7}
Source8: %{forgesource8}
Source9: %{forgesource9}
Source10: %{forgesource10}
Source11: %{forgesource11}
Source12: %{forgesource12}
Source13: %{forgesource13}
Source14: %{forgesource14}
Source15: %{forgesource15}
%description
A test package
%prep
%forgesetup -a
%build
exit 1
%install
%files
%doc
%<--
Merges: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/35
Using the modification time of the snapshot tarball for computing dist is a bad idea, since it's different on different machines.
For example, the computed date during the `buildSRPMfromSCM` koji task is likely different from the local date when the package was prepared, and so package builds (especially EVRs and changelog entries) are not reproducible.
With this change, the snapshot date is not calculated magically, but the packager has to set "%global date YYYYMMDD" manually. I also adapted the documentation for the macro to reflect that change.
This is related to the following FPC issue: https://pagure.io/packaging-committee/issue/719
