- Status Closed
- Percent Complete
- Task Type Bug Report
- Category Packages
- Assigned To No-one
- Operating System pentium4
- Severity Low
- Priority Medium
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Attached to Project: Arch Linux 32
Opened by Erich Eckner - 01.03.2020
Last edited by Erich Eckner - 08.03.2020
Opened by Erich Eckner - 01.03.2020
Last edited by Erich Eckner - 08.03.2020
FS#106 - packages are unstripped?
looks, like the new devtools do not strip packages anymore - maybe it was only an intermediate version, that lacked automatic stripping.
Mmh. Good point. I'm also experiencing a problem with disk space when updating normal
packages on a 4 GB SSD.
Maybe just one or two build slaves are not stripping, the rest is..
I'm currently building a gcc with up-to-date devtools - but it's building since quite some time (/etc/makepkg.conf inside the build chroot looks ok).
Hmm, "only a few slaves" is a good point, let's check which one built these packages. Unfortunately, we do not track package size in the mysql database, so there's no easy way to find out which packages grew considerably
the bad guys are/were:
nlopc46, eurobuild6-5, eurobuild6-7-i486
nlopc46 was building with devtools 20200213-1
mmh. strange: /usr/share/devtools/makepkg-i486.conf and /etc/makepkg.conf both contain
a strip on eurobuild6-7-i486.
eurobuild6-5 doesn't make much sense, as all eurobuild6-x slaves share the same devtools
and host /etc/makpkg.conf.
What I did now is, I reinstalled those two slaves (deleted /var/lib/archbuild/xxx).
Another idea: COMPRESSZST=(zstd -c -z -q -)
instead of -20, but I dought it would grow that drastically.
the size-increase is evident for the uncompressed package
I really suspect a temporary issue (I broke devtools inbetween - at least sudo did not work correctly). If the new gcc (which I now scheduled on a build slave, because I lost my patience) is stripped, I will reschedule all packages that grew by more than 50% during 2020.
Find attached a list of all packages, that grew by more than 50% from 2020-01-01 until now.
current status:
devtools-archlinuxewe (and I strongly suspect, devtools32, too) do not strip on i686 (and I strongly suspect pentium4, too), but strip on x86_64. Manually stripping on pentium4 works, though. They also report no apparent errors (except namcap complaining about unstripped binaries, obviously):
and later
it looks like `strip –strip-unneeded` on i686 does not strip, while it does on x86_64
looks, like `strip` works now, but `file` is broken:
(after introducing some debug code into /usr/share/makepkg/tidy/strip.sh inside the chroot
… rescheduling `file` … this will fix everything
If that doesn't help, I'm sure file has again some libseccomp issues which
need fixing in the code itself.
In contrast to chromium we can safely disable seccomp support in file/libmagic.
file 5.38-3.2 is still broken:
I'd say: it's up to your skills, now, Andreas
It was fakeroot triggering a bad syscall at msgget when running file in strip.sh
Adding the -S in strip.sh helps.
The patched 'pacman' package was errornously overwriting a patch from upstream
which added -S to the file call in strip.sh.