Bug#966417: vg: FTBFS in sid, with new elfutils
Source: vg Version: 1.25.0+ds-2 Severity: serious Hello, looks like elfutils dropped one library used by vg: # We do not provide a libebl anymore, use libdw instead. rm -f debian/tmp/usr/include/elfutils/libebl.h causing now FTBFS in sid: . ./source_me.sh && g++ -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -I/usr/include/fastahack -I/<>/vg-1.25.0+ds/include -I. -I/<>/vg-1.25.0+ds/src -I/<>/vg-1.25.0+ds/src/unittest -I/<>/vg-1.25.0+ds/src/subcommand -I/<>/vg-1.25.0+ds/include/dynamic -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/smithwaterman -I/usr/include/vcflib -I/usr/include/smithwaterman -I/usr/include/fastahack -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -Werror=return-type -std=c++14 -ggdb -g -MMD -MP -g -O2 -fdebug-prefix-map=/<>/vg-1.25.0+ds=. -fstack-protector-strong -Wformat -Werror=format-security -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -msse4.1 -fopenmp -o test/build_graph test/build_graph.cpp -lvg -L/<>/vg-1.25.0+ds/lib /<>/vg-1.25.0+ds/lib/libvgio.a -lz -lgssw -lssw -lprotobuf -lsublinearLS -ldeflate -lpthread -ljansson -lncurses -lgcsa2 -lgbwtgraph -lgbwt -ldivsufsort -ldivsufsort64 -lraptor2 -lpinchesandcacti -l3edgeconnected -lsonlib -lfml -llz4 -lstructures -lvw -lboost_program_options -lallreduce -lbdsg -lxg -lsdsl -lhandlegraph -lfastahack -lsmithwaterman -ldisorder -lvcflib -lsmithwaterman -ldisorder -lfastahack -lhts -ltabixpp -lcairo -ljansson -latomic -rdynamic -ldw -lelf -lebl -ldl -llzma -lrocksdb -lbz2 -ljemalloc /usr/bin/ld: cannot find -lebl I don't know if this patch is enough to make it build correctly, it is still building here diff -Nru vg-1.25.0+ds/debian/changelog vg-1.25.0+ds/debian/changelog --- vg-1.25.0+ds/debian/changelog 2020-07-14 15:15:28.0 +0200 +++ vg-1.25.0+ds/debian/changelog 2020-07-28 12:11:33.0 +0200 @@ -1,3 +1,9 @@ +vg (1.25.0+ds-2.1) unstable; urgency=medium + + * Fix build by not linking anymore libebl.a (Closes: #-1) + + -- Gianfranco Costamagna Tue, 28 Jul 2020 12:11:33 +0200 + vg (1.25.0+ds-2) unstable; urgency=medium * Restrict architectures to build for. Closes: #964039. diff -Nru vg-1.25.0+ds/debian/patches/use_packaged_elfutils vg-1.25.0+ds/debian/patches/use_packaged_elfutils --- vg-1.25.0+ds/debian/patches/use_packaged_elfutils 2020-02-03 13:26:00.0 +0100 +++ vg-1.25.0+ds/debian/patches/use_packaged_elfutils 2020-07-28 12:11:25.0 +0200 @@ -7,7 +7,7 @@ # We want to link against the elfutils libraries -LD_LIB_FLAGS += -ldwfl -ldw -ldwelf -lelf -lebl -+LD_LIB_FLAGS += -ldw -lelf -lebl ++LD_LIB_FLAGS += -ldw -lelf # We get OpenMP the normal way, using whatever the compiler knows about CXXFLAGS += -fopenmp
Bug#966340: cpp-10 10.2.0-3 requires the removal of llvm-9
control: tags -1 unreproducible control: close -1 dpkg -l |egrep "9.0.1|10.2.0" ii clang-91:9.0.1-13 amd64C, C++ and Objective-C compiler ii clang-tidy-9 1:9.0.1-13 amd64clang-based C++ linter tool ii clang-tools-9 1:9.0.1-13 amd64clang-based tools for C/C++ developments ii cpp-10 10.2.0-3amd64GNU C preprocessor ii g++-10 10.2.0-3amd64GNU C++ compiler ii gcc-10 10.2.0-3amd64GNU C compiler ii gcc-10-base:amd64 10.2.0-3amd64GCC, the GNU Compiler Collection (base package) ii lib32gcc-s110.2.0-3amd64GCC support library (32 bit Version) ii lib32stdc++6 10.2.0-3amd64GNU Standard C++ Library v3 (32 bit Version) ii libasan6:amd64 10.2.0-3amd64 AddressSanitizer -- a fast memory error detector ii libatomic1:amd64 10.2.0-3amd64support library providing __atomic built-in functions ii libcc1-0:amd64 10.2.0-3amd64GCC cc1 plugin for GDB ii libclang-common-9-dev 1:9.0.1-13 amd64Clang library - Common development package ii libclang-cpp9 1:9.0.1-13 amd64C++ interface to the Clang library ii libclang1-91:9.0.1-13 amd64C interface to the Clang library ii libgcc-10-dev:amd6410.2.0-3amd64GCC support library (development files) ii libgcc-s1:amd6410.2.0-3amd64GCC support library ii libgomp1:amd64 10.2.0-3amd64GCC OpenMP (GOMP) support library ii libitm1:amd64 10.2.0-3amd64GNU Transactional Memory Library ii libllvm9:amd64 1:9.0.1-13 amd64Modular compiler and toolchain technologies, runtime library ii liblsan0:amd64 10.2.0-3amd64 LeakSanitizer -- a memory leak detector (runtime) ii libobjc4:amd64 10.2.0-3amd64Runtime library for GNU Objective-C applications ii libquadmath0:amd64 10.2.0-3amd64GCC Quad-Precision Math Library ii libstdc++-10-dev:amd64 10.2.0-3amd64GNU Standard C++ Library v3 (development files) ii libstdc++6:amd64 10.2.0-3amd64GNU Standard C++ Library v3 ii libtsan0:amd64 10.2.0-3amd64 ThreadSanitizer -- a Valgrind-based detector of data races (runtime) ii libubsan1:amd6410.2.0-3amd64UBSan -- undefined behaviour sanitizer (runtime) ii llvm-9 1:9.0.1-13 amd64Modular compiler and toolchain technologies ii llvm-9-runtime 1:9.0.1-13 amd64Modular compiler and toolchain technologies, IR interpreter I can install all of them correctly in a clean sid chroot. you might have some packages coming from experimental or somewhere else, but unless you tell us *what* wants to remove *what*, with an example of apt removal log, we can't really do anything more. Please reopen if this is still an issue and you have some information for us to reproduce it. (also, some ongoing transition in sid might be the source of this issue, in this case, the bug is invalid per definition). G. G. On Mon, 27 Jul 2020 11:04:05 +0300 =?utf-8?B?0KHQtdGA0LPQtdC5INCk0ZHQtNC+0YDQvtCy?= wrote: > Package: cpp-10 > Version: 10.2.0-3 > Severity: normal > Tags: a11y > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads) > Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages cpp-10 depends on: > ii gcc-10-base 10.1.0-6 > ii libc62.31-2 > ii libgmp10 2:6.2.0+dfsg-6 > ii libisl22 0.22.1-1 > ii libmpc3 1.1.0-1 > ii libmpfr6 4.1.0-3 > ii libzstd1 1.4.5+dfsg-3 > ii zlib1g 1:1.2.11.dfsg-2 > > cpp-10 recommends no packages. > > Versions of packages cpp-10 suggests: > pn gcc-10-locales > > -- no debconf information > > Upgrading off package cpp-10 from 10.1.0-6 to 10.2.0-3 > requires the removal of packages: > > clang 1:9.0-49.1 > clang-91:9.0.1-13 > clang-tidy 1:9.0-49.1 > clang-tidy-9 1:9.0.1-13 > clang-tools-9 1:9.0.1-13 > libobjc-9-dev 9.3.0-16 > libobjc4 10.1.0-6 > >
Bug#966182: virtualbox FTBFS on amd64 with gsoap 2.8.104
control: forwarded -1 https://www.virtualbox.org/ticket/19634 On Fri, 24 Jul 2020 14:30:28 +0300 Adrian Bunk wrote: > Source: virtualbox > Version: 6.1.12-dfsg-6 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/fetch.php?pkg=virtualbox=amd64=6.1.12-dfsg-6%2Bb1=1595581404=0 > > ... > /<>/src/VBox/Main/webservice/vboxweb.cpp: In function ???void > doQueuesLoop()???: > /<>/src/VBox/Main/webservice/vboxweb.cpp:947: error: expression > cannot be used as a function > 947 | if (soap_socket_errno(soap.master) == SOAP_EINTR) > | > kmk: *** [/usr/share/kBuild/footer-pass2-compiling-targets.kmk:277: > /<>/out/obj/vboxwebsrv/vboxweb.o] Error 1 will fix thanks
Bug#956822: xpra: FTBFS on armel and armhf
and this is the correct link https://autopkgtest.ubuntu.com/packages/xpra G.
Bug#956822: xpra: FTBFS on armel and armhf
Hello, > xpra failed to build on armel and armhf. See > https://buildd.debian.org/status/fetch.php?pkg=xpra=armel=3.0.8%2Bdfsg1-1=1586872010=0 based on upstream suggestion, I removed the patch, and let the program do its job, by adding the dependencies on xorg and xvfb (this one can probably be installed just on arm) I also added xvfb on debian/tests/control, and the autopkgtest went green also on armhf! --- xpra-3.0.9+dfsg1/debian/changelog 2020-04-20 02:47:55.0 +0200 +++ xpra-3.0.9+dfsg1/debian/changelog 2020-07-21 18:49:46.0 +0200 @@ -1,3 +1,11 @@ +xpra (3.0.9+dfsg1-1.1) unstable; urgency=medium + + * Add xorg and xvfb to build and test deps and comment xorg patch +- This should help detection of the right backend on arm* and elsewhere. + see https://xpra.org/trac/ticket/2737 and Debian bug: #956822 + + -- Gianfranco Costamagna Tue, 21 Jul 2020 18:49:46 +0200 + xpra (3.0.9+dfsg1-1) unstable; urgency=medium * New upstream release. diff -Nru xpra-3.0.9+dfsg1/debian/control xpra-3.0.9+dfsg1/debian/control --- xpra-3.0.9+dfsg1/debian/control 2020-04-14 11:52:20.0 +0200 +++ xpra-3.0.9+dfsg1/debian/control 2020-07-21 18:49:46.0 +0200 @@ -28,6 +28,8 @@ ,python3-all-dev ,python3-cairo-dev ,python-gi-dev +,xorg +,xvfb Rules-Requires-Root: no Homepage: http://xpra.org/ Vcs-Git: https://salsa.debian.org/debian/xpra.git diff -Nru xpra-3.0.9+dfsg1/debian/patches/series xpra-3.0.9+dfsg1/debian/patches/series --- xpra-3.0.9+dfsg1/debian/patches/series 2020-03-26 11:08:09.0 +0100 +++ xpra-3.0.9+dfsg1/debian/patches/series 2020-07-21 18:49:35.0 +0200 @@ -1,7 +1,7 @@ ## Fixes build-hurd.patch -fix-xvfb-path.patch +#fix-xvfb-path.patch ## Misc. buildinfo.patch diff -Nru xpra-3.0.9+dfsg1/debian/tests/control xpra-3.0.9+dfsg1/debian/tests/control --- xpra-3.0.9+dfsg1/debian/tests/control 2019-04-10 03:39:32.0 +0200 +++ xpra-3.0.9+dfsg1/debian/tests/control 2020-07-21 18:49:46.0 +0200 @@ -3,6 +3,6 @@ #, isolation-container # ,isolation-machine # ,needs-recommends -Depends: @ ,coreutils ,procps ,x11-apps ,x11-xserver-utils ,xauth +Depends: @ ,coreutils ,procps ,x11-apps ,x11-xserver-utils ,xauth, xvfb # ,@builddeps@ # ,x11-common you can see autopkgtest results here https://autopkgtest.ubuntu.com/packages/xpra/groovy/ I know adding xorg and xvfb is far from ideal, but I agree that the autodetection system that upstream provides us should work, and eventually be fixed if something is not correct, rather than patching it manually downstream. I don't plan to NMU this change, because I still feel not too confident on it G.
Bug#963347: gst-plugins-ugly1.0: FTBFS: Can't locate Regexp/Assemble.pm in @INC
control: fixed -1 1.17.2-1 On Tue, 21 Jul 2020 15:54:47 +0200 Jonas Smedegaard wrote: > Package: cdbs > Followup-For: Bug #963347 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Control: affects -1 = > Control: reassign -1 src:gst-plugins-ugly1.0 1.16.2-2 > > cdbs provides templates for packages to include. > gst-plugins-ugly1.0 also build-depends on automake > even though it is called through a cdbs template. > > cdbs offers an optional mechanism to help resolve build-dependencies, > but does not itself build-depend on the tools used in its templates. > If that was the case, then cdbs would depend on openjdk and php-dev > and cmake and a lot of other tools, which would not be helpful. > > Concretely, src:gst-plugins-ugly1.0 uses the rules/utils.mk template > and need to either a) declare needed build-dependencies (which indeed has > changed over time¹), or supress unused parts (notably licensecheck), > or stop include /usr/share/cdbs/1/rules/utils.mk. > > Hope that helps, > yep, it helped thanks! in the meanwhile, the package in experimental moved to debhelper, so this bug is "fixed" in another way... G.
Bug#963347: reassigning bug to src:cdbs
control: reassign -1 src:cdbs control: affects -1 src:gst-plugins-ugly1.0 control: found -1 0.4.162 Hello, looks like the new cdbs is using features of libregexp-assemble-perl without having a runtime dependency on it. This makes gst-plugins-ugly1.0 FTBFS with the following error: > debian/rules build > CDBS WARNING: copyright-check disabled - touch debian/copyright_hints to > enable. > test -x debian/rules > mkdir -p "." > CDBS WARNING:DEB_DH_INSTALL_ARGS is deprecated since 0.4.85 > CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85 > CDBS WARNING:DEB_DH_BUILDDEB_ARGS is deprecated since 0.4.85 > > Scanning upstream source for new/changed copyright notices... > > set -e; find -- * -type f -regextype posix-extended '!' -regex '^(.+\.(|)|)$' > -regex '^.+\.(|)$' -print0 | perl -0 /usr/lib/cdbs/license-miner > Can't locate Regexp/Assemble.pm in @INC (you may need to install the > Regexp::Assemble module) (@INC contains: /etc/perl > /usr/local/lib/x86_64-linux-gnu/perl/5.30.3 /usr/local/share/perl/5.30.3 > /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 > /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.30 > /usr/share/perl/5.30 /usr/local/lib/site_perl) at /usr/lib/cdbs/license-miner > line 13. > BEGIN failed--compilation aborted at /usr/lib/cdbs/license-miner line 13. > make: *** [/usr/share/cdbs/1/rules/utils.mk:143: debian/copyright_newhints] > Error 2
Bug#965926: botch: FTBFS in sid
Source: botch Version: 0.22-4 Severity: serious Hello, the same that happened to other ocaml packages is now happening to botch too. If the omission is intentional or no other helper can take care of this consider adding the paths to debian/not-installed. dh_dwz dwz: debian/botch/usr/bin/botch-annotate-strong: DWARF version 0 unhandled dwz: debian/botch/usr/bin/botch-bin2src: DWARF version 0 unhandled dwz: debian/botch/usr/bin/botch-build-fixpoint: DWARF version 0 unhandled dwz: debian/botch/usr/bin/botch-buildcheck-more-problems: DWARF version 0 unhandled dwz: debian/botch/usr/bin/botch-buildgraph2srcgraph: DWARF version 0 unhandled dwz: debian/botch/usr/bin/botch-calculate-fas: DWARF version 0 unhandled dwz: debian/botch/usr/bin/botch-clean-repository: DWARF version 0 unhandled dwz: debian/botch/usr/bin/botch-collapse-srcgraph: DWARF version 0 unhandled dwz: debian/botch/usr/bin/botch-create-graph: DWARF version 0 unhandled dwz: debian/botch/usr/bin/botch-distcheck-more-problems: DWARF version 0 unhandled dwz: debian/botch/usr/bin/botch-find-fvs: DWARF version 0 unhandled dwz: debian/botch/usr/bin/botch-optuniv: DWARF version 0 unhandled dwz: debian/botch/usr/bin/botch-partial-order: DWARF version 0 unhandled dwz: debian/botch/usr/bin/botch-print-stats: DWARF version 0 unhandled dwz: debian/botch/usr/bin/botch-src2bin: DWARF version 0 unhandled dwz: Too few files for multifile optimization dh_dwz: error: dwz -mdebian/botch/usr/lib/debug/.dwz/x86_64-linux-gnu/botch.debug -M/usr/lib/debug/.dwz/x86_64-linux-gnu/botch.debug -- debian/botch/usr/bin/botch-annotate-strong debian/botch/usr/bin/botch-bin2src debian/botch/usr/bin/botch-build-fixpoint debian/botch/usr/bin/botch-buildcheck-more-problems debian/botch/usr/bin/botch-buildgraph2srcgraph debian/botch/usr/bin/botch-calculate-fas debian/botch/usr/bin/botch-clean-repository debian/botch/usr/bin/botch-collapse-srcgraph debian/botch/usr/bin/botch-create-graph debian/botch/usr/bin/botch-distcheck-more-problems debian/botch/usr/bin/botch-find-fvs debian/botch/usr/bin/botch-optuniv debian/botch/usr/bin/botch-partial-order debian/botch/usr/bin/botch-print-stats debian/botch/usr/bin/botch-src2bin returned exit code 1 make: *** [debian/rules:7: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 I still don't understand if the problem is in binutils or somewhere else G.
Bug#965372: ocaml-mccs: FTBFS in sid
sr/lib/x86_64-linux-gnu/blas/libblas.so to provide /usr/lib/x86_64-linux-gnu/libblas.so (libblas.so-x86_64-linux-gnu) in auto mode Setting up librbio2:amd64 (1:5.7.2+dfsg-1) ... Setting up libfile-stripnondeterminism-perl (1.9.0-1) ... Setting up libamd2:amd64 (1:5.7.2+dfsg-1) ... Setting up liblapack3:amd64 (3.9.0-2) ... update-alternatives: using /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3 to provide /usr/lib/x86_64-linux-gnu/liblapack.so.3 (liblapack.so.3-x86_64-linux-gnu) in auto mode Setting up libncurses-dev:amd64 (6.2-1) ... Setting up libgmp-dev:amd64 (2:6.2.0+dfsg-6) ... Setting up libcolamd2:amd64 (1:5.7.2+dfsg-1) ... Setting up libtool (2.4.6-14) ... Setting up libfindlib-ocaml (1.8.1-1+b1) ... Setting up m4 (1.4.18-4) ... Setting up libcamd2:amd64 (1:5.7.2+dfsg-1) ... Setting up libmongoose2:amd64 (1:5.7.2+dfsg-1) ... Setting up libglpk40:amd64 (4.65-2) ... Setting up ocaml-findlib (1.8.1-1+b1) ... Setting up liblapack-dev:amd64 (3.9.0-2) ... update-alternatives: using /usr/lib/x86_64-linux-gnu/lapack/liblapack.so to provide /usr/lib/x86_64-linux-gnu/liblapack.so (liblapack.so-x86_64-linux-gnu) in auto mode Setting up libcroco3:amd64 (0.6.13-1) ... Setting up autoconf (2.69-11.1) ... Setting up dh-strip-nondeterminism (1.9.0-1) ... Setting up dwz (0.13-5) ... Setting up groff-base (1.22.4-5) ... Setting up libklu1:amd64 (1:5.7.2+dfsg-1) ... Setting up libccolamd2:amd64 (1:5.7.2+dfsg-1) ... Setting up libncurses5-dev:amd64 (6.2-1) ... Setting up libcholmod3:amd64 (1:5.7.2+dfsg-1) ... Setting up automake (1:1.16.2-3) ... update-alternatives: using /usr/bin/automake-1.16 to provide /usr/bin/automake (automake) in auto mode Setting up libspqr2:amd64 (1:5.7.2+dfsg-1) ... Setting up gettext (0.19.8.1-10) ... Setting up man-db (2.9.3-2) ... Building database of manual pages ... Setting up intltool-debian (0.35.0+20060710.5) ... Setting up libumfpack5:amd64 (1:5.7.2+dfsg-1) ... Setting up libsuitesparse-dev:amd64 (1:5.7.2+dfsg-1) ... Setting up po-debconf (1.0.21) ... Setting up libglpk-dev:amd64 (4.65-2) ... Setting up dh-autoreconf (19) ... Setting up ocaml-interp (4.08.1-8) ... Setting up ocaml-nox (4.08.1-8) ... Setting up ocaml-compiler-libs (4.08.1-8) ... Setting up debhelper (13.2) ... Setting up libextlib-ocaml-dev (1.7.7-1) ... Setting up libcudf-ocaml-dev (0.7-5+b3) ... Processing triggers for libc-bin (2.31-1) ... -> Finished parsing the build-deps [0mI: Copying back the cached apt archive contents[0m [0mI: new cache content 'libcxsparse3_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: new cache content 'libcholmod3_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: new cache content 'libklu1_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: new cache content 'libcudf-ocaml-dev_0.7-5+b3_amd64.deb' added[0m [0mI: new cache content 'libmongoose2_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: new cache content 'libgfortran5_10.1.0-6_amd64.deb' added[0m [0mI: new cache content 'liblapack-dev_3.9.0-2_amd64.deb' added[0m [0mI: new cache content 'libextlib-ocaml_1.7.7-1_amd64.deb' added[0m [0mI: new cache content 'libmetis5_5.1.0.dfsg-7_amd64.deb' added[0m [0mI: new cache content 'libsuitesparse-dev_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: new cache content 'libcamd2_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: new cache content 'libldl2_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: new cache content 'libbtf1_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: new cache content 'libccolamd2_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: new cache content 'libcolamd2_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: new cache content 'libglpk-dev_4.65-2_amd64.deb' added[0m [0mI: new cache content 'libextlib-ocaml-dev_1.7.7-1_amd64.deb' added[0m [0mI: new cache content 'libblas3_3.9.0-2_amd64.deb' added[0m [0mI: new cache content 'librbio2_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: new cache content 'libsuitesparseconfig5_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: new cache content 'ocaml-dune_2.1.3-2_amd64.deb' added[0m [0mI: new cache content 'libglpk40_4.65-2_amd64.deb' added[0m [0mI: new cache content 'liblapack3_3.9.0-2_amd64.deb' added[0m [0mI: new cache content 'libblas-dev_3.9.0-2_amd64.deb' added[0m [0mI: new cache content 'libspqr2_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: new cache content 'libgraphblas3_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: new cache content 'libamd2_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: new cache content 'libumfpack5_1%3a5.7.2+dfsg-1_amd64.deb' added[0m [0mI: Building the package[0m [0mI: Running cd /build/ocaml-mccs-1.1+11/ && env PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage -us -uc [0m dpkg-buildpackage: info: source package ocaml-mccs dpkg-buildpackage: info: source version 1.1+11-1build2 dpkg-buildpackage: info: source distribution groovy dpkg-buildpackage: info: source changed by Gianfranco Costamagna dpkg-source --before-build . dpkg-buildpackage: info: host arch
Bug#965215: dune-common: please lower parallel builds
Hello Ansgar On Sat, 18 Jul 2020 10:09:34 +0200 Ansgar wrote: > On Fri, 2020-07-17 at 20:03 +0200, Gianfranco Costamagna wrote: > > Hello, dune-common is FTBFS in Ubuntu and on systems where there is not > > enough ram, because of OOM killer. > > The package builds in Debian. Maybe Canonical Ltd should configure > their buildd network with similar parameters as Debian (e.g. similar > amount of memory per task)? > > > Can you please consider adding --max-parallel=3 to dh invocation? > > > > People might want to rebuild on their system without having to swap during > > the build process. > > That might require parallel=1 depending on the system anyway. I > usually build with parallel=8 without problems, so I don't want to > limit it to 3. mmm what about doing something like this? ifeq ($(shell dpkg-vendor --is Ubuntu && echo yes),yes) dh $@ --builddirectory=build --max-parallel=3 else dh $@ --builddirectory=build endif this will make the package build fine in Ubuntu too, hopefully the ram will eventually increase, but as short term it will make the package syncable again :) thanks! Gianfranco
Bug#965215: dune-common: please lower parallel builds
Source: dune-common Version: 2.7.0-5 Severity: normal tags: patch Hello, dune-common is FTBFS in Ubuntu and on systems where there is not enough ram, because of OOM killer. Can you please consider adding --max-parallel=3 to dh invocation? People might want to rebuild on their system without having to swap during the build process. BTW if you don't want to do it in Debian, can you please consider doing something like this? +ifeq ($(shell dpkg-vendor --is Ubuntu && echo yes),yes) +DEB_BUILD_OPTIONS=parallel=3 +endif thanks! Gianfranco
Bug#965214: dune-grid: please lower parallel builds
Source: dune-grid Version: 2.7.0-2 Severity: normal tags: patch Hello, dune-grid is FTBFS in Ubuntu and on systems where there is not enough ram, because of OOM killer. Can you please consider adding --max-parallel=3 to dh invocation? People might want to rebuild on their system without having to swap during the build process. thanks!
Bug#964790: libmicrohttpd: please make autopkgtests cross-friendly
hello, no need to do an upload just for this... feel free to add on the next planned release! thanks for all! G. Il mercoledì 15 luglio 2020, 16:50:06 CEST, Bertrand Marc ha scritto: severity 964790 wishlist thanks Hi Gianfranco, This looks fine to me, please go ahead. Cheers, Bertrand
Bug#964044: mrpt: FTBFS: test failure
On Fri, 17 Jul 2020 08:41:13 +0200 Gianfranco Costamagna wrote: > Hello again > > I'm deleting the upload, looks like the new ftdi broke configure script. > > see the attached build log > > G. reuploaded, I gave ftdi a patch, and an upload is coming shortly G.
Bug#965177: libftdi: ships broken cmake file
Hello,
I'm attaching a tested patch that also adds a new autopkgtest that spots this
kind of failures in the future.
(the diff fixes also #965175)
G.
diff -Nru libftdi1-1.5/debian/changelog libftdi1-1.5/debian/changelog
--- libftdi1-1.5/debian/changelog 2020-07-14 23:32:06.0 +0200
+++ libftdi1-1.5/debian/changelog 2020-07-17 08:57:55.0 +0200
@@ -1,3 +1,11 @@
+libftdi1 (1.5-4) unstable; urgency=medium
+
+ * Mark one symbol as optional, disappearing on ppc64el with -O3 (Closes:
#965175)
+ * Add again the LIBDIR in rules file to make the cmake script happy (Closes:
#965177)
+ * Add an autopkgtest to test cmake scripts
+
+ -- Gianfranco Costamagna Fri, 17 Jul 2020
08:57:55 +0200
+
libftdi1 (1.5-3) unstable; urgency=medium
* Redirect autopkgtests stderr output to stdout.
diff -Nru libftdi1-1.5/debian/libftdipp1-3.symbols
libftdi1-1.5/debian/libftdipp1-3.symbols
--- libftdi1-1.5/debian/libftdipp1-3.symbols2020-06-27 14:53:49.0
+0200
+++ libftdi1-1.5/debian/libftdipp1-3.symbols2020-07-17 08:57:46.0
+0200
@@ -105,7 +105,7 @@
_ZNK4Ftdi4List6rbeginEv@Base 1.5
_ZNK4Ftdi7Context20get_usb_read_timeoutEv@Base 1.5
_ZNK4Ftdi7Context21get_usb_write_timeoutEv@Base 1.5
- _ZNSt7__cxx1110_List_baseIN4Ftdi7ContextESaIS2_EE8_M_clearEv@Base 1.5
+ (optional)_ZNSt7__cxx1110_List_baseIN4Ftdi7ContextESaIS2_EE8_M_clearEv@Base
1.5
_ZTIN5boost6detail15sp_counted_baseE@Base 1.5
_ZTIN5boost6detail17sp_counted_impl_pIN4Ftdi4List7PrivateEEE@Base 1.5
_ZTIN5boost6detail17sp_counted_impl_pIN4Ftdi6Eeprom7PrivateEEE@Base 1.5
diff -Nru libftdi1-1.5/debian/rules libftdi1-1.5/debian/rules
--- libftdi1-1.5/debian/rules 2020-07-13 11:23:42.0 +0200
+++ libftdi1-1.5/debian/rules 2020-07-17 08:57:55.0 +0200
@@ -11,6 +11,7 @@
override_dh_auto_configure:
dh_auto_configure --builddirectory=build-main -- \
-DBUILD_TESTS=ON \
+ -DCMAKE_INSTALL_LIBDIR="/usr/lib/$(DEB_HOST_MULTIARCH)" \
-DDOCUMENTATION:BOOL=ON \
-DEXAMPLES:BOOL=ON \
-DFTDIPP:BOOL=ON \
@@ -19,6 +20,7 @@
for v in $(PY3VERS) ; do \
dh_auto_configure --builddirectory=build-python$$v -- \
-DBUILD_TESTS=OFF \
+ -DCMAKE_INSTALL_LIBDIR="/usr/lib/$(DEB_HOST_MULTIARCH)"
\
-DDOCUMENTATION:BOOL=OFF \
-DEXAMPLES:BOOL=OFF \
-DFTDIPP:BOOL=ON \
diff -Nru libftdi1-1.5/debian/tests/control libftdi1-1.5/debian/tests/control
--- libftdi1-1.5/debian/tests/control 2020-07-12 14:45:44.0 +0200
+++ libftdi1-1.5/debian/tests/control 2020-07-17 08:57:55.0 +0200
@@ -1,2 +1,5 @@
Tests: test-libftdi1
Depends: build-essential, libftdi1-dev, libboost-test-dev, pkg-config
+
+Tests: test-libftdi1-cmake
+Depends: build-essential, libftdi1-dev, libboost-test-dev, cmake
diff -Nru libftdi1-1.5/debian/tests/test-libftdi1-cmake
libftdi1-1.5/debian/tests/test-libftdi1-cmake
--- libftdi1-1.5/debian/tests/test-libftdi1-cmake 1970-01-01
01:00:00.0 +0100
+++ libftdi1-1.5/debian/tests/test-libftdi1-cmake 2020-07-17
08:57:55.0 +0200
@@ -0,0 +1,38 @@
+#!/bin/sh
+
+set -e
+
+WORKDIR=$(mktemp -d)
+cat << EOF > $WORKDIR/CMakeLists.txt
+cmake_minimum_required(VERSION 3.16)
+project(test)
+find_package(LibFTDI1)
+
+message(STATUS "Include directories: " \${LIBFTDI_INCLUDE_DIRS})
+message(STATUS "Link directories: " \${LIBFTDI_LIBRARY_DIRS})
+message(STATUS "Libraries: " \${LIBFTDI_LIBRARIES})
+
+add_library(imp_ftdi INTERFACE IMPORTED)
+set_target_properties(imp_ftdi
+ PROPERTIES
+ INTERFACE_INCLUDE_DIRECTORIES "\${LIBFTDI_INCLUDE_DIRS}"
+ INTERFACE_LINK_DIRECTORIES "\${LIBFTDI_LIBRARY_DIRS}"
+ INTERFACE_LINK_LIBRARIES "\${LIBFTDI_LIBRARIES}"
+ )
+
+add_executable(test-libftdi1-cmake basic.cpp baudrate.cpp)
+include_directories("\${LIBFTDI_INCLUDE_DIRS}")
+target_link_libraries(test-libftdi1-cmake PRIVATE imp_ftdi
boost_unit_test_framework)
+EOF
+
+trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
+
+cp test/basic.cpp test/baudrate.cpp $WORKDIR
+cd $WORKDIR
+cmake .
+make VERBOSE=1
+
+echo "build: OK"
+[ -x $WORKDIR/test-libftdi1-cmake ]
+$WORKDIR/test-libftdi1-cmake 2>&1
+echo "run: OK"
Bug#965177: libftdi: ships broken cmake file
Hello again:
This is an example of cmake test file that might help in the future detecting
such issues:
(stolen and adapted from mrpt)
cat ../CMakeLists.txt
cmake_minimum_required(VERSION 3.16)
project(test)
find_package(LibFTDI1)
message("Include directories: " ${LIBFTDI_INCLUDE_DIRS})
message("Link directories: " ${LIBFTDI_LIBRARY_DIRS})
message("Libraries: " ${LIBFTDI_LIBRARIES})
add_library(imp_ftdi INTERFACE IMPORTED)
set_target_properties(imp_ftdi
PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "${LIBFTDI_INCLUDE_DIRS}"
INTERFACE_LINK_DIRECTORIES "${LIBFTDI_LIBRARY_DIRS}"
INTERFACE_LINK_LIBRARIES "${LIBFTDI_LIBRARIES}"
)
add_executable(main main.c)
target_link_libraries(main PRIVATE imp_ftdi)
$ cmake ..
Include directories: /usr/include/libftdi1
Link directories: lib/x86_64-linux-gnu
Libraries: ftdi1/usr/lib/x86_64-linux-gnu/libusb-1.0.so
-- Configuring done
CMake Error in CMakeLists.txt:
Target "imp_ftdi" contains relative path in its INTERFACE_LINK_DIRECTORIES:
"lib/x86_64-linux-gnu"
CMake Error in CMakeLists.txt:
Target "imp_ftdi" contains relative path in its INTERFACE_LINK_DIRECTORIES:
"lib/x86_64-linux-gnu"
-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.
and this is the patch that fixes the issue:
diff -Nru libftdi1-1.5/debian/changelog libftdi1-1.5/debian/changelog
--- libftdi1-1.5/debian/changelog 2020-07-17 08:57:55.0 +0200
+++ libftdi1-1.5/debian/changelog 2020-07-17 09:19:25.0 +0200
@@ -1,3 +1,9 @@
+libftdi1 (1.5-3.1) unstable; urgency=medium
+
+ * Add again the LIBDIR in rules file to make the cmake script happy (Closes:
#-1)
+
+ -- Gianfranco Costamagna Fri, 17 Jul 2020
09:19:25 +0200
+
libftdi1 (1.5-3ubuntu1) groovy; urgency=medium
* Mark one symbol as optional, disappearing on ppc64el with -O3
diff -Nru libftdi1-1.5/debian/rules libftdi1-1.5/debian/rules
--- libftdi1-1.5/debian/rules 2020-07-13 11:23:42.0 +0200
+++ libftdi1-1.5/debian/rules 2020-07-17 09:19:25.0 +0200
@@ -11,6 +11,7 @@
override_dh_auto_configure:
dh_auto_configure --builddirectory=build-main -- \
-DBUILD_TESTS=ON \
+ -DCMAKE_INSTALL_LIBDIR="/usr/lib/$(DEB_HOST_MULTIARCH)" \
-DDOCUMENTATION:BOOL=ON \
-DEXAMPLES:BOOL=ON \
-DFTDIPP:BOOL=ON \
@@ -19,6 +20,7 @@
for v in $(PY3VERS) ; do \
dh_auto_configure --builddirectory=build-python$$v -- \
-DBUILD_TESTS=OFF \
+ -DCMAKE_INSTALL_LIBDIR="/usr/lib/$(DEB_HOST_MULTIARCH)"
\
-DDOCUMENTATION:BOOL=OFF \
-DEXAMPLES:BOOL=OFF \
-DFTDIPP:BOOL=ON \
Bug#965175: libftdi1: please mark one symbol as optional
Source: libftdi1 Version: 1.5-3 Severity: normal tags: patch Hello, there is one symbol disappearing when libftdi1 is built with -O3 on ppc64el. Can you please mark it as optional? thanks --- debian/libftdipp1-3.symbols (libftdipp1-3_1.5-3_ppc64el) +++ dpkg-gensymbolsJ34vm1 2020-07-15 05:14:42.195395523 + @@ -105,7 +105,7 @@ _ZNK4Ftdi4List6rbeginEv@Base 1.5 _ZNK4Ftdi7Context20get_usb_read_timeoutEv@Base 1.5 _ZNK4Ftdi7Context21get_usb_write_timeoutEv@Base 1.5 - _ZNSt7__cxx1110_List_baseIN4Ftdi7ContextESaIS2_EE8_M_clearEv@Base 1.5 +#MISSING: 1.5-3# _ZNSt7__cxx1110_List_baseIN4Ftdi7ContextESaIS2_EE8_M_clearEv@Base 1.5 _ZTIN5boost6detail15sp_counted_baseE@Base 1.5 _ZTIN5boost6detail17sp_counted_impl_pIN4Ftdi4List7PrivateEEE@Base 1.5 _ZTIN5boost6detail17sp_counted_impl_pIN4Ftdi6Eeprom7PrivateEEE@Base 1.5 G.
Bug#964044: mrpt: FTBFS: test failure
Hello,
> which is not yet released as 2.0.5, and which you can include as a
> patch if you want to go on with the ros-geometry2 transition.
>
Since you are the maintainer, I'm uploading in deferred/1 your patch, refreshed
in some parts to apply to
the current 2.0.4 (and removing the rules part, since we can't patch with quilt
debian directory)
I'm attaching the diff that will go in unstable in ~24h
I didn't use NMU as notation, but a "team upload" since the patch comes from
you :)
let me know if this is good, so I can speed it up and let it go in sid today!
G.
diff -Nru mrpt-2.0.4/debian/changelog mrpt-2.0.4/debian/changelog
--- mrpt-2.0.4/debian/changelog 2020-06-20 17:24:00.0 +0200
+++ mrpt-2.0.4/debian/changelog 2020-07-17 08:14:20.0 +0200
@@ -1,3 +1,11 @@
+mrpt (1:2.0.4-2) unstable; urgency=medium
+
+ * Team upload
+ * debian/patches/e84511500276d38d3eeff0b220e8d45e0d74fc93.patch:
+- cherry-pick upstream "fix" for a failing test (Closes: #964044).
+
+ -- Gianfranco Costamagna Fri, 17 Jul 2020
08:14:20 +0200
+
mrpt (1:2.0.4-1) unstable; urgency=medium
* New version of upstream sources.
diff -Nru
mrpt-2.0.4/debian/patches/e84511500276d38d3eeff0b220e8d45e0d74fc93.patch
mrpt-2.0.4/debian/patches/e84511500276d38d3eeff0b220e8d45e0d74fc93.patch
--- mrpt-2.0.4/debian/patches/e84511500276d38d3eeff0b220e8d45e0d74fc93.patch
1970-01-01 01:00:00.0 +0100
+++ mrpt-2.0.4/debian/patches/e84511500276d38d3eeff0b220e8d45e0d74fc93.patch
2020-07-17 08:14:20.0 +0200
@@ -0,0 +1,55 @@
+From e84511500276d38d3eeff0b220e8d45e0d74fc93 Mon Sep 17 00:00:00 2001
+From: Jose Luis Blanco Claraco
+Date: Thu, 2 Jul 2020 23:53:34 +0200
+Subject: [PATCH] give up with the problematic unit test if building a Debian
+ package
+
+---
+ doc/doxygen-pages/changeLog_doc.h | 4
+ libs/apps/src/RawlogGrabberApp_unittest.cpp | 10 ++
+ packaging/debian/rules | 2 ++
+ 3 files changed, 16 insertions(+)
+
+Index: mrpt-2.0.4/doc/doxygen-pages/changeLog_doc.h
+===
+--- mrpt-2.0.4.orig/doc/doxygen-pages/changeLog_doc.h
mrpt-2.0.4/doc/doxygen-pages/changeLog_doc.h
+@@ -47,6 +47,10 @@
+ - Fix: mrpt::maps::CPointsMapXYZI::setFromPCLPointCloudXYZI() was using a
non-existing method.
+ - Fix: mrpt::nav::PlannerSimple2D did not honored maximum path length
correctly.
+ - Fix race condition in CGenericCamera_AVI unit test.
++- Deprecations:
++ - mrpt::system::TParameters is now deprecated.
++- BUG FIXES:
++ - Avoid crash in camera-calib app when clicking "Close" while capturing a
live video.
+
+ --
+ # Version 2.0.3: Released May 13, 2020
+Index: mrpt-2.0.4/libs/apps/src/RawlogGrabberApp_unittest.cpp
+===
+--- mrpt-2.0.4.orig/libs/apps/src/RawlogGrabberApp_unittest.cpp
mrpt-2.0.4/libs/apps/src/RawlogGrabberApp_unittest.cpp
+@@ -13,6 +13,7 @@
+ #include
+ #include
+ #include
++#include
+ #include
+
+ #if MRPT_HAS_FFMPEG && MRPT_HAS_OPENCV
+@@ -21,6 +22,15 @@
+ TEST(RawlogGrabberApp, DISABLED_CGenericCamera_AVI)
+ #endif
+ {
++ // This particular unit test is REALLY problematic for some reason on
build
++ // farms. It's safer to just disable it in this case:
++ if (::getenv("DEB_BUILD_ARCH") || ::getenv("DEB_BUILD_MAINT_OPTIONS"))
++ {
++ std::cerr << "Warning: Disabling test since we are building a
Debian "
++ "package.\n";
++ return;
++ }
++
+ using namespace std::string_literals;
+
+ const std::string ini_fil =
diff -Nru mrpt-2.0.4/debian/patches/series mrpt-2.0.4/debian/patches/series
--- mrpt-2.0.4/debian/patches/series2020-06-20 17:24:00.0 +0200
+++ mrpt-2.0.4/debian/patches/series2020-07-17 08:14:20.0 +0200
@@ -1 +1,2 @@
fix-inconsistent-appstream-metadata-license.diff
+e84511500276d38d3eeff0b220e8d45e0d74fc93.patch
diff -Nru mrpt-2.0.4/debian/rules mrpt-2.0.4/debian/rules
--- mrpt-2.0.4/debian/rules 2020-06-20 17:24:00.0 +0200
+++ mrpt-2.0.4/debian/rules 2020-07-17 08:14:20.0 +0200
@@ -68,6 +68,8 @@
# Show CPU flags, to help debugging unit test crashes related to
# illegal instructions, etc.
cat /proc/cpuinfo
+ # Show env vars for debugging:
+ env
# Autoconfigure step:
dh_auto_configure -- $(CMAKE_FLAGS)
Bug#965033: debdiff
and looking at the commit ids, the responsible might be this commit https://github.com/mesonbuild/meson/commit/57b468c75ae90e09f8bd98da12a5c420ab49cd79 (not sure if only that one) G.
Bug#965033: debdiff
Hello again, On Wed, 15 Jul 2020 17:02:36 -0700 Kunal Mehta wrote: > I'm happy to NMU this since it's affecting some of my packages (zimlib, > libkiwix, zim-tools, etc.). debdiff is attached. > > It's not clear to me why the dependency was commented out in the first > place, but it fixes the immediate issue. Let me know if that's OK and if > you'd like me to go ahead. > this is probably the rationale for it https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909440 G.
Bug#965033: debdiff
Hello, On Wed, 15 Jul 2020 17:02:36 -0700 Kunal Mehta wrote: > I'm happy to NMU this since it's affecting some of my packages (zimlib, > libkiwix, zim-tools, etc.). debdiff is attached. > > It's not clear to me why the dependency was commented out in the first > place, but it fixes the immediate issue. Let me know if that's OK and if > you'd like me to go ahead. > I'm not the maintainer, but in case you want to NMU, please add also this patch: from the other RC bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963546#50 diff -Nru meson-0.55.0/debian/tests/control meson-0.55.0/debian/tests/control --- meson-0.55.0/debian/tests/control 2020-07-12 16:29:07.0 +0200 +++ meson-0.55.0/debian/tests/control 2020-07-14 13:06:32.0 +0200 @@ -12,4 +12,4 @@ Depends: meson, @builddeps@, valac, rustc, ldc [!s390x !ppc64el] Tests: crossbuild -Depends: meson, g++, g++-arm-linux-gnueabihf +Depends: meson, g++, g++-arm-linux-gnueabihf [!s390x] thanks! G.
Bug#964044: mrpt: FTBFS: test failure
Hello, On Mon, 13 Jul 2020 21:20:41 +0200 Sebastian Ramacher wrote: > On 2020-06-30 22:37:57 +0200, Sebastian Ramacher wrote: > > Source: mrpt > > Version: 1:2.0.4-1 > > Severity: serious > > Tags: ftbfs > > Justification: fails to build from source (but built successfully in the > > past) > > > > binNMUs of mrpt failed to build: > > | [--] 1 test from RawlogGrabberApp > > | [ RUN ] RawlogGrabberApp.CGenericCamera_AVI > > | [CCameraSensor::initialize] Opening camera... > > | [CCameraSensor::initialize] FFmpeg stream: > > /<>/share/mrpt/datasets/dummy_video.avi... > > | [CCameraSensor::initialize] Done! > > | Rawlog grabbed objects: 1 > > | /<>/libs/apps/src/RawlogGrabberApp_unittest.cpp:94: Failure > > | Expected: (app.rawlog_saved_objects) >= (REQUIRED_GRAB_OBS), actual: 1 vs > > 3 > > | [ FAILED ] RawlogGrabberApp.CGenericCamera_AVI (1511 ms) > > | [--] 1 test from RawlogGrabberApp (1511 ms total) > > > > See > > https://buildd.debian.org/status/fetch.php?pkg=mrpt=amd64=1%3A2.0.4-1%2Bb1=1593549279=0 > > for example > > This issue has been fixed upstream: > https://github.com/MRPT/mrpt/commit/15234dc335c2413e3fd41021f7511f1d36fe915b. > Could you please apply the fix to the Debian package so that > ros-geometry2 transition can be completed? Thanks looks like that commit is already part of 2.0.4? G. > > Cheers > -- > Sebastian Ramacher
Bug#965115: extlib: FTBFS in sid (dh_dwz failure)
control: affects -1 ocaml-mccs for some reasons, the new binutils changed the dwarf version from 2 to 0 (I tested on stretch, upgraded dwz and binutils to bullseye and reproduced the issue) readelf --debug-dump=info src/extLib.cmxs | grep -A 2 'Compilation Unit @' readelf: Warning: CU at offset 0 contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 2e contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 5c contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 8a contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset b8 contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset e6 contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 114 contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 142 contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 170 contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 19e contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 1cc contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 1fa contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 228 contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 256 contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 284 contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 2b2 contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 2e0 contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 30e contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 33c contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 36a contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 398 contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 3c6 contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 0 contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 2e contains corrupt or unsupported version number: 0. readelf: Warning: CU at offset 5c contains corrupt or unsupported version number: 0. readelf: Warning: Compilation Unit @ offset 0x0: CU at offset 8a contains corrupt or unsupported version number: 0. Length:0x2a (32-bit) Version: 0 readelf: Warning: -- CU at offset b8 contains corrupt or unsupported version number: 0. Compilation Unit @ offset 0x2e: Length:0x2a (32-bit) readelf: Warning:Version: 0 CU at offset e6 contains corrupt or unsupported version number: 0. -- Compilation Unit @ offset 0x5c: readelf: Warning:Length:0x2a (32-bit)
Bug#965115: extlib: FTBFS in sid (dh_dwz failure)
Source: extlib
Version: 1.7.7-1
Severity: serious
Hello, as you can see in the attached build log, the package now FTBFS.
Honestly I don't know if the error
dwz: debian/libextlib-ocaml/usr/lib/ocaml/extlib/extLib.cmxs: DWARF version 0
unhandled
dh_dwz: error: dwz -- debian/libextlib-ocaml/usr/lib/ocaml/extlib/extLib.cmxs
returned exit code 1
is a fault on dwz or extlib, this is why I'm ccing doko, please reassign to
binutils/dwz or whenever you think its
more appropriate
thanks
G.
[0;34mD: cmdline: build --distribution sid --buildresult
/home/locutus/pbuilder/sid_result --basetgz /home/locutus/pbuilder/sid-base.tgz
--logfile /home/locutus/pbuilder/sid_result/extlib_1.7.7-1_amd64.build --mirror
http://deb.debian.org/debian --debootstrapopts
--keyring=/usr/share/keyrings/debian-archive-keyring.gpg --aptcache
/home/locutus/pbuilder/aptcache/debian --components main contrib non-free
extlib_1.7.7-1.dsc[0m
[1;33mW: cgroups are not available on the host, not using them.[0m
[0mI: pbuilder: network access will be disabled during build[0m
[0mI: Current time: Thu Jul 16 12:53:15 CEST 2020[0m
[0mI: pbuilder-time-stamp: 1594896795[0m
[0mI: Building the build Environment[0m
[0mI: extracting base tarball [/home/locutus/pbuilder/sid-base.tgz][0m
[0mI: copying local configuration[0m
[1;33mW: No local /etc/mailname to copy, relying on
/tmp/build/11969/etc/mailname to be correct[0m
[1;33mW: --override-config is not set; not updating apt.conf Read the manpage
for details.[0m
[0mI: mounting /proc filesystem[0m
[0mI: mounting /sys filesystem[0m
[0mI: creating /{dev,run}/shm[0m
[0mI: mounting /dev/pts filesystem[0m
[0mI: redirecting /dev/ptmx to /dev/pts/ptmx[0m
[0mI: policy-rc.d already exists[0m
[0mI: Obtaining the cached apt archive contents[0m
[0mI: Copying source file[0m
[0mI: copying [extlib_1.7.7-1.dsc][0m
[0mI: copying [./extlib_1.7.7.orig.tar.gz][0m
[0mI: copying [./extlib_1.7.7-1.debian.tar.xz][0m
[0mI: Extracting source[0m
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/tmp/dpkg-verify-sig.TYiqKJZL/trustedkeys.kbx':
General error
gpgv: Signature made Tue May 19 06:38:02 2020 UTC
gpgv:using RSA key 6DE24E97ECA886CC56E6250E21B8EEF1B1893081
gpgv:issuer "glo...@debian.org"
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./extlib_1.7.7-1.dsc
dpkg-source: info: extracting extlib in extlib-1.7.7
dpkg-source: info: unpacking extlib_1.7.7.orig.tar.gz
dpkg-source: info: unpacking extlib_1.7.7-1.debian.tar.xz
[0mI: Not using root during the build.[0m
[0mI: Installing the build-deps[0m
-> Attempting to parse the build-deps
-> Considering build-depdebhelper-compat (= 12)
-> Trying to add debhelper-compat=12
-> Loop detected, last APT error was: ==
Reading package lists...
Building dependency tree...
Reading state information...
E: Version '12' for 'debhelper-compat' was not found
-> =
-> (not adding to debhelper-compat=12)
-> Cannot install debhelper-compat=12; apt errors follow:
Reading package lists...
Building dependency tree...
Reading state information...
E: Version '12' for 'debhelper-compat' was not found
-> Considering debhelper to satisfy the dependency
-> Considering build-dep ocaml-nox
-> Trying to add ocaml-nox
-> Considering build-dep cppo
-> Trying to add cppo
-> Considering build-dep ocaml-findlib
-> Trying to add ocaml-findlib
-> Considering build-dep libfindlib-ocaml-dev
-> Trying to add libfindlib-ocaml-dev
-> Considering build-dep dh-ocaml
-> Trying to add dh-ocaml
-> Installing debhelper ocaml-nox cppo ocaml-findlib libfindlib-ocaml-dev
dh-ocaml
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
autoconf automake autopoint autotools-dev bsdextrautils dh-autoreconf
dh-strip-nondeterminism dwz file gettext gettext-base groff-base
intltool-debian libarchive-zip-perl libcroco3 libdebhelper-perl libelf1
libfile-stripnondeterminism-perl libfindlib-ocaml libglib2.0-0 libicu67
libmagic-mgc libmagic1 libncurses-dev libncurses5-dev libncurses6
libpipeline1 libsigsegv2 libsub-override-perl libtool libuchardet0 libxml2
m4 man-db ocaml-base-nox ocaml-compiler-libs ocaml-interp po-debconf
sensible-utils
Suggested packages:
autoconf-archive gnu-standards autoconf-doc dh-make git gettext-doc
libasprintf-dev libgettextpo-dev groff ncurses-doc libtool-doc gfortran
| fortran95-compiler gcj-jdk m4-doc apparmor less www-browser camlp4
ocaml-doc tuareg-mode libmail-box-perl
Recommended packages:
curl | wget | lynx libarchive-cpio-perl libglib2.0-data shared-mime-info
xdg-user-dirs libgpm2 libltdl-dev ocaml-man ledit | readline-editor
libmail-sendmail-perl
The following NEW packages will be installed:
autoconf automake autopoint autotools-dev
Bug#964680: ibus-pinyin: FTBFS: lmyoslib.c:68:36: error: expected ‘)’ before ‘LUA_QS’
control: tags -1 patch pending
Hello, I uploaded in deferred/5 the following debdiff (and submitted upstream)
Feel free to cancel/reschedule as you wish.
diff -Nru ibus-pinyin-1.5.0/debian/changelog ibus-pinyin-1.5.0/debian/changelog
--- ibus-pinyin-1.5.0/debian/changelog 2019-12-07 21:11:35.0 +0100
+++ ibus-pinyin-1.5.0/debian/changelog 2020-07-15 11:26:32.0 +0200
@@ -1,3 +1,11 @@
+ibus-pinyin (1.5.0-6.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix lua compatibility issue due to deprecated LUA_QS macro.
+(Closes: #964680)
+
+ -- Gianfranco Costamagna Wed, 15 Jul 2020
11:26:32 +0200
+
ibus-pinyin (1.5.0-6) unstable; urgency=medium
* Team upload.
diff -Nru ibus-pinyin-1.5.0/debian/patches/lua-5.4.patch
ibus-pinyin-1.5.0/debian/patches/lua-5.4.patch
--- ibus-pinyin-1.5.0/debian/patches/lua-5.4.patch 1970-01-01
01:00:00.0 +0100
+++ ibus-pinyin-1.5.0/debian/patches/lua-5.4.patch 2020-07-15
11:26:30.0 +0200
@@ -0,0 +1,19 @@
+Description: Fix lua 5.4 compatibility, due to deprecated LUA_QS macro
+See:
https://polyrex.io/polyrex/dependencies/lua/-/commit/f97c64d7bf4c0f373711795d8faba0e8cd206761
+For reference.
+Author: Gianfranco Costamagna
+Bug-Debian: https://bugs.debian.org/964680
+Forwarded: https://github.com/phuang/ibus-pinyin/pull/18
+Last-Update: 2020-07-15
+
+--- ibus-pinyin-1.5.0.orig/lua/lmyoslib.c
ibus-pinyin-1.5.0/lua/lmyoslib.c
+@@ -65,7 +65,7 @@ static int getfield (lua_State *L, const
+ res = (int)lua_tointeger(L, -1);
+ else {
+ if (d < 0)
+- return luaL_error(L, "field " LUA_QS " missing in date table", key);
++ return luaL_error(L, "field '%s' missing in date table", key);
+ res = d;
+ }
+ lua_pop(L, 1);
diff -Nru ibus-pinyin-1.5.0/debian/patches/series
ibus-pinyin-1.5.0/debian/patches/series
--- ibus-pinyin-1.5.0/debian/patches/series 2019-12-07 21:11:35.0
+0100
+++ ibus-pinyin-1.5.0/debian/patches/series 2020-07-15 11:23:29.0
+0200
@@ -14,3 +14,4 @@
# python3 support
python3.patch
+lua-5.4.patch
Bug#965014: bsdmainutils: binaries uploaded
Source: bsdmainutils Version: 12.1.4 Severity: serious Justification: can't migrate per Britney policy. Hello, thanks for fixing the bsdmainutils RC bugs, but without a source-only upload, the package won't ever migrate to testing. In specific, the arch:all packages can't be binNMUed, so please reupload if you want the fix to go in testing. thanks! Gianfranco
Bug#963546: fixed in meson 0.55.0-1
control: reopen -1 control: notfixed -1 0.55.0-1 control: notfixed -1 0.55.0~rc2-1 Hello, looks like there is still one tweak needed? +meson (0.55.0-2) unstable; urgency=medium + + * Don't require armhf tools on s390x (Closes: #963546) + + -- Gianfranco Costamagna Tue, 14 Jul 2020 13:06:33 +0200 + meson (0.55.0-1) unstable; urgency=medium * New upstream release. diff -Nru meson-0.55.0/debian/tests/control meson-0.55.0/debian/tests/control --- meson-0.55.0/debian/tests/control 2020-07-12 16:29:07.0 +0200 +++ meson-0.55.0/debian/tests/control 2020-07-14 13:06:32.0 +0200 @@ -12,4 +12,4 @@ Depends: meson, @builddeps@, valac, rustc, ldc [!s390x !ppc64el] Tests: crossbuild -Depends: meson, g++, g++-arm-linux-gnueabihf +Depends: meson, g++, g++-arm-linux-gnueabihf [!s390x] this is the failure: Reading package lists... Building dependency tree... Reading state information... Package g++-arm-linux-gnueabihf is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'g++-arm-linux-gnueabihf' has no installation candidate crossbuild FAIL badpkg blame: meson badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. autopkgtest [09:26:49]: summary basicmeson PASS clangmeson PASS exhaustive PASS crossbuild FAIL badpkg thanks for fixing everything else! (I'm still testing the patch right now, but I presume it should be good) Gianfranco
Bug#964880: npm: test failures in ppc64el and s390x
Source: npm
Version: 6.14.6+ds-1
Severity: serious
Hello, looks like one test is failing on ppc64el and s390x.
Could you please have a look?
this on s390x
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/n/npm/20200711_092356_eb5fd@/log.gz
# Subtest: test/tap/legacy-platform-all.js
# Subtest: setup
1..0
ok 1 - setup # time=2.926ms
# Subtest: platform-all
not ok 1 - no error messages
---
found: >
npm ERR! code EBADPLATFORM
npm ERR! notsup Unsupported platform for
npm-test-platform-all@9.9.9-9: wanted
{"os":"darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd","arch":"arm,arm64,mips,ia32,x64,sparc"}
(current: {"os":"linux","arch":"s390x"})
npm ERR! notsup Valid OS:
darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd
npm ERR! notsup Valid Arch: arm,arm64,mips,ia32,x64,sparc
npm ERR! notsup Actual OS: linux
npm ERR! notsup Actual Arch: s390x
npm ERR! A complete log of this run can be found in:
npm ERR!
/tmp/autopkgtest.TwzxSV/autopkgtest_tmp/smokeh0DzIy/test/npm_cache_legacy-platform-all/_logs/2020-07-11T09_18_58_795Z-debug.log
wanted: ''
compare: ===
at:
line: 55
column: 7
file: test/tap/legacy-platform-all.js
type: global
function: installCheckAndTest
stack: |
installCheckAndTest (test/tap/legacy-platform-all.js:55:7)
f (/usr/lib/nodejs/once/once.js:25:25)
ChildProcess. (test/common-tap.js:175:5)
source: |
t.is(stderr, '', 'no error messages')
...
not ok 2 - install went ok
---
found: 1
wanted: 0
compare: ===
at:
line: 56
column: 7
file: test/tap/legacy-platform-all.js
type: global
function: installCheckAndTest
stack: |
installCheckAndTest (test/tap/legacy-platform-all.js:56:7)
f (/usr/lib/nodejs/once/once.js:25:25)
ChildProcess. (test/common-tap.js:175:5)
source: |
t.is(code, 0, 'install went ok')
...
1..2
# failed 2 of 2 tests
not ok 2 - platform-all # time=767.548ms
# Subtest: cleanup
1..0
ok 3 - cleanup # time=1.651ms
1..3
# failed 1 of 3 tests
# time=782.166ms
not ok 103 - test/tap/legacy-platform-all.js # time=1350.563ms
and this on ppc64el
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/ppc64el/n/npm/20200711_093200_7007f@/log.gz
# Subtest: test/tap/legacy-platform-all.js
# Subtest: setup
1..0
ok 1 - setup # time=4.916ms
# Subtest: platform-all
not ok 1 - no error messages
---
found: >
npm ERR! code EBADPLATFORM
npm ERR! notsup Unsupported platform for
npm-test-platform-all@9.9.9-9: wanted
{"os":"darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd","arch":"arm,arm64,mips,ia32,x64,sparc"}
(current: {"os":"linux","arch":"ppc64"})
npm ERR! notsup Valid OS:
darwin,linux,win32,solaris,haiku,sunos,freebsd,openbsd,netbsd
npm ERR! notsup Valid Arch: arm,arm64,mips,ia32,x64,sparc
npm ERR! notsup Actual OS: linux
npm ERR! notsup Actual Arch: ppc64
npm ERR! A complete log of this run can be found in:
npm ERR!
/tmp/autopkgtest.RvsIrP/autopkgtest_tmp/smokevhVLkX/test/npm_cache_legacy-platform-all/_logs/2020-07-11T09_24_22_560Z-debug.log
wanted: ''
compare: ===
at:
line: 55
column: 7
file: test/tap/legacy-platform-all.js
type: global
function: installCheckAndTest
stack: |
installCheckAndTest (test/tap/legacy-platform-all.js:55:7)
f (/usr/lib/nodejs/once/once.js:25:25)
ChildProcess. (test/common-tap.js:175:5)
source: |
t.is(stderr, '', 'no error messages')
...
not ok 2 - install went ok
---
found: 1
wanted: 0
compare: ===
at:
line: 56
column: 7
file: test/tap/legacy-platform-all.js
type: global
function: installCheckAndTest
stack: |
installCheckAndTest (test/tap/legacy-platform-all.js:56:7)
f
Bug#964790: libmicrohttpd: please make autopkgtests cross-friendly
Source: libmicrohttpd
Version: 0.9.71-1
Severity: normal
tags: patch
Hello, can you please make tests cross-friendly, so we can test i386 on amd64?
Trivial patch will be directly committed on git once I have confirmation of the
sanity.
however, it will be similar to this:
--- libmicrohttpd-0.9.71/debian/tests/build 2020-03-14 15:58:09.0
+0100
+++ libmicrohttpd-0.9.71/debian/tests/build 2020-07-10 15:55:03.0
+0200
@@ -5,6 +5,12 @@
set -e
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE=${DEB_HOST_GNU_TYPE}-
+else
+CROSS_COMPILE=
+fi
+
WORKDIR=$(mktemp -d)
trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
cd $WORKDIR
@@ -18,7 +24,7 @@
return 0;
}
EOF
-gcc `pkg-config --cflags libmicrohttpd` -o build_test build_test.c `pkg-config
--libs libmicrohttpd`
+${CROSS_COMPILE}gcc `${CROSS_COMPILE}pkg-config --cflags libmicrohttpd` -o
build_test build_test.c `${CROSS_COMPILE}pkg-config --libs libmicrohttpd`
echo "build: OK"
[ -x build_test ]
./build_test
cheers,
Gianfranco
Bug#964771: seafile: sed in rules file leads to invalid dependencies
Hello, On Fri, 10 Jul 2020 11:37:23 +0200 Gianfranco Costamagna wrote: > Source: seafile > Version: 7.0.8-1 > Severity: serious > tags: patch > > Upstream switched to python3, and now the sed in rules file makes it become > python33 leading to an invalid runtime > dependency on python33:any. > > trivial patch: > diff -Nru seafile-7.0.8/debian/changelog seafile-7.0.8/debian/changelog > --- seafile-7.0.8/debian/changelog2020-07-06 09:42:21.0 +0200 > +++ seafile-7.0.8/debian/changelog2020-07-10 11:35:34.0 +0200 > @@ -1,3 +1,9 @@ > +seafile (7.0.8-1.1) unstable; urgency=medium > + > + * Drop hack leading to python33 shebang (Closes: #-1) > + > + -- Gianfranco Costamagna Fri, 10 Jul 2020 > 11:35:34 +0200 > + > seafile (7.0.8-1) unstable; urgency=medium > >* New upstream version 7.0.8 > diff -Nru seafile-7.0.8/debian/rules seafile-7.0.8/debian/rules > --- seafile-7.0.8/debian/rules2020-05-12 11:21:29.0 +0200 > +++ seafile-7.0.8/debian/rules2020-07-10 11:35:32.0 +0200 > @@ -23,6 +23,3 @@ > # emptying the dependency_libs field in .la files > sed -i "/dependency_libs/ s/'.*'/''/" `find debian/ -name '*.la'` > dh_strip --dbgsym-migration='seafile-daemon-dbg (<< 6.0.7-1), > libseafile-dbg (<< 6.0.7-1)' > - > -execute_before_dh_install: > - sed -e '1 s/python/python3/' -i $(CURDIR)/debian/tmp/usr/bin/seaf-cli > > this is now on git. G.
Bug#964771: seafile: sed in rules file leads to invalid dependencies
Source: seafile Version: 7.0.8-1 Severity: serious tags: patch Upstream switched to python3, and now the sed in rules file makes it become python33 leading to an invalid runtime dependency on python33:any. trivial patch: diff -Nru seafile-7.0.8/debian/changelog seafile-7.0.8/debian/changelog --- seafile-7.0.8/debian/changelog 2020-07-06 09:42:21.0 +0200 +++ seafile-7.0.8/debian/changelog 2020-07-10 11:35:34.0 +0200 @@ -1,3 +1,9 @@ +seafile (7.0.8-1.1) unstable; urgency=medium + + * Drop hack leading to python33 shebang (Closes: #-1) + + -- Gianfranco Costamagna Fri, 10 Jul 2020 11:35:34 +0200 + seafile (7.0.8-1) unstable; urgency=medium * New upstream version 7.0.8 diff -Nru seafile-7.0.8/debian/rules seafile-7.0.8/debian/rules --- seafile-7.0.8/debian/rules 2020-05-12 11:21:29.0 +0200 +++ seafile-7.0.8/debian/rules 2020-07-10 11:35:32.0 +0200 @@ -23,6 +23,3 @@ # emptying the dependency_libs field in .la files sed -i "/dependency_libs/ s/'.*'/''/" `find debian/ -name '*.la'` dh_strip --dbgsym-migration='seafile-daemon-dbg (<< 6.0.7-1), libseafile-dbg (<< 6.0.7-1)' - -execute_before_dh_install: - sed -e '1 s/python/python3/' -i $(CURDIR)/debian/tmp/usr/bin/seaf-cli
Bug#964377: bumblebee: please runtime depend on pciutils
Hello, > Hmm, then I've hit both of them ;-) yep :) (there might be more, but probably not that many) > Does bumblebee/git generate the correct dependencies on Ubuntu now? (And > empty lists for bumblebee-nvidia on the "new" architectures w/o driver > in Ubuntu?) > it is mostly everything correct, except for one bug I discovered. Britney can't let it migrate, because bumblebee-nvidia is universe, and nvidia-driver-390 is restricted bumblebee-nvidia/armhf unsatisfiable Depends: nvidia-driver-390 probably amd64 is not getting this issue because it has a generic "nvidia" alternate dependency that confuses britney in some way. For now I uploaded something like: -nv_version_Ubuntu += 390_[amd64_i386_armhf] +nv_version_Ubuntu += 390_[amd64_i386] I know, this isn't the smart approach to deal with the issue, but at least it should make it migrate. Maybe we can change it into a suggest or something less important? thanks Gianfranco
Bug#964377: bumblebee: please runtime depend on pciutils
Hello, > Good catch! > Should there be a lintian test for it? I remember fixing the same thing > in firmware-b43-installer recently. > it would probably help a lot, yes :) but a quick and incomplete look shows... https://codesearch.debian.net/search?q=lspci+path%3Apostinst%24=0 only two packages affected? G.
Bug#964384: [Debian-iot-maintainers] Bug#964384: ulfius: FTBFS with recent libmicrohttpd
Hello, > This test fails while getting "http://[::1]:8080/empty;, maybe there's > an ipv6 issue in ubuntu autopkgtest environment? > they might not have ipv6 capability, or that port being already allocated? not sure. > The last 2 errors will probably tell us more after the release since the > error message will be fixed in ulfius_send_smtp_rich_email, thanks to you! > thanks! the error now with that patch is: 2020-07-06T15:19:23Z - Ulfius ERROR: Ulfius - Error sending smtp message, error message Couldn't connect to server 2020-07-06T15:19:23Z - Ulfius ERROR: Ulfius - Error sending smtp message, error message Couldn't connect to server 2020-07-06T15:19:23Z - Ulfius ERROR: Ulfius - Error sending smtp message, error message Couldn't connect to server https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/u/ulfius/20200706_151935_d3556@/log.gz I honestly don't think using 8080 is a nice thing to do, probably such ports might be already opened let me know if you need some more testing! G.
Bug#964384: ulfius: FTBFS with recent libmicrohttpd
Source: ulfius Version: 2.6.7-4 Severity: serious tags: patch Hello, can you please apply the two patches below to fix the build failure with new libmicrohttpd and to give a more useful error message in case curl fails? (I don't know yet why, but the autopkgtest is failing in Ubuntu) https://github.com/babelouest/ulfius/pull/168 and https://github.com/babelouest/ulfius/commit/fa157b1bf14fd1aa0bf998f1f3f9c55d15a13a3b (updating to 2.6.8 grabs automagically this commit, while my pull request is not yet merged) thanks! also, help to track down the ubuntu failure is appreciated http://autopkgtest.ubuntu.com/packages/u/ulfius/groovy/amd64 Gianfranco
Bug#964377: bumblebee: please runtime depend on pciutils
Source: bumblebee Version: 3.2.1-23 Severity: serious Hello, bumblebee and bumblebee-nvidia (in Ubuntu) use lspci in their postinst files, without a dependency on it ./debian/bumblebee.postinst:busid=$(lspci -d10de: -nn | grep '\[030[02]\]' | cut -d' ' -f1 | tr . : | head -1) ./debian/bumblebee-nvidia.postinst.Ubuntu: busid=$(lspci -d10de: -nn | grep '\[030[02]\]' | cut -d' ' -f1 | tr . : | head -1) I think depending on pciutils might be a sane thing to do! (I think the severity is RC, but feel free to downgrade, I don't know what is the severity for this bug) cheers, Gianfranco
Bug#964141: libc6: "cannot allocate memory in static TLS block" with some library combinations on arm64
control: tags -1 patch Hello, the patch (v5) applied on top of 2.31 (build-tested in Ubuntu) seems to solve the issue: diff -Nru glibc-2.31/debian/changelog glibc-2.31/debian/changelog --- glibc-2.31/debian/changelog 2020-06-11 09:53:48.0 + +++ glibc-2.31/debian/changelog 2020-07-03 10:21:12.0 + @@ -1,3 +1,9 @@ +glibc (2.31-0ubuntu11) groovy; urgency=medium + + * Fix arm64 sadness on pyside2 + + -- Gianfranco Costamagna Fri, 03 Jul 2020 11:45:47 +0200 + glibc (2.31-0ubuntu10) groovy; urgency=medium * Copy the fully conditionalized x86 variant for math-vector-fortran.h diff -Nru glibc-2.31/debian/patches/arm64-fix-2.patch glibc-2.31/debian/patches/arm64-fix-2.patch --- glibc-2.31/debian/patches/arm64-fix-2.patch 1970-01-01 00:00:00.0 + +++ glibc-2.31/debian/patches/arm64-fix-2.patch 2020-07-03 10:21:10.0 + @@ -0,0 +1,606 @@ +Origin: http://51.15.138.76/patch/37618/ + +diff --git a/csu/libc-tls.c b/csu/libc-tls.c +index e2603157e8..fb77cd94fa 100644 +--- a/csu/libc-tls.c b/csu/libc-tls.c +@@ -56,6 +56,9 @@ size_t _dl_tls_static_align; +loaded modules with IE-model TLS or for TLSDESC optimization. +See comments in elf/dl-tls.c where it is initialized. */ + size_t _dl_tls_static_surplus; ++/* Remaining amount of static TLS that may be used for optimizing ++ dynamic TLS access (e.g. with TLSDESC). */ ++size_t _dl_tls_static_optional; + + /* Generation counter for the dtv. */ + size_t _dl_tls_generation; +diff --git a/elf/Makefile b/elf/Makefile +index 6fe1df90bb..5fadaec27c 100644 +--- a/elf/Makefile b/elf/Makefile +@@ -201,7 +201,7 @@ tests += restest1 preloadtest loadfail multiload origtest resolvfail \ +tst-unwind-ctor tst-unwind-main tst-audit13 \ +tst-sonamemove-link tst-sonamemove-dlopen tst-dlopen-tlsmodid \ +tst-dlopen-self tst-auditmany tst-initfinilazyfail tst-dlopenfail \ +- tst-dlopenfail-2 ++ tst-dlopenfail-2 tst-tls-ie tst-tls-ie-dlmopen + # reldep9 + tests-internal += loadtest unload unload2 circleload1 \ +neededtest neededtest2 neededtest3 neededtest4 \ +@@ -312,7 +312,11 @@ modules-names = testobj1 testobj2 testobj3 testobj4 testobj5 testobj6 \ + tst-auditmanymod7 tst-auditmanymod8 tst-auditmanymod9 \ + tst-initlazyfailmod tst-finilazyfailmod \ + tst-dlopenfailmod1 tst-dlopenfaillinkmod tst-dlopenfailmod2 \ +- tst-dlopenfailmod3 tst-ldconfig-ld-mod ++ tst-dlopenfailmod3 tst-ldconfig-ld-mod \ ++ tst-tls-ie-mod0 tst-tls-ie-mod1 tst-tls-ie-mod2 \ ++ tst-tls-ie-mod3 tst-tls-ie-mod4 tst-tls-ie-mod5 \ ++ tst-tls-ie-mod6 ++ + # Most modules build with _ISOMAC defined, but those filtered out + # depend on internal headers. + modules-names-tests = $(filter-out ifuncmod% tst-libc_dlvsym-dso tst-tlsmod%,\ +@@ -1699,3 +1702,23 @@ $(objpfx)tst-auxobj: $(objpfx)tst-filterobj-aux.so + + $(objpfx)tst-ldconfig-ld_so_conf-update.out: $(objpfx)tst-ldconfig-ld-mod.so + $(objpfx)tst-ldconfig-ld_so_conf-update: $(libdl) ++ ++$(objpfx)tst-tls-ie: $(libdl) $(shared-thread-library) ++$(objpfx)tst-tls-ie.out: \ ++ $(objpfx)tst-tls-ie-mod0.so \ ++ $(objpfx)tst-tls-ie-mod1.so \ ++ $(objpfx)tst-tls-ie-mod2.so \ ++ $(objpfx)tst-tls-ie-mod3.so \ ++ $(objpfx)tst-tls-ie-mod4.so \ ++ $(objpfx)tst-tls-ie-mod5.so \ ++ $(objpfx)tst-tls-ie-mod6.so ++ ++$(objpfx)tst-tls-ie-dlmopen: $(libdl) $(shared-thread-library) ++$(objpfx)tst-tls-ie-dlmopen.out: \ ++ $(objpfx)tst-tls-ie-mod0.so \ ++ $(objpfx)tst-tls-ie-mod1.so \ ++ $(objpfx)tst-tls-ie-mod2.so \ ++ $(objpfx)tst-tls-ie-mod3.so \ ++ $(objpfx)tst-tls-ie-mod4.so \ ++ $(objpfx)tst-tls-ie-mod5.so \ ++ $(objpfx)tst-tls-ie-mod6.so +diff --git a/elf/dl-reloc.c b/elf/dl-reloc.c +index ffcc84d396..6d32e49467 100644 +--- a/elf/dl-reloc.c b/elf/dl-reloc.c +@@ -39,13 +39,16 @@ + /* We are trying to perform a static TLS relocation in MAP, but it was +dynamically loaded. This can only work if there is enough surplus in +the static TLS area already allocated for each running thread. If this +- object's TLS segment is too big to fit, we fail. If it fits, +- we set MAP->l_tls_offset and return. +- This function intentionally does not return any value but signals error +- directly, as static TLS should be rare and code handling it should +- not be inlined as much as possible. */ ++ object's TLS segment is too big to fit, we fail with -1. If it fits, ++ we set MAP->l_tls_offset and return 0. ++ A portion of the surplus static TLS can be optionally used to optimize ++ dynamic TLS access (with TLSDESC or powerpc TLS optimizations). ++ If OPTIONAL is true then TLS is allocated for such optimization and ++ the caller must have a fallback in case the optional portion of surplus ++ TLS runs out. If OPTIONAL is false then the entire surplus TLS area is ++ considered and the allocation only
Bug#964196: zimlib: please increase test timeout
Source: zimlib Version: 6.1.3-4 tags: patch Hello, looks like on some slow (emulated) qemu architectures, some test requires more time than 60 seconds e.g. on Ubuntu, https://launchpadlibrarian.net/486974914/buildlog_ubuntu-groovy-riscv64.zimlib_6.1.3-4ubuntu2_BUILDING.txt.gz 1/7 cluster OK 83.77s this patch makes the build succeed. +Description: Increase a little bit the test timeout, to help slow architectures +Author: Gianfranco Costamagna +Last-Update: 2020-07-03 + +--- zimlib-6.1.3.orig/test/meson.build zimlib-6.1.3/test/meson.build +@@ -22,7 +22,7 @@ if gtest_dep.found() and not meson.is_cr + link_args: extra_link_args, + dependencies : deps + [gtest_dep], + build_rpath : '$ORIGIN') +-test(test_name, test_exe, timeout : 60) ++test(test_name, test_exe, timeout : 90) + endforeach + endif + diff -Nru zimlib-6.1.3/debian/patches/series zimlib-6.1.3/debian/patches/series --- zimlib-6.1.3/debian/patches/series 2019-08-06 07:11:17.0 + +++ zimlib-6.1.3/debian/patches/series 2020-07-03 08:11:32.0 + @@ -0,0 +1 @@ +increase-timeout-riscv.patch
Bug#964137: clazy: autopkgtests failure on 32bit
Hello, a smarter approach might be this one: https://invent.kde.org/sdk/clazy/commit/dbde38f1a67c2968c951629a5f5629c9847078bd (untested) G.
Bug#964137: clazy: autopkgtests failure on 32bit
Source: clazy Version: 1.7-2 severity: serious tags: patch Hello, the following patch should be sufficient to make it work also in autopkgtests. (note: I'm testing it right now on Ubuntu) https://launchpad.net/ubuntu/+source/clazy/1.7-2ubuntu1 if the version migrates it means the patch is correct, otherwise please have a look at the Ubuntu package before integrating! --- clazy-1.7/debian/changelog 2020-07-01 10:44:27.0 +0200 +++ clazy-1.7/debian/changelog 2020-07-02 13:10:00.0 +0200 @@ -1,3 +1,10 @@ +clazy (1.7-2.1) unstable; urgency=medium + + * Bring back patch to exclude inefficient-qlist check on autopkgtests +running on 32bit (Closes: #-1). + + -- Gianfranco Costamagna Thu, 02 Jul 2020 13:10:00 +0200 + clazy (1.7-2) unstable; urgency=medium * Exclude the inefficient-qlist check again, unfortunately on all the 32bit diff -Nru clazy-1.7/debian/tests/run-tests clazy-1.7/debian/tests/run-tests --- clazy-1.7/debian/tests/run-tests2018-11-27 07:23:27.0 +0100 +++ clazy-1.7/debian/tests/run-tests2020-07-02 13:09:59.0 +0200 @@ -2,9 +2,17 @@ set -e +DEB_HOST_ARCH_BITS=$(dpkg-architecture -qDEB_HOST_ARCH_BITS) + # show some facts about clang/clang++, so it is easier to debug issues clang -E -x c - -v < /dev/null clang++ -E -x c++ - -v < /dev/null cd tests -./run_tests.py --verbose +# wrong size reported, although the test correctly identifies the issue +# https://bugs.kde.org/show_bug.cgi?id=423728 +if [ $DEB_HOST_ARCH_BITS = 32 ]; then + ./run_tests.py --verbose --exclude inefficient-qlist +else + ./run_tests.py --verbose +fi
Bug#964093: kombu: please drop python3-importlib-metadata dependency
Source: kombu
Version: 4.6.11-2
Severity: normal
tags: patch
>From Ubuntu:
kombu (4.6.7-1ubuntu1) focal; urgency=medium
* d/control: Move python3-importlib-metadata to Suggests since
/usr/lib/python3.8/importlib/metadata.py is provided by the Python 3.8
standard library and Python 3.8 will be the default for Ubuntu Focal.
The python3-importlib-metadata dependency can be dropped entirely once
Python 3.8 is the minimum available python version (LP: #1851393).
-- Corey Bryant Mon, 10 Feb 2020 09:18:35 -0500
Can you please apply too?
./requirements/default.txt:importlib-metadata>=0.18; python_version<"3.8"
./extra/requirements/default.txt:importlib-metadata>=0.18; python_version<"3.8"
trivial patch:
diff -Nru kombu-4.6.11/debian/control kombu-4.6.11/debian/control
--- kombu-4.6.11/debian/control 2020-07-01 07:14:18.0 +0200
+++ kombu-4.6.11/debian/control 2020-07-01 18:31:32.0 +0200
@@ -20,7 +20,6 @@
python3-botocore ,
python3-case ,
python3-django ,
- python3-importlib-metadata ,
python3-mock ,
python3-msgpack ,
python3-pymongo ,
@@ -70,7 +69,6 @@
Depends:
python3-amqp (>= 1.4.6),
python3-anyjson (>= 0.3.3),
- python3-importlib-metadata,
${misc:Depends},
${python3:Depends},
Recommends:
Bug#870383: gpgme1.0: FTBFS on hurd-i386: hardinging flags mismatch w.r.t. Qt5
control: forwarded -1 https://dev.gnupg.org/T4982 thanks G.
Bug#963294: cmake-format: FTBFS: ./.pybuild/cpython3_3.8/build/CMakeFiles/CMakeTmp/./.pybuild/cpython3_3.8/build/CMakeFiles/CMakeTmp/src.c:11: undefined reference to `pthread_create'
> > if you rebuild locally after the first build, the counter increases
> > to 60%.
>
> Which choice becomes 60%?
pybuild, and I suspect it increases because of the .egg-info directory.
>
> cmake plugin has (the number is the extra score):
>
> OPTIONAL_FILES = {'cmake_uninstall.cmake': 10, 'CMakeCache.txt': 10}
>
> while distutils has:
>
> OPTIONAL_FILES = {'setup.cfg': 1,
> 'requirements.txt': 1,
> 'PKG-INFO': 10,
Yes, I saw your upload thanks for it! I was just trying to put my analysis
written somewhere before I forget about it :)
some ordering issue might be the case, because even after installing all the
files that are in the sbuild image
(via apt-get install after looking at the packages list on the chroot), I
couldn't reproduce the Ubuntu builders
behaviour.
G.
Bug#963294: cmake-format: FTBFS: ./.pybuild/cpython3_3.8/build/CMakeFiles/CMakeTmp/./.pybuild/cpython3_3.8/build/CMakeFiles/CMakeTmp/src.c:11: undefined reference to `pthread_create'
Hello Ian,
> It seems like pybuild has some heuristics for picking the build plugin
> to use, for me (and buildd) it selects plugin_distutils.py but for you
> it is selecting plugin_cmake.py. I can't see why. If you somehow had a
> `CMakeCache.txt` in the package directory that might explain it, but
> there's no reason for one of those to be there (I assume you'd have
> said if this was e.g. a repeated build without cleaning the package dir
> in the middle, but even if it was I don't think I'd ).
>
> In the absence of a local repro I'm going to throw in a
> 'PYBUILD_SYSTEM=distutils' which ought to force things to go the
> desired way no matter what. Fingers crossed!
>
I agree on your analysis.
In Ubuntu the build has been failing since the begin, and for some reasons it
started being successful yesterday, before your upload.
I can say that I tried to use a patched pybuild
-log.debug('detected build system: %s (certainty: %s%%)', plugin.NAME,
certainty)
+log.info('detected build system: %s (certainty: %s%%)', plugin.NAME,
certainty)
and the certainty was 50% fixed
I: pybuild pybuild:131: detected build system: distutils (certainty: 50%)
versus
I: pybuild pybuild:131: detected build system: cmake (certainty: 50%)
I can say, on Ubuntu builders, cmake was always pick up (not since yesterday),
while on local pbuilder and Debian, distutils was pick up
if you rebuild locally after the first build, the counter increases to 60%.
I suspect this has to deal with the fact that the source has "cmake" in the
name or in the setup.py script
This is my wild guess, but teaching pybuild to don't care about it looks a sane
option.
Just my .02$
Gianfranco
Bug#963782: gpgme1.0: autopkgtest failure due to bash wrong syntax
Source: gpgme1.0 Version: 1.13.1-8 Severity: serious Tags: patch Hello, please accept this patch to fix a bad syntax. (two main issues, missing Processing triggers for libc-bin (2.31-0ubuntu10) ... (Reading database ... 78068 files and directories currently installed.) Removing autopkgtest-satdep (0) ... autopkgtest [15:17:55]: test checky2106: [--- unsigned long on this platform is 4 octets. This means that GPGME will fail when encountering expiration dates after 2106-02-07 06:28:16Z. Please see https://dev.gnupg.org/T4766 and https://dev.gnupg.org/T4826 for more details. /tmp/autopkgtest.FpdOQK/build.XhH/src/debian/tests/checky2106: line 25: [: missing `]' autopkgtest [15:17:57]: test checky2106: ---] autopkgtest [15:18:00]: test checky2106: - - - - - - - - - - results - - - - - - - - - - checky2106 FAIL non-zero exit status 1 autopkgtest [15:18:00]: test checky2106: - - - - - - - - - - stderr - - - - - - - - - - /tmp/autopkgtest.FpdOQK/build.XhH/src/debian/tests/checky2106: line 25: [: missing `]' autopkgtest [15:18:02]: summary python3 PASS checky2106 FAIL non-zero exit status 1 diff -Nru gpgme1.0-1.13.1/debian/changelog gpgme1.0-1.13.1/debian/changelog --- gpgme1.0-1.13.1/debian/changelog2020-06-26 10:16:00.0 +0200 +++ gpgme1.0-1.13.1/debian/changelog2020-06-26 23:44:40.0 +0200 @@ -1,3 +1,9 @@ +gpgme1.0 (1.13.1-8ubuntu2) groovy; urgency=medium + + * Fix test sadness on 32bit systems due to bad bash syntax. + + -- Gianfranco Costamagna Fri, 26 Jun 2020 23:44:40 +0200 + gpgme1.0 (1.13.1-8ubuntu1) groovy; urgency=low * Merge from Debian unstable. Remaining changes: diff -Nru gpgme1.0-1.13.1/debian/tests/checky2106 gpgme1.0-1.13.1/debian/tests/checky2106 --- gpgme1.0-1.13.1/debian/tests/checky2106 2020-06-26 10:15:43.0 +0200 +++ gpgme1.0-1.13.1/debian/tests/checky2106 2020-06-26 23:44:17.0 +0200 @@ -22,8 +22,8 @@ Please see https://dev.gnupg.org/T4766 and https://dev.gnupg.org/T4826 for more details. " "$sz" "$limit" -if [ "$(dpkg-architecture -qDEB_HOST_ARCH_BITS)" == 32 && - $(date +%s) -lt $(TZ=UTC date +%s 2031-02-07) ]; then +if [ "$(dpkg-architecture -qDEB_HOST_ARCH_BITS)" == 32 ] && +[ $(date +%s) -lt $(TZ=UTC date +%s --date='2031-02-07') ]; then printf "We permit skipping this test during autopkgtest until 75 years before the cutoff. thanks! Gianfranco
Bug#963749: r-bioc-rwikipathways: non-installable in sid
Source: r-bioc-rwikipathways Version: 1.6.1+dfsg-1 Severity: serious Hello, for some reasons, dh-r is evaluating wrongly the runtime dependency on r-api-bioc (maybe from DESCRIPTION file?) dpkg: dependency problems prevent configuration of r-bioc-rwikipathways: r-bioc-rwikipathways depends on r-api-bioc-3.10; however: Package r-api-bioc-3.10 is not installed. this makes the package non-installable. (please reassign to r-base if you think the problem is there) thanks for having a look! Gianfranco
Bug#963546: meson: autopkgtest failures
On Fri, 26 Jun 2020 11:38:34 +0300 Jussi Pakkanen wrote: > On Fri, 26 Jun 2020 at 10:48, Gianfranco Costamagna > wrote: > > > I asked in Ubuntu to move the meson autopkgtests to a machine with more ram > > memory, and > > now the test passes. > > The Ubuntu VMs have 1536MB of ram, probably not enough for the testsuite to > > pass. > > Good that it works, but that seems a bit strange. I run the test suite > on an x86 Debian VM with 4 gigs of ram and it passes without problems. > > Probably if you lower the 4GB to 1.5GB you will get the same failure? IIRC when I tried with a value around 2GB everything was good... G.
Bug#870383: gpgme1.0: FTBFS on hurd-i386: hardinging flags mismatch w.r.t. Qt5
control: tags -1 patch Hello, the patch from Ubuntu seems enough to do the trick, can you please forward upstream? I'm still waiting for my account to get accepted on dev.gnupg.org (I just registered) diff -pruN 1.13.1-7/debian/patches/0006-PIC-and-shared.patch 1.13.1-7ubuntu2/debian/patches/0006-PIC-and-shared.patch --- 1.13.1-7/debian/patches/0006-PIC-and-shared.patch 1970-01-01 00:00:00.0 + +++ 1.13.1-7ubuntu2/debian/patches/0006-PIC-and-shared.patch2017-05-12 07:22:23.0 + @@ -0,0 +1,19 @@ +Description: Use -fPIC instead of -fpic. +Author: Adam Conrad +Last-Update: 2017-05-12 + +Index: gpgme1.0-1.8.0/m4/qt.m4 +=== +--- gpgme1.0-1.8.0.orig/m4/qt.m4 gpgme1.0-1.8.0/m4/qt.m4 +@@ -24,8 +24,9 @@ AC_DEFUN([FIND_QT], + [have_qt5test_libs="no"]) + + if ! test "$have_w32_system" = yes; then ++GPGME_QT_CFLAGS="$GPGME_QT_CFLAGS -shared" + if "$PKG_CONFIG" --variable qt_config Qt5Core | grep -q "reduce_relocations"; then +- GPGME_QT_CFLAGS="$GPGME_QT_CFLAGS -fpic" ++ GPGME_QT_CFLAGS="$GPGME_QT_CFLAGS -fPIC" + fi + fi + if test "$have_qt5_libs" = "yes"; then diff -pruN 1.13.1-7/debian/patches/series 1.13.1-7ubuntu2/debian/patches/series --- 1.13.1-7/debian/patches/series 2020-01-30 16:37:46.0 + +++ 1.13.1-7ubuntu2/debian/patches/series 2020-02-14 00:43:13.0 + @@ -5,3 +5,4 @@ 0005-tests-json-Bravo-key-does-not-have-secret-key-materi.patch 0006-gpg-Send-with-keygrip-when-listing-keys.patch 0007-use-FULL_PATH_NAMES-NO-for-reproducible-doxygen-docu.patch +0006-PIC-and-shared.patch thanks Gianfranco
Bug#963546: meson: autopkgtest failures
Hello, > > Interesting, this might explain also why I cannot replicate it under a > pbuilder environment... > Can we try to lower the ninja parallelism to see if the build ends correctly? > I suspect this might be an issue with Debian too, in the near future (e.g. > new gcc-10 defaults) > I asked in Ubuntu to move the meson autopkgtests to a machine with more ram memory, and now the test passes. The Ubuntu VMs have 1536MB of ram, probably not enough for the testsuite to pass. I hope Debian won't have the same problem in the near future, but for now the problem in Ubuntu is solved. G.
Bug#963681: primus-vk: please don't require bumblebee-nvidia on Ubuntu/ppc64el
addressed in https://salsa.debian.org/nvidia-team/primus-vk/-/merge_requests/10 G.
Bug#963681: primus-vk: please don't require bumblebee-nvidia on Ubuntu/ppc64el
Source: primus-vk Version: 1.5-1 Severity: important tags: patch trivial patch attached: (bumblebee-nvidia is not built on ppc64el) diff -Nru primus-vk-1.5/debian/changelog primus-vk-1.5/debian/changelog --- primus-vk-1.5/debian/changelog 2020-06-11 15:00:43.0 +0200 +++ primus-vk-1.5/debian/changelog 2020-06-25 10:12:17.0 +0200 @@ -1,3 +1,9 @@ +primus-vk (1.5-1.1) unstable; urgency=medium + + * Don't require bumblebee-nvidia on Ubuntu on ppc64el (Closes: #-1) + + -- Gianfranco Costamagna Thu, 25 Jun 2020 10:12:17 +0200 + primus-vk (1.5-1) unstable; urgency=medium * New upstream release. diff -Nru primus-vk-1.5/debian/rules primus-vk-1.5/debian/rules --- primus-vk-1.5/debian/rules 2020-06-11 15:00:43.0 +0200 +++ primus-vk-1.5/debian/rules 2020-06-25 10:12:15.0 +0200 @@ -9,7 +9,7 @@ nv_libs_Debian += nvidia-legacy-390xx-nonglvnd-vulkan-icd_[!ppc64el] nv_libs_Debian += nvidia-vulkan-icd-any -nv_libs_Ubuntu += bumblebee-nvidia +nv_libs_Ubuntu += bumblebee-nvidia_[!ppc64el] VENDOR := $(shell dpkg-vendor --derives-from Ubuntu && echo Ubuntu || echo Debian)
Bug#963546: meson: autopkgtest failures
Hello, On Wed, 24 Jun 2020 02:08:23 +0300 Jussi Pakkanen wrote: > On Tue, 23 Jun 2020 at 16:36, Gianfranco Costamagna > wrote: > > > Hello, as you can see, two tests can't be run on ppc64el and s390x, because > > of missing: > > g++-arm-linux-gnueabihf and ldc > > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/m/meson/6017346/log.gz > > Marking the two tests as "skip-not-installed" works > > Thanks, this will be in the next upload. double thanks! > > > Also, I noticed a failure on Ubuntu: > > c++ -Iextralibexe@exe -I. '-I../test cases/frameworks/1 boost' > > -I/usr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 > > -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++14 -g -pthread > > -DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 > > -DBOOST_LOG_SETUP_DYN_LINK=1 -DBOOST_THREAD_BUILD_DLL=1 > > -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_THREAD_USE_DLL=1 -DBOOST_LOG_DYN_LINK=1 > > -DBOOST_ALL_NO_LIB -MD -MQ 'extralibexe@exe/extralib.cpp.o' -MF > > 'extralibexe@exe/extralib.cpp.o.d' -o 'extralibexe@exe/extralib.cpp.o' -c > > '../test cases/frameworks/1 boost/extralib.cpp' > > c++: fatal error: Killed signal terminated program cc1plus > > > > do you have any clue? > > At this point Meson is no longer involved. Ninja has invoked c++ and > that process then crashes. Running that command by hand in the same > system should result in the same crash. > > From what I can tell this is either a bug in GCC or there is some > watchdog that kills the process for whatever reason such as running > out of memory. The latter can be a symptom of the former. > Interesting, this might explain also why I cannot replicate it under a pbuilder environment... Can we try to lower the ninja parallelism to see if the build ends correctly? I suspect this might be an issue with Debian too, in the near future (e.g. new gcc-10 defaults) G.
Bug#963546: meson: autopkgtest failures
Source: meson Version: 0.54.3-1 Severity: serious Hello, as you can see, two tests can't be run on ppc64el and s390x, because of missing: g++-arm-linux-gnueabihf and ldc https://ci.debian.net/data/autopkgtest/unstable/ppc64el/m/meson/6017346/log.gz Marking the two tests as "skip-not-installed" works diff -Nru meson-0.54.3/debian/tests/control meson-0.54.3/debian/tests/control --- meson-0.54.3/debian/tests/control 2020-03-27 23:40:23.0 + +++ meson-0.54.3/debian/tests/control 2020-06-23 13:25:22.0 + @@ -10,6 +10,8 @@ # tests are run and thus block broken uploads. Tests: exhaustive Depends: meson, @builddeps@, valac, rustc, ldc +Restrictions: skip-not-installable Tests: crossbuild Depends: meson, g++, g++-arm-linux-gnueabihf +Restrictions: skip-not-installable Also, I noticed a failure on Ubuntu: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/m/meson/20200616_020946_f376b@/log.gz Failed test during build: 'test cases/frameworks/1 boost (static=false)' Reason: Compiling source code failed. Skipping: test cases/frameworks/1 boost (static=false b_vscrt=md) Skipping: test cases/frameworks/1 boost (static=false b_vscrt=mdd) Succeeded test: test cases/frameworks/1 boost (static=true) Skipping: test cases/frameworks/1 boost (static=true b_vscrt=md) Skipping: test cases/frameworks/1 boost (static=true b_vscrt=mdd) Skipping: test cases/frameworks/1 boost (static=true b_vscrt=mt) Skipping: test cases/frameworks/1 boost (static=true b_vscrt=mtd) Mesonlogs of failing tests The Meson build system Version: 0.54.3 Source dir: /tmp/autopkgtest.u568ol/build.zhB/src/test cases/frameworks/1 boost Build dir: /tmp/autopkgtest.u568ol/build.zhB/src/b 125f976e40 Build type: native build Project name: boosttest Project version: undefined C++ compiler for the host machine: c++ (gcc 9.3.0 "c++ (Ubuntu 9.3.0-13ubuntu1) 9.3.0") C++ linker for the host machine: c++ ld.bfd 2.34 Host machine cpu family: x86_64 Host machine cpu: x86_64 Found pkg-config: /usr/bin/pkg-config (0.29.2) Run-time dependency Boost found: YES 1.71.0 (/usr/include) Run-time dependency Boost (found: date_time, system, thread) found: YES 1.71.0 (/usr) Run-time dependency Boost (found: unit_test_framework) found: YES 1.71.0 (/usr) Dependency boost found: YES 1.71.0 (cached) Run-time dependency Boost (found: date_time, filesystem, log, log_setup, regex, system, thread) found: YES 1.71.0 (/usr) Run-time dependency Boost (missing: this_should_not_exist_on_any_systen) found: NO Program python2 found: YES (/usr/bin/python2) Program python3 found: YES (/usr/bin/python3) test cases/frameworks/1 boost/meson.build:27: WARNING: Passed invalid keyword argument "disabler". WARNING: This will become a hard error in the future. Dependency python found: NO test cases/frameworks/1 boost/meson.build:28: WARNING: Passed invalid keyword argument "disabler". WARNING: This will become a hard error in the future. Dependency python found: YES (pkgconfig) Run-time dependency Boost (found: python38) found: YES 1.71.0 (/usr) Program /usr/bin/python2 found: YES (/usr/bin/python2) Program /usr/bin/python3 found: YES (/usr/bin/python3) Run-time dependency Boost found: YES 1.71.0 (/usr/include) Dependency boost found: YES 1.71.0 (cached) Build targets in project: 7 Found ninja-1.10.0 at /usr/bin/ninja [1/14] Compiling C++ object 'utf@exe/unit_test.cpp.o' [2/14] Linking target utf [3/14] Compiling C++ object 'nomod@exe/nomod.cpp.o' [4/14] Linking target nomod [5/14] Compiling C++ object 'linkedexe@exe/linkexe.cc.o' [6/14] Linking target linkedexe [7/14] Compiling C++ object 'extralibexe@exe/extralib.cpp.o' FAILED: extralibexe@exe/extralib.cpp.o c++ -Iextralibexe@exe -I. '-I../test cases/frameworks/1 boost' -I/usr/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++14 -g -pthread -DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_SETUP_DYN_LINK=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_THREAD_USE_DLL=1 -DBOOST_LOG_DYN_LINK=1 -DBOOST_ALL_NO_LIB -MD -MQ 'extralibexe@exe/extralib.cpp.o' -MF 'extralibexe@exe/extralib.cpp.o.d' -o 'extralibexe@exe/extralib.cpp.o' -c '../test cases/frameworks/1 boost/extralib.cpp' c++: fatal error: Killed signal terminated program cc1plus compilation terminated. [8/14] Compiling C++ object 'python3_module@sha/python_module.cpp.o' ninja: build stopped: subcommand failed. ninja explain: deps for 'linkedexe@exe/linkexe.cc.o' are missing ninja explain: linkedexe@exe/linkexe.cc.o is dirty ninja explain: linkedexe is dirty ninja explain: deps for 'utf@exe/unit_test.cpp.o' are missing ninja explain: utf@exe/unit_test.cpp.o is dirty ninja explain: utf is dirty ninja explain: deps for 'nomod@exe/nomod.cpp.o' are missing ninja explain: nomod@exe/nomod.cpp.o is dirty ninja explain: nomod is dirty ninja explain: deps for
Bug#963538: reverse-depends command is broken because qa.ubuntuwire.org is down
control: close -1 On Tue, 23 Jun 2020 15:25:08 +0530 Pirate Praveen wrote: > Package: ubuntu-dev-tools > Version: 0.176 > Severity: grave > Justification: ships a broken command > > reverse-depends command queries qa.ubuntuwire.org which is down. This > is a very useful command and we should get the service up again or > possibly run on debian infra if it is down permanently. > the service is back, but yes, if somebody gets the source code for ubuntuwire.org service and replicates in Debian, the tool can be easily adapted to work with two different infrastructures! G.
Bug#963539: npm: autopkgtests failures on various architectures
Source: npm Version: 6.14.5+ds-1 Severity: serious Hello, looks like npm is failing again its autopkgtests... On armhf there is a timeout that I "fixed" with: https://github.com/npm/cli/pull/1454 on ppc64el there is another failure: https://ci.debian.net/data/autopkgtest/unstable/ppc64el/n/npm/6017343/log.gz and I also spot a s390x failure on Ubuntu: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/n/npm/20200505_235736_15e60@/log.gz can you please have another look? (in the meanwhile I'm marking that test as flaky in Ubuntu) thanks! Gianfranco
Bug#963484: openscap: please cherry-pick upstream fix for dpkginfo_free_reply
Source: openscap Version: 1.2.17-0.1 Severity: important Hello, can you please cherry-pick upstream commit 5e5bc61c1fc6a6556665aa5689a62d6bc6487c74 already merged in maint-1.3 branch? thanks, it seems to be fixing some build failures with newer gcc or so, not sure why Ubuntu applied it, the patch comes from RedHat, merged in https://github.com/OpenSCAP/openscap/pull/1387 G.
Bug#963177: calendar: trying to overwrite '/etc/calendar/default', which is also in package bsdmainutils 12.1.1
Hello Josh On Sun, 21 Jun 2020 14:20:06 -0700 Josh Triplett wrote: > On Sun, 21 Jun 2020 04:05:43 +0200 Chris Hofstaedtler wrote: > > Hi Josh, > > > > I figured you might be interested in this, too, as IIRC the original > > patch was from you: > > > > * Thorsten Glaser [200621 02:04]: > > > Selecting previously unselected package calendar. > > > (Reading database ... 406194 files and directories currently installed.) > > > Preparing to unpack .../calendar_12.1.1_x32.deb ... > > > Unpacking calendar (12.1.1) ... > > > dpkg: error processing archive > > > /var/cache/apt/archives/calendar_12.1.1_x32.deb (--unpack): > > > trying to overwrite '/etc/calendar/default', which is also in package > > > bsdmainutils 12.1.1 > > > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) > > > Errors were encountered while processing: > > > /var/cache/apt/archives/calendar_12.1.1_x32.deb > > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > Ah. When I originally sent the patch, I believe I included appropriate > Breaks/Replaces headers to make sure this wouldn't happen, but it looks > like the version that incorporated the patch had advanced past the > version numbers in the Breaks/Replaces. The version numbers in the > Breaks/Replaces need updating. I opened a merge request, can you please double check my change? https://salsa.debian.org/meskes/bsdmainutils/-/merge_requests/4/diffs thanks! G.
Bug#963133: wine-development: FTBFS on arm64 with new llvm
Source: wine-development Version: 5.5-4 Severity: normal tags: patch Hello, I just disabled the warnigs... diff -Nru wine-development-5.5/debian/patches/arm64.patch wine-development-5.5/debian/patches/arm64.patch --- wine-development-5.5/debian/patches/arm64.patch 1970-01-01 01:00:00.0 +0100 +++ wine-development-5.5/debian/patches/arm64.patch 2020-03-31 13:01:53.0 +0200 @@ -0,0 +1,49 @@ +--- wine-development-5.2.orig/dlls/dbghelp/Makefile.in wine-development-5.2/dlls/dbghelp/Makefile.in +@@ -2,6 +2,7 @@ MODULE= dbghelp.dll + IMPORTLIB = dbghelp + EXTRADEFS = -D_IMAGEHLP_SOURCE_ + DELAYIMPORTS = version ++CFLAGS += -Wno-misleading-indentation + EXTRAINCL = $(Z_CFLAGS) + EXTRALIBS = $(Z_LIBS) $(CORESERVICES_LIBS) $(COREFOUNDATION_LIBS) + +--- wine-development-5.2.orig/dlls/dsound/Makefile.in wine-development-5.2/dlls/dsound/Makefile.in +@@ -1,5 +1,6 @@ + MODULE= dsound.dll + IMPORTLIB = dsound ++CFLAGS += -Wno-implicit-int-float-conversion + IMPORTS = dxguid uuid winmm ole32 advapi32 user32 ucrtbase + + EXTRADLLFLAGS = -mno-cygwin +--- wine-development-5.2.orig/dlls/msdmo/Makefile.in wine-development-5.2/dlls/msdmo/Makefile.in +@@ -1,6 +1,7 @@ + MODULE= msdmo.dll + IMPORTLIB = msdmo + IMPORTS = dmoguids uuid ole32 user32 advapi32 ++CFLAGS += -Wno-sizeof-array-div + + EXTRADLLFLAGS = -mno-cygwin + +--- wine-development-5.2.orig/dlls/kernelbase/Makefile.in 2020-03-30 11:19:47.0 +0200 wine-development-5.2/dlls/kernelbase/Makefile.in 2020-03-31 14:04:50.922976338 +0200 +@@ -1,6 +1,7 @@ + MODULE= kernelbase.dll + IMPORTLIB = kernelbase + IMPORTS = uuid ntdll winecrt0 ++CFLAGS += -Wno-array-bounds + EXTRADLLFLAGS = -nodefaultlibs -nostartfiles -mno-cygwin -Wl,--image-base,0x7b00 + + C_SRCS = \ +--- wine-development-5.2.orig/dlls/ntoskrnl.exe/Makefile.in2020-03-31 15:35:54.238661128 +0200 wine-development-5.2/dlls/ntoskrnl.exe/Makefile.in 2020-03-31 15:34:59.190755200 +0200 +@@ -2,6 +2,7 @@ MODULE= ntoskrnl.exe + IMPORTLIB = ntoskrnl + IMPORTS = advapi32 hal msvcrt + DELAYIMPORTS = setupapi user32 ++CFLAGS += -Wno-array-bounds + + EXTRADLLFLAGS = -mno-cygwin + diff -Nru wine-development-5.5/debian/patches/series wine-development-5.5/debian/patches/series --- wine-development-5.5/debian/patches/series 2020-06-14 00:58:54.0 +0200 +++ wine-development-5.5/debian/patches/series 2020-06-19 11:19:14.0 +0200 @@ -51,3 +51,4 @@ warnings/discarded-qualifiers.patch warnings/incompatible-pointers.patch warnings/uninitialized-variables.patch +arm64.patch thanks for having a look! Gianfranco
Bug#962402: haskell-text-icu built
control: severity -1 important On Sat, 13 Jun 2020 18:59:12 +0300 Adrian Bunk wrote: > On Fri, Jun 12, 2020 at 09:49:21PM +0200, Frédéric Bonnard wrote: > > Hi, > > I wanted to check that FTBFS but it actually built, on different setup. > > After a give back on ppc64el and s390x, everything went fine. Very few > > changes between the failing and succeeding build. Same ghc, kernel. > > For the record, linux-libc-dev, libgmpxx4ldbl, libgmp-dev, libkrb5support0, > > libk5crypto3, libkrb5-3, libgssapi-krb5-2, libnghttp2-14, hscolour were > > not the same. > > Both the buildd failures and the build failures in the reproducible CI > look as if the failure is random, perhaps with a different probability > depending on some unknown factor. Hello, I propose to downgrade to important, and raise back if we still experience the issue... Gianfranco
Bug#962936: sane-backends: please still keep libsane transitional package around
Hello, after thinking a little bit more, a Provides might even be enough to satisfy the dependency. To reproduce this issue: pbuilder-dist sid login apt-get install sane-utils add experimental repo: apt-get dist-upgrade -t experimental Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: acl cpp-9 fontconfig-config fonts-dejavu-core g++-9 gcc-9 libavahi-client3 libavahi-common-data libavahi-common3 libbsd0 libdbus-1-3 libexif12 libexpat1 libfontconfig1 libfreetype6 libgcc-9-dev libgd3 libgphoto2-6 libgphoto2-port12 libicu67 libieee1284-3 libjbig0 libjpeg62-turbo libkmod2 libpci3 libpng16-16 libsane-common libsensors-config libsensors5 libsnmp-base libsnmp35 libssl1.1 libstdc++-9-dev libtiff5 libusb-1.0-0 libwebp6 libwrap0 libx11-6 libx11-data libxau6 libxcb1 libxdmcp6 libxml2 libxpm4 pci.ids sensible-utils ucf udev update-inetd Use 'sudo apt autoremove' to remove them. The following packages will be REMOVED: libsane sane-utils The following NEW packages will be installed: cpp-10 g++-10 gcc-10 libasan6 libgcc-10-dev libstdc++-10-dev The following packages will be upgraded: binutils binutils-common binutils-x86-64-linux-gnu cpp dpkg dpkg-dev e2fsprogs g++ gcc libaudit-common libaudit1 libbinutils libc-bin libc-dev-bin libc6 libc6-dev libcom-err2 libctf-nobfd0 libctf0 libdbus-1-3 libdpkg-perl libext2fs2 libjpeg62-turbo libsane-common libselinux1 libsepol1 libss2 linux-libc-dev logsave 29 upgraded, 6 newly installed, 2 to remove and 0 not upgraded. Need to get 57.3 MB/57.3 MB of archives. After this operation, 140 MB of additional disk space will be used. Do you want to continue? [Y/n] Looks like it is trying to remove libsane and sane-utils instead of upgrading the latter G.
Bug#913346: libsane1: Cannot update libsane1
control: close -1 Hello, at the end the rename has been renamed again in experimental so this bug can be closed. However, since many packages outside Debian might need libsane and not libsane1 I opened a new bug report to track this: https://bugs.debian.org/962936 G. On Mon, 21 Jan 2019 09:47:49 -0500 Jeremy Bicha wrote: > On Mon, Jan 21, 2019 at 9:23 AM John Paul Adrian Glaubitz > wrote: > > Well, I have a different opinion on that. I do not consider a temporary > > issue in unstable a bug affecting anything but developers. > > 3 months isn't temporary. While I think Testing is a better fit for > users than Unstable (maybe we agree there), there are huge numbers of > people and writings that argue that users should use Unstable instead > because "Testing has no security guarantees". > > > I'm not sure why you are resorting to the Release Team here? What does the > > Release Team have to do with unstable which isn't even a release? > > Because you're "appealing to authority" by asking me to prove that > there is a bug here. I think we all agree that the Debian Release Team > can decide what is an RC bug. But I guess you're going to nitpick and > argue that the Release Team has no authority over Unstable and we > shouldn't even consider their opinion then… > > > Why is Ubuntu importing packages with RC bugs open? Shouldn't that > > be blocked? > > I did block it: Ubuntu itself never had this bug because it was > blocked in the "devel-proposed" section which even developers aren't > supposed to be using. > > Let me be more direct here: I don't understand why you are blocking > this bug fix. You don't even have to do the upload yourself: just > apply the patch that has been given and allow Gianfranco to do the > NMU. How does accepting this bugfix hurt anybody? > > Thanks, > Jeremy Bicha > >
Bug#962936: sane-backends: please still keep libsane transitional package around
Source: sane-backends
Version: 1.0.30-1~experimental2
Severity: serious
Hello, I tried to upgrade from the old sane-backends to the new one, and
libsane in some condition
was not removed, and sane-utils were removed as result.
I don't know how and why, but adding back libsane as transitional package
helped in doing the upgrade in a smooth
way.
The trivial patch uploaded in Ubuntu is here:
diff -Nru sane-backends-1.0.30/debian/changelog
sane-backends-1.0.30/debian/changelog
--- sane-backends-1.0.30/debian/changelog 2020-05-31 07:23:01.0
+
+++ sane-backends-1.0.30/debian/changelog 2020-06-14 11:36:40.0
+
@@ -1,3 +1,11 @@
+sane-backends (1.0.30-1~experimental2ubuntu1) groovy; urgency=medium
+
+ * Sync from debian experimental, Remaining changes:
+- add back libsane transitional package, to ease upgrades.
+ (this can be dropped after 22.04)
+
+ -- Gianfranco Costamagna Sun, 14 Jun 2020
13:36:40 +0200
+
sane-backends (1.0.30-1~experimental2) experimental; urgency=medium
* debian/not-installed:
diff -Nru sane-backends-1.0.30/debian/control
sane-backends-1.0.30/debian/control
--- sane-backends-1.0.30/debian/control 2020-05-26 10:15:40.0 +
+++ sane-backends-1.0.30/debian/control 2020-06-14 11:36:38.0 +
@@ -131,3 +131,24 @@
.
This package contains the files needed to build your applications
using SANE.
+
+Package: libsane
+Architecture: any
+Multi-Arch: same
+Section: oldlibs
+Depends:
+ libsane1 (>= ${source:Version}),
+ ${misc:Depends}
+Description: API library for scanners [transitional package]
+ SANE stands for "Scanner Access Now Easy" and is an application
+ programming interface (API) that provides standardized access to any
+ raster image scanner hardware (flatbed scanner, hand-held scanner,
+ video- and still-cameras, frame-grabbers, etc.). The SANE standard is
+ free and its discussion and development are open to everybody. The
+ current source code is written to support several operating systems,
+ including GNU/Linux, OS/2, Win32 and various Unices and is available
+ under the GNU General Public License (commercial applications and
+ backends are welcome, too, however).
+ .
+ This package is here to ensure smooth upgrades. It can be removed when
+ you see fit.
thanks for considering it!
Gianfranco
Bug#962725: gst-plugins-bad1.0: depend on cruft package libsrt-dev
Source: gst-plugins-bad1.0 Version: 1.16.2-2.1 Severity: serious tags: patch Hello, I choose the gnutls flavour, matching what ffmpeg did (libsrt was mentioned twice, I removed one of the two) this is the patch: diff --git a/debian/build-deps b/debian/build-deps index 01a6f775..f3d4f4d0 100644 --- a/debian/build-deps +++ b/debian/build-deps @@ -65,7 +65,7 @@ librtmp-dev libsndfile1-dev (>= 1.0.16) libsoundtouch-dev (>= 1.5.0) libspandsp-dev -libsrt-dev +libsrt-gnutls-dev libsrtp2-dev (>= 2.1) libssl-dev libtool (>= 2.2.6) diff --git a/debian/build-deps.in b/debian/build-deps.in index bca081f3..41fe2883 100644 --- a/debian/build-deps.in +++ b/debian/build-deps.in @@ -81,6 +81,6 @@ liblcms2-dev (>= 2.7) libopenmpt-dev libnice-dev (>= 0.1.14) libpango1.0-dev (>= 1.22) -libsrt-dev +libsrt-gnutls-dev libaom-dev libusrsctp-dev diff --git a/debian/control b/debian/control index 7c8b9160..1163c0d8 100644 --- a/debian/control +++ b/debian/control @@ -16,7 +16,6 @@ Build-Depends: libasound2-dev (>= 0.9.1) [linux-any], libdrm-dev (>= 2.4.55) [linux-any], wayland-protocols (>= 1.4) [linux-any], libvulkan-dev [linux-any], - libsrt-dev [linux-any], libgstreamer1.0-dev (>= 1.16.1), autoconf (>= 2.69), automake (>= 1.14), @@ -83,7 +82,7 @@ Build-Depends: libasound2-dev (>= 0.9.1) [linux-any], libsndfile1-dev (>= 1.0.16), libsoundtouch-dev (>= 1.5.0), libspandsp-dev, - libsrt-dev, + libsrt-gnutls-dev, libsrtp2-dev (>= 2.1), libssl-dev, libtool (>= 2.2.6), diff --git a/debian/rules b/debian/rules index dca960d8..2751a2e3 100755 --- a/debian/rules +++ b/debian/rules @@ -74,7 +74,6 @@ gst_extra_build_depends += , libwayland-dev (>= 1.11.0) [linux-any] gst_extra_build_depends += , libdrm-dev (>= 2.4.55) [linux-any] gst_extra_build_depends += , wayland-protocols (>= 1.4) [linux-any] gst_extra_build_depends += , libvulkan-dev [linux-any] -gst_extra_build_depends += , libsrt-dev [linux-any] PLUGINS += plugins-bad opencv ifeq ($(DEB_HOST_ARCH_OS),linux)
Bug#962720: gst-plugins-bad1.0: FTBFS in sid
Also this patch https://aur.archlinux.org/cgit/aur.git/tree/0001-vulkan-Drop-use-of-VK_RESULT_BEGIN_RANGE.patch?h=lib32-gst-plugins-bad looks needed because of new mesa G.
Bug#962624: libsrt1-openssl: missing Breaks+Replaces
control: tags -1 patch
(patch uploaded in Ubuntu)
--- srt-1.4.1/debian/changelog 2020-06-10 21:33:17.0 +0200
+++ srt-1.4.1/debian/changelog 2020-06-12 13:10:33.0 +0200
@@ -1,3 +1,9 @@
+srt (1.4.1-3.1) unstable; urgency=medium
+
+ * Add breaks/replaces to ease upgrades (Closes: #962624)
+
+ -- Gianfranco Costamagna Fri, 12 Jun 2020
13:10:33 +0200
+
srt (1.4.1-3) unstable; urgency=medium
[ Jonas Smedegaard ]
diff -Nru srt-1.4.1/debian/control srt-1.4.1/debian/control
--- srt-1.4.1/debian/control2020-06-10 21:33:17.0 +0200
+++ srt-1.4.1/debian/control2020-06-12 13:10:33.0 +0200
@@ -18,9 +18,11 @@
Package: libsrt1-openssl
Architecture: any
+Breaks: libsrt1 (<< 1.4.1-3)
+Replaces: libsrt1 (<< 1.4.1-3)
Multi-Arch: same
Depends: ${shlibs:Depends}, ${misc:Depends}
-Conflicts: libsrt1-gnutls
+Conflicts: libsrt1-gnutls, libsrt1
Description: Secure Reliable Transport UDP streaming library (OpenSSL flavour)
SRT is a latency-aware UDP transport mechanism optimized for video streams.
It detects and compensates for jitter and bandwidth fluctuations due to
@@ -32,7 +34,7 @@
Architecture: any
Multi-Arch: same
Depends: ${shlibs:Depends}, ${misc:Depends}
-Conflicts: libsrt1-openssl
+Conflicts: libsrt1-openssl, libsrt1
Description: Secure Reliable Transport UDP streaming library (GnuTLS flavour)
SRT is a latency-aware UDP transport mechanism optimized for video streams.
It detects and compensates for jitter and bandwidth fluctuations due to
@@ -42,9 +44,11 @@
Package: libsrt-openssl-dev
Section: libdevel
+Breaks: libsrt-dev (<< 1.4.1-2)
+Replaces: libsrt-dev (<< 1.4.1-2)
Architecture: any
Multi-Arch: same
-Conflicts: libsrt-gnutls-dev
+Conflicts: libsrt-gnutls-dev, libsrt-dev
Depends: libsrt1-openssl (= ${binary:Version}), ${misc:Depends}
Suggests: libsrt-doc (= ${binary:Version}), libssl-dev (>= 1.1)
Description: Secure Reliable Transport UDP streaming library
@@ -57,9 +61,11 @@
Package: libsrt-gnutls-dev
Section: libdevel
+Breaks: libsrt-dev (<< 1.4.1-2)
+Replaces: libsrt-dev (<< 1.4.1-2)
Architecture: any
Multi-Arch: same
-Conflicts: libsrt-openssl-dev
+Conflicts: libsrt-openssl-dev, libsrt-dev
Depends: libsrt1-gnutls (= ${binary:Version}), ${misc:Depends}
Suggests: libsrt-doc (= ${binary:Version}), libgnutls28-dev
Description: Secure Reliable Transport UDP streaming library
Hello, I'm not sure about the fix I did
(libsrt1 and libsrt-dev should have been transitional packages probably, but
meh, they didn't live
that long to be needed probably).
Forcing their uninstallation, with breaks+replaces did the trick.
No need for the gnutls package to break/replaces the libsrt1 because files are
called in a different way
G.
On Wed, 10 Jun 2020 22:42:41 +0200 Sebastian Ramacher
wrote:
> Package: libsrt1-openssl
> Version: 1.4.1-2
> Severity: serious
>
> When installing libsrt1-openssl if libsrt1 is already installed:
>
> Preparing to unpack .../libsrt1-openssl_1.4.1-2_amd64.deb ...
> Unpacking libsrt1-openssl:amd64 (1.4.1-2) ...
> dpkg: error processing archive
> /var/cache/apt/archives/libsrt1-openssl_1.4.1-2_amd64.deb (--unpack):
> trying to overwrite '/usr/lib/x86_64-linux-gnu/libsrt.so.1.4.1', which is
> also in package libsrt1:amd64 1.4.1-1
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Selecting previously unselected package libsrt-openssl-dev:amd64.
> Preparing to unpack .../libsrt-openssl-dev_1.4.1-2_amd64.deb ...
>
> Same issue for libsrt-openssl-dev if libsrt-dev is already installed:
>
> Unpacking libsrt-openssl-dev:amd64 (1.4.1-2) ...
> dpkg: error processing archive
> /var/cache/apt/archives/libsrt-openssl-dev_1.4.1-2_amd64.deb (--unpack):
> trying to overwrite '/usr/include/srt/logging_api.h', which is also in
> package libsrt-dev:amd64 1.4.1-1
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Errors were encountered while processing:
> /var/cache/apt/archives/libsrt1-openssl_1.4.1-2_amd64.deb
> /var/cache/apt/archives/libsrt-openssl-dev_1.4.1-2_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> Cheers
> --
> Sebastian Ramacher
Bug#960144: srt: please package new upstream bugfix release 1.4.1
control: fixed -1 1.4.1-1 control: close -1 G. On Sat, 09 May 2020 23:10:40 +0200 Jonas Smedegaard wrote: > Source: srt > Severity: normal > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Upstream released a new bugfix release in December 2019. > > It includes some improvements and also fixes for several crashing issues. > > Please upgrade the package in Debian. > > Raising severity due to the nature of the changes to that release. > > - Jonas > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl63HE8ACgkQLHwxRsGg > ASGABQ//eNSAzImCrSYiJKRhj3683LtOGWTPHB07c6Q2/4ZGCCbD0PKCTxxU9NNS > Qi8NwghnoMG3sxe8NI2R/jIqbOGhUHBghRQ27Pji3L6tXTN6Yb/XAJs9f3Uj9zd2 > M/60iyCNv+R7e4gNX2jLLMNnWdAE5J+VTgdKsrDvQvm10qac0IV509xaWSLe9RLT > CBEvpiXOd0x49EiwVh96BcFCNkGevitLhTFcsS75gAdqaZU2yUdSt9A3B+QnbhJ9 > Z8PUS00x13+vzOZPoRL8Nhz0pZ+UWS65HsgPhth8KeQ6+2j1VjuF1h3LZyD99+md > rJbEaeX1JMqTfhM/k7XT+2DMmutlIxlFhByF5qHQeP5OQ/grgXL6c8+9F/T97+VB > /hInS6PUhEvqerYTjHvvLTQIQAnBJsOQXhGM43f7Gc3hhUCuMGcMOlHyqx6nz1Dj > /q83xRLAuG6Oy9TUsJgVEZXt/imd51EkPlOCUNKIBD9NZ5HPr96gwhHXjVODIsm+ > b1VnqBVPq8Ayi2txREO/T8u4iBL1ordbO60Cp8WDov91CrjVr+ESUylNZpW5qyXZ > gMcPahu2883FZPVIfCNdHmhxYy8SAZjZhAGQZy78QZ6SX/gGpQvm2jcwVlTjWU6G > n4EDwE0Yvc7ZemEkBSIzC7YhiSDonaiMPAaKmsRKn19ljkcp54A= > =HWAg > -END PGP SIGNATURE- > >
Bug#961986: re: lix FTBFS: Error: undefined identifier `FracSec`, did you mean function `fracSec`?
control: tags -1 pending
in deferred/2
thanks
Gianfranco
diff -Nru lix-0.9.29/debian/changelog lix-0.9.29/debian/changelog
--- lix-0.9.29/debian/changelog 2019-12-10 09:02:16.0 +0100
+++ lix-0.9.29/debian/changelog 2020-06-10 13:11:32.0 +0200
@@ -1,3 +1,13 @@
+lix (0.9.29-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+
+ [ Peter Michael Green ]
+ * Add patch from upstream pull request to fix build with new libphobos
+(Closes: 961986)
+
+ -- Gianfranco Costamagna Wed, 10 Jun 2020
13:11:32 +0200
+
lix (0.9.29-1) unstable; urgency=medium
* New upstream version. (Closes: #941390)
diff -Nru lix-0.9.29/debian/patches/phobos-2.091.patch
lix-0.9.29/debian/patches/phobos-2.091.patch
--- lix-0.9.29/debian/patches/phobos-2.091.patch1970-01-01
01:00:00.0 +0100
+++ lix-0.9.29/debian/patches/phobos-2.091.patch2020-06-10
13:11:09.0 +0200
@@ -0,0 +1,39 @@
+Patch taken from
https://github.com/Abscissa/SDLang-D/pull/70/commits/90e5bdad1d803a507b34d46c5ecf82cb1feb7cd4
+with paths adjusted to apply to the Debian lix package.
+
+commit 90e5bdad1d803a507b34d46c5ecf82cb1feb7cd4
+Author: Steven Schveighoffer
+Date: Fri Mar 20 17:26:58 2020 -0400
+
+Remove FracSec usage if not available in Phobos (2.091+) Fixes #68.
+
+diff --git a/sdlang-d-0.10.4/sdlang-d/src/sdlang/token.d
b/sdlang-d-0.10.4/sdlang-d/src/sdlang/token.d
+index 593746c..074c705 100644
+--- a/sdlang-d-0.10.4/sdlang-d/src/sdlang/token.d
b/sdlang-d-0.10.4/sdlang-d/src/sdlang/token.d
+@@ -24,9 +24,11 @@ struct DateTimeFrac
+ {
+ DateTime dateTime;
+ Duration fracSecs;
+- deprecated("Use fracSecs instead.") {
++ static if(is(FracSec)) {
++ deprecated("Use fracSecs instead.") {
+ @property FracSec fracSec() const { return
FracSec.from!"hnsecs"(fracSecs.total!"hnsecs"); }
+ @property void fracSec(FracSec v) { fracSecs = v.hnsecs.hnsecs;
}
++ }
+ }
+ }
+
+@@ -44,9 +46,11 @@ struct DateTimeFracUnknownZone
+ {
+ DateTime dateTime;
+ Duration fracSecs;
+- deprecated("Use fracSecs instead.") {
++ static if(is(FracSec)) {
++ deprecated("Use fracSecs instead.") {
+ @property FracSec fracSec() const { return
FracSec.from!"hnsecs"(fracSecs.total!"hnsecs"); }
+ @property void fracSec(FracSec v) { fracSecs = v.hnsecs.hnsecs;
}
++ }
+ }
+ string timeZone;
+
diff -Nru lix-0.9.29/debian/patches/series lix-0.9.29/debian/patches/series
--- lix-0.9.29/debian/patches/series2018-12-04 10:55:25.0 +0100
+++ lix-0.9.29/debian/patches/series2020-06-10 13:11:09.0 +0200
@@ -1 +1,2 @@
dub-i-dub-i-dub-dub-dub
+phobos-2.091.patch
Bug#955521: libsass: patch for using autopkgtests in cross-environments
hello, looks like I can't open a merge request from my forked project. this is the commit id: https://salsa.debian.org/locutusofborg/libsass/-/commit/b89fdbd02fb2d076a07a8d7bea0837efac866227 G.
Bug#955521: libsass: patch for using autopkgtests in cross-environments
control: tags -1 pending the attached diff has been uploaded in deferred/10 (I'll open shortly a merge request) cheers, Gianfranco On Wed, 1 Apr 2020 23:21:54 +0200 Gianfranco Costamagna wrote: > Source: libsass > Version: 3.6.3-1 > Tags: patch > Severity: important > > Hello, please apply the following patch from Steve Langasek to make it work > with ruby on i386 when cross-tested > > diff -Nru libsass-3.6.3/debian/changelog libsass-3.6.3/debian/changelog > --- libsass-3.6.3/debian/changelog 2020-02-28 12:04:53.0 +0100 > +++ libsass-3.6.3/debian/changelog 2020-04-01 13:55:07.0 +0200 > @@ -1,3 +1,10 @@ > +libsass (3.6.3-1.1) unstable; urgency=medium > + > + [ Steve Langasek ] > + * Use ruby:native to fix autopkgtests on cross-environments (Closes: #-1) > + > + -- Gianfranco Costamagna Wed, 01 Apr 2020 > 13:55:07 +0200 > + > libsass (3.6.3-1) unstable; urgency=medium > >[ upstream ] > diff -Nru libsass-3.6.3/debian/tests/control > libsass-3.6.3/debian/tests/control > --- libsass-3.6.3/debian/tests/control 2018-11-19 12:00:46.0 +0100 > +++ libsass-3.6.3/debian/tests/control 2020-04-01 13:55:05.0 +0200 > @@ -1,2 +1,2 @@ > Tests: spec > -Depends: ruby, sassc, sass-spec, sass-spec-data > +Depends: ruby:native, sassc, sass-spec, sass-spec-data > > > thanks > > Gianfranco > > diff -Nru libsass-3.6.4/debian/changelog libsass-3.6.4/debian/changelog --- libsass-3.6.4/debian/changelog 2020-06-08 22:25:22.0 +0200 +++ libsass-3.6.4/debian/changelog 2020-06-09 13:30:40.0 +0200 @@ -1,3 +1,12 @@ +libsass (3.6.4-2.1) unstable; urgency=medium + + * Non-maintainer upload. + + [ Steve Langasek ] + * Use ruby:native to fix autopkgtests on cross-environments (Closes: #955521) + + -- Gianfranco Costamagna Tue, 09 Jun 2020 13:30:40 +0200 + libsass (3.6.4-2) unstable; urgency=medium * simplifiy build; diff -Nru libsass-3.6.4/debian/tests/control libsass-3.6.4/debian/tests/control --- libsass-3.6.4/debian/tests/control 2018-07-01 10:00:08.0 +0200 +++ libsass-3.6.4/debian/tests/control 2020-06-09 13:29:56.0 +0200 @@ -1,2 +1,2 @@ Tests: spec -Depends: ruby, sassc, sass-spec, sass-spec-data +Depends: ruby:native, sassc, sass-spec, sass-spec-data
Bug#962434: ros-resource-retriever: calls home during build.
Source: ros-resource-retriever
Version: 1.12.6-1
Severity: serious
Hello, using internet during build is forbidden by policy, but still allowed in
Debian builders.
In Ubuntu, where this is more strictly forbidden, the failure seems to indicate
that the package
is trying to connect to internet during tests:
see e.g.
https://launchpad.net/ubuntu/+source/ros-resource-retriever/1.12.6-1/+build/19419607
[ FAILED ] 1 test, listed below:
[ FAILED ] Retriever.http
def test_http():
res = r.get("http://packages.ros.org/ros.key;)
assert len(res) > 0
thanks
Gianfranco
Bug#962329: cegui-mk2: please mark one symbol as optional
Source: cegui-mk2 Version: 0.8.7-7 tags: patch Hello, there is one symbol disappearing when the package is built with -O3 optimization level on ppc64el: --- cegui-mk2-0.8.7/debian/changelog2020-06-06 02:18:26.0 +0200 +++ cegui-mk2-0.8.7/debian/changelog2020-06-06 12:13:25.0 +0200 @@ -1,3 +1,9 @@ +cegui-mk2 (0.8.7-7.1) unstable; urgency=medium + + * Mark again one symbol as optional, disappearing on ppc64el with -O3 (Closes: #-1) + + -- Gianfranco Costamagna Sat, 06 Jun 2020 12:13:25 +0200 + cegui-mk2 (0.8.7-7) unstable; urgency=medium * Update symbols to fix FTBFS (Closes: #960378, #957076) diff -Nru cegui-mk2-0.8.7/debian/libcegui-mk2-0.8.7.symbols cegui-mk2-0.8.7/debian/libcegui-mk2-0.8.7.symbols --- cegui-mk2-0.8.7/debian/libcegui-mk2-0.8.7.symbols 2020-06-06 02:17:37.0 +0200 +++ cegui-mk2-0.8.7/debian/libcegui-mk2-0.8.7.symbols 2020-06-06 12:13:23.0 +0200 @@ -11375,7 +11375,7 @@ (optional=templinst)_ZNK5CEGUI25TplWindowRendererPropertyINS_24FalagardMultiLineEditboxEfE5cloneEv@Base 0.8.7 _ZNK5CEGUI8Property26initialisePropertyReceiverEPNS_16PropertyReceiverE@Base 0.8.7 _ZNKSt8_Rb_treeIN5CEGUI6StringESt4pairIKS1_PNS0_8PropertyEESt10_Select1stIS6_ENS0_21StringFastLessCompareESaIS6_EE4findERS3_@Base 0.8.7 - _ZNSt6vectorIN5CEGUI10RefCountedINS0_9BoundSlotEEESaIS3_EE12emplace_backIJS3_EEEvDpOT_@Base 0.8.7 + (optional=templinst)_ZNSt6vectorIN5CEGUI10RefCountedINS0_9BoundSlotEEESaIS3_EE12emplace_backIJS3_EEEvDpOT_@Base 0.8.7 _ZNSt6vectorIN5CEGUI10RefCountedINS0_9BoundSlotEEESaIS3_EE17_M_realloc_insertIJS3_EEEvN9__gnu_cxx17__normal_iteratorIPS3_S5_EEDpOT_@Base 0.8.7 (optional=GCC10_removed)_ZNSt6vectorIPN5CEGUI17FactoryRegistererESaIS2_EE12emplace_backIJS2_EEEvDpOT_@Base 0.8.7 _ZNSt6vectorIPN5CEGUI17FactoryRegistererESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base 0.8.7
Bug#962194: lintian-brush: autopkgtest failure on s390x
control: severity -1 serious Hello, (this is on zelenka) python3 test.py Traceback (most recent call last): File "test.py", line 16, in yaml.load(f) File "/usr/lib/python3/dist-packages/ruamel/yaml/main.py", line 331, in load return constructor.get_single_data() File "/usr/lib/python3/dist-packages/ruamel/yaml/constructor.py", line 109, in get_single_data node = self.composer.get_single_node() File "ext/_ruamel_yaml.pyx", line 701, in _ruamel_yaml.CParser.get_single_node File "ext/_ruamel_yaml.pyx", line 904, in _ruamel_yaml.CParser._parse_next_event ruamel.yaml.reader.ReaderError: unacceptable character #x: control characters are not allowed in "", position 244 So, yes, looks like yaml has an endianess issue? Can you please reassign to the appropriate library? thanks! Gianfranco
Bug#962263: nvidia-cuda-toolkit: missing libjpeg62-dev dependency
Source: nvidia-cuda-toolkit Version: 10.1.243-5 Severity: serious tags: patch Hello, looks like that control file is missing an explicit libjpeg62-dev dependency, and this fails when a different jpeg implementation is default in the system. dpkg-shlibdeps: error: cannot find library libjpeg.so.62 needed by debian/nvidia-openjdk-8-jre/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libsplashscreen.so (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64') --- nvidia-cuda-toolkit-10.1.243/debian/changelog 2020-06-03 09:54:22.0 +0200 +++ nvidia-cuda-toolkit-10.1.243/debian/changelog 2020-06-05 08:09:24.0 +0200 @@ -1,3 +1,9 @@ +nvidia-cuda-toolkit (10.1.243-5.1) unstable; urgency=medium + + * Add missing libjpeg62 dependency to fix build failure (Closes: #-1) + + -- Gianfranco Costamagna Fri, 05 Jun 2020 08:09:24 +0200 + nvidia-cuda-toolkit (10.1.243-5) unstable; urgency=medium * Merge changes from 10.1.168-11. diff -Nru nvidia-cuda-toolkit-10.1.243/debian/control nvidia-cuda-toolkit-10.1.243/debian/control --- nvidia-cuda-toolkit-10.1.243/debian/control 2020-06-03 09:54:22.0 +0200 +++ nvidia-cuda-toolkit-10.1.243/debian/control 2020-06-05 08:09:24.0 +0200 @@ -42,6 +42,7 @@ liblcms2-dev, libpcsclite-dev, libpng-dev, + libjpeg62, (please don't use libjpeg62-dev package, because it conflicts with the turbo one, and makes the package bd-uninstallable) Cheers Gianfranco
Bug#962190: primer3: please disable Big Endian tests on autopkgtests too
control: tags -1 patch
This might work better:
--- primer3-2.4.0/debian/tests/run-unit-test2018-05-28 15:44:30.0
+0200
+++ primer3-2.4.0/debian/tests/run-unit-test2020-06-04 11:47:04.0
+0200
@@ -8,6 +8,12 @@
AUTOPKGTEST_TMP=`mktemp -d /tmp/${pkg}-test.XX`
fi
+BUILDARCH=$(dpkg-architecture -q DEB_BUILD_ARCH_ENDIAN)
+
+P3CORE_FAILED_TESTS="primer_masker primer_masker_formatted"
+
+FAILED_TESTS="testmasker"
+
cp -a /usr/share/doc/${pkg}/examples/* $AUTOPKGTEST_TMP
cd $AUTOPKGTEST_TMP
@@ -19,6 +25,16 @@
ln -s /usr/bin/ntthal ./src/ntthal
ln -s /usr/bin/oligotm ./src/oligotm
+if [ $BUILDARCH = big ]; then
+ cp -a test/p3test.pl test/p3test.pl~
+ cp -a test/Makefile test/Makefile~
+ # exclude tests known to fail on big endian
+ # See README.source for further explanation.
+ for tst in $P3CORE_FAILED_TESTS ; do sed -i "/$tst/d" test/p3test.pl ; done
+ sed -i "0,/$FAILED_TESTS/s///" test/Makefile
+ sed -i "/$FAILED_TESTS/,/endif/d" test/Makefile
+fi
+
cd test/;
echo "testcmdline:"
@@ -36,4 +52,12 @@
echo "testtm:"
perl oligotm_test.pl ${TESTOPTS}
+cd ..
+
+if [ $BUILDARCH = big ]; then
+ # restore original test file
+ mv test/p3test.pl~ test/p3test.pl
+ mv test/Makefile~ test/Makefile
+fi
+
echo "PASS"
Bug#890993: fixed in primer3 2.4.0-2
control: close -1 Lets close, I opened a new one in the meanwhile G.
Bug#962194: lintian-brush: autopkgtest failure on s390x
Source: lintian-brush
Version: 0.69
Hello, since version 0.68 we are hitting autopkgtest failures on Ubuntu s390x
(but I presume this might be an endianess issue unrelated to Ubuntu, but an
issue on Debian too)
look e.g.:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/l/lintian-brush/20200526_071151_45b70@/log.gz
or
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/l/lintian-brush/20200602_160733_92e77@/log.gz
autopkgtest [16:06:43]: test tool-testsuite: [---
failed to open trace file: [Errno 13] Permission denied:
'/you-should-use-TestCaseInTempDir-if-you-need-a-log-file'
.../usr/lib/python3/dist-packages/debian/changelog.py:483: UserWarning:
Unexpected line while looking for first heading: THIS IS NOT A PARSEABLE LINE
warnings.warn(message)
/usr/lib/python3/dist-packages/debian/changelog.py:483:
UserWarning: Unexpected line while looking for first heading: lalalalala
warnings.warn(message)
/usr/lib/python3/dist-packages/debian/changelog.py:483: UserWarning: Found eof
where expected first heading
warnings.warn(message)
./tmp/autopkgtest.aoDwvO/build.6pK/src/lintian_brush/_deb822.py:115:
UserWarning: cannot parse package relationship "${misc:Depends}", returning it
raw
warnings.warn(
...ss...EE.x..sed:
can't read debian/rules: No such file or directory
sed: can't read debian/rules: No such file or directory
.sed: can't read debian/rules: No such file or directory
sed: can't read debian/rules: No such file or directory
./tmp/autopkgtest.aoDwvO/build.6pK/src/fixers/common-license.py:176:
UserWarning: A common license shortname (Apache-2.0) is used, but license text
not recognized.
warn(
../tmp/autopkgtest.aoDwvO/build.6pK/src/fixers/common-license.py:160:
UserWarning: Unable to get canonical name for 'BSD-3-clause'
warn('Unable to get canonical name for %r' % license_id)
/tmp/autopkgtest.aoDwvO/build.6pK/src/fixers/common-license.py:190:
UserWarning: Found full license text for BSD-3-clause, but unknown synopsis
BSD-3-clause (BSD-3-clause)
warn('Found full license text for %s, but unknown synopsis %s (%s)'
.../usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115:
UserWarning: cannot parse package relationship "libf2fs5 (=
${binary:Version})", returning it raw
warnings.warn(
/usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115: UserWarning:
cannot parse package relationship "libf2fs-format4 (= ${binary:Version})",
returning it raw
warnings.warn(
/usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115: UserWarning:
cannot parse package relationship "${shlibs:Depends}", returning it raw
warnings.warn(
/usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115: UserWarning:
cannot parse package relationship "${misc:Depends}", returning it raw
warnings.warn(
/usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115: UserWarning:
cannot parse package relationship "f2fs-tools (= ${binary:Version})", returning
it raw
warnings.warn(
/usr/lib/python3/dist-packages/debian/changelog.py:483:
UserWarning: Unexpected line while looking for start of change data: * Initial
Release.
warnings.warn(message)
.../usr/lib/python3/dist-packages/lintian_brush/_deb822.py:115:
UserWarning: cannot parse package relationship "${misc:Depends}", returning it
raw
warnings.warn(
..Tree has non-standard patches directory debian/patches-applied.
..dpkg-architecture: warning: cannot determine CC system
type, falling back to default (native compilation)
Use of uninitialized value $step in string ne at
/usr/share/perl5/Debian/Debhelper/Buildsystem/perl_build.pm line 24.
Use of uninitialized value $step in string ne at
/usr/share/perl5/Debian/Debhelper/Buildsystem.pm line 424.
..dpkg-architecture: warning: cannot determine CC system type, falling back to
default (native compilation)
Use of uninitialized value $step in string ne at
/usr/share/perl5/Debian/Debhelper/Buildsystem/perl_build.pm line 24.
Use of uninitialized value $step in string ne at
/usr/share/perl5/Debian/Debhelper/Buildsystem.pm line 424.
../tmp/autopkgtest.aoDwvO/build.6pK/src/fixers/package-uses-deprecated-debhelper-compat-version.py:80:
UserWarning: Not upgrading beyond debhelper 10, since the package disables
autoreconf but its configure does not provide --runstatedir.
warnings.warn(
.gpg: WARNING: running with faked system time: 2019-08-24
12:26:39
gpg: WARNING: running with faked system time: 2019-08-24 12:26:39
.gpg: WARNING:
Bug#962190: primer3: please disable Big Endian tests on autopkgtests too
Source: primer3
Version: 2.4.0-2
Severity: serious
Hello, can you please apply the same on autopkgtests? now autopkgtests failures
are considered RC buggy
something like this might work:
--- primer3-2.4.0/debian/changelog 2018-05-28 15:44:30.0 +0200
+++ primer3-2.4.0/debian/changelog 2020-06-04 11:47:04.0 +0200
@@ -1,3 +1,9 @@
+primer3 (2.4.0-2.1) unstable; urgency=medium
+
+ * Also skip autopkgtests that fail on big endian (see: 890993,) Closes: #-1
+
+ -- Gianfranco Costamagna Thu, 04 Jun 2020
11:47:04 +0200
+
primer3 (2.4.0-2) unstable; urgency=medium
[ Liubov Chuprikova ]
diff -Nru primer3-2.4.0/debian/tests/run-unit-test
primer3-2.4.0/debian/tests/run-unit-test
--- primer3-2.4.0/debian/tests/run-unit-test2018-05-28 15:44:30.0
+0200
+++ primer3-2.4.0/debian/tests/run-unit-test2020-06-04 11:47:04.0
+0200
@@ -8,6 +8,13 @@
AUTOPKGTEST_TMP=`mktemp -d /tmp/${pkg}-test.XX`
fi
+BUILDARCH=$(dpkg-architecture -q DEB_BUILD_ARCH_ENDIAN)
+
+P3CORE_FAILED_TESTS='primer_masker' \
+ 'primer_masker_formatted'
+
+FAILED_TESTS=testmasker
+
cp -a /usr/share/doc/${pkg}/examples/* $AUTOPKGTEST_TMP
cd $AUTOPKGTEST_TMP
@@ -19,6 +26,16 @@
ln -s /usr/bin/ntthal ./src/ntthal
ln -s /usr/bin/oligotm ./src/oligotm
+if [ $BUILDARCH = big ]; then
+ cp -a test/p3test.pl test/p3test.pl~
+ cp -a test/Makefile test/Makefile~
+ # exclude tests known to fail on big endian
+ # See README.source for further explanation.
+ for tst in $(P3CORE_FAILED_TESTS) ; do sed -i "/$${tst}/d" test/p3test.pl ;
done
+ sed -i "0,/$(FAILED_TESTS)/s///" test/Makefile
+ sed -i "/$(FAILED_TESTS)/,/endif/d" test/Makefile
+fi
+
cd test/;
echo "testcmdline:"
@@ -36,4 +53,12 @@
echo "testtm:"
perl oligotm_test.pl ${TESTOPTS}
+cd ..
+
+if [ $BUILDARCH = big ]; then
+ # restore original test file
+ mv test/p3test.pl~ test/p3test.pl
+ mv test/Makefile~ test/Makefile
+fi
+
echo "PASS"
On Tue, 29 May 2018 17:36:48 + Liubov Chuprikova
wrote:
> Source: primer3
> Source-Version: 2.4.0-2
>
> We believe that the bug you reported is fixed in the latest version of
> primer3, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed. If you
> have further comments please address them to 890...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Liubov Chuprikova (supplier of updated primer3
> package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Mon, 28 May 2018 13:44:30 +
> Source: primer3
> Binary: primer3 primer3-examples
> Architecture: source
> Version: 2.4.0-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Med Packaging Team
>
> Changed-By: Liubov Chuprikova
> Description:
> primer3- tool to design flanking oligo nucleotides for DNA amplification
> primer3-examples - tool to design flanking oligo nucleotides for DNA
> amplification (
> Closes: 890993
> Changes:
> primer3 (2.4.0-2) unstable; urgency=medium
> .
>[ Liubov Chuprikova ]
>* Team upload.
>* Skip tests that fail on big endian
> Closes: #890993
>* Added d/README.source with explanation why some tests are skipped
>* debian/patches/p3test_fix_exit_status.patch: Fix test to show correct
> exit
> status
> .
>[ Andreas Tille ]
>* Point Vcs fields to salsa.debian.org
>* Standards-Version: 4.1.4
> Checksums-Sha1:
> ed7288049fca41a312d5d528d3e57e0b51be9bdc 2117 primer3_2.4.0-2.dsc
> 9d7f7874ef42796bd45181a610ad4d2d9193ef02 12060 primer3_2.4.0-2.debian.tar.xz
> 60fe57fc774ab8b537785d4c6d07e54647aabd70 5964 primer3_2.4.0-2_amd64.buildinfo
> Checksums-Sha256:
> 541ec07c9092995dd359620326630c45135321868ee2c2350ef61e1d4d67628d 2117
> primer3_2.4.0-2.dsc
> 96247e4223393e0056a8886209b1bb37abfa7dc7fb00eca4e3e695daf62dd71e 12060
> primer3_2.4.0-2.debian.tar.xz
Bug#890993: fixed in primer3 2.4.0-2
Hello, can you please apply the same on autopkgtests? now autopkgtests failures
are considered RC buggy
something like this might work:
--- primer3-2.4.0/debian/changelog 2018-05-28 15:44:30.0 +0200
+++ primer3-2.4.0/debian/changelog 2020-06-04 11:47:04.0 +0200
@@ -1,3 +1,9 @@
+primer3 (2.4.0-2ubuntu1) groovy; urgency=medium
+
+ * Also skip autopkgtests that fail on big endian (see: 890993)
+
+ -- Gianfranco Costamagna Thu, 04 Jun 2020
11:47:04 +0200
+
primer3 (2.4.0-2) unstable; urgency=medium
[ Liubov Chuprikova ]
diff -Nru primer3-2.4.0/debian/tests/run-unit-test
primer3-2.4.0/debian/tests/run-unit-test
--- primer3-2.4.0/debian/tests/run-unit-test2018-05-28 15:44:30.0
+0200
+++ primer3-2.4.0/debian/tests/run-unit-test2020-06-04 11:47:04.0
+0200
@@ -8,6 +8,13 @@
AUTOPKGTEST_TMP=`mktemp -d /tmp/${pkg}-test.XX`
fi
+BUILDARCH=$(dpkg-architecture -q DEB_BUILD_ARCH_ENDIAN)
+
+P3CORE_FAILED_TESTS='primer_masker' \
+ 'primer_masker_formatted'
+
+FAILED_TESTS=testmasker
+
cp -a /usr/share/doc/${pkg}/examples/* $AUTOPKGTEST_TMP
cd $AUTOPKGTEST_TMP
@@ -19,6 +26,16 @@
ln -s /usr/bin/ntthal ./src/ntthal
ln -s /usr/bin/oligotm ./src/oligotm
+if [ $BUILDARCH = big ]; then
+ cp -a test/p3test.pl test/p3test.pl~
+ cp -a test/Makefile test/Makefile~
+ # exclude tests known to fail on big endian
+ # See README.source for further explanation.
+ for tst in $(P3CORE_FAILED_TESTS) ; do sed -i "/$${tst}/d" test/p3test.pl ;
done
+ sed -i "0,/$(FAILED_TESTS)/s///" test/Makefile
+ sed -i "/$(FAILED_TESTS)/,/endif/d" test/Makefile
+fi
+
cd test/;
echo "testcmdline:"
@@ -36,4 +53,12 @@
echo "testtm:"
perl oligotm_test.pl ${TESTOPTS}
+cd ..
+
+if [ $BUILDARCH = big ]; then
+ # restore original test file
+ mv test/p3test.pl~ test/p3test.pl
+ mv test/Makefile~ test/Makefile
+fi
+
echo "PASS"
On Tue, 29 May 2018 17:36:48 + Liubov Chuprikova
wrote:
> Source: primer3
> Source-Version: 2.4.0-2
>
> We believe that the bug you reported is fixed in the latest version of
> primer3, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed. If you
> have further comments please address them to 890...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Liubov Chuprikova (supplier of updated primer3
> package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Mon, 28 May 2018 13:44:30 +
> Source: primer3
> Binary: primer3 primer3-examples
> Architecture: source
> Version: 2.4.0-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Med Packaging Team
>
> Changed-By: Liubov Chuprikova
> Description:
> primer3- tool to design flanking oligo nucleotides for DNA amplification
> primer3-examples - tool to design flanking oligo nucleotides for DNA
> amplification (
> Closes: 890993
> Changes:
> primer3 (2.4.0-2) unstable; urgency=medium
> .
>[ Liubov Chuprikova ]
>* Team upload.
>* Skip tests that fail on big endian
> Closes: #890993
>* Added d/README.source with explanation why some tests are skipped
>* debian/patches/p3test_fix_exit_status.patch: Fix test to show correct
> exit
> status
> .
>[ Andreas Tille ]
>* Point Vcs fields to salsa.debian.org
>* Standards-Version: 4.1.4
> Checksums-Sha1:
> ed7288049fca41a312d5d528d3e57e0b51be9bdc 2117 primer3_2.4.0-2.dsc
> 9d7f7874ef42796bd45181a610ad4d2d9193ef02 12060 primer3_2.4.0-2.debian.tar.xz
> 60fe57fc774ab8b537785d4c6d07e54647aabd70 5964 primer3_2.4.0-2_amd64.buildinfo
> Checksums-Sha256:
> 541ec07c9092995dd359620326630c45135321868ee2c2350ef61e1d4d67628d 2117
> primer3_2.4.0-2.dsc
> 96247e4223393e0056a8886209b1bb37abfa7dc7fb00eca4e3e695daf62dd71e 12060
> primer3_2.4.0-2.debian.tar.xz
Bug#942915: ca-certificates: Python2 removal in sid/bullseye
Hello, the patch is now committed on the shared git, but I don't plan to upload it. (I don't like to touch native packages when possible) G.
Bug#942915: ca-certificates: Python2 removal in sid/bullseye
control: tags -1 patch Since the Ubuntu patch is really trivial, I don't see any reason for delaying this more, specially because this is a core-component diff -pruN 20190110/debian/changelog 20190110ubuntu1/debian/changelog --- 20190110/debian/changelog 2019-01-11 01:31:31.0 + +++ 20190110ubuntu1/debian/changelog2020-03-30 10:09:50.0 + @@ -1,3 +1,9 @@ +ca-certificates (20190110ubuntu1) focal; urgency=medium + + * Build using python3. + + -- Matthias Klose Mon, 30 Mar 2020 12:09:50 +0200 + ca-certificates (20190110) unstable; urgency=high * debian/control: diff -pruN 20190110/debian/control 20190110ubuntu1/debian/control --- 20190110/debian/control 2019-01-11 01:31:31.0 + +++ 20190110ubuntu1/debian/control 2020-03-30 10:09:42.0 + @@ -5,7 +5,7 @@ Maintainer: Michael Shuler , Thijs Kinkhorst Build-Depends: debhelper-compat (= 12), po-debconf -Build-Depends-Indep: python, openssl +Build-Depends-Indep: python3, openssl Standards-Version: 4.3.0.1 Vcs-Git: https://salsa.debian.org/debian/ca-certificates.git Vcs-Browser: https://salsa.debian.org/debian/ca-certificates diff -pruN 20190110/mozilla/certdata2pem.py 20190110ubuntu1/mozilla/certdata2pem.py --- 20190110/mozilla/certdata2pem.py2019-01-11 01:31:31.0 + +++ 20190110ubuntu1/mozilla/certdata2pem.py 2020-03-30 10:09:28.0 + @@ -1,4 +1,4 @@ -#!/usr/bin/python +#!/usr/bin/python3 # vim:set et sw=4: # # certdata2pem.py - splits certdata.txt into multiple files diff -pruN 20190110/mozilla/Makefile 20190110ubuntu1/mozilla/Makefile --- 20190110/mozilla/Makefile 2018-10-13 14:07:11.0 + +++ 20190110ubuntu1/mozilla/Makefile2020-03-30 10:09:50.0 + @@ -3,7 +3,7 @@ # all: - python certdata2pem.py + python3 certdata2pem.py clean: -rm -f *.crt On Wed, 23 Oct 2019 02:33:19 + mo...@debian.org wrote: > Source: ca-certificates > Version: 20190110 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests (the specific reason can be found searching this > source package in > https://people.debian.org/~morph/mass-bug-py2removal_take2.txt ). > Please stop using Python2, and fix this issue by one of the following > actions. > > - Convert your Package to Python3. This is the preferred option. In > case you are providing a Python module foo, please consider dropping > the python-foo package, and only build a python3-foo package. Please > don't drop Python2 modules, which still have reverse dependencies, > just document them. > > This is the preferred option. > > - If the package is dead upstream, cannot be converted or maintained > in Debian, it should be removed from the distribution. If the > package still has reverse dependencies, raise the severity to > "serious" and document the reverse dependencies with the BTS affects > command. If the package has no reverse dependencies, confirm that > the package can be removed, reassign this issue to ftp.debian.org, > make sure that the bug priority is set to normal and retitle the > issue to "RM: PKG -- removal triggered by the Python2 removal". > > - If the package has still many users (popcon >= 300), or is needed to > build another package which cannot be removed, document that by > adding the "py2keep" user tag (not replacing the py2remove tag), > using the debian-pyt...@lists.debian.org user. Also any > dependencies on an unversioned python package (python, python-dev) > must not be used, same with the python shebang. These have to be > replaced by python2/python2.7 dependencies and shebang. > > This is the least preferred option. > > If there are questions, please refer to the wiki page for the removal: > https://wiki.debian.org/Python/2Removal, or ask for help on IRC > #debian-python, or the debian-pyt...@lists.debian.org mailing list. > > >
Bug#961744: devscripts: uscan: please add capability to download gzipped content
control: forcemerge 961744 -1 > > thanks, I'll look at this. Note that this is a server side bug: it > should not send compressed data if request doesn't specify > "Accept-Encoging: gzip" > Hello, yes we know this is a server issue, but meh, we can't fix the internet :) Did you look at the patch in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952738 ? Not sure how and why, but the patch is really more trivial than my approach! G.
Bug#947438: RM: llvm-toolchain-7 -- ROM; Less versions of llvm, the better
control: tags -1 -moreinfo Hello, flang (out from testing) is the last blocker, I asked on 947437 if we can proceed with this. is it possible to remove it anyway, or break the build of it? (ccing Alastair) G.
Bug#947437: flang in bullseye - llvm 11 ?
On Sat, 18 Apr 2020 17:09:35 +0200 Sylvestre Ledru wrote: > Le 18/04/2020 à 16:10, Alastair McKinstry a écrit : > > Hi, > > > > flang is now merged into LLVM base. > > > > I can build flang/f18 from the LLVM main install, but this targets llvm-11. > > > > Are we likely to have llvm-11 (not necessarily default) in Debian > > Bullseye ? what approach should be taken ? > Quite likely. > I think llvm 11 will be released end of 2020 / early 2021 > and is already available in experimental. > > Cheers, > Sylvestre > > > So, since flang is the last llvm-toolchain-7 reverse-dependency, what about removing it for now or break it so we can drop llvm-7 while 11 becomes available in sid? G.
Bug#961844: fixed in libguestfs 1:1.42.0-4
control: reopen -1 control: notfixed -1 1:1.42.0-4 Hello, to fix the issue I added the -Xguestfs-erlang.3 to dh_missing, not dh_install target cheers, Gianfranco On Sat, 30 May 2020 13:33:31 + Debian FTP Masters wrote: > Source: libguestfs > Source-Version: 1:1.42.0-4 > Done: Hilko Bengen > > We believe that the bug you reported is fixed in the latest version of > libguestfs, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 961...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Hilko Bengen (supplier of updated libguestfs package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Sat, 30 May 2020 15:15:25 +0200 > Source: libguestfs > Architecture: source > Version: 1:1.42.0-4 > Distribution: unstable > Urgency: medium > Maintainer: Debian Libvirt Maintainers > > Changed-By: Hilko Bengen > Closes: 961844 > Changes: > libguestfs (1:1.42.0-4) unstable; urgency=medium > . >* dh_install: Ignore guestfs-erlang manpage, for real (Closes: #961844) > Checksums-Sha1: > 0b0159ed5e3752f5171ee32f0f8dce2d03493f1a 5980 libguestfs_1.42.0-4.dsc > 7eb184de970045dfb7222166f6b8ec89b6512fab 42240 > libguestfs_1.42.0-4.debian.tar.xz > 03bb953b2527846596b6a24045f65e47c570710f 18144 > libguestfs_1.42.0-4_source.buildinfo > Checksums-Sha256: > 9f1f6a131a5c86fc480a157eb1b6515ee646eb14989973e901063c3dfac1d191 5980 > libguestfs_1.42.0-4.dsc > eec71057dddb8776c62b3824af3c677a2e51008df179908a2fdb50958efb7a21 42240 > libguestfs_1.42.0-4.debian.tar.xz > f02fbd69a08032d2741f0299e7a4157a4e3830bf728887ca947c2c27dbc5a335 18144 > libguestfs_1.42.0-4_source.buildinfo > Files: > bdad4f2afbd414b00f91e3006c72587f 5980 libs optional libguestfs_1.42.0-4.dsc > dbcc87c3597969e0bcf811d07d37ab10 42240 libs optional > libguestfs_1.42.0-4.debian.tar.xz > 1c8fd9e06ec320979101cc08e3fcdfd2 18144 libs optional > libguestfs_1.42.0-4_source.buildinfo > > -BEGIN PGP SIGNATURE- > > iQJGBAEBCAAwFiEErnMQVUQqHZbPTUx4dbcQY1whOn4FAl7SXJUSHGJlbmdlbkBk > ZWJpYW4ub3JnAAoJEHW3EGNcITp+xpQP+wUtB64ic5ngIh8ju4OnFEHxktTlkoMf > 0vtalnNoU7sZCkbrQ5qK+9QEs/8mNQBaUVu6KG3dDWVCepvrhbOqUfCbyuUd+a+1 > FWL37M2b5BifUw6qaHX5J2hP59d36dep9lRh+GZmoXXZBYV5bXrY9IoyhNTSSBip > Bh98yE2VMNcXPRwnaBgIFNKW2ZxSpsKeur1uEMY2x4UI5sCx0/8U8E3TdYOnhbS4
Bug#961844: libguestfs: FTBFS in sid
Source: libguestfs Version: 1:1.42.0-2 Severity: serious tags: patch something like this works: override_dh_missing: dh_missing --fail-missing \ - -X.la -X.so.owner -Xbindtests -X/usr/lib/go/ -X/usr/lib/go- -Xpackages.orig -Xetc/php.d + -X.la -X.so.owner -Xbindtests -X/usr/lib/go/ -X/usr/lib/go- -Xpackages.orig -Xetc/php.d -Xguestfs-erlang.3 Thanks! Gianfranco
Bug#961550: flatbuffers FTBFS: MISSING symbols for libflatbuffers1
control: fixed -1 1.11.0+dfsg1-1.4 control: close -1 closing! On Mon, 25 May 2020 21:40:04 + Vasyl Gello wrote: > Source: flatbuffers > Version: 1.11.0+dfsg1-1.3 > Severity: serious > Tags: patch ftbfs > > Dear colleagues, > > I tried to build flatbuffers for buster/amd64, and got the following symbols > missing: > > * _ZN11flatbuffers14IntToStringHexB5cxx11Eii@Base 1.11.0+dfsg > > This is an inline symbol, g++ 8.3.0 inlined it properly instead of making > it weak. > > * _ZN11flatbuffers9GetFieldSERKNS_5TableERKN10reflection5FieldE@Base > 1.11.0+dfsg1 > > Also inline symbol > > * _ZN11flexbuffers7Builder5AlignENS_8BitWidthE@Base 1.11.0+dfsg1 > * _ZN11flexbuffers7Builder6EndMapEm@Base 1.11.0+dfsg1 > * _ZN11flexbuffers7Builder8WriteAnyERKNS0_5ValueEh@Base 1.11.0+dfsg1 > * _ZN11flexbuffers7BuilderD1Ev@Base 1.11.0+dfsg1 > * _ZN11flexbuffers7BuilderD2Ev@Base 1.11.0+dfsg1 > * _ZNK10reflection5Field6VerifyERN11flatbuffers8VerifierE@Base 1.11.0+dfsg1 > * _ZNK11flexbuffers9Reference8AsUInt64Ev@Base 1.11.0+dfsg1 > * > _ZNSt6vectorIhSaIhEE17_M_realloc_insertIJhEEEvN9__gnu_cxx17__normal_iteratorIPhS1_EEDpOT_@Base > 1.11.0+dfsg1 > > NOT inlined symbols but missing nonetheless despute of "optional" tagging. > > I have created a PR on Salsa to fix the missing symbols and also the lintian > errors on > newly-added symbols: > > https://salsa.debian.org/debian/flatbuffers/-/merge_requests/4 > > Building the same fixed git snapshot for buster and sid on amd64 completed > successfully, > the build artifacts were used to rebuild Kodi whuch runs successfully on > buster. > > Please review the PR and push the updated revision to unstable. > Pushing the same release to stable would be ideal as well. > -- > Vasyl Gello
Bug#961791: node-jsesc: please increase autopkgtest timeouts
Source: node-jsesc Version: 3.0.1-1 tags: patch Hello, on some slow arm machines, mocha tests are timeouting on 20seconds timeout. Can you please increase it a little bit? diff -Nru node-jsesc-3.0.1/debian/tests/upstreamtestsuite node-jsesc-3.0.1/debian/tests/upstreamtestsuite --- node-jsesc-3.0.1/debian/tests/upstreamtestsuite 2020-04-12 08:45:28.0 +0200 +++ node-jsesc-3.0.1/debian/tests/upstreamtestsuite 2020-05-29 10:33:42.0 +0200 @@ -2,4 +2,4 @@ set -e sed tests/tests.js -e "s|'../jsesc.js'|'jsesc'|g" > tests.js -mocha tests.js +mocha tests.js --timeout 4 something like this works! thanks Gianfranco
Bug#961744: devscripts: uscan: please add capability to download gzipped content
Source: devscripts Version: 2.20.3 X-Debbugs-CC: y...@debian.org Hello, looks like ghc watch file is not able to work anymore version=3 opts="pgpsigurlmangle=s/$/.sig/,dirversionmangle=s/-rc/~rc/,repacksuffix=+dfsg1,dversionmangle=s/\+dfsg\d*$//" \ https://downloads.haskell.org/~ghc/(\d[\d.rc-]*)/ghc-(\d[\d.]*)-src.tar.(?:bz2|xz|gz) the problem is that the https://downloads.haskell.org/~ghc/ page is configured to send gzipped content (something that browsers handle natively). I'm not able to speak perl, but I crafted a "fake patch" that worked for me to grab the new version, and I would like to share it with you. (note: I was not able to gunzip a buffer variable, so I saved the content into a file and loaded it from there, sorry but my perl-foo is really NULL) This is a POC that works for ghc, but of course it needs to be changed to selectively allow gzipped content via configuration switch, or by detecting the type of received stream, or something else diff -Nru devscripts-2.20.3/lib/Devscripts/Uscan/http.pm devscripts-2.20.4/lib/Devscripts/Uscan/http.pm --- devscripts-2.20.3/lib/Devscripts/Uscan/http.pm 2020-04-25 21:01:45.0 +0200 +++ devscripts-2.20.4/lib/Devscripts/Uscan/http.pm 2020-04-25 21:15:48.0 +0200 @@ -6,6 +6,7 @@ use Devscripts::Uscan::Utils; use Devscripts::Uscan::_xtp; use Moo::Role; +use IO::Uncompress::Gunzip qw(gunzip $GunzipError) ; *http_newfile_base = \::Uscan::_xtp::_xtp_newfile_base; @@ -239,6 +240,12 @@ } my $content = $response->content; +open(FH, '>', '/tmp/content') or die $!; +print FH $content; +close(FH); + +my $input = new IO::File "< /tmp/content"; +gunzip $input => \$content; uscan_debug "received content:\n$content\n[End of received content] by HTTP";
Bug#957140: dlt-daemon: ftbfs with GCC-10
control: forwarded -1 https://github.com/GENIVI/dlt-daemon/pull/228/files On Sat, 23 May 2020 21:50:35 +0200 Gianfranco Costamagna wrote: > hello, this > https://github.com/GENIVI/dlt-daemon/pull/228/files > > might be a patch for it > (it builds, but I'm not sure if it also works or not) > > G. > >
Bug#961516: linux: please enable VBOXSF_FS on amd64 and i386
Source: linux Version: 5.6.14-1 Severity: normal Hello, can you please enable vboxsf kernel module build now that it is mainline? it will allow me to relax dependencies on virtualbox package on the dkms builds.
Bug#959487: libpng built without VSX support on ppc64le
control: close -1 Hello, answering inline On Sat, 2 May 2020 16:32:27 -0500 (CDT) Timothy Pearson wrote: > Package: libpng16-16:ppc64le > Version: 1.6.36-6 > > libpng is built without VSX support on POWER systems. This breaks > assumptions in other software, such as node optipng (log below). > > I can work around it with this, but it is not ideal: > CFLAGS="-DPNG_POWERPC_VSX_OPT=0" npm install optipng-bin > > npm install optipng-bin > npm WARN npm npm does not support Node.js v10.15.2 > npm WARN npm You should probably upgrade to a newer version of node as we > npm WARN npm can't make any promises that npm will work with this version. > npm WARN npm Supported releases of Node.js are the latest release of 4, 6, 7, > 8, 9. > npm WARN npm You can find the latest version at https:/nodejs.org/ > > > optipng-bin@6.0.0 postinstall > > /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin > > node lib/install.js > > ⚠ Command failed: > /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng > --version > /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: > 1: > /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: > @@8�@@@�: not found > /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: > 2: > /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: > d: not found > /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: > 1: > /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: > ELF: not found > /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: > 1: > /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: > Syntax error: ";" unexpected > bad thing to run binaries built for amd64 and i386 on ppc64el, this is an optipng upstream issue > > ⚠ optipng pre-build test failed > ℹ compiling from source > ✖ Error: Command failed: /bin/sh -c make install > pngrtran.c:99:1: warning: ‘png_rtran_ok’ defined but not used > [-Wunused-function] > png_rtran_ok(png_structrp png_ptr, int need_IHDR) > ^~~~ > ar: `u' modifier ignored since `D' is the default (see `U') > ar: `u' modifier ignored since `D' is the default (see `U') > ar: `u' modifier ignored since `D' is the default (see `U') > ar: `u' modifier ignored since `D' is the default (see `U') > pngxmem.c: In function ‘pngx_malloc_rows_extended’: > pngxmem.c:38:34: warning: comparison is always false due to limited range of > data type [-Wtype-limits] > (pngx_alloc_size_t)height > (pngx_alloc_size_t)(-1) / > sizeof(png_bytep)) > ^ > ar: `u' modifier ignored since `D' is the default (see `U') > /usr/bin/ld: ../libpng/libpng.a(pngrutil.o): in function > `png_read_filter_row': > pngrutil.c:(.text+0x29c0): undefined reference to > `png_init_filter_functions_vsx' > collect2: error: ld returned 1 exit status > make[1]: *** [Makefile:100: optipng] Error 1 > make: *** [Makefile:14: install] Error 2 > > cd src/optipng && \ > make install && \ > cd ../.. > make[1]: Entering directory > '/home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/a4e0fea9-c020-4419-98f6-a1b3d4dfc863/src/optipng' > cd ../libpng && \ > make -f Makefile PNGLIBCONF_H_PREBUILT=pnglibconf.h.optipng && \ > cd ../optipng > make[2]: Entering directory > '/home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/a4e0fea9-c020-4419-98f6-a1b3d4dfc863/src/libpng' > cp pnglibconf.h.optipng pnglibconf.h > gcc -c -I../zlib -O2 -Wall -Wextra -o png.o png.c > gcc -c -I../zlib -O2 -Wall -Wextra -o pngerror.o pngerror.c > gcc -c -I../zlib -O2 -Wall -Wextra -o pngget.o pngget.c > gcc -c -I../zlib -O2 -Wall -Wextra -o pngmem.o pngmem.c > gcc -c -I../zlib -O2 -Wall -Wextra -o pngpread.o pngpread.c as you can see you are trying to build libpng by yourself, not using the system version. steps to reproduce: git clone https://github.com/imagemin/optipng-bin cd optipng-bin look for lib/install.js and see how the installation is done: basically, extracts a tarball with lots of embedded stuff (including libpng) and run make tar xvf vendor/source/optipng.tar.gz cd optipng-0.7.7/ ./configure --with-system-zlib --prefix=foo --bindir=bar make here I see two errors: 1) libpng configure is not run: edit configure and change with_preconfigured_libpng=1 to with_preconfigured_libpng=0 so you run a fresh libpng configure script, detecting correctly what is needed for your platform. make will fail because of a library being misnamed misplaced cp ../optipng-0.7.7/src/libpng/.libs/libpng16.a ../optipng-0.7.7/src/libpng/libpng.a make will succeed 2) use system libpng (the version you are blaming currently :p) ~/optipng-bin$ tar xvf vendor/source/optipng.tar ~/optipng-bin$ cd optipng-0.7.7/ ~/optipng-bin/optipng-0.7.7$
Bug#960832: notfixed in ubuntu...
control: unarchive -1
control: reopen -1
Hello, I tried 0.65 and testsuite failed with:
==
FAIL: test_add_new (lintian_brush.tests.test_run.ChangelogAddEntryTests)
lintian_brush.tests.test_run.ChangelogAddEntryTests.test_add_new
--
testtools.testresult.real._StringException: log: {{{
2.311 creating repository in
file:///tmp/testbzr-6n26vnuu.tmp/lintian_brush.tests.test_run.ChangelogAddEntryTests.test_add_new/work/.bzr/.
2.312 creating branch in
file:///tmp/testbzr-6n26vnuu.tmp/lintian_brush.tests.test_run.ChangelogAddEntryTests.test_add_new/work/
2.316 trying to create missing lock
'/tmp/testbzr-6n26vnuu.tmp/lintian_brush.tests.test_run.ChangelogAddEntryTests.test_add_new/work/.bzr/checkout/dirstate'
2.318 opening working tree
'/tmp/testbzr-6n26vnuu.tmp/lintian_brush.tests.test_run.ChangelogAddEntryTests.test_add_new/work'
}}}
Traceback (most recent call last):
File "/<>/lintian_brush/tests/test_run.py", line 913, in
test_add_new
self.assertEqual([
File "/usr/lib/python3/dist-packages/breezy/tests/__init__.py", line 1315, in
assertEqual
raise AssertionError("%snot equal:\na = %s\nb = %s\n"
AssertionError: not equal:
a = ['lintian-brush (0.36) UNRELEASED; urgency=medium', '', ' * Add a foo', '']
b = ['lintian-brush (0.35ubuntu1) UNRELEASED; urgency=medium',
'',
' * Add a foo',
'']
--
Ran 581 tests in 39.308s
FAILED (failures=1, expected failures=1)
Test failed:
error: Test failed:
E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1:
python3.8 setup.py test
dh_auto_test: error: pybuild --test -i python{version} -p 3.8 returned exit
code 13
make: *** [debian/rules:6: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
Can you please have another deeper look?
thanks!
G.
Bug#936981: fixed in mailnag 2.0.0-0.1
Hello, I pushed another NMU diff -Nru mailnag-2.0.0/debian/changelog mailnag-2.0.0/debian/changelog --- mailnag-2.0.0/debian/changelog 2020-05-09 10:31:35.0 +0200 +++ mailnag-2.0.0/debian/changelog 2020-05-24 13:08:09.0 +0200 @@ -1,3 +1,12 @@ +mailnag (2.0.0-0.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fixup previous upload by exporting PYBUILD_NAME and depending on +python3-all (patch taken from Ubuntu, Sebastien Bacher +) LP: #1874275 + + -- Gianfranco Costamagna Sun, 24 May 2020 13:08:09 +0200 + mailnag (2.0.0-0.1) unstable; urgency=medium * Non-maintainer upload diff -Nru mailnag-2.0.0/debian/control mailnag-2.0.0/debian/control --- mailnag-2.0.0/debian/control2020-05-09 10:31:35.0 +0200 +++ mailnag-2.0.0/debian/control2020-05-24 13:07:57.0 +0200 @@ -2,7 +2,7 @@ Section: mail Priority: optional Maintainer: Vincent Cheng -Build-Depends: debhelper-compat (= 12), dh-python, gettext, python3, python3-dbus, python3-xdg +Build-Depends: debhelper-compat (= 12), dh-python, gettext, python3-all, python3-dbus, python3-xdg Standards-Version: 3.9.8 Homepage: https://github.com/pulb/mailnag Vcs-Svn: svn://anonscm.debian.org/collab-maint/deb-maint/mailnag/trunk diff -Nru mailnag-2.0.0/debian/rules mailnag-2.0.0/debian/rules --- mailnag-2.0.0/debian/rules 2020-05-09 10:31:35.0 +0200 +++ mailnag-2.0.0/debian/rules 2020-05-24 13:08:07.0 +0200 @@ -1,5 +1,7 @@ #!/usr/bin/make -f +export PYBUILD_NAME=Mailnag + %: dh $@ --with python3 --buildsystem=pybuild
Bug#957140: dlt-daemon: ftbfs with GCC-10
hello, this https://github.com/GENIVI/dlt-daemon/pull/228/files might be a patch for it (it builds, but I'm not sure if it also works or not) G.
Bug#944253: dlt-daemon contains example systemd units for binaries in dlt-tools and libdlt-examples
control: tags -1 patch pending > Sorry for the delay. Now had a chance to look at this again. > sorry at the end the breaks/replaces were not needed because the files are installed into a different location now. I didn't spot that part. I uploaded in deferred/5 G.
Bug#961211: r-cran-lwgeom: autopkgtest failures on s390x
Source: r-cran-lwgeom
Version: 0.2-3-1
Severity: serious
Hello, looks like some changes in r-cran-lwgeom/proj/geom made the testsuite
fail with the latest versions
of the programs in sid.
Looks like an endianess regression introduced in the last version fo lwgeom,
can you please have a look?
I'm attaching a log taken from a test on zelenka.debian.org
thanks
Gianfranco
BEGIN TEST azimuth.R
R version 4.0.0 (2020-04-24) -- "Arbor Day"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: s390x-ibm-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> suppressPackageStartupMessages(library(sf))
> suppressPackageStartupMessages(library(lwgeom))
> p = st_sfc(st_point(c(7,52)), st_point(c(8,53)), crs = 4326)
> st_geod_azimuth(p)
Unknown WKB type (248)! Full WKB type number was (16777248).
Error in CPL_geodetic_azimuth(st_geometry(x), p$SemiMajor, p$InvFlattening) :
lwgeom error
Calls: st_geod_azimuth -> CPL_geodetic_azimuth
Execution halted
BEGIN TEST dist.R
R version 4.0.0 (2020-04-24) -- "Arbor Day"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: s390x-ibm-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> suppressPackageStartupMessages(library(sf))
> library(sp)
> suppressPackageStartupMessages(library(units))
> library(geosphere)
>
> x = st_sfc(
+ st_point(c(0,0)),
+ st_point(c(1,0)),
+ st_point(c(2,0)),
+ st_point(c(3,0)),
+ crs = 4326
+ )
>
> y = st_sfc(
+ st_point(c(0,10)),
+ st_point(c(1,0)),
+ st_point(c(2,0)),
+ st_point(c(3,0)),
+ st_point(c(4,0)),
+ crs = 4326
+ )
>
> st_crs(y) = 4326
> st_crs(x) = 4326
> (d.sf = st_distance(x, y))
Error in CPL_geodetic_distance(st_geometry(x), st_geometry(y), p$SemiMajor, :
Unknown WKB type (248)! Full WKB type number was (16777248).
Calls: st_distance -> -> CPL_geodetic_distance
Execution halted
BEGIN TEST geod.R
R version 4.0.0 (2020-04-24) -- "Arbor Day"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: s390x-ibm-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> ### Name: lw_geodetic
> ### Title: geodetic length, area, and predicates
> ### Aliases: lw_geodetic st_geod_area lw_geodetic st_geod_length
> ### lw_geodetic st_geod_segmentize lw_geodetic st_geod_covers
>
> ### ** Examples
>
> suppressPackageStartupMessages(library(sf))
> suppressPackageStartupMessages(library(lwgeom))
> suppressPackageStartupMessages(library(units))
> nc = st_read(system.file("gpkg/nc.gpkg", package="sf"), quiet = TRUE)
> st_geod_area(nc[1:3,])
Unknown WKB type (296)! Full WKB type number was (100663296).
Error in CPL_geodetic_area(st_geometry(x), p$SemiMajor, p$InvFlattening) :
lwgeom error
Calls: st_geod_area -> CPL_geodetic_area
Execution halted
BEGIN TEST perimeter.R
R version 4.0.0 (2020-04-24) -- "Arbor Day"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: s390x-ibm-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> suppressPackageStartupMessages(library(lwgeom))
> suppressPackageStartupMessages(library(sf))
> nc = st_read(system.file("gpkg/nc.gpkg", package="sf"), quiet = TRUE)
> nc = st_transform(nc, 3857)
> st_perimeter(nc)[1:5]
Unknown WKB type (328)! Full WKB type number was (100663328).
Error in
Bug#960899: paramiko: autopkgtests failures
Hello, after trying approach "b" > b) the autopkgtest needs to install recommends too I get some new autopkgtests failures such as: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/p/paramiko/20200518_022340_86e27@/log.gz (they are all new tests) G.
Bug#960899: paramiko: autopkgtests failures
Source: paramiko Version: 2.7.1-1 Severity: serious Hello, looks like the latest paramiko version is now failing its autopkgtests. Not sure if a) "invoke" should be moved from recommends to depends b) the autopkgtest needs to install recommends too c) something else Processing triggers for libc-bin (2.30-8) ... (Reading database ... 13936 files and directories currently installed.) Removing autopkgtest-satdep (0) ... autopkgtest [19:10:54]: test upstream: [--- = test session starts == platform linux -- Python 3.8.3, pytest-4.6.9, py-1.8.1, pluggy-0.13.0 -- /usr/bin/python3 cachedir: .pytest_cache rootdir: /tmp/autopkgtest-lxc.5uagjxdu/downtmp/build.uH0/src, inifile: setup.cfg collecting ... collected 257 items / 1 errors / 256 selected ERRORS ERROR collecting tests/test_config.py _ ImportError while importing test module '/tmp/autopkgtest-lxc.5uagjxdu/downtmp/build.uH0/src/tests/test_config.py'. Hint: make sure your test modules/packages have valid Python names. Traceback: tests/test_config.py:9: in from invoke import Result E ModuleNotFoundError: No module named 'invoke' !!! Interrupted: 1 errors during collection === 1 error in 0.59 seconds autopkgtest [19:10:55]: test upstream: ---] autopkgtest [19:10:55]: test upstream: - - - - - - - - - - results - - - - - - - - - - upstream FAIL non-zero exit status 2 autopkgtest [19:10:55]: summary cheers, Gianfranco
Bug#960832: dch, fix with --vendor=Debian?
Hello again, I'm not sure but this might be a fix for the issue:
It works, but I'm not sure if this is a good fix or not, I'm not tagging the
bug as "patch" :)
--- lintian-brush-0.64/lintian_brush/__init__.py2020-05-16
16:33:36.0 +0200
+++ lintian-brush-0.64ubuntu2/lintian_brush/__init__.py 2020-05-17
12:55:43.0 +0200
@@ -617,7 +617,7 @@
path: Path to the changelog file
summary: Entry to add
"""
-args = ["dch", "--no-auto-nmu"]
+args = ["dch", "--no-auto-nmu", "--vendor=debian"]
if qa:
args.append('--qa')
p = subprocess.Popen(
thanks for considering it and maintaining the package,
Gianfranco
Bug#960832: lintian-brush: please exclude dch tests in Ubuntu
Source: lintian-brush
Version: 0.64
Severity: normal
Hello, looks like in Ubuntu dch -i is different w.r.t. Debian, so the package
FTBFS there.
https://launchpadlibrarian.net/480139410/buildlog_ubuntu-groovy-amd64.lintian-brush_0.64_BUILDING.txt.gz
fixer test: simple for binary-control-field-duplicates-source ... ok
==
FAIL: test_add_new (lintian_brush.tests.test_run.ChangelogAddEntryTests)
lintian_brush.tests.test_run.ChangelogAddEntryTests.test_add_new
--
testtools.testresult.real._StringException: log: {{{
1.156 creating repository in
file:///tmp/testbzr-11xllwu6.tmp/lintian_brush.tests.test_run.ChangelogAddEntryTests.test_add_new/work/.bzr/.
1.157 creating branch in
file:///tmp/testbzr-11xllwu6.tmp/lintian_brush.tests.test_run.ChangelogAddEntryTests.test_add_new/work/
1.161 trying to create missing lock
'/tmp/testbzr-11xllwu6.tmp/lintian_brush.tests.test_run.ChangelogAddEntryTests.test_add_new/work/.bzr/checkout/dirstate'
1.162 opening working tree
'/tmp/testbzr-11xllwu6.tmp/lintian_brush.tests.test_run.ChangelogAddEntryTests.test_add_new/work'
}}}
Traceback (most recent call last):
File "/<>/lintian_brush/tests/test_run.py", line 913, in
test_add_new
self.assertEqual([
File "/usr/lib/python3/dist-packages/breezy/tests/__init__.py", line 1315, in
assertEqual
raise AssertionError("%snot equal:\na = %s\nb = %s\n"
AssertionError: not equal:
a = ['lintian-brush (0.36) UNRELEASED; urgency=medium', '', ' * Add a foo', '']
b = ['lintian-brush (0.35ubuntu1) UNRELEASED; urgency=medium',
'',
' * Add a foo',
'']
--
Ran 574 tests in 37.609s
FAILED (failures=1, expected failures=1)
The Ubuntu patch currently is now to ignore that test in Ubuntu
http://launchpadlibrarian.net/480139452/lintian-brush_0.64_0.64ubuntu1.diff.gz
Can you please have a look and fix the package so it works on both Debian and
Ubuntu?
thanks
Gianfranco
