代码拉取完成，页面将自动刷新
同步操作将从 张以正/autospec 强制同步，此操作会覆盖自 Fork 仓库以来所做的任何修改，且无法恢复！！！
确定后同步将在后台操作，完成时将刷新页面，请耐心等待。
autospec is a tool to assist in the automated creation and maintenance of RPM packaging. It will continuously run updated builds based on new information discovered from build failures until it has a complete and valid .spec file. The tool makes use of mock to achieve this.
Table of Contents
autospec is available under the terms of the GPL, version 3.0
Copyright (C) 2017 Intel Corporation
autospec is configured by means of a simple INI-style configuration file.
The default location of this file is assumed to be
/usr/share/defaults/autospec/autospec.conf.
Example autospec.conf file:
[autospec] git = [email protected]/%(NAME)s license_fetch = http://yourhost/hash.php license_show = http://yourhost/showone.php?hash=%(HASH)s packages_file = file:///path/to/package_list_file yum_conf = file:///path/to/yum.conf upstream = http://yourhost/tarballs/%(HASH)s/%(NAME)s
usage: autospec.py [-h] [-g] [-n NAME] [-v VERSION]
[-a [ARCHIVES [ARCHIVES ...]]] [-l] [-b] [-c CONFIG]
[-t TARGET] [-i] [-p] [--non_interactive] [-C]
[-m MOCK_CONFIG] <url>
url (required) tarball URL
(e.g. http://example.com/downloads/mytar.tar.gz)
| -h, --help | show this help message and exit |
| -g, --skip-git | Don't commit result to git |
| -n NAME, --name NAME | |
| Override the package name | |
| -v VERSION, --version VERSION | |
| Override the package version | |
| -a ARCHIVES, --archives ARCHIVES | |
| tarball URLs for additional source archives and a location for the sources to be extacted to (e.g. http://example.com/downloads/dependency.tar.gz /directory/relative/to/extract/root ) | |
| -l, --license-only | |
| Only scan for license files | |
| -b, --skip-bump | |
| Don't bump release number | |
| -c CONFIG, --config CONFIG | |
| Set configuration file to use | |
| -t TARGET, --target TARGET | |
| Target location to create or reuse | |
| -i, --integrity | |
| Search for package signature from source URL and attempt to verify package | |
| -p, --prep-only | |
| Only perform preparatory work on package | |
| --non_interactive | |
| Disable interactive mode for package verification | |
| -C, --cleanup | Clean up mock chroot after building the package |
| -m MOCK_CONFIG, --mock-config MOCK_CONFIG | |
| Value to pass with Mock's -r option. Defaults to "clear", meaning that Mock will use /etc/mock/clear.cfg. | |
In order to run correctly, autospec requires the following components:
If autospec is not configured to use a license server, then it will use the
autospec/license_hashes file - which is a list of licenses to facilitate
automatic license detection during the scan of a tarball. For correctness,
license names should be in the SPDX identifier format. Each line in the file
constitutes a license definition, for example:
750b9d9cc986bfc80b47c9672c48ca615cac0c87, BSD-3-Clause 175e59be229a5bedc6be93e958a970385bb04a62, Apache-2.0 794a893e510ca5c15c9c97a609ce47b0df74fc1a, BSD-2-Clause
It is possible to influence precisely how autospec will behave in order to gain fine control over the build itself. These files may be used to alter the default behaviour of the configure routine, to blacklist build dependencies from being automatically added, and such.
These files are expected to live in same directory that the resulting .spec
will live.
.spec. This is also bumped and generated on existing and new packages,
respectively. This results in less manual work via automatic management.autospec will exit with an error. Update this file to
contain the valid SPDX identifier for any license(s) for the package,
replacing $package in the filename with the actual package name..spec.autospec will automatically transform the
names into their pkgconfig($name) style when generating the .spec..spec.main subpackage, they will be placed on the -${custom} subpackage..spec.main subpackage, they will be placed on the -${custom} subpackage.buildreq_ban. As with
pkgconfig_add, these names are automatically transformed by autospec
into their correct pkgconfig($name)) style.main subpackage, they will be removed from the -${custom}
subpackage.main subpackage, they will be removed from the -${custom}
subpackage.Note
Run time requirements are not assumed to be build time requirement If a package has the same build and run time requirement it must be added to both buildreq_add and requires_add.
.spec and
optionally installed as well. Each non-blank and non-comment line should start
with the file name as found in the Git directory, followed by arguments to be
passed to the /usr/bin/install(3) command, with at least one argument starting
with a slash, denoting the destination directory (there's no need for
%{buildroot}). If the install arguments are missing, Autospec will not
generate an installation command and the package should specify how to install
in the install_append file (see below).%configure macro for
autotools based tarballs. As an example, adding --disable-static to
./configure for an autootools based tarball would result in %configure
--disable-static being emitted in the .spec.%configure macro for
autotools based tarballs to configure openmpi builds.%cmake macro for
CMake based tarballs. As an example, adding -DUSE_LIB64=ON to
./cmake_args would result in %cmake -DUSE_LIB64=ON being emitted in
the .spec.%cmake macro for
CMake based tarballs for openmpi builds.make
command, i.e. use this if make should be replace with another build tool
like ninja.make invocation. This may be
useful for passing arguments to make, i.e. make TOOLDIR=/usr
make invocation of the 32bit
build. It is appended after the make_args content so 32bit specific overrides
can be added.make_args, this will pass arguments to the make install
macro in the .spec
make32_args, this will pass arguments to the make install
macro in the .spec for the 32bit build. Again it is appended after
make_install_args so 32bit specific overrides can be added.%prep
and before the %setup macro. This will be placed in the
resulting .spec, and is used for situations where fine-grained
control is required.%build and before
the %configure macro or equivalent (%cmake, etc.). If autospec
is creating AVX2, AVX-512 or 32-bit, these actions will be repeated for
each of those builds, This will be placed in the resulting .spec,
and is used for situations where fine-grained control is required.%build
and before the %configure macro or equivalent (%cmake, etc.).
If autospec is creating AVX2, AVX-512 or 32-bit, these action will
not be repeated for each of those builds, This will be placed in the
resulting .spec, and is used for situations where fine-grained
control is required.%make macro or equivalent. If
autospec is creating AVX2, AVX-512 or 32-bit, these actions will be
repeated for each of those builds, before their respective make
steps. This will be placed in the resulting .spec, and is used
for situations where fine-grained control is required.%install but before the %make_install macro (or equivalent).
This will be placed in the resulting .spec, and is used for
situations where fine-grained control is required.%install section. This will be placed in the resulting .spec,
and is used for situations where fine-grained control is required.install routine, i.e. use this if %make_install is insufficient.Makefile's available in the root of the
tarball. An example of this may be cross-platform projects that split
Makefile's into the unix subdirectory. Set the name in this file and the
.spec will emit the correct pushd and popd lines to utilise these
directories for each step in the build.In certain situations, the automatically detected build pattern may not work
for the given package. This one line file allows you to override the build
pattern that autospec will use. The supported build_pattern types are:
%configure autotools routeconfigure, but performs %reconfigure to
regenerate ./configure
configure_ac but uses the existing ./autogen.sh
instead of %reconfigure
make followed by make install, skipping configure. Note
that this is the fallback build pattern in case no other build patterns are
autodetected`cargo` to build and install content put in ~/.cargo/binThis file contains a list of patches to apply during the build, using the
%patch macro. As such it is affected by -p1 style modifiers.
Arguments to patch can be added after the patch filename. For example:
`
0001-my-awesome-patch.patch -d some/subdir -p1
`
This file contains a list of modules to remove version tests on during the build. It also modifies the requirement of the requires.txt egg if it exists in the package. For example:
`
colorama
`
in the file will cause this modification:
`
- 'colorama>=0.2.5,<0.4.4',
+ 'colorama',
`
%exclude lines in the .spec. This is
useful for omitting files from being included in the resulting package. Each
line in the file should be a full path name.Each line in the file should be a full path within the resulting package, that
you wish to be placed into an automatic -extras subpackage. This allows
one to keep the main package slim and split out optional functionality or
files.
Files paths can contain a single '*' per directory such that
a line of /foo*/bar* is allowed but /foo*bar* is not.
-extras subpackage, they will be placed in the -dev one. Use this
functionality to place files used only for development against this
software that Autospec does not automatically detect.-extras subpackage, they will be placed in the -tests one. Use this
functionality to place files used only for testing against this
software that Autospec does not automatically detect.-extras subpackage, they will be placed in the extras-${custom}
subpackage.Each line contains a subpackage names of other subpackages in the package.
This is used when the extras-${custom} subpackage has a runtime
requirement on a sibling subpackage.
An example of the ${custom}_extras and ${custom}_extras_requires
being used together with:
/usr/bin/foo
in foo_extras and:
data
in foo_extras_requires will produce a spec file package section for example-foo-extras with the following content:
%package extras-foo
Summary: extras-foo components for the example package.
Group: Default
Requires: example-data = %{version}-%{release}
%description extras-foo
extras-foo components for the example package.
setuid attribute set with the
%attr macro.Each line in this file should specify mode, user, group and filename
(space separated) which is translated into a full %attr macro
line that will be included in the .spec to have fine-grained control
over the permissions and ownership of files in the package.
An example of a attrs file would contain:
4755 root messagebus /usr/libexec/dbus-daemon-launch-helper
which would translate to the following line in the resulting .spec file:
%attr(4755,root,messagebus) /usr/libexec/dbus-daemon-launch-helper
By default, autospec will attempt to detect potential test suites that
can be run in the %check portion of the .spec.
%check portion of the .spec.
This may be useful when a package uses a custom test suite, or requires
additional work/parameters, to work correctly.summary
Provides the main Summary: value of the package, overriding any automatically found values. Only the first line is used.
Further control of the build can be achieved through the use of the
options.conf file. If this file does not exist it is created by autospec
with default values. If certain deprecated configuration files exists autospec
will use the value indicated by those files and remove them.
The options that can be set in options.conf are as follows:
.spec will disable the LD_AS_NEEDED variable.
Supporting binutils (such as found in Clear Linux Project for Intel
Architecture) will then revert to their normal behaviour, instead of enforcing
-Wl,-as-needed in the most correct sense.CFLAGS/LDFLAGS will be extended to build the
package optimized for size, and not for speed. Use this when size is more
critical than performance.CFLAGS/LDFLAGS will be extended to build the
package optimized for speed. In short this where speed is of paramount
importance, and will use -03 by default.CFLAGS/LDFLAGS will be replaced, using the
smallest -02 based generic flags possible. This is useful for operating
systems employing heavy optimizations or full RELRO by default.CFLAGS/CXXFLAGS will be extended to build the
package with profile-guided optimization data. It will add -O3,
-fprofile-use, -fprofile-correction and -fprofile-dir=pgo.%check code in a way that allows the build to continue.%define keepstatic 1 is emitted in the
.spec. As a result, any static archive (.a) files will not be removed
by rpmbuild..so files to be added to the lib subpackage
instead of the dev subpackage.extras subpackage is marked as a dependency of
the dev package.true. This flag is
intended to be used by tools running autospec automatically.debuginfo is not created for this package.autospec will attempt to use a number of patterns to determine the name and
version of the package by examining the URL. For most tarballs this is simple,
if they are of the format $name-$version.tar.$compression.
For websites such as bitbucket or GitHub, using get$ and
v$.tar.* style links, the project name itself is used from the URL and the
version is determined by stripping down the tag.
CPAN Perl packages, pypi ecosystem packages and R packages are automatically
prefixed with their respective names: perl-, pypi- and R-
respectively.
When these automated detections are not desirable, it is possible to override
these with the --name flag when invoking autospec
autospec can optionally talk to a license server instead of checking
local hashsum files, which enables greater coverage for license detection.
The URL set in license_fetch is expected to be a simple script that
talks HTTP.
This URL should accept POST requests with the following keys:
Implementations return a plain text response with the SPDX identifier
of the license, if known. An empty response is assumed to mean that this
license is unknown, in which case autospec will emit the license_show
URL. The implementation should show the now-stored license file via a
web page, and enable a human to make a decision on the license. This is
then stored internally, allowing future requests to automatically know
the license type when this hash is encountered again.
autospec can add most systemd template file types by having a file in the
filename.extension in the build directory. Supported extensions are:
mount, service, socket, target, timer, path and tmpfiles. The files will
be added as Source# entries and be installed to their appropriate system
location.
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
马建仓 AI 助手