Commit fa303d5ba6 moved buildhost and
buildtime calculation out of the package generation to early spec
initialization, but this broke reproducable builds: if buildtime is
to be set from changelog, changelog needs to be parsed first.
So either we need to do it twice or we need to do it right, and
besides avoiding duplication, conceptually these values are only
meaningful during a build and not a parse, so this restores that part
of the original code while keeping things thread-safe.
Fixes: #932
Packages can never provide rpmlib() capabilities, don't pollute the
namespace with invalid (if mostly harmless) data. The use-case of
identifying whether there are dynamically generated buildrequires in
an src.rpm is satisfied by looking for RPMSENSE_FIND_REQUIRES type
requires as of commit bee5dc94cf.
This makes them in line with regular auto-generated dependencies and allows
them to be easily identified. It also makes parseRCPOT() error reporting
do the right thing: generated dependencies do not relate to spec lines.
Fixes#801 (also reported as RhBug:1759100)
Commit 18e8f4e9b2 and related changes
caused us to capture and re-emit stdout of all build scriptlets,
whether we actually use the output for anything or not. Besides doing
a whole bunch of work for nothing, this can disrupt the output of
build scriptlets by making the output jerky and out of order, at least
inside mock and other tools which in turn grab rpm output. This makes
troubleshooting failed builds unnecessarily hard for no good reason.
Handle the whole thing in a different way: on regular builds, don't
capture anything where we don't actually need to. This restores the
natural flow of output. We still need to somehow handle quiet builds
though, and we can't use redirect to /dev/null from %___build_pre like
we used to, because dynamic buildrequires need to provide output even
on quiet builds. So somewhat counter-intuitively, we need to capture
the output in order to discard it.
Closes: #794
There is no way to get src.rpm with dynamic BuildRequires without
checking dependencies on the system. --nodeps always forces rpmbuild to
write buildreqs.nosrc.rpm, but in some cases it might be desired to get
src.rpm with dynamic BRs but without checking for dependencies.
Closes: https://github.com/rpm-software-management/rpm/issues/760
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Following snippet from buildlog is not helpful to user:
[…]
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.FqlMc8
[…]
+ exit 1
error: Exec of /var/tmp/rpm-tmp.FqlMc8 failed (%prep): No such file or directory
Previous rpmbuild versions returned:
[…]
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.epLFi2
[…]
+ exit 1
error: Bad exit status from /var/tmp/rpm-tmp.epLFi2 (%prep)
So let's restore good old version of a message.
References: https://github.com/rpm-software-management/rpm/issues/728
Fixes: 18e8f4e9b2
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Supports new %generate_buildrequires section in the spec file which is executed
after %prep. Stdout is captured and turned into BuildRequires. These are then
checked. If they cannot be fulfilled a source package is created with all
BuildRequires and the build is terminated after that.
rpmbuild has now the following new build modes -br, -tr, -rr and exits with 11
if build requirements are not met.
That means for users:
* No %generate_buildrequires
* rpmbuild -br is equivalent to rpmbuild -bs
* rpmbuild -br --nodeps is equivalent to rpmbuild -bs
* %generate_buildrequires
* rpmbuild -br will check dynamic BuildRequires
* Satisfied → src.rpm
* Unsatisfied → buildreqs.nosrc.rpm
* rpmbuild -br --nodeps will always generate buildreqs.nosrc.rpm
Source packages contain
Requires: rpmlib(DynamicBuildRequires) <= 4.15.0-1
if the spec contains a %generate_buildrequires section and
Provide: rpmlib(DynamicBuildRequires) = 4.15.0-1
if the results been added to the source package.
Co-authored-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
The output is going to be needed Dynamic BuildRequires.
Just do not duplicated to stdout if verbose mode is not enabled.
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
otherwise, builds before noon will not have normalized mtimes
from %clamp_mtime_to_source_date_epoch
This also helps other programs like tar --clamp-mtime
For NSPR, (which NSS uses internally) being portable to Windows and
whatnot and centered around apps like Firefox, simply ignoring
SIGPIPE is probably a reasonable choice. Rpm however is an old school
unix cli piece where SIGPIPE is very much relevant and handled where
necessary. Besides we now have not just one but two other, less obnoxious
crypto backends which exhibit different core rpm behavior due to the
difference, not good.
Save and restore the SIGPIPE handler across NSS initialization,
and remove all the now redundant calls to reset it after forking.
Should've done this ages ago but better late than never, no?
Note that the install-time scriptlet thing is different since we set
SIGPIPE to SIG_IGN by ourselves there, add a comment.
- Replace the hysterical "lets see if the temp creation gave an fpio
fd (it didn't), if not open another fd and then get its private
FILE pointer" fiddling: since we need a FILE stream then open one
with fdopen(), duh. Grabbing a rpmio fd to begin with is stupid enough
when all we want is a stream, but wanting to use rpmMkTempFile()
functionality...
- Also fixes an fd+mem leak in the unlikely but possible case that
rpmMkTempFile() succeeds but fdopen() fails.
- The build version has getUidS() and getGidS() for which there is
no counterpart in the rpmug api but there's not much point to them:
they check whether the user/groupname exists but return our own
string back to us even if it doesn't.
- The build version also caches more than current rpmug, but has an ugly
hardwired limit causing (in theory) errors that can't be nicely
handled, and is the last piece relying on RPMLOG_CRIT actually
terminating the process. The librpm version doesn't fail, in the
worst case its just a bit slower. And that can be fixed anytime by
making it to use hash tables for caching.
- Callers know perfectly well which part they're passing to doScript()
so they can just as well pass in the name and the scriptlet to run,
avoiding silly stuff in the switch-case
- Add another flag set to control package generation, passing around
as necessary. Use this to implement --nodirtokens functionality
in a cleaner manner.
- Call freeNames() at end of buildSpec() instead of requiring API
users to clean up after us. This does mean losing some of the
supposed caching advantage when building on more than one spec,
but hardly matters, one spec at a time is the typical build usage
anyway.
- The whole rootDir seems dubious for build purposes, but in any case its
only relevant during the actual build process, not for spec parsing.
Set spec->rootDir from buildSpec() for the duration of the
build to avoid having to refactor doScript() and all right now.
- Cookies are not a property of spec but a given build, handle this
internally to buildSpec() except for --rebuild which passes the
srpm identifier cookie through buildArgs
- Accept the entire build arguments structure along with a spec, these
contain everything that we'll need
- Just a convenience wrapper for buildSpec() for now, more things
to follow...
- Update the sole existing caller accordingly
The %sepolicy section is used to describe SELinux policy to be included
in a package. It's syntax is similar to other sections (%files, %pre,
%post, etc.) in that you can provide a string and -n after the
declaration to specify policy should be added to a subpackage.
For example:
%sepolicy
# policy in this section will be added to the main package
%sepolicy foo
# policy in this section will be added to the '<mainpackage>-foo' subpackage
%sepolicy -n bar
# policy in this section will be added to the 'bar' subpackage
The %sepolicy section contains zero or more %semodule directives, with the
following format:
%semodule [OPTIONS] path/to/module.pp
The available options are:
-b, --base
The module is a base module
-n, --name=NAME
The name of the module. If not given, assumes the name is the basename of
the module file with file extensions removed.
-t, --types=TYPES
One or more comma-separated strings specifying which policy types the
module can work with. To explicitly state that a module can work with any
policy type, "default" can be specified as the value. If not specified,
assumes the module can work with any policy type, and assigns the types as
"default".
Below is an example of this new format:
%sepolicy
%semodule -n foo -t mls policy/foo.pp
%semodule -n bar -t strict,targeted,mls -b policy/bar.pp
This also adds new header tags to store the new information:
RPMTAG_POLICYNAMES (string array)
RPMTAG_POLICYTYPES (string array)
RPMTAG_POLICYTYPESINDEXES (uint32 array)
RPMTAG_POLICYFLAGS (uint32 array)
The index of NAMES and FLAGS maps directly to the index of RPMTAG_POLICIES.
However, because a single policy can have multiple types, the mapping for
TYPES is not direct. For this, the index maps to TYPESINDEXES, which
contains the index of the policy that the type maps to. This is similar to
how DIRINDEXES is used to map DIRNAMES and BASENAMES. As an example, the
previous %sepolicy section would have the following header tags:
RPMTAG_POLICIES:
0: <foo.pp data, base64 encoded>
1: <bar.pp data, base64 encoded>
RPMTAG_POLICYNAMES:
0: foo
1: bar
RPMTAG_POLICYFLAGS:
0: 0
1: 1 # assumes flag 1 == BASE
RPMTAG_POILCYTYPES: RPMTAG_POLICYTYPESINDEXES:
0: mls 0: 0
1: strict 1: 1
2: targeted 2: 1
3: mls 3: 1
- Yank everything qualifying as "internal helper function" into
internal-only headers, loosely grouped as follows:
1) Everything involving spec-manipulation goes into rpmbuild_internal.h
2) All other miscellaneous helpers go into rpmbuild_misc.h
- This leaves us a rather minimal, and nearly useful API into librpmbuild:
Users need to be able to parse a spec, query or build (parts of) it
and free up the spec structure when done. This is what we have now,
various still exposed structures not counting.
- Actually use mkstemp() for creating the temp file and return a FD_t
dupped from the file descriptor returned by mkstemp().
- Simplify the interface while at it.
- Change callers for the new interface.
- Yes we now require mkstemp() to work, mkstemp() is in POSIX.1-2001 and
this is year 2008...
Panu Matilainen