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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
If debugedit failed to extract sources list, uncompress and try again.
Then compress back.
ps. Interesting relevant reading:
https://blogs.oracle.com/solaris/elf_section_compression-v2
Spelling suggestions by Dmitry V. Levin <ldv@altlinux.org>.
Terminate build if stripped ELF files are found. Usage:
%define _stripped_files_terminate_build 1
Formatting suggestions by Dmitry V. Levin <ldv@altlinux.org>.
Actually, `.debug_line` section is checked (implicitly by debugedit)
which should go together with all `.debug_*` sections. This
simplification will make check faster.
Note: Only non-stripped binaries are checked.
Spelling fixes, usage of `Warning' function, and redirect to stderr is
suggested by Dmitry V. Levin <ldv@altlinux.org>.
- brp-debuginfo: Re-enable processing of kernel modules.
- debuginfo.req: Fix 'vmlinux' processing error on ppc64le.
- process-debuginfo: Do not call eu-elfcompress if it doesn't exist.
E2K arch have old elfutils-0.159 which doesn't have eu-elfcompress.
Error:
/usr/lib/rpm/process-debuginfo: line 68: eu-elfcompress: command not found
Reported-by: Andrey Savchenko <bircoph@altlinux.org>
`vmlinux' on ppc appears to have `Dynamic Section', this triggers its
processing with `/usr/lib/rpm/ldd' which returns error:
ldd: ERROR: /usr/src/tmp/kernel-image-std-test-buildroot/usr/lib/debug/lib/modules/5.4.49-std-test-alt4/vmlinux: failed to find the program interpreter
find-requires: ERROR: /usr/lib/rpm/debuginfo.req failed
error: /bin/sh failed
error: Failed to find Requires
Reported-by: Anton V. Boyarshinov <boyarsh@altlinux.org>
Do not try to process ELF relocatable objects that are not kernel
modules, this fixes the following regression:
/usr/lib/rpm/debugedit: ./usr/lib64/gcc/x86_64-alt-linux/9/crtfastmath.o: DWARF version 0 unhandled
objdump: ./usr/lib64/gcc/x86_64-alt-linux/9/crtfastmath.o: bad value
verify-elf: ERROR: ./usr/lib64/gcc/x86_64-alt-linux/9/crtfastmath.o: objdump failed
Fixes: 7aa048df38 ("Generate debuginfo for kernel packages")
- Generate debuginfo for kernel packages.
- Process debuginfo in parallel using process-debuginfo script.
- debugedit -n to avoid recomputing build-id.
Allow `crash` (gdb-7.6 based) to work out of the box.
Otherwise it will fail with the error:
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 4)
Alas, it will not be able to load debuginfo for the ko modules, but, advanced
user can `eu-elfcompress -t none` them manually.
We can't keep modules uncompressed due to `cpio archive too big - 4136M'
RPM build error.
Avoid `DWARF version 0 unhandled' for compressed ELFs in
find-debuginfo-files.
Based on 6e9fd97f6 ("debugedit: Add -n, --no-recompute-build-id.")
by Mark Wielaard <mark@klomp.org>.
- Support uncompressed (std-def) and compressed (un-def) modules. Also,
support xz(1) compression if we'd switch to it.
- If module is uncompressed it stays in the kernel-image rpm, if it's
compressed then uncompressed module goes into /usr/lib/debug tree and
will be in debuginfo rpm. Compressed modules will be re-compressed after
stripping.
- vmlinuz binary triggers extraction of vmlinux from the kernel-source
tree, and it's then placed into /usr/lib/debug tree, then processed and
stripped as usual.
- Logic of processing of vmlinux binary for domU packages is not changed.
Some flavours do not even pack it. Thus, do not remove your
`%brp_strip_none'.
- Output of file(1) for vmlinuz is only parsed for filename, because, on
different architectures it detects completely different things.
- Debug files are compressed with `eu-elfcompress'.
- You still need to enable `CONFIG_DEBUG_INFO=y' in for `.config'.
No other changes to spec should be needed.
Thanks to Nikita Ermakov for starting this work.
- Added /usr/lib/rpm/armv8l-alt-linux/macros for builds on armv8l machines.
(Fixes 4.0.4-alt108:
- installplatform, rpmrc.in: made armv8l compatible with armh.)
* * *
Add arch_canon statements for "armh", "armv7l", "armv8l". Re-order
them to be more similar to the current upstream rpmrc.in (say,
rpm-4.15 or rpm-4.13.0.1-alt22). Note, however, that this change
doesn't seem to be essential for anything, since "the arch in the lead
[the arch number] is not used for any purpose for most of this
century".[1]
[1]: https://stackoverflow.com/a/39426935/94687 "answer by Jeff Johnson"
* * *
Re-order ARM arch_compat statements to get an order similar to the
upstream (say, rpm-4.15 or rpm-4.13.0.1-alt22) to be able to compare
them more easily; compare to our rpmrc.in:
* the upstream first lists the big-endian archs (noarch -> armv4b);
* then the little-endian ones without hardfloat (noarch -> armv3l -> armv4l ->
-> armv4tl -> armv5tl -> armv5tel -> armv5tejl -> armv6l -> armv7l -> armv8l);
* the the little-endian ones with hardfloat
(noarch -> armv6hl -> armv7hl -> armv7hnl -> armv8hl);
* and separately the 64-bit one (noarch -> aarch64).
In our version of rpm-build we don't have any code for the detection
of the 'h' (hardfloat) or 'n' (neon) CPU features, but we actually
insert our "armh" arch into this chain (with 'h' hardfloat) between
what ought to be "armv6hl" and "armv7hl", and drop "armv6hl" from our
chain; in our compatibility chain, 'h' is silently supposed for "armv7l"
and "armv8l".
However, note a bad thing about this discrepancy: when our rpm-build
builds a package on armv8l targeting this arch, it's arch is armv8l.
However, when installing such a package on a normal ARMv8-A machine,
the 'h' feature must have been detected by "rpm -i", so our just built
package must not match the system arch and the installation must be
denied. However, in practice, I don't see such bad behavior in our
Girar builder when rpminstall-test-archcompat-checkinstall is
invoked... (I don't know why. Perhaps, the 'h' detection code doesn't
work as expected in rpm.)
* * *
Re-order similarly buildarch_compat statements.
Targeting armv8l should trigger all the general ARM conditions in
specfiles and set the custom optflags.
Fixes: c18f1b7d ("installplatform, rpmrc.in: made armv8l compatible with armh")
If rpmbuild is invoked without --target, it looks for the macros based
on `uname -m`. The resulting error message on armv8l machines (when
building a noarch package) was like this:
> Invalid or unknown architecture: noarch-alt-linux
> Executing(%install): /bin/sh -e /tmp/sh.txFqhrP3/rpm-tmp.63120
> error: Bad exit status from /tmp/sh.txFqhrP3/rpm-tmp.63120 (%install)
--a bit misleading due to the following fallback code from macros.in
being executed:
%___build_pre \
%{warn:Invalid or unknown architecture: %{_target_cpu}-%{_vendor}-%{_target_os}\
}exit 1\
%nil
(Are there additional customizations that we might want to enable on
armv8l compared to our armv7l or armh configuration?
armv8l means having AArch32 architecture, typically on a CPU with
AArch64, too. AArch32 means that A32 (ARM) and T32 (Thumb-2)
instruction sets are admitted. See, e.g.,
<https://bgamari.github.io/posts/2019-06-12-arm-terminology.html>.
Currently, our armv8l-alt-linux/macros won't differ essentially from
armv7l-alt-linux/macros. Probably, that's fine, because it seems that
all ARMv8 and all ARMv7 processors support Thumb-2 instructions in the
T32 instruction set, so there are no essential differences in the
optimizations that can be applied.)
Reported-by: Vitaly Chikunov <vt@altlinux.org>
Suggested-by: Dmitry V. Levin <ldv@altlinux.org>
Fixes: c18f1b7d ("installplatform, rpmrc.in: made armv8l compatible with armh")
FCFLAGS is modern replacement of FFLAGS for gfortran.
Details can be found in [1].
Modern Fortran applications use FCFLAGS instead of FFLAGS, so we have
them built without platform-specific and general optimizations.
As an example one may look how libgfortran is being built within gcc-9:
libgfortran/Makefile.in uses only FCFLAGS, not FFLAGS and mary other
applications follow.
[1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Fortran-Compiler.html
- ldd.in: made preloading of PIE objects work again.
- Set the value of SOURCE_DATE_EPOCH environment variable (if any)
as the source package buildtime.
glibc starting with commit glibc-2.30~85
(elf: Refuse to dlopen PIE objects [BZ #24323])
no longer supports preloading of PIE objects.
Workaround this by swapping the target object and the preloading
PIE object when possible.
Reported-by: ALT beekeeper
Reported-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
When hasher generates an src.rpm from pkg.tar, it sets $SOURCE_DATE_EPOCH
according to pkg.tar's specfile modification time which in turn is set to
the corresponding commit time.
When hasher builds from an src.rpm, it sets $SOURCE_DATE_EPOCH according
to the src.rpm's RPMTAG_BUILDTIME.
This changes helps to connect these two stages, setting the
RPMTAG_BUILDTIME of the generated src.rpm to $SOURCE_DATE_EPOCH.
Co-Authored-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
- find-package, shebang.req: introduced RPM_FINDPACKAGE_MANDATORY=1.
When an interpreter is invoked by name, as in "#!/usr/bin/env python32",
and is missing, this will now force the dependency on /usr/bin/python32.
* build/parsePrep.c (doPatch): Do not pass null pointer to sprintf.
(doAutopatchMacro): Do not pass null pointer to strcmp.
Fixes: 9c18a402 ("Make %autopatch and %patch accept -pg")
- Generate requirements on binaries used in systemd service files
(by Anton V. Boyarshinov)
- Made %autopatch and %patch accept -pg (by Vladimir D. Seleznev).
- Fixed build with new gettext.
* parsePrep.c (doPatch): Change strip argument type to const char *.
(doPatchMacro, doAutopatchMacro): Change opt_p variable type to char *,
change checking of opt_p: it can be either a number or a 'g' symbol
assuming that -pg is a valid option for patch command.
Mechanically substitute _IO_off64_t with off64_t using
$ git grep -Fwl _IO_off64_t |xargs -r sed -i s/_IO_off64_t/off64_t/g
This follows glibc-2.28~574 and fixes build with glibc >= 2.28.
Spec files have a lot of metadata about a project. However one of the
most key components is the upstream version control system which was
notably lacking.
Resolve this by adding a "VCS" key. There is no specification
for contents of this key, given that the set of version control
systems (and features thereof) are not well-defined. However,
recommendations are:
* git: This URL should be in a form that can be passed to "git clone",
with the additional feature that an optional fragment identifier "#foo"
denotes a branch or tag.
%autopatch is a directive to apply all patches, it supports -p<num> and
-F<num> options
%autopatch was initially introduced in rpm.org with version 4.11 but with
different implementation.
