Bug#966483: iptables-netflow: sourcing of external scripts in dkms file?
Hello Axel, > Yeah, and the version.sh call itself can be removed, too. Will do. > > Thanks for bringing this up despite the initially differing opinions. > :-) > thanks to you! And forgive me if I wasn't clear enough, I wrote the email after a somewhat deep analysis of the issue, and my initial effort was to have something like a "dkms.in" evaulated during build into a "dkms" file, after doing the substitutions. Unfortunately, it became a little difficult to implement, due to the version.sh file not being easy to convert into a "sed s/FOO/foo/g < dkms.in > dkms" This is what I did before thinking it was not easily upstreamable: diff -Nru iptables-netflow-2.5/debian/patches/patch iptables-netflow-2.5/debian/patches/patch --- iptables-netflow-2.5/debian/patches/patch 1970-01-01 01:00:00.0 +0100 +++ iptables-netflow-2.5/debian/patches/patch 2020-08-11 21:00:13.0 +0200 @@ -0,0 +1,30 @@ +--- iptables-netflow-2.5.orig/Makefile.in iptables-netflow-2.5/Makefile.in +@@ -43,7 +43,7 @@ mclean: + lclean: + -rm -f *.so *_sh.o + clean: mclean lclean +- -rm -f *.so *.o modules.order version.h compat_def.h ++ -rm -f *.so *.o modules.order version.h compat_def.h dkms.conf + + snmp_NETFLOW.so: snmp_NETFLOW.c + $(CC) -fPIC -shared -o $@ $< -lnetsnmp +@@ -76,6 +76,7 @@ version.h: ipt_NETFLOW.c ipt_NETFLOW.h c + + linstall: | libipt_NETFLOW.so libip6t_NETFLOW.so + @echo " *" ++ sed s/@VERSION@/$(shell ./version.sh)/g < dkms.conf.in > dkms.conf + install -D libipt_NETFLOW.so $(DESTDIR)$(IPTABLES_MODULES)/libipt_NETFLOW.so + install -D libip6t_NETFLOW.so $(DESTDIR)$(IPTABLES_MODULES)/libip6t_NETFLOW.so + +--- /dev/null iptables-netflow-2.5/dkms.conf.in +@@ -0,0 +1,8 @@ ++PACKAGE_NAME="ipt-netflow" ++PACKAGE_VERSION=@VERSION@ ++BUILT_MODULE_NAME[0]=ipt_NETFLOW ++DEST_MODULE_LOCATION[0]=/kernel/extra ++STRIP[0]=no ++MAKE[0]="make ipt_NETFLOW.ko" ++PRE_BUILD="./configure --from-dkms-conf=$kernel_source_dir" ++AUTOINSTALL=yes and then I simplified rules file, to drop the VERSION sed. --- iptables-netflow-2.5/debian/rules 2020-05-20 17:20:43.0 +0200 +++ iptables-netflow-2.5/debian/rules 2020-08-11 21:01:54.0 +0200 @@ -42,5 +42,5 @@ [ ! -e Makefile ] || $(MAKE) lclean override_dh_dkms: - sed -e 's#`\./version.sh`#$(DEB_VERSION_UPSTREAM)#;s#^PRE_BUILD="\(.*\)"#PRE_BUILD="\1 $(DKMS_CONFIGURE_OPTIONS)"#' dkms.conf > debian/dkms + sed -e 's#^PRE_BUILD="\(.*\)"#PRE_BUILD="\1 $(DKMS_CONFIGURE_OPTIONS)"#' dkms.conf > debian/dkms dh_dkms this looks somewhat upstreamable, and also Debian friendly (I'm not sure if having a .git directory makes the script fail to provide the correct output, this is one reason for me not giving the patch before) Feel free to send it upstream if you like it! thanks a lot! G.
Bug#966483: iptables-netflow: sourcing of external scripts in dkms file?
Hello! > Not "external" stuff but stuff from its own source. > oops, you are right... > > I don't think this is a sane idea, > > I disagree. Using pushd/popd (or "cd -") in scripts is a valid way to > avoid a helper variable to save the previous directory. > > But what I dislike in the aforementioned code snippet is that > $BASH_SOURCE is > > a) used at all and hence the script is not bourne-shell compatible. > b) is used in an unclear way (couldn't find in bash(1) what the >meaning of using an array as scalar should return. From my >experiments, it seems to return its first value.) > > I also disagree that "I don't think this is a sane idea" is RC-level, > not even important. Hence downgrading to "normal. > right also here > > specially because in Debian we don't even use version.sh script to > > fill the dkms.conf file. > > I don't understand what you refer to with "in Debian". Do you mean the > fact that I didn't ship the package's upstream's version.sh? Do you > think I should? I think we shouldn't, because it is used/useful only at build time... > > > Can you please remove the two lines? > > At least not in the way you propsed. Hence removing the tag "patch". > > > this is what we do to test dkms packages: > [...] > > dkms_pkg=$(bash -c ". $dkms_conf; echo \$PACKAGE_NAME" 2>/dev/null) > > dkms_ver=$(bash -c ". $dkms_conf; echo \$PACKAGE_VERSION" 2>/dev/null) > > You could do ". $dkms_conf > /dev/null" > interesting, this works indeed: +dkms_pkg=$(bash -c ". $dkms_conf > /dev/null; echo \$PACKAGE_NAME" 2>/dev/null) +dkms_ver=$(bash -c ". $dkms_conf > /dev/null; echo \$PACKAGE_VERSION" 2>/dev/null) (and uploaded in sid) Honestly, I still think my patch is something sane to do (of course, as Debian specific patch), because of this done in rules file: override_dh_dkms: sed -e 's#`\./version.sh`#$(DEB_VERSION_UPSTREAM)#;s#^PRE_BUILD="\(.*\)"#PRE_BUILD="\1 $(DKMS_CONFIGURE_OPTIONS)"#' dkms.conf > debian/dkms dh_dkms so, in any case, that version.sh is *never* ran in Debian packaging, so the whole pushd/popd are useless in this context. G.
Bug#968225: advi: FTBFS in sid
Source: advi Version: 1.10.2-6 Severity: serious dh_fixperms dh_missing dh_dwz dwz: debian/advi/usr/bin/advi: DWARF version 0 unhandled dwz: Too few files for multifile optimization dh_dwz: error: dwz -mdebian/advi/usr/lib/debug/.dwz/x86_64-linux-gnu/advi.debug -M/usr/lib/debug/.dwz/x86_64-linux-gnu/advi.debug -- debian/advi/usr/bin/advi debian/advi/usr/lib/ocaml/stublibs/dlladvi.so returned exit code 1 Looks like also advi got trapped by this new bug... G.
Bug#957063: calculix-cgx: ftbfs with GCC-10
control: fixed -1 2.17+dfsg-1
control: close -1
We can consider it "fixed" in the new release
G.
On Fri, 17 Apr 2020 10:57:34 + Matthias Klose wrote:
> Package: src:calculix-cgx
> Version: 2.11+dfsg-1
> Severity: normal
> Tags: sid bullseye
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-10
>
> Please keep this issue open in the bug tracker for the package it
> was filed for. If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
>
> The package fails to build in a test rebuild on at least amd64 with
> gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The
> severity of this report will be raised before the bullseye release,
> so nothing has to be done for the buster release.
>
> The full build log can be found at:
> http://people.debian.org/~doko/logs/gcc10-20200225/calculix-cgx_2.11+dfsg-1_unstable_gcc10.log
> The last lines of the build log are at the end of this report.
>
> To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
>
> apt-get -t=experimental install g++
>
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++ related build failures see the porting guide at
> http://gcc.gnu.org/gcc-10/porting_to.html
>
> [...]
> generateTet.cpp:402:10: warning: deprecated conversion from string constant
> to ‘char*’ [-Wwrite-strings]
> 402 | delSet("+snodSet");
> | ^~
> generateTet.cpp:403:10: warning: deprecated conversion from string constant
> to ‘char*’ [-Wwrite-strings]
> 403 | delSet("+velemSet");
> | ^~~
> generateTet.cpp:404:20: warning: deprecated conversion from string constant
> to ‘char*’ [-Wwrite-strings]
> 404 | snodSet=pre_seta("+snodSet","i",0);
> |^~
> generateTet.cpp:404:31: warning: deprecated conversion from string constant
> to ‘char*’ [-Wwrite-strings]
> 404 | snodSet=pre_seta("+snodSet","i",0);
> | ^~~
> generateTet.cpp:405:18: warning: deprecated conversion from string constant
> to ‘char*’ [-Wwrite-strings]
> 405 | setNr=pre_seta("+velemSet","i",0);
> | ^~~
> generateTet.cpp:405:30: warning: deprecated conversion from string constant
> to ‘char*’ [-Wwrite-strings]
> 405 | setNr=pre_seta("+velemSet","i",0);
> | ^~~
> generateTet.cpp:419:39: warning: deprecated conversion from string constant
> to ‘char*’ [-Wwrite-strings]
> 419 | for(k=0; k<3; k++)
> seta(snodSet,"n",e_enqire[surf[s].elem[i]].nod[k]);
> | ^~~
> generateTet.cpp:439:14: warning: deprecated conversion from string constant
> to ‘char*’ [-Wwrite-strings]
> 439 | { errMsg("ERROR: realloc failure in generateTet\n"); return(0); }
> | ^
> generateTet.cpp:500:19: warning: deprecated conversion from string constant
> to ‘char*’ [-Wwrite-strings]
> 500 | if ( ( readNG( "test.vol", anz_ng, , _ng, _ng,
> NULL)) == -1)
> | ^~
Bug#968176: gdcm: wrong debian/control file (mono archs missing)
Source: gdcm Version: 3.0.7-2 Severity: serious Hello, your debian/control file is missing the restrictions for archs (e.g. ports, and mips64el), leading to BD-uninstallabilities where mono is not available. Please refresh the file to make it build everywhere thanks Gianfranco
Bug#965018: RFS: freetype-py/2.2.0-1 -- Freetype Python bindings for Python 3
control: tags -1 moreinfo On Sat, 1 Aug 2020 10:25:24 +0200 Bastian Germann wrote: > On Wed, 29 Jul 2020 17:45:32 +0200 mat...@debian.org wrote: > > That's the `clean` step that is failing, which is done outside of the > > chroot. That's responsability of whoever is calling `pdebuild` to > > satisfy. > > > > If you are sure your source is clean you may as well just skip cleaning > > and not use pdebuild: > > dpkg-source -b . > > dpkg-source --after-build . > > pbuilder b ../freetype-py_2.2.0-1.dsc > > the above sequence should prove that nothing is at fault here. > > The package builds fine with the given steps. > > nack. +Copyright 2010-2018 Adobe (http://www.adobe.com/), with Reserved Font Name 'Source'. All Rights Reserved. Source is a trademark of Adobe in the United States and/or other countries. + +This Font Software is licensed under the SIL Open Font License, Version 1.1. missing licenses other stuff LGTM G.
Bug#966655: orthanc: using tzdata but missing dependency on it?
Source: orthanc Version: 1.7.2+dfsg-1 Severity: serious tags: patch Hello, looks like orthanc fails to build from source (testsuite error) when tzdata is not installed in the chroot. I'm not sure if this is an essential package or not, but looks like it can be removed, or not be available on some chroots this is an example of failure mkdir -p /<>/debian/tmp/locale/ localedef -f UTF-8 -i en_US /<>/debian/tmp/locale/en_US.UTF-8/ ( cd Build; LOCPATH=/<>/debian/tmp/locale/ ./UnitTests ) E0731 17:53:29.829350 OrthancException.h:76] Internal error: On UNIX-like systems, the file /etc/localtime must be present on the filesystem (install "tzdata" package on Debian) terminate called after throwing an instance of 'Orthanc::OrthancException' Aborted (core dumped) make[1]: *** [debian/rules:73: override_dh_auto_test] Error 134 I think adding it as explicit dependency might solve some headaches. G.
Bug#966654: libgpiod: symbol mismatches with gcc-10/O3 optimization
Source: libgpiod Version: 1.5.1-1 Severity: serious tags: patch Hello, looks like some symbols are disappearing when built with -O3 optimization level, and some other changed in armhf and ppc64el (probably due to gcc-10) the following patch seems to be enough to make everybody happy, by making some symbols optional. thanks for considering it G. --- libgpiod-1.5.1/debian/changelog 2020-07-01 05:27:41.0 +0200 +++ libgpiod-1.5.1/debian/changelog 2020-07-31 20:08:33.0 +0200 @@ -1,3 +1,9 @@ +libgpiod (1.5.1-1.1) unstable; urgency=medium + + * Refresh symbols (Closes: #-1) + + -- Gianfranco Costamagna Fri, 31 Jul 2020 20:08:33 +0200 + libgpiod (1.5.1-1) unstable; urgency=medium * Import new upstream release diff -Nru libgpiod-1.5.1/debian/libgpiod2.symbols libgpiod-1.5.1/debian/libgpiod2.symbols --- libgpiod-1.5.1/debian/libgpiod2.symbols 2020-07-01 05:27:19.0 +0200 +++ libgpiod-1.5.1/debian/libgpiod2.symbols 2020-07-31 20:08:33.0 +0200 @@ -99,6 +99,8 @@ gpiod_line_update@Base 1.1 gpiod_version_string@Base 1.1 libgpiodcxx.so.1 libgpiod2 #MINVER# + (c++|optional)"std::_Function_base::~_Function_base()@Base" 1.5.1 + (c++|optional)"std::_Function_base::~_Function_base()@Base" 1.5.1 (c++)"gpiod::line_request::FLAG_ACTIVE_LOW@Base" 1.1 (c++)"gpiod::line_request::FLAG_OPEN_DRAIN@Base" 1.1 (c++)"gpiod::line_request::FLAG_OPEN_SOURCE@Base" 1.1 @@ -209,7 +211,7 @@ (c++)"std::system_error::system_error(int, std::_V2::error_category const&, std::__cxx11::basic_string, std::allocator > const&)@Base" 1.1 (c++)"std::system_error::system_error(std::error_code, char const*)@Base" 1.1 (c++)"std::system_error::system_error(int, std::_V2::error_category const&, std::__cxx11::basic_string, std::allocator > const&)@Base" 1.1 - (c++)"std::_Function_base::_Base_manager, std::allocator > const&)>::_M_manager(std::_Any_data&, std::_Any_data const&, std::_Manager_operation)@Base" 1.1 + (c++|optional)"std::_Function_base::_Base_manager, std::allocator > const&)>::_M_manager(std::_Any_data&, std::_Any_data const&, std::_Manager_operation)@Base" 1.1 (c++|arch= !armel !riscv64)"std::_Sp_counted_ptr::_M_dispose()@Base" 1.1 (c++|arch= !armel !riscv64)"std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_destroy()@Base" 1.1 (c++)"std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()@Base" 1.4.1 @@ -219,8 +221,8 @@ (c++|optional|arch-bits=32)"std::vector >::_M_default_append(unsigned int)@Base" 1.5.1 (c++|optional)"void std::__cxx11::basic_string, std::allocator >::_M_construct(char const*, char const*, std::forward_iterator_tag)@Base" 1.1 (c++|optional)"std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_get_insert_unique_pos(int const&)@Base" 1.1 - (c++|arch=amd64 arm64 ppc64el mips64el riscv64)"std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator >, int const&)@Base" 1.1 - (c++)"std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase(std::_Rb_tree_node >*)@Base" 1.1 + (c++|optional|arch=amd64 arm64 ppc64el mips64el riscv64)"std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator >, int const&)@Base" 1.1 + (c++|optional)"std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase(std::_Rb_tree_node >*)@Base" 1.1 (c++|arch= !armel !riscv64)"typeinfo for std::_Mutex_base<(__gnu_cxx::_Lock_policy)2>@Base" 1.1 (c++|arch= !armel !riscv64)"typeinfo for std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>@Base" 1.1 (c++|arch= !armel !riscv64)"typeinfo name for std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>@Base" 1.4 @@ -235,6 +237,6 @@ (c++|arch= armel riscv64)"typeinfo name for __gnu_cxx::__mutex@Base" 1.2 (c++|arch= armel riscv64)"typeinfo name for std::_Mutex_base<(__gnu_cxx::_Lock_policy)1>@Base" 1.2 (c++|arch= armel riscv64)"typeinfo name for std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)1>@Base" 1.2 - (c++|arch= i386 armel mipsel armhf s390x)"std::map, std::allocator > >::map(std::initializer_list >, std::less const&, std::allocator > const&)@Base" 1.3 + (c++|optional|arch= i386 armel mipsel armhf s390x)"std::map, std::allocator > >::map(std::initializer_list >, std::less const&, std::allocator > const&)@Base" 1.3 (c++|arch= !armel !riscv64)"std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()@Base" 1.4.1 (c++|arch= !armel !riscv64)"typeinfo name for std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>@Base" 1.4.1
Bug#966613: orthanc-postgresql
Source: orthanc-postgresql
Version: 3.2-2
tags: patch
Hello, can you please add support for postgresql12?
(and maybe consider also adding 13)
thanks!
(note: I'm not the author for the patch, and I don't speak mercurial, so please
forward upstream!)
trivial patch:
diff -Nru orthanc-postgresql-3.2/debian/patches/pg12.patch
orthanc-postgresql-3.2/debian/patches/pg12.patch
--- orthanc-postgresql-3.2/debian/patches/pg12.patch1970-01-01
00:00:00.0 +
+++ orthanc-postgresql-3.2/debian/patches/pg12.patch2020-02-06
01:11:19.0 +
@@ -0,0 +1,15 @@
+Description: Add pg12 to cmake detection.
+Author: Dimitri John Ledkov
+
+
+--- orthanc-postgresql-3.2.orig/Resources/CMake/PostgreSQLConfiguration.cmake
orthanc-postgresql-3.2/Resources/CMake/PostgreSQLConfiguration.cmake
+@@ -378,7 +378,7 @@ if (STATIC_BUILD OR NOT USE_SYSTEM_LIBPQ
+
+ else()
+ set(PostgreSQL_ADDITIONAL_VERSIONS
+-"11" "10" "9.6" "9.5" "9.4" "9.3" "9.2" "9.1" "9.0" "8.4" "8.3" "8.2"
"8.1" "8.0")
++"12" "11" "10" "9.6" "9.5" "9.4" "9.3" "9.2" "9.1" "9.0" "8.4" "8.3"
"8.2" "8.1" "8.0")
+ if (NOT WIN32)
+ foreach (suffix ${PostgreSQL_ADDITIONAL_VERSIONS})
+ list(APPEND PostgreSQL_ADDITIONAL_SEARCH_PATHS
diff -Nru orthanc-postgresql-3.2/debian/patches/series
orthanc-postgresql-3.2/debian/patches/series
--- orthanc-postgresql-3.2/debian/patches/series2020-04-03
05:42:37.0 +
+++ orthanc-postgresql-3.2/debian/patches/series2020-06-05
15:16:01.0 +
@@ -0,0 +1 @@
+pg12.patch
Bug#966600: nfstrace: patch for newer json-c/gcc-10
control: forwarded -1 https://github.com/epam/nfstrace/pull/42 G.
Bug#966600: nfstrace: patch for newer json-c/gcc-10
:) https://github.com/epam/nfstrace/pull/42 Il venerdì 31 luglio 2020, 11:41:12 CEST, Andrej Shadura ha scritto: Hi, On Fri, 31 Jul 2020, at 11:23, Gianfranco Costamagna wrote: > Source: nfstrace > Version: 0.4.3.2+git20180104+6561cf6-1 > Severity: serious > tags: patch > > hello, attached a patch that makes it build with newer json-c/gcc-10 Thanks! Could you please also submit it upstream or should I? -- Cheers, Andrej
Bug#966597: multipath-tools: patch for newer json-c
hello, I see lots of various people upstream did sed s/TRUE/1/g sed s/FALSE/0/g :) G. Il venerdì 31 luglio 2020, 11:29:45 CEST, Chris Hofstaedtler ha scritto: Hi Gianfranco, * Gianfranco Costamagna [200731 10:30]: > Source: multipath-tools > Version: 0.8.4-2 > Severity: serious > tags: patch > > hello, attached a patch that makes it build with newer json-c Thanks! I'm considering going with a somewhat different patch given TRUE is used only once at all. Should be done soon. Chris
Bug#957236: frr: ftbfs with GCC-10
control: close -1 thanks G. On Fri, 17 Apr 2020 11:00:39 + Matthias Klose wrote: > Package: src:frr > Version: 7.2.1-1 > Severity: normal > Tags: sid bullseye > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-10 > > Please keep this issue open in the bug tracker for the package it > was filed for. If a fix in another package is required, please > file a bug for the other package (or clone), and add a block in this > package. Please keep the issue open until the package can be built in > a follow-up test rebuild. > > The package fails to build in a test rebuild on at least amd64 with > gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The > severity of this report will be raised before the bullseye release, > so nothing has to be done for the buster release. > > The full build log can be found at: > http://people.debian.org/~doko/logs/gcc10-20200225/frr_7.2.1-1_unstable_gcc10.log > The last lines of the build log are at the end of this report. > > To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly, > or install the gcc, g++, gfortran, ... packages from experimental. > > apt-get -t=experimental install g++ > > Common build failures are new warnings resulting in build failures with > -Werror turned on, or new/dropped symbols in Debian symbols files. > For other C/C++ related build failures see the porting guide at > http://gcc.gnu.org/gcc-10/porting_to.html > > [...] > /bin/bash ./libtool --tag=CC --mode=link gcc -std=gnu11 -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -fno-omit-frame-pointer -funwind-tables -Wall -Wextra > -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith > -Wbad-function-cast -Wwrite-strings -Wno-unused-result -Wno-unused-parameter > -Wno-missing-field-initializers -pthread -export-dynamic-Wl,-z,relro > -Wl,-z,now -o ospf6d/ospf6d ospf6d/ospf6_main.o ospf6d/libospf6.a > lib/libfrr.la -lcap -ldl -lcrypt -ljson-c -lsystemd -lrt > libtool: link: gcc -std=gnu11 -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security > -fno-omit-frame-pointer -funwind-tables -Wall -Wextra -Wmissing-prototypes > -Wmissing-declarations -Wpointer-arith -Wbad-function-cast -Wwrite-strings > -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers > -pthread -Wl,-z -Wl,relro -Wl,-z -Wl,now -o ospfd/.libs/ospfd > ospfd/ospf_main.o -Wl,--export-dynamic ospfd/libfrrospf.a > lib/.libs/libfrr.so -lcap -lm -ldl -lcrypt -ljson-c -lsystemd -lrt -pthread > -Wl,-rpath -Wl,/usr/lib/x86_64-linux-gnu/frr > libtool: link: gcc -std=gnu11 -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security > -fno-omit-frame-pointer -funwind-tables -Wall -Wextra -Wmissing-prototypes > -Wmissing-declarations -Wpointer-arith -Wbad-function-cast -Wwrite-strings > -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers > -pthread -Wl,-z -Wl,relro -Wl,-z -Wl,now -o ospf6d/.libs/ospf6d > ospf6d/ospf6_main.o -Wl,--export-dynamic ospf6d/libospf6.a > lib/.libs/libfrr.so -lcap -ldl -lcrypt -ljson-c -lsystemd -lrt -pthread > -Wl,-rpath -Wl,/usr/lib/x86_64-linux-gnu/frr > /bin/bash ./libtool --tag=CC --mode=link gcc -std=gnu11 -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -fno-omit-frame-pointer -funwind-tables -Wall -Wextra > -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith > -Wbad-function-cast -Wwrite-strings -Wno-unused-result -Wno-unused-parameter > -Wno-missing-field-initializers -pthread -export-dynamic-Wl,-z,relro > -Wl,-z,now -o isisd/isisd isisd/isis_bpf.o isisd/isis_dlpi.o > isisd/isis_main.o isisd/isis_pfpacket.o yang/frr-isisd.yang.o isisd/libisis.a > lib/libfrr.la -lcap -ldl -lcrypt -ljson-c -lsystemd -lrt > /bin/bash ./libtool --tag=CC --mode=link gcc -std=gnu11 -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -fno-omit-frame-pointer -funwind-tables -Wall -Wextra > -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith > -Wbad-function-cast -Wwrite-strings -Wno-unused-result -Wno-unused-parameter > -Wno-missing-field-initializers -pthread -export-dynamic-Wl,-z,relro > -Wl,-z,now -o isisd/fabricd isisd/fabricd-isis_bpf.o > isisd/fabricd-isis_dlpi.o isisd/fabricd-isis_main.o > isisd/fabricd-isis_pfpacket.o isisd/libfabric.a lib/libfrr.la -lcap -ldl > -lcrypt -ljson-c -lsystemd -lrt > libtool: link: gcc -std=gnu11 -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security > -fno-omit-frame-pointer -funwind-tables -Wall -Wextra -Wmissing-prototypes > -Wmissing-declarations -Wpointer-arith -Wbad-function-cast -Wwrite-strings > -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers > -pthread -Wl,-z -Wl,relro -Wl,-z -Wl,now -o isisd/.libs/isisd > isisd/isis_bpf.o isisd/isis_dlpi.o
Bug#958010: yubikey-personalization: ftbfs with GCC-10
control: tags -1 patch On Sun, 26 Jul 2020 14:58:58 +0100 Shayan Doust wrote: > Hello, > > Any rough timeframe as to when this FTBFS is fixed? > > Kind regards, > Shayan Doust I'm attaching the upstream fix to this bug report. thanks G. ## Description: add some description ## Origin/Author: add some origin or author ## Bug: bug URL >From 09ea16d9e2030e4da6ad00c1e5147e962aa7ff84 Mon Sep 17 00:00:00 2001 From: Klas Lindfors Date: Mon, 17 Feb 2020 08:58:33 +0100 Subject: [PATCH] make header declarations extern fixes #155 --- ykpers-args.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ykpers-args.h b/ykpers-args.h index 2a63268..9ff455a 100644 --- a/ykpers-args.h +++ b/ykpers-args.h @@ -33,8 +33,8 @@ #include "ykpers.h" -const char *usage; -const char *optstring; +extern const char *usage; +extern const char *optstring; int args_to_config(int argc, char **argv, YKP_CONFIG *cfg, char *oathid, size_t oathid_len, const char **infname,
Bug#966606: yubikey-personalization: patch for newer json-c
FYI upstream did something like sed s/FALSE/0 and sed s/TRUE/1 on the code, instead of defining them. G. On Fri, 31 Jul 2020 12:56:16 +0200 Gianfranco Costamagna wrote: > Source: yubikey-personalization > Version: 1.20.0-2 > Severity: serious > tags: patch > > Hello, this is the trivial patch that makes the package build with newer > jsonc. > > Description: Patch to make it build with newer json-c deprecated TRUE/FALSE > defines > > Author: Gianfranco Costamagna > Last-Update: 2020-07-31 > > Index: yubikey-personalization-1.20.0/ykpers-json.c > === > --- yubikey-personalization-1.20.0.orig/ykpers-json.c > +++ yubikey-personalization-1.20.0/ykpers-json.c > @@ -36,6 +36,14 @@ > #include > #include > > +// not exported anymore by new json-c > +#ifndef TRUE > +#define TRUE 1 > +#endif > +#ifndef FALSE > +#define FALSE 0 > +#endif > + > #ifdef HAVE_JSON_OBJECT_OBJECT_GET_EX > #define yk_json_object_object_get(obj, key, value) > json_object_object_get_ex(obj, key, ) > #else > > > G. > > >
Bug#957595: netdata: ftbfs with GCC-10
control: tags -1 patch attached the upstream fix refreshed on top of the current debian version thanks Gianfranco On Fri, 17 Apr 2020 11:07:07 + Matthias Klose wrote: > Package: src:netdata > Version: 1.19.0-2 > Severity: normal > Tags: sid bullseye > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-10 > > Please keep this issue open in the bug tracker for the package it > was filed for. If a fix in another package is required, please > file a bug for the other package (or clone), and add a block in this > package. Please keep the issue open until the package can be built in > a follow-up test rebuild. > > The package fails to build in a test rebuild on at least amd64 with > gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The > severity of this report will be raised before the bullseye release, > so nothing has to be done for the buster release. > > The full build log can be found at: > http://people.debian.org/~doko/logs/gcc10-20200225/netdata_1.19.0-2_unstable_gcc10.log > The last lines of the build log are at the end of this report. > > To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly, > or install the gcc, g++, gfortran, ... packages from experimental. > > apt-get -t=experimental install g++ > > Common build failures are new warnings resulting in build failures with > -Werror turned on, or new/dropped symbols in Debian symbols files. > For other C/C++ related build failures see the porting guide at > http://gcc.gnu.org/gcc-10/porting_to.html > > [...] > gcc-I/usr/include/uuid -lcap -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -Wall -O3 -pthread -flto -I/usr/include/uuid >-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o nfacct.plugin > collectors/nfacct.plugin/plugin_nfacct.o > libnetdata/adaptive_resortable_list/adaptive_resortable_list.o > libnetdata/config/appconfig.o libnetdata/avl/avl.o libnetdata/buffer/buffer.o > libnetdata/clocks/clocks.o libnetdata/dictionary/dictionary.o > libnetdata/eval/eval.o libnetdata/libnetdata.o libnetdata/locks/locks.o > libnetdata/log/log.o libnetdata/popen/popen.o libnetdata/procfile/procfile.o > libnetdata/os.o libnetdata/simple_pattern/simple_pattern.o > libnetdata/socket/socket.o libnetdata/socket/security.o > libnetdata/statistical/statistical.o > libnetdata/storage_number/storage_number.o libnetdata/threads/threads.o > libnetdata/url/url.o libnetdata/json/json.o libnetdata/json/jsmn.o > libnetdata/health/health.o -lm -lz -lcrypto -lssl -luuid -luv -llz4 -lJudy > -lcrypto -lssl -ljson-c -lnetfilter_acct -lmnl > /usr/bin/ld: libnetdata/adaptive_resortable_list/adaptive_resortable_list.o > (symbol from plugin): in function `arl_callback_str2ull': > (.text+0x0): multiple definition of `silencers'; > collectors/nfacct.plugin/plugin_nfacct.o (symbol from plugin):(.text+0x0): > first defined here > /usr/bin/ld: libnetdata/config/appconfig.o (symbol from plugin): in function > `appconfig_section_compare': > (.text+0x0): multiple definition of `silencers'; > collectors/nfacct.plugin/plugin_nfacct.o (symbol from plugin):(.text+0x0): > first defined here > /usr/bin/ld: libnetdata/avl/avl.o (symbol from plugin): in function > `avl_search': > (.text+0x0): multiple definition of `silencers'; > collectors/nfacct.plugin/plugin_nfacct.o (symbol from plugin):(.text+0x0): > first defined here > /usr/bin/ld: libnetdata/buffer/buffer.o (symbol from plugin): in function > `buffer_reset': > (.text+0x0): multiple definition of `silencers'; > collectors/nfacct.plugin/plugin_nfacct.o (symbol from plugin):(.text+0x0): > first defined here > /usr/bin/ld: libnetdata/clocks/clocks.o (symbol from plugin): in function > `test_clock_boottime': > (.text+0x0): multiple definition of `silencers'; > collectors/nfacct.plugin/plugin_nfacct.o (symbol from plugin):(.text+0x0): > first defined here > /usr/bin/ld: libnetdata/dictionary/dictionary.o (symbol from plugin): in > function `dictionary_create': > (.text+0x0): multiple definition of `silencers'; > collectors/nfacct.plugin/plugin_nfacct.o (symbol from plugin):(.text+0x0): > first defined here > /usr/bin/ld: libnetdata/eval/eval.o (symbol from plugin): in function > `eval_and': > (.text+0x0): multiple definition of `silencers'; > collectors/nfacct.plugin/plugin_nfacct.o (symbol from plugin):(.text+0x0): > first defined here > /usr/bin/ld: libnetdata/libnetdata.o (symbol from plugin): in function > `strdupz': > (.text+0x0): multiple definition of `silencers'; > collectors/nfacct.plugin/plugin_nfacct.o (symbol from plugin):(.text+0x0): > first defined here > /usr/bin/ld: libnetdata/locks/locks.o (symbol from plugin): in function > `netdata_thread_disable_cancelability': > (.text+0x0): multiple definition of `silencers'; > collectors/nfacct.plugin/plugin_nfacct.o (symbol from plugin):(.text+0x0): > first defined here > /usr/bin/ld: libnetdata/log/log.o (symbol from plugin): in
Bug#966606: yubikey-personalization: patch for newer json-c
Source: yubikey-personalization Version: 1.20.0-2 Severity: serious tags: patch Hello, this is the trivial patch that makes the package build with newer jsonc. Description: Patch to make it build with newer json-c deprecated TRUE/FALSE defines Author: Gianfranco Costamagna Last-Update: 2020-07-31 Index: yubikey-personalization-1.20.0/ykpers-json.c === --- yubikey-personalization-1.20.0.orig/ykpers-json.c +++ yubikey-personalization-1.20.0/ykpers-json.c @@ -36,6 +36,14 @@ #include #include +// not exported anymore by new json-c +#ifndef TRUE +#define TRUE 1 +#endif +#ifndef FALSE +#define FALSE 0 +#endif + #ifdef HAVE_JSON_OBJECT_OBJECT_GET_EX #define yk_json_object_object_get(obj, key, value) json_object_object_get_ex(obj, key, ) #else G.
Bug#966604: libu2f-server: patch for newer json-c
Source: libu2f-server Version: 1.1.10-1 Severity: serious tags: patch Hello, this is the trivial patch that makes the package build with newer jsonc. Description: Patch to make it build with newer json-c deprecated TRUE/FALSE defines Author: Gianfranco Costamagna Last-Update: 2020-07-31 Index: libu2f-server-1.1.0/u2f-server/core.c === --- libu2f-server-1.1.0.orig/u2f-server/core.c +++ libu2f-server-1.1.0/u2f-server/core.c @@ -37,6 +37,14 @@ #include "b64/cdecode.h" #include "sha256.h" +// not exported anymore by new json-c +#ifndef TRUE +#define TRUE 1 +#endif +#ifndef FALSE +#define FALSE 0 +#endif + #ifdef HAVE_JSON_OBJECT_OBJECT_GET_EX #define u2fs_json_object_object_get(obj, key, value) json_object_object_get_ex(obj, key, ) #else G.
Bug#966602: libu2f-host: patch for newer json-c
Source: libu2f-host Version: 1.1.10-1 Severity: serious tags: patch Hello, this is the trivial patch that makes the package build with newer jsonc Description: Patch to make it build with newer json-c deprecated TRUE/FALSE defines Author: Gianfranco Costamagna Last-Update: 2020-07-31 --- libu2f-host-1.1.10.orig/u2f-host/u2fmisc.c +++ libu2f-host-1.1.10/u2f-host/u2fmisc.c @@ -26,6 +26,14 @@ #define HID_TIMEOUT 2 #define HID_MAX_TIMEOUT 4096 +// not exported anymore by new json-c +#ifndef TRUE +#define TRUE 1 +#endif +#ifndef FALSE +#define FALSE 0 +#endif + #ifdef HAVE_JSON_OBJECT_OBJECT_GET_EX #define u2fh_json_object_object_get(obj, key, value) json_object_object_get_ex(obj, key, ) #else G.
Bug#957217: forked-daapd: ftbfs with GCC-10
control: tags -1 patch Description: Fix build with gcc-10 Author: Gianfranco Costamagna Last-Update: 2020-07-31 --- forked-daapd-26.4+dfsg1.orig/src/input.h +++ forked-daapd-26.4+dfsg1/src/input.h @@ -137,7 +137,7 @@ struct input_definition /* * Input modules should use this to test if playback should end */ -int input_loop_break; +static int input_loop_break; /* * Transfer stream data to the player's input buffer. The input evbuf will be I uploaded this patch in Ubuntu, fixing the FTBFS. (upstream heavily refactored that code, so my suggestion is to move to the new upstream release if possible) G.
Bug#966601: dkms: move dh_dkms to a separate package
Hello,
On Fri, 31 Jul 2020 11:35:54 +0200 Andreas Beckmann wrote:
> Package: dkms
> Version: 2.8.3-3
> Severity: wishlist
>
> Hi,
>
> is it possible to move dh_dkms and friends into a separate package (dh-dkms)
> to be used as build-depends by the various packages building *-dkms packages?
> There is no need that installing build-dependencies attempts to build and
> install kernel modules on the build environent.
>
> I'm willing to look into this and provide a patch.
>
> Transition plan:
> 1. dkms Depends: dh-dkms (= ${binary:Version})
> 2. reverse B-D of dkms switch to dh-dkms
> 3. dkms drops Depends: dh-dkms
>
I like this, I'm not maintainer, but feel free to just do it, since looks like
"nobody" is actually maintaining the package :)
G.
Bug#964594: psensor FTBFS with libmicrohttpd 0.9.71
control: tags -1 patch pending
NMU ongoing
G.
On Thu, 09 Jul 2020 13:03:10 +0300 Adrian Bunk wrote:
> Source: psensor
> Version: 1.1.5-1.1
> Severity: serious
> Tags: ftbfs
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/psensor.html
>
> ...
> server.c: In function 'main':
> server.c:430:21: error: passing argument 5 of 'MHD_start_daemon' from
> incompatible pointer type [-Werror=incompatible-pointer-types]
> 430 | NULL, NULL, _http_request, server_data.sensors,
> | ^
> | |
> | int (*)(void *, struct MHD_Connection *, const
> char *, const char *, const char *, const char *, size_t *, void **) {aka int
> (*)(void *, struct MHD_Connection *, const char *, const char *, const char
> *, const char *, long unsigned int *, void **)}
> In file included from server.c:39:
> /usr/include/microhttpd.h:2425:1: note: expected 'MHD_AccessHandlerCallback'
> {aka 'enum MHD_Result (*)(void *, struct MHD_Connection *, const char *,
> const char *, const char *, const char *, long unsigned int *, void **)'} but
> argument is of type 'int (*)(void *, struct MHD_Connection *, const char *,
> const char *, const char *, const char *, size_t *, void **)' {aka 'int
> (*)(void *, struct MHD_Connection *, const char *, const char *, const char
> *, const char *, long unsigned int *, void **)'}
> 2425 | MHD_start_daemon (unsigned int flags,
> | ^~~~
> cc1: all warnings being treated as errors
> make[4]: *** [Makefile:471: server.o] Error 1
>
>
diff -Nru psensor-1.1.5/debian/changelog psensor-1.1.5/debian/changelog
--- psensor-1.1.5/debian/changelog 2019-08-12 15:41:22.0 +0200
+++ psensor-1.1.5/debian/changelog 2020-07-31 12:00:39.0 +0200
@@ -1,3 +1,11 @@
+psensor (1.1.5-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches/14.patch:
+- adapt to new mhd 0.9.71 with upstream (rebased) patch (Closes: #964594)
+
+ -- Gianfranco Costamagna Fri, 31 Jul 2020
12:00:39 +0200
+
psensor (1.1.5-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru psensor-1.1.5/debian/patches/14.patch
psensor-1.1.5/debian/patches/14.patch
--- psensor-1.1.5/debian/patches/14.patch 1970-01-01 01:00:00.0
+0100
+++ psensor-1.1.5/debian/patches/14.patch 2020-07-31 11:56:50.0
+0200
@@ -0,0 +1,34 @@
+From 3e8dfe6f2a4317c4cab3d5afec42abdefa3cc2df Mon Sep 17 00:00:00 2001
+From: Jean-Philippe Orsini
+Date: Fri, 17 Jul 2020 00:10:54 +0200
+Subject: [PATCH 1/7] fix compilation with microhttpd since version 0.9.71
+ which changes the return type of the cbk
+
+--- psensor-1.1.5.orig/src/server/server.c
psensor-1.1.5/src/server/server.c
+@@ -281,13 +281,18 @@ create_response(const char *nurl, const
+ MHD_RESPMEM_MUST_FREE);
+ }
+
+-static int cbk_http_request(void *cls,
+- struct MHD_Connection *connection,
+- const char *url,
+- const char *method,
+- const char *version,
+- const char *upload_data,
+- size_t *upload_data_size, void **ptr)
++#if MHD_VERSION < 0x00097002
++static int
++#else
++static enum MHD_Result
++#endif
++cbk_http_request(void *cls,
++ struct MHD_Connection *connection,
++ const char *url,
++ const char *method,
++ const char *version,
++ const char *upload_data,
++ size_t *upload_data_size, void **ptr)
+ {
+ static int dummy;
+ struct MHD_Response *response;
diff -Nru psensor-1.1.5/debian/patches/series
psensor-1.1.5/debian/patches/series
--- psensor-1.1.5/debian/patches/series 2019-06-30 10:33:04.0 +0200
+++ psensor-1.1.5/debian/patches/series 2020-07-31 11:57:13.0 +0200
@@ -1 +1,2 @@
0001-Update-rsensor.c-drop-is_error-macro-definition.patch
+14.patch
Bug#966600: nfstrace: patch for newer json-c/gcc-10
Source: nfstrace
Version: 0.4.3.2+git20180104+6561cf6-1
Severity: serious
tags: patch
hello, attached a patch that makes it build with newer json-c/gcc-10
thanks
Gianfranco
Description: gcc-10 build fixes
Author: Gianfranco Costamagna
Last-Update: 2020-07-31
--- nfstrace-0.4.3.2+git20180104+6561cf6.orig/analyzers/src/json/json_plugin.cpp
+++ nfstrace-0.4.3.2+git20180104+6561cf6/analyzers/src/json/json_plugin.cpp
@@ -23,6 +23,7 @@
#include "json_analyzer.h"
//--
+#include
static constexpr int DefaultPort = ;
static constexpr const char* DefaultHost = IpEndpoint::WildcardAddress;
static constexpr std::size_t DefaultWorkersAmount= 10U;
--- nfstrace-0.4.3.2+git20180104+6561cf6.orig/analyzers/src/watch/nc_windows/statistics_window.cpp
+++ nfstrace-0.4.3.2+git20180104+6561cf6/analyzers/src/watch/nc_windows/statistics_window.cpp
@@ -23,6 +23,7 @@
#include
#include
+#include
#include "nc_window_const.h"
#include "statistics_window.h"
--- nfstrace-0.4.3.2+git20180104+6561cf6.orig/analyzers/src/watch/user_gui.cpp
+++ nfstrace-0.4.3.2+git20180104+6561cf6/analyzers/src/watch/user_gui.cpp
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
--- nfstrace-0.4.3.2+git20180104+6561cf6.orig/src/analysis/analyzers.cpp
+++ nfstrace-0.4.3.2+git20180104+6561cf6/src/analysis/analyzers.cpp
@@ -22,6 +22,7 @@
#include "analysis/analyzers.h"
#include "analysis/print_analyzer.h"
#include "utils/out.h"
+#include
//--
namespace NST
{
--- nfstrace-0.4.3.2+git20180104+6561cf6.orig/src/controller/controller.h
+++ nfstrace-0.4.3.2+git20180104+6561cf6/src/controller/controller.h
@@ -24,6 +24,7 @@
#define CONTROLLER_H
//--
#include
+#include
#include "analysis/analysis_manager.h"
#include "controller/parameters.h"
--- nfstrace-0.4.3.2+git20180104+6561cf6.orig/src/controller/parameters.cpp
+++ nfstrace-0.4.3.2+git20180104+6561cf6/src/controller/parameters.cpp
@@ -21,6 +21,7 @@
//--
#include
#include
+#include
#include
#include
--- nfstrace-0.4.3.2+git20180104+6561cf6.orig/src/controller/running_status.h
+++ nfstrace-0.4.3.2+git20180104+6561cf6/src/controller/running_status.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include "utils/noncopyable.h"
//--
--- nfstrace-0.4.3.2+git20180104+6561cf6.orig/src/controller/signal_handler.cpp
+++ nfstrace-0.4.3.2+git20180104+6561cf6/src/controller/signal_handler.cpp
@@ -21,6 +21,7 @@
//--
#include
#include // std::ref
+#include
#include
#include
--- nfstrace-0.4.3.2+git20180104+6561cf6.orig/src/filtration/filtration_manager.cpp
+++ nfstrace-0.4.3.2+git20180104+6561cf6/src/filtration/filtration_manager.cpp
@@ -19,6 +19,7 @@
along with Nfstrace. If not, see <http://www.gnu.org/licenses/>.
*/
//--
+#include
#include
#include "filtration/dumping.h"
--- nfstrace-0.4.3.2+git20180104+6561cf6.orig/src/filtration/filtration_processor.h
+++ nfstrace-0.4.3.2+git20180104+6561cf6/src/filtration/filtration_processor.h
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
--- nfstrace-0.4.3.2+git20180104+6561cf6.orig/src/protocols/xdr/xdr_decoder.h
+++ nfstrace-0.4.3.2+git20180104+6561cf6/src/protocols/xdr/xdr_decoder.h
@@ -23,6 +23,7 @@
#define XDR_DECODER_H
//--
#include
+#include
#include
//--
#include "api/nfs3_types_rpcgen.h"
Bug#966597: rt-app: patch for newer json-c
control: retitle -1 multipath-tools: patch for newer json-c thanks! G. On Fri, 31 Jul 2020 10:27:16 +0200 Gianfranco Costamagna wrote: > Source: multipath-tools > Version: 0.8.4-2 > Severity: serious > tags: patch > > hello, attached a patch that makes it build with newer json-c > > Description: Patch to make it build with newer json-c deprecated TRUE/FALSE > defines > > Author: Gianfranco Costamagna > Last-Update: 2020-07-31 > > --- multipath-tools-0.8.4.orig/libdmmp/libdmmp_private.h > +++ multipath-tools-0.8.4/libdmmp/libdmmp_private.h > @@ -32,6 +32,14 @@ > #include > #include > > +// not exported anymore by new json-c > +#ifndef TRUE > +#define TRUE 1 > +#endif > +#ifndef FALSE > +#define FALSE 0 > +#endif > + > #include "libdmmp/libdmmp.h" > > #ifdef __cplusplus > > > thanks > > G. > > >
Bug#966597: rt-app: patch for newer json-c
Source: multipath-tools Version: 0.8.4-2 Severity: serious tags: patch hello, attached a patch that makes it build with newer json-c Description: Patch to make it build with newer json-c deprecated TRUE/FALSE defines Author: Gianfranco Costamagna Last-Update: 2020-07-31 --- multipath-tools-0.8.4.orig/libdmmp/libdmmp_private.h +++ multipath-tools-0.8.4/libdmmp/libdmmp_private.h @@ -32,6 +32,14 @@ #include #include +// not exported anymore by new json-c +#ifndef TRUE +#define TRUE 1 +#endif +#ifndef FALSE +#define FALSE 0 +#endif + #include "libdmmp/libdmmp.h" #ifdef __cplusplus thanks G.
Bug#966594: rt-app: patch for newer json-c
Source: rt-app
Version: 0.3-2
Severity: serious
tags: patch
hello, attached a patch that makes it build with newer json-c
thanks
G.
diff -Nru rt-app-0.3/debian/changelog rt-app-0.3/debian/changelog
--- rt-app-0.3/debian/changelog 2017-03-09 14:44:33.0 +0100
+++ rt-app-0.3/debian/changelog 2020-07-31 10:09:43.0 +0200
@@ -1,3 +1,9 @@
+rt-app (0.3-2.1) unstable; urgency=medium
+
+ * Patch for newer json-c (Closes: #-1)
+
+ -- Gianfranco Costamagna Fri, 31 Jul 2020
10:09:43 +0200
+
rt-app (0.3-2) unstable; urgency=medium
* Fix FTBFS on some arches by defining unsigned long long as __u64
diff -Nru rt-app-0.3/debian/patches/new-jsoncpp.patch
rt-app-0.3/debian/patches/new-jsoncpp.patch
--- rt-app-0.3/debian/patches/new-jsoncpp.patch 1970-01-01 01:00:00.0
+0100
+++ rt-app-0.3/debian/patches/new-jsoncpp.patch 2020-07-31 10:09:32.0
+0200
@@ -0,0 +1,35 @@
+Description: Patch for newer json-c removed is_error
+Author: Gianfranco Costamagna
+Last-Update: 2020-07-30
+
+Index: rt-app-0.3/src/rt-app_parse_config.c
+===
+--- rt-app-0.3.orig/src/rt-app_parse_config.c
rt-app-0.3/src/rt-app_parse_config.c
+@@ -18,9 +18,16 @@
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
USA.
+ */
+-#include
+ #include "rt-app_parse_config.h"
+
++// not exported anymore by new json-c
++#ifndef TRUE
++#define TRUE 1
++#endif
++#ifndef FALSE
++#define FALSE 0
++#endif
++
+ #define PFX "[json] "
+ #define PFL " "PFX
+ #define PIN PFX""
+@@ -886,7 +893,7 @@
+ {
+ struct json_object *global, *tasks, *resources;
+
+- if (is_error(root)) {
++ if (root == NULL) {
+ log_error(PFX "Error while parsing input JSON");
+ exit(EXIT_INV_CONFIG);
+ }
diff -Nru rt-app-0.3/debian/patches/series rt-app-0.3/debian/patches/series
--- rt-app-0.3/debian/patches/series2017-03-09 14:44:33.0 +0100
+++ rt-app-0.3/debian/patches/series2020-07-31 10:09:39.0 +0200
@@ -1 +1,2 @@
longlong-u64.diff
+new-jsoncpp.patch
Bug#966131: pylint: Requires old python3-isort (<<5) which won't be available in Debian
control: tags -1 patch
Hello, I grabbed the upstream proposed patch and rebased on top of the version
in Debian.
The result now builds fine and testsuite seems ok
attached!
G.
diff -Nru pylint-2.5.3/debian/changelog pylint-2.5.3/debian/changelog
--- pylint-2.5.3/debian/changelog 2020-07-21 08:18:14.0 +0200
+++ pylint-2.5.3/debian/changelog 2020-07-31 09:34:41.0 +0200
@@ -1,3 +1,10 @@
+pylint (2.5.3-1ubuntu1) groovy; urgency=medium
+
+ * debian/patches/3725.patch:
+- cherry-pick and adapt upstream proposed fix for new isort
+
+ -- Gianfranco Costamagna Fri, 31 Jul 2020
09:34:41 +0200
+
pylint (2.5.3-1) unstable; urgency=medium
* New upstream release
diff -Nru pylint-2.5.3/debian/patches/3725.patch
pylint-2.5.3/debian/patches/3725.patch
--- pylint-2.5.3/debian/patches/3725.patch 1970-01-01 01:00:00.0
+0100
+++ pylint-2.5.3/debian/patches/3725.patch 2020-07-31 09:34:41.0
+0200
@@ -0,0 +1,502 @@
+From db0a6524ac2b1709c1e295cc2377486f32da5bca Mon Sep 17 00:00:00 2001
+From: Damien Baty
+Date: Sun, 5 Jul 2020 23:06:04 +0200
+Subject: [PATCH 1/3] Support both isort 4 and isort 5
+
+The API of isort 5 (released on 2020-07-04) is completely different.
+We must still support isort 4 because isort 5 dropped the
+compatibility with Python 3.5, which pylint still supports.
+
+Fix #3722.
+---
+ ChangeLog | 4 +++
+ pylint/__pkginfo__.py | 2 +-
+ pylint/checkers/imports.py| 8 +++---
+ pylint/utils/__init__.py | 2 ++
+ pylint/utils/utils.py | 31 +++
+ tests/functional/w/wrong_import_order.txt | 6 ++---
+ tests/test_functional.py | 5
+ tox.ini | 4 ++-
+ 8 files changed, 52 insertions(+), 10 deletions(-)
+
+Index: pylint/ChangeLog
+===
+--- pylint.orig/ChangeLog
pylint/ChangeLog
+@@ -40,6 +40,10 @@
+
+ Close #3646
+
++* Support both isort 4 and isort 5.
++
++ Close #3722
++
+
+ What's New in Pylint 2.5.2?
+ ===
+Index: pylint/pylint/__pkginfo__.py
+===
+--- pylint.orig/pylint/__pkginfo__.py
pylint/pylint/__pkginfo__.py
+@@ -37,7 +37,7 @@
+
+ install_requires = [
+ "astroid>=2.4.0,<=2.5",
+-"isort>=4.2.5,<5",
++"isort>=4.2.5,<6",
+ "mccabe>=0.6,<0.7",
+ "toml>=0.7.1",
+ ]
+Index: pylint/pylint/checkers/imports.py
+===
+--- pylint.orig/pylint/checkers/imports.py
pylint/pylint/checkers/imports.py
+@@ -46,7 +46,6 @@
+ from distutils import sysconfig
+
+ import astroid
+-import isort
+ from astroid import modutils
+ from astroid.decorators import cached
+
+@@ -60,7 +59,7 @@
+ from pylint.graph import DotBackend, get_cycles
+ from pylint.interfaces import IAstroidChecker
+ from pylint.reporters.ureports.nodes import Paragraph, VerbatimText
+-from pylint.utils import get_global_option
++from pylint.utils import IsortDriver, get_global_option
+
+
+ def _qualified_names(modname):
+@@ -709,8 +708,7 @@
+ third_party_not_ignored = []
+ first_party_not_ignored = []
+ local_not_ignored = []
+-isort_obj = isort.SortImports(
+-file_contents="",
++isort_driver = IsortDriver(
+ known_third_party=self.config.known_third_party,
+ known_standard_library=self.config.known_standard_library,
+ )
+@@ -723,7 +721,7 @@
+ ignore_for_import_order = not self.linter.is_message_enabled(
+ "wrong-import-order", node.fromlineno
+ )
+-import_category = isort_obj.place_module(package)
++import_category = isort_driver.place_module(package)
+ node_and_package_import = (node, package)
+ if import_category in ("FUTURE", "STDLIB"):
+ std_imports.append(node_and_package_import)
+Index: pylint/pylint/utils/__init__.py
+===
+--- pylint.orig/pylint/utils/__init__.py
pylint/pylint/utils/__init__.py
+@@ -46,6 +46,8 @@
+ from pylint.utils.ast_walker import ASTWalker
+ from pylint.utils.file_state import FileState
+ from pylint.utils.utils import (
++HAS_ISORT_5,
++IsortDriver,
+ _basename_in_blacklist_re,
+ _check_csv,
+ _format_option_value,
+Index: pylint/pylint/utils/utils.py
+===
+--- pylint.orig/pylint/utils/utils.py
pylint/pylint/utils/utils.py
+@@ -1,6 +1,15 @@
+ # Licensed under the GPL:
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
+ # For details: https://github.com/PyCQA/pylin
Bug#966562: altos: hardcodes runtime json-c dependency
Source: altos Version: 1.9.4-1 Severity: serious tags: patch Hello, please update to -c5 or better drop it in case you want to keep it, sed s/libjson-c4/libjson-c5/g -i debian/control does the job G.
Bug#957289: gnss-sdr: ftbfs with GCC-10
fstack-protector-strong > -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 > -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra -std=c++2a -o > CMakeFiles/acquisition_adapters.dir/beidou_b3i_pcps_acquisition.cc.o -c > /<>/src/algorithms/acquisition/adapters/beidou_b3i_pcps_acquisition.cc > [ 95%] Building CXX object > src/algorithms/acquisition/adapters/CMakeFiles/acquisition_adapters.dir/galileo_e1_pcps_8ms_ambiguous_acquisition.cc.o > cd /<>/obj-x86_64-linux-gnu/src/algorithms/acquisition/adapters > && /usr/bin/c++ -DGNSSSDR_INSTALL_DIR=\"/usr\" -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE -D_LARGE_FILES -I/<>/src/core/interfaces > -I/<>/src/algorithms/libs/gsl/include > -I/<>/src/algorithms/libs > -I/<>/src/algorithms/acquisition/gnuradio_blocks > -I/<>/src/algorithms/libs/opencl > -I/<>/src/algorithms/acquisition/libs > -I/<>/src/core/receiver > -I/<>/src/algorithms/channel/libs > -I/<>/src/core/system_parameters -isystem /usr/include/glog > -isystem > /<>/obj-x86_64-linux-gnu/volk_gnsssdr_module/build/include > -isystem > /<>/src/algorithms/libs/volk_gnsssdr_module/volk_gnsssdr/include > -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong > -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 > -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra -std=c++2a -o > CMakeFiles/acquisition_adapters.dir/galileo_e1_pcps_8ms_ambiguous_acquisition.cc.o > -c > /<>/src/algorithms/acquisition/adapters/galileo_e1_pcps_8ms_ambiguous_acquisition.cc > [ 95%] Building CXX object > src/algorithms/acquisition/adapters/CMakeFiles/acquisition_adapters.dir/galileo_e1_pcps_ambiguous_acquisition.cc.o > cd /<>/obj-x86_64-linux-gnu/src/algorithms/acquisition/adapters > && /usr/bin/c++ -DGNSSSDR_INSTALL_DIR=\"/usr\" -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE -D_LARGE_FILES -I/<>/src/core/interfaces > -I/<>/src/algorithms/libs/gsl/include > -I/<>/src/algorithms/libs > -I/<>/src/algorithms/acquisition/gnuradio_blocks > -I/<>/src/algorithms/libs/opencl > -I/<>/src/algorithms/acquisition/libs > -I/<>/src/core/receiver > -I/<>/src/algorithms/channel/libs > -I/<>/src/core/system_parameters -isystem /usr/include/glog > -isystem > /<>/obj-x86_64-linux-gnu/volk_gnsssdr_module/build/include > -isystem > /<>/src/algorithms/libs/volk_gnsssdr_module/volk_gnsssdr/include > -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong > -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 > -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra -std=c++2a -o > CMakeFiles/acquisition_adapters.dir/galileo_e1_pcps_ambiguous_acquisition.cc.o > -c > /<>/src/algorithms/acquisition/adapters/galileo_e1_pcps_ambiguous_acquisition.cc > make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu' diff -Nru gnss-sdr-0.0.12/debian/changelog gnss-sdr-0.0.12/debian/changelog --- gnss-sdr-0.0.12/debian/changelog2020-03-12 20:10:59.0 +0100 +++ gnss-sdr-0.0.12/debian/changelog2020-07-29 11:11:13.0 +0200 @@ -1,3 +1,11 @@ +gnss-sdr (0.0.12-1.1) unstable; urgency=medium + + * debian/patches/76cce022ac51917242e5af905c2118669bec017e.patch: +- cherry-pick and rebase upstream fix for gcc-10 build failure (Closes: + #957289) + + -- Gianfranco Costamagna Wed, 29 Jul 2020 11:11:13 +0200 + gnss-sdr (0.0.12-1) unstable; urgency=medium * First release of upstream version 0.0.12 diff -Nru gnss-sdr-0.0.12/debian/patches/76cce022ac51917242e5af905c2118669bec017e.patch gnss-sdr-0.0.12/debian/patches/76cce022ac51917242e5af905c2118669bec017e.patch --- gnss-sdr-0.0.12/debian/patches/76cce022ac51917242e5af905c2118669bec017e.patch 1970-01-01 01:00:00.0 +0100 +++ gnss-sdr-0.0.12/debian/patches/76cce022ac51917242e5af905c2118669bec017e.patch 2020-07-29 11:11:13.0 +0200 @@ -0,0 +1,79 @@ +From 76cce022ac51917242e5af905c2118669bec017e Mon Sep 17 00:00:00 2001 +From: Carles Fernandez +Date: Mon, 27 Jul 2020 09:53:01 +0200 +Subject: [PATCH] Fix building in Ubuntu 20.10 + +--- + .../adapters/osmosdr_signal_source.cc | 29 +-- + 1 file changed, 14 insertions(+), 15 deletions(-) + +diff --git a/src/algorithms/signal_source/adapters/osmosdr_signal_source.cc b/src/algorithms/signal_source/adapters/osmosdr_signal_source.cc +index b3c32a2bd..b62e8fc3a 100644 +--- a/src/algorithms/signal_source/adapters/osmosdr_signal_source.cc b/src/algorithms/signal_source/adapters/osmosdr_signal_source.cc +@@ -22,7 +22,6 @@ + #include "GPS_L1_CA.h" + #include "configuration_interface.h" + #include "gnss_sdr_valve
Bug#966483: iptables-netflow: sourcing of external scripts in dkms file?
Source: iptables-netflow Version: 2.5-2 Severity: serious tags: patch Hello, looks like your dkms ship file is sourcing external stuff with pushd/popd and so on. I don't think this is a sane idea, specially because in Debian we don't even use version.sh script to fill the dkms.conf file. Can you please remove the two lines? this is what we do to test dkms packages: if ! dkms_conf=$(dpkg -L $pkg | grep '/usr/src' | grep '/dkms.conf$'); then echo "I: Package $pkg has no dkms.conf, skipping" return fi echo "I: Testing binary package $pkg" dkms_pkg=$(bash -c ". $dkms_conf; echo \$PACKAGE_NAME" 2>/dev/null) dkms_ver=$(bash -c ". $dkms_conf; echo \$PACKAGE_VERSION" 2>/dev/null) bash -c ". dkms.conf; echo \$PACKAGE_NAME" /tmp/iptables-netflow-2.5 /tmp/iptables-netflow-2.5 /tmp/iptables-netflow-2.5 ipt-netflow I think dkms.conf files are meant to be sourced from outside, and launching scripts is a bad idea. this is the trivial patch: Description: Don't print useless stuff and change directory in dkms file, it is meant to be sourced from outside. Author: Gianfranco Costamagna Bug-Debian: https://bugs.debian.org/-1 Last-Update: 2020-07-29 --- iptables-netflow-2.5.orig/dkms.conf +++ iptables-netflow-2.5/dkms.conf @@ -1,7 +1,5 @@ PACKAGE_NAME="ipt-netflow" -pushd `dirname $BASH_SOURCE` PACKAGE_VERSION=`./version.sh` -popd BUILT_MODULE_NAME[0]=ipt_NETFLOW DEST_MODULE_LOCATION[0]=/kernel/extra STRIP[0]=no
Bug#966479: sysdig: broken support on 32 bit kernels?
Source: sysdig Version: 0.26.7-2 Severity: serious Forwarded: https://github.com/draios/sysdig/issues/1669 Hello, I don't know if this happens also in Debian, but there is no reason for it not happening there. I asked upstream for help, this is what happens: CC [M] /var/lib/dkms/sysdig/0.26.7/build/ppm_cputime.o LD [M] /var/lib/dkms/sysdig/0.26.7/build/sysdig-probe.o Building modules, stage 2. MODPOST 1 modules ERROR: "__aeabi_uldivmod" [/var/lib/dkms/sysdig/0.26.7/build/sysdig-probe.ko] undefined! make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1 thanks for having a look Gianfranco
Bug#959910: dkms: improve dkms-autopkgtest
Hello, nevermind dpkg -L broadcom-sta-dkms |grep "dkms.conf" /etc/modprobe.d/broadcom-sta-dkms.conf /usr/src/broadcom-sta-6.30.223.271/dkms.conf LOL :) I'll tweak the grep to make sure it finds only the latter :) G. Il martedì 28 luglio 2020, 20:22:44 CEST, Andreas Beckmann ha scritto: [resending after unarchiving] On 7/28/20 6:55 PM, Gianfranco Costamagna wrote: > Hello Andreas > > > Unfortunately this dkms patch, while worked for most of the Ubuntu packages, > failed to work for 3 of them > autopkgtest for broadcom-sta/6.30.223.271-14: amd64: Regression ♻ , arm64: > Ignored failure, armhf: Ignored failure, i386: Ignored failure, ppc64el: > Ignored failure, s390x: Ignored failure > autopkgtest for iptables-netflow/2.5-2: amd64: Regression ♻ , arm64: > Regression ♻ , armhf: Regression ♻ , ppc64el: Regression ♻ , s390x: > Regression ♻ > autopkgtest for r8168/8.048.03-1: amd64: Regression ♻ , arm64: Regression ♻ , > armhf: Regression ♻ , i386: Ignored failure, ppc64el: Regression ♻ , s390x: > Regression ♻ > Additional info: > > you can see e.g. > https://autopkgtest.ubuntu.com/packages/b/broadcom-sta/groovy/amd64 > https://autopkgtest.ubuntu.com/packages/i/iptables-netflow/groovy/amd64 > https://autopkgtest.ubuntu.com/packages/r/r8168/groovy/amd64 > > I really don't know why they fail, I can see the stuff is not getting built, > and then something fails because of a parameter mismatch. > > I uploaded 2.8.3 to sid some seconds ago, but I know it won't fix any of this > kind of issues. > > Can you please have a look? > > Also, dumping the failure log would be great in case of build failure... > > G. > I'll take a look ...
Bug#966417: vg: FTBFS in sid, with new elfutils
tags: patch Hello, I confirm the patch works correctly, the build finished in Ubuntu https://launchpad.net/ubuntu/+source/vg/1.25.0+ds-2ubuntu1/+build/19650765 G.
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
