IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- Add _allow_deps_with_beginning_dot macro to allow dependencies
beginning with a dot character (such as ones generated by replaceDeps
function) in spec file (vseleznv@).
After commit f4d876f93 rpm-build may generate dependencies beginning
with a dot character, but spec parser refuses such dependencies.
rpmrebuild fails to rebuild packages with such dependencies because it
builds packages with rpmbuild from generated spec files.
Most of the binaries on mipsel do not contain the stack section,
so this check is not relevant for that architecture. Morover,
it fails, since it can't find the stack section, which is
(rightfully) not present.
eu-elflint does not understand mipsel binaries currently,
so here we disable that check, too.
The code in question uses an improvised "strntoul" function (hidden
behind the GET_NUM_FIELD macro) which returns "int".
int cpioHeaderRead(FSM_t fsm, struct stat * st)
...
GET_NUM_FIELD(hdr.filesize, st->st_size);
When a file size undergoes an "int bottleneck", it cannot be safely
converted back to an unsigned 64-bit integer. By the C rules, if the
size is in the range 2G..4G-1, int becomes negative (or this may be
undefined behaviour already, I'm not a language lawyer), and conversion
to unsigned 64-bit is performed as if by adding 2^64 to the negative
value.
So you get a huge 64-bit file size. Funnily enough, if you truncate it
to 32 bits, it's back to normal! That's why things worked with 32-bit
size_t.
static int expandRegular(/*@special@*/ FSM_t fsm)
...
size_t left = st->st_size;
- Implemented limited support for large files: a 2GB+ file can now be packaged,
but the total size of uncompressed cpio payload is capped at 4 GB.
- Automatically downgrade LZMA compression levels 7-9 -> 6 on small payloads.
- Implemented limited support for large files: a 2GB+ file can now be packaged,
but the total size of uncompressed cpio payload is capped at 4 GB.
- Automatically downgrade LZMA compression levels 7-9 -> 6 on small payloads.
This is probably the last change of such kind. There are many other
instances left, and fixing them all is hopeless. On the other hand,
the way mod 2^32 arithmetic works, although technically not always
well defined, is to our advantage. I suggest that only user-visible
discrepancies further be fixed.
The following comparison to st_size looks particularly bad.
The code turns out to be unused!
lib/signature.c:
> verifySizeSignature(const char * datafile, int_32 size, /*@out@*/ char * result)
> [...]
> if (size != st.st_size) {
> sprintf(result, "Header+Archive size mismatch.\n"
Some of the preceding code is probably undefined or unspecified behavior,
but there's no easy way to fix it other than rewriting, which I'm not
going to do. Surprisingly enough, the code just happens to work, due to
a series of mutual cancellations mod 2^32. As they say in Russian,
the war will write off all. Likewise, mod 2^32 arithmetic can write off
a multitude of sins (James 5:20).
> static inline rpmRC checkSize(FD_t fd, int siglen, int pad, int datalen)
[...]
> int delta;
[...]
> delta = (sizeof(struct rpmlead) + siglen + pad + datalen) - st.st_size;
Here, the expression in parentheses yields a different numeric value
depending on whether datalen is signed or unsigned. However, when delta
is finally truncated to 32 bits, the result turns out to be the same.
> switch (delta) {
> case -32: /* XXX rpm-4.0 packages */
> case 32: /* XXX Legacy headers have a HEADER_IMAGE tag added. */
> case 0:
The diff context is just big enough to see what happens.
RPMTAG_FILESIZES are interpreted as signed integers, and st_size which
has type off_t is also signed. So the 32-bit file size form the header
gets sign-extended, after which the equality to st_size does not hold.
This completes support for building packages with 2G+ files, more or
less (packaging 4G+ files is still a distant goal). I am able to build
a valid package with a 3G sparse file on both i586 and x86-64. On i586,
though, such a package cannot be installed with rpm-4.0:
error: unpacking of archive failed on file /usr/bin/6;5a70a676:
cpio: write failed - File too large
I believe there is no obvious way to identify and mark such packages,
since rpmlib(LargeFiles) dependency is meant only for 4G+ files, which
require 07070X cpio entries.
Therefore, limited support for handling such packages shall be provided
for rpm-4.0 in branch p8 (there are issues other than simply enabling
AC_SYS_LARGEFILE).
This turns out to be a bit easier than I thought yesterday. When mmap
fails in lib/fsm.c, it falls back to file descriptor IO. So by simply
enabling AC_SYS_LARGEFILE, I'm already able to package a 3G file, which
can be written like this:
perl -e 'seek STDOUT,3<<30,0 and print 1 or die' >out
The nearest goal is to be able to package files up to 4G, on both 32-bit
64-bit architectures, provided that cpio payload size also does not
exceed 4G. More specifically, the limit is 2^32-2, while 2^32-1 remains
special (this is not my own invention, I adopt it from rpm.org).
If the limit is exceeded, rpmbuild should fail gracefully instead of
writing malformed packages with truncated integer tags.
(Supporting 4G+ files is a distant goal - neither rpm-4.0 nor apt-rpm
can handle them yet. Besides, it's not clear if producing such big
packages is even a good idea, unless one wishes to package p0rn.)
This is the reason why files >= 2G could not be added to cpio, even on
64-bit architectures. Fwrite was called with a buffer >= 2G, but the
return value was truncated to int (this narrowing conversion is probably
undefined behavior already; what happens next, though, is that after
casting to size_t it assumes a very big numeric value of >= 2^64-2^32).
So rpmbuild was failing with an unrelated errno, "cpio: write failed -
Bad file descriptor".
There are other reasons why this still won't work on 32-bit architectures.
For one, rpmbuild mmaps a file before feeding it to cpio, and 32-bit
architectures have a very limited ability, if any, to mmap 2G+ files.
- imz@:
+ Turned on running %__find_{conflicts,obsoletes} if they are defined.
+ shell.req.files: included #!/usr/bin/env sh.
+ verify-elf: allowed standalone use (without failing due to grep's status).
- macro.c: increased maximal macro depth.
- Introduced %_libsuff and %_is_libsuff macros.
- Added support of mips{,n32,64}{,el}, riscv64, and s390x targets.
- Added non-lfs symbols from librt.so.1 library to verify_lfs check.
- Filtered string functions from the list of non-lfs symbols.
Previously one who wanted to use only suffix from %_lib macro (without
'lib' prefix) had to either strip it with shell or try to guess it
from %_lib macro.
New macros allow to simplify library suffix logics in spec files:
* %_libsuff is always defined (to %nil on targets where %_lib = lib);
* %_is_libsuff is defined only on those targets where suffix
is not empty (it is useful for %{?...} expressions).
Previously (according to the exit statuses):
0. if something strange was found in $rpath, an error was reported;
1. if nothing strange was found, no error was reported;
2. if grep failed, it looked like the previous case and no error was
reported (as if $rpath was valid).
Now, the pipe (and the whole script) would abort on grep's failure.
Now, if something fails, the pipe (and the function, and the whole
script) will fail.
If the exit codes are normal, they are handled according to our logic.
Previously, a failure (which is an exceptional rare case) would lead to:
1. skipping the further exe_stack check and error_strict STACK "$f" 'STACK entry not found'
2. silently skipping the exe_stack check (which was impossible anyway because of the failure)
The pipe (and the function, and the whole script) would fail when the
resulting constructed rpath was empty. But usually at least
$RPM_VERIFY_ELF_LDD_RPATH is not empty, so the bad behavior has not
been observed.
However, when verify-elf is used standalone, $RPM_VERIFY_ELF_LDD_RPATH
is empty indeed, and this improvement becomes important.
Before this improvement:
$ RPM_BUILD_ROOT=/home /usr/lib/rpm/verify-elf /bin/pwd; echo $?
1
After this improvement:
$ VERIFY_ELF_UNRESOLVED=strict RPM_BUILD_ROOT=/home /usr/lib/rpm/verify-elf /bin/pwd; echo $?
0
$ VERIFY_ELF_UNRESOLVED=strict RPM_BUILD_ROOT=/home /usr/lib/rpm/verify-elf /usr/lib64/python3/site-packages/_cffi_backend.cpython-35m.so; echo $?
verify-elf: ERROR: /usr/lib64/python3/site-packages/_cffi_backend.cpython-35m.so: undefined symbol: PyExc_SystemError
....
1
nproc(1) based approach has two advantages over /proc/stat based
calculations. Firstly, nproc(1) uses sched_getaffinity(2) and therefore
is not affected by /proc availability. Secondly, nproc(1) outputs
the number of processors actually available which may be less than
the number of online processors.
nproc(1) was introduced in coreutils-8.1.
When the given ELF file doesn't specify PT_INTERP, e.g. if it's a shared
library, we have to guess it. We used to try the program interpreter
of dump_ld_config, but it doesn't work well enough in multilib
environments, so extend the guess by trying interpreters listed
in RTLDLIST from /usr/bin/ldd script.
If RPM_STRICT_INTERDEPS environment variable is set and not empty, this
function replaces every strict requirement on NEVR with
".${RPM_STRICT_INTERDEPS}-NEVR", and adds to every package which
provides NEVR ".${RPM_STRICT_INTERDEPS}-NEVR" provide if some other
package requires this ".${RPM_STRICT_INTERDEPS}-NEVR".
This is needed to able to build a source package to different repo
branches with the same NEVR, and to rebuild the source package as well
with same NEVR within one branch and avoid interdep collisions.
- Add e2k arch and subarches:
- Modify installplatform for e2k.
- Add e2k arch, subarches and all macros for them.
- Tag changes (by vseleznev):
- Add RPMTAG_IDENTITY, RPMTAG_AUTOINSTALLED.
- respect device ID when remap inodes.
This tag represents binary package build characteristic: if two binary
packages have equal RPMTAG_IDENTITY values, it means that these packages
have no significant differences.
One of the applications of RPMTAG_IDENTITY is reproducible build
verification.
Signed-off-by: Vladimir D. Seleznev <vseleznv@altlinux.org>
This tag is needed to track automatically installed packages with
rpmdb. Zero value means that a package was installed manually, other
values mean that the package was installed automatically as some else
package dependency.
Signed-off-by: Vladimir D. Seleznev <vseleznv@altlinux.org>
