In the %apply_patches that inspired %autopatch, patch application
respects the fuzz settings that are used for %patch. %autopatch
and %autosetup weren't using this, which led to an inconsistent
patch application behavior.
This is useful to silence output in forked programs:
https://bugzilla.redhat.com/show_bug.cgi?id=1287918
Tested with the following scriptlet:
%post -p <lua>
pid = posix.fork()
if pid == 0 then
assert(posix.exec("/bin/sed"))
elseif pid > 0 then
posix.wait(pid)
end
pid = posix.fork()
if pid == 0 then
posix.redirect2null(2)
assert(posix.exec("/bin/awk"))
elseif pid > 0 then
posix.wait(pid)
end
As expected, the error message from sed is printed, the error message
from awk is not.
When --builtrpms is used then rpmspec operates only on the binary
package headers of packages which would be built from spec. That means
ignoring package headers of packages that won't be built from spec
i. e. ignoring package headers of packages without file section.
For a pre hook function display an error message and for a post hook
function display just a warning message. This corresponds with
the way how error/warning messages are displayed for scriptlets.
Also add a debug message into selinux plugin.
In rpmbuild only an init hook was called and no other hooks was called.
So the plugins were initialized in rpmbuild but they were never used
in rpmbuild. Even the init hook was called from place where calling
of init hook made no sense (it was called from rpmCheckDeps()).
Also it wasn't possible to disabled plugins in rpmbuild with --noplugins,
which caused problems in rpm test suite.
SOURCE_DATE_EPOCH environment variable is a distribution-agnostic
standard for build systems to exchange a timestamp.
SOURCE_DATE_EPOCH specification is available at:
https://reproducible-builds.org/specs/source-date-epoch
Signed-off-by: Dhiru Kholia <dhiru@openwall.com>
Some noarch packages need build tools not available on all architectures.
By using %_build_cpu you can restrict the architectures those noarch
packages can be build on.
rpmquery and rpmverify are symlinks to rpm. The former are usually
installed in /usr/bin, the latter in /bin, so the symlink points to
../../bin/rpm. But for installations into other prefixes, the synlimk
should just point to the same directory.
If there was need to regenerate indexes and index file was open readonly
then index file was closed and open again as readwrite. But problem was
that index file may have already been memory mapped so closing it wasn't
right solution.
Now if it is possible then index file is open as readwrite from
the beggining no matter of requested open flags.
We really should not suspend or hibernate during rpm operations. Chances are
too high to not wake up properly and damage the system (see rhbz#1297984).
Previously it wasn't able to get an exclusive lock with rpmpkgLock() if
pkgdb was open readonly. That's ok for pkgdb but rpmpkgLock() is also
used in rpmxdbLock() which is used for locking indexes. And when pkgdb
was open rdonly even if indexes were open rw, it wasn't possible to
write into them because it wasn't possible to get exclusive lock with
rpmxdbLock()->rpmpkgLock().
Having pkgdb readonly and indexes rw can happen when pkdb is open as
readonly but during opening of indexes some missing index is detected
so it is necessary to open indexes as rw and regenerate them.
Now rpmpkgLock() enables to get exclusive lock without having pkgdb
open as rw. New function rpmpkgLockInternal() behaves as rpmpkgLock()
previously and it is used only for pkgdb.
Per the recommendation of Nick Coghlan and Toshio Kuratomi,
pythonXegg(M) is being renamed to pythonX.Ydist(M).
An option has also been added to add a pythonXdist(M)
Provides for distributions that may prefer to have it.
The option '--majorver-provides' is intended for use
if only one Python stack per major version will be
available at a given time, as unexpected results may
occur if there are multiple independent Python stacks
per major version available.
Consequently, it will not be on by default when using
the generator for generating Provides.
Additionally, .egg-info data is being replaced with
.dist-info data, so we need to handle that case, too.
See for more details:
https://lists.fedoraproject.org/archives/list/python-devel%40lists.fedoraproject.org/thread/SQBSAS4T25HK5YJBNBSFDD7KDQWDELL6/
Also, Thierry Vignaud brought up on rpm-maint that Mageia
currently uses "pythonegg(X)(M)" (e.g. "pythonegg(3)(rpm)"
for python3 rpm bindings package) in their Python packages
to pull in Python dependencies and requested a way to
not break Mageia.
After discussing with Florian Festi about it, Mageia's
pythonegg(X)(M) will be supported by adding '--legacy'
as a switch to generate legacy Provides/Requires to maintain
compatibility with Mageia's existing usage.
The '--legacy-provides' switch will enable pythonegg(X)(M)
Provides in addition to the new pythonX.Ydist(M) format to
allow for a easier transition.
The RPM code contains setprogname()/getprogname() support implemented through compatiblity layer with very old GLIBC (internals supported back to '95 and earlier), before stabilization of the GNU C library. This compatiblity layer (__progname, __assert_progname, setprogname()) is supposed to support well archaic GLIBC, but on the other hand it pollutes the library namespace and introduces unpredicable compillation errors on BSD systems.
The functions setprogname() and getprogname() are natively supported in NetBSD and work the same way as __progname from the GNU C library (they are even implemented in the same way - but with a slightly changed logic). The support for very old (20 years and older) GNU C Library is obfuscating the code, because it uses defines over defines without a word of explaination why to do so.
It's important to note that the setprogname()/getprogname() was inconstiently implemented in the codebase, duplicating the code and/or functionality.
Add new generic functions getprogname() and setprogname() and bind it to:
- the current and for two decades stable GNU LIB C implementation,
- the current NetBSD implementation (introduces to NetBSD in 2002),
- fallback reimplementation functions of the setprogname() and getprogname() functionality for other systems.
Don't support anymore old GNU Lib C internals and don't support older NetBSD systems, as they aren't supported for many years.
Add to the codebase comments explaining the relevant codeparts.
rationale:
1) typelib deps are unrelated to python
2) typelib deps are computed by suse generator
3) suse generator is not present upstream
4) let's not reinvent internal deps generator here...
fdatasync() is not enough in some filesystems because blocks with data
are flushed to a disk but the structure which references these data
blocks is not.
Failing ftruncate() at this place is not critical but show at least
warning that something goes wrong and quiet the compiler warning
about unused result.
Currently, there's no callback type that would be issued per each
transaction element. RPMCALLBACK_TRANS_PROGRESS is only issued during
the prepare phase but not when packages are actually installed or
erased. Likewise, RPMCALLBACK_INST_ST* and RPMCALLBACK_UNINST_ST* won't
be issued if an install or erase operation is skipped for some reason (a
script or package upgrade failure).
Having such a callback would allow the Python API consumers to always
know upfront which element is about to be processed, before any other
callbacks are issued. This is important since not every callback type
carries enough data about the subject package; while the INST types
provide the user object passed to a former addInstall call, the UNINST
types only provide the package name (which may not be unique within the
transaction set).
This commit adds such a callback.
Invoking '%__scm_setup_$__scm' without looking at option '-S' in the
specfile, permits dynamic selection of the SCM on the commandline
rpmbuild --define="__scm SCM"
Tested with rpmbuild 4.13, git, svn, ... on Linux Mint 17.2.
Neal Gompa (ニール・ゴンパ)