Bug#971233: Please build r-cran-rstan on more powerful hardware for mipsel

[Andreas Tille]

Hi,

the build on mipsel[1] failed with


g++ -std=gnu++14 -I"/usr/share/R/include" -DNDEBUG -I"../inst/include" 
-I"../inst/include/boost_not_in_BH" -I"." -DBOOST_DISABLE_ASSERTS 
-DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION -DBOOST_NO_AUTO_PTR -D_REENTRANT 
-DSTAN_THREADS   -I'/usr/lib/R/site-library/Rcpp/include' 
-I'/usr/lib/R/site-library/RcppEigen/include' 
-I'/usr/lib/R/site-library/BH/include' 
-I'/usr/lib/R/site-library/StanHeaders/include' 
-I'/usr/lib/R/site-library/RcppParallel/include'-fpic  -g -O2 
-fdebug-prefix-map=/build/r-base-dGwTCJ/r-base-4.0.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c 
stan/lang/grammars/block_var_decls_grammar_inst.cpp -o 
stan/lang/grammars/block_var_decls_grammar_inst.o
virtual memory exhausted: Cannot allocate memory
make[1]: *** [/usr/lib/R/etc/Makeconf:176: 
stan/lang/grammars/block_var_decls_grammar_inst.o] Error 1


Is it possible to build this package on a more powerful machine?  If not
we should probably exclude mipsel from the set of target architectures.

Kind regards

Andreas.


[1] 
https://buildd.debian.org/status/fetch.php?pkg=r-cran-rstan=mipsel=2.21.2-2=1601481233=0

-- 
http://fam-tille.de

Bug#960769: swt4-gtk FTBFS on 32bit

[tony mancill]

It turns out there was already an RM bug filed:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969975 

I will merge the duplicate I created into it:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971730

Bug#960769: swt4-gtk FTBFS on 32bit

[tony mancill]

On Mon, Oct 05, 2020 at 06:30:51AM +0200, Sebastiaan Couwenberg wrote:
> On 10/5/20 6:04 AM, tony mancill wrote:
> > On Sun, Oct 04, 2020 at 04:34:17PM +0200, Sebastiaan Couwenberg wrote:
> >> Control: severity -1 serious
> >> Control: affects -1 src:openjfx
> >>
> >> This issue is preventing testing migration of swt4-gtk, it also blocks
> >> openjfx builds on the architectures where swt4-gtk FTBFS preventing the
> >> fix for #967185 from migrating to testing.
> >>
> >> Either fix the build or request removal of swt4-gtk and its rdeps from
> >> these architectures.
> > 
> > The binaries for the 32-bit architectures were removed in #962915 [1],
> > but only for version 4.13.0-1 in unstable. 
> 
> This was not sufficient to let it migrate to testing.
> 
> The britney output logs a bunch of packages on i386.
> 
> i386 & amd64 are the NOBREAKALL_ARCHES in britney.conf, see:
> 
>  https://release.debian.org/britney/britney.conf
> 
> > bullseye still contains the
> > binaries [2].  From the RM email:
> > 
> >> Packages are usually not removed from testing by hand. Testing tracks
> >> unstable and will automatically remove packages which were removed
> >> from unstable when removing them from testing causes no dependency
> >> problems. The release team can force a removal from testing if it is
> >> really needed, please contact them if this should be the case.
> > 
> > Is the problem here that we need to RM all of the rdeps on those
> > architectures from unstable as well? 
> 
> At least in the case of openjfx (and its non-arch:all rdeps).

I see.  It sounds like the RM should remove the set of transitive
(non-arch:all) rdeps.

> > If that's sufficient, I can put
> > together that RM request.
> > 
> > Also, shouldn't we explicitly enumerate the supported Architectures in
> > the next upload of swt4-gtk instead of specifying "Architecture: all" ?
> 
> You mean "Architecture: any" I presume? If so, you could do that, but
> maintaining the list of architectures over time is a PITA from my
> experience, I wouldn't recommend it unless swt4-gtk only sometimes fails
> to build on these architectures. If it's persistent removing the
> packages from those architectures should suffice. Once its rdeps are
> removed as well they will be in BD-Uninstallable state on those archs.
> But because of the RM the missing binaries won't block testing migration.

Oops - yes, I meant "Architecture: any" and thank you for the guidance
here.  It sounds like the arch-specific RM acts like a mask that will
prevent the auto builders on the RM'd arches from attempting to rebuild
subsequent source uploads.  (As I type that, I realize that I should
know that already.  But arch-specific RMs don't occur that often for the
Java Team packages.)

Thank you again,
tony

Bug#971728: malcontent-gui: Missing .policy file prevents service from working

[Diego Escalante Urrelo]

Package: malcontent-gui
Version: 0.9.0-1
Severity: grave
Tags: patch
Justification: renders package unusable
X-Debbugs-Cc: die...@gnome.org

Hi, it seems that there's a missing .policy file in the .install file
for `malcontent-gui`, specifically:
  `usr/share/polkit-1/actions/org.freedesktop.MalcontentControl.policy`

I opened a MR a few weeks ago for that:
  https://salsa.debian.org/freedesktop-team/malcontent/-/merge_requests/2

Since gnome-control-center now depends on malcontent, the broken
functionality (no ability to _use_ malcontent-gui) is now exposed to all
users.

You'll notice this issue when you open `malcontent-control`, which will
warn you that there's no data for users, and you should fix your
accountsservice. The message is somewhat confusing, because the reason
for the failure is that the .policy file is missing.

Thanks!

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages malcontent-gui depends on:
ii  libaccountsservice00.6.55-3
ii  libc6  2.31-3
ii  libcairo2  1.16.0-4
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-5
ii  libglib2.0-0   2.66.0-2
ii  libgtk-3-0 3.24.23-1
ii  libmalcontent-ui-0-0   0.9.0-1
ii  libpolkit-gobject-1-0  0.117-1
ii  malcontent 0.9.0-1

malcontent-gui recommends no packages.

malcontent-gui suggests no packages.

-- no debconf information

Processed: 4g8: diff for NMU version 1.0-3.3

[Debian Bug Tracking System]

Processing control commands:

> tags 956970 + patch
Bug #956970 [src:4g8] 4g8: ftbfs with GCC-10
Added tag(s) patch.
> tags 956970 + pending
Bug #956970 [src:4g8] 4g8: ftbfs with GCC-10
Added tag(s) pending.

-- 
956970: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956970
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#956970: 4g8: diff for NMU version 1.0-3.3

[mwhudson]

Control: tags 956970 + patch
Control: tags 956970 + pending


Dear maintainer,

