Starting to take care of failing packages #40
Labels
No Label
blocked upstream
bug
build-failure
duplicate
enhancement
help wanted
informational
invalid
invalid/corrupt package
packaging issue
priority: high
question
support
wontfix
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: ALHP/ALHP.GO#40
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I will make this tread so we can take care of failing pacakges.
Correct me if i may be wrong, but packages are build with LTO righ?
For those packages that failed to pass validity check.
The solution would be either to "SKIP" the validity check, or either download the package on 2 computers checksum the file and if the checksum return the same, then replace it to the new checksum.
If replacing the checksum, verifying on two seperate compturer whould add a layer of security in case the file might have been tempered with (witch should be highly unlikely anyway)
These are some of the packages that i've looked at for now and fail to pass validity check.
Libssh2
dnscrypt-proxy
discord
libpipewire02
libpipewire02 is missing libudev as a dependency,we should add it and see if it build. I had no luck at the moment with it. It not a super important pacakge to worry about at the moment, because it is deprecated anyway, and the only package that need it is Weston
xz
xz seem to be building fine on my side, it might just need a rebuild
I was also thinking, for packages that need to be build with go, should we try to build them with gcc-go instead? It give more optimized pacakges and need less build time.
Some pacakges might fail to build tho, so it is to see.
gst-plugins-base, gst-plugins-good, libxcrypt, mdadm and syslinux
gst-plugins-base, gst-plugins-good, libxcrypt, mdadm and syslinux, seems to not want to build with -O3, we should try to build them with -O2 instead.
If it doesn't build with -O2, it would need further investigating.
jfsutils
jfsutils might just need a simple rebuild
Here is a list of all pacakge that either didn't pass checksum or coundln't download, i might have missed a few, but they're mostly all here:
apper
anthy
algol68g
apr
byuu
buckygen
bsdiff
cksfv
chntpw
cgns
cauchy
cargo-depgraph
duperemove
drumgizmo
dnscrypt-proxy
disorderfs
discord
discover
deepin-wm
epson-inkjet-printer-escpr
emacs
emacs-nox
e3
flickcurl
fbreader
gsettings-qt
gitea
gdc
httping
imlib2
intel-dnnl
java8-openjfx
kexi
kiwix-lib
kmplayer
knative-client
kubectl-ingress-nginx
libappindicator
libgcrypt11
libgcrypt15
libguess
libkate
liblzf
libmilter
libpgf
libretro-pcsx-rearmed
libssh2
libx86
livewallpaper
love
lv2file
mac
mcqd
mdk3
multitail
n2n
netwatch
non-sequencer
normaliz
nss_ldap
openbsd-netcat
pax-utils
pdnsd
pidgin-talkfilters
primus_vk
prjtrellis
psiconv
purple-plugin-pack
python-thrift
quagga
r8168-lts and r8168 (should add it to the blacklist)
scummvm-tools
sdl2_mixer
signon-plugin-oauth2
signon-ui
signond
slirp4netns
sloccount
soil
sonic-visualiser
sqlheavy
sundials
tachyon
telepathy-accounts-signon
tickrs
ukui-control-center
uutils-coreutils
vamp-plugin-sdk
virtualgl
wabt
waylock
xawtv
Thanks for starting this, I somehow still didn't find time.
Let me go through some of your points. Just before I start I want to clarify that we want to upstream almost all problems we find (we want to be as close to 'vanilla' Archlinux as we can get), since these problems are going to be in upstream Arch as well (besides -O3/x86-64-v3 specific problems of course).
PKGBUILD modifying beyond pkgver/pkgrel or trivial changes is also undesired, since that would require some overlay work in ALHP and manual intervention for almost all updates, which defeats having a buildbot in the first place in my humble opinion.
Packages are build with a on-start modified
makepkg.conffromdevtools, see https://github.com/archlinux/devtools/blob/master/makepkg-x86_64.conf.This is a tricky one. So, these packages are most likely just out-of-date, but, as you may know, that in itself is not a bug from an Archlinux point of view.
Best solution here may be to check if they really are (out of date) and flag them if its not already done.
Should be reported upstream, see my explanation at the beginning.
Interesting idea. That can only be done if PKGBUILD modification to build with gcc-go can be automated.
That needs a feature in ALHP which I already mentioned in some issues but have not implemented yet: an
-O3specific blacklist.I'm going to requeue that, can't hurt to try.
If I find some spare time I'll try to dig into that failed list as well.
If anyone wants to report any of these issues upstream it would make sense to reconfirm that these problems exist with the vanilla buildflags. Also, linking any created/existing bugreports would be a big help for anyone who wants to contribute.
I'd love to add myself to the list of people attempting to fix builds, seeing as I have a skylake class processor. However, I'm not sure where to begin. @anonfunc is there some guide on how I can get started contributing?
A guide in of itself not (yet), but its relatively simple, even if somewhat time-consuming.
Eli wanted a list of packages failing, sorted by broader categories, like for example missing or wrong declared dependencies. Since we build without checks (!checks), some packages fail because their checkdependency is really a makedependency, like above mentioned
libpipewire02.Other packages fail because the stricter gcc checks, like e.g.
libxcrypt(there are many more).We also have a lot that fail to download or verify, but I think these need to be excluded for now, since most of them could be simply out of date, which is not a bug.
Then we have a another category witch are plain packaging bugs or oversights, like rm'ing a file that's not even there, etc.
There are a lot of things we can, and should, report upstream, as long as its really a problem existing in vanilla Arch too. They'll run into these eventually. (well maybe except for the check dep. things)
My suggestion for now would be something like this (excluding verification/download problems where it's not obvious source has moved):
Feel free to suggest better categorization if you feel like you got it nailed down.
List of failing packages can be obtained either in the package overview (search for FAILED) or in the *_failing.txt files at the repo root dir. Logs for these failed builds are directly linked in package overview, for the text files you need to go to repo/logs/$pkgbase.log
That's helpful, thanks. I guess what I'm saying is I assume to help with these one would need to clone this repo and run the service locally?
Oh no that's not necessary. All buildlogs from failing packages are publicly available. (see my post at the very end)
The information is all there, it just needs sorting.
A short update: I enabled checks recently after some discussion with various Archlinux devs and TUs. There was no real consensus among them if failed builds caused by disabled checks leading to missing dependencies is a real issue concerning them.
Enabling checks leads to higher buildtimes overall, especially for some of the larger packages with big testsuites, but as long as wrong/missing makedeps are considered 'wontfix' from upstream there is no real alternative other then patching PKGBUILDs, which I like to avoid because it comes with a lot of manual intervention.
I queued all 300 something failed packages to get an overall impression of how many still fail and why. A big chunk of still failing builds are caused by missing PGP keys, which we can ignore for now.
Okay hope they're will be less failing packages