Bug#1049886: btllib: FTBFS on armhf due to tests timing out
Source: btllib Version: 1.4.10+dfsg-1 Severity: serious Justification: FTBFS Tags: trixie sid ftbfs Hi, btllib currently fails to build from source on armhf with the following tests-related error: Iteration 1 Test FASTA == Summary of Failures: 9/15 indexlr TIMEOUT30.18s killed by signal 15 SIGTERM 10/15 seq_reader_fasta_module TIMEOUT30.08s killed by signal 15 SIGTERM 11/15 seq_reader_fastq_module TIMEOUT30.14s killed by signal 15 SIGTERM 12/15 seq_reader_multiline_fasta_module TIMEOUT30.07s killed by signal 15 SIGTERM 13/15 seq_reader_multiline_fastq_module TIMEOUT30.12s killed by signal 15 SIGTERM 14/15 seq_reader_sam_module TIMEOUT30.08s killed by signal 15 SIGTERM 15/15 seq_writerTIMEOUT30.05s killed by signal 15 SIGTERM Ok: 8 Expected Fail: 0 Fail: 0 Unexpected Pass:0 Skipped:0 Timeout:7 dh_auto_test: error: cd obj-arm-linux-gnueabihf && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 meson test returned exit code 7 make[1]: *** [debian/rules:12: override_dh_auto_test] Error 25 make[1]: Leaving directory '/<>' make: *** [debian/rules:8: binary] Error 2
Bug#1049872: FTBFS on multiple release architectures
Source: asmjit
Version: 0.0~git20230427.3577608-1
Severity: serious
Tags: sid trixie ftbfs
Hi,
asmjit does not build correctly on the following architectures:
armel, armhf, mips64el, mipsel, s390x.
On armel, armhf, and s390x the error is tests-related:
[...]
1: Success:
1: All tests passed!
6/6 Test #1: asmjit_test_unit . Passed 57.81 sec
83% tests passed, 1 tests failed out of 6
Total Test time (real) = 57.82 sec
The following tests FAILED:
6 - asmjit_test_compiler (SEGFAULT)
Errors while running CTest
make[1]: *** [Makefile:74: test] Error 8
make[1]: Leaving directory '/<>/obj-arm-linux-gnueabi'
dh_auto_test: error: cd obj-arm-linux-gnueabi && make -j4 test
ARGS\+=--verbose ARGS\+=-j4 returned exit code 2
make: *** [debian/rules:7: binary-arch] Error 25
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit
status 2
On mips64el and mipsel the failure looks different:
[...]
[ 91%] Building CXX object
CMakeFiles/asmjit_test_perf.dir/test/asmjit_test_perf_a64.cpp.o
/usr/bin/c++ -I"/<>/src" -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fvisibility=hidden
-Wall -Wextra -Wconversion -fno-math-errno -fno-threadsafe-statics
-fno-semantic-interposition -DASMJIT_STATIC -O2 -fmerge-all-constants
-fno-enforce-eh-specs -MD -MT
CMakeFiles/asmjit_test_perf.dir/test/asmjit_test_perf_a64.cpp.o -MF
CMakeFiles/asmjit_test_perf.dir/test/asmjit_test_perf_a64.cpp.o.d -o
CMakeFiles/asmjit_test_perf.dir/test/asmjit_test_perf_a64.cpp.o -c
"/<>/test/asmjit_test_perf_a64.cpp"
/<>/test/asmjit_test_perf.h:56:22: error: expected unqualified-id
before numeric constant
56 | static inline double mips(double duration, uint64_t instCount)
noexcept {
| ^~~~
In file included from /<>/test/asmjit_test_perf_a64.cpp:15:
/<>/test/asmjit_test_perf.h: In function ‘void
asmjit_perf_utils::bench(asmjit::_abi_1_10::CodeHolder&,
asmjit::_abi_1_10::Arch, uint32_t, const char*, uint32_t, const FuncT&)’:
/<>/test/asmjit_test_perf.h:105:34: error: expression cannot be
used as a function
105 | printf(", %8.3f [MI/s]", mips(duration, instCount));
| ^
make[3]: *** [CMakeFiles/asmjit_test_perf.dir/build.make:93:
CMakeFiles/asmjit_test_perf.dir/test/asmjit_test_perf_a64.cpp.o] Error 1
make[3]: Leaving directory '/<>/obj-mips64el-linux-gnuabi64'
make[2]: *** [CMakeFiles/Makefile2:178: CMakeFiles/asmjit_test_perf.dir/all]
Error 2
Bug#1049884: birdtray: FTBFS on armhf, armel, mipsel due to thunderbird build-dep
Source: birdtray Version: 1.9.0+ds-2 Severity: serious Justification: FTBFS Tags: trixie sid ftbfs Hi, birdtray is 'Architecture: any' and build-depends on thunderbird. However, armhf, armel, and mipsel are not in thunderbird's architecture list. For this reason birdtray cannot be build on those architectures: The following packages have unmet dependencies: sbuild-build-depends-main-dummy : Depends: thunderbird (>= 1:60) but it is not installable
Bug#1049869: FTBFS with GCC-13 on arm64 and armhf
Package: src:arm-compute-library Version: 20.08+dfsg-7 Severity: serious Tags: sid trixie User: debian-...@lists.debian.org Usertags: ftbfs-gcc-13 With GCC-13, arm-compute-library fails to build from source on both arm64 and armhf with the following errors: ./arm_compute/core/utils/misc/Utility.h: In function ‘bool arm_compute::utility::check_aligned(void*, size_t)’: ./arm_compute/core/utils/misc/Utility.h:194:35: error: ‘uintptr_t’ in namespace ‘std’ does not name a type 194 | return (reinterpret_cast(ptr) % alignment) == 0; | ^ ./arm_compute/core/utils/misc/Utility.h:32:1: note: ‘std::uintptr_t’ is defined in header ‘’; did you forget to ‘#include ’? 31 | #include +++ |+#include 32 | In file included from ./arm_compute/core/TensorShape.h:29, from ./arm_compute/core/IAccessWindow.h:28, from ./arm_compute/core/AccessWindowTranspose.h:28, from src/core/AccessWindowTranspose.cpp:24: ./arm_compute/core/utils/misc/Utility.h: In function ‘bool arm_compute::utility::check_aligned(void*, size_t)’: ./arm_compute/core/utils/misc/Utility.h:194:35: error: ‘uintptr_t’ in namespace ‘std’ does not name a type 194 | return (reinterpret_cast(ptr) % alignment) == 0; | ^ ./arm_compute/core/utils/misc/Utility.h:32:1: note: ‘std::uintptr_t’ is defined in header ‘’; did you forget to ‘#include ’? 31 | #include +++ |+#include 32 | ./arm_compute/core/TensorShape.h: At global scope: ./arm_compute/core/TensorShape.h:39:39: error: ‘uint32_t’ was not declared in this scope 39 | class TensorShape : public Dimensions | ^~~~ ./arm_compute/core/TensorShape.h:30:1: note: ‘uint32_t’ is defined in header ‘’; did you forget to ‘#include ’? 29 | #include "arm_compute/core/utils/misc/Utility.h" +++ |+#include 30 | ./arm_compute/core/TensorShape.h:39:47: error: template argument 1 is invalid 39 | class TensorShape : public Dimensions | ^ [...]
Bug#1049958: coccinelle: FTBFS on armhf - Fatal error: out of memory
Source: coccinelle Version: 1.1.1.deb-3 Severity: serious Tags: sid ftbfs User: debian-...@lists.debian.org Usertags: armhf Hi, coccinelle fails to build from source on armhf with a "out of memory" error. (1) The error seems to be a red herring given that the machine on which I'm building the package has 32G of memory, of which only about 4G are in use when the build fails. (2) On armel the package builds correctly. OCAMLOPT engine/ctlcocci_integration.ml OCAMLOPT -o engine/engine.cmxa Fatal error: out of memory Aborted make[1]: *** [Makefile:423: parsing_cocci/parser_cocci_menhir.cmx] Error 134 make[1]: Leaving directory '/<>' dh_auto_build: error: make -j8 returned exit code 2 make: *** [debian/rules:24: binary-arch] Error 25
Bug#1050031: coinor-bonmin: FTBFS with /usr/bin/ld: cannot find -lgfortran
Source: coinor-bonmin Version: 1.8.9-1 Severity: serious Tags: sid trixie ftbfs Hi, coinor-bonmin fails to build with the following error: g++ -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/13/crtbeginS.o .libs/BonCbc.o .libs/BonCbcNlpStrategy.o .libs/BonCbcNode.o .libs/BonBabInfos.o .libs/BonGuessHeuristic.o .libs/BonDiver.o -Wl,--whole-archive ../Algorithms/.libs/libbonalgorithms.a ../Interfaces/.libs/libbonmininterfaces.a Heuristics/.libs/libbonheuristics.a -Wl,--no-whole-archive -lCbcSolver -lCbc -lpthread -lrt -lCgl -lOsiClp -lClpSolver -lClp -lOsi -lCoinUtils -lbz2 -lz -lipopt -L/usr/lib/gcc/x86_64-linux-gnu/13 -L/usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/13/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/13/../../.. -llapack -ldmumps_seq -lgfortran -lquadmath -lblas -ldl -L/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/13/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/crtn.o -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-soname -Wl,libbonmin.so.4 -o .libs/libbonmin.so.4.8.9 /usr/bin/ld: cannot find -lgfortran: No such file or directory collect2: error: ld returned 1 exit status make[4]: *** [Makefile:503: libbonmin.la] Error 1 Version 1.8.9-1 of the package did build properly in the past [1]. One potentially significant difference is that the successful build was with GCC-12, while the failure occurrs with GCC-13. [1] https://buildd.debian.org/status/fetch.php?pkg=coinor-bonmin=amd64=1.8.9-1%2Bb1=1690533628=0
Bug#1037579: still ftbfs on arm64 and armhf
Hi Matthias, On 2023-08-18 06:46, Matthias Klose wrote: > still ftbfs on arm64 and armhf. would it be possible to pay attention to > build failures after uploads, or even better to pay attention until the > package migrates? See https://bugs.debian.org/1037579#43 We are currently packaging the last upstream of both arm-compute-library and armnn, they should build fine with GCC-13.
Bug#1050019: cctz: FTBFS due to time_zone_lookup_test failure
Source: cctz Version: 2.3+dfsg1-3 Severity: serious Tags: sid trixie ftbfs Hi, cctz fails to build with the following error message: 75% tests passed, 1 tests failed out of 4 Total Test time (real) = 30.25 sec The following tests FAILED: 2 - time_zone_lookup_test (Failed) Errors while running CTest make[1]: *** [Makefile:74: test] Error 8 make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu' dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j16 test ARGS\+=--verbose ARGS\+=-j16 returned exit code 2 make: *** [debian/rules:7: build] Error 25
Bug#1049876: [Debian-med-packaging] Bug#1050491: RM: bbhash [armel armhf i386 mipsel powerpc Buildd exposure stats hurd-i386 hppa sh4] -- ROM; Does not build on 32bit architectures
Hi, On 2023-08-25 09:46, Graham Inggs wrote: > On Fri, 25 Aug 2023 at 09:03, Andreas Tille wrote: > > upstream does not support 32bit and the usage of this package on 32bit is > > questionable anyway so please remove all 32bit builds of this package. > > Andreas, what 32-bit builds? bbhash has never built on 32-bit architectures. > > Emanuele, since when is this RC? My apologies! For some reason I was convinced bbhash and btllib did build in the past. In both cases it seems to make sense to limit the Architecture field to the supported ones, given that as far as I understand both packages and are not portable? See: https://www.debian.org/doc/debian-policy/ch-controlfields.html#architecture
Bug#1049886: btllib: FTBFS on armhf due to tests timing out
Hallo Andreas, On Fri, Aug 25, 2023 at 11:28:16AM +0200, Andreas Tille wrote: > Am Wed, Aug 16, 2023 at 03:43:24PM +0200 schrieb Emanuele Rocca: > > btllib currently fails to build from source on armhf with the following > > tests-related error: > > Armhf (as well as all other 32bit archs) are not part of the supportet > architectures. since the latest upload > > btllib (1.4.10+dfsg-1) unstable; urgency=medium [...] > So I'm wondering why this bug came up at all and closing it hereby. Ah yes, the reason why it came up is that btllib-tools is still Architecture: any. The buildds are attempting to build the package, and it fails. See for example 1.4.10+dfsg-1 on i386: https://buildd.debian.org/status/fetch.php?pkg=btllib=i386=1.4.10%2Bdfsg-1=1685883214=0 Emanuele
Bug#1053457: More info needed, cannot reproduce
Hi Roland! On 2023-11-08 06:50, Roland Clobus wrote: > I've run the commands that you have provided, and am unable to reproduce > your case. > > lb config --distribution sid --updates false --archive-areas 'main > non-free-firmware' --bootloaders grub-efi > echo live-task-lxde > config/package-lists/desktop.list.chroot > lb build --debug > > My last line in the output is: > P: Build completed successfully > > I'm running (lb --version) 20230502 on sid, all commands have run as root. Yeah 20230502 is the version I'm using too. I can reproduce on all systems I have available, including my amd64 workstation and my arm64 Macbook M1. However, the issue is *not* reproducible on a VM created with debvm-create. One of the differences seem to be efivars support. Are you by any chance running the commands in a VM or more in general on a system without efivars? What's the output of the following? sudo dmesg | grep efivars: I can reproduce on systems where the output looks like: [0.035071] efivars: Registered efivars operations Whereas on the VM (issue NOT reproducible) the command does not give any output. Emanuele
Bug#1055711: gcc-13: Please build gcc with -mbranch-protection=standard to fix PAC/BTI support on arm64
Package: gcc-13
Version: 13.2.0-6
Severity: normal
Dear Maintainer,
On arm64 dpkg-dev adds -mbranch-protection=standard to the default build
flags since version 1.22.0. However, the flag is not used in Debian and
Ubuntu when building GCC. This means that the feature does not work as
intended when building programs. A simple test case to check for
functioning gcc support is:
printf '#include \n\nint main() {}' > /tmp/test.c
gcc -mbranch-protection=standard -z force-bti /tmp/test.c
On systems where PAC/BTI support in GCC is working as intended, the
following output is produced:
[root@eniac ~]# gcc -mbranch-protection=standard -z force-bti /tmp/test.c
[root@eniac ~]# readelf -n a.out 2>/dev/null | grep Properties
Properties: AArch64 feature: BTI, PAC
[root@eniac ~]# gcc --version | head -1
gcc (GCC) 13.2.1 20231011 (Red Hat 13.2.1-4)
In Sid the following happens instead:
(sid-arm64)root@eniac:~# gcc -mbranch-protection=standard -z force-bti
/tmp/test.c
/usr/bin/ld:
/usr/lib/gcc/aarch64-linux-gnu/13/../../../aarch64-linux-gnu/Scrt1.o: warning:
BTI turned on by -z force-bti when all inputs do not have BTI in NOTE section.
/usr/bin/ld:
/usr/lib/gcc/aarch64-linux-gnu/13/../../../aarch64-linux-gnu/crti.o: warning:
BTI turned on by -z force-bti when all inputs do not have BTI in NOTE section.
/usr/bin/ld: /usr/lib/gcc/aarch64-linux-gnu/13/crtbeginS.o: warning: BTI
turned on by -z force-bti when all inputs do not have BTI in NOTE section.
/usr/bin/ld: /usr/lib/gcc/aarch64-linux-gnu/13/crtendS.o: warning: BTI turned
on by -z force-bti when all inputs do not have BTI in NOTE section.
/usr/bin/ld:
/usr/lib/gcc/aarch64-linux-gnu/13/../../../aarch64-linux-gnu/crtn.o: warning:
BTI turned on by -z force-bti when all inputs do not have BTI in NOTE section.
(sid-arm64)root@eniac:~# readelf -n a.out 2>/dev/null | grep Properties
Properties: AArch64 feature: BTI
(sid-arm64)root@eniac:~# gcc --version | head -1
gcc (Debian 13.2.0-6) 13.2.0
It seems that Ubuntu Mantic is affected as well:
(ubuntu-arm64)root@eniac:/home/ema# gcc -mbranch-protection=standard -z
force-bti /tmp/test.c
/usr/bin/ld:
/usr/lib/gcc/aarch64-linux-gnu/13/../../../aarch64-linux-gnu/Scrt1.o: warning:
BTI turned on by -z force-bti when all inputs do not have BTI in NOTE section.
[...]
(ubuntu-arm64)root@eniac:/home/ema# gcc --version | head -1
gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0
On Debian amd64, GCC is built with the -fcf-protection flag on:
x86_64-linux-gnu-gcc-12 -c -DHAVE_CONFIG_H -g -I.
-I../../src/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE -fcf-protection
-fpic ../../src/libiberty/dyn-string.c -o pic/dyn-string.o; \
Analogously, on arm64 it should be built with -mbranch-protection=standard.
Thanks,
Emanuele
Bug#1009200: pytorch: (autopkgtest) needs update for python3.10: 'float' object cannot be interpreted as an integer
Hi, On 08/04 09:36, Paul Gevers wrote: > We are in the transition of making python3.10 the default Python versions > [0]. With a recent upload of python3-defaults the autopkgtest of pytorch > fails in testing when that autopkgtest is run with the binary packages of > python3-defaults from unstable. It passes when run with only packages from > testing. There's an upstream issue tracking the ongoing work to add Python 3.10 support to pytorch: https://github.com/pytorch/pytorch/issues/66424 The following pull request linked in the issue in particular seems relevant for this bug: https://github.com/pytorch/pytorch/pull/74007 This one may be needed too: https://github.com/pytorch/pytorch/pull/74013
Bug#1018279: python3-testpath: Empty binary package
On 28/08 10:04, Gordon Ball wrote: > Package: python3-testpath > Version: 0.6.0+dfsg-2 > The package is empty except for the changelog. Proposed fix here: https://salsa.debian.org/python-team/packages/testpath/-/merge_requests/1
Bug#1017051: tinyarray: FTBFS on i386
On 12/08 02:36, Graham Inggs wrote: > Source: tinyarray > Version: 1.2.3-4 > Severity: serious > Tags: ftbfs > User: debian-pyt...@lists.debian.org > Usertags: python3.10 > > Hi Maintainer > > Your package FTBFS on i386 during the recent rebuilds for Python 3.10 I've enabled CI/CD on Salsa and the issue is reproduced by the i386 job. See https://salsa.debian.org/python-team/packages/tinyarray/-/pipelines/417235
Bug#1011951: python-gevent: Build-Depends: libpython3.9-testsuite
tag 1011951 pending thanks Fixed in git: https://salsa.debian.org/python-team/packages/python-gevent/-/blob/9fc8b389269f5d6415ef1019e81e2a458667829b/debian/changelog
Bug#1019321: budgie-extras: FTBFS: E275 missing whitespace after keyword
Source: budgie-extras Version: 1.4.90-2 Severity: serious Justification: FTBFS Tags: sid ftbfs patch Hi, budgie-extras fails to build due to a pep8 error with pycodestyle 2.9.1-1 (currently in sid). The attached patch fixes the issue. See the relevant part of the build logs: ./tools/run-pep8 = pycodestyle = checking ./budgie-dropby/copy_flash checking ./budgie-dropby/checkonwin checking ./budgie-dropby/dropby_tools.py ./budgie-dropby/dropby_tools.py:133:11: E275 missing whitespace after keyword make[1]: *** [debian/rules:13: override_dh_auto_test] Error 1 make[1]: Leaving directory '/tmp/autopkgtest.MWCN9F/build.gEw/real-tree' make: *** [debian/rules:6: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Fix pep8 error: E275 missing whitespace after keyword Index: budgie-extras-1.4.90/budgie-dropby/dropby_tools.py === --- budgie-extras-1.4.90.orig/budgie-dropby/dropby_tools.py +++ budgie-extras-1.4.90/budgie-dropby/dropby_tools.py @@ -130,4 +130,4 @@ def get_volumes(allvols): devdata["free"] = free devdata["volume_path"] = fpath relevant.append(devdata) -return(relevant) +return (relevant)
Bug#1019323: ros-rosdep: FTBFS E275 missing whitespace after keyword
Source: ros-rosdep Version: 0.22.1-1 Severity: serious Justification: FTBFS Tags: sid ftbfs Hi, ros-rosdep fails to build with the flake8 version currently in sid. The relevant part of a failed build follows: 1 E275 missing whitespace after keyword - Captured stderr call - /build/ros-rosdep-0.22.1/.pybuild/cpython3_3.10/build/test/test_rosdep_source.py:191:15: E275 missing whitespace after keyword assert not(commands) ^ flake8 reported 1 errors
Bug#1019352: python-pytest-flake8: FTBFS with flake8 5.0.4
Source: python-pytest-flake8 Version: 1.0.6-4 Severity: serious The package fails to build with the flake8 version currently in sid, namely 5.0.4-1. Multiple tests fail, partial output follows: [...] copying pytest_flake8.py -> /build/python-pytest-flake8-1.0.6/.pybuild/cpython3_3.10_python-pytest-flake8/build dh_auto_test -O--buildsystem=pybuild I: pybuild base:240: cd /build/python-pytest-flake8-1.0.6/.pybuild/cpython3_3.10_python-pytest-flake8/build; pyt hon3.10 -m pytest = test session starts == platform linux -- Python 3.10.6, pytest-7.1.2, pluggy-1.0.0+repack rootdir: /build/python-pytest-flake8-1.0.6, configfile: tox.ini plugins: flake8-1.0.6 collected 14 items pytest_flake8.py F [ 7%] test_flake8.py F...FF.xF [100%] LURES === _ FLAKE8-check _ pytest_flake8.py:122: in runtest found_errors = check_file( pytest_flake8.py:201: in check_file config_finder = config.ConfigFileFinder( E AttributeError: module 'flake8.options.config' has no attribute 'ConfigFileFinder' _ FLAKE8-check _ /usr/lib/python3/dist-packages/pluggy/_hooks.py:265: in __call__ return self._hookexec(self.name, self.get_hookimpls(), kwargs, firstresult) /usr/lib/python3/dist-packages/pluggy/_manager.py:80: in _hookexec [...] The autopkgtests also fail, see full output at: https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-pytest-flake8/25797652/log.gz
Bug#1019345: flake8-class-newline: autopkgtest failure
Source: flake8-class-newline Version: 1.6.0-2 Severity: serious Hi, the test fails with the latest flake8 version in sid (5.0.4-1). The output of flake8 --version with -class-newline installed is now: $ flake8 --version 5.0.4 (flake8-class-newline: 1.6.0, mccabe: 0.6.1, pycodestyle: 2.9.1, pyflakes: 2.5.0) CPython 3.10.6 on Linux While the autopkgtest expects it to include the string "new_line_checker". https://ci.debian.net/data/autopkgtest/testing/amd64/f/flake8-class-newline/25797651/log.gz [...] Processing triggers for libc-bin (2.34-7) ... (Reading database ... 14305 files and directories currently installed.) Removing autopkgtest-satdep (0) ... autopkgtest [20:13:42]: test install: [--- autopkgtest [20:13:43]: test install: ---] autopkgtest [20:13:43]: test install: - - - - - - - - - - results - - - - - - - - - - install FAIL non-zero exit status 1 autopkgtest [20:13:43]: summary install FAIL non-zero exit status 1
Bug#770175: uhub: diff for NMU version 0.4.1-3.2
Control: tags 770175 + pending Dear maintainer, I've prepared an NMU for uhub (versioned as 0.4.1-3.2) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. Regards, Emanuele diff -Nru uhub-0.4.1/debian/changelog uhub-0.4.1/debian/changelog --- uhub-0.4.1/debian/changelog 2016-12-23 05:27:45.0 +0100 +++ uhub-0.4.1/debian/changelog 2022-09-12 11:14:29.0 +0200 @@ -1,3 +1,10 @@ +uhub (0.4.1-3.2) unstable; urgency=medium + + * Non-maintainer upload. + * Add arm64-fix-ftbfs.patch to fix FTBFS on arm64. (Closes: #770175) + + -- Emanuele Rocca Mon, 12 Sep 2022 11:14:29 +0200 + uhub (0.4.1-3.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru uhub-0.4.1/debian/patches/arm64-fix-ftbfs.patch uhub-0.4.1/debian/patches/arm64-fix-ftbfs.patch --- uhub-0.4.1/debian/patches/arm64-fix-ftbfs.patch 1970-01-01 01:00:00.0 +0100 +++ uhub-0.4.1/debian/patches/arm64-fix-ftbfs.patch 2022-09-12 11:10:29.0 +0200 @@ -0,0 +1,19 @@ +Description: Fix build on arm64 +Author: Emanuele Rocca +Last-Update: 2022-09-12 + +Index: uhub-0.4.1/src/system.h +=== +--- uhub-0.4.1.orig/src/system.h uhub-0.4.1/src/system.h +@@ -202,6 +202,10 @@ + #define CPUINFO "ARM" + #endif + ++#if defined(__aarch64__) ++#define CPUINFO "AArch64" ++#endif ++ + #if defined(__i386__) || defined(__i386) || defined(i386) || defined(_M_IX86) || defined(__X86__) || defined(_X86_) || defined(__I86__) || defined(__INTEL__) || defined(__THW_INTEL__) + #define CPUINFO "i386" + #endif diff -Nru uhub-0.4.1/debian/patches/series uhub-0.4.1/debian/patches/series --- uhub-0.4.1/debian/patches/series 2016-12-23 05:27:45.0 +0100 +++ uhub-0.4.1/debian/patches/series 2022-09-12 11:10:42.0 +0200 @@ -1,2 +1,3 @@ fix-build-on-hurd-i386 openssl1.1.patch +arm64-fix-ftbfs.patch
Bug#727343: reuse this issue for the more general solution to use dh-autoreconf
Hello, On 15/03 04:39, James Cowgill wrote: > While doing the NMU for #821970 I had a look at adding dh-autoreconf > support. It's made a bit more complex by configure.ac not being at the > root of the source package. Unfortunately the nice way of adding this > requires debhelper compat 10 and I didn't want to make a major change > like that in an NMU without asking first. Debhelper compatibility is 13 since chise-base 0.3.0-2.2, so this shouldn't be a problem anymore. > So I am asking if it's OK for me to update the packaging a bit to use > debhelper compat 10 and dh which should make it easy to fix this bug. Go ahead if you still feel like! Otherwise I may look into doing the work in the next days. FTR: the package now builds fine as-is on both arm64 and ppc64el.
Bug#1019741: flask-limiter: build with sphinx inline_tabs
Source: flask-limiter Version: 2.6.2-1 Severity: wishlist Flask-limiter 2.6.2 uses the inline_tabs sphinx extension. As the extension is not in Debian yet, I've added a patch to flask-limiter to build without it, debian/patches/no_inline_tabs.patch. Once sphinx-inline-tabs will be in the archive, the patch should be dropped and the extension added as a build dependency. The sphinx-inline-tabs WNPP bug is https://bugs.debian.org/992745
Bug#1019747: flask-limiter: build with sphinx enum_tools
Source: flask-limiter Version: 2.6.2-1 Severity: wishlist Flask-limiter 2.6.2 uses the enum_tools sphinx extension. As the extension is not in Debian yet, I've added a patch to flask-limiter to build without it, debian/patches/no_enum_tools.patch. Once sphinx-enum-tools will be in the archive, the patch should be dropped and the extension added as a build dependency. The sphinx-enum-tools WNPP bug is https://bugs.debian.org/1019745
Bug#1019745: RFP: sphinx-enum-tools -- expand Python's enum module in Sphinx documentation
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-pyt...@lists.debian.org * Package name: sphinx-enum-tools Version : 0.9.0 Upstream Author : Dominic Davis-Foster * URL : https://github.com/domdfcoding/enum_tools * License : LGPL-3 Programming Lang: Python Description : expand Python's enum module in Sphinx documentation The enum_tools Sphinx extension can be used to document Enums better than autoclass can currently. Additionally, this library includes a decorator to add docstrings to Enum members from a comment at the end of the line. --- The package is being requested since the latest flask-limiter version uses the enum_tools extension for its documentation.
Bug#1019869: systemtap of debian testing not work with the default testing kernel 5.19
Hi, On 15/09 02:35, Z Y wrote: > During testing systemtap 4.7 with kernel 5.19, I found it can't resolve > some global variables of nginx. > However systemtap 4.7 can resolve them if test with kernel 5.10. Which variables exactly? Can you share a sample script reproducing the issue? Thanks for the bug report! Emanuele
Bug#1019925: backblaze-b2: new upstream 3.5.0 available
Source: backblaze-b2 Severity: wishlist A new upstream version of backblaze-b2 is available: https://github.com/Backblaze/B2_Command_Line_Tool/archive/refs/tags/v3.5.0.tar.gz The new version depends on phx-class-registry, which is currently not packaged in Debian. See https://github.com/todofixthis/class-registry
Bug#1019928: ITP: python-phx-class-registry -- module to define global factories and service registries
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-pyt...@lists.debian.org * Package name: python-phx-class-registry Version : 3.0.5 Upstream Author : Phoenix Zerin * URL : https://github.com/todofixthis/class-registry * License : MIT Programming Lang: Python Description : module to define global factories and service registries At the intersection of the Registry and Factory patterns lies the ClassRegistry. . This module allows to: . * Define global factories that generate new class instances based on configurable keys. * Seamlessly create powerful service registries. * Integrate with setuptools's entry_points system to make registries extensible by 3rd-party libraries. --- The module is a dependency of backblaze-b2 since 3.5.0: https://bugs.debian.org/1019925
Bug#1019869: systemtap of debian testing not work with the default testing kernel 5.19
Hello Yibin and Frank, On 19/09 05:03, Z Y wrote: > The global variable is ngx_cycle in openresty/nginx, openresty is actually > nginx with a lua extension. > The steps to reproduce this bug is as follows, the scripts used are > attached: > > > wget https://openresty.org/download/openresty-1.19.3.2.tar.gz > > tar -xf openresty-1.19.3.2.tar.gz > > cd openresty-1.19.3.2 > > ./configure --with-cc-opt="-O0 -g" > > make -j12 > > make install > > /usr/local/openresty/bin/resty -j off nest-call.lua 1000 & > > stap --disable-cache ./openresty.stp -x $(pgrep -n nginx) -v [...] I can reproduce the regression. The openresty.stp script provided by Yibin works fine with Linux 5.10 from Debian Bullseye, while it fails with the 5.19 kernel from testing/sid. In both cases I've used systemtap 4.7-1 from testing/sid. Here's the output with the Bullseye kernel: $ uname -a Linux ariel 5.10.0-18-amd64 #1 SMP Debian 5.10.140-1 (2022-09-02) x86_64 GNU/Linux $ sudo stap --disable-cache ~/Downloads/openresty.stp -x $(pgrep -n nginx) WARNING: Kernel function symbol table missing [man warning::symbols] WARNING: nginx pid 3224 target 3224 WARNING: ngx_cycle 0x55caf7ef1b60 WARNING: module_index 54 WARNING: lmcf 0x55caf7f048b8 WARNING: ngx lua 0x7fcfe451b380 And the failure with with the 5.19 kernel from testing/sid: $ uname -a Linux ariel 5.19.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.19.6-1 (2022-09-01) x86_64 GNU/Linux $ sudo stap --disable-cache ~/Downloads/openresty.stp -x $(pgrep -n nginx) WARNING: Kernel function symbol table missing [man warning::symbols] warning: the compiler differs from the one used to build the kernel The kernel was built by: gcc-11 (Debian 11.3.0-5) 11.3.0 You are using: gcc-11 (Debian 11.3.0-6) 11.3.0 WARNING: nginx pid 5978 target 5978 ERROR: read fault [man error::fault] at 0x5602ca215380 near operator '@var' at /home/ema/Downloads/openresty.stp:18:17 WARNING: Number of errors: 1, skipped probes: 0 WARNING: /usr/bin/staprun exited with status: 1 Pass 5: run failed. [man error::pass5] Tip: /usr/share/doc/systemtap/README.Debian should help you get started. I've tried booting the 5.19 kernel with all possible values for preempt=, namely "none", "voluntary", and "full" to no avail. The 5.19 kernel has this to say when the script fails: [ 60.484129] kprobes: kprobe jump-optimization is disabled. All kprobes are based on software breakpoint. [ 60.548807] stap_3811 (openresty.stp): systemtap: 4.7/0.187, base: c1153000, memory: 388data/52text/129ctx/262246net/324alloc kb, probes: 2
Bug#1003002: autopkgtest-virt-qemu: Console setup issue on armhf
On 2022-01-12 10:58, Christian Kastner wrote: > On 2022-01-12 20:14, Christian Kastner wrote: > > Addendum: I'm now occasionally also seeing this with arm64 when using > > sbuild with --chroot-mode=autopkgtest. I'd say it's 50/50 between > > success and failure. > > Yet another data point: by reducing the CPU count to 1, it seems that > the success rate climbs to 100% on arm64. I also encountered this with an arm64 qemu image, and the count of CPUs seems indeed to be the key difference between success and failure. On my system, the following works fine: $ autopkgtest -- qemu --cpus=1 --qemu-architecture=aarch64 /var/tmp/autopkgtest-unstable-arm64.img Any value of --cpus greater than 1 fails consistently as follows. $ autopkgtest -- qemu --cpus=2 --qemu-architecture=aarch64 /var/tmp/autopkgtest-unstable-arm64.img autopkgtest [16:53:30]: starting date: 2022-10-13 autopkgtest [16:53:30]: version 5.26 autopkgtest [16:53:30]: host ariel; command line: /usr/bin/autopkgtest -- qemu --cpus=2 --qemu-architecture=aarch64 /var/tmp/autopkgtest-unstable-arm64.img qemu-system-aarch64: -drive if=pflash,format=raw,unit=0,read-only,file=/usr/share/AAVMF/AAVMF_CODE.fd: warning: short-form boolean option 'read-only' deprecated Please use read-only=on instead qemu-system-aarch64: terminating on signal 15 from pid 86611 (/usr/bin/python3) : failure: The VM does not start a root shell on ttyS1 or hvc1 already. The only other supported login mechanism is through --user and --password on the guest ttyS0 autopkgtest [16:54:04]: ERROR: testbed failure: unexpected eof from the testbed
Bug#1003002: some more information
On 2022-03-09 11:23, Maximilian Engelhardt wrote:
> What I noticed after booting the autopkgtest image is the following:
>
> ttyAMA0 inside the vm is ttyS0 outside
> hvc0 inside the vm is hvc1 outside
> hcv1 inside the vm is hvc2 outside
> hvc0 outside the vm doesn't seem to do anything
>
> So that's the problem, the hvc console numbers are all shifted by one. If you
> leave out hvc2 in the qemu command line (to get the same as done by
> autopkgtest), then hcv1 inside the vm does not exist: "No such device".
Based on this observation from Maximilian I've tried the following, which seems
to address the issue on arm64. Patch is also attached.
diff --git a/lib/autopkgtest_qemu.py b/lib/autopkgtest_qemu.py
index f958e0f..0cf307d 100644
--- a/lib/autopkgtest_qemu.py
+++ b/lib/autopkgtest_qemu.py
@@ -206,7 +206,7 @@ class Qemu:
subdirectory of $TMPDIR)
"""
-self.consoles = set(['hvc0', 'hvc1'])
+self.consoles = set(['hvc0', 'hvc1', 'hvc2'])
self.cpus = cpus
self.images = []# type: List[QemuImage]
self.overlay_dir = overlay_dir
@@ -359,7 +359,7 @@ class Qemu:
) % self.shareddir,
])
-for hvc in ('hvc0', 'hvc1'):
+for hvc in self.consoles:
if hvc == 'hvc0' and self.qemu_architecture == 'ppc64le':
# The first -serial argument shows up as /dev/hvc0 in
# the VM on ppc64le, so identify it as such
diff --git a/virt/autopkgtest-virt-qemu b/virt/autopkgtest-virt-qemu
index 2b5b3fe..a92cee5 100755
--- a/virt/autopkgtest-virt-qemu
+++ b/virt/autopkgtest-virt-qemu
@@ -151,7 +151,7 @@ def setup_shell() -> str:
user = args.user
password = args.password
-for name in ('hvc1', 'ttyS1'):
+for name in ('hvc1', 'ttyS1', 'hvc2'):
# if the VM is already prepared to start a root shell on ttyS1, just
use it
if name not in qemu.consoles:
continue
Here's what the debug logs have to say. Note that the shell is found on
hvc2:
autopkgtest [17:10:10]: starting date: 2022-10-13
autopkgtest [17:10:10]: version 5.26
autopkgtest [17:10:10]: host ariel; command line: /usr/bin/autopkgtest -- qemu
-d --cpus=2 --qemu-architecture=aarch64 /var/tmp/autopkgtest-unstable-arm64.img
autopkgtest-virt-qemu: DBG: executing open
autopkgtest-virt-qemu: DBG: find_free_port: trying 10022
autopkgtest-virt-qemu: DBG: find_free_port: 10022 is free
autopkgtest-virt-qemu: DBG: qemu architecture: aarch64
[...]
autopkgtest-virt-qemu: DBG: full qemu command-line: ['qemu-system-aarch64',
'-machine', 'virt', '-cpu', 'cortex-a53', '-m', '1024', '-smp', '2',
'-nographic', '-net', 'nic,model=virtio', '-net',
'user,hostfwd=tcp:127.0.0.1:10022-:22', '-object',
'rng-random,filename=/dev/urandom,id=rng0', '-device',
'virtio-rng-pci,rng=rng0,id=rng-device0', '-monitor',
'unix:/tmp/autopkgtest-qemu.bkj2lum4/monitor,server=on,wait=off', '-virtfs',
'local,id=autopkgtest,path=/tmp/autopkgtest-qemu.bkj2lum4/shared,security_model=none,mount_tag=autopkgtest',
'-chardev',
'socket,path=/tmp/autopkgtest-qemu.bkj2lum4/hvc0,server=on,wait=off,id=hvc0',
'-device', 'virtio-serial', '-device', 'virtconsole,chardev=hvc0', '-chardev',
'socket,path=/tmp/autopkgtest-qemu.bkj2lum4/hvc2,server=on,wait=off,id=hvc2',
'-device', 'virtio-serial', '-device', 'virtconsole,chardev=hvc2', '-chardev',
'socket,path=/tmp/autopkgtest-qemu.bkj2lum4/hvc1,server=on,wait=off,id=hvc1',
'-device', 'virtio-serial', '-device', 'virtconsole,chardev=hvc1', '-serial',
'unix:/tmp/autopkgtest-qemu.bkj2lum4/ttyS0,server=on,wait=off', '-drive',
'index=0,file=/tmp/autopkgtest-qemu.bkj2lum4/overlay.img,cache=unsafe,if=virtio,discard=unmap,format=qcow2',
'-drive',
'if=pflash,format=raw,unit=0,read-only=on,file=/usr/share/AAVMF/AAVMF_CODE.fd',
'-drive',
'if=pflash,format=raw,unit=1,file=/tmp/autopkgtest-qemu.bkj2lum4/efivars.fd']
autopkgtest-virt-qemu: DBG: expect: b' login: '
autopkgtest-virt-qemu: DBG: expect: found "'login prompt on serial console'"
autopkgtest-virt-qemu: DBG: expect: b'ok'
autopkgtest-virt-qemu: DBG: expect: b'ok'
autopkgtest-virt-qemu: DBG: expect: found "b'ok'"
autopkgtest-virt-qemu: DBG: setup_shell(): there already is a shell on hvc2
diff --git a/lib/autopkgtest_qemu.py b/lib/autopkgtest_qemu.py
index f958e0f..0cf307d 100644
--- a/lib/autopkgtest_qemu.py
+++ b/lib/autopkgtest_qemu.py
@@ -206,7 +206,7 @@ class Qemu:
subdirectory of $TMPDIR)
"""
-self.consoles = set(['hvc0', 'hvc1'])
+self.consoles = set(['hvc0', 'hvc1', 'hvc2'])
self.cpus = cpus
self.images = []# type: List[QemuImage]
self.overlay_dir = overlay_dir
@@ -359,7 +359,7 @@ class Qemu:
) % self.shareddir,
])
-for hvc in ('hvc0', 'hvc1'):
+for hvc in self.consoles:
if hvc == 'hvc0' and self.qemu_architecture == 'ppc64le':
# The first -serial argument shows up as /dev/hvc0
Bug#1003002: some more information
On Thu, Oct 13, 2022 at 05:16:44PM +0200, Emanuele Rocca wrote: > Based on this observation from Maximilian I've tried the following, which > seems > to address the issue on arm64. Not reliably though. The first few times I tried it worked, but now even with hvc2 I could reproduce setup_console's failure.
Bug#1021341: autopkgtest-build-qemu: add dependency on zerofree
Package: autopkgtest Version: 5.26 Severity: normal Hi, autopkgtest-build-qemu assumes that zerofree is installed, but it does not depend on the relevant package. [...] 2022-09-23 20:26:11 INFO Calling > 2022-09-23 20:26:11 DEBUG Unmounting /tmp/tmp4a9yk5hg and everything on top of it 2022-09-23 20:26:12 DEBUG Finished unmounting /tmp/tmp4a9yk5hg 2022-09-23 20:26:12 INFO Exec: ['zerofree', '-v', '/dev/mapper/loop0p1'] 2022-09-23 20:26:12 ERROR [Errno 2] No such file or directory: 'zerofree'
Bug#727343: chise-base: diff for NMU version 0.3.0-2.3
Control: tags 727343 + patch
Control: tags 727343 + pending
Dear maintainer,
I've prepared an NMU for chise-base (versioned as 0.3.0-2.3) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.
Regards.
diff -u chise-base-0.3.0/debian/changelog chise-base-0.3.0/debian/changelog
--- chise-base-0.3.0/debian/changelog
+++ chise-base-0.3.0/debian/changelog
@@ -1,3 +1,14 @@
+chise-base (0.3.0-2.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Use dh_update_autotools_config, dh_autoreconf and dh_autoreconf_clean in
+debian/rules. Closes: #727343
+ * Do not manually copy /usr/share/misc/config.{sub,guess} over
+libchise/config.{sub,guess} in the clean target, dh_clean takes care of
+doing that.
+
+ -- Emanuele Rocca Thu, 06 Oct 2022 11:35:07 +0200
+
chise-base (0.3.0-2.2) unstable; urgency=medium
* Non-maintainer upload.
diff -u chise-base-0.3.0/debian/rules chise-base-0.3.0/debian/rules
--- chise-base-0.3.0/debian/rules
+++ chise-base-0.3.0/debian/rules
@@ -35,6 +35,9 @@
libchise/config.status: libchise/configure
dh_testdir
+ cp libchise/libtool debian/libtool.bkp
+ dh_update_autotools_config
+ dh_autoreconf
cd libchise && CFLAGS="$(CFLAGS)" ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
@@ -49,15 +52,11 @@
clean:
dh_testdir
dh_testroot
- rm -f build-stamp
+ rm -f build-stamp
cd libchise && [ ! -f Makefile ] || $(MAKE) distclean
-ifneq "$(wildcard /usr/share/misc/config.sub)" ""
- cp -f /usr/share/misc/config.sub libchise/config.sub
-endif
-ifneq "$(wildcard /usr/share/misc/config.guess)" ""
- cp -f /usr/share/misc/config.guess libchise/config.guess
-endif
+ dh_autoreconf_clean
dh_clean
+ -mv debian/libtool.bkp libchise/libtool
install: build
dh_testdir
Bug#1021780: schroot: example of file chroot missing type=file
Package: schroot Version: 1.6.13-3 Severity: minor Hi, the config file /etc/schroot/schroot.conf ships the following example of file-based chroot: #[lenny-file] #description=Debian lenny (oldstable) #file=/srv/chroot/lenny.tar.gz #location=/lenny #groups=sbuild The example does not work as is, it needs "type=file" too.
Bug#1021776: autopkgtest: warn about missing packages in autopkgtest-build-qemu
Package: autopkgtest Version: 5.26 Severity: minor The program autopkgtest-build-qemu needs a few packages to be installed in order to work properly. However, such packages are not listed as dependencies of autopkgtest given that they are qemu-specific, and qemu is only one of the backends supported by autopkgtest. Some (but not all) of the needed packages are listed as Suggests. For vmdb2, autopkgtest-build-qemu detects its absence and warns about the fact: vmdb2 not found. This script requires vmdb2 to be installed Another required package is zerofree, which is not currently listed in Suggests though it should be. See https://bugs.debian.org/1021341. Similarly to what it does for vmdb2, the script should warn if zerofree is missing too. Depending on the arguments passed to autopkgtest-build-qemu, the combination of required packages may change. For example, when building an arm64 image on a amd64 host with --architecture=arm64, the following packages are needed too: - qemu-user-static - binfmt-support - qemu-efi-aarch64 - qemu-system-arm For other architectures the list of requirements is likely a bit different. It would be great if autopkgtest-build-qemu could detect this and print a message about the missing packages instead of crashing.
Bug#1028626: ITP: parsec-service -- Abstraction layer for secure storage and operations
Package: wnpp Severity: wishlist Owner: Emanuele Rocca X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: parsec-service Version : 1.1.0 Upstream Author : Parsec Project Contributors * URL : https://github.com/parallaxsecond/parsec * License : Apache-2.0 Programming Lang: Rust Description : Abstraction layer for secure storage and operations Parsec is an abstraction layer that can be used to interact with hardware-backed security facilities such as the Hardware Security Module (HSM), the Trusted Platform Module (TPM), firmware-backed, and isolated software services. . The core component of Parsec is the security service, provided by this package. The service is a background process that runs on the host platform and provides connectivity with the secure facilities of that host, exposing a platform-neutral API that can be consumed into different programming languages using a client library. This package will be maintained under the umbrella of the Debian Rust Team.
Bug#790265: acpi: diff for NMU version 1.7-1.2
Control: tags 790265 + patch
Control: tags 790265 + pending
Dear maintainer,
I've prepared an NMU for acpi (versioned as 1.7-1.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.
Regards.
diff -u acpi-1.7/debian/changelog acpi-1.7/debian/changelog
--- acpi-1.7/debian/changelog
+++ acpi-1.7/debian/changelog
@@ -1,3 +1,10 @@
+acpi (1.7-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add arm64 architecture. (Closes: #790265)
+
+ -- Emanuele Rocca Wed, 25 Jan 2023 15:05:11 +0100
+
acpi (1.7-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -u acpi-1.7/debian/control acpi-1.7/debian/control
--- acpi-1.7/debian/control
+++ acpi-1.7/debian/control
@@ -8,7 +8,7 @@
Homepage: http://sourceforge.net/projects/acpiclient
Package: acpi
-Architecture: i386 ia64 amd64 mips mipsel mipsn32 mipsn32el mips64 mips64el x32
+Architecture: i386 ia64 amd64 mips mipsel mipsn32 mipsn32el mips64 mips64el x32 arm64
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: displays information on ACPI devices
Attempts to replicate the functionality of the 'old' apm command on
Bug#1013904: rinse: support newer fedora/opensuse and arm64
Hi,
On 2022-06-27 06:35, Benjamin Burton wrote:
> I’m using rinse for some ongoing porting efforts, and I’ve made
> some patches that I’m hoping can be incorporated upstream.
I've downloaded Benjamin's changes locally and I'm currently testing
them.
Meanwhile please find a debdiff of the work attached, which may be
easier to review.
Thanks so much for updating rinse Benjamin!
Emanuele
diff -Nru rinse-3.7/bin/rinse rinse-3.7+bab.1/bin/rinse
--- rinse-3.7/bin/rinse 2020-06-24 15:26:42.0 +0200
+++ rinse-3.7+bab.1/bin/rinse 2022-06-26 15:31:46.0 +0200
@@ -57,7 +57,7 @@
=over 8
=item B<--arch>
-Specify the architecture to install. Valid choices are 'amd64' and 'i386' only.
+Specify the architecture to install. Valid choices are 'amd64', 'i386' or 'arm64' only.
=item B<--add-pkg-list>
Add a list of additional packages.
@@ -221,7 +221,7 @@
#
# Release number.
#
-my $RELEASE = 'XXUNRELEASEDXX';
+my $RELEASE = '3.7+bab';
#
@@ -515,13 +515,16 @@
if ( $CONFIG{ 'arch' } ) {
if ( ( $CONFIG{ 'arch' } ne "i386" ) &&
( $CONFIG{ 'arch' } ne "amd64" ) &&
- ( $CONFIG{ 'arch' } ne "x86_64" ) ) {
+ ( $CONFIG{ 'arch' } ne "x86_64" ) &&
+ ( $CONFIG{ 'arch' } ne "arm64" ) &&
+ ( $CONFIG{ 'arch' } ne "aarch64" ) ) {
print <= 32 and opensuse >= 15.3
+ * make the opensuse 15.x post-install zypper commands slightly more failsafe
+
+ -- Ben Burton Sun, 26 Jun 2022 23:31:46 +1000
+
rinse (3.7) unstable; urgency=low
* add support for Rocky Linux 8, thanks to Hannes Eberhardt
diff -Nru rinse-3.7/etc/fedora-32.packages rinse-3.7+bab.1/etc/fedora-32.packages
--- rinse-3.7/etc/fedora-32.packages 1970-01-01 01:00:00.0 +0100
+++ rinse-3.7+bab.1/etc/fedora-32.packages 2022-06-26 15:31:46.0 +0200
@@ -0,0 +1,146 @@
+alternatives
+audit-libs
+basesystem
+bash
+bzip2-libs
+ca-certificates
+coreutils
+coreutils-common
+coreutils-single
+crypto-policies
+curl
+curl-minimal
+cyrus-sasl-lib
+dnf
+dnf-data
+elfutils-default-yama-scope
+elfutils-libelf
+elfutils-libs
+expat
+fedora-gpg-keys
+fedora-release
+fedora-release-cinnamon
+fedora-release-cloud
+fedora-release-common
+fedora-release-container
+fedora-release-coreos
+fedora-release-iot
+fedora-release-kde
+fedora-release-matecompiz
+fedora-release-server
+fedora-release-silverblue
+fedora-release-snappy
+fedora-release-soas
+fedora-release-workstation
+fedora-release-xfce
+fedora-repos
+file-libs
+filesystem
+gawk
+gdbm-libs
+generic-release
+generic-release-common
+glib2
+glibc
+glibc-common
+glibc-minimal-langpack
+gmp
+gnupg2
+gnutls
+gpgme
+grep
+ima-evm-utils
+json-c
+keyutils-libs
+krb5-libs
+libacl
+libarchive
+libassuan
+libattr
+libblkid
+libbrotli
+libcap
+libcap-ng
+libcom_err
+libcomps
+libcurl
+libcurl-minimal
+libdb
+libdb-utils
+libdnf
+libffi
+libgcc
+libgcrypt
+libgomp
+libgpg-error
+libidn2
+libksba
+libmetalink
+libmodulemd
+libmodulemd1
+libmount
+libnghttp2
+libnsl2
+libpsl
+librepo
+libreport-filesystem
+libselinux
+libsepol
+libsigsegv
+libsmartcols
+libsolv
+libssh
+libssh-config
+libstdc++
+libtasn1
+libtirpc
+libunistring
+libusbx
+libuuid
+libverto
+libxcrypt
+libxml2
+libyaml
+libzstd
+lua-libs
+lz4-libs
+mpfr
+ncurses
+ncurses-base
+ncurses-libs
+nettle
+npth
+openldap
+openssl
+openssl-libs
+p11-kit
+p11-kit-trust
+pcre
+pcre2
+pcre2-syntax
+popt
+publicsuffix-list-dafsa
+python3
+python3-dnf
+python3-gpg
+python3-hawkey
+python3-libcomps
+python3-libdnf
+python3-libs
+python3-rpm
+python-pip-wheel
+python-setuptools-wheel
+readline
+rpm
+rpm-build-libs
+rpm-libs
+rpm-sign-libs
+sed
+setup
+sqlite-libs
+systemd-libs
+tss2
+tzdata
+xz-libs
+zchunk-libs
+zlib
diff -Nru rinse-3.7/etc/fedora-33.packages rinse-3.7+bab.1/etc/fedora-33.packages
--- rinse-3.7/etc/fedora-33.packages 1970-01-01 01:00:00.0 +0100
+++ rinse-3.7+bab.1/etc/fedora-33.packages 2022-06-26 15:31:46.0 +0200
@@ -0,0 +1,161 @@
+alternatives
+audit-libs
+basesystem
+bash
+bzip2-libs
+ca-certificates
+coreutils
+coreutils-common
+coreutils-single
+crypto-policies
+curl
+curl-minimal
+cyrus-sasl-lib
+dnf
+dnf-data
+elfutils-default-yama-scope
+elfutils-libelf
+elfutils-libs
+expat
+fedora-gpg-keys
+fedora-release
+fedora-release-cinnamon
+fedora-release-cloud
+fedora-release-common
+fedora-release-container
+fedora-release-coreos
+fedora-release-designsuite
+fedora-release-identity-basic
+fedora-release-identity-cinnamon
+fedora-release-identity-cloud
+fedora-release-identity-container
+fedora-release-identity-coreos
+fedora-release-identity-designsuite
+fedora-release-identity-iot
+fedora-release-identity-kde
+fedora-release-identity-matecompiz
+fedora-release-identity-server
+fedora-release-identity-silverblue
+fedora-release-identity-snappy
+fedora-release-identity-soas
+fedora-release-identity-workstation
+fedora-release-identity-xfce
+fedora-release-iot
+fedora-release-kde
+fedora-release-matecompiz
+fedora-release-server
+fedora-release-silverblue
Bug#1023259: rinse: yum update fails after creating a fedora chroot
Package: rinse
Version: 3.7
Tags: patch
Hi,
commands like 'yum update -v' fail with the following error:
Cannot download
'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f28=x86_64':
Cannot prepare internal mirrorlist: Curl error (77): Problem with the SSL CA
cert (path? access rights?) for
https://mirrors.fedoraproject.org/metalink?repo=updates-released-f28=x86_64
[error setting certificate verify locations:
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none].
Error: Failed to synchronize cache for repo 'updates'
This happens right after creating a Fedora 28 chroot with:
$ sudo rinse --distribution fedora-28 --arch amd64 --directory
/var/tmp/fedora-28
The problem can be solved by running `update-ca-trust` in the chroot.
See the attached patch for a proposed fix.
diff --git a/scripts/fedora-22/post-install.sh b/scripts/fedora-22/post-install.sh
index 2d24455..dd73883 100755
--- a/scripts/fedora-22/post-install.sh
+++ b/scripts/fedora-22/post-install.sh
@@ -89,3 +89,8 @@ rm -f ${prefix}/*.rpm ${prefix}/var/cache/yum/core/packages/*.rpm
find ${prefix} -name '*.rpmorig' -delete
find ${prefix} -name '*.rpmnew' -delete
+
+#
+# 7. Call update-ca-trust to fix files under /etc/pki/ needed by yum update.
+#
+chroot ${prefix} /usr/bin/update-ca-trust
Bug#1013904: rinse: support newer fedora/opensuse and arm64
On 2022-11-01 12:50, Emanuele Rocca wrote: > I've downloaded Benjamin's changes locally and I'm currently testing > them. Just to confirm, I've successfull created amd64 chroots for all newly supported fedora/opensuse releases. Essentially: for f in 32 33 34 35 36; do sudo rinse --distribution fedora-$f --arch amd64 --directory /srv/chroots/fedora-$f ; done for s in 15.3 15.4; do sudo rinse --distribution opensuse-$s --arch amd64 --directory /srv/chroots/opensuse-$s; done Also opensuse 15.3 *arm64* works fine. Emanuele
Bug#982794: firefox-esr: illegal instruction in libxul.so on armhf
Control: tags -1 + patch
On Fri, Mar 03, 2023 at 03:13:15PM +0100, Emanuele Rocca wrote:
> Firefox seems to erroneously enable NEON in places where it shouldn't. Trying
> to figure out exactly where and what's the best way to address this.
Patch attached.
According to the large disclaimer in moz.build one should not touch that file
but instead modify generate_mozbuild.py. It seems to me however that changes to
the python script are not automatically applied to moz.build?
In any case with the attached patch firefox-esr builds properly for armhf and
works fine here emulating a cortex-r5f CPU.
Thanks,
ema
Index: firefox-esr-102.8.0esr/gfx/skia/moz.build
===
--- firefox-esr-102.8.0esr.orig/gfx/skia/moz.build
+++ firefox-esr-102.8.0esr/gfx/skia/moz.build
@@ -455,8 +455,6 @@ if CONFIG['INTEL_ARCHITECTURE']:
SOURCES['skia/src/opts/SkOpts_sse42.cpp'].flags += ['-msse4.2']
SOURCES['skia/src/opts/SkOpts_avx.cpp'].flags += ['-mavx']
SOURCES['skia/src/opts/SkOpts_hsw.cpp'].flags += ['-mavx2', '-mf16c', '-mfma']
-elif CONFIG['CPU_ARCH'] == 'arm' and CONFIG['CC_TYPE'] in ('clang', 'gcc'):
-CXXFLAGS += CONFIG['NEON_FLAGS']
elif CONFIG['CPU_ARCH'] == 'aarch64' and CONFIG['CC_TYPE'] in ('clang', 'gcc'):
SOURCES['skia/src/opts/SkOpts_crc32.cpp'].flags += ['-march=armv8-a+crc']
Bug#1032615: dstat is discontinued, let us consider dool ?
Hi Christian, On Fri, Mar 10, 2023 at 08:24:22AM +0100, Christian Ehrhardt wrote: > So I wondered if/how we should consider replacing dstat with dool in Debian? Thanks for starting the discussion. I agree that dstat in Debian could use some improvement! :-) Dool looks good, let's get it in the archive. Feel free to go ahead with ITP+upload if you have the time and add me as co-maintainer. > 1. Should we add dool independent of dstat, and once dool looks good > make dstat a transitional (and add a name alias and conflicts to dool > to take over as drop in)? I think this is the way to go. Thanks, ema
Bug#1032648: depthcharge-tools-installer: repeatedly logs about non-ChromeOS board
Package: depthcharge-tools-installer Hi, while looking at d-i logs for one of my systems I've noticed the following message repeated many times: depthcharge-tools-installer: Not installing to non-ChromeOS board. Please consider removing the logging statement from isinstallable. Thanks, ema
Bug#1032528: installation-reports: Raspberry Pi 3 Model B Plus in EFI mode - debian-bookworm-DI-alpha2-arm64-netinst.iso
Package: installation-reports Boot method: USB stick Image version: https://cdimage.debian.org/cdimage/bookworm_di_alpha2/arm64/iso-cd/debian-bookworm-DI-alpha2-arm64-netinst.iso Date: 2023-03-08 Machine: Raspberry Pi 3 Model B Plus Rev 1.3 Processor: ARM Cortex-A53 Memory: 1G Partitions: Filesystem Type 1K-blocksUsed Available Use% Mounted on udev devtmpfs395476 0395476 0% /dev tmpfs tmpfs91436 500 90936 1% /run /dev/mmcblk0p5 ext4 30196596 1749452 26887900 7% / tmpfs tmpfs 457172 0457172 0% /dev/shm tmpfs tmpfs 5120 0 5120 0% /run/lock /dev/mmcblk0p1 vfat307016 21048285968 7% /boot/efi tmpfs tmpfs91432 0 91432 0% /run/user/1000 Output of lspci -knn (or lspci -nn): n/a Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O*] Configure network: [O] Detect media: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[E] Overall install:[] Comments/Problems: I have tested the Bookworm Alpha 2 installer on a RPi 3B+ in EFI mode. To do so, I first had to add the UEFI Firmware for Raspberry Pi 3 to the SD card onto which I planned to install Debian. The firmware images are available here: https://github.com/pftf/RPi3/releases On another Linux system I created a msdos (not GPT) partition table on the SD card with fdisk: $ sudo fdisk /dev/sdf Created a new partition with 'n', specified it should be primary with 'p', assigned it number '1', First sector '2048', Last sector '+300m'. Changed the partition type with 't', specified hex code 'e' for "W95 FAT16 (LBA)", made it bootable with 'a', saved with 'w'. Then I created a FAT16 filesystem on the partition with: $ sudo mkfs.vfat -F 16 /dev/sdf1 Mounted /dev/sdf1, unzipped RPi3_UEFI_Firmware_v1.38.zip onto it. At this point, the RPi3 was able to boot regular vanilla d-i images from a USB stick. I used debian-bookworm-DI-alpha2-arm64-netinst.iso. - Both wifi and wired ethernet were found, though for some reason the wired interface did not always manage to get configured via DHCP. I tried a few times, and when wired ethernet did not work, the wifi interface did. It seemed hit-or-miss. The installer also detected that some non-free firmware was required by the brcm module, but I don't think this is the reason for the issue, which I suspect would have otherwise been always reproducible? - The raspi-firmware package did not get installed, and I think it should probably have? - To ensure that Guided partitioning would not automatically change the partition table to GPT, but leave it as msdos, I have manually created a root partition. I haven't tested whether this was actually necessary though. - Rebooting into the freshly installed system unfortunately did not work. This is because bootaa64.efi (and indeed the whole /boot/efi/EFI/boot directory) was missing. I could fix this by booting the installer again in Rescue Mode and choosing "Force GRUB installation to the EFI removable media path", which added /boot/efi/EFI/BOOT with: ema@raspi:~$ sudo ls -l /boot/efi/EFI/BOOT total 5160 -rwx-- 1 root root 856064 Mar 8 2023 BOOTAA64.EFI -rwx-- 1 root root 91520 Mar 8 2023 fbaa64.efi -rwx-- 1 root root 4322752 Mar 8 2023 grubaa64.efi - depthcharge-tools-installer was very keen in letting me know that I do not have a ChromeOS board. The message "depthcharge-tools-installer: Not installing to non-ChromeOS board." was repeated a total of 21 times. ema@raspi:~$ sudo grep -c "non-ChromeOS board" /var/log/installer/syslog 21 Mentioning that once, if at all, would probably be enough. :-) So all in all the only truly serious problem was the fact that grub had to be installed to the EFI removable media path. I briefly discussed this with Sledge on irc and he mentioned that it would be good to have a list of platforms requiring such workaround, so that we can apply it when needed. Please find the contents of /var/log/installer/ attached. installer.tar.gz Description: application/gzip
Bug#1029167: mozjs78: Fails to build on armhf and armel
Hi Jeremy and Simon! On 2023-03-15 11:50, Emanuele Rocca wrote: > Motivated by this, I've tried to build mozjs78 with GCC 11 instead of > 12, and it *did* build successfully. My proposal is thus to build > mozjs78 with GCC 11 on armhf and armel, see attached patch. I've now discovered that this very bug was reported upstream [0] and it has been already fixed in the debian/102/master branch [1]. To confirm, I've just built mozjs78 successfully on armhf with the patch applied (Remove-workaround-for-old-libstdc-problem-which-now-cause.patch) The right way to fix the problem in mozjs78 seems to be just cherry-picking 3230b3af to debian/78/master as well. Thanks, Emanuele [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1786621 [1] https://salsa.debian.org/gnome-team/mozjs/-/commit/3230b3af440e67260139572a12064cea10134779
Bug#1033046: unblock: arm-compute-library/20.08+dfsg-7
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package arm-compute-library. [ Reason ] Fix RC bug in bookworm, the package fails to build from source due to missing include directives: https://bugs.debian.org/1032041 [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock arm-compute-library/20.08+dfsg-7 Thanks, Emanuele diff -Nru arm-compute-library-20.08+dfsg/debian/changelog arm-compute-library-20.08+dfsg/debian/changelog --- arm-compute-library-20.08+dfsg/debian/changelog 2020-11-06 01:30:42.0 +0100 +++ arm-compute-library-20.08+dfsg/debian/changelog 2023-03-03 14:31:21.0 +0100 @@ -1,3 +1,17 @@ +arm-compute-library (20.08+dfsg-7) unstable; urgency=medium + + * Actually include d/patches/missing-includes.patch, all changes to d/patches +got removed by dgit. + + -- Emanuele Rocca Fri, 03 Mar 2023 14:31:21 +0100 + +arm-compute-library (20.08+dfsg-6) unstable; urgency=medium + + * Add d/patches/missing-includes.patch to fix FTBFS (Closes: #1032041) + * Add myself to Uploaders with Wookey's permission. + + -- Emanuele Rocca Fri, 03 Mar 2023 14:12:26 +0100 + arm-compute-library (20.08+dfsg-5) unstable; urgency=medium * Re-release as source-only upload diff -Nru arm-compute-library-20.08+dfsg/debian/control arm-compute-library-20.08+dfsg/debian/control --- arm-compute-library-20.08+dfsg/debian/control 2020-11-06 01:30:42.0 +0100 +++ arm-compute-library-20.08+dfsg/debian/control 2023-03-03 14:16:04.0 +0100 @@ -2,7 +2,7 @@ Section: libs Priority: optional Maintainer: Compute Library Team -Uploaders: Georgios Pinitas , +Uploaders: Georgios Pinitas , Emanuele Rocca Standards-Version: 4.5.0 Homepage: https://github.com/ARM-software/ComputeLibrary Vcs-git: https://salsa.debian.org/wookey/arm-compute-library diff -Nru arm-compute-library-20.08+dfsg/debian/patches/missing-includes.patch arm-compute-library-20.08+dfsg/debian/patches/missing-includes.patch --- arm-compute-library-20.08+dfsg/debian/patches/missing-includes.patch 1970-01-01 01:00:00.0 +0100 +++ arm-compute-library-20.08+dfsg/debian/patches/missing-includes.patch 2023-03-03 14:30:48.0 +0100 @@ -0,0 +1,136 @@ +From: Emanuele Rocca +Date: Fri, 03 Mar 2023 14:14:18 +0100 +Subject: add missing includes to fix https://bugs.debian.org/1032041 + +Index: arm-compute-library-20.08+dfsg/arm_compute/core/ITensorPack.h +=== +--- arm-compute-library-20.08+dfsg.orig/arm_compute/core/ITensorPack.h arm-compute-library-20.08+dfsg/arm_compute/core/ITensorPack.h +@@ -25,6 +25,7 @@ + #define ARM_COMPUTE_ITENSORPACK_H + + #include ++#include + #include + + namespace arm_compute +Index: arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/mergeresults.cpp +=== +--- arm-compute-library-20.08+dfsg.orig/src/core/NEON/kernels/arm_gemm/mergeresults.cpp arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/mergeresults.cpp +@@ -25,6 +25,7 @@ + /* As some of the merges need these headers, but are all included in the + * arm_gemm namespace, put these headers here. */ + #include ++#include + + #include + +Index: arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/generic.cpp +=== +--- arm-compute-library-20.08+dfsg.orig/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/generic.cpp arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/generic.cpp +@@ -24,6 +24,7 @@ + #ifdef __aarch64__ + + #include ++#include + + #include "arm_gemm.hpp" + +Index: arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/a55.cpp +=== +--- arm-compute-library-20.08+dfsg.orig/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/a55.cpp arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/a55.cpp +@@ -24,6 +24,7 @@ + #ifdef __aarch64__ + + #include ++#include + + #include "arm_gemm.hpp" + +Index: arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/x1.cpp +=== +--- arm-compute-library-20.08+dfsg.orig/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/x1.cpp arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/x1.cpp +@@ -24,6 +24,7 @@ + #ifdef __aarch64__ + + #include ++#include + + #include "arm_gemm.hpp" + +Index: arm-compute-library-20
Bug#913431: Debian Installer Bullseye RC 2 release
Hi Vincent, On 2021-06-20 10:54, Vincent Danjean wrote: > Would someone give a feedback to the (old) patch proposed > in #913431 in order to be able to also use power-of-two units > in the Debian Installer? It took a while, sorry about that. :) There is (now) a function in partman-base called valid_human [1] which checks if the partition size specified by the user is valid. Probably when you first wrote the patch this wasn't the case. That function needs to be modified as well to accept GiB and friends. [1] https://salsa.debian.org/installer-team/partman-base/-/blob/master/lib/base.sh#L373
Bug#1029167: mozjs78: Fails to build on armhf and armel
On 2023-01-27 12:03, Adrian Bunk wrote:
> WITH_SYSTEM_ICU = yes fixes this error on armel.
And on armhf too.
> The build fails later due to 146 TEST-UNEXPECTED-FAIL,
> which is not a problem for 0ad who aren't running the mozjs testsuite.
Of those 146 test failures, many seem to be discrepancies such as:
/build/mozjs78-78.15.0/js/src/tests/non262/Date/shell.js:160:21 Error:
Assertion failed: got "CEST", expected "Central European Summer Time"
/build/mozjs78-78.15.0/js/src/tests/non262/Intl/DisplayNames/dateTimeField.js:141:15
Error: Assertion failed: got "yr", expected "yr."
/build/mozjs78-78.15.0/js/src/tests/non262/Intl/NumberFormat/shell.js:42:21
Error: Assertion failed: got "US$123.00", expected "$123.00": locale=en-CA,
options={"style":"currency","currency":"USD","currencyDisplay":"narrowSymbol"},
value=123
There are a bunch of patches under debian/patches/system-ICU that seem
to deal with those differences such as [1]. Even applying those patches
though, other tests (140+) fail in a similar way.
The presence of those patches under debian/patches/system-ICU seems to
suggest that we don't really care much about the discrepancies. If
that's the case, should we just skip the tests? Any other suggestion for
how to properly move from the embedded ICU to libicu-dev?
[1]
https://sources.debian.org/src/mozjs78/78.15.0-6/debian/patches/system-ICU/tests-Adapt-formatted-strings-results-to-system-ICU.patch/
Bug#913431: Debian Installer Bullseye RC 2 release
Hi Vincent, On 2023-03-24 11:03, Vincent Danjean wrote: > However, I did not rebuild all the installer packages to generate a > new installer and test it in real conditions. I haven't had the time to test your patch yet, but there's a hack I'd like to share to test things in d-i without rebuilding anything. Create a preseed file (say preseed.cfg) with the following line: d-i partman/early_command string wget https://example.org/partman-base-vincent.sh -O /lib/partman/lib/base.sh Upload the preseed file to a webserver, say https://example.org/preseed.cfg, and your patched base.sh to https://example.org/partman-base-vincent.sh. When booting the installer, pass the following to the kernel command line: preseed/url=https://example.org/preseed.cfg Just in case you want to give it a try.
Bug#1029167: mozjs78: Fails to build on armhf and armel
Control: tags -1 + patch Hi Simon, On 2023-03-13 04:42, Simon McVittie wrote: > The other possible route for fixing mozjs78's build on armhf and armel > is to locate whatever fixes in ICU made it link successfully on armhf > and armel, and backport those to the version of ICU that is vendored by > mozjs78. I would expect this to be the easier route, and almost certainly > a smaller diff to present to the release team, with a correspondingly > smaller regression risk for mozjs78/cjs/Cinnamon. I agree that this route seems indeed easier to follow. However, I could not see any big difference between libicu-dev and the ICU version vendored in mozjs78. I suspect the difference is possibly not in the code itself but rather static vs dynamic linking. There's this old GCC regression that looks similar to the issue we have here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 Motivated by this, I've tried to build mozjs78 with GCC 11 instead of 12, and it *did* build successfully. My proposal is thus to build mozjs78 with GCC 11 on armhf and armel, see attached patch. Meanwhile I'll try to write a smaller repro for the GCC regression and investigate that separately. diff -Nru mozjs78-78.15.0/debian/changelog mozjs78-78.15.0/debian/changelog --- mozjs78-78.15.0/debian/changelog 2023-01-17 23:26:39.0 +0100 +++ mozjs78-78.15.0/debian/changelog 2023-03-15 10:36:30.0 +0100 @@ -1,3 +1,10 @@ +mozjs78 (78.15.0-6.1) unstable; urgency=medium + + * Non-maintainer upload. + * Build with GCC 11 on armhf and armel (Closes: #1029167). + + -- Emanuele Rocca Wed, 15 Mar 2023 10:36:30 +0100 + mozjs78 (78.15.0-6) unstable; urgency=medium * Add patch to fix build with Python 3.11 (Closes: #1028308) diff -Nru mozjs78-78.15.0/debian/control.in mozjs78-78.15.0/debian/control.in --- mozjs78-78.15.0/debian/control.in 2023-01-17 23:26:39.0 +0100 +++ mozjs78-78.15.0/debian/control.in 2023-03-15 10:36:30.0 +0100 @@ -10,6 +10,8 @@ autoconf, autoconf2.13, automake, + gcc-11 [armhf armel], + g++-11 [armhf armel], libreadline-dev, llvm, zlib1g-dev (>= 1:1.2.3), diff -Nru mozjs78-78.15.0/debian/rules mozjs78-78.15.0/debian/rules --- mozjs78-78.15.0/debian/rules 2023-01-17 23:26:39.0 +0100 +++ mozjs78-78.15.0/debian/rules 2023-03-15 10:36:30.0 +0100 @@ -120,6 +120,13 @@ CXX := $(DEB_HOST_GNU_TYPE)-g++ endif +# Use GCC 11 when building for armhf and armel. +# See https://bugs.debian.org/1029167 +ifneq (,$(findstring $(DEB_HOST_GNU_TYPE),arm-linux-gnueabi arm-linux-gnueabihf)) +CC := $(addsuffix -11,$(CC)) +CXX := $(addsuffix -11,$(CXX)) +endif + override_dh_auto_configure: mkdir -p $(BUILDDIR) cd $(BUILDDIR); \
Bug#1027781: qemu-user-static on arm64 host lacks registering arm (hf) support with binfmt_misc
On Fri, Jan 06, 2023 at 12:07:26PM +0100, pe...@flying-snail.de wrote: > From what I've read, support for arm32 is optional for arm64 CPU, moreover > virtualization of arm32 is not possible at least on an Apple host. > > So yes, the option to configure arm32 support at binfmt installation would > appear very useful indeed. Agreed. It's also pretty easy to find out whether a given arm64 CPU can run arm32 code natively or not. On arm64 machines capable of both modes, lscpu shows the following: $ lscpu | grep op-mode CPU op-mode(s): 32-bit, 64-bit On processors that cannot run 32 bit code, such as the Apple M1, the output is simply: $ lscpu | grep op-mode CPU op-mode(s): 64-bit
Bug#982794: firefox-esr: illegal instruction in libxul.so on armhf
Hi, On Sun, Feb 14, 2021 at 02:12:17PM +, Vincent Arkesteijn wrote: > Firefox is killed with SIGILL shortly after startup: > $ firefox-esr -safe-mode > Illegal instruction > $ This is due to the fact that some armhf CPUs do not have support for NEON instructions. skia used to detect such support at runtime, but that behavior was removed in https://github.com/google/skia/commit/809ccf37ec836d0df64afd0b13023fd968d505a4 Firefox seems to erroneously enable NEON in places where it shouldn't. Trying to figure out exactly where and what's the best way to address this. Meanwhile, to reproduce and debug this issue on a amd64 machine: apt install debootstrap qemu-user-static binfmt-support schroot Trying to run a armhf binary on the x86 host will invoke qemu-arm-static, see: /usr/sbin/update-binfmts --display qemu-arm ls -l /usr/libexec/qemu-binfmt/arm-binfmt-P Create a armhf chroot: debootstrap --arch=armhf sid /srv/sid-armhf printf '[armhf]\ntype=directory\ndirectory=/srv/sid-armhf\n' >> /etc/schroot/schroot.conf Install and run firefox-esr in the chroot: schroot -c armhf (armhf)root@ariel:/home/ema# apt install --no-install-recommends firefox-esr Firefox seems to be working: (armhf)root@ariel:/home/ema# firefox --help | head -1 Usage: firefox-esr [ options ... ] [URL] The reason why firefox does not crash here is that the default armhf CPU emulated by qemu-arm-static has NEON support. We can override that by setting QEMU_CPU to cortex-r5f (which cannot execute NEON instructions) and reproduce the issue: (armhf)root@ariel:/home/ema# QEMU_CPU=cortex-r5f firefox qemu: uncaught target signal 4 (Illegal instruction) - core dumped Illegal instruction To get a backtrace, install Firefox's debugging symbols in the chroot: (armhf)root@ariel:/home/ema# echo 'deb http://deb.debian.org/debian-debug sid-debug main' > /etc/apt/sources.list.d/debug.list (armhf)root@ariel:/home/ema# apt update && apt install firefox-esr-dbgsym And do the following on the x86 host: dpkg --add-architecture armhf apt install libc6:armhf libc6-dbg:armhf gdb-multiarch LD_LIBRARY_PATH=/srv/sid-armhf/usr/lib/arm-linux-gnueabihf qemu-arm-static -g 1234 -cpu cortex-r5f /srv/sid-armhf/usr/bin/firefox-esr --private-window In another terminal, again on the host, this should give you a backtrace: gdb-multiarch -q /srv/sid-armhf/usr/bin/firefox-esr -ex 'set architecture arm' -ex 'target remote :1234' -ex 'set debug-file-directory /srv/sid-armhf/usr/lib/debug' -ex 'set pagination off' -ex 'continue' -ex 'bt' -ex 'continue' -ex 'exit' Something like: Program received signal SIGILL, Illegal instruction. 0x37071dc6 in _GLOBAL__sub_I_SkOpts.cpp () from /srv/sid-armhf/usr/lib/firefox-esr/libxul.so #0 0x37071dc6 in _GLOBAL__sub_I_SkOpts.cpp () from /srv/sid-armhf/usr/lib/firefox-esr/libxul.so #1 0x3f7d144c in call_init (env=0x3f208340, argv=0x3c94, argc=1, l=) at dl-init.c:70 #2 call_init (l=, argc=1, argv=0x3c94, env=0x3f208340) at dl-init.c:26 #3 0x3f7d14f2 in _dl_init (main_map=0x3f245f00, argc=1, argv=0x3c94, env=0x3f208340) at dl-init.c:117 #4 0x3f56664a in _dl_catch_exception () from /srv/sid-armhf/usr/lib/arm-linux-gnueabihf/libc.so.6 #5 0x3f7d5b60 in dl_open_worker (a=0x3fffd7b0) at dl-open.c:808 #6 0x3f566614 in _dl_catch_exception () from /srv/sid-armhf/usr/lib/arm-linux-gnueabihf/libc.so.6 #7 0x3f7d5da2 in _dl_open (file=0x3fffda64 "/srv/sid-armhf/usr/lib/firefox-esr/libxul.so", mode=-2147483391, caller_dlopen=0x4000af81 <_start+4560>, nsid=-2, argc=1, argv=0x3c94, env=0x3f208340) at dl-open.c:884 #8 0x3f4d9da0 in ?? () from /srv/sid-armhf/usr/lib/arm-linux-gnueabihf/libc.so.6
Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Hi, On Wed, Mar 01, 2023 at 02:41:05PM +0100, Jérémy Lal wrote: > For now I'm unlucky with the porterbox, because /var/run/schroot > disappeared yesterday. I can confirm that the issue isn't reproducible with V8_DEFAULT_STACK_SIZE_KB set to 984. Built and tested on a Macbook M1. (sid-arm64)ema@sarzana:~/debian/dygraphs-2.2.1 $ babeljs --config-file $PWD/babel.config.json --compact false --source-maps inline -d tests5 auto_tests Successfully compiled 59 files with Babel (994ms).
Bug#1031398: debian-installer-utils: fetch-url fails with https if system date is wrong
Package: debian-installer-utils Version: 1.144 Booting with preseed/url=https://example.org/preseed.cfg fails if the system's clock is awfully wrong. I've got a system convinved that today is January 1st, 1970 and unsurprisingly the wget certificate check fails. Also unsurprisingly adding debian-installer/allow_unauthenticated_ssl=true is a viable workaround. Given that AFAIK d-i does support setting the date with ntp, it may possibly make sense to do that before wgetting the preseed file? Thanks, Emanuele
Bug#913431: Debian Installer Bullseye RC 2 release
Hi Vincent, On Sat, Apr 22, 2023 at 02:58:22AM +0200, Vincent Danjean wrote: > I made a push request[1] but I missed the fact that it fails. > It was due to the tests being run with sh(dash) instead of bash or > busybox sh. > So, I just fixed the code so that it works with any of these 3 shells > and I update the testsuite. Now, all the tests pass on salsa. Nice! > Let me know if this is ok for you. As d-i is already in RC, if > you prefer, I can revert the longint2human part that modifies > some information, and only keep the human2longint that adds > some new input that were forbidden before (no change for what > was already accepted). The longint2human part can be added after > the release if you think it is too intrusive (or if it must be > adapted) I think splitting the patch as you suggest is a good idea. The longint2human part is quite a large change, let's do that after Bookworm. Thanks, ema
Bug#1035018: btrfs-progs: /sbin/fsck.btrfs missing from udeb
Package: btrfs-progs Version: 6.2-1 X-Debbugs-CC: debian-b...@lists.debian.org Tags: patch Hi, the btrfs-progs udeb currently includes only /bin/btrfs and /bin/mkfs.btrfs. Please add /sbin/fsck.btrfs as well so that it can be included in the initramfs generated by the debian installer. Patch attached. Thanks! ema diff -Nru btrfs-progs-6.2/debian/btrfs-progs-udeb.install btrfs-progs-6.2/debian/btrfs-progs-udeb.install --- btrfs-progs-6.2/debian/btrfs-progs-udeb.install 2023-03-01 00:16:51.0 +0100 +++ btrfs-progs-6.2/debian/btrfs-progs-udeb.install 2023-04-27 16:43:48.0 +0200 @@ -1,2 +1,3 @@ btrfs /bin mkfs.btrfs /bin +fsck.btrfs /sbin
Bug#830857: [Pkg-libvirt-maintainers] Bug#830857: libvirt-daemon: CPU feature cmt not found
Hi, On Tue, Jul 12, 2016 at 08:22:31PM +0200, Ansgar Hegerfeld wrote: > Okay, thanks. I opened a bugreport upstream: > https://bugzilla.redhat.com/show_bug.cgi?id=1355857 The upstream bug was fixed a long time ago. Is the issue still reproducible in Debian, or can this bug be closed? Thanks, ema
Bug#1035018: btrfs-progs: /sbin/fsck.btrfs missing from udeb
Hi Adam, On Thu, Apr 27, 2023 at 05:52:42PM +0200, Adam Borowski wrote: > Ie, /sbin/fsck.btrfs serves no purpose that'd be useful in an udeb. > > Before I close this report, may I ask if you have a purpose for this > stub? You probably wanted a full-blown recovery tool, but I may be > getting you wrong. During d-i testing I saw a warning from update-initramfs mentioning that fsck.btrfs could not be found and thus would not be copied into the initramfs. I noticed that d-i does have /sbin/fsck.jfs and friends, but not fsck.btrfs, and concluded that not having fsck.btrfs in the udeb was the reason for the warning. However (as pham pointed out on #debian-boot) the initramfs is generated inside /target/, ie. the chroot of the installed system, which means that lack of fsck.btrfs in the udeb is not the cause of the problem I've seen. The reason for the warning is that the first time update-initramfs is called in /target/, btrfs-progs is not installed yet in the target chroot. Later on, when btrfs-progs actually does get installed, the initramfs is generated once again, this time with fsck.btrfs. Please feel free to close this bug.
Bug#1035381: virt-manager: does not autodetect OS of Debian Installer RC ISOs
Package: virt-manager Version: 1:4.1.0-2 X-Debbugs-CC: debian-b...@lists.debian.org Hi, Step 2 of the "Create a new virtual machine" wizard fails to automatically detect the operating system when using an RC version of d-i such as [0]. See attached screenshot. Stable images like [1] are correctly identified as "Debian 11". Given that "debiantesting" is in the list of known operating systems, it would be great if d-i RC ISOs could be identified as such. Thanks, ema [0] https://cdimage.debian.org/cdimage/bookworm_di_rc2/amd64/iso-cd/debian-bookworm-DI-rc2-amd64-netinst.iso [1] https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.7.0-amd64-netinst.iso
Bug#1033613: edk2: please provide DEBUG versions of OVMF_CODE and AAVMF_CODE
Source: edk2 Version: 2022.11-6 Severity: wishlist Hi, edk2 binaries are currently built with BUILD_TYPE = RELEASE [1]. For debugging purposes, it is also possible to build them with BUILD_TYPE = DEBUG. It would be great if debug versions of OVMF_CODE and AAVMF_CODE could be built, perhaps named AAVMF_CODE.debug.fd and OVMF_CODE.debug.fd Thanks, Emanuele [1] https://sources.debian.org/src/edk2/2022.11-6/debian/rules/#L7
Bug#1033569: systemd-boot-efi: Secure Boot via shim broken on arm64 due to missing SBAT section
Hi, On Mon, Mar 27, 2023 at 06:23:57PM +0200, Michael Biebl wrote: > Please consider raising this issue upstream There's no need, the bug is fixed in main (currently at 3a051522). It is however reproducible checking out tag v253, so presumably upstream version v254 will be the first release fixing this. I see that there's been quite some work in the area, eg. commit 2afeaf16. Thanks, Emanuele
Bug#1033657: grub-efi-arm64-signed: Secure Boot not working on arm64
On 2023-03-29 04:13, Emanuele Rocca wrote: > We need to be able to reproduce the issue (a) with a self-signed > version of grub. I did manage to reproduce with a self-signed grub by using a new key instead of the one included in AAVMF_VARS.snakeoil.fd. The latter is included in PK and DB, while to reproduce we need a key present in MOK only. openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -days 36500 -subj "/CN=My Name/" openssl x509 -inform der -in MOK.der -out MOK.pem After enrolling the key from fwsetup, I could get the exact same error with a self-signed grub as I get with the one signed with Debian CA: grub> linux /vmlinuz-6.1.0-7-arm64.onlymok grub> boot [Security] 3rd party image[0] can be loaded after EndOfDxe: MemoryMapped(0x2,0x6A045000,0x6C735DC0). DxeImageVerificationLib: Image is signed but signature is not allowed by DB and SHA256 hash of image is not found in DB/DBX. The image doesn't pass verification: MemoryMapped(0x2,0x6A045000,0x6C735DC0) error: cannot load image.
Bug#1033657: grub-efi-arm64-signed: Secure Boot not working on arm64
Control: tags -1 + patch Proposed fix: https://salsa.debian.org/grub-team/grub/-/merge_requests/32
Bug#1033567: systemd: move /usr/bin/kernel-install to package systemd-boot
Package: systemd Version: 252.6-1 Hi, the systemd binary package currently ships the following files: /usr/bin/kernel-install /usr/share/bash-completion/completions/kernel-install /usr/share/man/man8/kernel-install.8.gz /usr/share/zsh/vendor-completions/_kernel-install Given that AFAIU kernel-install is not particularly useful without systemd-boot, please consider moving the files mentioned above to the systemd-boot binary package.
Bug#1033569: systemd-boot-efi: Secure Boot via shim broken on arm64 due to missing SBAT section
Package: systemd-boot-efi Version: 252.6-1 Hi, booting in Secure Boot mode with a self-signed systemd-bootaa64.efi works well on arm64. However, trying to boot via shimaa64.efi fails with the following error: shim.c:866:load_image() attempting to load \EFI\BOOT\grubaa64.efi pe.c:844:verify_sbat_section() No .sbat section data Verification failed: Security Policy Violation Looking for the SBAT section in systemd-bootaa64.efi confirms that indeed it is missing: objdump -x /usr/lib/systemd/boot/efi/systemd-bootaa64.efi | grep .sbat # <- no output Instead, on amd64: $ objdump -x /usr/lib/systemd/boot/efi/systemd-bootx64.efi | grep .sbat 7 .sbat 00d9 00028040 00028040 0001dc00 2**2 [136](sec 8)(fl 0x00)(ty0)(scl 3) (nx 0) 0x sbat Note that .sbat is not the only section missing. On arm64 there's only .text and .data: Sections: Idx Name Size VMA LMA File off Algn 0 .text 0001a000 1000 1000 1000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 2000 0001b000 0001b000 0001b000 2**2 CONTENTS, ALLOC, LOAD, DATA While amd64 has: Sections: Idx Name Size VMA LMA File off Algn 0 .text 00015710 5000 5000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .reloc000c 0001b000 0001b000 00015c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 64b8 0001c000 0001c000 00015e00 2**4 CONTENTS, ALLOC, LOAD, DATA 3 .dynamic 0100 00023000 00023000 0001c400 2**2 CONTENTS, ALLOC, LOAD, DATA 4 .rela 1038 00024000 00024000 0001c600 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .dynsym 0018 00026000 00026000 0001d800 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .sdmagic 002b 00028000 00028000 0001da00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .sbat 00d9 00028040 00028040 0001dc00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .osrel003f 00028120 00028120 0001de00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA
Bug#1033657: grub-efi-arm64-signed: Secure Boot not working on arm64
Package: grub-efi-arm64-signed Version: 2.06-8 Hi, Secure Boot does not work on arm64 using the shim signed by Microsoft [0] and grub2 signed by Debian [1] currently in sid. (a) SB not working with Debian's shim, grub and kernel: $ sbverify --list /mnt/efi/boot/bootaa64.efi | grep subject warning: data remaining[839096 vs 979672]: gaps between PE/COFF sections? - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 $ sbverify --list /mnt/efi/boot/grubaa64.efi | grep subject - subject: /CN=Debian Secure Boot Signer 2022 - grub2 $ sbverify --list /mnt/vmlinuz-6.1.0-7-arm64 | grep subject - subject: /CN=Debian Secure Boot Signer 2022 - linux With the efi variables from qemu-efi-aarch64's AAVMF_VARS.ms.fd plus SHIM_VERBOSE enabled `mokutil --set-verbosity true`, and the firmware file AAVM_CODE.fd from edk2 rebuilt in debug mode - see https://bugs.debian.org/1033613 $ qemu-system-aarch64 -machine virt -cpu cortex-a57 \ -drive file=AAVMF_CODE.debug.fd,format=raw,if=pflash,readonly=true \ -drive file=AAVMF_VARS.ms.verbose.fd \ [...] grub> linux /vmlinuz-6.1.0-7-arm64 [...] shim.c:665:verify_buffer_authenticode() Attempting to verify signature 0: shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (db) shim.c:154:check_db_cert_in_ram() trying to verify cert 1 (db) shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (MokListRT) shim.c:164:check_db_cert_in_ram() AuthenticodeVerify() succeeded: 1 grub> boot [Security] 3rd party image[0] can be loaded after EndOfDxe: MemoryMapped(0x2,0x6A03D000,0x6C72D7C0). DxeImageVerificationLib: Image is signed but signature is not allowed by DB and SHA256 hash of image is not found in DB/DBX. The image doesn't pass verification: MemoryMapped(0x2,0x6A03D000,0x6C72D7C0) error: cannot load image. However: (b) SB works with Ubuntu's shim, grub and kernel [2] (c) SB works using a self-signed shim, grub, and kernel from unstable The Ubuntu output (b) is: grub> linux /vmlinuz-6.2.0-18-generic shim.c:665:verify_buffer_authenticode() Attempting to verify signature 0: shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (dbx) shim.c:154:check_db_cert_in_ram() trying to verify cert 1 (dbx) shim.c:154:check_db_cert_in_ram() trying to verify cert 2 (dbx) shim.c:154:check_db_cert_in_ram() trying to verify cert 3 (dbx) shim.c:154:check_db_cert_in_ram() trying to verify cert 4 (dbx) shim.c:154:check_db_cert_in_ram() trying to verify cert 5 (dbx) shim.c:154:check_db_cert_in_ram() trying to verify cert 6 (dbx) shim.c:154:check_db_cert_in_ram() trying to verify cert 7 (dbx) shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (db) shim.c:154:check_db_cert_in_ram() trying to verify cert 1 (db) shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (MokListRT) shim.c:164:check_db_cert_in_ram() AuthenticodeVerify() succeeded: 1 grub> boot EFI stub: Booting Linux Kernel... EFI stub: EFI_RNG_PROTOCOL unavailable EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary EFI stub: ERROR: FIRMWARE BUG: Image BSS overlaps adjacent EFI memory region EFI stub: Generating empty DTB EFI stub: Exiting boot services... EFI stub: UEFI Secure Boot is enabled. And the Debian self-signed output (c) is: grub> linux /vmlinuz-6.1.0-7-arm64.selfsigned [...] shim.c:665:verify_buffer_authenticode() Attempting to verify signature 0: shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (db) shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (MokListRT) shim.c:164:check_db_cert_in_ram() AuthenticodeVerify() succeeded: 1 shim.c:665:verify_buffer_authenticode() Attempting to verify signature 1: shim.c:154:check_db_cert_in_ram() trying to verify cert 0 (db) shim.c:164:check_db_cert_in_ram() AuthenticodeVerify() succeeded: 1 grub> boot [Security] 3rd party image[0] can be loaded after EndOfDxe: MemoryMapped(0x2,0x6A04,0x6C730E68). DxeImageVerificationLib: Image is signed but signature is not allowed by DB and SHA256 hash of image is not found in DB/DBX. DxeImageVerification: MeasureVariable (Pcr - 7, EventType - 80E0, VariableName - db, VendorGuid - D719B2CB-3D3A-4596-A3BC-DAD00E67656F) MeasureBootPolicyVariable - Not Found None of Tcg2Protocol/CcMeasurementProtocol is installed. [...] EFI stub: Booting Linux Kernel... EFI stub: EFI_RNG_PROTOCOL unavailable EFI stub: UEFI Secure Boot is enabled. As per the way forward: the diff between Debian's grub and Ubuntu's is non-trivial, so comparing the two may not be the best course of action. I see that there is an old patchset at https://bugs.debian.org/836140 which could be forward-ported though. In any case there are two difficulties when it comes to testing a new grub version: - Secure Boot just works when self-signing (c), and I'm not sure why that is
Bug#1033643: debvm: consider using cpu=cortex-a57 instead of cpu=max on arm64
Hi, On 2023-03-29 01:12, Arnd Bergmann wrote: > a) try to reproduce the behavior on an x86-64 host Good point. Also on a x86-64 host cpu=cortex-a57 is significantly faster: max: [ 30.086331] systemd[1]: Hostname set to . cortex-a57: [ 13.870771] systemd[1]: Hostname set to .
Bug#1033643: debvm: consider using cpu=cortex-a57 instead of cpu=max on arm64
Package: debvm Version: 0.2.9 Hi, some arm64 hosts unfortunately do not have KVM support: kvm [1]: HYP mode not available On those systems, running qemu with -cpu=cortex-a57 results in significantly improved performance compared to -cpu=max. For example: here is how long it takes debvm-run to reach the point where the hostname is being set when using -cpu=max: [ 34.838074] systemd[1]: Hostname set to . Modifying /usr/bin/debvm-run to set CPU=cortex-a57 instead: [ 12.450115] systemd[1]: Hostname set to . Please consider using CPU=cortex-a57 instead of CPU=max for arm64, and/or adding a command line switch to override the value of CPU. Clearly, if kvm support *is* present CPU=host keeps on being the best choice. Thank you for writing debvm!
Bug#1033643: debvm: consider using cpu=cortex-a57 instead of cpu=max on arm64
On 2023-03-29 06:55, Helmut Grohne wrote: > At this point, my preference is max,pauth-impdef=on. Agreed. > Would someone confirm that this also speeds up on arm64? Confirmed. Thanks! ema
Bug#1031221: grub-installer: db_input / db_go undefined in postinst
Package: grub-installer Version: 1.186 Severity: normal Tags: newcomer Hi, The function die() in /var/lib/dpkg/info/grub-installer.postinst calls db_input and db_go, but the functions are not defined: https://salsa.debian.org/installer-team/grub-installer/-/blob/master/debian/postinst#L16 Here's the relevant error in /var/log/syslog: /var/lib/dpkg/info/grub-installer postinst: line 16: db_input not found configuring 'grub-installer' failed with error code 1 The script should source /usr/share/debconf/confmodule. Thanks, ema
Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted
control: tag -1 patch On Sun, Feb 12, 2023 at 09:46:34PM +0100, Emanuele Rocca wrote: > I'm unsure as to what the best course of action is here, but perhaps an idea > is > to avoid calling "die" when mount fails for efivarfs, and log an error to > /var/log/syslog instead? Of course the relevant umount should be skipped too. > > In any case, the "|| true" part in the mountvirtfs efivarfs call should > probably be dropped. Patch at https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/11
Bug#1031221: grub-installer: db_input / db_go undefined in postinst
control: tag -1 patch Patch here: https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/12
Bug#1030216: armnn: FTBFS with GCC12
Package: armnn Version: 20.08 Severity: serious Tags: upstream ftbfs patch Justification: fails to build from source (but built successfully in the past) The package fails to build with gcc 12, currently in sid and bookworm. It does build fine with gcc 10 in bullseye. The issue has been fixed upstream: https://github.com/ARM-software/armnn/issues/643 This is the patch: https://github.com/ARM-software/armnn/commit/85edad42b8b76e76c5d969e4bc380b0e8a845c9b.patch Here is an excerpt from the build failure on the amd64 buildd x86-ubc-02: In file included from /<>/src/backends/reference/workloads/ElementwiseFunction.cpp:9: /<>/src/backends/reference/workloads/Minimum.hpp:12:30: error: ‘template struct std::binary_function’ is deprecated [-Werror=deprecated-declarations] 12 | struct minimum : public std::binary_function | ^~~ [...] cc1plus: all warnings being treated as errors See https://buildd.debian.org/status/logs.php?pkg=armnn=20.08-10%2Bb1=sid
Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted
Package: grub-installer
Version: 1.186
Severity: important
Hi,
On systems where efivarfs cannot be mounted, the grub installation step fails
even though it would have otherwise worked just fine skipping the mount
efivarfs command, i.e. system installation is successful with this preseed file:
d-i partman/early_command string sed -i 's/mountvirtfs efivarfs/#/'
/var/lib/dpkg/info/grub-installer.postinst
The relevant code in d/postinst looks as follows, suggesting the intention to
ignore failures:
mountvirtfs efivarfs /target/sys/firmware/efi/efivars || true
However, mountvirtfs itself is exiting with 1 in case of mount errors:
mountvirtfs () {
fstype="$1"
path="$2"
if grep -q "[[:space:]]$fstype\$" /proc/filesystems && \
! grep -q "^[^ ]\+ \+$path " /proc/mounts; then
mkdir -p "$path" || \
die grub-installer/mounterr "Error creating $path"
mount -t "$fstype" "$fstype" "$path" || \
die grub-installer/mounterr "Error mounting $path"
trap "umount $path" HUP INT QUIT KILL PIPE TERM EXIT
fi
}
I'm unsure as to what the best course of action is here, but perhaps an idea is
to avoid calling "die" when mount fails for efivarfs, and log an error to
/var/log/syslog instead? Of course the relevant umount should be skipped too.
In any case, the "|| true" part in the mountvirtfs efivarfs call should
probably be dropped.
Please note that this issue is different from https://bugs.debian.org/933523.
In that case, installing grub fails *because* efivarfs does not get mounted
properly, and the surprising bit is that the mountvirtfs efivarfs call does
*not* fail for some reason. :-)
FTR here's the error I get trying to mount efivarfs manually:
~ # mount -t efivarfs efivarfs /target/sys/firmware/efi/efivars
mount: mounting efivarfs on /target/sys/firmware/efi/efivars failed:
Operation not supported
Thanks!
ema
Bug#933523: Possible solution
Hi, On Wed, Jul 21, 2021 at 03:42:25PM +0200, Sebastian Neuser wrote: > > On Wed, 2021-07-21 at 14:59 +0200, John Paul Adrian Glaubitz wrote: > > That's probably because of the "|| true" that Steve added to the mount > > call which means that this line will always succeed even when the > > mount attempt actually failed. > > I don't think so: > mountvirtfs() mounts efivarfs with `mount ... || die ...` and die() ends > with `exit 1`, so `|| true` after the call to mountvirtfs() is actually > dead code. > > Unless I still don't get shell script logic, which is of course entirely > possible. :-) Just to confirm your understanding of the logic, indeed in case of mount efivarfs errors the script should fail because of the die() calls, see https://bugs.debian.org/1031183. Why did the mount command seemingly succeed in this case and yet the FS did not get mounted I guess is the open question. Is this bug still reproducible with a recent installer image?
Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."
Hi again, On 2023-05-03 08:16, Axel Beckert wrote: > Machine: Thinkpad X13s (ARM) Sorry, I've realized only after sending my previous message and having a coffee that this is about the X13s. :) The X13s is unfortunately not supported by Linux 6.1 that Bookworm will ship with. Hopefully 6.4 will include all the needed patches. > But Dimitri's Ubuntu Installer Live image lunar-desktop-arm64.iso from > https://people.canonical.com/~xnox/ubuntu-concept/full/daily-live/current/ > as of 2023-03-07 20:08 booted fine without these issues. > > It would be nice if Dimitri (xnox@d.o, Cc'ed) could tell us which fix > has been applied by him (or Ubuntu) to this image so that we can fix > this issue also in Debian, maybe even before the release of Bookworm. If that image works, then it includes quite a few of out of tree kernel patches. As per [1] they are unfortunately not going to be applied to the Debian kernel, we have to wait for upstream inclusion. Emanuele [1] https://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."
Hi Axel, On 2023-05-03 08:16, Axel Beckert wrote: > After choosing either "expert install" (first and prefered try) or > "graphical expert install" (second try and second choice) I saw these > three lines and then nothing more happened: > > EFI stub: Booting Linux Kernel... > EFI stub: Using DTB from configuration table > EFI stub: Exiting boot services... > > Waited 10 minutes at least, i.e. left it alone, did something else and > came back later. Even adding the "debug" kernel parameter didn't bring > up any more details on what's happening. Perhaps we can get some more output by adding 'earlycon=efifb keep_bootcon' after 'debug' to the kernel CLI. Additionally, please try adding 'set debug=linux' to grub's configuration as well -- after the setparams directive for example. See attached screenshot. Thanks, Emanuele
Bug#1038868: [Pkg-pascal-devel] Bug#1038868: fpc: armhf binaries should have the hard-float ELF flag set
Hello Abou,
On 2023-07-06 01:59, Abou Al Montacir wrote:
> Can you please give the output of fpc -i and fpc -vi?
> This was requested by upstream to investigate the issue.
Of course.
(sid-armhf)root@ariel:/var/tmp# fpc -vi hello.pas
Free Pascal Compiler version 3.2.2+dfsg-21 [2023/06/17] for arm
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Linux for ARMHF
Compiling hello.pas
Linking hello
4 lines compiled, 0.3 sec
(sid-armhf)root@ariel:/var/tmp# fpc -i
Free Pascal Compiler version 3.2.2
Compiler date : 2023/06/17
Compiler CPU target: arm
Supported targets (targets marked with '{*}' are under development):
Linux: Linux for ARMHF
WinCE: WinCE for ARM
gba: GameBoy Advance
PalmOS: PalmOS
nds: Nintendo DS
embedded: Embedded
Symbian: Symbian OS for ARM
iOS: iOS for ARM
Android: Android for ARMEL
AROS: AROS for ARM
NetBSD: NetBSD for ARMHF {*}
Supported CPU instruction sets:
ARMV3,ARMV4,ARMV4T,ARMV5,ARMV5T,ARMV5TE,ARMV5TEJ,ARMV6,ARMV6K,ARMV6T2
ARMV6Z,ARMV6M,ARMV7,ARMV7A,ARMV7R,ARMV7M,ARMV7EM
Supported FPU instruction sets:
SOFT,LIBGCC,FPA,FPA10,FPA11,VFPV2,VFPV3,VFPV3_D16,FPV4_S16,VFPV4
Supported inline assembler modes:
STANDARD
DIVIDED
UNIFIED
Recognized compiler and RTL features:
HEAP,INITFINAL,RTTI,CLASSES,EXCEPTIONS,EXITCODE,ANSISTRINGS,WIDESTRINGS
TEXTIO,CONSOLEIO,FILEIO,RANDOM,VARIANTS,OBJECTS,DYNARRAYS,THREADING
COMMANDARGS,PROCESSES,STACKCHECK,DYNLIBS,SOFTFPU,OBJECTIVEC1,RESOURCES
UNICODESTRINGS
Supported ABI targets:
DEFAULT
EABIHF
Supported Optimizations:
REGVAR
STACKFRAME
PEEPHOLE
LOOPUNROLL
TAILREC
CSE
DFA
ORDERFIELDS
FASTMATH
REMOVEEMPTYPROCS
CONSTPROP
FORCENOSTACKFRAME
Supported Whole Program Optimizations:
All
DEVIRTCALLS
OPTVMTS
SYMBOLLIVENESS
Supported Microcontroller types:
LPC810M021FN8,LPC811M001FDH16,LPC812M101FDH16,LPC812M101FD20
LPC812M101FDH20,LPC1110FD20,LPCFDH20_002,LPCFHN33_101
LPCFHN33_102,LPCFHN33_103,LPCFHN33_201,LPCFHN33_202
LPCFHN33_203,LPC1112FD20_102,LPC1112FDH20_102,LPC1112FDH28_102
LPC1112FHN33_101,LPC1112FHN33_102,LPC1112FHN33_103,LPC1112FHN33_201
LPC1112FHN24_202,LPC1112FHN33_202,LPC1112FHN33_203,LPC1112FHI33_202
LPC1112FHI33_203,LPC1113FHN33_201,LPC1113FHN33_202,LPC1113FHN33_203
LPC1113FHN33_301,LPC1113FHN33_302,LPC1113FHN33_303,LPC1113FBD48_301
LPC1113FBD48_302,LPC1113FBD48_303,LPC1114FDH28_102,LPC1114FN28_102
LPC1114FHN33_201,LPC1114FHN33_202,LPC1114FHN33_203,LPC1114FHN33_301
LPC1114FHN33_302,LPC1114FHN33_303,LPC1114FHN33_333,LPC1114FHI33_302
LPC1114FHI33_303,LPC1114FBD48_301,LPC1114FBD48_302,LPC1114FBD48_303
LPC1114FBD48_323,LPC1114FBD48_333,LPC1115FBD48_303,LPC11C12FBD48_301
LPC11C14FBD48_301,LPC11C22FBD48_301,LPC11C24FBD48_301
LPC11D14FBD100_302,LPC1224FBD48_101,LPC1224FBD48_121,LPC1224FBD64_101
LPC1224FBD64_121,LPC1225FBD48_301,LPC1225FBD48_321,LPC1225FBD64_301
LPC1225FBD64_321,LPC1226FBD48_301,LPC1226FBD64_301,LPC1227FBD48_301
LPC1227FBD64_301,LPC12D27FBD100_301,LPC1311FHN33,LPC1311FHN33_01
LPC1313FHN33,LPC1313FHN33_01,LPC1313FBD48,LPC1313FBD48_01,LPC1315FHN33
LPC1315FBD48,LPC1316FHN33,LPC1316FBD48,LPC1317FHN33,LPC1317FBD48
LPC1317FBD64,LPC1342FHN33,LPC1342FBD48,LPC1343FHN33,LPC1343FBD48
LPC1345FHN33,LPC1345FBD48,LPC1346FHN33,LPC1346FBD48,LPC1347FHN33
LPC1347FBD48,LPC1347FBD64,LPC2114,LPC2124,LPC2194,LPC1754,LPC1756
LPC1758,LPC1764,LPC1766,LPC1768,AT91SAM7S256,AT91SAM7SE256,AT91SAM7X256
AT91SAM7XC256,STM32F030C6,STM32F030C8,STM32F030F4,STM32F030K6
STM32F030R8,STM32F050C4,STM32F050C6,STM32F050F4,STM32F050F6,STM32F050G4
STM32F050G6,STM32F050K4,STM32F050K6,STM32F051C4,STM32F051C6,STM32F051C8
STM32F051K4,STM32F051K6,STM32F051K8,STM32F051R4,STM32F051R6,STM32F051R8
STM32F091CC,STM32F091CB,STM32F091RC,STM32F091RB,STM32F091VC,STM32F091VB
STM32F100X4,STM32F100X6,STM32F100X8,STM32F100XB,STM32F100XC,STM32F100XD
STM32F100XE,STM32F101X4,STM32F101X6,STM32F101X8,STM32F101XB,STM32F101XC
STM32F101XD,STM32F101XE,STM32F101XF,STM32F101XG,STM32F102X4,STM32F102X6
STM32F102X8,STM32F102XB,STM32F103X4,STM32F103X6,STM32F103X8,STM32F103XB
STM32F103XC,STM32F103XD,STM32F103XE,STM32F103XF,STM32F103XG,STM32F107X8
STM32F107XB,STM32F107XC,STM32F105R8,STM32F105RB,STM32F105RC,STM32F105V8
STM32F105VB,STM32F105VC,STM32F107RB,STM32F107RC,STM32F107VB,STM32F107VC
STM32F401CB,STM32F401RB,STM32F401VB,STM32F401CC,STM32F401RC,STM32F401VC
DISCOVERYF401VC,STM32F401CD,STM32F401RD,STM32F401VD,STM32F401CE
STM32F401RE,NUCLEOF401RE,STM32F401VE,STM32F407VG,DISCOVERYF407VG
STM32F407IG,STM32F407ZG,STM32F407VE,STM32F407ZE,STM32F407IE,STM32F411CC
STM32F411RC,STM32F411VC,STM32F411CE,STM32F411RE,NUCLEOF411RE
STM32F411VE,DISCOVERYF411VE,STM32F429VG,STM32F429ZG,STM32F429IG
STM32F429VI,STM32F429ZI,DISCOVERYF429ZI,STM32F429II,STM32F429VE
STM32F429ZE,STM32F429IE,STM32F429BG,STM32F429BI,STM32F429BE,STM32F429NG
STM32F429NI,STM32F429NE,STM32F446MC,STM32F446RC,STM32F446VC,STM32F446ZC
Bug#1040194: ITP: parsec-tool -- Command line tool to communicate with the Parsec service
Package: wnpp Severity: wishlist Owner: Emanuele Rocca X-Debbugs-Cc: debian-de...@lists.debian.org, debian-r...@lists.debian.org * Package name: parsec-tool Version : 0.6.0 Upstream Author : Parsec Project Contributors * URL : https://github.com/parallaxsecond/parsec-tool * License : Apache-2.0 Programming Lang: Rust Description : Command line tool to communicate with the Parsec service Parsec is an abstraction layer that can be used to interact with hardware-backed security facilities such as the Hardware Security Module (HSM), the Trusted Platform Module (TPM), firmware-backed, and isolated software services. . This package provides the command line tool to communicate with the Parsec service. Like parsec-service, parsec-tool will also be maintained under the umbrella of the Debian Rust Team.
Bug#1040919: gcc-11-cross-mipsen: missing binaries gcc-11-mips-linux-gnu{,-base}
Source: gcc-11-cross-mipsen Version: 5+c3 Hi, the following two binary packages seem to be missing: - gcc-11-mips-linux-gnu - gcc-11-mips-linux-gnu-base We do however have the equivalent packages for GCC 10, 12, and 13 in sid. https://packages.debian.org/unstable/gcc-10-mips-linux-gnu https://packages.debian.org/unstable/gcc-11-mips-linux-gnu https://packages.debian.org/unstable/gcc-12-mips-linux-gnu https://packages.debian.org/unstable/gcc-13-mips-linux-gnu
Bug#1040626: gcc-13-cross-mipsen ftbfs in unstable
Hi, On 2023-07-08 08:43, Matthias Klose wrote: > [...] > checking linker soname option... yes > checking linker --demangle support... no > checking linker plugin support... 0 > checking assembler for explicit relocation support... no > checking assembler for -mno-shared support... no > checking assembler for .gnu_attribute support... no > checking assembler for .module support... no > configure: error: Requesting --with-fp-32= requires assembler support for > .module. > make[4]: *** [Makefile:4569: configure-gcc] Error 1 > make[4]: Leaving directory '/<>/gcc/build' > make[3]: *** [Makefile:1042: all] Error 2 > make[3]: Leaving directory '/<>/gcc/build' FTR it seems that the issue affects arm64 and ppc64el but not other architectures: https://buildd.debian.org/status/package.php?p=gcc%2d13%2dcross%2dmipsen For example, some interesting differences on the mips64el build: checking linker --demangle support... yes checking linker plugin support... 2 checking assembler for explicit relocation support... yes checking assembler for -mno-shared support... yes checking assembler for .gnu_attribute support... yes checking assembler for .module support... yes
Bug#1040929: gcc-13-cross-ports: please add arm64 to HOST_ARCHS_
Source: gcc-13-cross-ports Version: 6 Severity: wishlist Hi, On amd64 hosts all ports are supported (ie: the binary package gcc-13-alpha-linux-gnu and similar are available). That is not the case for arm64 hosts. Please add arm64 to HOST_ARCHS_ in d/rules. Thanks, Emanuele
Bug#1040929: gcc-13-cross-ports: please add arm64 to HOST_ARCHS_
Hi Matthias, On 2023-07-12 08:22, Matthias Klose wrote: > how will you care about build time regressions? The change is not > difficult, however I'd like to see some commitment how to deal with these > issues. Happy to help should any issues arise. FWIW there's no need to enable all arches in one go, we could start with a subset (one or more of m68k, hppa, sh4, and sparc64?) if we want to be extra cautious. Emanuele
Bug#1038868: [Pkg-pascal-devel] Bug#1038868: fpc: armhf binaries should have the hard-float ELF flag set
Hi Abou, On 2023-07-06 01:59, Abou Al Montacir wrote: > This was requested by upstream to investigate the issue. I assume you've opened an upstream issue, but I can't find it on https://gitlab.com/freepascal.org/fpc/source/-/issues/ Am I looking in the wrong place? Can you please point me at it? Thanks! Emanuele
Bug#1040010: [debian-installer] Please support more arm64 boards
Hello Roman, On 2023-07-01 04:18, Roman Mamedov wrote: > There are 42 DTBs shipped with the installer for Allwinner alone: > https://d-i.debian.org/daily-images/arm64/daily/device-tree/allwinner/ > > But for the bootloader aka firmware aka u-boot: > https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/ > it is an extremely weird and arbitrary list of 12 random boards. For instance > supporting "Orange Pi Zero Plus2" of all things specifically, not even just > "Zero Plus"; and not, say, Orange Pi Prime or Orange Pi Win (and so on). The choice of 12 boards does indeed look a little puzzling. Having no historical background on this, I can try and guess that they were added on a case-by-case basis every time someone needed to boot the installer on their system. Out of interest: do you have a board that's not among the lucky 12? :-) > So despite having all the other DTBs, the system is not installable on those > boards. Unless the user is sent to find and compile their own u-boot, but if > so, what is the purpose of randomly providing it for 12 random niche boards to > begin with, might as well make everyone do that. > > Instead, I suggest a better solution: maybe not even daily, but at least once > per month, could you build a bootloader part for ALL the supported boards, and > not just a handful of them. In an ideal world we would have just one single image that works on all systems! That's one of the ideas behind the Arm SystemReady certification program at least: making sure that the board can boot a regular, unmodified distro ISO without any additional blobs. We don't live in such a world unfortunately, at least not yet and not for all boards. I'm not sure we should have one different image for each DTB honestly. I'd rather go for having no custom images at all, but a very simple procedure to build your own image for your board. Maybe in the form of documentation, or a script, or both. Emanuele
Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages
Hi, On Tue, May 30, 2023 at 09:08:45PM +0200, Cyril Brulebois wrote: > Philip Hands (2023-05-30): > > Apparently, this MR fixes the problem: > > > > https://salsa.debian.org/installer-team/rootskel/-/merge_requests/8 > > > > Although this does prompt the question of why aarch64 has TERM set to > > 'vt102' at this point, rather than 'linux'. > > Glancing at the merge request earlier, my first (intertwined) questions > were: > > 1. Why is aarch64 special here? > 2. Where does that difference come from? According to Jessica Clarke this is due to busybox using vt102: https://society.oftrolls.com/@jrtc27@mastodon.social/110459684352427882 > 3. Which other architectures might be impacted if we were to change > that? I'm not sure, and I haven't tested the S40term-linux patch yet. However I can report that booting the installer by passing console=tty0 to the kernel fixes the problem (thanks alpernebbi!). Which of the two changes (console=tty0 vs S40term-linux patch) is less risky?
Bug#1036215: installation-reports: PXE netboot x86_64 libvirt guest on aarch64 host
Hello, following up here on the BTS for the benefit of those not reading #debian-boot. On Wed, May 17, 2023 at 05:37:07PM +0200, Cyril Brulebois wrote: > Emanuele Rocca (2023-05-17): > > (B) failure to load the grub splash screen [...] > > sarzana dnsmasq-tftp[7413]: file /srv/tftp/bookworm/isolinux/splash.png > > not found for 192.168.122.7 > > sarzana dnsmasq-tftp[7413]: file /srv/tftp/bookworm/splash.png not found > > for 192.168.122.7 > > > > The grub.cfg file under /debian-installer/amd64/grub/grub.cfg has the > > following > > conditionals: > > > > if background_image /isolinux/splash.png; then > > [...] > > elif background_image /splash.png; then > > > > The splash screen is loaded correctly replacing either of those with > > /debian-installer/amd64/boot-screens/splash.png instead. > > Adding an extra conditional in there really doesn't seem appropriate at > this point. Seeing how images/netboot/ is 745M, and how splash.png is > 58K, I think I'd rather have it duplicated in a way that it's found in > /splash.png for both text and gtk installers (/isolinux/splash.png could > would be a weird location given the booting happens via GRUB). Even better than duplicating the image, we can use a symlink instead, see: https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/32
Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages
Hi, On 2023-05-31 05:46, Samuel Thibault wrote: > I'd rather see a patch like > > if [ "$TERM" = vt102 -a `tty` = /dev/tty1 ] ; then > # Busybox's init uses a global TERM across all consoles. > # If the serial console is the default such as on arm64, that > # will force vt102 on the Linux VT. Fix this back so we get > # colors, utf-8, etc. > TERM=linux > fi > > (to be tested etc.) The following patch works. I've built a netboot image with patched rootskel, see attached screenshots for before and after the cure. diff -Nur rootskel-1.135/src/lib/debian-installer.d/S40term-linux /home/ema/debian/rootskel-1.135+nmu1/src/lib/debian-installer.d/S40term-linux --- rootskel-1.135/src/lib/debian-installer.d/S40term-linux 2011-01-20 01:05:16.0 +0100 +++ /home/ema/debian/rootskel-1.135+nmu1/src/lib/debian-installer.d/S40term-linux 2023-06-01 15:05:32.514361854 +0200 @@ -1,5 +1,13 @@ export LANG=C +if [ "$TERM" = vt102 -a `tty` = /dev/tty1 ] ; then + # Busybox's init uses a global TERM across all consoles. +# If the serial console is the default such as on arm64, that +# will force vt102 on the Linux VT. Fix this back so we get + # colors, utf-8, etc. + TERM=linux +fi + if [ "$TERM" = linux ] ; then if [ "$TERM_TYPE" = virtual ]; then echo -ne "\033[9;0]" # Turn off console blanking.
Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages
Hi again, On 2023-05-31 05:46, Samuel Thibault wrote: > The problem is that both are frown-prone. I guess there is a reason why > on arm the default console is set to the serial port, e.g. for simpler > debugging or something like that. Also worth mentioning: there is no bug on real hardware (eg: RPi 3B+). So far I think we've only heard about people getting this issue with qemu. ciao, ema
Bug#1042942: armnn: FTBFS on i386 due to test failures
Package: src:armnn Version: 20.08-13 Severity: serious armnn 20.08-13 seems to compile correctly on i386, but then FTBFS due to the following test failures: Running 430 test cases... ./src/armnn/test/ModelAccuracyCheckerTest.cpp(103): [1;31;49merror: in "ModelAccuracyCheckerTest/TestFloat32OutputTensorAccuracy": check totalAccuracy == 33.321f has failed [0;39;49m ./src/armnn/test/ModelAccuracyCheckerTest.cpp(107): [1;31;49merror: in "ModelAccuracyCheckerTest/TestFloat32OutputTensorAccuracy": check totalAccuracy == 66.641f has failed [0;39;49m ./src/armnn/test/optimizations/ConvertConstantsBFloatTests.cpp(120): [1;31;49merror: in "Optimizer/ConvertConstantsBFloatToFloatTest": check data[3] == 3.1072295E29f has failed [0;39;49m ./src/armnn/test/optimizations/ConvertConstantsBFloatTests.cpp(121): [1;31;49merror: in "Optimizer/ConvertConstantsBFloatToFloatTest": check data[4] == 9.131327E-10f has failed [0;39;49m ./src/armnn/test/optimizations/ConvertConstantsBFloatTests.cpp(123): [1;31;49merror: in "Optimizer/ConvertConstantsBFloatToFloatTest": check data[6] == -3.1072295E29f has failed [0;39;49m ./src/armnn/test/optimizations/ConvertConstantsBFloatTests.cpp(124): [1;31;49merror: in "Optimizer/ConvertConstantsBFloatToFloatTest": check data[7] == -9.131327E-10f has failed [0;39;49m ./src/profiling/test/ProfilingTests.cpp(1366): [1;31;49merror: in "ExternalProfiling/CheckCounterDirectoryRegisterCounter": check counter->m_Multiplier == 123.45f has failed [0;39;49m ./src/profiling/test/ProfilingTests.cpp(1408): [1;31;49merror: in "ExternalProfiling/CheckCounterDirectoryRegisterCounter": check counterWUnits->m_Multiplier == 123.45f has failed [0;39;49m ./src/profiling/test/ProfilingTests.cpp(1436): [1;31;49merror: in "ExternalProfiling/CheckCounterDirectoryRegisterCounter": check counterWoDevice->m_Multiplier == 123.45f has failed [0;39;49m ./src/profiling/test/ProfilingTests.cpp(1490): [1;31;49merror: in "ExternalProfiling/CheckCounterDirectoryRegisterCounter": check counterWDevice->m_Multiplier == 123.45f has failed [0;39;49m ./src/profiling/test/ProfilingTests.cpp(1519): [1;31;49merror: in "ExternalProfiling/CheckCounterDirectoryRegisterCounter": check counterWoCounterSet->m_Multiplier == 123.45f has failed [0;39;49m ./src/profiling/test/ProfilingTests.cpp(1561): [1;31;49merror: in "ExternalProfiling/CheckCounterDirectoryRegisterCounter": check counterWNumberOfCores->m_Multiplier == 123.45f has failed [0;39;49m ./src/profiling/test/ProfilingTests.cpp(1600): [1;31;49merror: in "ExternalProfiling/CheckCounterDirectoryRegisterCounter": check counterWMultiCoreDevice->m_Multiplier == 123.45f has failed [0;39;49m ./src/profiling/test/ProfilingTests.cpp(1648): [1;31;49merror: in "ExternalProfiling/CheckCounterDirectoryRegisterCounter": check counterWMultiCoreDeviceWParentCategory->m_Multiplier == 123.45f has failed [0;39;49m ./src/profiling/test/ProfilingTests.cpp(1684): [1;31;49merror: in "ExternalProfiling/CheckCounterDirectoryRegisterCounter": check counterWCounterSet->m_Multiplier == 123.45f has failed [0;39;49m ./src/profiling/test/ProfilingTests.cpp(1708): [1;31;49merror: in "ExternalProfiling/CheckCounterDirectoryRegisterCounter": check counterWDeviceWCounterSet->m_Multiplier == 123.45f has failed [0;39;49m ./src/profiling/test/ProfilingTests.cpp(1741): [1;31;49merror: in "ExternalProfiling/CheckCounterDirectoryRegisterCounter": check anotherCounter->m_Multiplier == .00043f has failed [0;39;49m [1;31;49m*** 17 failures are detected in the test module "UnitTests" [0;39;49mmake[1]: *** [debian/rules:67: override_dh_auto_test] Error 201 make[1]: Leaving directory '/<>' make: *** [debian/rules:30: build-arch] Error 2 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 Full build logs at: https://buildd.debian.org/status/fetch.php?pkg=armnn=i386=20.08-13=1690924863=0
Bug#1037579: armnn: ftbfs with GCC-13
Note that since the upload of 20.08-13 the package now fails to build for different reasons on i386 vs arm64/armhf. I've opened https://bugs.debian.org/1042942 for i386. On arm64/armhf the bug seems to be due to a missing include in core/utils/misc/Utility.h from libarm-compute-dev. [ 2%] Building CXX object profiling/common/src/CMakeFiles/pipeCommon.dir/CommandHandlerRegistry.cpp.o cd /<>/build-area/profiling/common/src && /usr/bin/c++ -DARMCOMPUTECL_ENABLED -DARMCOMPUTENEON_ENABLED -DARMNN_DYNAMIC_BACKEND_ENABLED -DARMNN_SERIALIZER -DARMNN_SERIALIZER_SCHEMA_PATH=\"/<>/src/armnnSerializer/ArmnnSchema.fbs\" -DARMNN_TF_LITE_PARSER -DBOOST_ALL_DYN_LINK -DBOOST_ALL_NO_LIB -DDYNAMIC_BACKEND_BUILD_DIR=\"/<>/build-area\" -I/<>/include -I/<>/profiling -I/<>/profiling/common/include -I/<>/common/include -I/<>/src/profiling -I/<>/src/armnnUtils -isystem /<>/third-party -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++14 -Wall -Wextra -Werror -Wold-style-cast -Wno-missing-braces -Wconversion -Wsign-conversion -fPIC '-DDYNAMIC_BACKEND_PATHS="/usr/lib/aarch64-linux-gnu/armnn22/"' -MD -MT profiling/common/src/CMakeFiles/pipeCommon.dir/CommandHandlerRegistry.cpp.o -MF CMakeFiles/pipeCommon.dir/CommandHandlerRegistry.cpp.o.d -o CMakeFiles/pipeCommon.dir/CommandHandlerRegistry.cpp.o -c /<>/profiling/common/src/CommandHandlerRegistry.cpp In file included from /usr/include/aarch64-linux-gnu/arm_compute/core/TensorShape.h:29, from /usr/include/aarch64-linux-gnu/arm_compute/core/ITensorInfo.h:29, from /usr/include/aarch64-linux-gnu/arm_compute/core/ITensor.h:27, from /<>/src/backends/aclCommon/ArmComputeTensorUtils.hpp:10, from /<>/src/backends/aclCommon/ArmComputeTensorUtils.cpp:5: /usr/include/aarch64-linux-gnu/arm_compute/core/utils/misc/Utility.h: In function ‘bool arm_compute::utility::check_aligned(void*, size_t)’: /usr/include/aarch64-linux-gnu/arm_compute/core/utils/misc/Utility.h:194:35: error: ‘uintptr_t’ in namespace ‘std’ does not name a type 194 | return (reinterpret_cast(ptr) % alignment) == 0; | ^ /usr/include/aarch64-linux-gnu/arm_compute/core/utils/misc/Utility.h:30:1: note: ‘std::uintptr_t’ is defined in header ‘’; did you forget to ‘#include ’? 29 | #include +++ |+#include 30 | #include [ 2%] Building CXX object src/backends/backendsCommon/CMakeFiles/armnnBackendsCommon.dir/DynamicBackend.cpp.o cd /<>/build-area/src/backends/backendsCommon && /usr/bin/c++ -DARMCOMPUTECL_ENABLED -DARMCOMPUTENEON_ENABLED -DARMNN_DYNAMIC_BACKEND_ENABLED -DARMNN_SERIALIZER -DARMNN_SERIALIZER_SCHEMA_PATH=\"/<>/src/armnnSerializer/ArmnnSchema.fbs\" -DARMNN_TF_LITE_PARSER -DBOOST_ALL_DYN_LINK -DBOOST_ALL_NO_LIB -DDYNAMIC_BACKEND_BUILD_DIR=\"/<>/build-area\" -I/<>/include -I/<>/profiling -I/<>/include/armnn/backends -I/<>/src/armnn -I/<>/src/armnnUtils -I/<>/src/backends -I/<>/src/profiling -I/<>/profiling/common/include -isystem /<>/third-party -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++14 -Wall -Wextra -Werror -Wold-style-cast -Wno-missing-braces -Wconversion -Wsign-conversion -fPIC '-DDYNAMIC_BACKEND_PATHS="/usr/lib/aarch64-linux-gnu/armnn22/"' -MD -MT src/backends/backendsCommon/CMakeFiles/armnnBackendsCommon.dir/DynamicBackend.cpp.o -MF CMakeFiles/armnnBackendsCommon.dir/DynamicBackend.cpp.o.d -o CMakeFiles/armnnBackendsCommon.dir/DynamicBackend.cpp.o -c /<>/src/backends/backendsCommon/DynamicBackend.cpp make[3]: *** [src/backends/aclCommon/CMakeFiles/armnnAclCommon.dir/build.make:79: src/backends/aclCommon/CMakeFiles/armnnAclCommon.dir/ArmComputeTensorUtils.cpp.o] Error 1 make[3]: Leaving directory '/<>/build-area' make[2]: *** [CMakeFiles/Makefile2:989: src/backends/aclCommon/CMakeFiles/armnnAclCommon.dir/all] Error 2
Bug#1038339: qbittorrent: no icons after upgrade to 4.5.3
Hi, On 2023-06-18 06:30, Sam Uienn wrote: > On Sat, 17 Jun 2023 10:46:37 +0200 Emanuele Rocca wrote: > > After upgrading qbittorrent from 4.5.2 - currently in testing - to 4.5.3 > > in sid, all icons are gone. > > I've also noticed this problem on upgrade from 4.5.3-1 to 4.5.3-2 - > installing the `libqt6svg6` library restored the missing icons for me. That was it, thank you Sam. After installing libqt6svg6 the icons are now back.
Bug#1038339: qbittorrent: no icons after upgrade to 4.5.3
Hi, On 2023-06-17 04:57, Christian Marillat wrote: > 'Use icons from system theme' is set in preferences ? Yes. "Use custom UI Theme" is not set, "Use icons from system theme" is. Please find a screenshot of qt5ct attached, it looks a little weird?
Bug#1038339: qbittorrent: no icons after upgrade to 4.5.3
Hi Christian, On 2023-06-17 11:26, Christian Marillat wrote: > On 17 juin 2023 19:18, Emanuele Rocca wrote: > > Yes. "Use custom UI Theme" is not set, "Use icons from system theme" is. > > I mixed up these two options in my previous e-mail. > > Do you see icons when the second option is not set ? Nope. With qbittorrent 4.5.3-2 there are no icons regardless of whether "Use icons from system theme" is set or not.
Bug#1038162: amrhf/armel executables produced with EABI Version4 instead of 5
Package: tcc Version: 0.9.27+git20200814.62c30a4a-1 Severity: wishlist Hi, executables compiled on armhf and armel target the ARM ABI Version4. Since Debian 10 (Buster), the baseline was updated to Version 5: it would be great if tcc could target Version 5 too. ema@eniac:~ $ readelf -h /tmp/armel | grep Flags Flags: 0x4000202, Version4 EABI, ema@eniac:~ $ readelf -h /tmp/armhf | grep Flags Flags: 0x4000402, Version4 EABI,
Bug#1021292: Enabling branch protection on amd64 and arm64
Hey Moritz, On 2022-10-26 08:20, Moritz Mühlenhoff wrote: > I think this should rather be applied early after the Bookworm > release (and ideally we can also finish off the necessary testing > and add -fstack-clash-protection at least for amd64 and other archs > which are ready for it (#918914)). Can we go ahead with the dpkg patch now, any specific tests you had in mind before applying it? ema
Bug#1038868: fpc: armhf binaries should have the hard-float ELF flag set
Package: fpc
Version: 3.2.2+dfsg-21
Hi,
binaries produced by fpc on armhf currently lack the hard-float ELF
flag.
I've built the following hello world program with `fpc hello.pas`:
program Hello;
begin
writeln ('Hello, world.');
end.
The resulting ELF object looks like this, note in particular the value
of "Flags", namely "0x5000200, Version5 EABI, soft-float ABI". This
should be "0x5000400, Version5 EABI, hard-float ABI" instead.
$ readelf -h hello
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI:UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x100ec
Start of program headers: 52 (bytes into file)
Start of section headers: 231208 (bytes into file)
Flags: 0x5000200, Version5 EABI, soft-float ABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 4
Size of section headers: 40 (bytes)
Number of section headers: 10
Section header string table index: 9
Compare with a C hello world program built with `gcc hello.c`, and again
note the value of Flags: "0x5000400, Version5 EABI, hard-float ABI".
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI:UNIX - System V
ABI Version: 0
Type: DYN (Position-Independent Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x409
Start of program headers: 52 (bytes into file)
Start of section headers: 6692 (bytes into file)
Flags: 0x5000400, Version5 EABI, hard-float ABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 9
Size of section headers: 40 (bytes)
Number of section headers: 29
Additionally, the attribute "Tag_ABI_VFP_args" should be set to "VFP registers".
$ readelf -A hello
Attribute Section: aeabi
File Attributes
Tag_CPU_arch: v4T
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
And compare with the attributes in the ELF file produced by GCC:
$ readelf -A a.out
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-A"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3-D16
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_rounding: Needed
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_VFP_args: VFP registers
Tag_CPU_unaligned_access: v6
Bug#1039887: debcargo: make Test-Command configurable
Package: debcargo Version: 2.6.0-2 Severity: wishlist Hi, I'd like to have the option to use a custom Test-Command instead of /usr/share/cargo/bin/cargo-auto-test for the generated autopkgtests. The use case I have in mind is shipping a wrapper script under debian/tests/ that does some initial work to set up the test environment and *then* calls cargo-auto-test. Here's a practical example: https://salsa.debian.org/rust-team/debcargo-conf/-/commit/d8d2afe One way to do this would be a PackageOverride configuration option called 'test_command' or similar. Thanks, ema
Bug#1034856: dstat: autopkgtest regression on multiple archs: TypeError: '<' not supported between instances of 'dict' and 'int'
Hi Paul, On 2023-04-25 10:03, Paul Gevers wrote: > Your package has an autopkgtest, great. However, it fails since April 2023 > on arm64, i386, ppc64el and s390x. Can you please investigate the situation > and fix it? I copied some of the output at the bottom of this report. The reality of the situation is that dstat is fairly buggy. Still usable in many cases, but far from perfect. Unfortunately the project is not maintained upstream since several years [1], and fixing the outstanding issues is not trivial. All my hopes are now on dool, which seems to be a promising replacement and is currently being packaged [2]. ciao, ema [1] https://github.com/dstat-real/dstat/issues/170 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032875