I've prepared an NMU for 4g8 (versioned as 1.0-3.3) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u 4g8-1.0/debian/changelog 4g8-1.0/debian/changelog
--- 4g8-1.0/debian/changelog
+++ 4g8-1.0/debian/changelog
@@ -1,3 +1,11 @@
+4g8 (1.0-3.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with GCC 10 by ensuring global variables only have one
+definition. (Closes: #956970)
+
+ -- Michael Hudson-Doyle   Tue, 06 Oct 2020 13:51:30 +1300
+
 4g8 (1.0-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u 4g8-1.0/src/globals.h 4g8-1.0/src/globals.h
--- 4g8-1.0/src/globals.h
+++ 4g8-1.0/src/globals.h
@@ -128,20 +128,20 @@
 #define P_UINT640x
 
-char w_file[OPT_MAXLEN];
+extern char w_file[OPT_MAXLEN];
 
-pcap_t *pkt;
-libnet_t *pkt_d;
-u_int8_t *device;
-u_int8_t display;
-u_int8_t dump_pkt;
-u_int16_t payload_len;
-u_int16_t hdr_len;
-u_int16_t ip_hdrlen;
-u_int8_t *gw_ip;
-u_int8_t *gw_mac;
-u_int8_t *host_ip;
-u_int8_t *host_mac;
-u_int8_t outbound;
-u_int8_t poison_cache;
+extern pcap_t *pkt;
+extern libnet_t *pkt_d;
+extern u_int8_t *device;
+extern u_int8_t display;
+extern u_int8_t dump_pkt;
+extern u_int16_t payload_len;
+extern u_int16_t hdr_len;
+extern u_int16_t ip_hdrlen;
+extern u_int8_t *gw_ip;
+extern u_int8_t *gw_mac;
+extern u_int8_t *host_ip;
+extern u_int8_t *host_mac;
+extern u_int8_t outbound;
+extern u_int8_t poison_cache;
 
 #endif /* __GLOBALS_H */
only in patch2:
unchanged:
--- 4g8-1.0.orig/src/error.h
+++ 4g8-1.0/src/error.h
@@ -29,7 +29,7 @@
 #define SUCCESS1
 #define FAILURE-1
 
-char error_buf[ERRBUF_MAXLEN];
+extern char error_buf[ERRBUF_MAXLEN];
 
 void fatal_error(u_int8_t *,...);
 
only in patch2:
unchanged:
--- 4g8-1.0.orig/src/main.c
+++ 4g8-1.0/src/main.c
@@ -22,6 +22,25 @@
 
 #include "main.h"
 
+char w_file[OPT_MAXLEN];
+
+pcap_t *pkt;
+libnet_t *pkt_d;
+u_int8_t *device;
+u_int8_t display;
+u_int8_t dump_pkt;
+u_int16_t payload_len;
+u_int16_t hdr_len;
+u_int16_t ip_hdrlen;
+u_int8_t *gw_ip;
+u_int8_t *gw_mac;
+u_int8_t *host_ip;
+u_int8_t *host_mac;
+u_int8_t outbound;
+u_int8_t poison_cache;
+
+char error_buf[ERRBUF_MAXLEN];
+
 int
 main(int argc, char *argv[])
 {

Processed: xsd: diff for NMU version 4.0.0-8.1

[Debian Bug Tracking System]

Processing control commands:

> tags 957999 + patch
Bug #957999 [src:xsd] xsd: ftbfs with GCC-10
Added tag(s) patch.
> tags 957999 + pending
Bug #957999 [src:xsd] xsd: ftbfs with GCC-10
Added tag(s) pending.

-- 
957999: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957999
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#957999: xsd: diff for NMU version 4.0.0-8.1

[mwhudson]

Control: tags 957999 + patch
Control: tags 957999 + pending


Dear maintainer,

I've prepared an NMU for xsd (versioned as 4.0.0-8.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru xsd-4.0.0/debian/changelog xsd-4.0.0/debian/changelog
--- xsd-4.0.0/debian/changelog  2018-05-06 05:42:32.0 +1200
+++ xsd-4.0.0/debian/changelog  2020-10-06 14:03:20.0 +1300
@@ -1,3 +1,10 @@
+xsd (4.0.0-8.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from upstream to fix build with gcc 10. (Closes: #957999)
+
+ -- Michael Hudson-Doyle   Tue, 06 Oct 2020 14:03:20 +1300
+
 xsd (4.0.0-8) unstable; urgency=medium
 
   * Team upload.
diff -Nru xsd-4.0.0/debian/patches/0002-missing-include.patch 
xsd-4.0.0/debian/patches/0002-missing-include.patch
--- xsd-4.0.0/debian/patches/0002-missing-include.patch 1970-01-01 
12:00:00.0 +1200
+++ xsd-4.0.0/debian/patches/0002-missing-include.patch 2020-10-06 
09:38:15.0 +1300
@@ -0,0 +1,19 @@
+From 5029f8665190879285787a9dcdaf5f997cadd2e2 Mon Sep 17 00:00:00 2001
+From: Boris Kolpackov 
+Date: Fri, 23 Oct 2015 15:40:35 +0200
+Subject: Add missing #include
+
+---
+ xsd-frontend/semantic-graph/elements.cxx | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/libxsd-frontend/xsd-frontend/semantic-graph/elements.cxx
 b/libxsd-frontend/xsd-frontend/semantic-graph/elements.cxx
+@@ -3,6 +3,7 @@
+ // license   : GNU GPL v2 + exceptions; see accompanying LICENSE file
+ 
+ #include 
++#include 
+ 
+ #include 
+ 
diff -Nru xsd-4.0.0/debian/patches/series xsd-4.0.0/debian/patches/series
--- xsd-4.0.0/debian/patches/series 2018-05-06 05:42:32.0 +1200
+++ xsd-4.0.0/debian/patches/series 2020-10-06 09:37:19.0 +1300
@@ -3,3 +3,4 @@
 0700_hurd_PATH_MAX.patch
 0105-Fix_path_handling_bug.patch
 0110-xerces-c3.2.patch
+0002-missing-include.patch

Bug#958004: xtron: diff for NMU version 1.1a-14.1

[mwhudson]

Control: tags 958004 + patch
Control: tags 958004 + pending


Dear maintainer,

I've prepared an NMU for xtron (versioned as 1.1a-14.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u xtron-1.1a/debian/changelog xtron-1.1a/debian/changelog
--- xtron-1.1a/debian/changelog
+++ xtron-1.1a/debian/changelog
@@ -1,3 +1,11 @@
+xtron (1.1a-14.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from Reiner Herrmann to fix ftbfs with gcc 10.
+(Closes: #958004)
+
+ -- Michael Hudson-Doyle   Tue, 06 Oct 2020 13:59:40 +1300
+
 xtron (1.1a-14) unstable; urgency=low
 
   * Standards-Version: 3.8.0.
only in patch2:
unchanged:
--- xtron-1.1a.orig/xtron.c
+++ xtron-1.1a/xtron.c
@@ -21,6 +21,9 @@
 
 #include "xtron.h"
 
+struct Player p[2];
+struct Board b;
+
 void plr_setup(void)
 {
   int i;
only in patch2:
unchanged:
--- xtron-1.1a.orig/xtron.h
+++ xtron-1.1a/xtron.h
@@ -40,11 +40,15 @@
   int alive;
   enum directions plr_dir;
   enum play_types plr_type; 
-} p[2];
+};
+
+extern struct Player p[2];
 
 struct Board {
   short int contents[200][200];
-} b;
+};
+
+extern struct Board b;
  
 void plr_setup(void);
 int plr_checkmove(int p_num, int new_val, int axis_type, enum directions dir);

Processed: xtron: diff for NMU version 1.1a-14.1

[Debian Bug Tracking System]

Processing control commands:

> tags 958004 + patch
Bug #958004 [src:xtron] xtron: ftbfs with GCC-10
Ignoring request to alter tags of bug #958004 to the same tags previously set
> tags 958004 + pending
Bug #958004 [src:xtron] xtron: ftbfs with GCC-10
Added tag(s) pending.

-- 
958004: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958004
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: ziproxy: diff for NMU version 3.3.1-2.2

[Debian Bug Tracking System]

Processing control commands:

> tags 958012 + patch
Bug #958012 [src:ziproxy] ziproxy: ftbfs with GCC-10
Added tag(s) patch.
> tags 958012 + pending
Bug #958012 [src:ziproxy] ziproxy: ftbfs with GCC-10
Added tag(s) pending.

-- 
958012: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958012
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#958012: ziproxy: diff for NMU version 3.3.1-2.2

[mwhudson]

Control: tags 958012 + patch
Control: tags 958012 + pending


Dear maintainer,

I've prepared an NMU for ziproxy (versioned as 3.3.1-2.2) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru ziproxy-3.3.1/debian/changelog ziproxy-3.3.1/debian/changelog
--- ziproxy-3.3.1/debian/changelog  2016-06-27 22:06:07.0 +1200
+++ ziproxy-3.3.1/debian/changelog  2020-10-06 13:54:59.0 +1300
@@ -1,3 +1,10 @@
+ziproxy (3.3.1-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with gcc 10. (Closes: 958012)
+
+ -- Michael Hudson-Doyle   Tue, 06 Oct 2020 13:54:59 +1300
+
 ziproxy (3.3.1-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru ziproxy-3.3.1/debian/patches/04_gcc10.diff 
ziproxy-3.3.1/debian/patches/04_gcc10.diff
--- ziproxy-3.3.1/debian/patches/04_gcc10.diff  1970-01-01 12:00:00.0 
+1200
+++ ziproxy-3.3.1/debian/patches/04_gcc10.diff  2020-10-05 13:55:19.0 
+1300
@@ -0,0 +1,26 @@
+Description: fix multiple defintions which causes an error with gcc 10
+Author: Michael Hudson-Doyle 
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958012
+Last-Update: 2020-10-05
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/tosmarking.c
 b/src/tosmarking.c
+@@ -32,15 +32,11 @@
+ #include "urltables.h"
+ #include "cttables.h"
+ #include "log.h"
++#include "cfgfile.h"
+ 
+ /* private, local. those are not the same as the vars with the same name */
+ int tosmarking_enabled;
+ SOCKET sock_child_out;
+-int TOSFlagsDefault;
+-int TOSFlagsDiff;
+-const t_ut_urltable *tos_markasdiff_url;
+-const t_ct_cttable *tos_maskasdiff_ct;
+-ZP_DATASIZE_TYPE TOSMarkAsDiffSizeBT;
+ 
+ int current_tos;
+ ZP_DATASIZE_TYPE tos_bytecount;   /* counter used by TOSMarkAsDiffSizeBT 
*/
diff -Nru ziproxy-3.3.1/debian/patches/series 
ziproxy-3.3.1/debian/patches/series
--- ziproxy-3.3.1/debian/patches/series 2016-06-27 22:01:35.0 +1200
+++ ziproxy-3.3.1/debian/patches/series 2020-10-05 13:49:42.0 +1300
@@ -1,3 +1,4 @@
 01_ziproxyconf.diff
 02_small_spelling.diff
 03_giflib5.diff
+04_gcc10.diff

Bug#958011: yersinia: diff for NMU version 0.8.2-2.1

[mwhudson]

Control: tags 958011 + patch
Control: tags 958011 + pending


Dear maintainer,

I've prepared an NMU for yersinia (versioned as 0.8.2-2.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru yersinia-0.8.2/debian/changelog yersinia-0.8.2/debian/changelog
--- yersinia-0.8.2/debian/changelog 2017-09-18 07:00:46.0 +1200
+++ yersinia-0.8.2/debian/changelog 2020-10-06 12:42:32.0 +1300
@@ -1,3 +1,11 @@
+yersinia (0.8.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build failure with gcc-10 now that -fno-common is the default.
+(Closes: 958011) 
+
+ -- Michael Hudson-Doyle   Tue, 06 Oct 2020 12:42:32 +1300
+
 yersinia (0.8.2-2) unstable; urgency=medium
 
   * added fix from Frédéric Bonnard 
diff -Nru yersinia-0.8.2/debian/control yersinia-0.8.2/debian/control
--- yersinia-0.8.2/debian/control   2017-09-18 07:00:46.0 +1200
+++ yersinia-0.8.2/debian/control   2020-10-05 16:17:28.0 +1300
@@ -1,7 +1,8 @@
 Source: yersinia
 Section: admin
 Priority: optional
-Maintainer: Noël Köthe 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Noël Köthe 
 Build-Depends: debhelper (>= 9.0.0), dh-autoreconf, libncurses5-dev (>=5.4), 
libnet1-dev (>=1.1.2), libpcap0.8-dev, libgtk2.0-dev, lsb-release
 Standards-Version: 4.1.0
 Homepage: http://www.yersinia.net/
diff -Nru yersinia-0.8.2/debian/patches/gcc10.patch 
yersinia-0.8.2/debian/patches/gcc10.patch
--- yersinia-0.8.2/debian/patches/gcc10.patch   1970-01-01 12:00:00.0 
+1200
+++ yersinia-0.8.2/debian/patches/gcc10.patch   2020-10-05 16:26:28.0 
+1300
@@ -0,0 +1,133 @@
+--- a/src/gtk-gui.h
 b/src/gtk-gui.h
+@@ -47,7 +47,7 @@
+ #define MAX_PAD_HEIGHT 40 
+ #define MAX_PAD_WIDTH  70
+ 
+-u_int8_t pointer[MAX_PROTOCOLS];
++extern u_int8_t pointer[MAX_PROTOCOLS];
+ 
+ void gtk_gui(void *);
+ void gtk_gui_th_exit(struct term_node *);
+--- a/src/interfaces.h
 b/src/interfaces.h
+@@ -67,7 +67,7 @@
+ 
+ #define NO_TIMEOUT  0
+ 
+-list_t *interfaces;
++extern list_t *interfaces;
+ 
+ struct interface_data {
+int8_t   up;  /* is it active? */
+--- a/src/ncurses-interface.h
 b/src/ncurses-interface.h
+@@ -80,8 +80,8 @@
+ #define CAN_RESIZE 1
+ #endif
+ 
+-u_int8_t pointer[MAX_PROTOCOLS];
+-WINDOW *info_window;
++extern u_int8_t pointer[MAX_PROTOCOLS];
++extern WINDOW *info_window;
+ 
+ int8_t  ncurses_i_init(WINDOW *[], PANEL *[], struct term_node *);
+ voidncurses_i_add_node(void);
+--- a/src/protocols.h
 b/src/protocols.h
+@@ -207,7 +207,7 @@
+end_t end;
+ };
+ 
+-struct protocol_def protocols[MAX_PROTOCOLS];
++extern struct protocol_def protocols[MAX_PROTOCOLS];
+ 
+ void   protocol_init(void);
+ int8_t protocol_register(u_int8_t, const char *, const char *, const char *,
+--- a/src/gtk-gui.c
 b/src/gtk-gui.c
+@@ -70,6 +70,9 @@
+ #include "gtk-interface.h"
+ #include "gtk-support.h"
+ 
++u_int8_t pointer[MAX_PROTOCOLS];
++
++
+ void
+ gtk_gui (void *args)
+ {
+--- a/src/interfaces.c
 b/src/interfaces.c
+@@ -102,7 +102,7 @@
+ 
+ #include "interfaces.h"
+ 
+-
++list_t *interfaces;
+ 
+ 
+ 

+--- a/src/ncurses-interface.c
 b/src/ncurses-interface.c
+@@ -92,6 +92,8 @@
+ #include "ncurses-interface.h"
+ #include "ncurses-callbacks.h"
+ 
++WINDOW *info_window;
++
+ 
+ /*
+  * Ncurses init
+--- a/src/protocols.c
 b/src/protocols.c
+@@ -61,6 +61,9 @@
+ 
+ #include "protocols.h"
+ 
++struct protocol_def protocols[MAX_PROTOCOLS];
++
++
+ void
+ protocol_init(void)
+ {
+--- a/src/gtk-interface.c
 b/src/gtk-interface.c
+@@ -36,7 +36,11 @@
+ 
+ #include "gtk-interface.h"
+ 
+-#define GLADE_HOOKUP_OBJECT(component,widget,name) \
++GtkWidget *protocols_tree[MAX_PROTOCOLS + 1];
++GtkListStore *protocols_tree_model[MAX_PROTOCOLS + 1];
++
++
++#define GLADE_HOOKUP_OBJECT(component,widget,name)\
+   g_object_set_data_full (G_OBJECT (component), name, \
+ gtk_widget_ref (widget), (GDestroyNotify) gtk_widget_unref)
+ 
+--- a/src/gtk-interface.h
 b/src/gtk-interface.h
+@@ -26,8 +26,8 @@
+ #include "gtk-callbacks.h"
+ #include "gtk-support.h"
+ 
+-GtkWidget *protocols_tree[MAX_PROTOCOLS + 1];
+-GtkListStore *protocols_tree_model[MAX_PROTOCOLS + 1];
++extern GtkWidget *protocols_tree[MAX_PROTOCOLS + 1];
++extern GtkListStore *protocols_tree_model[MAX_PROTOCOLS + 1];
+ 
+ GtkWidget* gtk_i_create_Main (struct gtk_s_helper *);
+ GtkWidget* gtk_i_create_opendialog (struct gtk_s_helper *);
+--- a/src/ncurses-callbacks.h
 b/src/ncurses-callbacks.h
+@@ -77,8 +77,8 @@
+ #define CAN_RESIZE 1
+ #endif
+ 
+-u_int8_t pointer[MAX_PROTOCOLS];
+-WINDOW *info_window;
++extern u_int8_t pointer[MAX_PROTOCOLS];
++extern WINDOW *info_window;
+ 
+ voidncurses_c_refresh_mwindow(u_int8_t, WINDOW *, u_int8_t, struct 
term_node *);
+ voidncurses_c_refresh_bwindow(u_int8_t, WINDOW 

Processed: yersinia: diff for NMU version 0.8.2-2.1

[Debian Bug Tracking System]

Processing control commands:

> tags 958011 + patch
Bug #958011 [src:yersinia] yersinia: ftbfs with GCC-10
Added tag(s) patch.
> tags 958011 + pending
Bug #958011 [src:yersinia] yersinia: ftbfs with GCC-10
Added tag(s) pending.

-- 
958011: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958011
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#957824: marked as done (snoopy: ftbfs with GCC-10)

[Debian Bug Tracking System]

Your message dated Mon, 05 Oct 2020 23:03:25 +
with message-id 
and subject line Bug#957824: fixed in snoopy 2.4.8-1
has caused the Debian Bug report #957824,
regarding snoopy: ftbfs with GCC-10
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
957824: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957824
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:snoopy
Version: 2.4.6-6
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/snoopy_2.4.6-6_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

[...]
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/<>/etc'
Making all in lib
make[3]: Entering directory '/<>/lib'
Making all in inih
make[4]: Entering directory '/<>/lib/inih'
Making all in src
make[5]: Entering directory '/<>/lib/inih/src'
/bin/bash ../../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../../..   -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Werror -Wextra 
-Wno-unused-parameter -std=c99 -pedantic -I../../.. -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o ini.lo ini.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wall -Werror -Wextra -Wno-unused-parameter -std=c99 
-pedantic -I../../.. -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c ini.c  -fPIC -DPIC 
-o .libs/ini.o
/bin/bash ../../../libtool  --tag=CC   --mode=link gcc -Wall -Werror -Wextra 
-Wno-unused-parameter -std=c99 -pedantic -I../../.. -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security  -Wl,-z,relro -Wl,-z,now -o libinih.la  ini.lo  
-lpthread -ldl 
libtool: link: ar cr .libs/libinih.a .libs/ini.o 
libtool: link: ranlib .libs/libinih.a
libtool: link: ( cd ".libs" && rm -f "libinih.la" && ln -s "../libinih.la" 
"libinih.la" )
make[5]: Leaving directory '/<>/lib/inih/src'
make[5]: Entering directory '/<>/lib/inih'
make[5]: Nothing to be done for 'all-am'.
make[5]: Leaving directory '/<>/lib/inih'
make[4]: Leaving directory '/<>/lib/inih'
make[4]: Entering directory '/<>/lib'
make[4]: Nothing to be done for 'all-am'.
make[4]: Leaving directory '/<>/lib'
make[3]: Leaving directory '/<>/lib'
Making all in src
make[3]: Entering directory '/<>/src'
Making all in eventsource
make[4]: Entering directory '/<>/src/eventsource'
/bin/bash ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../..   -Wdate-time -D_FORTIFY_SOURCE=2 `echo -Wall -Werror -Wextra 
-Wno-unused-parameter -std=c99 -pedantic -I../.. -I../../src | sed -e 
's/-pedantic//'` -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o 
libsnoopy_eventsource_execve_wrapper_la-execve_wrapper.lo `test -f 
'execve_wrapper.c' || echo './'`execve_wrapper.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wall -Werror -Wextra -Wno-unused-parameter -std=c99 
-I../.. -I../../src -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c execve_wrapper.c  
-fPIC -DPIC -o .libs/libsnoopy_eventsource_execve_wrapper_la-execve_wrapper.o
/bin/bash ../../libtool  --tag=CC   --mode=link gcc `echo -Wall -Werror -Wextra 
-Wno-unused-parameter -std=c99 -pedantic -I../.. -I../../src | sed -e 
's/-pedantic//'` -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security  -Wl,-z,relro 
-Wl,-z,now -o 

Bug#908681: libsane1: pointless package rename

[Vincent Lefevre]

On 2020-10-05 15:35:23 +0200, Gianfranco Costamagna wrote:
> In this case, the symbols were private, and incorrectly exposed
> outside, so removing them is "safe" as long as nobody uses them.

I've looked at the repository, and in more details, they were
incorrectly exposed outside via the symbol table, but not via
a header file.[*] Thus I agree that there is no chance that
anyone uses them via the API.

[*] as the issue was fixed only by adding "static":

commit 62614a46609d85f03d9b73a826f8c94a3554e2b1
Author: Povilas Kanapickas 
Date:   2020-03-28 21:08:39 +0100

sanei_usb: Use internal linkage for private static variables

diff --git a/sanei/sanei_usb.c b/sanei/sanei_usb.c
index db0f452ae..291a48024 100644
--- a/sanei/sanei_usb.c
+++ b/sanei/sanei_usb.c
@@ -195,15 +195,15 @@ static sanei_usb_testing_mode testing_mode = 
sanei_usb_testing_mode_disabled;
 
 #if WITH_USB_RECORD_REPLAY
 static int testing_development_mode = 0;
-int testing_known_commands_input_failed = 0;
-unsigned testing_last_known_seq = 0;
-SANE_String testing_record_backend = NULL;
-xmlNode* testing_append_commands_node = NULL;
+static int testing_known_commands_input_failed = 0;
+static unsigned testing_last_known_seq = 0;
+static SANE_String testing_record_backend = NULL;
+static xmlNode* testing_append_commands_node = NULL;
 
 // XML file from which we read testing data
-SANE_String testing_xml_path = NULL;
-xmlDoc* testing_xml_doc = NULL;
-xmlNode* testing_xml_next_tx_node = NULL;
+static SANE_String testing_xml_path = NULL;
+static xmlDoc* testing_xml_doc = NULL;
+static xmlNode* testing_xml_next_tx_node = NULL;
 #endif // WITH_USB_RECORD_REPLAY
 
 #if defined(HAVE_LIBUSB_LEGACY) || defined(HAVE_LIBUSB)

> So, yes, the ABI changed, but the change was not reflected into
> a real issue for any Debian application, or any custom-built
> application.

Actually, though the symbol table changed, the ABI didn't.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#971234: marked as done (src:ruby-bson: fails to migrate to testing for too long: FTBFS on s390x)

[Debian Bug Tracking System]

Your message dated Mon, 05 Oct 2020 22:50:36 +
with message-id 
and subject line Bug#971234: fixed in ruby-bson 4.10.0-2
has caused the Debian Bug report #971234,
regarding src:ruby-bson: fails to migrate to testing for too long: FTBFS on 
s390x
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
971234: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971234
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: ruby-bson
Version: 4.7.0-2
Severity: serious
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:ruby-bson in
its current version in unstable has been trying to migrate for 61 days
[2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or its
(reverse-)dependencies. We expect maintainers to fix issues that hamper
the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have tagged this bug to only affect sid and bullseye, so it doesn't
affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=ruby-bson




signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Source: ruby-bson
Source-Version: 4.10.0-2
Done: =?utf-8?q?C=C3=A9dric_Boutillier?= 

We believe that the bug you reported is fixed in the latest version of
ruby-bson, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 971...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Cédric Boutillier  (supplier of updated ruby-bson package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 06 Oct 2020 00:24:42 +0200
Source: ruby-bson
Architecture: source
Version: 4.10.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Team 

Changed-By: Cédric Boutillier 
Closes: 971234
Changes:
 ruby-bson (4.10.0-2) unstable; urgency=medium
 .
   * Add upstream patch to fix segfault on s390x (Closes: #971234)
Checksums-Sha1:
 3d9d3a7b11dbb3ed0ffbbf0e632520d75f4f42d9 1793 ruby-bson_4.10.0-2.dsc
 540d75bf7b1e8fe80ae5142af70ea86ef046d364 158673 ruby-bson_4.10.0.orig.tar.gz
 a2c6dc1541c9b6f0a3a1e0f7683a92945c529696 4112 ruby-bson_4.10.0-2.debian.tar.xz
 ea23fd9eef0bdb845140ce457a2084da078467b6 8800 
ruby-bson_4.10.0-2_amd64.buildinfo
Checksums-Sha256:
 44611ddb2b32761ea330264ef13376196c55013960adcbcbfe1638a6361a8b84 1793 
ruby-bson_4.10.0-2.dsc
 b4defdc1c1c4564918a85cc8d310448440366b63d1bceb96154d1a9c3456dc78 158673 
ruby-bson_4.10.0.orig.tar.gz
 a849ca512cbff4062a16e856c3c8cdaf0c87c4bed4eefe40ff9b25e0a45ed77d 4112 
ruby-bson_4.10.0-2.debian.tar.xz
 4352b346febbc61a0447d471deec22da3bcefe76c72bd08d8811a9d261866330 8800 
ruby-bson_4.10.0-2_amd64.buildinfo
Files:
 4a109dd695c674ae167cebe9849596dd 1793 ruby optional ruby-bson_4.10.0-2.dsc
 fcaaa17eb05f3633a1f6991a9e96ddc1 158673 ruby optional 
ruby-bson_4.10.0.orig.tar.gz
 bd009d868633edcded31e5caad7326bc 4112 ruby optional 
ruby-bson_4.10.0-2.debian.tar.xz
 a4200d13336d11f16db42e3bd32d06a1 8800 ruby optional 
ruby-bson_4.10.0-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEnM1rMZ2/jkCrGr0aia+CtznNIXoFAl97n5sACgkQia+CtznN
IXq55gf9F+65IPLwjhpaRwgv/WGSSIJmJ0uFgswq3JFEa+8rQ5P/SxvWqMuIVYfd
UpJtLsff3SojV0UxB7WMEWTWsuiWGSEL8RmUgwmBzivMrs3WGbZZEFZYPLYVzX/3
P6UgWuC+I/AkxO2QChFiyaK6VQzPDc65BYsQYX7fhgHUjl1f4JLh64PmLuus1I/A

Processed: Bug#971234 marked as pending in ruby-bson

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #971234 [src:ruby-bson] src:ruby-bson: fails to migrate to testing for too 
long: FTBFS on s390x
Added tag(s) pending.

-- 
971234: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971234
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#971234: marked as pending in ruby-bson

[Cédric Boutillier]

Control: tag -1 pending

Hello,

Bug #971234 in ruby-bson reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-bson/-/commit/67106212bc90679d35c25e9e67e82fe57b907319


Add upstream patch to fix segfault on s390x (Closes: #971234)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/971234

Processed: tagging 958620

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 958620 + pending
Bug #958620 [src:sanlock] sanlock: Build-Depends on deprecated dh-systemd which 
is going away
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
958620: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958620
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#971666: mkdocs-bootstrap: broken with mkdocs 1.0

[Brian May]

Dmitry Shachnev  writes:

> I would be happy to update the packaging to the latest upstream
> release (1.1) and upload it, if the maintainer (Brian) wants so.

That is good with me.

Thanks.
-- 
Brian May 

Bug#948706: Polite ping

[Julian Gilbey]

On Mon, Oct 05, 2020 at 07:53:05AM +0100, Julian Gilbey wrote:
> On Mon, Oct 05, 2020 at 12:57:59AM +0100, Julian Gilbey wrote:
> > 4) The output of "greylist list" is now somewhat mangled: the "Data"
> > field shows something like:
> > [ ' 1 . 2 . 3 . 4 / 2 4 ' ,   ' i n f o @ e x a m p l e . c o m ' ,   ' j d 
> > g @ d e b i a n . o r g ' ]
> > rather than
> > 1.2.3.4/24  i...@example.com  j...@debian.org
> > I guess this should be easy to fix?
> 
> Oh, it turns out that this is not so straightforward: the command
> greylist add 1.2.3.4/24  i...@example.com  j...@debian.org
> yields the following line in /var/lib/greylistd/triplets, which will
> probably break things:
> 4921632547390726349 = 1.2.3.4/24 i...@example.com j...@debian.org
> 
> So it seems the triplets need turning into simple strings before they
> are stored in the triplets file / triplets hash, rather than being
> stored as Python literals with lots of excess spaces.

Hi Benedikt and Thorsten,

I've found the cause of this and made a pull request on your GitHub
repository.

If you're happy with it or a week or so passes and I don't hear from
you or the maintainer (Thorsten), I'll upload an NMU to the delayed
queue.

Thorsten: there are many more changes here than would usually be
permitted in an NMU.  But the package is currently completely broken
and won't get into testing.  This set of patches fixes the critical
issues and several other lintian warnings (as well as Benedikt's other
cleaning-up).  The big remaining lintian warning is that there is no
systemd service file.  This will take some effort to do, as systemd
will happily look after the socket creation, but then the Python code
will need adapting to accept the systemd socket rather than creating
one itself.  I've never done this and don't really have time right now
to do so.

Best wishes,

   Julian

Bug#971721: mime-support: missing dependency on perl

[Niko Tyni]

Package: mime-support
Version: 3.64
Severity: serious

On Mon, Oct 05, 2020 at 09:09:01AM +0200, Adam Borowski wrote:
> On Mon, Oct 05, 2020 at 01:52:19PM +1000, Jai Flack wrote:
> > Forgive me if this is an ignorant question but isn't mailcap missing
> > dependencies? If I build, then install all three and then ask apt about
> > mailcap's dependencies it gives:
> 
> [...]
> 
> > But the script it installs clearly depends on Perl:
> > 
> > #! /usr/bin/perl
> 
> > Is this an exception because Perl is part of the base system and assumed
> > to always be installed?
> 
> perl-base is essential.

Indeed.

However, the script in question (/usr/bin/run-mailcap) uses modules not
shipped in perl-base.

  use Encode qw(decode);
  use I18N::Langinfo qw(langinfo CODESET);

So yes, the mime-support package in sid is missing a dependency on perl.
This seems to have regressed in 3.55 with the fix for #682900.

Filing a bug about this, thanks for noticing.
-- 
Niko Tyni   nt...@debian.org

Processed: src:rust-sequoia-openpgp: fails to migrate to testing for too long: unsatisfied B-D

[Debian Bug Tracking System]

Processing control commands:

> close -1 0.18.0-1
Bug #971717 [src:rust-sequoia-openpgp] src:rust-sequoia-openpgp: fails to 
migrate to testing for too long: unsatisfied B-D
The source 'rust-sequoia-openpgp' and version '0.18.0-1' do not appear to match 
any binary packages
Marked as fixed in versions rust-sequoia-openpgp/0.18.0-1.
Bug #971717 [src:rust-sequoia-openpgp] src:rust-sequoia-openpgp: fails to 
migrate to testing for too long: unsatisfied B-D
Marked Bug as done
> block -1 by 971099
Bug #971717 {Done: Paul Gevers } [src:rust-sequoia-openpgp] 
src:rust-sequoia-openpgp: fails to migrate to testing for too long: unsatisfied 
B-D
971717 was not blocked by any bugs.
971717 was not blocking any bugs.
Added blocking bug(s) of 971717: 971099

-- 
971717: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971717
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#971717: src:rust-sequoia-openpgp: fails to migrate to testing for too long: unsatisfied B-D

[Paul Gevers]

Source: rust-sequoia-openpgp
Version: 0.17.0-5
Severity: serious
Control: close -1 0.18.0-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 971099

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:rust-sequoia-openpgp in its current version in unstable has been
trying to migrate for 60 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=rust-sequoia-openpgp




signature.asc
Description: OpenPGP digital signature

Bug#971715: src:rust-sequoia-sqv: fails to migrate to testing for too long: unsatisfied B-D

[Paul Gevers]

Source: rust-sequoia-sqv
Version: 0.17.0-1
Severity: serious
Control: close -1 0.18.0-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 971103

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:rust-sequoia-sqv in its current version in unstable has been trying
to migrate for 60 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=rust-sequoia-sqv




signature.asc
Description: OpenPGP digital signature

Processed: src:rust-sequoia-sqv: fails to migrate to testing for too long: unsatisfied B-D

[Debian Bug Tracking System]

Processing control commands:

> close -1 0.18.0-2
Bug #971715 [src:rust-sequoia-sqv] src:rust-sequoia-sqv: fails to migrate to 
testing for too long: unsatisfied B-D
The source 'rust-sequoia-sqv' and version '0.18.0-2' do not appear to match any 
binary packages
Marked as fixed in versions rust-sequoia-sqv/0.18.0-2.
Bug #971715 [src:rust-sequoia-sqv] src:rust-sequoia-sqv: fails to migrate to 
testing for too long: unsatisfied B-D
Marked Bug as done
> block -1 by 971103
Bug #971715 {Done: Paul Gevers } [src:rust-sequoia-sqv] 
src:rust-sequoia-sqv: fails to migrate to testing for too long: unsatisfied B-D
971715 was not blocked by any bugs.
971715 was not blocking any bugs.
Added blocking bug(s) of 971715: 971103

-- 
971715: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971715
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: src:rust-sequoia-sop: fails to migrate to testing for too long: unsatisfied B-D

[Debian Bug Tracking System]

Processing control commands:

> close -1 0.18.0-1
Bug #971716 [src:rust-sequoia-sop] src:rust-sequoia-sop: fails to migrate to 
testing for too long: unsatisfied B-D
The source 'rust-sequoia-sop' and version '0.18.0-1' do not appear to match any 
binary packages
Marked as fixed in versions rust-sequoia-sop/0.18.0-1.
Bug #971716 [src:rust-sequoia-sop] src:rust-sequoia-sop: fails to migrate to 
testing for too long: unsatisfied B-D
Marked Bug as done
> block -1 by 971105
Bug #971716 {Done: Paul Gevers } [src:rust-sequoia-sop] 
src:rust-sequoia-sop: fails to migrate to testing for too long: unsatisfied B-D
971716 was not blocked by any bugs.
971716 was not blocking any bugs.
Added blocking bug(s) of 971716: 971105

-- 
971716: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971716
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#971716: src:rust-sequoia-sop: fails to migrate to testing for too long: unsatisfied B-D

[Paul Gevers]

Source: rust-sequoia-sop
Version: 0.17.0-2
Severity: serious
Control: close -1 0.18.0-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 971105

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:rust-sequoia-sop in its current version in unstable has been trying
to migrate for 60 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=rust-sequoia-sop




signature.asc
Description: OpenPGP digital signature

Processed: src:libiscsi: fails to migrate to testing for too long: FTBFS

[Debian Bug Tracking System]

Processing control commands:

> close -1 1.19.0-2
Bug #971714 [src:libiscsi] src:libiscsi: fails to migrate to testing for too 
long: FTBFS
The source 'libiscsi' and version '1.19.0-2' do not appear to match any binary 
packages
Marked as fixed in versions libiscsi/1.19.0-2.
Bug #971714 [src:libiscsi] src:libiscsi: fails to migrate to testing for too 
long: FTBFS
Marked Bug as done
> block -1 by 969074
Bug #971714 {Done: Paul Gevers } [src:libiscsi] 
src:libiscsi: fails to migrate to testing for too long: FTBFS
971714 was not blocked by any bugs.
971714 was not blocking any bugs.
Added blocking bug(s) of 971714: 969074

-- 
971714: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971714
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#971714: src:libiscsi: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: libiscsi
Version: 1.19.0-1
Severity: serious
Control: close -1 1.19.0-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 969074

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:libiscsi in
its current version in unstable has been trying to migrate for 61 days
[2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=libiscsi




signature.asc
Description: OpenPGP digital signature

Bug#971666: mkdocs-bootstrap: broken with mkdocs 1.0

[Dmitry Shachnev]

Hi,

On Sun, Oct 04, 2020 at 11:56:56AM -0300, Antonio Terceiro wrote:
> Dear Maintainer,
>
> the current version of mkdocs-bootstrap in the archive is broken and
> does not work with the version of mkdocs that we have.

Yes, unfortunately it is probably also broken in stable. Let's fix it at least
for Bullseye.

> [...]
>
> I see that the git repository has a new upstream version that would
> work, but hasn't been uploaded for almost 2 years. I'm copying Dmitry,
> who did that work, in this bug report.

I would be happy to update the packaging to the latest upstream release (1.1)
and upload it, if the maintainer (Brian) wants so.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#971027: gcc-10: regression in 10.2.0-9 causes segmentation fault in vlc

[Sebastian Ramacher]

On 2020-10-05 11:51:59 +0200, Matthias Klose wrote:
> On 9/30/20 12:38 AM, Sebastian Ramacher wrote:
> > On 2020-09-30 00:01:52 +0200, Ahzo wrote:
> >>
> >> Sep 29, 2020, 07:14 by rguent...@suse.de:
> >>
> >>> I've filed > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236
> >>>
> >>> Someone needs to create a testcase or provide instructions how to
> >>> reproduce the bug.
> >>>
> >>
> >> Thanks for taking care of this issue upstream.
> >>
> >> Sep 29, 2020, 15:18 by d...@debian.org:
> >>
> >>> On 9/29/20 12:30 PM, Matthias Klose wrote:
> >>> upstream now has a reduced test case.
> >>>
> >>> 10.2.0-12 is uploaded, reverting that commit for now.
> >>>
> >> Thanks for the quick upload. This should prevent further fallout, until 
> >> upstream finds a better solution.
> > 
> > I've confirmed that vlc works again after rebuilding it with gcc-10
> > 10.2.0-12 and scheduled binNMUs of vlc which should hit the archive
> > soon.
> 
> please could also recheck with 10.2.0-14 from experimental, with the two
> reversions undone, and the new fix backported to the gcc-10 branch?

Local builds with -14 also work correctly. Thanks

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Processed: [bts-link] source package src:snoopy

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> #
> # bts-link upstream status pull for source package src:snoopy
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> # https://bts-link-team.pages.debian.net/bts-link/
> #
> user debian-bts-l...@lists.debian.org
Setting user to debian-bts-l...@lists.debian.org (was 
debian-bts-l...@lists.debian.org).
> # remote status report for #957824 (http://bugs.debian.org/957824)
> # Bug title: snoopy: ftbfs with GCC-10
> #  * https://github.com/a2o/snoopy/issues/157
> #  * remote status changed: open -> closed
> #  * closed upstream
> tags 957824 + fixed-upstream
Bug #957824 [src:snoopy] snoopy: ftbfs with GCC-10
Added tag(s) fixed-upstream.
> usertags 957824 - status-open
Usertags were: status-open.
Usertags are now: .
> usertags 957824 + status-closed
There were no usertags set.
Usertags are now: status-closed.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
957824: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957824
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: [bts-link] source package src:python-tornado

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> #
> # bts-link upstream status pull for source package src:python-tornado
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> # https://bts-link-team.pages.debian.net/bts-link/
> #
> user debian-bts-l...@lists.debian.org
Setting user to debian-bts-l...@lists.debian.org (was 
debian-bts-l...@lists.debian.org).
> # remote status report for #971108 (http://bugs.debian.org/971108)
> # Bug title: python-tornado: FTBFS: dh_auto_test: error: pybuild --test -i 
> python{version} -p 3.8 returned exit code 13
> #  * https://github.com/tornadoweb/tornado/issues/2852
> #  * remote status changed: (?) -> closed
> #  * closed upstream
> tags 971108 + fixed-upstream
Bug #971108 [src:python-tornado] python-tornado: FTBFS: dh_auto_test: error: 
pybuild --test -i python{version} -p 3.8 returned exit code 13
Added tag(s) fixed-upstream.
> usertags 971108 + status-closed
There were no usertags set.
Usertags are now: status-closed.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
971108: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971108
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: [bts-link] source package src:otb

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> #
> # bts-link upstream status pull for source package src:otb
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> # https://bts-link-team.pages.debian.net/bts-link/
> #
> user debian-bts-l...@lists.debian.org
Setting user to debian-bts-l...@lists.debian.org (was 
debian-bts-l...@lists.debian.org).
> # remote status report for #957653 (http://bugs.debian.org/957653)
> # Bug title: otb: ftbfs with GCC-10
> #  * https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2045
> #  * remote status changed: opened -> closed
> #  * closed upstream
> tags 957653 + fixed-upstream
Bug #957653 [src:otb] otb: ftbfs with GCC-10
Added tag(s) fixed-upstream.
> usertags 957653 - status-opened
Usertags were: status-opened.
Usertags are now: .
> usertags 957653 + status-closed
There were no usertags set.
Usertags are now: status-closed.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
957653: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957653
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#933948: systemd forces stop and garbage in coureir again

[PICCORO McKAY Lenz]

i checked this in devuan (it lacks of systemd) and does work..but not on debian

root@venenux:~# service courier-imap-ssl status
● courier-imap-ssl.service - LSB: Courier IMAP server (TLS)
   Loaded: loaded (/etc/init.d/courier-imap-ssl; generated)
   Active: active (exited) since Mon 2020-10-05 15:28:47 VET; 34s ago

it said "active" but (exited) seems, premature received success of
lauch .. i guess cos there's no such good control of pid file if
process broke:

based on https://sourceforge.net/p/courier/mailman/message/35056163/

seems systemd cannot handle that! maybe that's why by the sysv script
does work! again systemd problem related


Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Processed: block 963628 with 887167

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 963628 with 887167
Bug #963628 [node-jest] Node-jest fails with: Error: Cannot find module 
'import-local'
963628 was not blocked by any bugs.
963628 was not blocking any bugs.
Added blocking bug(s) of 963628: 887167
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
963628: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963628
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#920545: marked as done (python-intervaltree breaks python-intervaltree-bio autopkgtest)

[Debian Bug Tracking System]

Your message dated Mon, 05 Oct 2020 15:21:05 +
with message-id 
and subject line Bug#920545: fixed in python-intervaltree-bio 1.0.1-4
has caused the Debian Bug report #920545,
regarding python-intervaltree breaks python-intervaltree-bio autopkgtest
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
920545: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920545
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: python-intervaltree, python-intervaltree-bio
Control: found -1 python-intervaltree/3.0.2-1
Control: found -1 python-intervaltree-bio/1.0.1-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: important
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of python-intervaltree the autopkgtest of
python-intervaltree-bio fails in testing when that autopkgtest is run
with the binary packages of python-intervaltree from unstable. It passes
when run with only packages from testing. In tabular form:
passfail
python-intervaltree from testing3.0.2-1
python-intervaltree-bio from testing1.0.1-2
all others  from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of
python-intervaltree to testing [1]. Due to the nature of this issue, I
filed this bug report against both packages. Can you please investigate
the situation and reassign the bug to the right package? If needed,
please change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-intervaltree

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-intervaltree-bio/1785537/log.gz

=== FAILURES
===
 test_knownGene


def test_knownGene():
# To speed up testing, we'll download the file and reuse the
downloaded copy
knownGene_url =
'http://hgdownload.cse.ucsc.edu/goldenpath/hg19/database/knownGene.txt.gz'
# Mirror. Slightly faster and more stable, I believe:
knownGene_url =
'http://kt.era.ee/distribute/pyintervaltree/knownGene.txt.gz'

# To speed up testing, we'll download the file and reuse the
downloaded copy
knownGene_file, headers = urlretrieve(knownGene_url)

knownGene_localurl = 'file:///%s' % os.path.abspath(knownGene_file)
knownGene =
GenomeIntervalTree.from_table(url=knownGene_localurl, decompress=True) #
Py3 downloads .gz files to local files with names not ending with .gz
assert len(knownGene) == 82960
>   result = knownGene[b'chr1'].search(10, 138529)
E   AttributeError: 'IntervalTree' object has no attribute 'search'

.pc/offline-test-data.patch/tests/genomeintervaltree_test.py:28:
AttributeError
 
test_knownGene[file:///tmp/autopkgtest-lxc.z3ra1nek/downtmp/build.Szw/src/debian/data/]

base_url =
'file:///tmp/autopkgtest-lxc.z3ra1nek/downtmp/build.Szw/src/debian/data/'

def test_knownGene(base_url):
# To speed up testing, we'll download the file and reuse the
downloaded copy
knownGene_url = base_url + 'knownGene.txt.gz'

# To speed up testing, we'll download the file and reuse the
downloaded copy
knownGene_file, headers = urlretrieve(knownGene_url)

knownGene_localurl = 'file:///%s' % os.path.abspath(knownGene_file)
knownGene =
GenomeIntervalTree.from_table(url=knownGene_localurl, decompress=True) #
Py3 downloads .gz files to local files with names not ending with .gz
assert len(knownGene) == 82960
>   result = knownGene[b'chr1'].search(10, 138529)
E   AttributeError: 'IntervalTree' object has no attribute 'search'



signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Source: python-intervaltree-bio
Source-Version: 1.0.1-4
Done: Nilesh Patra 

We believe that the bug you reported is fixed in the latest version of
python-intervaltree-bio, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 920...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.

Bug#969372: uwsgi-emperor: SysV init script does nothing

[Vlastimil Zima]

Package: uwsgi-emperor
Version: 2.0.19.1-3
Followup-For: Bug #969372

Dear Maintainer,

it seems this bug still exists in 2.0.19.1-3.

I've upgraded from 2.0.19.1-1 this morning and since then the
uwsgi-emperor can't be started using systemd or
/etc/init.d/uwsgi-emperor script. I tried to purge and install the
uwsgi-emperor package.

The /etc/init.d/uwsgi-emperor still seems to be broken.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (90, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages uwsgi-emperor depends on:
ii  uwsgi-core  2.0.19.1-3

uwsgi-emperor recommends no packages.

uwsgi-emperor suggests no packages.

-- no debconf information

Bug#971703: golang-github-knadh-koanf: not buildable from source in Debian

[Steve Langasek]

Source: golang-github-knadh-koanf
Version: 0.10.0-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy

Dear maintainers,

The golang-github-knadh-koanf package cannot be built in Debian due to
missing build-dependency, golang-github-rhnvrm-simples3-dev:

$ sudo apt build-dep golang-github-knadh-koanf
[sudo] password for vorlon: 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:golang-github-knadh-koanf : Depends: 
golang-github-rhnvrm-simples3-dev but it is not installable
E: Unable to correct problems, you have held broken packages.
$

This package is not in the Debian NEW queue, and does not have an open ITP
bug.

Please take care of the missing build-dependency.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#971668: marked as done (libsane: broke ABI)

[Debian Bug Tracking System]

Your message dated Mon, 5 Oct 2020 15:46:16 +0200
with message-id <158b483f-0235-ac8b-6a0c-4f9878e3c...@debian.org>
and subject line Re: Bug#971668: libsane: broke ABI
has caused the Debian Bug report #971668,
regarding libsane: broke ABI
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
971668: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971668
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libsane
Version: 1.0.31-2
Severity: grave

From 1.0.31-1~experimental1:

   * debian/libsane1.symbols:
- Remove 7 not longer available symbols.

Hence provinding libsane that depends on libsane1 with a different ABI
is wrong.

Cheers

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (650, 'unstable-debug'), (650, 'unstable'), (601, 'testing'), 
(600, 'experimental-debug'), (600, 'buildd-unstable'), (600, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libsane depends on:
ii  libsane1  1.0.31-2

libsane recommends no packages.

libsane suggests no packages.

-- no debconf information

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Hello, I proposed to close this one, and use #971687

but the real bug is back to be just #908681
as explained in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908681#197

G.

On Mon, 5 Oct 2020 03:48:26 +0200 Vincent Lefevre  wrote:
> Control: clone -1 -2
> Control: reassign -2 libsane1 1.0.31-2
> Control: retitle -2 libsane1: broke ABI
> 
> On 2020-10-04 18:03:30 +0200, Sebastian Ramacher wrote:
> > Package: libsane
> > Version: 1.0.31-2
> > Severity: grave
> > 
> > From 1.0.31-1~experimental1:
> > 
> >* debian/libsane1.symbols:
> > - Remove 7 not longer available symbols.
> > 
> > Hence provinding libsane that depends on libsane1 with a different ABI
> > is wrong.
> 
> Not just libsane is wrong, but libsane1 (which contains the library
> itself) too (at least for programs compiled by users).
> 
> -- 
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> 
> --- End Message ---

Processed: Re: Bug#970589: tracker-extract: Crashes due to statx SIGABRT causes disk full ( need update to 2.3.5 )

[Debian Bug Tracking System]

Processing control commands:

> severity -1 serious
Bug #970589 [tracker-extract] tracker-extract: Crashes due to statx SIGABRT 
causes disk full ( need update to 2.3.5 )
Severity set to 'serious' from 'normal'
> tags -1 + fixed-upstream patch bullseye sid
Bug #970589 [tracker-extract] tracker-extract: Crashes due to statx SIGABRT 
causes disk full ( need update to 2.3.5 )
Added tag(s) patch, bullseye, fixed-upstream, and sid.

-- 
970589: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970589
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#908681: libsane1: pointless package rename

[Gianfranco Costamagna]

Hello Joerg,

> We are not back.

to be honest, yes we are :)

> 
> Between 1.0.30 and 1.0.31 are the following 7 symbols are not longer 
> available:
> 
> #MISSING: 1.0.31# testing_append_commands_node@Base 1.0.29
> #MISSING: 1.0.31# testing_known_commands_input_failed@Base 1.0.29
> #MISSING: 1.0.31# testing_last_known_seq@Base 1.0.29
> #MISSING: 1.0.31# testing_record_backend@Base 1.0.29
> #MISSING: 1.0.31# testing_xml_doc@Base 1.0.29
> #MISSING: 1.0.31# testing_xml_next_tx_node@Base 1.0.29
> #MISSING: 1.0.31# testing_xml_path@Base 1.0.29
> 
> This ABI changes are not backward-compatible. And so the change are required. 
> 

So, to explain:

If you think they are not backward-compatible, you should rename the package, 
but not provide the old SONAME
as transitional package, otherwise you are doing a mistake

In this case, the symbols were private, and incorrectly exposed outside, so 
removing them is "safe"
as long as nobody uses them.

When I sponsored the package for you, even if I forgot to write that on the RFS 
bug, I had a discussion about this
with some other DDs, and we agreeded that this wasn't worth a SONAME change, 
because the end user applications
were still ABI-safe.

So, this is why I asked you to restore the old package name, and make it 
transitional, to avoid people being forced
to upgrade to a new library SONAME without a real SONAME change.

This way, we made almost "everybody" happy, or at least improved the status quo 
for some bits.

(the real world fix was to ignore lintian, or to not start with a wrong soname, 
but this history now)

So, yes, the ABI changed, but the change was not reflected into a real issue 
for any Debian application, or any custom-built application.

I honestly think we should just move forward, and change the soname again if a 
the library changes in the future.

G.

Bug#920545: [RFS] python-intervaltree-bio

[Nilesh Patra]

Hi,
I've attempted to fix: #920545 which is about failing autopkgtests for
python-intervaltree-bio. It seems to pass on my chroot and I've pushed the
corresponding changes to the team repo here[1].
It'd be great if someone could try testing my changes once - and either
sponsor or grant me access to do so.

[1]: https://salsa.debian.org/med-team/python-intervaltree-bio

Kind regards
Nilesh

Processed: Re: Bug#971668: libsane: broke ABI

[Debian Bug Tracking System]

Processing control commands:

> severity -1 important
Bug #971687 [libsane1] libsane1: broke ABI
Severity set to 'important' from 'grave'
> reassign -1 src:sane-backends
Bug #971687 [libsane1] libsane1: broke ABI
Bug reassigned from package 'libsane1' to 'src:sane-backends'.
No longer marked as found in versions sane-backends/1.0.31-2.
Ignoring request to alter fixed versions of bug #971687 to the same values 
previously set
> retitle -1 sane-backends: dropped unused symbols without changing SONAME
Bug #971687 [src:sane-backends] libsane1: broke ABI
Changed Bug title to 'sane-backends: dropped unused symbols without changing 
SONAME' from 'libsane1: broke ABI'.

-- 
971687: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971687
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#971687: Bug#971668: libsane: broke ABI

[Gianfranco Costamagna]

control: severity -1 important
control: reassign -1 src:sane-backends
control: retitle -1 sane-backends: dropped unused symbols without changing 
SONAME 


Hello Vincent and Sebastian

On Mon, 5 Oct 2020 03:48:26 +0200 Vincent Lefevre  wrote:
> Control: clone -1 -2
> Control: reassign -2 libsane1 1.0.31-2
> Control: retitle -2 libsane1: broke ABI
> 
> On 2020-10-04 18:03:30 +0200, Sebastian Ramacher wrote:
> > Package: libsane
> > Version: 1.0.31-2
> > Severity: grave
> > 
> > From 1.0.31-1~experimental1:
> > 
> >* debian/libsane1.symbols:
> > - Remove 7 not longer available symbols.
> > 
> > Hence provinding libsane that depends on libsane1 with a different ABI
> > is wrong.
> 
> Not just libsane is wrong, but libsane1 (which contains the library
> itself) too (at least for programs compiled by users).
> 

Seriously?

this is the list of "dropped symbols"

- testing_append_commands_node@Base 1.0.29
- testing_known_commands_input_failed@Base 1.0.29
- testing_last_known_seq@Base 1.0.29
- testing_record_backend@Base 1.0.29
- testing_xml_doc@Base 1.0.29
- testing_xml_next_tx_node@Base 1.0.29
- testing_xml_path@Base 1.0.29


Please find a single reference of something in the archive, or outside the 
archive, that ever used
part of such (not meant to be exported) API.

The *bug* was to export them in the previous version, not to remove them, 
because meant to be internal symbols.

We had other references in the archive history, where symbols incorrectly 
exposed were dropped without
the need to change the ABI.

We discussed many times already, few people (including I guess the sponsor for 
that particular upload), and at least
3 other DDs agreeded that there was no need to change the SONAME just because 
of something that was not really
used anywhere in the world, included self-compiled stuff.

All the RFS bugs for sane-backends are public, you can find lots of discussion 
about the topic, and help
in better developing the package.

I think this is a non-issue, I would like to have some real bugs before talking 
about the Sex Of Angels... [1]

I also think its better have one single bug, instead of having two of them, for 
the very same source package.


(sorry for the Italian reference :) )
[1] https://www.englishforums.com/English/SexOfAngels/kxpgm/post.htm

just my .02$

Gianfranco

> -- 
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> 
> 

Bug#971678: ghostscript: FTBFS: ERROR: cidfmap not virtually empty as expected

[Simon McVittie]

Control: tags -1 + patch

On Mon, 05 Oct 2020 at 12:23:19 +0100, Simon McVittie wrote:
> > > | grep: 
> > > debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap: 
> > > No such file or directory
> > > | rm: cannot remove 
> > > 'debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap':
> > >  No such file or directory
> > 
> > I think this is the real problem. Testing a patch now.
> 
> See attached.
> 
> However, when testing that, I get a different (unrelated?) FTBFS when
> *only* building the Architecture: all package (i.e. with -A)

I retried the build and it succeeded, so I think that might be an unrelated
issue - perhaps a race condition in the presence of parallel builds?

DDs can give-back failed builds now, so an intermittent build failure,
while unwelcome, is not necessarily the showstopper that it used to be.

smcv

Processed: Re: Bug#971678: ghostscript: FTBFS: ERROR: cidfmap not virtually empty as expected

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + patch
Bug #971678 [src:ghostscript] ghostscript: FTBFS when not building Arch:all: 
debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap: No 
such file or directory
Added tag(s) patch.

-- 
971678: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971678
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: luajit: lightuserdata problem with > 47 bit address space on arm64

[Debian Bug Tracking System]

Processing control commands:

> tags -1 fixed-upstream
Bug #908137 [src:luajit] luajit: lightuserdata problem with > 47 bit address 
space on arm64
Added tag(s) fixed-upstream.

-- 
908137: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908137
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#908137: luajit: lightuserdata problem with > 47 bit address space on arm64

[Santiago Ruano Rincón]

Control: tags -1 fixed-upstream

On Thu, 06 Sep 2018 16:54:30 +0300 Adrian Bunk  wrote:
> Source: luajit
> Version: 2.0.4+dfsg-1
> Severity: serious
> Forwarded: https://github.com/LuaJIT/LuaJIT/pull/230#issuecomment-260205661
> 
> This is an RFC regarding what to do for avoiding runtime
> problems on arm64 like e.g. #907729.
> 
> The big hammer would be to drop luajit on arm64,
> reverse dependencies are already able to cope
> with luajit not available on s390x.
> 
> 

From the latest comment by upstream on the same PR
https://github.com/LuaJIT/LuaJIT/pull/230#issuecomment-701054121
it seems this has been fixed now. This is the relevant commit:
https://github.com/LuaJIT/LuaJIT/commit/e9af1abec542e6f9851ff2368e7f196b6382a44c


signature.asc
Description: PGP signature

Bug#971678: ghostscript: FTBFS: ERROR: cidfmap not virtually empty as expected

[Simon McVittie]

On Mon, 05 Oct 2020 at 10:56:17 +0100, Simon McVittie wrote:
> Control: retitle 971678 ghostscript: FTBFS when not building Arch:all: 
> debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap: No 
> such file or directory
> 
> On Sun, 04 Oct 2020 at 22:55:24 +0200, Sebastian Ramacher wrote:
> > ghostscript currently FTBFS on the buildds:
> > | grep: 
> > debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap: No 
> > such file or directory
> > | rm: cannot remove 
> > 'debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap': 
> > No such file or directory
> 
> I think this is the real problem. Testing a patch now.

See attached.

However, when testing that, I get a different (unrelated?) FTBFS when
*only* building the Architecture: all package (i.e. with -A):

8<
make -f Makefile DISPLAY_DEV=./soobj/display.dev BUILDDIRPREFIX=so GENOPT='' 
LDFLAGS='-Wl,-z,relro  '\
 CFLAGS='-fPIC   -O2 -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2  -Wall 
-Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes 
-Wwrite-strings -fno-strict-aliasing -Werror=declaration-after-statement 
-fno-builtin -fno-common -Werror=return-type -DHAVE_STDINT_H=1 
-DHAVE_DIRENT_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_LIBDL=1 -DGX_COLOR_INDEX_TYPE="unsigned long long" 
-D__USE_UNIX98=1  -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -DHAVE_RESTRICT=1 
-DUSE_LIBPAPER -I/usr/include/x86_64-linux-gnu  -fno-strict-aliasing 
-DHAVE_POPEN_PROTO=1 -DGS_DEVS_SHARED 
-DGS_DEVS_SHARED_DIR=\"/usr/lib/x86_64-linux-gnu/ghostscript/9.53.3\" ' 
prefix=/usr\
 ./sobin/gsc ./sobin/gsx -so-loader -so-loader -so-loader
make[4]: Entering directory '/<>'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/Scrt1.o: in function 
`_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
make[4]: *** [base/unix-dll.mak:174: sobin/gsc] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: Leaving directory '/<>'
make[3]: *** [base/unix-dll.mak:294: so-subtarget] Error 2
make[3]: Leaving directory '/<>'
make[2]: *** [base/unix-dll.mak:243: so] Error 2
make[2]: Leaving directory '/<>'
dh_auto_build: error: make -j2 so SHARE_JPEG=1 SHARE_LIBPNG=1 SHARE_LIBTIFF=1 
SHARE_ZLIB=1 SHARE_JBIG2=1 SHARE_IJS=1 SHARE_EXPAT=1 WHICH_CMS=lcms2 
SHARE_LCMS=1 LCMS2DIR=/usr SHARE_JPX=1 SHARE_FT=1 SHARE_LCUPS=1 SHARE_LCUPSI=1 
returned exit code 2
make[1]: *** [debian/rules:78: override_dh_auto_build] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:165: binary-indep] Error 2
8<

So this presumably can't be a complete solution. I don't know why my patch
would make this happen; perhaps it's coincidence.

Again, I'd recommend testing the -A and -B build modes before uploading.

smcv
>From 199e129841d1da4a6a7a41cc46fcc50bd8a96c79 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 5 Oct 2020 10:57:03 +0100
Subject: [PATCH] Don't check/remove cidfmap when not building libgs9-common

This fixes FTBFS when libgs9-common is not built, in particular on the
official Debian buildd for each architecture.

Closes: #971678
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index f02e98dd..e33927c5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,6 +15,8 @@ pkg-lib = $(libname)$(GS_VERSION_MAJOR)
 pkg-dev = $(libname)-dev
 pkg-data = $(libname)$(GS_VERSION_MAJOR)-common
 
+binaries := $(shell dh_listpackages)
+
 # use upstream bootstrapping script
 override_dh_autoreconf:
 	dh_autoreconf ./autogen.sh
@@ -132,6 +134,7 @@ override_dh_install:
 
 	dh_link --package=$(pkg-data) -- $(DEB_DH_LINK_$(pkg-data))
 	dh_link --no-package=$(pkg-data)
+ifneq ($(filter $(pkg-data),$(binaries)),)
 	file='debian/$(pkg-data)/usr/share/ghostscript/$(GS_DOT_VERSION)/Resource/Init/cidfmap'; \
 	  ! egrep -v '^(%([^%].*)?)?$$' "$$file" && rm "$$file" || ( \
 		echo; \
@@ -146,6 +149,7 @@ override_dh_install:
 		usr/share/ghostscript/$(GS_DOT_VERSION)/Resource/Font
 	rename 's/\.t1$$//' \
 		debian/$(pkg-data)/usr/share/ghostscript/$(GS_DOT_VERSION)/Resource/Font/*
+endif
 
 # check that tracked issues are solved
 override_dh_auto_test:
-- 
2.28.0

Processed: Re: Bug#971678: ghostscript: FTBFS: ERROR: cidfmap not virtually empty as expected

[Debian Bug Tracking System]

Processing control commands:

> retitle 971678 ghostscript: FTBFS when not building Arch:all: 
> debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap: No 
> such file or directory
Bug #971678 [src:ghostscript] ghostscript: FTBFS: ERROR: cidfmap not virtually 
empty as expected
Changed Bug title to 'ghostscript: FTBFS when not building Arch:all: 
debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap: No 
such file or directory' from 'ghostscript: FTBFS: ERROR: cidfmap not virtually 
empty as expected'.

-- 
971678: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971678
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#971678: ghostscript: FTBFS: ERROR: cidfmap not virtually empty as expected

[Simon McVittie]

Control: retitle 971678 ghostscript: FTBFS when not building Arch:all: 
debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap: No 
such file or directory

On Sun, 04 Oct 2020 at 22:55:24 +0200, Sebastian Ramacher wrote:
> ghostscript currently FTBFS on the buildds:
> | grep: 
> debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap: No 
> such file or directory
> | rm: cannot remove 
> 'debian/libgs9-common/usr/share/ghostscript/9.53.3/Resource/Init/cidfmap': No 
> such file or directory

I think this is the real problem. Testing a patch now.

When doing build-system surgery like commit d7ed869d, please remember to
test the build with separate build passes for Architecture: all and
Architecture: any packages (dpkg-buildpackage -A and -B, respectively),
not just a combined build, because the separate build passes are what
will happen on the buildds.

smcv

Bug#971027: gcc-10: regression in 10.2.0-9 causes segmentation fault in vlc

[Matthias Klose]

On 9/30/20 12:38 AM, Sebastian Ramacher wrote:
> On 2020-09-30 00:01:52 +0200, Ahzo wrote:
>>
>> Sep 29, 2020, 07:14 by rguent...@suse.de:
>>
>>> I've filed > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236
>>>
>>> Someone needs to create a testcase or provide instructions how to
>>> reproduce the bug.
>>>
>>
>> Thanks for taking care of this issue upstream.
>>
>> Sep 29, 2020, 15:18 by d...@debian.org:
>>
>>> On 9/29/20 12:30 PM, Matthias Klose wrote:
>>> upstream now has a reduced test case.
>>>
>>> 10.2.0-12 is uploaded, reverting that commit for now.
>>>
>> Thanks for the quick upload. This should prevent further fallout, until 
>> upstream finds a better solution.
> 
> I've confirmed that vlc works again after rebuilding it with gcc-10
> 10.2.0-12 and scheduled binNMUs of vlc which should hit the archive
> soon.

please could also recheck with 10.2.0-14 from experimental, with the two
reversions undone, and the new fix backported to the gcc-10 branch?

Matthias

Bug#957450: marked as done (libmygpo-qt: ftbfs with GCC-10)

[Debian Bug Tracking System]

Your message dated Mon, 05 Oct 2020 08:22:28 +
with message-id 
and subject line Bug#957450: fixed in libmygpo-qt 1.1.0-4
has caused the Debian Bug report #957450,
regarding libmygpo-qt: ftbfs with GCC-10
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
957450: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957450
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:libmygpo-qt
Version: 1.1.0-3
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/libmygpo-qt_1.1.0-3_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

[...]
make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
   dh_install -O--parallel
   dh_installdocs -O--parallel
   dh_installchangelogs -O--parallel
   dh_installexamples -O--parallel
   dh_installinit -O--parallel
   dh_perl -O--parallel
   dh_link -O--parallel
   dh_strip_nondeterminism -O--parallel
   dh_compress -O--parallel
   dh_fixperms -O--parallel
   dh_missing -O--parallel
   dh_strip -O--parallel
   dh_makeshlibs -O--parallel
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libmygpo-qt5-1/DEBIAN/symbols doesn't match 
completely debian/libmygpo-qt5-1.symbols
--- debian/libmygpo-qt5-1.symbols (libmygpo-qt5-1_1.1.0-3_amd64)
+++ dpkg-gensymbolsLKrZU8   2020-02-26 12:46:52.782423768 +
@@ -7,11 +7,13 @@
  _ZN10QByteArrayC2Ev@Base 1.0.9
  _ZN10QByteArrayD1Ev@Base 1.0.9
  _ZN10QByteArrayD2Ev@Base 1.0.9
- _ZN10QByteArrayaSEOS_@Base 1.0.9
+#MISSING: 1.1.0-3# _ZN10QByteArrayaSEOS_@Base 1.0.9
  _ZN10QByteArraypLERKS_@Base 1.0.9
  
(optional=templinst)_ZN12QMapNodeBase25callDestructorIfNecessaryI7QStringEENSt9enable_ifIXsr9QTypeInfoIT_E9isComplexEvE4typeERS4_@Base
 1.0.9
  
(optional=templinst)_ZN12QMapNodeBase25callDestructorIfNecessaryI8QVariantEENSt9enable_ifIXsr9QTypeInfoIT_E9isComplexEvE4typeERS4_@Base
 1.0.9
- _ZN4QUrlaSEOS_@Base 1.0.9
+ _ZN12QMapNodeBase8setColorENS_5ColorE@Base 1.1.0-3
+ _ZN12QMapNodeBase9setParentEPS_@Base 1.1.0-3
+#MISSING: 1.1.0-3# _ZN4QUrlaSEOS_@Base 1.0.9
  _ZN5QCharC1E11QLatin1Char@Base 1.0.9
  _ZN5QCharC2E11QLatin1Char@Base 1.0.9
  _ZN5mygpo10ApiRequest10searchOpmlERK7QString@Base 1.0.9
@@ -232,8 +234,8 @@
  _ZN7QStringC2Ev@Base 1.0.9
  _ZN7QStringD1Ev@Base 1.0.9
  _ZN7QStringD2Ev@Base 1.0.9
- _ZN7QStringaSEOS_@Base 1.0.9
- _ZN7QStringpLERKS_@Base 1.0.9
+#MISSING: 1.1.0-3# _ZN7QStringaSEOS_@Base 1.0.9
+#MISSING: 1.1.0-3# _ZN7QStringpLERKS_@Base 1.0.9
  _ZN8QVariant7PrivateC1ERKS0_@Base 1.0.9
  _ZN8QVariant7PrivateC1Ev@Base 1.0.9
  _ZN8QVariant7PrivateC2ERKS0_@Base 1.0.9
@@ -246,9 +248,9 @@
  
(optional=templinst)_ZN8QVariant8setValueI14QSharedPointerIN5mygpo7PodcastvRKT_@Base
 1.0.9
  _ZN8QVariantC1Ev@Base 1.0.9
  _ZN8QVariantC2Ev@Base 1.0.9
- _ZN8QVariantaSEOS_@Base 1.0.9
+#MISSING: 1.1.0-3# _ZN8QVariantaSEOS_@Base 1.0.9
  _ZN9QDateTime4swapERS_@Base 1.0.9
- _ZN9QDateTimeaSEOS_@Base 1.0.9
+#MISSING: 1.1.0-3# _ZN9QDateTimeaSEOS_@Base 1.0.9
 #MISSING: 1.1.0-3# _ZN9QListData7disposeEv@Base 1.0.9
 #MISSING: 1.1.0-3# _ZNK10QByteArraycvPKcEv@Base 1.0.9
  _ZNK5mygpo10DeviceList10metaObjectEv@Base 1.0.9
@@ -350,7 +352,7 @@
  _ZNO7QString11toLocal8BitEv@Base 1.0.9
  _ZNO7QString8toLatin1Ev@Base 1.0.9
  (optional=templinst)_ZNSt13__atomic_baseIiEmmEv@Base 1.0.9
- (optional=templinst)_ZNSt13__atomic_baseIiEppEv@Base 1.0.9
+#MISSING: 

Bug#964647: marked as done (libmygpo-qt: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below)

[Debian Bug Tracking System]

Your message dated Mon, 05 Oct 2020 08:22:28 +
with message-id 
and subject line Bug#964647: fixed in libmygpo-qt 1.1.0-4
has caused the Debian Bug report #964647,
regarding libmygpo-qt: FTBFS: dpkg-gensymbols: error: some symbols or patterns 
disappeared in the symbols file: see diff output below
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
964647: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964647
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: libmygpo-qt
Version: 1.1.0-3
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20200709 ftbfs-bullseye

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.

Relevant part (hopefully):
> make[2]: Entering directory '/<>/obj-x86_64-linux-gnu'
> make[2]: Nothing to be done for 'preinstall'.
> make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> Install the project...
> /usr/bin/cmake -P cmake_install.cmake
> -- Install configuration: "None"
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig/libmygpo-qt5.pc
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/mygpo-qt5/Mygpo-qt5Targets.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/mygpo-qt5/Mygpo-qt5Targets-none.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/mygpo-qt5/Mygpo-qt5Config.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/mygpo-qt5/Mygpo-qt5ConfigVersion.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libmygpo-qt5.so.1.1.0
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libmygpo-qt5.so.1
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libmygpo-qt5.so
> -- Installing: /<>/debian/tmp/usr/include/mygpo-qt5/ApiRequest.h
> -- Installing: 
> /<>/debian/tmp/usr/include/mygpo-qt5/mygpo_export.h
> -- Installing: /<>/debian/tmp/usr/include/mygpo-qt5/Config.h
> -- Installing: /<>/debian/tmp/usr/include/mygpo-qt5/Podcast.h
> -- Installing: /<>/debian/tmp/usr/include/mygpo-qt5/PodcastList.h
> -- Installing: /<>/debian/tmp/usr/include/mygpo-qt5/Episode.h
> -- Installing: /<>/debian/tmp/usr/include/mygpo-qt5/EpisodeList.h
> -- Installing: /<>/debian/tmp/usr/include/mygpo-qt5/Tag.h
> -- Installing: /<>/debian/tmp/usr/include/mygpo-qt5/TagList.h
> -- Installing: /<>/debian/tmp/usr/include/mygpo-qt5/Device.h
> -- Installing: /<>/debian/tmp/usr/include/mygpo-qt5/DeviceList.h
> -- Installing: 
> /<>/debian/tmp/usr/include/mygpo-qt5/DeviceSyncResult.h
> -- Installing: 
> /<>/debian/tmp/usr/include/mygpo-qt5/DeviceUpdates.h
> -- Installing: 
> /<>/debian/tmp/usr/include/mygpo-qt5/EpisodeAction.h
> -- Installing: 
> /<>/debian/tmp/usr/include/mygpo-qt5/EpisodeActionList.h
> -- Installing: /<>/debian/tmp/usr/include/mygpo-qt5/Settings.h
> -- Installing: 
> /<>/debian/tmp/usr/include/mygpo-qt5/AddRemoveResult.h
> make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
>dh_install -O--parallel
> dh_install: warning: Compatibility levels before 10 are deprecated (level 9 
> in use)
>dh_installdocs -O--parallel
> dh_installdocs: warning: Compatibility levels before 10 are deprecated (level 
> 9 in use)
>dh_installchangelogs -O--parallel
> dh_installchangelogs: warning: Compatibility levels before 10 are deprecated 
> (level 9 in use)
>dh_installexamples -O--parallel
> dh_installexamples: warning: Compatibility levels before 10 are deprecated 
> (level 9 in use)
>dh_installinit -O--parallel
> dh_installinit: warning: Compatibility levels before 10 are deprecated (level 
> 9 in use)
>dh_perl -O--parallel
>dh_link -O--parallel
>dh_strip_nondeterminism -O--parallel
>dh_compress -O--parallel
> dh_compress: warning: Compatibility levels before 10 are deprecated (level 9 
> in use)
> dh_compress: warning: Compatibility levels before 10 are deprecated (level 9 
> in use)
>dh_fixperms -O--parallel
>dh_missing -O--parallel
> dh_missing: warning: Compatibility levels before 10 are deprecated (level 9 
> in use)
>dh_strip -O--parallel
> dh_strip: warning: Compatibility levels before 10 are deprecated (level 9 in 
> use)
> dh_strip: warning: Compatibility levels before 10 are deprecated (level 9 in 
> use)
>dh_makeshlibs -O--parallel
> dh_makeshlibs: warning: Compatibility levels before 10 are deprecated (level 
> 9 in use)
> dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
> diff output below
> dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
> file: see diff output below
> 

Processed: Re: Bug#971689: gnome-shell-extension-pixelsaver: Fails with "No JS module 'tweener' found in search path"

[Debian Bug Tracking System]

Processing control commands:

> retitle -1 gnome-shell-extension-pixelsaver: Fails to load on Shell 3.38: No 
> JS module 'tweener' found in search path
Bug #971689 [gnome-shell-extension-pixelsaver] 
gnome-shell-extension-pixelsaver: Fails with "No JS module 'tweener' found in 
search path"
Changed Bug title to 'gnome-shell-extension-pixelsaver: Fails to load on Shell 
3.38: No JS module 'tweener' found in search path' from 
'gnome-shell-extension-pixelsaver: Fails with "No JS module 'tweener' found in 
search path"'.
> severity -1 grave
Bug #971689 [gnome-shell-extension-pixelsaver] 
gnome-shell-extension-pixelsaver: Fails to load on Shell 3.38: No JS module 
'tweener' found in search path
Severity set to 'grave' from 'important'
> tags -1 + fixed-upstream patch bullseye sid
Bug #971689 [gnome-shell-extension-pixelsaver] 
gnome-shell-extension-pixelsaver: Fails to load on Shell 3.38: No JS module 
'tweener' found in search path
Added tag(s) bullseye, fixed-upstream, and sid.

-- 
971689: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971689
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: dpkg-source cause gap-atlasrep to FTBFS for no reason

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 971203 important
Bug #971203 [dpkg-dev] gap-atlasrep: FTBFS: dpkg-source: error: pathname 
'/<>/debian/gaproot/pkg/AtlasRep' points outside source root (to 
'/<>')
Severity set to 'important' from 'serious'
> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
971203: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971203
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#971203: dpkg-source cause gap-atlasrep to FTBFS for no reason

[Bill Allombert]

severity 971203 important
quit

> > root (to '/tmp/gap-atlasrep-2.1.0')
> > E: Unpack command 'dpkg-source --no-check -x gap-atlasrep_2.1.0-2.dsc'
> > failed.
> > 
> > There is no rationale to reject such a symlink which does not point
> > _outside_ the source root, but _to_ the source root.
> > This leads to a spurious FTBFS.

I lowered the severity to important because gap-atlasrep has been updated
to avoid this FTBFS and according to Lucas there are no other packages
affected in unstable.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#969616: marked as done (rust-tui builds 5 uninstallable packages)

[Debian Bug Tracking System]

Your message dated Mon, 05 Oct 2020 07:49:05 +
with message-id 
and subject line Bug#969616: fixed in rust-tui 0.8.0-3
has caused the Debian Bug report #969616,
regarding rust-tui builds 5 uninstallable packages
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
969616: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969616
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: rust-tui
Version: 0.8.0-2
Severity: grave
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy

The rust-tui source package builds 5 different binary packages all of which
has unsatisfiable dependencies, as reported by britney:

librust-tui+crossterm-dev/amd64 has unsatisfiable dependency
librust-tui+curses-dev/amd64 has unsatisfiable dependency
librust-tui+easycurses-dev/amd64 has unsatisfiable dependency
librust-tui+pancurses-dev/amd64 has unsatisfiable dependency
librust-tui+rustbox-dev/amd64 has unsatisfiable dependency

None of rust-crossterm, rust-easycurses, rust-pancurses, or rust-rustbox
appear anywhere in Debian, including in the NEW queue.

We should not have uninstallable packages in the archive.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Source: rust-tui
Source-Version: 0.8.0-3
Done: Sylvestre Ledru 

We believe that the bug you reported is fixed in the latest version of
rust-tui, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 969...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sylvestre Ledru  (supplier of updated rust-tui package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 05 Oct 2020 09:18:34 +0200
Source: rust-tui
Architecture: source
Version: 0.8.0-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Rust Maintainers 

Changed-By: Sylvestre Ledru 
Closes: 969616
Changes:
 rust-tui (0.8.0-3) unstable; urgency=medium
 .
   * Team upload.
   * Package tui 0.8.0 from crates.io using debcargo 2.4.3
 Fixes dependencies (Closes: #969616)
Checksums-Sha1:
 276965257810204b7fd371584f1d944647e5d545 3066 rust-tui_0.8.0-3.dsc
 528640631787fc7bdf1b74d7f4c8b0a01220c51f 3260 rust-tui_0.8.0-3.debian.tar.xz
 6e51a7275e46050600acbc88438ee13c33015025 8306 rust-tui_0.8.0-3_source.buildinfo
Checksums-Sha256:
 62634b6d025beb1d8bcb14ac4b3365ad9234498471d4926b5ed229258291ee08 3066 
rust-tui_0.8.0-3.dsc
 be1bb40244338fe3cbcda15d8f5828c83b3df4bb6a384d1001e7c60aa0a74837 3260 
rust-tui_0.8.0-3.debian.tar.xz
 8b7ee47f7ccf5c95fb8e152033ed3e9fdf41f0d23130a52a1fdf8108e5281fd9 8306 
rust-tui_0.8.0-3_source.buildinfo
Files:
 b1f1a7208a05f25ac07aab8c38b6fe8f 3066 rust optional rust-tui_0.8.0-3.dsc
 218e7578db9a2f51524933918d8ca047 3260 rust optional 
rust-tui_0.8.0-3.debian.tar.xz
 894ef85d7aae9f764b8621dedd0f9e19 8306 rust optional 
rust-tui_0.8.0-3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEtg21mU05vsTRqVzPfmUo2nUvG+EFAl96yM0ACgkQfmUo2nUv
G+FJ9Q//Xd8YryjV+7PZT3qnzWkpabctUWH6tHztg/UuD4nrQOwooB+Lgd3qW1Eb
gs6nlRMVaRYlfiteSwSkjO/RYvZDVwoubF0Eo0ebiZwWgIZam0JgZUBfbEXMgXOw
VoFsuoLfsDVRpVsjyPrENlWEFukKMvflbpiJ9I0pD+z8Tq6nrUhIS3FV+Ryfkpvf
HwC9upUlQAZE6XN3zbKs4nePE9WGEse1K/Q8m/soESKdk/98mkYWaw+vw5fkFd6m
JjrYPYUiNfhkRVE06/BWXzGmhf4JN812Sqnghr5RhbZe713EUewnbL+pLrgNxZR2
izRZwcQAkYre8IP5342Ip4sJmn8+isiNlRBQ+S+abzdU3akzpmiEivaTOU/proei
HOSDGyiUg0urTsCM8HqKZImOrRzQH6j/PkdpOZtkVJgx58OxQd41iDoGRh8KwJ0Q
6bgVOTZZzbHQTscFTny0TDCXAZtV2jMoT2+4IamkkVmE89sAIfNuKoIGck00ool7
tQ7KvlZuro+l1vQk/Syf54MyqG681x04u0uwBNRGgBNetgP7zm/w7sq4OPeyLhrC
Xhh2VGvQjKxKkUnSrFk6ORJvZrm7unsg4oI/TZXrwJU4NIphTIOC/2MeOoAzVAYi
2FOQkN0oV5LP28zeUZabgUa1s2uElylQqg+g4ZzY6NucSDwsIXQ=
=9bdN
-END PGP SIGNATURE End Message ---

Bug#948706: Polite ping

[Julian Gilbey]

On Mon, Oct 05, 2020 at 12:57:59AM +0100, Julian Gilbey wrote:
> 4) The output of "greylist list" is now somewhat mangled: the "Data"
> field shows something like:
> [ ' 1 . 2 . 3 . 4 / 2 4 ' ,   ' i n f o @ e x a m p l e . c o m ' ,   ' j d g 
> @ d e b i a n . o r g ' ]
> rather than
> 1.2.3.4/24  i...@example.com  j...@debian.org
> I guess this should be easy to fix?

Oh, it turns out that this is not so straightforward: the command
greylist add 1.2.3.4/24  i...@example.com  j...@debian.org
yields the following line in /var/lib/greylistd/triplets, which will
probably break things:
4921632547390726349 = 1.2.3.4/24 i...@example.com j...@debian.org

So it seems the triplets need turning into simple strings before they
are stored in the triplets file / triplets hash, rather than being
stored as Python literals with lots of excess spaces.

Best wishes,

   Julian

Processed: Re: Bug#969141: fixed in doxygen 1.8.20-3

[Debian Bug Tracking System]

Processing control commands:

> fixed -1 1.8.20-4
Bug #969141 [doxygen] websocketpp: errors while generating documentation & 
FTBFS with doxygen 1.8.19
Marked as fixed in versions doxygen/1.8.20-4.
> close -1
Bug #969141 [doxygen] websocketpp: errors while generating documentation & 
FTBFS with doxygen 1.8.19
Marked Bug as done

-- 
969141: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969141
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#969141: fixed in doxygen 1.8.20-3

[Gianfranco Costamagna]

control: fixed -1 1.8.20-4
control: close -1

at the end upstream committed a very simple and straightforward additional fix, 
that I just cherry-picked
and uploaded.

G.

On Fri, 2 Oct 2020 12:29:53 +0200 Gianfranco Costamagna 
 wrote:
> Hello,
> 
> I don't want to package a snapshot, so I'll leave this bug open, 1.8.21 will 
> contain the fix anyway.
> 
> G.
> On Fri, 2 Oct 2020 09:34:36 +0200 Gianfranco Costamagna 
>  wrote:
> > control: reopen -1
> > control: notfixed -1 1.8.20-3
> > 
> > Unfortunately for some reasons, commit 
> > d067baf495d0415283ce724ad32cb9a08dc17c83 didn't fix the issue,
> > even if my git bisect resulted in it being the culprit.
> > 
> > I suspect we need some other changes between the 1.8.20 tag and commit 
> > d067baf495d0415283ce724ad32cb9a08dc17c83
> > I'll try to spot them
> > 
> > G.
> > 
> > On Thu, 01 Oct 2020 21:33:47 + Debian FTP Masters 
> >  wrote:
> > > Source: doxygen
> > > Source-Version: 1.8.20-3
> > > Done: Gianfranco Costamagna 
> > > 
> > > We believe that the bug you reported is fixed in the latest version of
> > > doxygen, which is due to be installed in the Debian FTP archive.
> > > 
> > > A summary of the changes between this version and the previous one is
> > > attached.
> > > 
> > > Thank you for reporting the bug, which will now be closed.  If you
> > > have further comments please address them to 969...@bugs.debian.org,
> > > and the maintainer will reopen the bug report if appropriate.
> > > 
> > > Debian distribution maintenance software
> > > pp.
> > > Gianfranco Costamagna  (supplier of updated 
> > > doxygen package)
> > > 
> > > (This message was generated automatically at their request; if you
> > > believe that there is a problem with it please contact the archive
> > > administrators by mailing ftpmas...@ftp-master.debian.org)
> > > 
> > > 
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > > 
> > > Format: 1.8
> > > Date: Thu, 01 Oct 2020 23:23:51 +0200
> > > Source: doxygen
> > > Architecture: source
> > > Version: 1.8.20-3
> > > Distribution: unstable
> > > Urgency: medium
> > > Maintainer: Paolo Greppi 
> > > Changed-By: Gianfranco Costamagna 
> > > Closes: 969141
> > > Changes:
> > >  doxygen (1.8.20-3) unstable; urgency=medium
> > >  .
> > >* Team upload (salsa.d.o namespace)
> > >* debian/patches/d067baf495d0415283ce724ad32cb9a08dc17c83.patch:
> > >  - cherry-pick upstream fix for crash during parse with CLANG helper

Bug#971160: marked as done (golang-github-circonus-labs-circonus-gometrics: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 github.com/circonus-labs/circonus-gometrics

[Debian Bug Tracking System]

Your message dated Mon, 05 Oct 2020 06:03:25 +
with message-id 
and subject line Bug#971160: fixed in 
golang-github-circonus-labs-circonus-gometrics 2.3.1-3
has caused the Debian Bug report #971160,
regarding golang-github-circonus-labs-circonus-gometrics: FTBFS: dh_auto_test: 
error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 
github.com/circonus-labs/circonus-gometrics 
github.com/circonus-labs/circonus-gometrics/api 
github.com/circonus-labs/circonus-gometrics/api/config 
github.com/circonus-labs/circonus-gometrics/checkmgr returned exit code 1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
971160: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971160
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: golang-github-circonus-labs-circonus-gometrics
Version: 2.3.1-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20200926 ftbfs-bullseye

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.

Relevant part (hopefully):
>  debian/rules build
> dh build --buildsystem=golang --with=golang
>dh_update_autotools_config -O--buildsystem=golang
>dh_autoreconf -O--buildsystem=golang
>dh_auto_configure -O--buildsystem=golang
>dh_auto_build -O--buildsystem=golang
>   cd obj-x86_64-linux-gnu && go install -trimpath -v -p 4 
> github.com/circonus-labs/circonus-gometrics 
> github.com/circonus-labs/circonus-gometrics/api 
> github.com/circonus-labs/circonus-gometrics/api/config 
> github.com/circonus-labs/circonus-gometrics/checkmgr
> internal/unsafeheader
> runtime/internal/atomic
> internal/cpu
> runtime/internal/sys
> internal/race
> runtime/internal/math
> sync/atomic
> unicode
> unicode/utf8
> encoding
> internal/bytealg
> math/bits
> internal/testlog
> unicode/utf16
> math
> crypto/internal/subtle
> crypto/subtle
> runtime
> container/list
> vendor/golang.org/x/crypto/cryptobyte/asn1
> internal/nettrace
> vendor/golang.org/x/crypto/internal/subtle
> runtime/cgo
> github.com/circonus-labs/circonus-gometrics/api/config
> internal/reflectlite
> sync
> internal/singleflight
> math/rand
> errors
> sort
> internal/oserror
> strconv
> io
> syscall
> vendor/golang.org/x/net/dns/dnsmessage
> bytes
> strings
> reflect
> bufio
> hash
> crypto
> time
> internal/syscall/unix
> internal/syscall/execenv
> crypto/internal/randutil
> crypto/hmac
> crypto/rc4
> vendor/golang.org/x/crypto/hkdf
> hash/crc32
> vendor/golang.org/x/text/transform
> path
> regexp/syntax
> internal/poll
> context
> os
> regexp
> path/filepath
> net
> encoding/binary
> internal/fmtsort
> io/ioutil
> fmt
> vendor/golang.org/x/sys/cpu
> encoding/base64
> crypto/cipher
> crypto/sha512
> encoding/json
> crypto/aes
> math/big
> crypto/des
> crypto/ed25519/internal/edwards25519
> crypto/md5
> crypto/sha1
> crypto/sha256
> crypto/rand
> crypto/elliptic
> encoding/asn1
> crypto/ed25519
> crypto/rsa
> vendor/golang.org/x/crypto/cryptobyte
> crypto/dsa
> encoding/hex
> encoding/pem
> crypto/x509/pkix
> net/url
> crypto/ecdsa
> vendor/golang.org/x/crypto/chacha20
> vendor/golang.org/x/crypto/poly1305
> vendor/golang.org/x/crypto/curve25519
> compress/flate
> log
> vendor/golang.org/x/crypto/chacha20poly1305
> compress/gzip
> vendor/golang.org/x/text/unicode/bidi
> vendor/golang.org/x/text/unicode/norm
> vendor/golang.org/x/net/http2/hpack
> vendor/golang.org/x/text/secure/bidirule
> mime
> mime/quotedprintable
> net/http/internal
> github.com/pkg/errors
> github.com/circonus-labs/circonusllhist
> vendor/golang.org/x/net/idna
> vendor/golang.org/x/net/http/httpproxy
> net/textproto
> crypto/x509
> vendor/golang.org/x/net/http/httpguts
> mime/multipart
> crypto/tls
> net/http/httptrace
> net/http
> github.com/hashicorp/go-cleanhttp
> github.com/tv42/httpunix
> github.com/hashicorp/go-retryablehttp
> github.com/circonus-labs/circonus-gometrics/api
> github.com/circonus-labs/circonus-gometrics/checkmgr
> github.com/circonus-labs/circonus-gometrics
>dh_auto_test -O--buildsystem=golang
>   cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 
> github.com/circonus-labs/circonus-gometrics 
> github.com/circonus-labs/circonus-gometrics/api 
> github.com/circonus-labs/circonus-gometrics/api/config 
> github.com/circonus-labs/circonus-gometrics/checkmgr
> === RUN   TestNew
> circonus-gometrics_test.go:66: invalid config (none)
> circonus-gometrics_test.go:75: no API token, no submission URL
> circonus-gometrics_test.go:85: no API token, submission URL only
> circonus-gometrics_test.go:110: no Log, Debug = true
>