Bug #5151
closed
OBS armv7 builds fail with "could not autodetect package type"
Added by osmith almost 3 years ago.
Updated almost 3 years ago.
Description
Some armv7 builds are failing with the following:
[ 1s]
[ 1s] armbuild04 started "build open5gs_2.2.8.202105110026.dsc" at Tue May 11 17:22:37 UTC 2021.
[ 1s]
[ 1s] Building open5gs for project 'network:osmocom:nightly' repository 'Debian_10' arch 'armv7l' srcmd5 '043932919ec53053d14455bc4d0f5119'
[ 1s]
[ 1s] processing recipe /var/cache/obs/worker/root_2/.build-srcdir/open5gs_2.2.8.202105110026.dsc ...
[ 1s] running changelog2spec --target debian --file /var/cache/obs/worker/root_2/.build-srcdir/open5gs_2.2.8.202105110026.dsc
[ 1s] init_buildsystem --configdir /var/run/obs/worker/2/build/configs --cachedir /var/cache/build --prepare --clean --rpmlist /var/cache/obs/worker/root_2/.build.rpmlist /var/cache/obs/worker/root_2/.build-srcdir/open5gs_2.2.8.202105110026.dsc build ...
[ 1s] unknown keyword in config:
[ 1s] could not autodetect package type
[ 1s]
[ 1s] armbuild04 failed "build open5gs_2.2.8.202105110026.dsc" at Tue May 11 17:22:37 UTC 2021.
[ 1s]
This appears to be a problem with the "armbuild04" node. The same packages build fine with e.g. "armbuild21".
This is an upstream issue, I have reported it in #opensuse-buildservice, and got the suggestion to add "binarytype: deb" to the prjconf as workaround, while this is being looked into. I did add the following, but the result is the same:
%if 0%{?debian_version}
binarytype: deb
%endif
It has been one week and we're still suffering this issue. Osmocom users on ARM platforms as a result have a broken package feed for one week.
If we look at
https://build.opensuse.org/project/monitor/network:osmocom:nightly we see that this affects
- Debian 10 / armv7l
- Debian 9 / armv7l
- Raspbian 10 / armv7l
They all fail due to the last successful osmo-gsm-manuals build is 20210818 while osmocom-nightly is already 20210819.
- Status changed from Stalled to Resolved
- % Done changed from 0 to 100
We did not receive e-mails with that build failure anymore. However, the armv7l builders were always behind, and could not finish building packages before the next nightly sources were pushed. As discussed, I've disabled armv7l for debian 9 and 10 for the nightly feed.
See also: #5165
New developments:
- Yesterday I've worked on an unrelated feature that required update-osmo-ci-on-slaves jenkins job to work properly
- I've noticed that this job didn't actually run on any nodes anymore and just instantly finish with success without doing anything
- So I configured it to run on all nodes again
- Docker images were rebuilt on all nodes
- master-osmo-trx and master-osmo-pcu started failing for armv7 with "No package 'gnutls' found" since debian-stretch-jenkins was rebuilt
- I've investigated this today and found that "dpkg --add-architecture i386" added four years ago for x86_64 was also running on ARM and suddenly caused i386 packages for libgnutls-dev and some others to get installed.
- I tried to verify that above patch works, and ran into another issue. Now debian-stretch-jenkins fails to build for rpi with: 'E: Unable to locate package libulfius-dev'
- The problem is, that we install liblimesuite-dev, libuhd-dev, libulfius-dev from Osmocom nightly in debian-stretch-jenkins (so we have these builddeps available to build various Osmocom software that may need it), the rpis run an armv7 kernel, and the packages are not available for armv7 anymore (disabled 7 days ago, see above).
- I guess this error was masked earlier with "dpkg --add-architecture i386", it probably had just installed the i386 versions of these packages and we didn't notice build failures by chance because we didn't build projects in jenkins that depend on these packages.
- So now I'm configuring OBS to enable building only these packages and their depends for armv7 again, then debian-stretch-jenkins should work again.
Also available in: Atom
PDF
