Bug#971251: dpkg: Accept maintainer's config file if all changes are commented

2020-09-27 Thread hyiltiz
Package: dpkg
Version: 1.20.5
Severity: normal
X-Debbugs-Cc: hyil...@gmail.com

Some packages prompt for whether to accept the package manager's config file or
keep the one in the system (like the one shown below). It is quite common (as
was the case shown below) that the new config file is in fact just contains some
more documentation or commented out lines. I propose that, if all the lines that
changed are commented (either from ours or from maintainer), dpkg should *not*
prompt for the choice, but instead simply merge the new documentation/commented
out available options.

Configuration file '/etc/bluetooth/main.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** main.conf (Y/I/N/O/D/Z) [default=N] ? y

A possible complication for this is that if the package maintainer or the
sysadmin of the system decides to re-arrange the order of the config option
lines, then simply merging might further complicate the issue, and result in a
convoluted file with the same options showing up at multiple places, which is
undesirable even though all of those duplicated lines were commented. But I am
sure we can discuss and find a reasonable merge strategy to adopt that would
a) allow not having to deal with the choice if everything changed was just
   comments
b) automatic action wouldn't ultimately lead to complex/broken config files if
   some common editing actions such as swapping chucks of lines were performed


-- Package-specific info:
System tainted due to merged-usr-via-symlinks.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-3
ii  liblzma5 5.2.4-1+b1
ii  libselinux1  3.1-2
ii  tar  1.30+dfsg-7
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.1.10
pn  debsig-verify  

-- no debconf information



Bug#971249: waf: CHECK_VALUEOF does not work during cross compilation

2020-09-27 Thread Helmut Grohne
Source: tevent
Version: 0.10.2-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Thank you for applying my previous cross build patches. My previous
installment ended with:

> 5. waf has a mandatory run test for determining whether mkstemp works.
> 6. probably more

I've now looked into this and think that there are two bigger steps to
solve these. In the "probably more" department, there is a recurring
scheme of using a "CHECK_VALUEOF". It is used to determine the value of
an integer. If that value happens to be a compile time constant, it can
be determined using bisection. waf already does something similar in
CHECK_SIZEOF. I've implemented it for CHECK_VALUEOF and it now works
similar to autoconf's AC_COMPUTE_INT. In particular, it only does the
expensive bisection during cross compilation. In a native build, it
continues to use the quick run test it did before. I've attached a patch
for this.

For the mkstemp thingy there is little we can do. You cannot check this
property without running code. So during cross compilation, all you can
do is assume that it works. I think the solution will be adding

--cross-compile --cross-answers=somefile

to the waf invocation and having it tell that mkstemp works. This is
also is similar to what autoconf does except that autoconf has
centralized this answer file into a cross-config package. Does that work
for you?

Therefore please consider applying this patch for CHECK_VALUEOF,
preferrably upstream it. For making it work in the packaging, one must
pass --cross-compile to waf. You can do so using the following snippet:

$(if $(filter $(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)),,--cross-compile)

Thank you

Helmut
--- tevent-0.10.2.orig/buildtools/wafsamba/samba_autoconf.py
+++ tevent-0.10.2/buildtools/wafsamba/samba_autoconf.py
@@ -348,16 +348,72 @@
 v_define = define
 if v_define is None:
 v_define = 'VALUEOF_%s' % v.upper().replace(' ', '_')
-if CHECK_CODE(conf,
-  'printf("%%u", (unsigned)(%s))' % v,
-  define=v_define,
-  execute=True,
-  define_ret=True,
-  quote=False,
-  headers=headers,
-  local_include=False,
-  msg="Checking value of %s" % v):
-return int(conf.env[v_define])
+if conf.env.CROSS_COMPILE:
+negative = CHECK_CODE(conf,
+'static int test_array[1 - 2 * !((%s) < 0)];' % v,
+define=v_define + "_negative",
+quote=False, addmain=False, link=False,
+headers=headers,
+local_include=False,
+msg="Checking if %s is negative" % v)
+positive = CHECK_CODE(conf,
+'static int test_array[1 - 2 * !((%s) > 0)];' % v,
+define=v_define + "_positive",
+quote=False, addmain=False, link=False,
+headers=headers,
+local_include=False,
+msg="Checking if %s is positive" % v)
+zero = CHECK_CODE(conf,
+'static int test_array[1 - 2 * !((%s) == 0)];' % v,
+define=v_define + "_zero",
+quote=False, addmain=False, link=False,
+headers=headers,
+local_include=False,
+msg="Checking if %s is zero" % v)
+if zero + positive + negative != 1:
+Logs.warn("Couldn't determine value of '%s'" % v)
+return None
+if zero:
+return 0
+upper_bound = 1
+comp = ">=" if negative else "<="
+sign = -1 if negative else 1
+while not CHECK_CODE(conf,
+'static int test_array[1 - 2 * !((%s) %s %d)];' %
+ (v, comp, sign * upper_bound),
+define=v_define + "_le_%d" % upper_bound,
+quote=False, addmain=False, link=False,
+headers=headers,
+local_include=False,
+msg="Checking if %s %s %d" % (v, comp, sign * upper_bound)):
+upper_bound *= 2
+lower_bound = upper_bound // 2
+while lower_bound + 1 < upper_bound:
+mid = (lower_bound + upper_bound) // 2
+if CHECK_CODE(conf,
+'static int test_array[1 - 2 * !((%s) %s %d)];' %
+ (v, comp, sign * mid),
+define=v_define + "_le_%d" % upper_bound,
+quote=False, addmain=False, link=False,
+headers=headers,
+local_include=False,
+msg="Checking if %s %s %d" % (v, comp, sign * mid)):
+upper_bound = mid
+else:
+lower_bound = mid
+conf.DEFINE(v_define, upper_bound)
+return upper_bound
+else:
+if CHECK_CODE(conf,
+  'printf("%%u", (unsigned)(%s))' % v,
+  define=v_define,
+

Bug#971248: RFS: jag/0.3.8-2 [RC] -- arcade and puzzle 2D game

2020-09-27 Thread Carlos Donizete Froes
Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "jag":

 * Package name: jag
   Version : 0.3.8-2
   Upstream Author : XlabSoft & Industrial Infosystems
 * URL : https://gitlab.com/coringao/jag/wikis
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/games-team/jag
   Section : games

It builds those binary packages:

  jag - arcade and puzzle 2D game

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/jag/

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/j/jag/jag_0.3.8-2.dsc

Changes since the last upload:

 jag (0.3.8-2) unstable; urgency=medium
 .
   * debian/control:
 + Breaks+Replaces on jag-data, thanks gusnan@! (Closes: #970638)

Regards,
--
  Carlos Donizete Froes [a.k.a coringao]



Bug#970983: sugar-themes: does not define @text_view_bg named colour

2020-09-27 Thread James Cameron
Thanks Simon,

I've just tested Debian Testing (Bullseye), with src:sugar 0.117-3,
src:sugar-artwork:0.117-1, src:sugar-terminal-activity version 47-1,
src:vte2.91 version 0.62.0-1, and GTK 3.24.23-1 but do not see any
problem.

The terminal is correctly rendered in black on white or white on black
modes.

I've looked at our GTK themes in https://github.com/sugarlabs/sugar-artwork
but they are unmaintained; changes to the GTK builtin theme since 3.20
are yet to be cascaded.

Is there a way to reproduce the problem?

Please review
https://github.com/sugarlabs/sugar-artwork/pull/117

-- 
James Cameron
http://quozl.netrek.org/



Bug#944738: [Openjdk] Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

2020-09-27 Thread tony mancill
On Fri, Sep 25, 2020 at 03:51:38PM +0100, Julian Gilbey wrote:
> > openjdk-13 does have the problem, so we could do another upload, but
> > given that it's not an LTS release and 14 is already available and
> > patched, do we need to?
> 
> Good question.  It's easy to do, and it does fix a bug, so I don't see
> a good reason not to do so.
> 
> > Neither 13 nor 15 have open bugs filed against them for the jlink hash
> > issue.
> 
> Indeed, but we can still fix it (and in the changelog say something
> like "fixes bug #... for this version of openjdk").

I have uploaded an NMU for openjdk-13 and will take a look at reworking
the openjdk-15 patch as per the discussion in this bug report.



Bug#971247: openjdk-13: diff for NMU version 13.0.4+8-1.1

2020-09-27 Thread tony mancill
Package: openjdk-13
Version: 13.0.4+8-1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for openjdk-13 (versioned as 13.0.4+8-1.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I should
delay it longer or remove it from the queue.

Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944738 for
context.

Thank you,
tony
diff -Nru openjdk-13-13.0.4+8/debian/changelog openjdk-13-13.0.4+8/debian/changelog
--- openjdk-13-13.0.4+8/debian/changelog	2020-07-17 11:24:46.0 -0700
+++ openjdk-13-13.0.4+8/debian/changelog	2020-09-27 13:38:20.0 -0700
@@ -1,3 +1,13 @@
+openjdk-13 (13.0.4+8-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch to strip nondeterminism before computing jmod hash.
+Thank you to Julian Gilbey for the patch.
+See Debian bugs #944738 and #968991.
+Add Build-Depends on strip-nondeterminism.
+
+ -- tony mancill   Sun, 27 Sep 2020 13:38:20 -0700
+
 openjdk-13 (13.0.4+8-1) unstable; urgency=medium
 
   * OpenJDK 13.0.4 release, build 8.
diff -Nru openjdk-13-13.0.4+8/debian/control openjdk-13-13.0.4+8/debian/control
--- openjdk-13-13.0.4+8/debian/control	2020-07-17 09:25:05.0 -0700
+++ openjdk-13-13.0.4+8/debian/control	2020-09-27 13:37:50.0 -0700
@@ -15,6 +15,7 @@
   zlib1g-dev:native, zlib1g-dev, libattr1-dev, libpng-dev, libjpeg-dev, libgif-dev, 
   libnss3-dev (>= 2:3.17.1),
   openjdk-13-jdk-headless ,
+  strip-nondeterminism,
 Build-Depends-Indep: graphviz, pandoc,
 Standards-Version: 4.4.0
 Homepage: http://openjdk.java.net/
diff -Nru openjdk-13-13.0.4+8/debian/patches/reproducible-build-jmod.diff openjdk-13-13.0.4+8/debian/patches/reproducible-build-jmod.diff
--- openjdk-13-13.0.4+8/debian/patches/reproducible-build-jmod.diff	1969-12-31 16:00:00.0 -0800
+++ openjdk-13-13.0.4+8/debian/patches/reproducible-build-jmod.diff	2020-09-27 13:36:33.0 -0700
@@ -0,0 +1,33 @@
+Description: jlink: Hash of module differs to expected hash recorded in java.base
+ The cause is the use of dh_strip_nondeterminism late in the build
+ process.  This reorganises the jmod files, which in turn changes their
+ SHA256 checksums.  This would not be a problem, except that the
+ checksums are saved in java.base.jmod *before* the use of
+ dh_strip_nondeterminism.  Performing this stripping immediately after
+ each jmod file is created results in the checksums being consistent
+ throughout.
+Author: Julian Gilbey 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944738
+Forwarded: not-needed
+
+--- a/make/CreateJmods.gmk
 b/make/CreateJmods.gmk
+@@ -216,6 +216,9 @@
+ 
+ # Create jmods in the support dir and then move them into place to keep the
+ # module path in $(IMAGES_OUTPUTDIR)/jmods valid at all times.
++# strip-nondeterminism requires the same timestamp as
++# dh_strip_nondeterminism uses, so we determine this first.
++DSN_TIMESTAMP := $(shell perl -MDebian::Debhelper::Dh_Lib -e 'print get_source_date_epoch()')
+ $(eval $(call SetupExecute, create_$(JMOD_FILE), \
+ WARN := Creating $(INTERIM_MSG)$(JMOD_FILE), \
+ DEPS := $(DEPS), \
+@@ -226,7 +229,7 @@
+ --target-platform '$(OPENJDK_MODULE_TARGET_PLATFORM)' \
+ --module-path $(JMODS_DIR) $(JMOD_FLAGS) \
+ $(JMODS_SUPPORT_DIR)/$(JMOD_FILE), \
+-POST_COMMAND := $(MV) $(JMODS_SUPPORT_DIR)/$(JMOD_FILE) $(JMODS_DIR)/$(JMOD_FILE), \
++POST_COMMAND := strip-nondeterminism --timestamp $(DSN_TIMESTAMP) $(JMODS_SUPPORT_DIR)/$(JMOD_FILE) && $(MV) $(JMODS_SUPPORT_DIR)/$(JMOD_FILE) $(JMODS_DIR)/$(JMOD_FILE), \
+ ))
+ 
+ TARGETS += $(create_$(JMOD_FILE))
diff -Nru openjdk-13-13.0.4+8/debian/patches/series openjdk-13-13.0.4+8/debian/patches/series
--- openjdk-13-13.0.4+8/debian/patches/series	2020-04-14 23:41:08.0 -0700
+++ openjdk-13-13.0.4+8/debian/patches/series	2020-09-27 13:36:27.0 -0700
@@ -43,3 +43,4 @@
 reproducible-copyright-headers.diff
 reproducible-build-user.diff
 JDK-8230708.diff
+reproducible-build-jmod.diff


signature.asc
Description: PGP signature


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

2020-09-27 Thread Guillem Jover
Hi!

On Sun, 2020-09-27 at 22:53:13 +0200, Bill Allombert wrote:
> On Sun, Sep 27, 2020 at 08:58:00PM +0200, Lucas Nussbaum wrote:
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> > 
> > > dpkg-source: error: pathname 
> > > '/<>/debian/gaproot/pkg/AtlasRep' points outside source root 
> > > (to '/<>')

> $ apt-get source gap-atlasrep
> Fetched 1351 kB in 2s (722 kB/s)
> dpkg-source: info: extracting gap-atlasrep in gap-atlasrep-2.1.0
> dpkg-source: info: unpacking gap-atlasrep_2.1.0.orig.tar.bz2
> dpkg-source: info: unpacking gap-atlasrep_2.1.0-2.debian.tar.xz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: applying doc-makefile
> dpkg-source: info: applying default-dir
> dpkg-source: error: pathname
> 'gap-atlasrep-2.1.0/debian/gaproot/pkg/AtlasRep' points outside source
> 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.

Right, this is due to a regex not matching when the basedir is the
same as the canonicalized symlink target. I've fixed this, but need to
adapt the new test case.

> Also I am concerned that developers might need to unpack old packages
> with symlinks in them. There should be a way to do it, if only to fix
> the packaging.

I guess it might make sense indeed to disable this when running under
--no-check.

Thanks,
Guillem



Bug#971246: thermald: incorrect homepage, update to https://01.org/linux-thermal-daemon

2020-09-27 Thread Paul Wise
Package: thermald
Version: 2.3-3
Severity: normal

The Homepage field points at GitHub but it should point here:

https://01.org/linux-thermal-daemon

The GitHub URL is the VCS repository not the Homepage.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part


Bug#971245: apt-setup: Please add proposed-updates configuration to /etc/apt/sources.list

2020-09-27 Thread xiao sheng wen
Package: apt-setup
Severity: wishlist

Dear Maintainer,

please consider adding a sources.list configuration for
proposed-updates during the installation.
Commenting them out by default would probably be a safe default.

Cheers,
xiao sheng wen

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-11-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE=zh_CN:zh 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#971244: nqp-data: Missing Breaks/Replaces headers: trying to overwrite '/usr/share/nqp/lib/MASTNodes.moarvm', which is also in package nqp 2020.06+dfsg-1

2020-09-27 Thread Axel Beckert
Package: nqp-data
Version: 2020.09+dfsg-1
Severity: serious

Hi,

upgrading nqp and nqp-data from 2020.06 to 2020.09 fails for me as
follows:

[...]
Unpacking nqp-data (2020.09+dfsg-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-lsZi6y/14-nqp-data_2020.09+dfsg-1_all.deb (--unpack):
 trying to overwrite '/usr/share/nqp/lib/MASTNodes.moarvm', which is also in 
package nqp 2020.06+dfsg-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Preparing to unpack .../15-nqp_2020.09+dfsg-1_amd64.deb ...
Unpacking nqp (2020.09+dfsg-1) over (2020.06+dfsg-1) ...
[...]

If I run the upgrade a second time, it works because nqp is already
upgraded then. Nevertheless an RC bug due to the file conflict upon
first upgrade.

Looks as if Breaks and Replaces headers are missing in the nqp-data
package and that it takes over files from the old nqp package.

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages nqp-data depends on:
ii  libjs-angularjs  1.8.0-1
ii  libjs-bootstrap  3.4.1+dfsg-1
ii  moarvm   2020.09+dfsg-1

nqp-data recommends no packages.

nqp-data suggests no packages.

-- no debconf information



Bug#960831: about RFS: yiyantang

2020-09-27 Thread Paul Wise
On Sun, Sep 27, 2020 at 3:18 PM Tobias Frost wrote:

> If upstream is gone and won't come back you can delete the watch file.

I suggest instead to keep the watch file, but add a comment mentioning
the upstream situation.

> Did you look if there are any forks that could be new upstream?

It can also be a good idea to create a new upstream project or take
over the existing one if it is still there but not active.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Bug#932431: DDPO: package removed from experimental but still shown in DDPO column

2020-09-27 Thread Paul Wise
Control: tags -1 - wontfix
Control: retitle -1 DDPO: hide Extra-Source-Only packages by default,
add option to show them

On Sun, Sep 27, 2020 at 6:00 AM Paul Wise wrote:

> The version in experimental is ESO, so I think it is fine to hide it by
> default, perhaps with a parameter to show ESO packages?

Updating the bug metadata to reflect that suggestion.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Bug#971214: elpy: FTBFS: tests failed

2020-09-27 Thread Salman Mohammadi

Hi,

What I can see is that


> (error "Elpy error: black not installed")


Is *black* already installed?


Cheers,

Salman


On Sun, 27 Sep 2020 21:06:17 +0200 Lucas Nussbaum  wrote:

> Source: elpy
> Version: 1.34.0-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):
> > make[1]: Entering directory '/<>'
> > dh_auto_build
> > I: pybuild base:217: /usr/bin/python3 setup.py build
> > running build
> > running build_py
> > creating /<>/.pybuild/cpython3_3.8_elpy/build/elpy
> > copying elpy/jedibackend.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy
> > copying elpy/refactor.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy
> > copying elpy/__init__.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy
> > copying elpy/__main__.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy
> > copying elpy/pydocutils.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy
> > copying elpy/blackutil.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy
> > copying elpy/yapfutil.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy
> > copying elpy/compat.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy
> > copying elpy/auto_pep8.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy
> > copying elpy/rpc.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy
> > copying elpy/server.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy

> > creating /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> > copying elpy/tests/test_server.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> > copying elpy/tests/test_rpc.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> > copying elpy/tests/support.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> > copying elpy/tests/test_yapf.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> > copying elpy/tests/__init__.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> > copying elpy/tests/test_pydocutils.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> > copying elpy/tests/test_auto_pep8.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> > copying elpy/tests/test_refactor.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> > copying elpy/tests/test_jedibackend.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> > copying elpy/tests/compat.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> > copying elpy/tests/test_black.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> > copying elpy/tests/test_support.py -> 
/<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests

> > running egg_info
> > creating elpy.egg-info
> > writing elpy.egg-info/PKG-INFO
> > writing dependency_links to elpy.egg-info/dependency_links.txt
> > writing requirements to elpy.egg-info/requires.txt
> > writing top-level names to elpy.egg-info/top_level.txt
> > writing manifest file 'elpy.egg-info/SOURCES.txt'
> > reading manifest file 'elpy.egg-info/SOURCES.txt'
> > reading manifest template 'MANIFEST.in'
> > writing manifest file 'elpy.egg-info/SOURCES.txt'
> > PYTHONPATH=. python3 -m sphinx -N -bman docs/ build/man
> > Running Sphinx v3.2.1
> > making output directory... done
> > building [mo]: targets for 0 po files that are out of date
> > building [man]: all manpages
> > updating environment: [new config] 9 added, 0 changed, 0 removed
> > reading sources... [ 11%] FAQ



Bug#970777: fish: tty settings are not resetted on exit

2020-09-27 Thread Boyuan Yang
X-Debbugs-CC: lu...@debian.org mithra...@debian.org

Hi all,

Just in case you missed it: the proposed fix can be found at 
https://salsa.debian.org/debian/fish/-/merge_requests/2 .

-- 
Regards,
Boyuan Yang

在 2020-09-27星期日的 20:56 -0400,Boyuan Yang写道:
> X-Debbugs-CC: lu...@debian.org mithra...@debian.org
> 
> On Wed, 23 Sep 2020 17:41:00 +0800 Wang Shanker <
> shankerwangm...@gmail.com> wrote:
> > Control: severity -1 important
> > 
> > I raise the severity to important, because under certain
> circumstances, after exiting fish,
> > the tty becomes totally unusable. For example:
> > 
> > (bash) $ sudo fish
> > (fish) # exit
> > (bash) $ <- tty unusable here
> 
> Hi Tristan,
> 
> I was contacted by the bug submitter about this important bug and
> verified the severity and proposed fix. I'm wondering if you are
> going
> to make a stable upload soon to fix this issue.
> 
> I received some unofficial messages from Mo Zhou that he is too busy
> to
> handle it right now.
> 
> Please let me know if this will be handled in the near future. If not
> (or if there's no reply within 1 week), I plan to do a NMU stable
> upload and contact the Release Team about this stable upload.
> 
> Thanks and looking forward to your reply. Please include me in the CC
> list.
> 



Bug#970777: Acknowledgement (fish: tty settings are not resetted on exit)

2020-09-27 Thread Boyuan Yang
X-Debbugs-CC: lu...@debian.org mithra...@debian.org

On Wed, 23 Sep 2020 17:41:00 +0800 Wang Shanker <
shankerwangm...@gmail.com> wrote:
> Control: severity -1 important
> 
> I raise the severity to important, because under certain
circumstances, after exiting fish,
> the tty becomes totally unusable. For example:
> 
> (bash) $ sudo fish
> (fish) # exit
> (bash) $ <- tty unusable here

Hi Tristan,

I was contacted by the bug submitter about this important bug and
verified the severity and proposed fix. I'm wondering if you are going
to make a stable upload soon to fix this issue.

I received some unofficial messages from Mo Zhou that he is too busy to
handle it right now.

Please let me know if this will be handled in the near future. If not
(or if there's no reply within 1 week), I plan to do a NMU stable
upload and contact the Release Team about this stable upload.

Thanks and looking forward to your reply. Please include me in the CC
list.

-- 
Regards,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part


Bug#880156: ITP: albert -- fast and flexible keyboard launcher

2020-09-27 Thread Boyuan Yang
Control: owner -1 !
Control: retitle -1 RFP: albert -- fast and flexible keyboard launcher

Since I don't have enought time to work on this, I am converting this
bug to a Request-to-package bug report.

Thanks,
Boyuan Yang

On Mon, 30 Oct 2017 12:22:58 +0800 Boyuan Yang <073p...@gmail.com>
wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Boyuan Yang <073p...@gmail.com>
> X-Debbugs-CC: debian-de...@lists.debian.org manuelschnei...@gmail.com
> 
> * Package name: albert
>   Version : 0.14.4
>   Upstream Author : Manuel Schneider 
> * URL : https://github.com/albertlauncher/albert
> * License : GPL-3+
>   Programming Lang: C++/Qt
>   Description : fast and flexible keyboard launcher
> 
> Albert is a new desktop keyboard launcher written in C++/Qt. Its 
> functionalities is arranged as plugins and can be extended easily.
> 
> Original project put plugins into git submodules. I will repack
upstream 
> source code to put them inside a repacked src tarball. Vendored 3rd
party code 
> (in the form of git submodule, like pybind11) and non-free part
(e.g., 
> virtualbox plugin which needs vbox headers) will be disabled or
removed before 
> we have a better solution.
> 
> I intend to co-maintain it inside a collab-maint repository on
Alioth. (co-
> maintainers welcome)


signature.asc
Description: This is a digitally signed message part


Bug#971243: sysprof: Split to separate binary packages

2020-09-27 Thread Jeremy Bicha
Source: sysprof
Version: 3.38.0-2

We should split sysprof into separate packages, a library package, a
development headers package, etc.

The biggest benefit would be for users of GNOME Builder. GNOME Builder
integrates features from the sysprof library. Installing GNOME Builder
also gets you the Sysprof app but there's not really a need for every
GNOME Builder user to also have that app in their app list.

This has been a known issue for years, but it's been a fairly low
priority so far.

Thanks,
Jeremy Bicha



Bug#908234: cjs: Please switch to mozjs78

2020-09-27 Thread Norbert Preining
Hi Simon,

thanks for the update.

> but the GNOME team doesn't really have the resources to deal with more
> than one version (we'd prefer not to maintain mozjs78 either, but we

Neither do I have the resources and will do deail with mozjs52, and the
rest of the cinnamon team seems to have even less interest than me.

I pinged upstream again, but don't bet on much move there.

Since I myself are using cinnamon nowadays only sporadically, I don't
see anyone taking up the ball, which means that orphaning mozjs52, and
follow up removal of mozjs52 and cinnamon from testing looks like the
only possible outcome.

I am fine with that.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13



Bug#958404: Tried to confirm on clean VM

2020-09-27 Thread Felix Stupp
I TRIED to confirm the issue in a clean VirtualBox VM, but failed.

On Debian Buster after enabling Backports, installing wireguard and confirming 
that it was built by dkms, I got the same issue. Rebooting the system did not 
help.

I collected more information about the dkms module, and found the issue:
"wireguard-dkms" was built for the newest kernel available in buster (not 
backports),
in my case "4.19.0-11-amd64" (see output of "dkms status") due to first 
installing "linux-headers-amd64" (wasn't required before).
Testing with "modprobe wireguard" showed, that the kernel module could not be 
loaded.
And that was because I was running the older kernel version "4.19.0-10-amd64".
Upgrading and restarting the system solved the issue in my case.

It must be that a new kernel version was released while I was working today 
with the VM,
maybe a similar issue happened to you, too?

Best Regards,
Felix Stupp

signature.asc
Description: This is a digitally signed message part.


Bug#908234: cjs: Please switch to mozjs78

2020-09-27 Thread Simon McVittie
Control: retitle 908234 cjs: Please switch to mozjs78

On Mon, 17 Aug 2020 at 09:31:05 +0100, Simon McVittie wrote:
> On Fri, 07 Sep 2018 at 12:23:17 -0400, Jeremy Bicha wrote:
> > Ideally, cjs would switch to using mozjs60. I understand this will
> > require coordination with the Cinnamon developers.
> 
> Make that mozjs68, now.

And another Firefox ESR release cycle. We now have mozjs78 in unstable
and in use by gjs; this is the version that GNOME will be using in
Debian 11 'bullseye', unless the freeze happens much later than expected.

This means we now have:

mozjs52: cjs
(mozjs60 removed)
mozjs68: a libproxy plugin that doesn't actually work (probably removed soon)
mozjs78: gjs, policykit-1/experimental

We hope to remove mozjs68 soon, leaving only mozjs52 (for cjs) and mozjs78
(for gjs and policykit-1).

Releasing bullseye with both those versions maybe wouldn't be *so* bad,
but the GNOME team doesn't really have the resources to deal with more
than one version (we'd prefer not to maintain mozjs78 either, but we
need it and nobody else seems to want it, so we have to); so we might
well end up orphaning mozjs52.

smcv



Bug#971242: debconf-kde-helper: Widgets note and error show the Description and Extended Description in wrong order/position

2020-09-27 Thread Jaakko Kantojärvi
Package: debconf-kde-helper
Version: 1.0.3-4
Severity: normal

Dear Maintainer,

I think note and error inputs add the description and the extended description
in
wrong QWidgets. The Description is added to textTE (KTextEdit) and the extended
description is added into descriptionL (QLabel). The former is clearly meant
for the longer content, while the latter for the shorter text.

The rendering can be compared to the gnome frontend, where the information is
in a different order.

I have attached a small script, which can be used to show the wrong rendering.



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

Kernel: Linux 5.8.0-1-amd64 (SMP w/24 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debconf-kde-helper depends on:
ii  libc6  2.31-3
ii  libdebconf-kde11.0.3-4
ii  libkf5coreaddons5  5.70.0-2
ii  libkf5i18n55.70.0-1
ii  libqt5core5a   5.14.2+dfsg-6
ii  libqt5widgets5 5.14.2+dfsg-6
ii  libstdc++6 10.2.0-9

debconf-kde-helper recommends no packages.

debconf-kde-helper suggests no packages.
#!/bin/sh

tmp=$(mktemp -d /tmp/debconf-kde-bug.X)

cat > "$tmp/templates" < "$tmp/script" <

Bug#971241: debconf-kde-helper: Boolean inputs are always set to true/yes position, no matter what the actual state is

2020-09-27 Thread Jaakko Kantojärvi
Package: debconf-kde-helper
Version: 1.0.3-4
Severity: normal

Dear Maintainer,

I noticed that the debconf's kde frontend fails to handle boolean inputs
correctly. The GUI always sets the input to true/yes position even when the
value is false/no. Thus, if the current value is false/no the GUI will always
toggle it back on.

I have attached a small shell script, which does demostrate the bug.



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

Kernel: Linux 5.8.0-1-amd64 (SMP w/24 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debconf-kde-helper depends on:
ii  libc6  2.31-3
ii  libdebconf-kde11.0.3-4
ii  libkf5coreaddons5  5.70.0-2
ii  libkf5i18n55.70.0-1
ii  libqt5core5a   5.14.2+dfsg-6
ii  libqt5widgets5 5.14.2+dfsg-6
ii  libstdc++6 10.2.0-9

debconf-kde-helper recommends no packages.

debconf-kde-helper suggests no packages.
#!/bin/sh

tmp=$(mktemp -d /tmp/debconf-kde-bug.X)

cat > "$tmp/templates" < "$tmp/script" <

Bug#971058: [PATCH] ACPI / extlog: Check for RDMSR failure

2020-09-27 Thread Ben Hutchings
extlog_init() uses rdmsrl() to read an MSR, which on older CPUs
provokes a error message at boot:

unchecked MSR access error: RDMSR from 0x179 at rIP: 0xcd047307 
(native_read_msr+0x7/0x40)

Use rdmsrl_safe() instead, and return -ENODEV if it fails.

Reported-by: j...@photojim.ca
References: https://bugs.debian.org/971058
Cc: sta...@vger.kernel.org
Signed-off-by: Ben Hutchings 
---
 drivers/acpi/acpi_extlog.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c
index f138e12b7b82..72f1fb77abcd 100644
--- a/drivers/acpi/acpi_extlog.c
+++ b/drivers/acpi/acpi_extlog.c
@@ -222,9 +222,9 @@ static int __init extlog_init(void)
u64 cap;
int rc;
 
-   rdmsrl(MSR_IA32_MCG_CAP, cap);
-
-   if (!(cap & MCG_ELOG_P) || !extlog_get_l1addr())
+   if (rdmsrl_safe(MSR_IA32_MCG_CAP, ) ||
+   !(cap & MCG_ELOG_P) ||
+   !extlog_get_l1addr())
return -ENODEV;
 
rc = -EINVAL;


signature.asc
Description: PGP signature


Bug#971240: Where to set the variable "VERBOSITY"

2020-09-27 Thread Bjarni Ingi Gislason
Package: ifupdown-extra
Version: 0.31
Severity: normal

Dear Maintainer,

  the variable "VERBOSITY" is used in the file
"/etc/init.d/networking-routes" and the directory
"/etc/network/if-up.d".

  Where can, may it be defined outside these places?

N.B. The repository "anonscm.debian.org/collab-maint/ifupdown-extra.git"
is not found by the watch file. (tracker.debian.org/pkg/ifupdown-extra)


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

Kernel: Linux 5.8.7-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ifupdown-extra depends on:
ii  bind9-host [host]1:9.16.6-3
ii  curl 7.72.0-1
ii  dpkg 1.20.5
ii  iproute2 5.8.0-1
ii  iputils-arping   3:20200821-2
ii  iputils-ping [ping]  3:20200821-2
ii  lsb-base 11.1.0
ii  net-tools1.60+git20180626.aebd88e-1
ii  netcat-openbsd   1.217-2

Versions of packages ifupdown-extra recommends:
pn  ethtool  
pn  ndisc6   

ifupdown-extra suggests no packages.

-- Configuration Files:
/etc/default/network-test changed [not included]

-- no debconf information

-- 
Bjarni I. Gislason



Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs

2020-09-27 Thread Ben Hutchings
On Sun, 2020-09-27 at 13:43 -0300, Henrique de Moraes Holschuh wrote:
> Answering from my phone, please excuse brevity and other netiquete
> issues such as poor quoting cleanup.
> 
> On Fri, Sep 25, 2020, at 09:14, maximilian attems wrote:
> > Dear Henrique,
> > 
> > It be great to get your input, hence repinging (;
> > 
> > Especially as linux-firmware is the common upstream source, it be ideal to 
> > ship
> > the amd64 mircrocode out of our firmware packages.
> 
> We can ship the ucode and other related data files in linux-firmware-
> nonfree, yes.  But the initramsfs glue needs.to go somewhere.  Either
> it can stick in the older package, and a depends ensures it gets
> installed, or linux-firmware-nonfree must carry it as debian
> packaging.

That's a good point.  firmware-nonfree does have initramfs integration,
but currently that is just triggering update-initramfs for packages
whose firmware might get pulled in automatically.

[...]
> > On Sun, Sep 20, 2020 at 10:36:12AM +0200, maximilian attems wrote:
> > > Dear Henrique, dear debian kernel maintainers, Cc: Michael,
> > > 
> > > Would you agree to generate the amd64-firmware packages directly out of 
> > > the debian
> > > linux-firmware source package?
> > > 
> > > This way the microcode would be updated on every linux-firmware non-free 
> > > upload?
> 
> If you guys think this will improve update delivery latency in
> Debian, I am not opposed.  But ucode updates go to security,
> backports and stable unless there is too little feedback to gauge
> regression risk.
> 
>   Is that viable for the whole of linux-firmware-nonfree ?  If not,
> it would make sense to keep the amd64 ucode in a separate package.
[...]

firmware-nonfree is present in backports suites, and does get security
updates (mostly for Wifi and Bluetooth issues).

However, we normally take all changes from linux-firmware.git up to a
specific tag, and that might not be appropriate for the AMD microcode
given the potential for system-breaking regressions.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
   A fail-safe circuit will destroy others.




signature.asc
Description: This is a digitally signed message part


Bug#971058: linux-image-4.19.0-11-686: "Unchecked MSR access error: RDMSR" on Geode LX on 4.19.0-11-686; seems present on -10 too

2020-09-27 Thread Ben Hutchings
Control: tag -1 upstream

On Sat, 2020-09-26 at 18:26 -0600, j...@photojim.ca wrote:
> Package: src:linux
> Version: 4.19.146-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Debian 4.19 kernels (unsure for how long) are giving MSR access error
> upon boot on Geode LX CPUs.  (System otherwise is working OK.  Is this
> potentially due to the not-quite-686-compatibility of the Geode?  If so,
> how hard would it be for us to officially support Geode as the bottom
> end?)
[...]

Geode LX is a real 686 family processor.  The unchecked RDMSR is a
driver bug and it appears to be harmless (beside the error messages),
but should be fixed anyway.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
   A fail-safe circuit will destroy others.




signature.asc
Description: This is a digitally signed message part


Bug#971154: fever: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 github.com/DCSO/fever/cmd/fever github.com/DCSO/fever/cmd/fever/cmds github.com/DCSO/fever/db github.

2020-09-27 Thread Sascha Steinbiss
reassign 971154 golang-go
thanks


Hi Lucas,

Thanks for reporting this.

[…]
>> ok   github.com/DCSO/fever/input 15.229s
>> # github.com/DCSO/fever/processing [github.com/DCSO/fever/processing.test]
>> compile: loop

To me, this looks like a possible Go regression, though. The above seems to be 
an internal compiler message, and the tests finish fine in Go 1.14. I just 
confirmed that by running the tests from the upstream code (i.e. via my GOPATH) 
with these two golang-go versions in Debian. 1.15 fails, 1.14 succeeds. 
Unfortunately the Go 1.15 changelog does not mention any known problems in that 
direction… :/

Cheers
Sascha


signature.asc
Description: Message signed with OpenPGP


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

2020-09-27 Thread Bill Allombert
reassign 971203 dpkg-dev
severity grave
retitle dpkg-source cause gap-atlasrep to FTBFS
quit
On Sun, Sep 27, 2020 at 08:58:00PM +0200, Lucas Nussbaum wrote:
> Source: gap-atlasrep
> Version: 2.1.0-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.
> 
> > dpkg-source: error: pathname '/<>/debian/gaproot/pkg/AtlasRep' 
> > points outside source root (to '/<>')

Dear Dpkg developers,

$ apt-get source gap-atlasrep
Fetched 1351 kB in 2s (722 kB/s)
dpkg-source: info: extracting gap-atlasrep in gap-atlasrep-2.1.0
dpkg-source: info: unpacking gap-atlasrep_2.1.0.orig.tar.bz2
dpkg-source: info: unpacking gap-atlasrep_2.1.0-2.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying doc-makefile
dpkg-source: info: applying default-dir
dpkg-source: error: pathname
'gap-atlasrep-2.1.0/debian/gaproot/pkg/AtlasRep' points outside source
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.

Also I am concerned that developers might need to unpack old packages
with symlinks in them. There should be a way to do it, if only to fix
the packaging.

Cheers,
Bill



Bug#942884: RFS: zipios/2.2.5.0-1 -- small C++ library for reading zip files

2020-09-27 Thread François Mazen
Hello Tobias,

I've repacked the v2 of Zipios at salsa/debian/zipios repository. The
last package is uploaded at mentors:

https://mentors.debian.net/package/zipios++/

Could you please review and eventually sponsor the upload?

Thanks,
François



Bug#971238: Expose RPCNFSDOPTS in /etc/default/nfs-kernel-server

2020-09-27 Thread Mario Lang
Package: nfs-utils
Version: 1:1.3.4-4
Severity: wishlist
Tag: patch

The ability to pass extra options (like --rdma) to rpc.nfsd
is currently rather obscured.
Looking at /lib/systemd/scripts/nfs-utils_env.sh,
I see that RPCNFSDOPTS is being used.
However, there is no stub for it in /etc/default/nfs-kernel-server.

Since I was trying to enable RDMA,
mentioning that option as an example
seemed loke a good idea.

--- nfs-utils-1.3.4/debian/nfs-kernel-server.default.orig	2020-07-26 14:02:00.0 +0200
+++ nfs-utils-1.3.4/debian/nfs-kernel-server.default	2020-09-27 21:20:25.375657576 +0200
@@ -1,6 +1,10 @@
 # Number of servers to start up
 RPCNFSDCOUNT=8
 
+# Options for rpc.nfsd
+# To enable RDMA on the server, specify '--rdma' here
+RPCNFSDOPTS=""
+
 # Runtime priority of server (see nice(1))
 RPCNFSDPRIORITY=0
 

-- 
AR Mario Lang   Phone: +43 316 873 6897
Graz University of Technology  Mobile: +43 664 60 873 6897
IT-Services for research and teaching   Email: ml...@tugraz.at
Steyrergasse 30/1, 8010 Graz, Austria   Please https://useplaintext.email/


Bug#971239: grap.1: Some mistakes in the manual

2020-09-27 Thread Bjarni Ingi Gislason
Package: grap
Version: 1.45-3
Severity: minor

Dear Maintainer,

  Misspelled words:

comarisons

retore

  Trailing space:

There is a lot of instances of a space character at the end of a line.

  Other mistakes:

The warnings from "mandoc -T lint" should be fixed.

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

Kernel: Linux 5.8.7-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages grap depends on:
ii  libc6   2.31-3
ii  libgcc-s1   10.2.0-9
ii  libstdc++6  10.2.0-9

Versions of packages grap recommends:
ii  groff  1.22.4-5

grap suggests no packages.

-- no debconf information

-- 
Bjarni I. Gislason



Bug#971237: Additional info

2020-09-27 Thread Bruce Morgan
My hardware: Intel NUC10i7FNH1
card reader enabled in BIOS
uname: 4.19.0-11-amd64 #1 SMP Debian 4.19.146-1 (2020-09-17) x86_64
GNU/Linux
lspci -nn: 3b:00.0 SD Host controller [0805]: Genesys Logic, Inc Device
[17a0:9755]

I've seen this mentioned in 2 other cases:

"According to SD spec 3.00 3.6.1 signal voltage switch
procedure, host should wait 5ms after set 1.8V signal
enable bit in Host Control 2 register and check if 1.8V
is stable or not.
On some cards, found without the delay would see "1.8V
regulator output did not became stable" err log."

"For some reason the Host Control2 register of the Xenon SDHCI controller
sometimes reports the bit representing 1.8V signaling as 0 when read
after it was written as 1. Subsequent read reports 1.
This causes the sdhci_start_signal_voltage_switch function to report
1.8V regulator output did not become stable"



-- 
Bruce Morgan
blmor...@gmail.com


Bug#971112: gnome-builder: FTBFS: Package polkit-gobject-1 was not found in the pkg-config search path

2020-09-27 Thread Simon McVittie
Control: retitle -1 gnome-builder: FTBFS: Package polkit-gobject-1 was not 
found in the pkg-config search path

On Sun, 27 Sep 2020 at 20:31:29 +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):

The quoted part wasn't the relevant part. In a Meson build that fails
at the setup stage (analogous to ./configure), the quick version of the
error is quoted shortly before "A full log can be found at":

> Configuring phpize.plugin using configuration
> Configuring python-gi-imports-completion.plugin using configuration
> Configuring rustup.plugin using configuration
> Program glib-mkenums found: YES
> Program glib-mkenums found: YES
> Run-time dependency gspell-1 found: YES 1.8.4
> Run-time dependency enchant-2 found: YES 2.2.8
> Configuring stylelint.plugin using configuration
> Run-time dependency sysprof-4 found: NO
>
> ../src/plugins/sysprof/meson.build:3:0: ERROR: Could not generate cargs for 
> sysprof-4:
> Package polkit-gobject-1 was not found in the pkg-config search path.
> Perhaps you should add the directory containing `polkit-gobject-1.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'polkit-gobject-1', required by 'sysprof-4', not found
>
>
> A full log can be found at 
> /<>/obj-x86_64-linux-gnu/meson-logs/meson-log.txt
>   cd obj-x86_64-linux-gnu && tail -v -n \+0 meson-logs/meson-log.txt
> ==> meson-logs/meson-log.txt <==
> ...

and the fully comprehensive version (which in this case just says the same
thing in more words) will usually be the last thing in meson-log.txt.

smcv



Bug#958190: ausweisapp2: Fails to start because of missing dependency

2020-09-27 Thread BlaBlubber
Hi,

I had a similar issue / behaviour when starting AusweisApp2. Although
the cause was a little different in my case.
The reason mentioned here is

default2020.09.27 21:36:59.329 47262 W unknown(unknown:0)
 : QQmlApplicationEngine
failed to load component
default2020.09.27 21:36:59.330 47262 W unknown(unknown:0)
 :
qrc:/qml/+desktop/main.qml:171 Type ConfirmationPopup unavailable
qrc:/qml/Governikus/Global/ConfirmationPopup.qml:7 module
"QtQuick.Layouts" is not installed


Installing 'qml-module-qtquick-layouts' fixed this problem for me. Maybe
that package should be part of the dependencies as well.

Regards,

some pseudo anonymous person (mainly for spam porpouses)



Bug#971147: [Pkg-rust-maintainers] Bug#971147: rust-onig-sys: FTBFS: unsatisfiable build-dependencies: librust-cexpr-0.3+default-dev (>= 0.3.3-~~), librust-clang-sys-0.28+clang-6-0-dev, librust-clang-

2020-09-27 Thread Sylvestre Ledru

control: block -1 by 971139
control: block 971141 by -1

Le 27/09/2020 à 20:38, Lucas Nussbaum a écrit :

Source: rust-onig-sys
Version: 69.2.0-1
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.


Blocked by bindgen (in new)

S



Bug#971237: installation-reports: card reader gives 1.8V regulator output error

2020-09-27 Thread Bruce Morgan
Package: installation-reports
Severity: normal

Dear Maintainer,

New installation, error was immediate
dmesg: mmc0: Unknown controller version (5). You may experience problems
   mmc0: SDHCI controller on PCI [:02:00.0] using ADMA 64-bit
   mmc0: 1.8V regulator output did not become stable
when card is inserted: "1.8V regulator output did not became (sic) stable"


-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-11-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#971139: [Pkg-rust-maintainers] Bug#971139: rust-bindgen: FTBFS: unsatisfiable build-dependencies: librust-cexpr-0.3+default-dev (>= 0.3.3-~~), librust-clang-sys-0.28+clang-6-0-dev, librust-clang-s

2020-09-27 Thread Sylvestre Ledru

Control: tags -1 + fixed pending

Le 27/09/2020 à 20:37, Lucas Nussbaum a écrit :

Source: rust-bindgen
Version: 0.51.1-4
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.


Pending in NEW.

Cheers,
S




Bug#971121: perl6-readline: FTBFS: Could not find CompUnit::Repository::Staging

2020-09-27 Thread gregor herrmann
On Sun, 27 Sep 2020 20:36:26 +0200, Lucas Nussbaum wrote:

> Source: perl6-readline
> Version: 0.1.5-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.

> > Setting up rakudo (2020.08.2-1) ...
> >   rakudo-helper.pl: Reinstalling all perl6 modules ...
> > (1/1) reinstall: perl6-tap-harness
> > ===SORRY!=== Error while compiling 
> > /usr/share/perl6/tools/install-dist.p6
> > Could not find CompUnit::Repository::Staging in:
> > inst#/sbuild-nonexistent/.raku
> > inst#/usr/share/perl6/site
> > inst#/usr/share/perl6/vendor
> > inst#/usr/share/perl6/core
> > ap#
> > nqp#
> > perl5#
> > at /usr/share/perl6/tools/install-dist.p6:35

This is probably a duplicate of #969578 which was closed earlier today
(and of #971029 which could be merged/closed as well, I presume).

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Paco De Lucia, Al Di Meola, John Mc Laughlin: La Estiba


signature.asc
Description: Digital Signature


Bug#971203: gap-atlasrep: FTBFS: dpkg-source: error: pathname '/<>/debian/gaproot/pkg/AtlasRep' points outside source root (to '/<>')

2020-09-27 Thread Lucas Nussbaum
On 27/09/20 at 21:41 +0200, Bill Allombert wrote:
> On Sun, Sep 27, 2020 at 08:58:00PM +0200, Lucas Nussbaum wrote:
> > > gpgv: unknown type of key resource 'trustedkeys.kbx'
> > > gpgv: keyblock resource '/tmp/dpkg-verify-sig.DGPbPdCb/trustedkeys.kbx': 
> > > General error
> > > gpgv: Signature made Sat Apr  4 15:09:48 2020 UTC
> > > gpgv:using RSA key 
> > > 42028EA404A2E9D80AC453148F0E7C2B4522E387
> > > gpgv: Can't check signature: No public key
> > > dpkg-source: warning: failed to verify signature on 
> > > ./gap-atlasrep_2.1.0-2.dsc
> > > dpkg-source: info: extracting gap-atlasrep in /<>
> > > dpkg-source: info: unpacking gap-atlasrep_2.1.0.orig.tar.bz2
> > > dpkg-source: info: unpacking gap-atlasrep_2.1.0-2.debian.tar.xz
> > > dpkg-source: info: using patch list from debian/patches/series
> > > dpkg-source: info: applying doc-makefile
> > > dpkg-source: info: applying default-dir
> > > dpkg-source: error: pathname 
> > > '/<>/debian/gaproot/pkg/AtlasRep' points outside source root 
> > > (to '/<>')
> > > E: FAILED [dpkg-source died]
> 
> Hello Lucas,
> 
> I do not see why dpkg-source should cause a FTBFS.
> 
> This is a symlink that is never dereferenced, and /<> is
> not outside of /<>.
> 
> There is nothing that prevents debian/rules to create and uses such a
> symlink either.
> 
> Probably this should be reassigned to dpkg.

Hi,

There's another failure that is similar (ipywidgets, #971224), but that
other one looks more valid (pointing to '/usr/lib/nodejs/html2canvas').
No other package in the archive is affected.

Lucas



Bug#971203: gap-atlasrep: FTBFS: dpkg-source: error: pathname '/<>/debian/gaproot/pkg/AtlasRep' points outside source root (to '/<>')

2020-09-27 Thread Bill Allombert
On Sun, Sep 27, 2020 at 08:58:00PM +0200, Lucas Nussbaum wrote:
> > gpgv: unknown type of key resource 'trustedkeys.kbx'
> > gpgv: keyblock resource '/tmp/dpkg-verify-sig.DGPbPdCb/trustedkeys.kbx': 
> > General error
> > gpgv: Signature made Sat Apr  4 15:09:48 2020 UTC
> > gpgv:using RSA key 42028EA404A2E9D80AC453148F0E7C2B4522E387
> > gpgv: Can't check signature: No public key
> > dpkg-source: warning: failed to verify signature on 
> > ./gap-atlasrep_2.1.0-2.dsc
> > dpkg-source: info: extracting gap-atlasrep in /<>
> > dpkg-source: info: unpacking gap-atlasrep_2.1.0.orig.tar.bz2
> > dpkg-source: info: unpacking gap-atlasrep_2.1.0-2.debian.tar.xz
> > dpkg-source: info: using patch list from debian/patches/series
> > dpkg-source: info: applying doc-makefile
> > dpkg-source: info: applying default-dir
> > dpkg-source: error: pathname '/<>/debian/gaproot/pkg/AtlasRep' 
> > points outside source root (to '/<>')
> > E: FAILED [dpkg-source died]

Hello Lucas,

I do not see why dpkg-source should cause a FTBFS.

This is a symlink that is never dereferenced, and /<> is
not outside of /<>.

There is nothing that prevents debian/rules to create and uses such a
symlink either.

Probably this should be reassigned to dpkg.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



Bug#968052:

2020-09-27 Thread Chris Danis
I'd be happy to help with this package.  My employer, the Wikimedia
Foundation, depends on pmacct and is happy to support Debian and free
software in general.

I'm not sure if I can immediately sign up as maintainer -- I'm an
ex-DD, and while I've re-applied for project membership, for now I
would need someone to sponsor my uploads.  I'm interested in
doing the work, though.

I've also noticed that an Andy Davidson has forked the package on
Salsa and already started making improvements:

https://salsa.debian.org/andyd/pmacct

I'll try to get in touch with them.

-Chris



Bug#971118: dulwich: FTBFS: XXX

2020-09-27 Thread Lucas Nussbaum
retitle 971118 ERROR: test_send_remove_branch 
(dulwich.tests.compat.test_client.DulwichTCPClientTest)
thanks

Oops.



Bug#960423: unblock

2020-09-27 Thread Sudip Mukherjee
Control: unblock 943552 by -1
--

takari-polyglot-maven is needed to enable pomless tycho builds, so it
will be needed to enable that feature in tycho. I have now generated
the pom files manually for tracecompass, so its not blocking that
anymore.


-- 
Regards
Sudip



Bug#971236: src:r-cran-fs: fails to migrate to testing for too long: autopkgtest regression

2020-09-27 Thread Paul Gevers
Source: r-cran-fs
Version: 1.4.1+dfsg-1
Severity: serious
Control: close -1 1.4.2+dfsg-1
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:r-cran-fs 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=r-cran-fs




signature.asc
Description: OpenPGP digital signature


Bug#971235: src:r-cran-broom: fails to migrate to testing for too long: causes autopkgtest regression

2020-09-27 Thread Paul Gevers
Source: r-cran-broom
Version: 0.5.6+dfsg-2
Severity: serious
Control: close -1 0.7.0+dfsg-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 969494

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:r-cran-broom
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=r-cran-broom




signature.asc
Description: OpenPGP digital signature


Bug#971146: [Pkg-rust-maintainers] Bug#971146: rust-syntect: FTBFS: unsatisfiable build-dependencies: librust-onig-5+default-dev

2020-09-27 Thread Sylvestre Ledru

Hello Lucas,

Thanks for the bug reports!

FYI, many rust-* failures are caused by a bunch of packages blocked in NEW.

Cheers,
S


Le 27/09/2020 à 20:39, Lucas Nussbaum a écrit :

Source: rust-syntect
Version: 3.3.0-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):

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper (>= 11), dh-cargo (>= 18), cargo, rustc, 
libstd-rust-dev, librust-bincode-1+default-dev, librust-bitflags-1+default-dev, 
librust-flate2-1+default-dev, librust-fnv-1+default-dev, 
librust-lazy-static-1+default-dev, librust-lazycell-1+default-dev, 
librust-onig-5+default-dev, librust-plist-0.5+default-dev | 
librust-plist-0.4+default-dev, librust-regex-syntax-0.6+default-dev, 
librust-serde-1+default-dev, librust-serde-derive-1+default-dev, 
librust-serde-json-1+default-dev, librust-walkdir-2+default-dev, 
librust-yaml-rust-0.4+default-dev, build-essential, fakeroot
Filtered Build-Depends: debhelper (>= 11), dh-cargo (>= 18), cargo, rustc, 
libstd-rust-dev, librust-bincode-1+default-dev, librust-bitflags-1+default-dev, 
librust-flate2-1+default-dev, librust-fnv-1+default-dev, 
librust-lazy-static-1+default-dev, librust-lazycell-1+default-dev, 
librust-onig-5+default-dev, librust-plist-0.5+default-dev, 
librust-regex-syntax-0.6+default-dev, librust-serde-1+default-dev, 
librust-serde-derive-1+default-dev, librust-serde-json-1+default-dev, 
librust-walkdir-2+default-dev, librust-yaml-rust-0.4+default-dev, build-essential, 
fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [963 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [523 B]
Get:5 copy:/<>/apt_archive ./ Packages [588 B]
Fetched 2074 B in 0s (0 B/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
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:
  sbuild-build-depends-main-dummy : Depends: librust-onig-5+default-dev
Depends: librust-plist-0.5+default-dev but 
it is not installable
E: Unable to correct problems, you have held broken packages.
apt-get failed.

The full build log is available from:
http://qa-logs.debian.net/2020/09/26/rust-syntect_3.3.0-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

___
Pkg-rust-maintainers mailing list
pkg-rust-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers




Bug#971234: src:ruby-bson: fails to migrate to testing for too long: FTBFS on s390x

2020-09-27 Thread Paul Gevers
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


Bug#971233: src:r-cran-rstan: fails to migrate to testing for too long: autopkgtest regression and missing build on armel

2020-09-27 Thread Paul Gevers
Source: r-cran-rstan
Version: 2.19.3-1
Severity: serious
Control: close -1 2.21.2-1
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:r-cran-rstan
in its current version in unstable has been trying to migrate for 62
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=r-cran-rstan




signature.asc
Description: OpenPGP digital signature


Bug#971231: golang-github-sjoerdsimons-ostree-go: FTBFS: obj-x86_64-linux-gnu/src/github.com/sjoerdsimons/ostree-go/pkg/otadmin/admin.go:1:1: expected 'package', found 'EOF'

2020-09-27 Thread Lucas Nussbaum
Source: golang-github-sjoerdsimons-ostree-go
Version: 0.0~git20190304.5d29096-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
> obj-x86_64-linux-gnu/src/github.com/sjoerdsimons/ostree-go/pkg/otadmin/admin.go:1:1:
>  expected 'package', found 'EOF'
> obj-x86_64-linux-gnu/src/github.com/sjoerdsimons/ostree-go/pkg/otremote/remoteadd.go:1:1:
>  expected 'package', found 'EOF'
>   cd obj-x86_64-linux-gnu && go install -trimpath -v -p 4
> package .: no Go files in /<>/obj-x86_64-linux-gnu
> dh_auto_build: error: cd obj-x86_64-linux-gnu && go install -trimpath -v -p 4 
> returned exit code 1
> make: *** [debian/rules:4: build] Error 25

The full build log is available from:
   
http://qa-logs.debian.net/2020/09/26/golang-github-sjoerdsimons-ostree-go_0.0~git20190304.5d29096-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971232: src:grub2: fails to migrate to testing for too long: unresolved RC bug

2020-09-27 Thread Paul Gevers
Source: grub2
Version: 2.04-8
Severity: serious
Control: close -1 2.04-9
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 966575

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:grub2 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=grub2




signature.asc
Description: OpenPGP digital signature


Bug#645292: Fixed upstream

2020-09-27 Thread Charles Samuels
Fixed in libnet-cidr-perl 0.20:
https://github.com/svarshavchik/Net-CIDR/issues/1

Also resolves the problem in munin:
https://github.com/munin-monitoring/munin/issues/1177

Would the debian maintainer consider backporting the fix?



Bug#971230: haskell-gi-gdk: FTBFS: Unknown GIR element "docsection" when processing namespace "GLib", aborting.

2020-09-27 Thread Lucas Nussbaum
Source: haskell-gi-gdk
Version: 3.0.23-1
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):
> dpkg-buildpackage
> -
> 
> Command: dpkg-buildpackage -us -uc -sa -rfakeroot
> dpkg-buildpackage: info: source package haskell-gi-gdk
> dpkg-buildpackage: info: source version 3.0.23-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Ilias Tsitsimpis 
> 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  debian/rules clean
> test -x debian/rules
> dh_clean 
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> clean_recipe
> Running rm -rf dist dist-ghc dist-ghcjs dist-hugs debian/hlibrary.setup 
> Setup.hi Setup.ho Setup.o .\*config\*
> Running rm -f configure-ghc-stamp configure-ghcjs-stamp build-ghc-stamp 
> build-ghcjs-stamp build-hugs-stamp build-haddock-stamp
> Running rm -rf debian/tmp-inst-ghc debian/tmp-inst-ghcjs
> Running rm -f debian/extra-depends-ghc debian/extra-depends-ghcjs
> Running rm -f debian/hlibrary.Makefile
> Running rm -rf debian/dh_haskell_shlibdeps
> Running rm -rf debian/tmp-db
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building haskell-gi-gdk using existing 
> ./haskell-gi-gdk_3.0.23.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: building haskell-gi-gdk in 
> haskell-gi-gdk_3.0.23-1.debian.tar.xz
> dpkg-source: info: building haskell-gi-gdk in haskell-gi-gdk_3.0.23-1.dsc
>  debian/rules binary
> test -x debian/rules
> dh_testroot
> dh_prep 
> dh_installdirs -A 
> mkdir -p "."
> CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
> CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> make_setup_recipe
> Running ghc --make Setup.hs -o debian/hlibrary.setup
> [1 of 1] Compiling Main ( Setup.hs, Setup.o )
> Linking debian/hlibrary.setup ...
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> configure_recipe
> Running debian/hlibrary.setup configure --ghc -v2 
> --package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
> --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
> --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro 
> --haddockdir=/usr/lib/ghc-doc/haddock/gi-gdk-3.0.23/ --datasubdir=gi-gdk 
> --htmldir=/usr/share/doc/libghc-gi-gdk-doc/html/ --enable-library-profiling
> Using Parsec parser
> Unknown GIR element "docsection" when processing namespace "GLib", aborting.
> CallStack (from HasCallStack):
>   error, called at lib/Data/GI/CodeGen/API.hs:201:16 in 
> haskell-gi-0.24.4-GhfHY0VJtr89rHNQ5kPVxX:Data.GI.CodeGen.API
> make: *** [/usr/share/cdbs/1/class/hlibrary.mk:142: configure-ghc-stamp] 
> Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/haskell-gi-gdk_3.0.23-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971114: wordgrinder: FTBFS: src/c/arch/unix/cursesw/dpy.c:219:8: error: ‘KEY_EVENT’ undeclared (first use in this function); did you mean ‘KEY_SLEFT’?

2020-09-27 Thread David Given
It looks like ncurses has dropped KEY_EVENT:
https://invisible-island.net/ncurses/NEWS.html#index-t20200817

I'll fix this upstream and produce a new package --- it's about time anyway.

On Sun, 27 Sep 2020 at 20:51, Lucas Nussbaum  wrote:

> Source: wordgrinder
> Version: 0.7.2-1
> 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):
> > cc -MMD -MF .obj/lua-5.3-curses-release/src/c/arch/unix/cursesw/dpy.o.d
> -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -g -DVERSION='"0.7.2"' -DFILEFORMAT=7 -DNOUNCRYPT
> -DNOCRYPT -Isrc/c -Wall -Wno-unused-function -ffunction-sections
> -fdata-sections -Werror=implicit-function-declaration --std=gnu99
> -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -Os -I/usr/include/lua5.3
> -I/usr/include/lua5.3   -DARCH='"unix"' -D_XOPEN_SOURCE_EXTENDED
> -D_XOPEN_SOURCE -D_GNU_SOURCE -I/usr/include/minizip -c
> src/c/arch/unix/cursesw/dpy.c -o
> .obj/lua-5.3-curses-release/src/c/arch/unix/cursesw/dpy.o
> > : warning: "_XOPEN_SOURCE" redefined
> > : note: this is the location of the previous definition
> > src/c/arch/unix/cursesw/dpy.c: In function ‘dpy_getkeyname’:
> > src/c/arch/unix/cursesw/dpy.c:219:8: error: ‘KEY_EVENT’ undeclared
> (first use in this function); did you mean ‘KEY_SLEFT’?
> >   219 |   case KEY_EVENT: return "KEY_EVENT";
> >   |^
> >   |KEY_SLEFT
> > src/c/arch/unix/cursesw/dpy.c:219:8: note: each undeclared identifier is
> reported only once for each function it appears in
> > [14/82] cc -MMD -MF .obj/lua-5.3-curses-release/src/c/main.o.d
> -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -g -DVERSION='"0.7.2"' -DFILEFORMAT=7 -DNOUNCRYPT
> -DNOCRYPT -Isrc/c -Wall -Wno-unused-function -ffunction-sections
> -fdata-sections -Werror=implicit-function-declaration --std=gnu99
> -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -Os -I/usr/include/lua5.3
> -I/usr/include/lua5.3   -DARCH='"unix"' -D_XOPEN_SOURCE_EXTENDED
> -D_XOPEN_SOURCE -D_GNU_SOURCE -I/usr/include/minizip -c src/c/main.c -o
> .obj/lua-5.3-curses-release/src/c/main.o
> > : warning: "_XOPEN_SOURCE" redefined
> > : note: this is the location of the previous definition
> > [15/82] cc -MMD -MF .obj/lua-5.3-curses-release/src/c/lua.o.d
> -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -g -DVERSION='"0.7.2"' -DFILEFORMAT=7 -DNOUNCRYPT
> -DNOCRYPT -Isrc/c -Wall -Wno-unused-function -ffunction-sections
> -fdata-sections -Werror=implicit-function-declaration --std=gnu99
> -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -Os -I/usr/include/lua5.3
> -I/usr/include/lua5.3   -DARCH='"unix"' -D_XOPEN_SOURCE_EXTENDED
> -D_XOPEN_SOURCE -D_GNU_SOURCE -I/usr/include/minizip -c src/c/lua.c -o
> .obj/lua-5.3-curses-release/src/c/lua.o
> > : warning: "_XOPEN_SOURCE" redefined
> > : note: this is the location of the previous definition
> > [16/82] cc -MMD -MF .obj/lua-5.3-curses-release/src/c/screen.o.d
> -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -g -DVERSION='"0.7.2"' -DFILEFORMAT=7 -DNOUNCRYPT
> -DNOCRYPT -Isrc/c -Wall -Wno-unused-function -ffunction-sections
> -fdata-sections -Werror=implicit-function-declaration --std=gnu99
> -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -Os -I/usr/include/lua5.3
> -I/usr/include/lua5.3   -DARCH='"unix"' -D_XOPEN_SOURCE_EXTENDED
> -D_XOPEN_SOURCE -D_GNU_SOURCE -I/usr/include/minizip -c src/c/screen.c -o
> .obj/lua-5.3-curses-release/src/c/screen.o
> > : warning: "_XOPEN_SOURCE" redefined
> > : note: this is the location of the previous definition
> > [17/82] cc -MMD -MF .obj/lua-5.3-x11-release/.obj/luascripts.o.d
> -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -g -DVERSION='"0.7.2"' -DFILEFORMAT=7 -DNOUNCRYPT
> -DNOCRYPT -Isrc/c -Wall -Wno-unused-function -ffunction-sections
> -fdata-sections -Werror=implicit-function-declaration --std=gnu99
> -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/X11 -Os
> -I/usr/include/lua5.3 -I/usr/include/lua5.3   -DARCH='"unix"'
> -D_XOPEN_SOURCE_EXTENDED -D_XOPEN_SOURCE -D_GNU_SOURCE
> -I/usr/include/minizip -c .obj/luascripts.c -o
> .obj/lua-5.3-x11-release/.obj/luascripts.o
> > [18/82] cc -MMD -MF .obj/lua-5.3-curses-release/.obj/luascripts.o.d
> -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -g -DVERSION='"0.7.2"' -DFILEFORMAT=7 -DNOUNCRYPT
> -DNOCRYPT -Isrc/c -Wall -Wno-unused-function -ffunction-sections
> -fdata-sections -Werror=implicit-function-declaration --std=gnu99
> 

Bug#971226: pyqt-qwt: FTBFS: sip: Unable to find file "QtCore/QtCoremod.sip"

2020-09-27 Thread Lucas Nussbaum
Source: pyqt-qwt
Version: 1.02.00-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):
> make[1]: Entering directory '/<>'
> cp -a /usr/include/qwt header
> cp header/qwt_*.h header/qwt/
> set -e ;\
> for py in 3.8 ; do \
>   mkdir pybuild$py; \
>   cd pybuild$py  && ln -s ../sip .; \
>   QT_SELECT=qt5 python$py ../configure.py \
>   --qwt-incdir=../header/qwt \
>   --qwt-libdir=/usr/lib \
>   --qwt-lib=qwt-qt5 --verbose \
>   --no-dist-info; \
>   cd ..; \
> done
> Error: Unable to create the C++ code.
> /<>/header/qwt
> Configuring Qwt 6.1.2...
> Qwt 6.1.4 is being used.
> The Qwt .sip files will be installed in /usr/share/sip/PyQt5.
> Qwt will be installed in /usr/lib/python3/dist-packages/PyQt5.
> PyQt 5.15.1 is being used.
> Qt 5.14.2 is being used.
> sip 4.19.24 is being used.
> The sip executable is /usr/bin/sip.
> Qwt is being built with 'protected' redefined as 'public'.
> The PEP 484 stubs will be installed in /usr/lib/python3/dist-packages/PyQt5.
> Generating the C++ source for the Qwt module...
> /usr/bin/sip -n sip -n PyQt5.sip -t Qt_5_14_0 -t WS_X11 -B Qt_6_0_0 -I 
> /usr/share/sip/PyQt5 -y Qwt.pyi -P -o -c /<>/pybuild3.8/Qwt -I 
> sip sip/qwt.sip
> sip: Deprecation warning: the -B flag is deprecated
> sip: Unable to find file "QtCore/QtCoremod.sip"
> make[1]: *** [debian/rules:14: override_dh_auto_configure] Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/pyqt-qwt_1.02.00-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971224: ipywidgets: FTBFS: dpkg-source: error: pathname '/<>/debian/fakewebpack-unpacked/html2canvas' points outside source root (to '/usr/lib/nodejs/html2canvas')

2020-09-27 Thread Lucas Nussbaum
Source: ipywidgets
Version: 6.0.0-6
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):
> Unpack source
> -
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 3.0 (quilt)
> Source: ipywidgets
> Binary: python3-ipywidgets, python-ipywidgets-doc, 
> jupyter-nbextension-jupyter-js-widgets, python3-widgetsnbextension
> Architecture: all
> Version: 6.0.0-6
> Maintainer: Debian Python Modules Team 
> 
> Uploaders: Gordon Ball , Ximin Luo 
> 
> Homepage: https://github.com/jupyter-widgets/ipywidgets
> Standards-Version: 4.0.1
> Vcs-Browser: https://salsa.debian.org/python-team/modules/ipywidgets
> Vcs-Git: https://salsa.debian.org/python-team/modules/ipywidgets.git
> Build-Depends: debhelper-compat (= 10), dh-python, node-recast, libjs-jquery, 
> libjs-jquery-ui, node-backbone, node-d3-format (>= 1:1.4.1-1), 
> node-es6-promise (>= 4.2.8-4), node-semver (>= 6.3.0-1), node-typescript, 
> node-typescript-types (>= 20190926-1), node-underscore, patch, python3-all, 
> python3-pytest, python3-setuptools (>= 28), python3-coverage, 
> python3-ipython, python3-ipykernel, python3-jsonschema, python3-mock, 
> python3-nose, python3-traitlets, python3-sphinx, python3-sphinx-rtd-theme, 
> pandoc, m4
> Package-List:
>  jupyter-nbextension-jupyter-js-widgets deb python optional arch=all
>  python-ipywidgets-doc deb doc optional arch=all
>  python3-ipywidgets deb python optional arch=all
>  python3-widgetsnbextension deb python optional arch=all
> Checksums-Sha1:
>  92dd590dfa61bc912850e5fbba5d994292815c23 929535 ipywidgets_6.0.0.orig.tar.gz
>  48950c6d46899f23cb1188be58e36c34e5a00dad 132660 
> ipywidgets_6.0.0-6.debian.tar.xz
> Checksums-Sha256:
>  81b625ca68d1e6756d78c78756a320ea49e48912484f7c92ac499c66d844a8e8 929535 
> ipywidgets_6.0.0.orig.tar.gz
>  0e8f443594920779a5878d1f77f2a86b3cd62ef4cc85c1ae21606bfb3e9d0fcd 132660 
> ipywidgets_6.0.0-6.debian.tar.xz
> Files:
>  3082b6760be8c566d88bdf1c9fd94063 929535 ipywidgets_6.0.0.orig.tar.gz
>  91d77af4885ba95bc8eed1dd93878d1e 132660 ipywidgets_6.0.0-6.debian.tar.xz
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEE6PwpXIa418BJ+Xuno12v+60p6N4FAl335k8ACgkQo12v+60p
> 6N4YfxAAhHlh9UwVT+GiQ/ocBXsL1ZDwqWcWAV/YolwQY25ZaIZnnYTSw0A6Ju8A
> ceRxCfaHVJOOHJq7ssM0cFL+hvacD9OL2+j+f2kBjROjY9VCmuAl9IBbKujLMXQw
> /+/il++SARGhMbNENc9VEW6TC3/62joDrX1LiwleD5RlHGdItGecwDAft0QgnrVd
> YAZO8ZJ0qbLlQt1XL/G1aTvfnB19SBeRkDZXGeFAhRLNH426S7RWvX8krWneQxm0
> DMKRxUPDGLmEUdRwheKjvi/WxohgSxrRzXJHQYrAOGyDbUaSpvjOpxt5xKgRwHFw
> 9dHicaIfXd+HmrD7IRcmSlbM8pGAPh/LIJ4J4PFOV98/vQEmno6lAy9dp/FyQsMD
> eTHr0SXGp+eWyTe1TUF11XkVxNqLVgWxpBUoG53Y7Kuh0qW+DALjx9nHcGkRknUo
> gUZLPUz8b0AKY1TzYfsS6p5socOv1kHgddnMmPAoavMJ3GYAqY0cYyDwEQ6YDKLd
> S1ZVy1lRTB81QCcdQDAv3tT9Cyd51uXBo58eUe8NRKmIWoZiUtx9VNSENEb6IDm5
> OANMc7Rwh0VMHza4qkQBn4uxmaMdtAZU/VuMvMSwOMVbDaWYyGXufaRyFebEaZQK
> QRreDEyB1sMTqQS4QQ/hHrmLsp/8ca8LkDyLGzbNyn4DN9jpq/Q=
> =Xo+b
> -END PGP SIGNATURE-
> 
> gpgv: unknown type of key resource 'trustedkeys.kbx'
> gpgv: keyblock resource '/tmp/dpkg-verify-sig.34z_Wdmq/trustedkeys.kbx': 
> General error
> gpgv: Signature made Mon Dec 16 20:17:19 2019 UTC
> gpgv:using RSA key E8FC295C86B8D7C049F97BA7A35DAFFBAD29E8DE
> gpgv: Can't check signature: No public key
> dpkg-source: warning: failed to verify signature on ./ipywidgets_6.0.0-6.dsc
> dpkg-source: info: extracting ipywidgets in /<>
> dpkg-source: info: unpacking ipywidgets_6.0.0.orig.tar.gz
> dpkg-source: info: unpacking ipywidgets_6.0.0-6.debian.tar.xz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: applying 
> 0001-Unconditionally-import-setuptools-to-pick-up-depende.patch
> dpkg-source: info: applying 
> 0002-Don-t-build-extension.js-in-widgetsnbextension-setup.patch
> dpkg-source: info: applying 0003-Use-local-MathJax.patch
> dpkg-source: info: applying 
> 0004-Tweak-package.json-so-the-upstream-build-works-in-De.patch
> dpkg-source: info: applying 
> 0005-Import-specific-jupyterlab-service-types-so-we-only-.patch
> dpkg-source: info: applying 0006-tsconfig-es2015-iterable.patch
> dpkg-source: error: pathname 
> '/<>/debian/fakewebpack-unpacked/html2canvas' points outside 
> source root (to '/usr/lib/nodejs/html2canvas')
> E: FAILED [dpkg-source died]
> 
> +--+
> | Cleanup 
>  |
> +--+
> 
> Purging /<>
> Not cleaning session: cloned chroot in use
> E: FAILED [dpkg-source died]
> 
> +--+
> | Summary 
>  |
> 

Bug#971225: pyerfa: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 returned exit code 13

2020-09-27 Thread Lucas Nussbaum
Source: pyerfa
Version: 1.7.0+ds-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):
> === FAILURES 
> ===
> ___ TestVersion.test_version 
> ___
> 
> self = 
> 
> def test_version(self):
> assert hasattr(erfa, '__version__')
> version = erfa.__version__
> assert version is erfa.version.version
> # Oops, we had the wrong version for quite a while...
> >   assert (erfa.version.erfa_version == '1.6.0' and 
> > version.startswith('1.7.0')
> or version.startswith(erfa.version.erfa_version))
> E   AssertionError: assert (('1.7.1' == '1.6.0'
> E - 1.7.1
> E + 1.6.0) or False)
> E+  where False =  0x7fef2c703670>('1.7.1')
> E+where  0x7fef2c703670> = '1.7.0'.startswith
> E+and   '1.7.1' =  '/<>/.pybuild/cpython3_3.8_pyerfa/build/erfa/version.py'>.erfa_version
> E+  where  '/<>/.pybuild/cpython3_3.8_pyerfa/build/erfa/version.py'> = 
> erfa.version
> 
> erfa/tests/test_erfa.py:42: AssertionError
>  1 failed, 24 passed, 1 skipped in 0.56 seconds 
> 
> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd 
> /<>/.pybuild/cpython3_3.8_pyerfa/build; python3.8 -m pytest 
> dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 
> returned exit code 13

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/pyerfa_1.7.0+ds-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971221: golang-github-jesseduffield-go-getter: FTBFS: read /<>/obj-x86_64-linux-gnu/src/github.com/jesseduffield/go-getter/test-fixtures/detect-file-symlink-pwd/syml/pwd.s: read /<

2020-09-27 Thread Lucas Nussbaum
Source: golang-github-jesseduffield-go-getter
Version: 0.0~git20180822.906e156-3
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
> warning: ignoring symlink 
> /<>/obj-x86_64-linux-gnu/src/github.com/jesseduffield/go-getter/test-fixtures/detect-file-symlink-pwd/syml/pwd.s
> read 
> /<>/obj-x86_64-linux-gnu/src/github.com/jesseduffield/go-getter/test-fixtures/detect-file-symlink-pwd/syml/pwd.s:
>  read 
> /<>/obj-x86_64-linux-gnu/src/github.com/jesseduffield/go-getter/test-fixtures/detect-file-symlink-pwd/syml/pwd.s:
>  is a directory
>   cd obj-x86_64-linux-gnu && go install -trimpath -v -p 4
> package .: no Go files in /<>/obj-x86_64-linux-gnu
> dh_auto_build: error: cd obj-x86_64-linux-gnu && go install -trimpath -v -p 4 
> returned exit code 1
> make: *** [debian/rules:10: build] Error 25

The full build log is available from:
   
http://qa-logs.debian.net/2020/09/26/golang-github-jesseduffield-go-getter_0.0~git20180822.906e156-3_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971217: python-poppler-qt5: FTBFS: sip: Unable to find file "QtCore/QtCoremod.sip"

2020-09-27 Thread Lucas Nussbaum
Source: python-poppler-qt5
Version: 0.75.0-1
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):
> dpkg-buildpackage
> -
> 
> Command: dpkg-buildpackage -us -uc -sa -rfakeroot
> dpkg-buildpackage: info: source package python-poppler-qt5
> dpkg-buildpackage: info: source version 0.75.0-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Anthony Fok 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  debian/rules clean
> dh clean --with python3 --buildsystem=pybuild
>dh_auto_clean -O--buildsystem=pybuild
> I: pybuild base:217: python3.8 setup.py clean 
> running clean
> removing '/<>/.pybuild/cpython3_3.8_poppler-qt5/build' (and 
> everything under it)
> 'build/bdist.linux-x86_64' does not exist -- can't clean it
> 'build/scripts-3.8' does not exist -- can't clean it
>dh_autoreconf_clean -O--buildsystem=pybuild
>dh_clean -O--buildsystem=pybuild
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building python-poppler-qt5 using existing 
> ./python-poppler-qt5_0.75.0.orig.tar.gz
> dpkg-source: info: building python-poppler-qt5 in 
> python-poppler-qt5_0.75.0-1.debian.tar.xz
> dpkg-source: info: building python-poppler-qt5 in 
> python-poppler-qt5_0.75.0-1.dsc
>  debian/rules binary
> dh binary --with python3 --buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_autoreconf -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:217: python3.8 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:217: /usr/bin/python3 setup.py build 
> running build
> running build_ext
> building 'popplerqt5' extension
> /usr/bin/sip -I /usr/share/sip -t POPPLER_V0_74_0 -c 
> build/temp.linux-x86_64-3.8 -b build/temp.linux-x86_64-3.8/poppler-qt5.sbf -I 
> /usr/share/sip/PyQt5 -n PyQt5.sip -t Qt_5_14_0 -t WS_X11 poppler-qt5.sip
> sip: Unable to find file "QtCore/QtCoremod.sip"
> error: command '/usr/bin/sip' failed with exit status 1
> E: pybuild pybuild:352: build: plugin distutils failed with: exit code=1: 
> /usr/bin/python3 setup.py build 
> dh_auto_build: error: pybuild --build -i python{version} -p 3.8 returned exit 
> code 13
> make: *** [debian/rules:8: binary] Error 25

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/python-poppler-qt5_0.75.0-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971215: plplot: FTBFS: dh_install: error: missing files, aborting

2020-09-27 Thread Lucas Nussbaum
Source: plplot
Version: 5.15.0+dfsg-14
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):
> make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
> make[3]: Nothing to be done for 'preinstall'.
> make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> Install the project...
> /usr/bin/cmake -P cmake_install.cmake
> -- Install configuration: "None"
> -- Installing: 
> /<>/debian/tmp/usr/share/plplot5.15.0/examples/CTestCustom.cmake.in
> -- Installing: 
> /<>/debian/tmp/usr/share/plplot5.15.0/examples/CTestConfig.cmake
> -- Installing: /<>/debian/tmp/usr/share/doc/plplot/ABOUT
> -- Installing: /<>/debian/tmp/usr/share/doc/plplot/AUTHORS
> -- Installing: /<>/debian/tmp/usr/share/doc/plplot/COPYING.LIB
> -- Installing: 
> /<>/debian/tmp/usr/share/doc/plplot/ChangeLog.release
> -- Installing: /<>/debian/tmp/usr/share/doc/plplot/Copyright
> -- Installing: /<>/debian/tmp/usr/share/doc/plplot/FAQ
> -- Installing: /<>/debian/tmp/usr/share/doc/plplot/NEWS
> -- Installing: /<>/debian/tmp/usr/share/doc/plplot/PROBLEMS
> -- Installing: /<>/debian/tmp/usr/share/doc/plplot/README
> -- Installing: /<>/debian/tmp/usr/share/doc/plplot/README.release
> -- Installing: 
> /<>/debian/tmp/usr/share/doc/plplot/README.cumulated_release
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/plplot/plplotConfig.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/plplot/plplot_exports.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libcsirocsa.so.0.0.1
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libcsirocsa.so.0
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libcsirocsa.so
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/plplot/export_csirocsa.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/plplot/export_csirocsa-none.cmake
> -- Installing: /<>/debian/tmp/usr/share/doc/plplot/README.csa
> -- Installing: /<>/debian/tmp/usr/include/plplot/csa.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/csadll.h
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libcsironn.so.0.0.2
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libcsironn.so.0
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libcsironn.so
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/plplot/export_csironn.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/plplot/export_csironn-none.cmake
> -- Installing: /<>/debian/tmp/usr/share/doc/plplot/README.nn
> -- Installing: /<>/debian/tmp/usr/include/plplot/nn.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/nndll.h
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libqsastime.so.0.0.1
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libqsastime.so.0
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libqsastime.so
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/plplot/export_qsastime.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/plplot/export_qsastime-none.cmake
> -- Installing: /<>/debian/tmp/usr/include/plplot/qsastime.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/qsastimedll.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/disptab.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/drivers.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/pdf.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/pldebug.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/pldll.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/plevent.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/plplot.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/plplotP.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/plstrm.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/plxwd.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/plConfig.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/plDevs.h
> -- Installing: /<>/debian/tmp/usr/include/plplot/qt.h
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libplplot.so.17.0.0
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libplplot.so.17
> -- Set runtime path of 
> "/<>/debian/tmp/usr/lib/x86_64-linux-gnu/libplplot.so.17.0.0" to 
> ""
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/libplplot.so
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot-none.cmake
> -- Installing: 
> /<>/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig/plplot.pc
> -- Installing: /<>/debian/tmp/usr/share/plplot5.15.0/plstnd5.fnt
> -- Installing: /<>/debian/tmp/usr/share/plplot5.15.0/plxtnd5.fnt
> -- Installing: 
> /<>/debian/tmp/usr/share/plplot5.15.0/cmap0_default.pal
> -- Installing: 
> 

Bug#971228: sphinx-autoapi: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 returned exit code 13

2020-09-27 Thread Lucas Nussbaum
Source: sphinx-autoapi
Version: 1.3.0-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):
> dpkg-buildpackage
> -
> 
> Command: dpkg-buildpackage -us -uc -sa -rfakeroot
> dpkg-buildpackage: info: source package sphinx-autoapi
> dpkg-buildpackage: info: source version 1.3.0-2
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Andrej Shadura 
> 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  debian/rules clean
> dh clean --with python3,sphinxdoc --buildsystem=pybuild
>dh_auto_clean -O--buildsystem=pybuild
> I: pybuild base:217: python3.8 setup.py clean 
> running clean
> removing '/<>/.pybuild/cpython3_3.8_sphinx-autoapi/build' (and 
> everything under it)
> 'build/bdist.linux-x86_64' does not exist -- can't clean it
> 'build/scripts-3.8' does not exist -- can't clean it
>dh_autoreconf_clean -O--buildsystem=pybuild
>dh_clean -O--buildsystem=pybuild
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building sphinx-autoapi using existing 
> ./sphinx-autoapi_1.3.0.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: building sphinx-autoapi in 
> sphinx-autoapi_1.3.0-2.debian.tar.xz
> dpkg-source: info: building sphinx-autoapi in sphinx-autoapi_1.3.0-2.dsc
>  debian/rules binary
> dh binary --with python3,sphinxdoc --buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_autoreconf -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:217: python3.8 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:217: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi
> copying autoapi/inheritance_diagrams.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi
> copying autoapi/backends.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi
> copying autoapi/__init__.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi
> copying autoapi/extension.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi
> copying autoapi/documenters.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi
> copying autoapi/toctree.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi
> copying autoapi/directives.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi
> copying autoapi/settings.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi
> creating 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi/mappers
> copying autoapi/mappers/go.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi/mappers
> copying autoapi/mappers/__init__.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi/mappers
> copying autoapi/mappers/dotnet.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi/mappers
> copying autoapi/mappers/javascript.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi/mappers
> copying autoapi/mappers/base.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi/mappers
> creating 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi/mappers/python
> copying autoapi/mappers/python/__init__.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi/mappers/python
> copying autoapi/mappers/python/parser.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi/mappers/python
> copying autoapi/mappers/python/astroid_utils.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi/mappers/python
> copying autoapi/mappers/python/objects.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi/mappers/python
> copying autoapi/mappers/python/mapper.py -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi/mappers/python
> running egg_info
> creating sphinx_autoapi.egg-info
> writing sphinx_autoapi.egg-info/PKG-INFO
> writing dependency_links to sphinx_autoapi.egg-info/dependency_links.txt
> writing requirements to sphinx_autoapi.egg-info/requires.txt
> writing top-level names to sphinx_autoapi.egg-info/top_level.txt
> writing manifest file 'sphinx_autoapi.egg-info/SOURCES.txt'
> reading manifest file 'sphinx_autoapi.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no files found matching 'LICENSE.mit'
> writing manifest file 'sphinx_autoapi.egg-info/SOURCES.txt'
> creating 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi/templates
> copying autoapi/templates/index.rst -> 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi/templates
> creating 
> /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/autoapi/templates/base
> copying autoapi/templates/base/base.rst -> 
> 

Bug#971222: appstream-generator: FTBFS: dh_auto_configure: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localsta

2020-09-27 Thread Lucas Nussbaum
Source: appstream-generator
Version: 0.8.2-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):
> make[1]: Entering directory '/<>'
> dh_auto_configure -- --prefix=/usr --buildtype=plain -Ddownload-js=false
>   cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. 
> --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
> --localstatedir=/var --libdir=lib/x86_64-linux-gnu --prefix=/usr 
> --buildtype=plain -Ddownload-js=false
> The Meson build system
> Version: 0.55.3
> Source dir: /<>
> Build dir: /<>/obj-x86_64-linux-gnu
> Build type: native build
> Project name: AppStream Generator
> Project version: 0.8.2
> Using 'CFLAGS' from environment with value: '-g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
> Using 'CPPFLAGS' from environment with value: '-Wdate-time 
> -D_FORTIFY_SOURCE=2'
> Using 'DC' from environment with value: 'ldc2'
> Using 'DFLAGS' from environment with value: '-O -g -release -wi'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
> Using 'CFLAGS' from environment with value: '-g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
> Using 'CPPFLAGS' from environment with value: '-Wdate-time 
> -D_FORTIFY_SOURCE=2'
> Using 'DC' from environment with value: 'ldc2'
> Using 'DFLAGS' from environment with value: '-O -g -release -wi'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
> D compiler for the host machine: ldc2 (llvm 1.21.0 "LDC - the LLVM D compiler 
> (1.21.0):")
> D linker for the host machine: ldc2 ld.gold 2.35.1
> Host machine cpu family: x86_64
> Host machine cpu: x86_64
> Found pkg-config: /usr/bin/pkg-config (0.29.2)
> Run-time dependency glibd-2.0 found: YES 2.2.0
> Run-time dependency appstream found: YES 0.12.11
> Run-time dependency lmdb found: YES 0.9.24
> Run-time dependency libarchive found: YES 3.4.3
> Run-time dependency libsoup-2.4 found: YES 2.70.0
> Run-time dependency cairo found: YES 1.16.0
> Run-time dependency gdk-pixbuf-2.0 found: YES 2.40.0
> Run-time dependency librsvg-2.0 found: YES 2.48.8
> Run-time dependency freetype2 found: YES 23.2.17
> Run-time dependency pango found: YES 1.46.1
> Run-time dependency fontconfig found: YES 2.13.1
> Program girtod found: YES
> Message: Generating AppStream D interfaces from GIR...
> 
> ../meson.build:43:4: ERROR: Problem encountered: Unable to build D interfaces 
> from GIR:
> Error /usr/share/gir-1.0/GObject-2.0.gir(19729): Unexpected tag: docsection 
> in GirPackage: gobject
> 
> 
> A full log can be found at 
> /<>/obj-x86_64-linux-gnu/meson-logs/meson-log.txt
>   cd obj-x86_64-linux-gnu && tail -v -n \+0 meson-logs/meson-log.txt
> ==> meson-logs/meson-log.txt <==
> Build started at 2020-09-27T11:15:44.699093
> Main binary: /usr/bin/python3
> Build Options: -Ddownload-js=false -Dprefix=/usr 
> -Dlibdir=lib/x86_64-linux-gnu -Dlocalstatedir=/var -Dsysconfdir=/etc 
> -Dbuildtype=plain -Dwrap_mode=nodownload
> Python system: Linux
> The Meson build system
> Version: 0.55.3
> Source dir: /<>
> Build dir: /<>/obj-x86_64-linux-gnu
> Build type: native build
> None of 'PKG_CONFIG_PATH' are defined in the environment, not changing global 
> flags.
> None of 'PKG_CONFIG_PATH' are defined in the environment, not changing global 
> flags.
> Project name: AppStream Generator
> Project version: 0.8.2
> None of 'CC' are defined in the environment, not changing global flags.
> Using 'CFLAGS' from environment with value: '-g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
> Using 'CPPFLAGS' from environment with value: '-Wdate-time 
> -D_FORTIFY_SOURCE=2'
> None of 'CC_LD' are defined in the environment, not changing global flags.
> Using 'DC' from environment with value: 'ldc2'
> Using 'DFLAGS' from environment with value: '-O -g -release -wi'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
> None of 'DC_LD' are defined in the environment, not changing global flags.
> None of 'D_LD' are defined in the environment, not changing global flags.
> D compiler for the build machine: ldc2 (llvm 1.21.0 "LDC - the LLVM D 
> compiler (1.21.0):")
> D linker for the build machine: ldc2 ld.gold 2.35.1
> None of 'AR' are defined in the environment, not changing global flags.
> None of 'CC' are defined in the environment, not changing global flags.
> Using 'CFLAGS' from environment with value: '-g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
> Using 'CPPFLAGS' from environment with 

Bug#971220: dput-ng: FTBFS: /<>/dput/exceptions.py:docstring of dput.exceptions.NoSuchConfigError:1:duplicate object description of dput.exceptions.NoSuchConfigError, other instance in li

2020-09-27 Thread Lucas Nussbaum
Source: dput-ng
Version: 1.30
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):
> make[2]: Entering directory '/<>/docs'
> sphinx-build -b html -W -d _build/doctrees   . _build/html
> Running Sphinx v3.2.1
> making output directory... done
> building [mo]: targets for 0 po files that are out of date
> building [html]: targets for 36 source files that are out of date
> updating environment: [new config] 36 added, 0 changed, 0 removed
> reading sources... [  2%] index
> reading sources... [  5%] library/changes
> reading sources... [  8%] library/config
> reading sources... [ 11%] library/configs/dputcf
> reading sources... [ 13%] library/configs/dputng
> reading sources... [ 16%] library/configs/index
> reading sources... [ 19%] library/core
> reading sources... [ 22%] library/exceptions
> reading sources... [ 25%] library/hooks
> reading sources... [ 27%] library/hooks/checksum
> reading sources... [ 30%] library/hooks/deb
> reading sources... [ 33%] library/hooks/distribution
> reading sources... [ 36%] library/hooks/gpg
> reading sources... [ 38%] library/hooks/impatient
> reading sources... [ 41%] library/hooks/index
> reading sources... [ 44%] library/hooks/lintian
> reading sources... [ 47%] library/index
> reading sources... [ 50%] library/interface
> reading sources... [ 52%] library/interfaces/clinterface
> reading sources... [ 55%] library/interfaces/index
> reading sources... [ 58%] library/overrides
> reading sources... [ 61%] library/profile
> reading sources... [ 63%] library/uploader
> reading sources... [ 66%] library/uploaders/ftp
> reading sources... [ 69%] library/uploaders/http
> reading sources... [ 72%] library/uploaders/index
> reading sources... [ 75%] library/uploaders/local
> reading sources... [ 77%] library/uploaders/scp
> reading sources... [ 80%] library/uploaders/sftp
> reading sources... [ 83%] library/util
> reading sources... [ 86%] reference/configs
> reading sources... [ 88%] reference/contributing
> reading sources... [ 91%] reference/hookinstall
> reading sources... [ 94%] reference/hooks
> reading sources... [ 97%] reference/index
> reading sources... [100%] reference/migrating
> 
> 
> Warning, treated as error:
> /<>/dput/exceptions.py:docstring of 
> dput.exceptions.NoSuchConfigError:1:duplicate object description of 
> dput.exceptions.NoSuchConfigError, other instance in library/exceptions, use 
> :noindex: for one of them
> make[2]: *** [Makefile:45: html] Error 2

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/dput-ng_1.30_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971212: prometheus: FTBFS: dh_auto_test fails

2020-09-27 Thread Lucas Nussbaum
Source: prometheus
Version: 2.20.0+ds-1
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):
> === RUN   TestNewHTTPWithServerName
> 2020/09/27 11:19:57 http: TLS handshake error from 127.0.0.1:46428: remote 
> error: tls: bad certificate
> target_test.go:306: Get "https://127.0.0.1:41891": x509: certificate 
> relies on legacy Common Name field, use SANs or temporarily enable Common 
> Name matching with GODEBUG=x509ignoreCN=0
> --- FAIL: TestNewHTTPWithServerName (0.00s)

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/prometheus_2.20.0+ds-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971223: rust-redox-termios: FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101

2020-09-27 Thread Lucas Nussbaum
Source: rust-redox-termios
Version: 0.1.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):
> make[1]: Entering directory '/<>'
> export RUSTC_BOOTSTRAP=1; \
> case x86_64-unknown-linux-gnu in \
> arm-*|x86-*|x86_64-*) \
>   dh_auto_test;; \
> *) \
>   dh_auto_test || true;; \
> esac
> debian cargo wrapper: options, profiles, parallel: ['parallel=4'] [] ['-j4']
> debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, 
> x86_64-linux-gnu
> debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', 
> '/usr/bin/cargo', '-Zavoid-dev-deps', 'build', '--verbose', '--verbose', 
> '-j4', '--target', 'x86_64-unknown-linux-gnu'],) {}
>Compiling redox_syscall v0.1.40
>  Running `CARGO_PKG_VERSION=0.1.40 CARGO_PKG_VERSION_MAJOR=0 
> CARGO_MANIFEST_DIR=/<>/debian/cargo_registry/redox_syscall-0.1.40
>  CARGO_PKG_NAME=redox_syscall CARGO_PKG_HOMEPAGE= CARGO_PKG_AUTHORS='Jeremy 
> Soller ' 
> CARGO_PKG_REPOSITORY='https://github.com/redox-os/syscall' 
> CARGO_PKG_VERSION_PATCH=40 CARGO_PKG_VERSION_PRE= CARGO=/usr/bin/cargo 
> CARGO_PKG_DESCRIPTION='A Rust library to access raw Redox system calls' 
> CARGO_PKG_VERSION_MINOR=1 
> LD_LIBRARY_PATH='/<>/target/debug/deps:/usr/lib' rustc 
> --crate-name syscall 
> /<>/debian/cargo_registry/redox_syscall-0.1.40/src/lib.rs 
> --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type 
> lib --emit=dep-info,metadata,link -C debuginfo=2 -C metadata=29de329c21ef7345 
> -C extra-filename=-29de329c21ef7345 --out-dir 
> /<>/target/x86_64-unknown-linux-gnu/debug/deps --target 
> x86_64-unknown-linux-gnu -L 
> dependency=/<>/target/x86_64-unknown-linux-gnu/debug/deps -L 
> dependency=/<>/target/debug/deps --cap-lints warn -C debuginfo=2 
> --cap-lints warn -C linker=x86_64-linux-gnu-gcc -C link-arg=-Wl,-z,relro 
> --remap-path-prefix 
> /<>=/usr/share/cargo/registry/redox-termios-0.1.1`
> error: the legacy LLVM-style asm! syntax is no longer supported
>  --> 
> /usr/share/cargo/registry/redox-termios-0.1.1/debian/cargo_registry/redox_syscall-0.1.40/src/arch/x86_64.rs:4:5
>   |
> 4 |   asm!("int 0x80"
>   |   ^---
>   |   |
>   |  _help: replace with: `llvm_asm!`
>   | |
> 5 | | : "={rax}"(a)
> 6 | | : "{rax}"(a)
> 7 | | : "memory"
> 8 | | : "intel", "volatile");
>   | |___^
>   |
>   = note: consider migrating to the new asm! syntax specified in RFC 2873
>   = note: alternatively, switch to llvm_asm! to keep your code working as it 
> is
> 
> error: the legacy LLVM-style asm! syntax is no longer supported
>   --> 
> /usr/share/cargo/registry/redox-termios-0.1.1/debian/cargo_registry/redox_syscall-0.1.40/src/arch/x86_64.rs:14:5
>|
> 14 |   asm!("int 0x80"
>|   ^---
>|   |
>|  _help: replace with: `llvm_asm!`
>| |
> 15 | | : "={rax}"(a)
> 16 | | : "{rax}"(a), "{rbx}"(b)
> 17 | | : "memory"
> 18 | | : "intel", "volatile");
>| |___^
>|
>= note: consider migrating to the new asm! syntax specified in RFC 2873
>= note: alternatively, switch to llvm_asm! to keep your code working as it 
> is
> 
> error: the legacy LLVM-style asm! syntax is no longer supported
>   --> 
> /usr/share/cargo/registry/redox-termios-0.1.1/debian/cargo_registry/redox_syscall-0.1.40/src/arch/x86_64.rs:25:5
>|
> 25 |   asm!("int 0x80"
>|   ^---
>|   |
>|  _help: replace with: `llvm_asm!`
>| |
> 26 | | : "={rax}"(a)
> 27 | | : "{rax}"(a), "{rbx}"(b)
> 28 | | : "memory", "rbx", "rcx", "rdx", "rsi", "rdi", "r8",
> 29 | |   "r9", "r10", "r11", "r12", "r13", "r14", "r15"
> 30 | | : "intel", "volatile");
>| |___^
>|
>= note: consider migrating to the new asm! syntax specified in RFC 2873
>= note: alternatively, switch to llvm_asm! to keep your code working as it 
> is
> 
> error: the legacy LLVM-style asm! syntax is no longer supported
>   --> 
> /usr/share/cargo/registry/redox-termios-0.1.1/debian/cargo_registry/redox_syscall-0.1.40/src/arch/x86_64.rs:36:5
>|
> 36 |   asm!("int 0x80"
>|   ^---
>|   |
>|  _help: replace with: `llvm_asm!`
>| |
> 37 | | : "={rax}"(a)
> 38 | | : "{rax}"(a), "{rbx}"(b), "{rcx}"(c)
> 39 | | : "memory"
> 40 | | : "intel", "volatile");
>| |___^
>|
>= note: consider migrating to the new asm! syntax specified in RFC 2873
>= note: alternatively, switch to llvm_asm! to keep your code working as it 
> is
> 
> error: the legacy LLVM-style asm! syntax is no longer supported
>   --> 
> 

Bug#971218: jqueryui: FTBFS: Error: Cannot find module '/usr/lib/nodejs/requirejs/r.js'

2020-09-27 Thread Lucas Nussbaum
Source: jqueryui
Version: 1.12.1+dfsg-5
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):
> make[1]: Entering directory '/<>'
> cp debian/build.js build.js
> nodejs /usr/lib/nodejs/requirejs/r.js -o build.js
> internal/modules/cjs/loader.js:968
>   throw err;
>   ^
> 
> Error: Cannot find module '/usr/lib/nodejs/requirejs/r.js'
> at Function.Module._resolveFilename 
> (internal/modules/cjs/loader.js:965:15)
> at Function.Module._load (internal/modules/cjs/loader.js:841:27)
> at Function.executeUserEntryPoint [as runMain] 
> (internal/modules/run_main.js:71:12)
> at internal/main/run_main_module.js:17:47 {
>   code: 'MODULE_NOT_FOUND',
>   requireStack: []
> }
> make[1]: *** [debian/rules:28: jquery-ui.js] Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/jqueryui_1.12.1+dfsg-5_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971219: haskell-gi-vte: FTBFS: Unknown GIR element "docsection" when processing namespace "GLib", aborting.

2020-09-27 Thread Lucas Nussbaum
Source: haskell-gi-vte
Version: 2.91.27-1
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):
> dpkg-buildpackage
> -
> 
> Command: dpkg-buildpackage -us -uc -sa -rfakeroot
> dpkg-buildpackage: info: source package haskell-gi-vte
> dpkg-buildpackage: info: source version 2.91.27-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Ilias Tsitsimpis 
> 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  debian/rules clean
> test -x debian/rules
> dh_clean 
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> clean_recipe
> Running rm -rf dist dist-ghc dist-ghcjs dist-hugs debian/hlibrary.setup 
> Setup.hi Setup.ho Setup.o .\*config\*
> Running rm -f configure-ghc-stamp configure-ghcjs-stamp build-ghc-stamp 
> build-ghcjs-stamp build-hugs-stamp build-haddock-stamp
> Running rm -rf debian/tmp-inst-ghc debian/tmp-inst-ghcjs
> Running rm -f debian/extra-depends-ghc debian/extra-depends-ghcjs
> Running rm -f debian/hlibrary.Makefile
> Running rm -rf debian/dh_haskell_shlibdeps
> Running rm -rf debian/tmp-db
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building haskell-gi-vte using existing 
> ./haskell-gi-vte_2.91.27.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: building haskell-gi-vte in 
> haskell-gi-vte_2.91.27-1.debian.tar.xz
> dpkg-source: info: building haskell-gi-vte in haskell-gi-vte_2.91.27-1.dsc
>  debian/rules binary
> test -x debian/rules
> dh_testroot
> dh_prep 
> dh_installdirs -A 
> mkdir -p "."
> CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
> CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> make_setup_recipe
> Running ghc --make Setup.hs -o debian/hlibrary.setup
> [1 of 1] Compiling Main ( Setup.hs, Setup.o )
> Linking debian/hlibrary.setup ...
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> configure_recipe
> Running debian/hlibrary.setup configure --ghc -v2 
> --package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
> --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
> --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro 
> --haddockdir=/usr/lib/ghc-doc/haddock/gi-vte-2.91.27/ --datasubdir=gi-vte 
> --htmldir=/usr/share/doc/libghc-gi-vte-doc/html/ --enable-library-profiling
> Using Parsec parser
> Unknown GIR element "docsection" when processing namespace "GLib", aborting.
> CallStack (from HasCallStack):
>   error, called at lib/Data/GI/CodeGen/API.hs:201:16 in 
> haskell-gi-0.24.4-GhfHY0VJtr89rHNQ5kPVxX:Data.GI.CodeGen.API
> make: *** [/usr/share/cdbs/1/class/hlibrary.mk:142: configure-ghc-stamp] 
> Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/haskell-gi-vte_2.91.27-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971216: imagemagick: FTBFS: dh_doxygen: error: Doxygen documentation not found

2020-09-27 Thread Lucas Nussbaum
Source: imagemagick
Version: 8:6.9.11.24+dfsg-1
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):
> make[1]: Entering directory '/<>'
> # special source imagemagick-*-common
> dh_install --package=imagemagick-6-common
>   install -d debian/imagemagick-6-common//
>   cp --reflink=auto -a ./debian/tmp-indep/etc/ 
> debian/imagemagick-6-common///
>   install -d debian/imagemagick-6-common//usr/share/
>   cp --reflink=auto -a ./debian/tmp-indep/usr/share/ImageMagick-6 
> debian/imagemagick-6-common//usr/share//
>   install -d debian/imagemagick-6-common//usr/share/doc/
>   cp --reflink=auto -a 
> ./debian/prebuilt/usr/share/doc/imagemagick-6-common 
> debian/imagemagick-6-common//usr/share/doc//
> # remaining package
> dh_install --indep --remaining-packages --sourcedir=debian/tmp-indep 
> --autodest
>   install -d 
> debian/imagemagick-6-doc//usr/share/doc/imagemagick-6-common/html
>   cp --reflink=auto -a 
> debian/tmp-indep/usr/share/doc/imagemagick-6-common/html/images 
> debian/tmp-indep/usr/share/doc/imagemagick-6-common/html/index.html 
> debian/tmp-indep/usr/share/doc/imagemagick-6-common/html/www 
> debian/imagemagick-6-doc//usr/share/doc/imagemagick-6-common/html/
>   install -d debian/libmagickcore-6-headers//usr/include/ImageMagick-6
>   cp --reflink=auto -a debian/tmp-indep/usr/include/ImageMagick-6/magick 
> debian/libmagickcore-6-headers//usr/include/ImageMagick-6/
>   install -d debian/libmagickwand-6-headers//usr/include/ImageMagick-6
>   cp --reflink=auto -a debian/tmp-indep/usr/include/ImageMagick-6/wand 
> debian/libmagickwand-6-headers//usr/include/ImageMagick-6/
>   install -d debian/libmagick\+\+-6-headers//usr/include/ImageMagick-6
>   cp --reflink=auto -a 
> debian/tmp-indep/usr/include/ImageMagick-6/Magick\+\+ 
> debian/tmp-indep/usr/include/ImageMagick-6/Magick\+\+.h 
> debian/libmagick\+\+-6-headers//usr/include/ImageMagick-6/
>   cp --reflink=auto -a debian/tmp-indep/usr/share/perl5 
> debian/libimage-magick-perl//usr/share/
>   install -d debian/libimage-magick-perl//usr/share/man/man3
>   cp --reflink=auto -a 
> debian/tmp-indep/usr/share/man/man3/Image::Magick.3pm 
> debian/libimage-magick-perl//usr/share/man/man3/
> # fix doxygen problem
> ./debian/scripts/dh_doxygen --indep --package=imagemagick-6-doc
> dh_doxygen: error: Doxygen documentation not found
> make[1]: *** [debian/rules:722: override_dh_install-indep] Error 25

The full build log is available from:
   
http://qa-logs.debian.net/2020/09/26/imagemagick_6.9.11.24+dfsg-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971227: libjs-jquery-jstree: FTBFS: Error: Cannot find module '/usr/lib/nodejs/requirejs/r.js'

2020-09-27 Thread Lucas Nussbaum
Source: libjs-jquery-jstree
Version: 3.3.9+dfsg1-1
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):
> make[1]: Entering directory '/<>'
> cp debian/build.js build.js
> nodejs /usr/lib/nodejs/requirejs/r.js -o build.js
> internal/modules/cjs/loader.js:968
>   throw err;
>   ^
> 
> Error: Cannot find module '/usr/lib/nodejs/requirejs/r.js'
> at Function.Module._resolveFilename 
> (internal/modules/cjs/loader.js:965:15)
> at Function.Module._load (internal/modules/cjs/loader.js:841:27)
> at Function.executeUserEntryPoint [as runMain] 
> (internal/modules/run_main.js:71:12)
> at internal/main/run_main_module.js:17:47 {
>   code: 'MODULE_NOT_FOUND',
>   requireStack: []
> }
> make[1]: *** [debian/rules:14: dist/jstree.js] Error 1

The full build log is available from:
   
http://qa-logs.debian.net/2020/09/26/libjs-jquery-jstree_3.3.9+dfsg1-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971214: elpy: FTBFS: tests failed

2020-09-27 Thread Lucas Nussbaum
Source: elpy
Version: 1.34.0-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):
> make[1]: Entering directory '/<>'
> dh_auto_build
> I: pybuild base:217: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.8_elpy/build/elpy
> copying elpy/jedibackend.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy
> copying elpy/refactor.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy
> copying elpy/__init__.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy
> copying elpy/__main__.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy
> copying elpy/pydocutils.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy
> copying elpy/blackutil.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy
> copying elpy/yapfutil.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy
> copying elpy/compat.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy
> copying elpy/auto_pep8.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy
> copying elpy/rpc.py -> /<>/.pybuild/cpython3_3.8_elpy/build/elpy
> copying elpy/server.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy
> creating /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> copying elpy/tests/test_server.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> copying elpy/tests/test_rpc.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> copying elpy/tests/support.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> copying elpy/tests/test_yapf.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> copying elpy/tests/__init__.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> copying elpy/tests/test_pydocutils.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> copying elpy/tests/test_auto_pep8.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> copying elpy/tests/test_refactor.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> copying elpy/tests/test_jedibackend.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> copying elpy/tests/compat.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> copying elpy/tests/test_black.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> copying elpy/tests/test_support.py -> 
> /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests
> running egg_info
> creating elpy.egg-info
> writing elpy.egg-info/PKG-INFO
> writing dependency_links to elpy.egg-info/dependency_links.txt
> writing requirements to elpy.egg-info/requires.txt
> writing top-level names to elpy.egg-info/top_level.txt
> writing manifest file 'elpy.egg-info/SOURCES.txt'
> reading manifest file 'elpy.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> writing manifest file 'elpy.egg-info/SOURCES.txt'
> PYTHONPATH=. python3 -m sphinx -N -bman docs/ build/man
> Running Sphinx v3.2.1
> making output directory... done
> building [mo]: targets for 0 po files that are out of date
> building [man]: all manpages
> updating environment: [new config] 9 added, 0 changed, 0 removed
> reading sources... [ 11%] FAQ
> reading sources... [ 22%] concepts
> reading sources... [ 33%] customization_tips
> reading sources... [ 44%] editing
> reading sources... [ 55%] extending
> reading sources... [ 66%] ide
> reading sources... [ 77%] index
> reading sources... [ 88%] introduction
> reading sources... [100%] quickstart
> 
> /<>/docs/quickstart.rst:14: WARNING: duplicate description of 
> command elpy-shell-send-region-or-buffer, other instance in 
> /<>/docs/ide.rst
> /<>/docs/quickstart.rst:20: WARNING: duplicate description of 
> command elpy-shell-send-statement-and-step, other instance in 
> /<>/docs/ide.rst
> /<>/docs/quickstart.rst:26: WARNING: duplicate description of 
> command elpy-shell-switch-to-shell, other instance in 
> /<>/docs/ide.rst
> /<>/docs/quickstart.rst:31: WARNING: duplicate description of 
> command elpy-doc, other instance in /<>/docs/ide.rst
> looking for now-outdated files... none found
> pickling environment... done
> checking consistency... done
> writing... elpy.1 { introduction quickstart editing ide concepts extending 
> customization_tips FAQ } done
> build succeeded, 4 warnings.
> 
> The manual pages are in build/man.
> PYTHONPATH=. python3 -m sphinx -N -btexinfo docs/ build/info
> Running Sphinx v3.2.1
> making output directory... done
> building [mo]: targets for 0 po files that are out of date
> building [texinfo]: all documents
> updating environment: [new config] 9 added, 0 changed, 0 removed
> reading sources... [ 11%] FAQ
> reading sources... [ 22%] concepts
> reading sources... [ 33%] customization_tips
> reading sources... [ 44%] editing
> reading sources... [ 55%] extending
> reading sources... [ 66%] ide
> reading sources... [ 77%] index
> reading sources... [ 88%] introduction
> reading sources... [100%] quickstart
> 
> /<>/docs/quickstart.rst:14: WARNING: duplicate 

Bug#971210: libcoverart: FTBFS: make[5]: *** No rule to make target 'src/*.inc', needed by 'src/caa_c.cc'. Stop.

2020-09-27 Thread Lucas Nussbaum
Source: libcoverart
Version: 1.0.0+git20150706-8
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):
> make[5]: Entering directory '/<>/obj-x86_64-linux-gnu'
> cd /<>/obj-x86_64-linux-gnu && /usr/bin/cmake -E cmake_depends 
> "Unix Makefiles" /<> /<>/src 
> /<>/obj-x86_64-linux-gnu 
> /<>/obj-x86_64-linux-gnu/src 
> /<>/obj-x86_64-linux-gnu/src/CMakeFiles/src_gen.dir/DependInfo.cmake
>  --color=
> Scanning dependencies of target src_gen
> make[5]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> make  -f src/CMakeFiles/src_gen.dir/build.make 
> src/CMakeFiles/src_gen.dir/build
> make[5]: Entering directory '/<>/obj-x86_64-linux-gnu'
> make[5]: *** No rule to make target 'src/*.inc', needed by 'src/caa_c.cc'.  
> Stop.
> make[5]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> make[4]: *** [CMakeFiles/Makefile2:251: src/CMakeFiles/src_gen.dir/all] Error 
> 2

The full build log is available from:
   
http://qa-logs.debian.net/2020/09/26/libcoverart_1.0.0+git20150706-8_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971205: netkit-ntalk: FTBFS: dh_auto_configure: error: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTA

2020-09-27 Thread Lucas Nussbaum
Source: netkit-ntalk
Version: 0.17-16
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=cmake
>dh_update_autotools_config -O--buildsystem=cmake
>dh_autoreconf -O--buildsystem=cmake
>dh_auto_configure -O--buildsystem=cmake
>   cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
> -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
> -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
> -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON "-GUnix Makefiles" 
> -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu ..
> -- The C compiler identification is GNU 10.2.0
> -- The CXX compiler identification is GNU 10.2.0
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++ - skipped
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> CMake Error at CMakeLists.txt:10 (find_library):
>   Could not find NCURSES using the following names: lncurses
> 
> 
> -- Configuring incomplete, errors occurred!
> See also "/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeOutput.log".
>   cd obj-x86_64-linux-gnu && tail -v -n \+0 CMakeCache.txt
> ==> CMakeCache.txt <==
> # This is the CMakeCache file.
> # For build in directory: /<>/obj-x86_64-linux-gnu
> # It was generated by CMake: /usr/bin/cmake
> # You can edit this file to change values found and used by cmake.
> # If you do not want to change any of the values, simply exit the editor.
> # If you do want to change a value, simply edit, save, and exit the editor.
> # The syntax for the file is as follows:
> # KEY:TYPE=VALUE
> # KEY is the name of a variable in the cache.
> # TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!.
> # VALUE is the current value for the KEY.
> 
> 
> # EXTERNAL cache entries
> 
> 
> //Path to a program.
> CMAKE_ADDR2LINE:FILEPATH=/usr/bin/addr2line
> 
> //Path to a program.
> CMAKE_AR:FILEPATH=/usr/bin/ar
> 
> //Choose the type of build, options are: None Debug Release RelWithDebInfo
> // MinSizeRel ...
> CMAKE_BUILD_TYPE:STRING=None
> 
> //Enable/Disable color output during build.
> CMAKE_COLOR_MAKEFILE:BOOL=ON
> 
> //CXX compiler
> CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++
> 
> //A wrapper around 'ar' adding the appropriate '--plugin' option
> // for the GCC compiler
> CMAKE_CXX_COMPILER_AR:FILEPATH=/usr/bin/gcc-ar-10
> 
> //A wrapper around 'ranlib' adding the appropriate '--plugin' option
> // for the GCC compiler
> CMAKE_CXX_COMPILER_RANLIB:FILEPATH=/usr/bin/gcc-ranlib-10
> 
> //Flags used by the CXX compiler during all build types.
> CMAKE_CXX_FLAGS:STRING=-g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2
> 
> //Flags used by the CXX compiler during DEBUG builds.
> CMAKE_CXX_FLAGS_DEBUG:STRING=-g
> 
> //Flags used by the CXX compiler during MINSIZEREL builds.
> CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
> 
> //Flags used by the CXX compiler during NONE builds.
> CMAKE_CXX_FLAGS_NONE:STRING=
> 
> //Flags used by the CXX compiler during RELEASE builds.
> CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
> 
> //Flags used by the CXX compiler during RELWITHDEBINFO builds.
> CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
> 
> //C compiler
> CMAKE_C_COMPILER:FILEPATH=/usr/bin/cc
> 
> //A wrapper around 'ar' adding the appropriate '--plugin' option
> // for the GCC compiler
> CMAKE_C_COMPILER_AR:FILEPATH=/usr/bin/gcc-ar-10
> 
> //A wrapper around 'ranlib' adding the appropriate '--plugin' option
> // for the GCC compiler
> CMAKE_C_COMPILER_RANLIB:FILEPATH=/usr/bin/gcc-ranlib-10
> 
> //Flags used by the C compiler during all build types.
> CMAKE_C_FLAGS:STRING=-g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2
> 
> //Flags used by the C compiler during DEBUG builds.
> CMAKE_C_FLAGS_DEBUG:STRING=-g
> 
> //Flags used by the C compiler during MINSIZEREL builds.
> CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
> 
> //Flags used by the C compiler during NONE builds.
> CMAKE_C_FLAGS_NONE:STRING=
> 
> //Flags used by the C compiler during RELEASE builds.
> CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
> 
> //Flags used by the C compiler during RELWITHDEBINFO builds.
> CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
> 
> //Path to a program.
> CMAKE_DLLTOOL:FILEPATH=CMAKE_DLLTOOL-NOTFOUND
> 
> //Flags used by the linker during all build types.
> 

Bug#971201: mongo-c-driver: FTBFS: Could not import extension taglist (exception: cannot import name 'NoUri' from 'sphinx.environment' (/usr/lib/python3/dist-packages/sphinx/environment/__init__.py))

2020-09-27 Thread Lucas Nussbaum
Source: mongo-c-driver
Version: 1.17.0-1
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):
> make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
> [  1%] Building manual pages with Sphinx
> cd /<>/obj-x86_64-linux-gnu/src/libmongoc/doc && /usr/bin/cmake 
> -E env PYTHONDONTWRITEBYTECODE=1 /usr/bin/sphinx-build -qEW -b man -c 
> /<>/src/libmongoc/doc /<>/src/libmongoc/doc 
> /<>/obj-x86_64-linux-gnu/src/libmongoc/doc/man
> 
> Extension error:
> Could not import extension taglist (exception: cannot import name 'NoUri' 
> from 'sphinx.environment' 
> (/usr/lib/python3/dist-packages/sphinx/environment/__init__.py))
> 
> Extension error:
> Could not import extension taglist (exception: cannot import name 'NoUri' 
> from 'sphinx.environment' 
> (/usr/lib/python3/dist-packages/sphinx/environment/__init__.py))
> 
> Extension error:
> Could not import extension taglist (exception: cannot import name 'NoUri' 
> from 'sphinx.environment' 
> (/usr/lib/python3/dist-packages/sphinx/environment/__init__.py))
> 
> Extension error:
> Could not import extension taglist (exception: cannot import name 'NoUri' 
> from 'sphinx.environment' 
> (/usr/lib/python3/dist-packages/sphinx/environment/__init__.py))
> make[3]: *** [src/libbson/doc/CMakeFiles/bson-html.dir/build.make:551: 
> src/libbson/doc/html/api.html] Error 2

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/mongo-c-driver_1.17.0-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971207: rust-inotify-sys: FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo test --all returned exit code 1

2020-09-27 Thread Lucas Nussbaum
Source: rust-inotify-sys
Version: 0.1.3-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):
> make[1]: Entering directory '/<>'
> dh_auto_test -- test --all
> debian cargo wrapper: options, profiles, parallel: ['parallel=4'] [] ['-j4']
> debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, 
> x86_64-linux-gnu
> debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', 
> '/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose', '--verbose', 
> '-j4', '--target', 'x86_64-unknown-linux-gnu', '--all'],) {}
>Compiling libc v0.2.73
>  Running `CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_NAME=libc 
> CARGO_PKG_VERSION=0.2.73 
> CARGO_MANIFEST_DIR=/<>/debian/cargo_registry/libc-0.2.73 
> CARGO_PKG_VERSION_PRE= CARGO_PKG_VERSION_MINOR=2 CARGO_PKG_DESCRIPTION='Raw 
> FFI bindings to platform libraries like libc.
> ' CARGO_PKG_AUTHORS='The Rust Project Developers' CARGO_PKG_VERSION_PATCH=73 
> CARGO_PKG_HOMEPAGE='https://github.com/rust-lang/libc' 
> CARGO_PKG_REPOSITORY='https://github.com/rust-lang/libc' 
> LD_LIBRARY_PATH='/<>/target/debug/deps:/usr/lib' 
> CARGO=/usr/bin/cargo rustc --crate-name build_script_build 
> /<>/debian/cargo_registry/libc-0.2.73/build.rs 
> --error-format=json --json=diagnostic-rendered-ansi --crate-type bin 
> --emit=dep-info,link -C debuginfo=2 --cfg 'feature="default"' --cfg 
> 'feature="std"' -C metadata=fddeaec4f01175a7 -C 
> extra-filename=-fddeaec4f01175a7 --out-dir 
> /<>/target/debug/build/libc-fddeaec4f01175a7 -L 
> dependency=/<>/target/debug/deps --cap-lints warn`
>  Running 
> `/<>/target/debug/build/libc-fddeaec4f01175a7/build-script-build`
> [libc 0.2.73] cargo:rustc-cfg=freebsd11
> [libc 0.2.73] cargo:rustc-cfg=libc_priv_mod_use
> [libc 0.2.73] cargo:rustc-cfg=libc_union
> [libc 0.2.73] cargo:rustc-cfg=libc_const_size_of
> [libc 0.2.73] cargo:rustc-cfg=libc_align
> [libc 0.2.73] cargo:rustc-cfg=libc_core_cvoid
> [libc 0.2.73] cargo:rustc-cfg=libc_packedN
>  Running `CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_NAME=libc 
> CARGO_PKG_VERSION=0.2.73 
> CARGO_MANIFEST_DIR=/<>/debian/cargo_registry/libc-0.2.73 
> CARGO_PKG_VERSION_PRE= CARGO_PKG_VERSION_MINOR=2 CARGO_PKG_DESCRIPTION='Raw 
> FFI bindings to platform libraries like libc.
> ' CARGO_PKG_AUTHORS='The Rust Project Developers' 
> OUT_DIR=/<>/target/x86_64-unknown-linux-gnu/debug/build/libc-13f2b82d2a1fa182/out
>  CARGO_PKG_VERSION_PATCH=73 
> CARGO_PKG_HOMEPAGE='https://github.com/rust-lang/libc' 
> CARGO_PKG_REPOSITORY='https://github.com/rust-lang/libc' 
> LD_LIBRARY_PATH='/<>/target/debug/deps:/usr/lib' 
> CARGO=/usr/bin/cargo rustc --crate-name libc 
> /<>/debian/cargo_registry/libc-0.2.73/src/lib.rs 
> --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type 
> lib --emit=dep-info,metadata,link -C debuginfo=2 --cfg 'feature="default"' 
> --cfg 'feature="std"' -C metadata=75af03d4f216d925 -C 
> extra-filename=-75af03d4f216d925 --out-dir 
> /<>/target/x86_64-unknown-linux-gnu/debug/deps --target 
> x86_64-unknown-linux-gnu -L 
> dependency=/<>/target/x86_64-unknown-linux-gnu/debug/deps -L 
> dependency=/<>/target/debug/deps --cap-lints warn -C debuginfo=2 
> --cap-lints warn -C linker=x86_64-linux-gnu-gcc -C link-arg=-Wl,-z,relro 
> --remap-path-prefix 
> /<>=/usr/share/cargo/registry/inotify-sys-0.1.3 --cfg freebsd11 
> --cfg libc_priv_mod_use --cfg libc_union --cfg libc_const_size_of --cfg 
> libc_align --cfg libc_core_cvoid --cfg libc_packedN`
>Compiling inotify-sys v0.1.3 (/<>)
>  Running `CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_NAME=inotify-sys 
> CARGO_PKG_VERSION=0.1.3 CARGO_MANIFEST_DIR=/<> 
> CARGO_PKG_VERSION_PRE= CARGO_PKG_VERSION_MINOR=1 
> CARGO_PKG_DESCRIPTION='inotify bindings for the Rust programming language' 
> CARGO_PKG_AUTHORS='Hanno Braun ' 
> CARGO_PKG_VERSION_PATCH=3 CARGO_PKG_HOMEPAGE= 
> CARGO_PKG_REPOSITORY='https://github.com/inotify-rs/inotify-sys' 
> LD_LIBRARY_PATH='/<>/target/debug/deps:/usr/lib' 
> CARGO=/usr/bin/cargo rustc --crate-name inotify_sys src/lib.rs 
> --error-format=json --json=diagnostic-rendered-ansi --crate-type lib 
> --emit=dep-info,metadata,link -C debuginfo=2 -C metadata=16232beadc0ec397 -C 
> extra-filename=-16232beadc0ec397 --out-dir 
> /<>/target/x86_64-unknown-linux-gnu/debug/deps --target 
> x86_64-unknown-linux-gnu -C 
> incremental=/<>/target/x86_64-unknown-linux-gnu/debug/incremental
>  -L dependency=/<>/target/x86_64-unknown-linux-gnu/debug/deps -L 
> dependency=/<>/target/debug/deps --extern 
> libc=/<>/target/x86_64-unknown-linux-gnu/debug/deps/liblibc-75af03d4f216d925.rmeta
>  -C debuginfo=2 --cap-lints warn -C linker=x86_64-linux-gnu-gcc -C 
> link-arg=-Wl,-z,relro --remap-path-prefix 
> /<>=/usr/share/cargo/registry/inotify-sys-0.1.3`
> warning: unnecessary parentheses around assigned value
>--> src/lib.rs:308:31
> |

Bug#971206: haskell-snap-templates: FTBFS: die', called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:1022:20 in Cabal-3.0.1.0:Distribution.Simple.Configure

2020-09-27 Thread Lucas Nussbaum
Source: haskell-snap-templates
Version: 1.0.0.2-3
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):
> dpkg-buildpackage
> -
> 
> Command: dpkg-buildpackage -us -uc -sa -rfakeroot
> dpkg-buildpackage: info: source package haskell-snap-templates
> dpkg-buildpackage: info: source version 1.0.0.2-3
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Gianfranco Costamagna 
> 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  debian/rules clean
> test -x debian/rules
> dh_clean 
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> clean_recipe
> Running rm -rf dist dist-ghc dist-ghcjs dist-hugs debian/hlibrary.setup 
> Setup.hi Setup.ho Setup.o .\*config\*
> Running rm -f configure-ghc-stamp configure-ghcjs-stamp build-ghc-stamp 
> build-ghcjs-stamp build-hugs-stamp build-haddock-stamp
> Running rm -rf debian/tmp-inst-ghc debian/tmp-inst-ghcjs
> Running rm -f debian/extra-depends-ghc debian/extra-depends-ghcjs
> Running rm -f debian/hlibrary.Makefile
> Running rm -rf debian/dh_haskell_shlibdeps
> Running rm -rf debian/tmp-db
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building haskell-snap-templates using existing 
> ./haskell-snap-templates_1.0.0.2.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: building haskell-snap-templates in 
> haskell-snap-templates_1.0.0.2-3.debian.tar.xz
> dpkg-source: info: building haskell-snap-templates in 
> haskell-snap-templates_1.0.0.2-3.dsc
>  debian/rules binary
> test -x debian/rules
> dh_testroot
> dh_prep 
> dh_installdirs -A 
> mkdir -p "."
> CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
> CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> make_setup_recipe
> Running ghc --make Setup.hs -o debian/hlibrary.setup
> [1 of 1] Compiling Main ( Setup.hs, Setup.o )
> Linking debian/hlibrary.setup ...
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> configure_recipe
> Running debian/hlibrary.setup configure --ghc -v2 
> --package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
> --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
> --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro 
> --haddockdir=/usr/lib/ghc-doc/haddock/snap-templates-1.0.0.2/ 
> --datasubdir=snap-templates 
> --htmldir=/usr/share/doc/libghc-snap-templates-doc/html/
> Using Parsec parser
> Configuring snap-templates-1.0.0.2...
> CallStack (from HasCallStack):
>   die', called at 
> libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:1022:20 in 
> Cabal-3.0.1.0:Distribution.Simple.Configure
>   configureFinalizedPackage, called at 
> libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:475:12 in 
> Cabal-3.0.1.0:Distribution.Simple.Configure
>   configure, called at libraries/Cabal/Cabal/Distribution/Simple.hs:625:20 in 
> Cabal-3.0.1.0:Distribution.Simple
>   confHook, called at 
> libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:65:5 in 
> Cabal-3.0.1.0:Distribution.Simple.UserHooks
>   configureAction, called at 
> libraries/Cabal/Cabal/Distribution/Simple.hs:180:19 in 
> Cabal-3.0.1.0:Distribution.Simple
>   defaultMainHelper, called at 
> libraries/Cabal/Cabal/Distribution/Simple.hs:116:27 in 
> Cabal-3.0.1.0:Distribution.Simple
>   defaultMain, called at Setup.hs:3:8 in main:Main
> hlibrary.setup: Encountered missing or private dependencies:
> hashable ==1.1.* || >=1.2.0.6 && <1.3,
> template-haskell >=2.2 && <2.15
> 
> make: *** [/usr/share/cdbs/1/class/hlibrary.mk:142: configure-ghc-stamp] 
> Error 1

The full build log is available from:
   
http://qa-logs.debian.net/2020/09/26/haskell-snap-templates_1.0.0.2-3_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971204: onnx: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below

2020-09-27 Thread Lucas Nussbaum
Source: onnx
Version: 1.7.0+dfsg-1
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):
> make[1]: Entering directory '/<>'
> dh_missing --fail-missing
> make[1]: Leaving directory '/<>'
>dh_dwz -O-Spybuild
>dh_strip -O-Spybuild
>dh_makeshlibs -O-Spybuild
> 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/libonnx1/DEBIAN/symbols doesn't match 
> completely debian/libonnx1.symbols.amd64
> --- debian/libonnx1.symbols.amd64 (libonnx1_1.7.0+dfsg-1_amd64)
> +++ dpkg-gensymbolsmoGBDk 2020-09-27 11:07:10.622636058 +
> @@ -101,8 +101,9 @@
>   
> _ZN4onnx10MakeStringIJA23_cA92_cEEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEDpRKT_@Base
>  1.7.0+dfsg
>   
> _ZN4onnx10MakeStringIJA23_cNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEA13_ciA34_ciEEES7_DpRKT_@Base
>  1.6.0+dfsg
>   
> _ZN4onnx10MakeStringIJA23_cS1_EEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEDpRKT_@Base
>  1.7.0+dfsg
> - 
> _ZN4onnx10MakeStringIJA31_cNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEA2_cEEES7_DpRKT_@Base
>  1.6.0+dfsg
> +#MISSING: 1.7.0+dfsg-1# 
> _ZN4onnx10MakeStringIJA31_cNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEA2_cEEES7_DpRKT_@Base
>  1.6.0+dfsg
>   
> _ZN4onnx10MakeStringIJA49_cNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEA2_cEEES7_DpRKT_@Base
>  1.6.0+dfsg
> + 
> _ZN4onnx10MakeStringIJA7_cNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEA18_ciA20_ciS1_iA3_cEEES7_DpRKT_@Base
>  1.7.0+dfsg-1
>   
> _ZN4onnx10MakeStringIJA8_cA10_cA6_cA5_cA26_cEEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEDpRKT_@Base
>  1.6.0+dfsg
>   
> _ZN4onnx10MakeStringIJA8_cA6_cS2_A5_cA26_cEEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEDpRKT_@Base
>  1.6.0+dfsg
>   
> _ZN4onnx10MakeStringIJNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEA23_cS6_EEES6_DpRKT_@Base
>  1.7.0+dfsg
> @@ -432,6 +433,7 @@
>   
> _ZN4onnx11GetOpSchemaINS_36NegativeLogLikelihoodLoss_Onnx_ver12EEENS_8OpSchemaEv@Base
>  1.7.0+dfsg
>   _ZN4onnx11SchemaErrorD0Ev@Base 1.6.0+dfsg
>   _ZN4onnx11SchemaErrorD1Ev@Base 1.6.0+dfsg
> + _ZN4onnx11SchemaErrorD2Ev@Base 1.7.0+dfsg-1
>   _ZN4onnx11encodeGraphEPNS_10GraphProtoERKSt10shared_ptrINS_5GraphEE@Base 
> 1.6.0+dfsg
>   
> _ZN4onnx11make_uniqueINS_18version_conversion12Upsample_8_9EJEEENSt9enable_ifIXntsrSt8is_arrayIT_E5valueESt10unique_ptrIS5_St14default_deleteIS5_EEE4typeEDpOT0_@Base
>  1.6.0+dfsg
>   
> _ZN4onnx11make_uniqueINS_18version_conversion15TypeRestrictionEJRA4_KcNS_7OpSetIDES6_RSt6vectorINS_20TensorProto_DataTypeESaIS8_ENSt9enable_ifIXntsrSt8is_arrayIT_E5valueESt10unique_ptrISE_St14default_deleteISE_EEE4typeEDpOT0_@Base
>  1.6.0+dfsg
> @@ -446,6 +448,7 @@
>   
> _ZN4onnx11make_uniqueINS_18version_conversion30BroadcastBackwardCompatibilityEJRA4_KcNS_7OpSetIDES6_EEENSt9enable_ifIXntsrSt8is_arrayIT_E5valueESt10unique_ptrIS9_St14default_deleteIS9_EEE4typeEDpOT0_@Base
>  1.6.0+dfsg
>   _ZN4onnx12ConvertErrorD0Ev@Base 1.6.0+dfsg
>   _ZN4onnx12ConvertErrorD1Ev@Base 1.6.0+dfsg
> + _ZN4onnx12ConvertErrorD2Ev@Base 1.7.0+dfsg-1
>   _ZN4onnx12addAttributeEPNS_9NodeProtoEPNS_4NodeENS_6SymbolE@Base 1.6.0+dfsg
>   _ZN4onnx12assert_errorD0Ev@Base 1.6.0+dfsg
>   _ZN4onnx12assert_errorD1Ev@Base 1.6.0+dfsg
> @@ -461,28 +464,34 @@
>   _ZN4onnx12optimization12NopEmptyPass7runPassERNS_5GraphE@Base 1.6.0+dfsg
>   _ZN4onnx12optimization12NopEmptyPassD0Ev@Base 1.6.0+dfsg
>   _ZN4onnx12optimization12NopEmptyPassD1Ev@Base 1.6.0+dfsg
> + _ZN4onnx12optimization12NopEmptyPassD2Ev@Base 1.7.0+dfsg-1
>   _ZN4onnx12optimization12SplitPredict7runPassERNS_5GraphE@Base 1.6.0+dfsg
>   _ZN4onnx12optimization12SplitPredictD0Ev@Base 1.6.0+dfsg
>   _ZN4onnx12optimization12SplitPredictD1Ev@Base 1.6.0+dfsg
> + _ZN4onnx12optimization12SplitPredictD2Ev@Base 1.7.0+dfsg-1
>   
> _ZN4onnx12optimization13OptimizeFixedERKNS_10ModelProtoERKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaISA_EE@Base
>  1.6.0+dfsg
>   
> _ZN4onnx12optimization14FuseBNIntoConv11modify_convEPNS_4NodeES3_RNS_5GraphE@Base
>  1.6.0+dfsg
>   
> _ZN4onnx12optimization14FuseBNIntoConv12runTransformEPNS_4NodeERNS_5GraphERNS0_15NodeDestroyTypeE@Base
>  1.6.0+dfsg
>   
> _ZN4onnx12optimization14FuseBNIntoConv21patternMatchPredicateEPNS_4NodeE@Base 
> 1.6.0+dfsg
>   _ZN4onnx12optimization14FuseBNIntoConvD0Ev@Base 1.6.0+dfsg
>   _ZN4onnx12optimization14FuseBNIntoConvD1Ev@Base 1.6.0+dfsg
> + _ZN4onnx12optimization14FuseBNIntoConvD2Ev@Base 1.7.0+dfsg-1
>   
> _ZN4onnx12optimization15EliminateNopPad10is_nop_padEPNS_4NodeERNS_5GraphE@Base
>  1.7.0+dfsg
>   
> 

Bug#971195: ceres-solver: FTBFS: rm: cannot remove 'debian/tmp/usr/share/doc/ceres/html/_static/js/modernizr.min.js': No such file or directory

2020-09-27 Thread Lucas Nussbaum
Source: ceres-solver
Version: 1.14.0-8
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):
> make[1]: Entering directory '/<>'
> # make lintian happy
> # https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0 -> 
> /usr/share/javascript/mathjax
> sed -i 
> 's/https:\/\/cdnjs.cloudflare.com\/ajax\/libs\/mathjax\/2.7.1/\/usr\/share\/javascript\/mathjax/g'
>  /<>/debian/tmp/usr/share/doc/ceres/html/*.html
> rm debian/tmp/usr/share/doc/ceres/html/_static/jquery.js
> ln -s /usr/share/javascript/jquery/jquery.js 
> debian/tmp/usr/share/doc/ceres/html/_static/jquery.js
> rm debian/tmp/usr/share/doc/ceres/html/_static/js/modernizr.min.js
> rm: cannot remove 
> 'debian/tmp/usr/share/doc/ceres/html/_static/js/modernizr.min.js': No such 
> file or directory
> make[1]: *** [debian/rules:65: override_dh_installdocs] Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/ceres-solver_1.14.0-8_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971213: python-blazarclient: FTBFS: make[1]: pyversions: No such file or directory

2020-09-27 Thread Lucas Nussbaum
Source: python-blazarclient
Version: 3.0.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):
> make[1]: Entering directory '/<>'
> make[1]: pyversions: No such file or directory
> py3versions: no X-Python3-Version in control file, using supported versions
> pkgos-dh_auto_test --no-py2
> + PKGOS_USE_PY2=yes
> + PKGOS_USE_PY3=yes
> + PKGOS_TEST_PARALLEL=yes
> + PKGOS_TEST_SERIAL=no
> + PYTHONS=disabled
> + PYTHON3S=disabled
> + TEST_PARALLEL_OPT=--parallel
> + TEST_SERIAL_OPT=
> + PKGOS_USE_PY2=no
> + shift
> + [ no = yes ]
> + [ yes = yes ]
> + py3versions -vr
> + PYTHON3S=3.8
> + [ yes = no ]
> + [ no = yes ]
> + [ disabled = disabled ]
> + continue
> + [ 3.8 = disabled ]
> + echo 3.8
> + cut -d. -f1
> + PYMAJOR=3
> + echo ===> Testing with python (python3)
> ===> Testing with python (python3)
> + [ 3 = 3 ]
> + pwd
> + [ -d /<>/debian/tmp/usr/lib/python3/dist-packages ]
> + [ -e .stestr.conf ]
> + [ -e .testr.conf ]
> + [ -x /usr/bin/testr-python3 ]
> + TESTR=testr
> + rm -rf .testrepository
> + testr init
> + mktemp -t
> + TEMP_REZ=/tmp/tmp.mCuaVArKpa
> + PYTHON=python3.8 testr run --parallel --subunit
> + tee /tmp/tmp.mCuaVArKpa
> + subunit2pyunit
> blazarclient.tests.test_base.BaseClientManagerTestCase.test_init_with_insufficient_info
> blazarclient.tests.test_base.BaseClientManagerTestCase.test_init_with_insufficient_info
>  ... ok
> blazarclient.tests.test_base.BaseClientManagerTestCase.test_init_with_url_and_token
> blazarclient.tests.test_base.BaseClientManagerTestCase.test_init_with_url_and_token
>  ... ok
> blazarclient.tests.test_base.RequestManagerTestCase.test_get
> blazarclient.tests.test_base.RequestManagerTestCase.test_get ... ok
> blazarclient.tests.test_base.RequestManagerTestCase.test_put
> blazarclient.tests.test_base.RequestManagerTestCase.test_put ... ok
> blazarclient.tests.test_base.RequestManagerTestCase.test_request_fail_without_body
> blazarclient.tests.test_base.RequestManagerTestCase.test_request_fail_without_body
>  ... ok
> blazarclient.tests.test_base.RequestManagerTestCase.test_request_ok_without_body
> blazarclient.tests.test_base.RequestManagerTestCase.test_request_ok_without_body
>  ... ok
> blazarclient.tests.test_base.SessionClientTestCase.test_request_ok
> blazarclient.tests.test_base.SessionClientTestCase.test_request_ok ... ok
> blazarclient.tests.test_client.BaseClientTestCase.test_with_v1a0
> blazarclient.tests.test_client.BaseClientTestCase.test_with_v1a0 ... ok
> blazarclient.tests.test_base.RequestManagerTestCase.test_delete
> blazarclient.tests.test_base.RequestManagerTestCase.test_delete ... ok
> blazarclient.tests.test_base.BaseClientManagerTestCase.test_init_with_session
> blazarclient.tests.test_base.BaseClientManagerTestCase.test_init_with_session 
> ... ok
> blazarclient.tests.test_command.BlazarCommandTestCase.test_get_parser
> blazarclient.tests.test_command.BlazarCommandTestCase.test_get_parser ... ok
> blazarclient.tests.test_command.OpenstackCommandTestCase.test_take_action
> blazarclient.tests.test_command.OpenstackCommandTestCase.test_take_action ... 
> skipped 'Unskip it when get_data will do smthg'
> blazarclient.tests.test_base.RequestManagerTestCase.test_request_fail_with_body
> blazarclient.tests.test_base.RequestManagerTestCase.test_request_fail_with_body
>  ... ok
> blazarclient.tests.test_command.BlazarCommandTestCase.test_format_output_data
> blazarclient.tests.test_command.BlazarCommandTestCase.test_format_output_data 
> ... ok
> blazarclient.tests.test_command.OpenstackCommandTestCase.test_get_data
> blazarclient.tests.test_command.OpenstackCommandTestCase.test_get_data ... 
> skipped 'Unskip it when get_data will do smthg'
> blazarclient.tests.test_shell.BlazarShellTestCase.test_authenticate_user
> blazarclient.tests.test_shell.BlazarShellTestCase.test_authenticate_user ... 
> skipped 'lol'
> blazarclient.tests.test_base.RequestManagerTestCase.test_post
> blazarclient.tests.test_base.RequestManagerTestCase.test_post ... ok
> blazarclient.tests.test_base.RequestManagerTestCase.test_request_ok_with_body
> blazarclient.tests.test_base.RequestManagerTestCase.test_request_ok_with_body 
> ... ok
> blazarclient.tests.test_base.SessionClientTestCase.test_request_fail
> blazarclient.tests.test_base.SessionClientTestCase.test_request_fail ... ok
> blazarclient.tests.test_client.BaseClientTestCase.test_with_v1
> blazarclient.tests.test_client.BaseClientTestCase.test_with_v1 ... ok
> blazarclient.tests.test_client.BaseClientTestCase.test_with_wrong_vers
> blazarclient.tests.test_client.BaseClientTestCase.test_with_wrong_vers ... ok
> blazarclient.tests.test_command.CreateCommandTestCase.test_get_data_data
> blazarclient.tests.test_command.CreateCommandTestCase.test_get_data_data ... 
> skipped 'Under construction'
> 

Bug#971203: gap-atlasrep: FTBFS: dpkg-source: error: pathname '/<>/debian/gaproot/pkg/AtlasRep' points outside source root (to '/<>')

2020-09-27 Thread Lucas Nussbaum
Source: gap-atlasrep
Version: 2.1.0-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):
> Unpack source
> -
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 3.0 (quilt)
> Source: gap-atlasrep
> Binary: gap-atlasrep
> Architecture: all
> Version: 2.1.0-2
> Maintainer: Bill Allombert 
> Homepage: http://www.gap-system.org/Packages/atlasrep.html
> Standards-Version: 4.5.0
> Build-Depends: debhelper-compat (= 12), gap (>= 4r7), gap-doc, gap-gapdoc (>= 
> 1.6.2), gap-character-tables, texlive-latex-extra, texlive-fonts-recommended
> Package-List:
>  gap-atlasrep deb math optional arch=all
> Checksums-Sha1:
>  fe22425ae5f620c4b3c2284cfe8a444a500c 1336180 
> gap-atlasrep_2.1.0.orig.tar.bz2
>  b7935f99717e0c23d83e6adae1c47c35c2662dd1 12664 
> gap-atlasrep_2.1.0-2.debian.tar.xz
> Checksums-Sha256:
>  1cc7bbac20af9181401f8c092e19b3f27106d19c20417029ce684b377ad1ffb0 1336180 
> gap-atlasrep_2.1.0.orig.tar.bz2
>  8ffac380c265ac7932526bfd3089e6ca936af9e424b41d6f5f49f78a4ec5b0ad 12664 
> gap-atlasrep_2.1.0-2.debian.tar.xz
> Files:
>  c73236588127d00211321b3c09a0d140 1336180 gap-atlasrep_2.1.0.orig.tar.bz2
>  d83cbab29efa3de6b7d6a1370f2306ac 12664 gap-atlasrep_2.1.0-2.debian.tar.xz
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEQgKOpASi6dgKxFMUjw58K0Ui44cFAl6IozwACgkQjw58K0Ui
> 44dBZBAAsgo0a1FnY5g6xvF1Pf21bKV5CY38Q9hNx3iSC+iDc0ib5QxiOL45zxBg
> sZhqAQc2XnZBJqhHiCr/AEUjaR+Jz69L9Lom59g1PatjlPrqOKJTmF2gQzFP9oLY
> uAPHSd1uGNNC7j1cGdEQROz8hszyzNE791YrYGvwXP3RbLQXm//d0FotBXf/XAOq
> g2QD+ADUwTgzsTQLHgyesXkO1Uq2zWzEBDsEb/hq5+EoVaDETKpPGscvbzUTYpnu
> dMRRGiqCq4vzYMEo0AhOJq5/GAkz7SSaxwEDSfKZGdebwOtGUxUxQ+g92VOXz+p8
> G0mpJzPPI39tHHOYfkRwBASeFgB3CMROSyGqzzR6FY15Q137XBvJ/OtcNpuH59ow
> Pqt3VCLc09k+KEOmgbP2IMLUKMpFcdwouWfiK0EFKxrRFMCRCmXmALyZBIjeP3xE
> ukR+QvrEdvxD4ABLI10HhUEAwekqs6oVy0AzCqnqrWLmMxE6VNAyaZQdU7kASV/g
> URz7UKLlunL6IV728swXll9ITHzoWLU29FevH1a9bLYhkoRSXqqmqKV7Xu2YEqrJ
> XU564OxiJoroC51eZjJ0Hk0BFse4qxaFauWpXZgEf40CtEYGcZu1J2JO6T9mQl2S
> ZH5JvNzCBhq1x+S6qoXQ8ARHjUb/MONy7yzlVgU/68khGgpbmGs=
> =6Vi8
> -END PGP SIGNATURE-
> 
> gpgv: unknown type of key resource 'trustedkeys.kbx'
> gpgv: keyblock resource '/tmp/dpkg-verify-sig.DGPbPdCb/trustedkeys.kbx': 
> General error
> gpgv: Signature made Sat Apr  4 15:09:48 2020 UTC
> gpgv:using RSA key 42028EA404A2E9D80AC453148F0E7C2B4522E387
> gpgv: Can't check signature: No public key
> dpkg-source: warning: failed to verify signature on ./gap-atlasrep_2.1.0-2.dsc
> dpkg-source: info: extracting gap-atlasrep in /<>
> dpkg-source: info: unpacking gap-atlasrep_2.1.0.orig.tar.bz2
> dpkg-source: info: unpacking gap-atlasrep_2.1.0-2.debian.tar.xz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: applying doc-makefile
> dpkg-source: info: applying default-dir
> dpkg-source: error: pathname '/<>/debian/gaproot/pkg/AtlasRep' 
> points outside source root (to '/<>')
> E: FAILED [dpkg-source died]
> 
> +--+
> | Cleanup 
>  |
> +--+
> 
> Purging /<>
> Not cleaning session: cloned chroot in use
> E: FAILED [dpkg-source died]
> 
> +--+
> | Summary 
>  |
> +--+
> 
> Build Architecture: amd64
> Build Type: full
> Build-Space: 7060
> Build-Time: 0
> Distribution: unstable
> Fail-Stage: unpack
> Host Architecture: amd64
> Install-Time: 31
> Job: gap-atlasrep_2.1.0-2
> Machine Architecture: amd64
> Package: gap-atlasrep
> Package-Time: 0
> Source-Version: 2.1.0-2
> Space: 7060
> Status: given-back
> Version: 2.1.0-2
> 
> Finished at 2020-09-27T11:24:51Z
> Build needed 00:00:00, 7060k disk space
> E: FAILED [dpkg-source died]
> DC-Status: Failed 39.177077178s
> DC-Time-Estimation: 39.177077178 versus expected 90 (r/m: 1.297261727593598 ; 
> m: 39.177077178)

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/gap-atlasrep_2.1.0-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971211: glib-d: FTBFS: dh_auto_configure: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir=/var --

2020-09-27 Thread Lucas Nussbaum
Source: glib-d
Version: 2.2.0-1
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 --with gnome
>dh_update_autotools_config
>dh_autoreconf
>dh_auto_configure
>   cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. 
> --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
> --localstatedir=/var --libdir=lib/x86_64-linux-gnu
> The Meson build system
> Version: 0.55.3
> Source dir: /<>
> Build dir: /<>/obj-x86_64-linux-gnu
> Build type: native build
> Project name: GlibD
> Project version: 2.2.0
> Using 'CFLAGS' from environment with value: '-g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
> Using 'CPPFLAGS' from environment with value: '-Wdate-time 
> -D_FORTIFY_SOURCE=2'
> Using 'DC' from environment with value: 'ldc2'
> Using 'DFLAGS' from environment with value: '-O -g -release -wi'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
> Using 'CFLAGS' from environment with value: '-g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
> Using 'CPPFLAGS' from environment with value: '-Wdate-time 
> -D_FORTIFY_SOURCE=2'
> Using 'DC' from environment with value: 'ldc2'
> Using 'DFLAGS' from environment with value: '-O -g -release -wi'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
> D compiler for the host machine: ldc2 (llvm 1.21.0 "LDC - the LLVM D compiler 
> (1.21.0):")
> D linker for the host machine: ldc2 ld.gold 2.35.1
> Host machine cpu family: x86_64
> Host machine cpu: x86_64
> Found pkg-config: /usr/bin/pkg-config (0.29.2)
> Run-time dependency glib-2.0 found: YES 2.66.0
> Run-time dependency gmodule-2.0 found: YES 2.66.0
> Run-time dependency gobject-2.0 found: YES 2.66.0
> Run-time dependency gio-2.0 found: YES 2.66.0
> Run-time dependency gobject-introspection-1.0 found: YES 1.66.0
> Program girtod found: YES
> Message: Generating D interfaces from GIR...
> 
> ../meson.build:37:4: ERROR: Problem encountered: Unable to build D intefaces 
> from GIR:
> Error /usr/share/gir-1.0/GLib-2.0.gir(51578): Unexpected tag: docsection in 
> GirPackage: glib
> 
> 
> A full log can be found at 
> /<>/obj-x86_64-linux-gnu/meson-logs/meson-log.txt
>   cd obj-x86_64-linux-gnu && tail -v -n \+0 meson-logs/meson-log.txt
> ==> meson-logs/meson-log.txt <==
> Build started at 2020-09-27T11:22:13.071694
> Main binary: /usr/bin/python3
> Build Options: -Dprefix=/usr -Dlibdir=lib/x86_64-linux-gnu 
> -Dlocalstatedir=/var -Dsysconfdir=/etc -Dbuildtype=plain 
> -Dwrap_mode=nodownload
> Python system: Linux
> The Meson build system
> Version: 0.55.3
> Source dir: /<>
> Build dir: /<>/obj-x86_64-linux-gnu
> Build type: native build
> None of 'PKG_CONFIG_PATH' are defined in the environment, not changing global 
> flags.
> None of 'PKG_CONFIG_PATH' are defined in the environment, not changing global 
> flags.
> Project name: GlibD
> Project version: 2.2.0
> None of 'CC' are defined in the environment, not changing global flags.
> Using 'CFLAGS' from environment with value: '-g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
> Using 'CPPFLAGS' from environment with value: '-Wdate-time 
> -D_FORTIFY_SOURCE=2'
> None of 'CC_LD' are defined in the environment, not changing global flags.
> Using 'DC' from environment with value: 'ldc2'
> Using 'DFLAGS' from environment with value: '-O -g -release -wi'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
> None of 'DC_LD' are defined in the environment, not changing global flags.
> None of 'D_LD' are defined in the environment, not changing global flags.
> D compiler for the build machine: ldc2 (llvm 1.21.0 "LDC - the LLVM D 
> compiler (1.21.0):")
> D linker for the build machine: ldc2 ld.gold 2.35.1
> None of 'AR' are defined in the environment, not changing global flags.
> None of 'CC' are defined in the environment, not changing global flags.
> Using 'CFLAGS' from environment with value: '-g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
> Using 'CPPFLAGS' from environment with value: '-Wdate-time 
> -D_FORTIFY_SOURCE=2'
> None of 'CC_LD' are defined in the environment, not changing global flags.
> Using 'DC' from environment with value: 'ldc2'
> Using 'DFLAGS' from environment with value: '-O -g -release -wi'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro'
> None of 'DC_LD' are defined in the environment, not changing global flags.
> None of 'D_LD' are defined in 

Bug#971198: haskell-gi-dbusmenugtk3: FTBFS: Unknown GIR element "docsection" when processing namespace "GLib", aborting.

2020-09-27 Thread Lucas Nussbaum
Source: haskell-gi-dbusmenugtk3
Version: 0.4.9-1
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):
> dpkg-buildpackage
> -
> 
> Command: dpkg-buildpackage -us -uc -sa -rfakeroot
> dpkg-buildpackage: info: source package haskell-gi-dbusmenugtk3
> dpkg-buildpackage: info: source version 0.4.9-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Ilias Tsitsimpis 
> 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  debian/rules clean
> test -x debian/rules
> dh_clean 
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> clean_recipe
> Running rm -rf dist dist-ghc dist-ghcjs dist-hugs debian/hlibrary.setup 
> Setup.hi Setup.ho Setup.o .\*config\*
> Running rm -f configure-ghc-stamp configure-ghcjs-stamp build-ghc-stamp 
> build-ghcjs-stamp build-hugs-stamp build-haddock-stamp
> Running rm -rf debian/tmp-inst-ghc debian/tmp-inst-ghcjs
> Running rm -f debian/extra-depends-ghc debian/extra-depends-ghcjs
> Running rm -f debian/hlibrary.Makefile
> Running rm -rf debian/dh_haskell_shlibdeps
> Running rm -rf debian/tmp-db
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building haskell-gi-dbusmenugtk3 using existing 
> ./haskell-gi-dbusmenugtk3_0.4.9.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: building haskell-gi-dbusmenugtk3 in 
> haskell-gi-dbusmenugtk3_0.4.9-1.debian.tar.xz
> dpkg-source: info: building haskell-gi-dbusmenugtk3 in 
> haskell-gi-dbusmenugtk3_0.4.9-1.dsc
>  debian/rules binary
> test -x debian/rules
> dh_testroot
> dh_prep 
> dh_installdirs -A 
> mkdir -p "."
> CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
> CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> make_setup_recipe
> Running ghc --make Setup.hs -o debian/hlibrary.setup
> [1 of 1] Compiling Main ( Setup.hs, Setup.o )
> Linking debian/hlibrary.setup ...
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> configure_recipe
> Running debian/hlibrary.setup configure --ghc -v2 
> --package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
> --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
> --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro 
> --haddockdir=/usr/lib/ghc-doc/haddock/gi-dbusmenugtk3-0.4.9/ 
> --datasubdir=gi-dbusmenugtk3 
> --htmldir=/usr/share/doc/libghc-gi-dbusmenugtk3-doc/html/ 
> --enable-library-profiling
> Using Parsec parser
> Unknown GIR element "docsection" when processing namespace "GLib", aborting.
> CallStack (from HasCallStack):
>   error, called at lib/Data/GI/CodeGen/API.hs:201:16 in 
> haskell-gi-0.24.4-GhfHY0VJtr89rHNQ5kPVxX:Data.GI.CodeGen.API
> make: *** [/usr/share/cdbs/1/class/hlibrary.mk:142: configure-ghc-stamp] 
> Error 1

The full build log is available from:
   
http://qa-logs.debian.net/2020/09/26/haskell-gi-dbusmenugtk3_0.4.9-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971187: haskell-ncurses: FTBFS: Cannot find a definition for `KEY_EVENT' in the header file.

2020-09-27 Thread Lucas Nussbaum
Source: haskell-ncurses
Version: 0.2.16-4
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):
> dpkg-buildpackage
> -
> 
> Command: dpkg-buildpackage -us -uc -sa -rfakeroot
> dpkg-buildpackage: info: source package haskell-ncurses
> dpkg-buildpackage: info: source version 0.2.16-4
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Ilias Tsitsimpis 
> 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  debian/rules clean
> test -x debian/rules
> dh_clean 
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> clean_recipe
> Running rm -rf dist dist-ghc dist-ghcjs dist-hugs debian/hlibrary.setup 
> Setup.hi Setup.ho Setup.o .\*config\*
> Running rm -f configure-ghc-stamp configure-ghcjs-stamp build-ghc-stamp 
> build-ghcjs-stamp build-hugs-stamp build-haddock-stamp
> Running rm -rf debian/tmp-inst-ghc debian/tmp-inst-ghcjs
> Running rm -f debian/extra-depends-ghc debian/extra-depends-ghcjs
> Running rm -f debian/hlibrary.Makefile
> Running rm -rf debian/dh_haskell_shlibdeps
> Running rm -rf debian/tmp-db
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building haskell-ncurses using existing 
> ./haskell-ncurses_0.2.16.orig.tar.gz
> dpkg-source: info: building haskell-ncurses in 
> haskell-ncurses_0.2.16-4.debian.tar.xz
> dpkg-source: info: building haskell-ncurses in haskell-ncurses_0.2.16-4.dsc
>  debian/rules binary
> test -x debian/rules
> dh_testroot
> dh_prep 
> dh_installdirs -A 
> mkdir -p "."
> CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
> CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> make_setup_recipe
> Running ghc --make Setup.hs -o debian/hlibrary.setup
> [1 of 1] Compiling Main ( Setup.hs, Setup.o )
> Linking debian/hlibrary.setup ...
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> configure_recipe
> Running debian/hlibrary.setup configure --ghc -v2 
> --package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
> --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
> --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro 
> --haddockdir=/usr/lib/ghc-doc/haddock/ncurses-0.2.16/ --datasubdir=ncurses 
> --htmldir=/usr/share/doc/libghc-ncurses-doc/html/ --enable-library-profiling
> Using Parsec parser
> Configuring ncurses-0.2.16...
> Flags chosen: force-narrow-library=False, use-pkgconfig=False
> Dependency base >=4.0 && <5.0: using base-4.13.0.0
> Dependency containers >=0.2: using containers-0.6.2.1
> Dependency text >=0.7: using text-1.2.4.0
> Dependency transformers >=0.2: using transformers-0.5.6.2
> Source component graph: component lib
> Configured component graph:
> component ncurses-0.2.16-DlbBRnylFrw1BhVAk5l8d3
> include base-4.13.0.0
> include containers-0.6.2.1
> include text-1.2.4.0
> include transformers-0.5.6.2
> Linked component graph:
> unit ncurses-0.2.16-DlbBRnylFrw1BhVAk5l8d3
> include base-4.13.0.0
> include containers-0.6.2.1
> include text-1.2.4.0
> include transformers-0.5.6.2
> 
> UI.NCurses=ncurses-0.2.16-DlbBRnylFrw1BhVAk5l8d3:UI.NCurses,UI.NCurses.Panel=ncurses-0.2.16-DlbBRnylFrw1BhVAk5l8d3:UI.NCurses.Panel
> Ready component graph:
> definite ncurses-0.2.16-DlbBRnylFrw1BhVAk5l8d3
> depends base-4.13.0.0
> depends containers-0.6.2.1
> depends text-1.2.4.0
> depends transformers-0.5.6.2
> Using Cabal-3.0.1.0 compiled by ghc-8.8
> Using compiler: ghc-8.8.4
> Using install prefix: /usr
> Executables installed in: /usr/bin
> Libraries installed in:
> /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/ncurses-0.2.16-DlbBRnylFrw1BhVAk5l8d3
> Dynamic Libraries installed in:
> /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4
> Private executables installed in:
> /usr/lib/x86_64-linux-ghc-8.8.4/ncurses-0.2.16
> Data files installed in: /usr/share/ncurses
> Documentation installed in:
> /usr/share/doc/x86_64-linux-ghc-8.8.4/ncurses-0.2.16
> Configuration files installed in: /usr/etc
> No alex found
> Using ar found on system at: /usr/bin/x86_64-linux-gnu-ar
> Using c2hs version 0.28.6 found on system at: /usr/bin/c2hs
> No cpphs found
> No doctest found
> Using gcc version 10 found on system at: /usr/bin/x86_64-linux-gnu-gcc
> Using ghc version 8.8.4 found on system at: /usr/bin/ghc
> Using ghc-pkg version 8.8.4 found on system at: /usr/bin/ghc-pkg
> No ghcjs found
> No ghcjs-pkg found
> No greencard found
> Using haddock version 2.23.0 found on system at: /usr/bin/haddock
> No happy found
> Using haskell-suite found on system at: haskell-suite-dummy-location
> Using haskell-suite-pkg found on system at: 

Bug#971196: haskell-gi-gio: FTBFS: Unknown GIR element "docsection" when processing namespace "Gio", aborting.

2020-09-27 Thread Lucas Nussbaum
Source: haskell-gi-gio
Version: 2.0.27-1
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):
> dpkg-buildpackage
> -
> 
> Command: dpkg-buildpackage -us -uc -sa -rfakeroot
> dpkg-buildpackage: info: source package haskell-gi-gio
> dpkg-buildpackage: info: source version 2.0.27-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Ilias Tsitsimpis 
> 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  debian/rules clean
> test -x debian/rules
> dh_clean 
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> clean_recipe
> Running rm -rf dist dist-ghc dist-ghcjs dist-hugs debian/hlibrary.setup 
> Setup.hi Setup.ho Setup.o .\*config\*
> Running rm -f configure-ghc-stamp configure-ghcjs-stamp build-ghc-stamp 
> build-ghcjs-stamp build-hugs-stamp build-haddock-stamp
> Running rm -rf debian/tmp-inst-ghc debian/tmp-inst-ghcjs
> Running rm -f debian/extra-depends-ghc debian/extra-depends-ghcjs
> Running rm -f debian/hlibrary.Makefile
> Running rm -rf debian/dh_haskell_shlibdeps
> Running rm -rf debian/tmp-db
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building haskell-gi-gio using existing 
> ./haskell-gi-gio_2.0.27.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: building haskell-gi-gio in 
> haskell-gi-gio_2.0.27-1.debian.tar.xz
> dpkg-source: info: building haskell-gi-gio in haskell-gi-gio_2.0.27-1.dsc
>  debian/rules binary
> test -x debian/rules
> dh_testroot
> dh_prep 
> dh_installdirs -A 
> mkdir -p "."
> CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
> CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> make_setup_recipe
> Running ghc --make Setup.hs -o debian/hlibrary.setup
> [1 of 1] Compiling Main ( Setup.hs, Setup.o )
> Linking debian/hlibrary.setup ...
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> configure_recipe
> Running debian/hlibrary.setup configure --ghc -v2 
> --package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
> --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
> --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro 
> --haddockdir=/usr/lib/ghc-doc/haddock/gi-gio-2.0.27/ --datasubdir=gi-gio 
> --htmldir=/usr/share/doc/libghc-gi-gio-doc/html/ --enable-library-profiling
> Using Parsec parser
> Unknown GIR element "docsection" when processing namespace "Gio", aborting.
> CallStack (from HasCallStack):
>   error, called at lib/Data/GI/CodeGen/API.hs:201:16 in 
> haskell-gi-0.24.4-GhfHY0VJtr89rHNQ5kPVxX:Data.GI.CodeGen.API
> make: *** [/usr/share/cdbs/1/class/hlibrary.mk:142: configure-ghc-stamp] 
> Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/haskell-gi-gio_2.0.27-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971202: haskell-gi-gdkx11: FTBFS: Unknown GIR element "docsection" when processing namespace "GLib", aborting.

2020-09-27 Thread Lucas Nussbaum
Source: haskell-gi-gdkx11
Version: 3.0.10-1
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):
> dpkg-buildpackage
> -
> 
> Command: dpkg-buildpackage -us -uc -sa -rfakeroot
> dpkg-buildpackage: info: source package haskell-gi-gdkx11
> dpkg-buildpackage: info: source version 3.0.10-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Ilias Tsitsimpis 
> 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  debian/rules clean
> test -x debian/rules
> dh_clean 
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> clean_recipe
> Running rm -rf dist dist-ghc dist-ghcjs dist-hugs debian/hlibrary.setup 
> Setup.hi Setup.ho Setup.o .\*config\*
> Running rm -f configure-ghc-stamp configure-ghcjs-stamp build-ghc-stamp 
> build-ghcjs-stamp build-hugs-stamp build-haddock-stamp
> Running rm -rf debian/tmp-inst-ghc debian/tmp-inst-ghcjs
> Running rm -f debian/extra-depends-ghc debian/extra-depends-ghcjs
> Running rm -f debian/hlibrary.Makefile
> Running rm -rf debian/dh_haskell_shlibdeps
> Running rm -rf debian/tmp-db
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building haskell-gi-gdkx11 using existing 
> ./haskell-gi-gdkx11_3.0.10.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: building haskell-gi-gdkx11 in 
> haskell-gi-gdkx11_3.0.10-1.debian.tar.xz
> dpkg-source: info: building haskell-gi-gdkx11 in 
> haskell-gi-gdkx11_3.0.10-1.dsc
>  debian/rules binary
> test -x debian/rules
> dh_testroot
> dh_prep 
> dh_installdirs -A 
> mkdir -p "."
> CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
> CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> make_setup_recipe
> Running ghc --make Setup.hs -o debian/hlibrary.setup
> [1 of 1] Compiling Main ( Setup.hs, Setup.o )
> Linking debian/hlibrary.setup ...
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> configure_recipe
> Running debian/hlibrary.setup configure --ghc -v2 
> --package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
> --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
> --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro 
> --haddockdir=/usr/lib/ghc-doc/haddock/gi-gdkx11-3.0.10/ 
> --datasubdir=gi-gdkx11 --htmldir=/usr/share/doc/libghc-gi-gdkx11-doc/html/ 
> --enable-library-profiling
> Using Parsec parser
> Unknown GIR element "docsection" when processing namespace "GLib", aborting.
> CallStack (from HasCallStack):
>   error, called at lib/Data/GI/CodeGen/API.hs:201:16 in 
> haskell-gi-0.24.4-GhfHY0VJtr89rHNQ5kPVxX:Data.GI.CodeGen.API
> make: *** [/usr/share/cdbs/1/class/hlibrary.mk:142: configure-ghc-stamp] 
> Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/haskell-gi-gdkx11_3.0.10-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971190: haskell-gi-gtk: FTBFS: Unknown GIR element "docsection" when processing namespace "GLib", aborting.

2020-09-27 Thread Lucas Nussbaum
Source: haskell-gi-gtk
Version: 3.0.36-1
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):
> dpkg-buildpackage
> -
> 
> Command: dpkg-buildpackage -us -uc -sa -rfakeroot
> dpkg-buildpackage: info: source package haskell-gi-gtk
> dpkg-buildpackage: info: source version 3.0.36-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Ilias Tsitsimpis 
> 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  debian/rules clean
> test -x debian/rules
> dh_clean 
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> clean_recipe
> Running rm -rf dist dist-ghc dist-ghcjs dist-hugs debian/hlibrary.setup 
> Setup.hi Setup.ho Setup.o .\*config\*
> Running rm -f configure-ghc-stamp configure-ghcjs-stamp build-ghc-stamp 
> build-ghcjs-stamp build-hugs-stamp build-haddock-stamp
> Running rm -rf debian/tmp-inst-ghc debian/tmp-inst-ghcjs
> Running rm -f debian/extra-depends-ghc debian/extra-depends-ghcjs
> Running rm -f debian/hlibrary.Makefile
> Running rm -rf debian/dh_haskell_shlibdeps
> Running rm -rf debian/tmp-db
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building haskell-gi-gtk using existing 
> ./haskell-gi-gtk_3.0.36.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: building haskell-gi-gtk in 
> haskell-gi-gtk_3.0.36-1.debian.tar.xz
> dpkg-source: info: building haskell-gi-gtk in haskell-gi-gtk_3.0.36-1.dsc
>  debian/rules binary
> test -x debian/rules
> dh_testroot
> dh_prep 
> dh_installdirs -A 
> mkdir -p "."
> CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
> CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> make_setup_recipe
> Running ghc --make Setup.hs -o debian/hlibrary.setup
> [1 of 1] Compiling Main ( Setup.hs, Setup.o )
> Linking debian/hlibrary.setup ...
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> configure_recipe
> Running debian/hlibrary.setup configure --ghc -v2 
> --package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
> --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
> --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro 
> --haddockdir=/usr/lib/ghc-doc/haddock/gi-gtk-3.0.36/ --datasubdir=gi-gtk 
> --htmldir=/usr/share/doc/libghc-gi-gtk-doc/html/ --enable-library-profiling
> Using Parsec parser
> Unknown GIR element "docsection" when processing namespace "GLib", aborting.
> CallStack (from HasCallStack):
>   error, called at lib/Data/GI/CodeGen/API.hs:201:16 in 
> haskell-gi-0.24.4-GhfHY0VJtr89rHNQ5kPVxX:Data.GI.CodeGen.API
> make: *** [/usr/share/cdbs/1/class/hlibrary.mk:142: configure-ghc-stamp] 
> Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/haskell-gi-gtk_3.0.36-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971194: warzone2100: FTBFS: Exit with code 1 due to network error: ProtocolUnknownError

2020-09-27 Thread Lucas Nussbaum
Source: warzone2100
Version: 3.3.0-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):
> make[4]: Entering directory '/<>/doc'
> a2x -f manpage ./warzone2100.6.asciidoc
> a2x -f xhtml ./quickstartguide.asciidoc
> wkhtmltopdf ./quickstartguide.html ./quickstartguide.pdf
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-user42'
> Loading page (1/2)
> [>   ] 0%
> [>   ] 14%
> Warning: Blocked access to file /<>/doc/docbook-xsl.css
> Warning: Blocked access to file /<>/doc/images/www.png
> Warning: Blocked access to file /<>/doc/images/logo.png
> Warning: Blocked access to file /<>/doc/images/interface.jpg
> Warning: Blocked access to file /<>/doc/images/minimap.jpg
> Warning: Blocked access to file /<>/doc/images/powerbar.jpg
> Warning: Blocked access to file /<>/doc/images/oilresource.jpg
> Warning: Blocked access to file /<>/doc/images/cheapweapon.png
> Warning: Blocked access to file 
> /<>/doc/images/expensiveweapon.png
> Warning: Blocked access to file /<>/doc/images/powerupgrade.png
> Warning: Blocked access to file /<>/doc/images/unitordersmenu.jpg
> Warning: Blocked access to file /<>/doc/images/attackrange.jpg
> Warning: Blocked access to file 
> /<>/doc/images/retreatthreshold.jpg
> Warning: Blocked access to file /<>/doc/images/firing.jpg
> Warning: Blocked access to file /<>/doc/images/movement.jpg
> Warning: Blocked access to file /<>/doc/images/return.jpg
> Warning: Blocked access to file /<>/doc/images/recycling.jpg
> Warning: Blocked access to file /<>/doc/images/commandpanel.png
> Warning: Blocked access to file 
> /<>/doc/images/manufacture-select.jpg
> Warning: Blocked access to file /<>/doc/images/manufacture.jpg
> Error: Failed to load about:blank, with network status code 301 and http 
> status code 0 - Protocol "about" is unknown
> Warning: Blocked access to file /<>/doc/images/rallypoints.jpg
> Warning: Blocked access to file 
> /<>/doc/images/research-select.jpg
> Warning: Blocked access to file /<>/doc/images/research.jpg
> Warning: Blocked access to file 
> /<>/doc/images/building-select.jpg
> Warning: Blocked access to file /<>/doc/images/building.jpg
> Warning: Blocked access to file /<>/doc/images/design.jpg
> Warning: Blocked access to file /<>/doc/images/design-unit.jpg
> Warning: Blocked access to file /<>/doc/images/design-more.png
> Warning: Blocked access to file /<>/doc/images/design-screen.jpg
> Warning: Blocked access to file /<>/doc/images/design-bars.jpg
> Warning: Blocked access to file 
> /<>/doc/images/intelligencedisplay.jpg
> Warning: Blocked access to file /<>/doc/images/commander.png
> Warning: Blocked access to file 
> /<>/doc/images/commander-panel.jpg
> Warning: Blocked access to file 
> /<>/doc/images/commander-factory-assignment.jpg
> Warning: Blocked access to file 
> /<>/doc/images/indirect-fire-support.jpg
> Warning: Blocked access to file /<>/doc/images/sensor.png
> Warning: Blocked access to file 
> /<>/doc/images/artillery-sensor.jpg
> Warning: Blocked access to file 
> /<>/doc/images/artillery-far-away.jpg
> Warning: Blocked access to file /<>/doc/images/cb-sensor.png
> Warning: Blocked access to file /<>/doc/images/cb-sensor-vtol.png
> Warning: Blocked access to file /<>/doc/images/hq.png
> Warning: Blocked access to file /<>/doc/images/sensor-tower.png
> Warning: Blocked access to file 
> /<>/doc/images/satellite-uplink.png
> Warning: Blocked access to file /<>/doc/images/wss.png
> Warning: Blocked access to file /<>/doc/images/transport.jpg
> Warning: Blocked access to file /<>/doc/images/awaymission.jpg
> Error: Failed to load about:blank, with network status code 301 and http 
> status code 0 - Protocol "about" is unknown
> Error: Failed to load about:blank, with network status code 301 and http 
> status code 0 - Protocol "about" is unknown
> Error: Failed to load about:blank, with network status code 301 and http 
> status code 0 - Protocol "about" is unknown
> Error: Failed to load about:blank, with network status code 301 and http 
> status code 0 - Protocol "about" is unknown
> Error: Failed to load about:blank, with network status code 301 and http 
> status code 0 - Protocol "about" is unknown
> Error: Failed to load about:blank, with network status code 301 and http 
> status code 0 - Protocol "about" is unknown
> Error: Failed to load about:blank, with network status code 301 and http 
> status code 0 - Protocol "about" is unknown
> Error: Failed to load about:blank, with network status code 301 and http 
> status code 0 - Protocol "about" is unknown
> Error: Failed to load about:blank, with network status code 301 and http 
> status code 0 - Protocol "about" is unknown
> Error: Failed to load about:blank, with network status code 

Bug#971209: rust-redox-syscall: FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101

2020-09-27 Thread Lucas Nussbaum
Source: rust-redox-syscall
Version: 0.1.40-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):
> make[1]: Entering directory '/<>'
> export RUSTC_BOOTSTRAP=1; \
> case x86_64-unknown-linux-gnu in \
> arm-*|x86-*|x86_64-*) \
>   dh_auto_test;; \
> *) \
>   dh_auto_test || true;; \
> esac
> debian cargo wrapper: options, profiles, parallel: ['parallel=4'] [] ['-j4']
> debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, 
> x86_64-linux-gnu
> debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', 
> '/usr/bin/cargo', '-Zavoid-dev-deps', 'build', '--verbose', '--verbose', 
> '-j4', '--target', 'x86_64-unknown-linux-gnu'],) {}
>Compiling redox_syscall v0.1.40 (/<>)
>  Running `CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_NAME=redox_syscall 
> CARGO=/usr/bin/cargo 
> CARGO_PKG_REPOSITORY='https://github.com/redox-os/syscall' 
> CARGO_PKG_AUTHORS='Jeremy Soller ' 
> CARGO_PKG_VERSION_MINOR=1 CARGO_PKG_VERSION_PRE= 
> CARGO_MANIFEST_DIR=/<> CARGO_PKG_VERSION=0.1.40 
> CARGO_PKG_VERSION_PATCH=40 CARGO_PKG_DESCRIPTION='A Rust library to access 
> raw Redox system calls' CARGO_PKG_HOMEPAGE= 
> LD_LIBRARY_PATH='/<>/target/debug/deps:/usr/lib' rustc 
> --crate-name syscall src/lib.rs --error-format=json 
> --json=diagnostic-rendered-ansi --crate-type lib 
> --emit=dep-info,metadata,link -C debuginfo=2 -C metadata=65c14a21970da5f1 -C 
> extra-filename=-65c14a21970da5f1 --out-dir 
> /<>/target/x86_64-unknown-linux-gnu/debug/deps --target 
> x86_64-unknown-linux-gnu -C 
> incremental=/<>/target/x86_64-unknown-linux-gnu/debug/incremental
>  -L dependency=/<>/target/x86_64-unknown-linux-gnu/debug/deps -L 
> dependency=/<>/target/debug/deps -C debuginfo=2 --cap-lints warn 
> -C linker=x86_64-linux-gnu-gcc -C link-arg=-Wl,-z,relro --remap-path-prefix 
> /<>=/usr/share/cargo/registry/redox-syscall-0.1.40`
> error: the legacy LLVM-style asm! syntax is no longer supported
>  --> src/arch/x86_64.rs:4:5
>   |
> 4 |   asm!("int 0x80"
>   |   ^---
>   |   |
>   |  _help: replace with: `llvm_asm!`
>   | |
> 5 | | : "={rax}"(a)
> 6 | | : "{rax}"(a)
> 7 | | : "memory"
> 8 | | : "intel", "volatile");
>   | |___^
>   |
>   = note: consider migrating to the new asm! syntax specified in RFC 2873
>   = note: alternatively, switch to llvm_asm! to keep your code working as it 
> is
> 
> error: the legacy LLVM-style asm! syntax is no longer supported
>   --> src/arch/x86_64.rs:14:5
>|
> 14 |   asm!("int 0x80"
>|   ^---
>|   |
>|  _help: replace with: `llvm_asm!`
>| |
> 15 | | : "={rax}"(a)
> 16 | | : "{rax}"(a), "{rbx}"(b)
> 17 | | : "memory"
> 18 | | : "intel", "volatile");
>| |___^
>|
>= note: consider migrating to the new asm! syntax specified in RFC 2873
>= note: alternatively, switch to llvm_asm! to keep your code working as it 
> is
> 
> error: the legacy LLVM-style asm! syntax is no longer supported
>   --> src/arch/x86_64.rs:25:5
>|
> 25 |   asm!("int 0x80"
>|   ^---
>|   |
>|  _help: replace with: `llvm_asm!`
>| |
> 26 | | : "={rax}"(a)
> 27 | | : "{rax}"(a), "{rbx}"(b)
> 28 | | : "memory", "rbx", "rcx", "rdx", "rsi", "rdi", "r8",
> 29 | |   "r9", "r10", "r11", "r12", "r13", "r14", "r15"
> 30 | | : "intel", "volatile");
>| |___^
>|
>= note: consider migrating to the new asm! syntax specified in RFC 2873
>= note: alternatively, switch to llvm_asm! to keep your code working as it 
> is
> 
> error: the legacy LLVM-style asm! syntax is no longer supported
>   --> src/arch/x86_64.rs:36:5
>|
> 36 |   asm!("int 0x80"
>|   ^---
>|   |
>|  _help: replace with: `llvm_asm!`
>| |
> 37 | | : "={rax}"(a)
> 38 | | : "{rax}"(a), "{rbx}"(b), "{rcx}"(c)
> 39 | | : "memory"
> 40 | | : "intel", "volatile");
>| |___^
>|
>= note: consider migrating to the new asm! syntax specified in RFC 2873
>= note: alternatively, switch to llvm_asm! to keep your code working as it 
> is
> 
> error: the legacy LLVM-style asm! syntax is no longer supported
>   --> src/arch/x86_64.rs:46:5
>|
> 46 |   asm!("int 0x80"
>|   ^---
>|   |
>|  _help: replace with: `llvm_asm!`
>| |
> 47 | | : "={rax}"(a)
> 48 | | : "{rax}"(a), "{rbx}"(b), "{rcx}"(c), "{rdx}"(d)
> 49 | | : "memory"
> 50 | | : "intel", "volatile");
>| |___^
>|
>= note: consider migrating to the new asm! syntax specified in RFC 2873
>= note: alternatively, switch to llvm_asm! to keep your 

Bug#971191: haskell-gi-dbusmenu: FTBFS: Unknown GIR element "docsection" when processing namespace "GLib", aborting.

2020-09-27 Thread Lucas Nussbaum
Source: haskell-gi-dbusmenu
Version: 0.4.8-1
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):
> dpkg-buildpackage
> -
> 
> Command: dpkg-buildpackage -us -uc -sa -rfakeroot
> dpkg-buildpackage: info: source package haskell-gi-dbusmenu
> dpkg-buildpackage: info: source version 0.4.8-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Ilias Tsitsimpis 
> 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  debian/rules clean
> test -x debian/rules
> dh_clean 
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> clean_recipe
> Running rm -rf dist dist-ghc dist-ghcjs dist-hugs debian/hlibrary.setup 
> Setup.hi Setup.ho Setup.o .\*config\*
> Running rm -f configure-ghc-stamp configure-ghcjs-stamp build-ghc-stamp 
> build-ghcjs-stamp build-hugs-stamp build-haddock-stamp
> Running rm -rf debian/tmp-inst-ghc debian/tmp-inst-ghcjs
> Running rm -f debian/extra-depends-ghc debian/extra-depends-ghcjs
> Running rm -f debian/hlibrary.Makefile
> Running rm -rf debian/dh_haskell_shlibdeps
> Running rm -rf debian/tmp-db
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building haskell-gi-dbusmenu using existing 
> ./haskell-gi-dbusmenu_0.4.8.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: building haskell-gi-dbusmenu in 
> haskell-gi-dbusmenu_0.4.8-1.debian.tar.xz
> dpkg-source: info: building haskell-gi-dbusmenu in 
> haskell-gi-dbusmenu_0.4.8-1.dsc
>  debian/rules binary
> test -x debian/rules
> dh_testroot
> dh_prep 
> dh_installdirs -A 
> mkdir -p "."
> CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
> CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> make_setup_recipe
> Running ghc --make Setup.hs -o debian/hlibrary.setup
> [1 of 1] Compiling Main ( Setup.hs, Setup.o )
> Linking debian/hlibrary.setup ...
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> configure_recipe
> Running debian/hlibrary.setup configure --ghc -v2 
> --package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
> --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
> --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro 
> --haddockdir=/usr/lib/ghc-doc/haddock/gi-dbusmenu-0.4.8/ 
> --datasubdir=gi-dbusmenu 
> --htmldir=/usr/share/doc/libghc-gi-dbusmenu-doc/html/ 
> --enable-library-profiling
> Using Parsec parser
> Unknown GIR element "docsection" when processing namespace "GLib", aborting.
> CallStack (from HasCallStack):
>   error, called at lib/Data/GI/CodeGen/API.hs:201:16 in 
> haskell-gi-0.24.4-GhfHY0VJtr89rHNQ5kPVxX:Data.GI.CodeGen.API
> make: *** [/usr/share/cdbs/1/class/hlibrary.mk:142: configure-ghc-stamp] 
> Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/haskell-gi-dbusmenu_0.4.8-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971193: mina2: FTBFS: Bundle org.apache.mina:mina-core:bundle:2.0.19 : package info for org.apache.mina.util attribute [version~='2.0.19'], key must be an EXTENDED (CORE1.3.2 [-.\w]+). From null

2020-09-27 Thread Lucas Nussbaum
Source: mina2
Version: 2.0.19-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):
> make[1]: Entering directory '/<>'
> dh_auto_build -- -f src/pom.xml package javadoc:aggregate
>   /usr/lib/jvm/default-java/bin/java -noverify -cp 
> /usr/share/maven/boot/plexus-classworlds-2.x.jar 
> -Dmaven.home=/usr/share/maven 
> -Dmaven.multiModuleProjectDirectory=/<> 
> -Dclassworlds.conf=/etc/maven/m2-debian.conf 
> -Dproperties.file.manual=/<>/debian/maven.properties 
> org.codehaus.plexus.classworlds.launcher.Launcher 
> -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian 
> -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode -f 
> src/pom.xml package javadoc:aggregate -DskipTests -Dnotimestamp=true 
> -Dlocale=en_US
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> com.google.inject.internal.cglib.core.$ReflectUtils$1 
> (file:/usr/share/maven/lib/guice.jar) to method 
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
> WARNING: Please consider reporting this to the maintainers of 
> com.google.inject.internal.cglib.core.$ReflectUtils$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> [INFO] Scanning for projects...
> [WARNING] The project org.apache.mina:mina-parent:pom:2.0.19 uses 
> prerequisites which is only intended for maven-plugin projects but not for 
> non maven-plugin projects. For such purposes you should use the 
> maven-enforcer-plugin. See 
> https://maven.apache.org/enforcer/enforcer-rules/requireMavenVersion.html
> [INFO] 
> 
> [INFO] Reactor Build Order:
> [INFO] 
> [INFO] Apache MINA
> [pom]
> [INFO] Apache MINA Core
> [bundle]
> [INFO] Apache MINA APR Transport   
> [bundle]
> [INFO] Apache MINA Compression Filter  
> [bundle]
> [INFO] Apache MINA JavaBeans Integration   
> [bundle]
> [INFO] Apache MINA XBean Integration  
> [jar]
> [INFO] Apache MINA OGNL Integration
> [bundle]
> [INFO] Apache MINA JMX Integration 
> [bundle]
> [WARNING] The POM for org.apache.maven.plugins:maven-antrun-plugin:jar:1.3 is 
> missing, no dependency information available
> [WARNING] Failed to retrieve plugin descriptor for 
> org.apache.maven.plugins:maven-antrun-plugin:1.3: Plugin 
> org.apache.maven.plugins:maven-antrun-plugin:1.3 or one of its dependencies 
> could not be resolved: Cannot access central 
> (https://repo.maven.apache.org/maven2) in offline mode and the artifact 
> org.apache.maven.plugins:maven-antrun-plugin:jar:1.3 has not been downloaded 
> from it before.
> [WARNING] The POM for 
> org.apache.maven.plugins:maven-assembly-plugin:jar:3.1.0 is missing, no 
> dependency information available
> [WARNING] Failed to retrieve plugin descriptor for 
> org.apache.maven.plugins:maven-assembly-plugin:3.1.0: Plugin 
> org.apache.maven.plugins:maven-assembly-plugin:3.1.0 or one of its 
> dependencies could not be resolved: Cannot access central 
> (https://repo.maven.apache.org/maven2) in offline mode and the artifact 
> org.apache.maven.plugins:maven-assembly-plugin:jar:3.1.0 has not been 
> downloaded from it before.
> [WARNING] The POM for 
> org.apache.maven.plugins:maven-changes-plugin:jar:2.12.1 is missing, no 
> dependency information available
> [WARNING] Failed to retrieve plugin descriptor for 
> org.apache.maven.plugins:maven-changes-plugin:2.12.1: Plugin 
> org.apache.maven.plugins:maven-changes-plugin:2.12.1 or one of its 
> dependencies could not be resolved: Cannot access central 
> (https://repo.maven.apache.org/maven2) in offline mode and the artifact 
> org.apache.maven.plugins:maven-changes-plugin:jar:2.12.1 has not been 
> downloaded from it before.
> [WARNING] The POM for 
> org.apache.maven.plugins:maven-checkstyle-plugin:jar:2.17 is missing, no 
> dependency information available
> [WARNING] Failed to retrieve plugin descriptor for 
> org.apache.maven.plugins:maven-checkstyle-plugin:2.17: Plugin 
> org.apache.maven.plugins:maven-checkstyle-plugin:2.17 or one of its 
> dependencies could not be resolved: Cannot access central 
> (https://repo.maven.apache.org/maven2) in offline mode and the artifact 
> org.apache.maven.plugins:maven-checkstyle-plugin:jar:2.17 has not been 
> downloaded from it before.
> [WARNING] The POM for 
> org.apache.maven.plugins:maven-dependency-plugin:jar:3.0.2 

Bug#971200: libmusicbrainz5: FTBFS: make[5]: *** No rule to make target 'src/*.inc', needed by 'src/mb5_c.cc'. Stop.

2020-09-27 Thread Lucas Nussbaum
Source: libmusicbrainz5
Version: 5.1.0+git20150707-9
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):
> make[5]: Entering directory '/<>/obj-x86_64-linux-gnu'
> cd /<>/obj-x86_64-linux-gnu && /usr/bin/cmake -E cmake_depends 
> "Unix Makefiles" /<> /<>/src 
> /<>/obj-x86_64-linux-gnu 
> /<>/obj-x86_64-linux-gnu/src 
> /<>/obj-x86_64-linux-gnu/src/CMakeFiles/src_gen.dir/DependInfo.cmake
>  --color=
> Scanning dependencies of target src_gen
> make[5]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> make  -f src/CMakeFiles/src_gen.dir/build.make 
> src/CMakeFiles/src_gen.dir/build
> make[5]: Entering directory '/<>/obj-x86_64-linux-gnu'
> make[5]: *** No rule to make target 'src/*.inc', needed by 'src/mb5_c.cc'.  
> Stop.
> make[5]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> make[4]: *** [CMakeFiles/Makefile2:256: src/CMakeFiles/src_gen.dir/all] Error 
> 2

The full build log is available from:
   
http://qa-logs.debian.net/2020/09/26/libmusicbrainz5_5.1.0+git20150707-9_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971197: golang-github-checkpoint-restore-go-criu: FTBFS: package github.com/checkpoint-restore/go-criu/test: C source files not allowed when not using cgo or SWIG: piggie.c

2020-09-27 Thread Lucas Nussbaum
Source: golang-github-checkpoint-restore-go-criu
Version: 4.1.0-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):
> make[1]: Entering directory '/<>'
> cp -rv debian/missing-sources/* ./
> 'debian/missing-sources/rpc/rpc.proto' -> './rpc/rpc.proto'
> 'debian/missing-sources/rpc/rpc.proto.URL' -> './rpc/rpc.proto.URL'
> 'debian/missing-sources/stats/stats.proto' -> './stats/stats.proto'
> 'debian/missing-sources/stats/stats.proto.URL' -> './stats/stats.proto.URL'
> protoc --go_out=. rpc/rpc.proto
> cp -rv debian/missing-sources/* ./
> 'debian/missing-sources/rpc/rpc.proto' -> './rpc/rpc.proto'
> 'debian/missing-sources/rpc/rpc.proto.URL' -> './rpc/rpc.proto.URL'
> 'debian/missing-sources/stats/stats.proto' -> './stats/stats.proto'
> 'debian/missing-sources/stats/stats.proto.URL' -> './stats/stats.proto.URL'
> protoc --go_out=. stats/stats.proto
> dh_auto_configure
> make[1]: Leaving directory '/<>'
>dh_auto_build -O--builddirectory=_build -O--buildsystem=golang
> package github.com/checkpoint-restore/go-criu/test: C source files not 
> allowed when not using cgo or SWIG: piggie.c
>   cd _build && go install -trimpath -v -p 4
> package .: no Go files in /<>/_build
> dh_auto_build: error: cd _build && go install -trimpath -v -p 4 returned exit 
> code 1
> make: *** [debian/rules:9: binary] Error 25

The full build log is available from:
   
http://qa-logs.debian.net/2020/09/26/golang-github-checkpoint-restore-go-criu_4.1.0-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971199: texext: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 returned exit code 13

2020-09-27 Thread Lucas Nussbaum
Source: texext
Version: 0.6.6-1
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 --with python3 --buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_autoreconf -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:217: python3.8 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:217: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.8_texext/build/texext
> copying texext/__init__.py -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext
> copying texext/math_dollar.py -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext
> copying texext/_version.py -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext
> copying texext/mathcode.py -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext
> creating /<>/.pybuild/cpython3_3.8_texext/build/texext/tests
> copying texext/tests/__init__.py -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests
> copying texext/tests/test_mathdollar.py -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests
> copying texext/tests/for_docstrings.py -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests
> copying texext/tests/test_plotdirective.py -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests
> copying texext/tests/conftest.py -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests
> copying texext/tests/test_custom_plotdirective.py -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests
> copying texext/tests/test_tinypages.py -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests
> copying texext/tests/test_docstrings.py -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests
> copying texext/tests/test_custom_plotcontext.py -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests
> creating 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests/tinypages
> copying texext/tests/tinypages/some_math.rst -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests/tinypages
> copying texext/tests/tinypages/index.rst -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests/tinypages
> copying texext/tests/tinypages/conf.py -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests/tinypages
> creating 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests/tinypages/_static
> copying texext/tests/tinypages/_static/README.txt -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests/tinypages/_static
> creating 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests/plotdirective
> copying texext/tests/plotdirective/index.rst -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests/plotdirective
> copying texext/tests/plotdirective/plot_and_math.rst -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests/plotdirective
> copying texext/tests/plotdirective/conf.py -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests/plotdirective
> creating 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests/plotdirective/_static
> copying texext/tests/plotdirective/_static/README.txt -> 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/tests/plotdirective/_static
> UPDATING 
> /<>/.pybuild/cpython3_3.8_texext/build/texext/_version.py
> set /<>/.pybuild/cpython3_3.8_texext/build/texext/_version.py to 
> '0.6.6'
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:217: cd /<>/.pybuild/cpython3_3.8_texext/build; 
> python3.8 -m pytest 
> = test session starts 
> ==
> platform linux -- Python 3.8.6, pytest-4.6.11, py-1.9.0, pluggy-0.13.0
> rootdir: /<>
> collected 17 items
> 
> texext/tests/test_custom_plotcontext.py  [ 
> 23%]
> texext/tests/test_custom_plotdirective.py .. [ 
> 35%]
> texext/tests/test_docstrings.py ..   [ 
> 47%]
> texext/tests/test_mathdollar.py .[ 
> 52%]
> texext/tests/test_plotdirective.py   [ 
> 76%]
> texext/tests/test_tinypages.py F.F.  
> [100%]
> 
> === FAILURES 
> ===
> _ TestTinyPages.test_some_math 
> _
> 
> self = 
> 
> def test_some_math(self):
> assert isdir(self.out_dir)
> assert isdir(self.doctree_dir)
> doctree = self.get_doctree('some_math')
> assert len(doctree.document) == 1
> tree_str = self.doctree2str(doctree)
> if SPHINX_ge_1p5:
> back_ref = (
> 'Refers to equation at '
> ' 'refexplicit="False" reftarget="some-label" '
> 'reftype="eq" refwarn="True">'
> 

Bug#971208: python-dotenv: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 returned exit code 13

2020-09-27 Thread Lucas Nussbaum
Source: python-dotenv
Version: 0.9.1-1
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 --with python3 --buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_autoreconf -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
>   pybuild --configure --test-pytest -i python{version} -p 3.8
> I: pybuild base:217: python3.8 setup.py config 
> Pandoc not found. Long_description conversion failure.
> running config
>dh_auto_build -O--buildsystem=pybuild
>   pybuild --build --test-pytest -i python{version} -p 3.8
> I: pybuild base:217: /usr/bin/python3 setup.py build 
> Pandoc not found. Long_description conversion failure.
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.8_python-dotenv/build/dotenv
> copying dotenv/cli.py -> 
> /<>/.pybuild/cpython3_3.8_python-dotenv/build/dotenv
> copying dotenv/__init__.py -> 
> /<>/.pybuild/cpython3_3.8_python-dotenv/build/dotenv
> copying dotenv/compat.py -> 
> /<>/.pybuild/cpython3_3.8_python-dotenv/build/dotenv
> copying dotenv/ipython.py -> 
> /<>/.pybuild/cpython3_3.8_python-dotenv/build/dotenv
> copying dotenv/version.py -> 
> /<>/.pybuild/cpython3_3.8_python-dotenv/build/dotenv
> copying dotenv/main.py -> 
> /<>/.pybuild/cpython3_3.8_python-dotenv/build/dotenv
>dh_auto_test -O--buildsystem=pybuild
>   pybuild --test --test-pytest -i python{version} -p 3.8
> I: pybuild base:217: cd 
> /<>/.pybuild/cpython3_3.8_python-dotenv/build; python3.8 -m 
> pytest -k 'not test_default_path and not test_console_script'
> = test session starts 
> ==
> platform linux -- Python 3.8.6, pytest-4.6.11, py-1.9.0, pluggy-0.13.0
> rootdir: /<>, inifile: setup.cfg
> collected 41 items / 2 deselected / 39 selected
> 
> tests/test_cli.py F  [ 
> 43%]
> tests/test_core.py . [ 
> 97%]
> tests/test_utils.py .
> [100%]
> 
> === FAILURES 
> ===
> __ test_list_wo_file 
> ___
> 
> cli = 
> 
> def test_list_wo_file(cli):
> result = cli.invoke(dotenv_cli, ['--file', 'doesnotexists', 'list'])
> assert result.exit_code == 2, result.output
> >   assert 'Invalid value for "-f"' in result.output
> E   assert 'Invalid value for "-f"' in "Usage: cli [OPTIONS] COMMAND 
> [ARGS]...\nTry 'cli --help' for help.\n\nError: Invalid value for '-f' / 
> '--file': Path 'doesnotexists' does not exist.\n"
> E+  where "Usage: cli [OPTIONS] COMMAND [ARGS]...\nTry 'cli --help' 
> for help.\n\nError: Invalid value for '-f' / '--file': Path 'doesnotexists' 
> does not exist.\n" = .output
> 
> tests/test_cli.py:53: AssertionError
> === warnings summary 
> ===
> dotenv/main.py:17
>   
> /<>/.pybuild/cpython3_3.8_python-dotenv/build/dotenv/main.py:17: 
> DeprecationWarning: invalid escape sequence \$
> __posix_variable = re.compile('\$\{[^\}]*\}')
> 
> .pybuild/cpython3_3.8_python-dotenv/build/tests/test_cli.py::test_get_key
> .pybuild/cpython3_3.8_python-dotenv/build/tests/test_cli.py::test_set_key
>   
> /<>/.pybuild/cpython3_3.8_python-dotenv/build/dotenv/main.py:65: 
> UserWarning: File doesn't exist 
> /<>/.pybuild/cpython3_3.8_python-dotenv/build/tests/.env
> warnings.warn("File doesn't exist {}".format(self.dotenv_path))
> 
> .pybuild/cpython3_3.8_python-dotenv/build/tests/test_cli.py::test_get_key
> .pybuild/cpython3_3.8_python-dotenv/build/tests/test_cli.py::test_set_key
> .pybuild/cpython3_3.8_python-dotenv/build/tests/test_cli.py::test_unset
>   
> /<>/.pybuild/cpython3_3.8_python-dotenv/build/dotenv/main.py:111:
>  UserWarning: key HELLO not found in 
> /<>/.pybuild/cpython3_3.8_python-dotenv/build/tests/.env.
> warnings.warn("key %s not found in %s." % (key, self.dotenv_path))
> 
> .pybuild/cpython3_3.8_python-dotenv/build/tests/test_cli.py::test_get_key
> .pybuild/cpython3_3.8_python-dotenv/build/tests/test_cli.py::test_set_key
>   
> /<>/.pybuild/cpython3_3.8_python-dotenv/build/dotenv/main.py:132:
>  UserWarning: can't write to 
> /<>/.pybuild/cpython3_3.8_python-dotenv/build/tests/.env - it 
> doesn't exist.
> warnings.warn("can't write to %s - it doesn't exist." % dotenv_path)
> 
> .pybuild/cpython3_3.8_python-dotenv/build/tests/test_cli.py::test_set_key
>   
> /<>/.pybuild/cpython3_3.8_python-dotenv/build/dotenv/main.py:111:
>  UserWarning: key foo not found in 
> /<>/.pybuild/cpython3_3.8_python-dotenv/build/tests/.env.
> warnings.warn("key %s not found in %s." % (key, 

Bug#971185: pyqwt3d: FTBFS: sip: Unable to find file "QtCore/QtCoremod.sip"

2020-09-27 Thread Lucas Nussbaum
Source: pyqwt3d
Version: 0.1.8-5
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_testdir
> export QTDIR=/usr/share/qt5
> set -e ;\
> for py in 3.8 ; do \
>   mkdir -p build/py$py-qt5; \
>   cp -Rl `ls . |grep -v build|grep -v debian` build/py$py-qt5; \
>   (cd build/py$py-qt5/configure;\
>   python$py configure-qt5.py -5 -I /usr/include/qwtplot3d 
> --extra-libs=qwtplot3d-qt5 -D GL2PS_HAVE_ZLIB); \
> done
> sip: Deprecation warning: ../sip/OpenGL_Qt5_Module.sip:31: %Module version 
> number should be specified using the 'version' argument
> sip: Deprecation warning: ../sip/Qwt3D_Qt5_Module.sip:31: %Module version 
> number should be specified using the 'version' argument
> sip: Unable to find file "QtCore/QtCoremod.sip"
> Command line options:
> {'debug': False,
>  'disable_numarray': False,
>  'disable_numeric': False,
>  'disable_numpy': False,
>  'excluded_features': [],
>  'extra_cflags': [],
>  'extra_cxxflags': [],
>  'extra_defines': ['GL2PS_HAVE_ZLIB'],
>  'extra_include_dirs': ['/usr/include/qwtplot3d'],
>  'extra_lflags': [],
>  'extra_lib_dirs': [],
>  'extra_libs': ['qwtplot3d-qt5'],
>  'jobs': '',
>  'module_install_path': '',
>  'modules': [],
>  'qt': 5,
>  'qwtplot3d_sources': '',
>  'sip_include_dirs': ['-I ../sip'],
>  'subdirs': [],
>  'timelines': [],
>  'trace': '',
>  'zlib_sources': ''}
> 
> Found SIP-4.19.24.
> 
> Found 'posix' operating system:
> 3.8.6 (default, Sep 25 2020, 09:36:53) 
> [GCC 10.2.0]
> 
> Found NumPy-1.19.2.
> 
> Setup the OpenGL package build.
> -n PyQt5.sip -t Qt_5_14_0 -t WS_X11
> sip invokation:
> ('/usr/bin/sip -I /usr/share/sip/PyQt5 -n PyQt5.sip -t Qt_5_14_0 -t WS_X11 -b 
> '
>  'tmp-OpenGL_Qt5/OpenGL_Qt5.sbf -c tmp-OpenGL_Qt5   '
>  '../sip/OpenGL_Qt5_Module.sip')
> Copy tmp-OpenGL_Qt5/sipOpenGLcmodule.cpp -> OpenGL_Qt5/sipOpenGLcmodule.cpp.
> Copy tmp-OpenGL_Qt5/sipAPIOpenGL.h -> OpenGL_Qt5/sipAPIOpenGL.h.
> Copy tmp-OpenGL_Qt5/OpenGL_Qt5.sbf -> OpenGL_Qt5/OpenGL_Qt5.sbf.
> 3 file(s) lazily copied.
> Setup the Qwt3D package build.
> Extended options:
> {'debug': False,
>  'disable_numarray': False,
>  'disable_numeric': False,
>  'disable_numpy': False,
>  'excluded_features': ['-x HAS_QT3 -x HAS_QT4'],
>  'extra_cflags': [],
>  'extra_cxxflags': [],
>  'extra_defines': ['GL2PS_HAVE_ZLIB', 'HAS_NUMPY'],
>  'extra_include_dirs': ['/usr/include/qwtplot3d',
> '/usr/include/python3.8',
> '/usr/lib/python3/dist-packages/numpy/core/include',
> '/usr/include/x86_64-linux-gnu/qt5/Qt',
> '/usr/include/x86_64-linux-gnu/qt5/QtCore',
> '/usr/include/x86_64-linux-gnu/qt5/QtGui',
> '/usr/include/x86_64-linux-gnu/qt5/QtWidgets',
> '/usr/include/x86_64-linux-gnu/qt5/QtOpenGL',
> '/usr/include/x86_64-linux-gnu/qt5'],
>  'extra_lflags': [],
>  'extra_lib_dirs': [],
>  'extra_libs': ['qwtplot3d-qt5'],
>  'jobs': '',
>  'module_install_path': '/usr/lib/python3.8/dist-packages/PyQt5/Qwt3D',
>  'modules': [],
>  'opengl': 'OpenGL_Qt5',
>  'qt': 5,
>  'qwt3d': 'Qwt3D_Qt5',
>  'qwtplot3d_sources': '',
>  'sip_include_dirs': ['-I ../sip'],
>  'subdirs': ['Qwt3D_Qt5', 'OpenGL_Qt5'],
>  'timelines': [],
>  'trace': '',
>  'zlib_sources': ''}
> 
> sip invokation:
> ('/usr/bin/sip -I /usr/share/sip/PyQt5 -n PyQt5.sip -t Qt_5_14_0 -t WS_X11 -b 
> '
>  'tmp-Qwt3D_Qt5/qwt3d.sbf -c tmp-Qwt3D_Qt5   -I ../sip -x HAS_QT3 -x HAS_QT4 '
>  '../sip/Qwt3D_Qt5_Module.sip')
> 
> SIP failed to generate the C++ code.
> make: *** [debian/rules:25: configure-stamp] Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/pyqwt3d_0.1.8-5_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971186: haskell-gi-pango: FTBFS: Unknown GIR element "docsection" when processing namespace "GLib", aborting.

2020-09-27 Thread Lucas Nussbaum
Source: haskell-gi-pango
Version: 1.0.23-1
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):
> dpkg-buildpackage
> -
> 
> Command: dpkg-buildpackage -us -uc -sa -rfakeroot
> dpkg-buildpackage: info: source package haskell-gi-pango
> dpkg-buildpackage: info: source version 1.0.23-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Ilias Tsitsimpis 
> 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  debian/rules clean
> test -x debian/rules
> dh_clean 
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> clean_recipe
> Running rm -rf dist dist-ghc dist-ghcjs dist-hugs debian/hlibrary.setup 
> Setup.hi Setup.ho Setup.o .\*config\*
> Running rm -f configure-ghc-stamp configure-ghcjs-stamp build-ghc-stamp 
> build-ghcjs-stamp build-hugs-stamp build-haddock-stamp
> Running rm -rf debian/tmp-inst-ghc debian/tmp-inst-ghcjs
> Running rm -f debian/extra-depends-ghc debian/extra-depends-ghcjs
> Running rm -f debian/hlibrary.Makefile
> Running rm -rf debian/dh_haskell_shlibdeps
> Running rm -rf debian/tmp-db
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building haskell-gi-pango using existing 
> ./haskell-gi-pango_1.0.23.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: building haskell-gi-pango in 
> haskell-gi-pango_1.0.23-1.debian.tar.xz
> dpkg-source: info: building haskell-gi-pango in haskell-gi-pango_1.0.23-1.dsc
>  debian/rules binary
> test -x debian/rules
> dh_testroot
> dh_prep 
> dh_installdirs -A 
> mkdir -p "."
> CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
> CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> make_setup_recipe
> Running ghc --make Setup.hs -o debian/hlibrary.setup
> [1 of 1] Compiling Main ( Setup.hs, Setup.o )
> Linking debian/hlibrary.setup ...
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> configure_recipe
> Running debian/hlibrary.setup configure --ghc -v2 
> --package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
> --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
> --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro 
> --haddockdir=/usr/lib/ghc-doc/haddock/gi-pango-1.0.23/ --datasubdir=gi-pango 
> --htmldir=/usr/share/doc/libghc-gi-pango-doc/html/ --enable-library-profiling
> Using Parsec parser
> Unknown GIR element "docsection" when processing namespace "GLib", aborting.
> CallStack (from HasCallStack):
>   error, called at lib/Data/GI/CodeGen/API.hs:201:16 in 
> haskell-gi-0.24.4-GhfHY0VJtr89rHNQ5kPVxX:Data.GI.CodeGen.API
> make: *** [/usr/share/cdbs/1/class/hlibrary.mk:142: configure-ghc-stamp] 
> Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/haskell-gi-pango_1.0.23-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971192: thrift: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2

2020-09-27 Thread Lucas Nussbaum
Source: thrift
Version: 0.13.0-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):
> make[6]: Entering directory '/<>/lib/go'
> GOPATH=`pwd` /usr/bin/go test ./thrift
> # _/<>/lib/go/thrift
> thrift/field.go:58:83: conversion from int to string yields a string of one 
> rune, not a string of digits (did you mean fmt.Sprint(x)?)
> thrift/numeric.go:72:12: conversion from int64 to string yields a string of 
> one rune, not a string of digits (did you mean fmt.Sprint(x)?)
> thrift/json_protocol_test.go:612:92: conversion from int to string yields a 
> string of one rune, not a string of digits (did you mean fmt.Sprint(x)?)
> thrift/simple_json_protocol_test.go:685:96: conversion from int to string 
> yields a string of one rune, not a string of digits (did you mean 
> fmt.Sprint(x)?)
> FAIL  _/<>/lib/go/thrift [build failed]
> FAIL
> make[6]: *** [Makefile:825: check-local] Error 2
> make[6]: Leaving directory '/<>/lib/go'
> make[5]: *** [Makefile:694: check-am] Error 2
> make[5]: Leaving directory '/<>/lib/go'
> make[4]: *** [Makefile:542: check-recursive] Error 1
> make[4]: Leaving directory '/<>/lib/go'
> make[3]: *** [Makefile:585: check-recursive] Error 1
> make[3]: Leaving directory '/<>/lib'
> make[2]: *** [Makefile:687: check-recursive] Error 1
> make[2]: Leaving directory '/<>'
> dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/thrift_0.13.0-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971174: strophejs: FTBFS: Error: Cannot find module '/usr/lib/nodejs/requirejs/r.js'

2020-09-27 Thread Lucas Nussbaum
Source: strophejs
Version: 1.2.14+dfsg-5
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):
> make[1]: Entering directory '/<>'
> node /usr/lib/nodejs/requirejs/r.js -o build.js 
> name=/usr/share/nodejs/almond/almond.js insertRequire=strophe-polyfill 
> include=strophe-polyfill out=strophe.min.js
> internal/modules/cjs/loader.js:968
>   throw err;
>   ^
> 
> Error: Cannot find module '/usr/lib/nodejs/requirejs/r.js'
> at Function.Module._resolveFilename 
> (internal/modules/cjs/loader.js:965:15)
> at Function.Module._load (internal/modules/cjs/loader.js:841:27)
> at Function.executeUserEntryPoint [as runMain] 
> (internal/modules/run_main.js:71:12)
> at internal/main/run_main_module.js:17:47 {
>   code: 'MODULE_NOT_FOUND',
>   requireStack: []
> }
> make[1]: *** [debian/rules:17: override_dh_auto_build] Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/strophejs_1.2.14+dfsg-5_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971171: libvirt-dbus: FTBFS: dh_auto_test: error: cd debian/build && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 ninja test returned exit code 1

2020-09-27 Thread Lucas Nussbaum
Source: libvirt-dbus
Version: 1.4.0-1
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):
> make[1]: Entering directory '/<>'
> dh_auto_configure -- \
>   -Dsystem_user=libvirtdbus
>   cd debian/build && LC_ALL=C.UTF-8 meson ../.. --wrap-mode=nodownload 
> --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir=/var 
> --libdir=lib/x86_64-linux-gnu -Dsystem_user=libvirtdbus
> The Meson build system
> Version: 0.55.3
> Source dir: /<>
> Build dir: /<>/debian/build
> Build type: native build
> Project name: libvirt-dbus
> Project version: 1.4.0
> Using 'CFLAGS' from environment with value: '-g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro -Wl,-z,now'
> Using 'CPPFLAGS' from environment with value: '-Wdate-time 
> -D_FORTIFY_SOURCE=2'
> Using 'CFLAGS' from environment with value: '-g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security'
> Using 'LDFLAGS' from environment with value: '-Wl,-z,relro -Wl,-z,now'
> Using 'CPPFLAGS' from environment with value: '-Wdate-time 
> -D_FORTIFY_SOURCE=2'
> C compiler for the host machine: cc (gcc 10.2.0 "cc (Debian 10.2.0-9) 10.2.0")
> C linker for the host machine: cc ld.bfd 2.35.1
> Host machine cpu family: x86_64
> Host machine cpu: x86_64
> Found pkg-config: /usr/bin/pkg-config (0.29.2)
> Run-time dependency gio-unix-2.0 found: YES 2.66.0
> Run-time dependency glib-2.0 found: YES 2.66.0
> Run-time dependency libvirt found: YES 6.6.0
> Run-time dependency libvirt-glib-1.0 found: YES 3.0.0
> Compiler for C supports arguments -W: YES 
> Compiler for C supports arguments -Waddress: YES 
> Compiler for C supports arguments -Waggressive-loop-optimizations: YES 
> Compiler for C supports arguments -Wall: YES 
> Compiler for C supports arguments -Warray-bounds=2: YES 
> Compiler for C supports arguments -Wattributes: YES 
> Compiler for C supports arguments -Wbad-function-cast: YES 
> Compiler for C supports arguments -Wbool-compare: YES 
> Compiler for C supports arguments -Wbuiltin-macro-redefined: YES 
> Compiler for C supports arguments -Wcast-align: YES 
> Compiler for C supports arguments -Wchar-subscripts: YES 
> Compiler for C supports arguments -Wclobbered: YES 
> Compiler for C supports arguments -Wcomment: YES 
> Compiler for C supports arguments -Wcomments: YES 
> Compiler for C supports arguments -Wcoverage-mismatch: YES 
> Compiler for C supports arguments -Wcpp: YES 
> Compiler for C supports arguments -Wdate-time: YES 
> Compiler for C supports arguments -Wdeprecated-declarations: YES 
> Compiler for C supports arguments -Wdesignated-init: YES 
> Compiler for C supports arguments -Wdiscarded-array-qualifiers: YES 
> Compiler for C supports arguments -Wdiscarded-qualifiers: YES 
> Compiler for C supports arguments -Wdiv-by-zero: YES 
> Compiler for C supports arguments -Wdouble-promotion: YES 
> Compiler for C supports arguments -Wduplicated-cond: YES 
> Compiler for C supports arguments -Wempty-body: YES 
> Compiler for C supports arguments -Wendif-labels: YES 
> Compiler for C supports arguments -Wextra: YES 
> Compiler for C supports arguments -Wformat: YES 
> Compiler for C supports arguments -Wformat-contains-nul: YES 
> Compiler for C supports arguments -Wformat-extra-args: YES 
> Compiler for C supports arguments -Wformat-nonliteral: YES 
> Compiler for C supports arguments -Wformat-security: YES 
> Compiler for C supports arguments -Wformat-y2k: YES 
> Compiler for C supports arguments -Wformat-zero-length: YES 
> Compiler for C supports arguments -Wframe-address: YES 
> Compiler for C supports arguments -Wframe-larger-than=1024: YES 
> Compiler for C supports arguments -Wfree-nonheap-object: YES 
> Compiler for C supports arguments -Whsa: YES 
> Compiler for C supports arguments -Wignored-attributes: YES 
> Compiler for C supports arguments -Wignored-qualifiers: YES 
> Compiler for C supports arguments -Wimplicit: YES 
> Compiler for C supports arguments -Wimplicit-function-declaration: YES 
> Compiler for C supports arguments -Wimplicit-int: YES 
> Compiler for C supports arguments -Wincompatible-pointer-types: YES 
> Compiler for C supports arguments -Winit-self: YES 
> Compiler for C supports arguments -Winline: YES 
> Compiler for C supports arguments -Wint-conversion: YES 
> Compiler for C supports arguments -Wint-to-pointer-cast: YES 
> Compiler for C supports arguments -Winvalid-memory-model: YES 
> Compiler for C supports arguments -Winvalid-pch: YES 
> Compiler for C supports arguments -Wjump-misses-init: YES 
> Compiler for C supports arguments -Wlogical-not-parentheses: YES 
> Compiler for C supports arguments -Wlogical-op: YES 
> Compiler for C supports arguments -Wmain: YES 
> Compiler for C 

Bug#971180: ipython: FTBFS: Could not import extension IPython.sphinxext.ipython_console_highlighting (exception: No module named 'decorator')

2020-09-27 Thread Lucas Nussbaum
Source: ipython
Version: 7.18.1-1
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):
> make[1]: Entering directory '/<>'
> http_proxy=127.0.0.1:9 https_proxy=127.0.0.1:9 PYTHONPATH=. python3 -m sphinx 
> -b html docs/source 
> debian/python-ipython-doc/usr/share/doc/python-ipython-doc/html
> Running Sphinx v3.2.1
> 
> Extension error:
> Could not import extension IPython.sphinxext.ipython_console_highlighting 
> (exception: No module named 'decorator')
> Adding Tag: ipystable
> make[1]: *** [debian/rules:22: override_dh_sphinxdoc] Error 2

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/ipython_7.18.1-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



Bug#971177: intake: FTBFS: TypeError: 'NoneType' object is not iterable

2020-09-27 Thread Lucas Nussbaum
Source: intake
Version: 0.6.0-3
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):
> make[1]: Entering directory '/<>'
> dh_auto_build
> I: pybuild base:217: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.8_intake/build/intake
> copying intake/__init__.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake
> copying intake/util_tests.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake
> copying intake/compat.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake
> copying intake/_version.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake
> copying intake/conftest.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake
> copying intake/config.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake
> copying intake/utils.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake
> creating /<>/.pybuild/cpython3_3.8_intake/build/intake/catalog
> copying intake/catalog/default.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/catalog
> copying intake/catalog/__init__.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/catalog
> copying intake/catalog/local.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/catalog
> copying intake/catalog/gui.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/catalog
> copying intake/catalog/entry.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/catalog
> copying intake/catalog/remote.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/catalog
> copying intake/catalog/zarr.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/catalog
> copying intake/catalog/exceptions.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/catalog
> copying intake/catalog/base.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/catalog
> copying intake/catalog/utils.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/catalog
> creating /<>/.pybuild/cpython3_3.8_intake/build/intake/container
> copying intake/container/semistructured.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/container
> copying intake/container/__init__.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/container
> copying intake/container/dataframe.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/container
> copying intake/container/serializer.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/container
> copying intake/container/ndarray.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/container
> copying intake/container/base.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/container
> copying intake/container/persist.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/container
> creating /<>/.pybuild/cpython3_3.8_intake/build/intake/tests
> copying intake/tests/test_top_level.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/tests
> copying intake/tests/__init__.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/tests
> copying intake/tests/test_utils.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/tests
> copying intake/tests/test_config.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/tests
> creating /<>/.pybuild/cpython3_3.8_intake/build/intake/source
> copying intake/source/csv.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/source
> copying intake/source/cache.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/source
> copying intake/source/decompress.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/source
> copying intake/source/__init__.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/source
> copying intake/source/discovery.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/source
> copying intake/source/textfiles.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/source
> copying intake/source/zarr.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/source
> copying intake/source/base.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/source
> copying intake/source/utils.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/source
> copying intake/source/npy.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/source
> creating /<>/.pybuild/cpython3_3.8_intake/build/intake/auth
> copying intake/auth/secret.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/auth
> copying intake/auth/__init__.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/auth
> copying intake/auth/base.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/auth
> creating /<>/.pybuild/cpython3_3.8_intake/build/intake/gui
> copying intake/gui/__init__.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/gui
> copying intake/gui/gui.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/gui
> copying intake/gui/conftest.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/gui
> copying intake/gui/base.py -> 
> /<>/.pybuild/cpython3_3.8_intake/build/intake/gui
> copying 

Bug#971175: haskell-gi-gobject: FTBFS: Unknown GIR element "docsection" when processing namespace "GObject", aborting.

2020-09-27 Thread Lucas Nussbaum
Source: haskell-gi-gobject
Version: 2.0.24-1
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):
> dpkg-buildpackage
> -
> 
> Command: dpkg-buildpackage -us -uc -sa -rfakeroot
> dpkg-buildpackage: info: source package haskell-gi-gobject
> dpkg-buildpackage: info: source version 2.0.24-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Ilias Tsitsimpis 
> 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  debian/rules clean
> test -x debian/rules
> dh_clean 
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> clean_recipe
> Running rm -rf dist dist-ghc dist-ghcjs dist-hugs debian/hlibrary.setup 
> Setup.hi Setup.ho Setup.o .\*config\*
> Running rm -f configure-ghc-stamp configure-ghcjs-stamp build-ghc-stamp 
> build-ghcjs-stamp build-hugs-stamp build-haddock-stamp
> Running rm -rf debian/tmp-inst-ghc debian/tmp-inst-ghcjs
> Running rm -f debian/extra-depends-ghc debian/extra-depends-ghcjs
> Running rm -f debian/hlibrary.Makefile
> Running rm -rf debian/dh_haskell_shlibdeps
> Running rm -rf debian/tmp-db
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building haskell-gi-gobject using existing 
> ./haskell-gi-gobject_2.0.24.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: building haskell-gi-gobject in 
> haskell-gi-gobject_2.0.24-1.debian.tar.xz
> dpkg-source: info: building haskell-gi-gobject in 
> haskell-gi-gobject_2.0.24-1.dsc
>  debian/rules binary
> test -x debian/rules
> dh_testroot
> dh_prep 
> dh_installdirs -A 
> mkdir -p "."
> CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
> CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> make_setup_recipe
> Running ghc --make Setup.hs -o debian/hlibrary.setup
> [1 of 1] Compiling Main ( Setup.hs, Setup.o )
> Linking debian/hlibrary.setup ...
> . /usr/share/haskell-devscripts/Dh_Haskell.sh && \
> configure_recipe
> Running debian/hlibrary.setup configure --ghc -v2 
> --package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
> --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
> --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro 
> --haddockdir=/usr/lib/ghc-doc/haddock/gi-gobject-2.0.24/ 
> --datasubdir=gi-gobject --htmldir=/usr/share/doc/libghc-gi-gobject-doc/html/ 
> --enable-library-profiling
> Using Parsec parser
> Unknown GIR element "docsection" when processing namespace "GObject", 
> aborting.
> CallStack (from HasCallStack):
>   error, called at lib/Data/GI/CodeGen/API.hs:201:16 in 
> haskell-gi-0.24.4-GhfHY0VJtr89rHNQ5kPVxX:Data.GI.CodeGen.API
> make: *** [/usr/share/cdbs/1/class/hlibrary.mk:142: configure-ghc-stamp] 
> Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/09/26/haskell-gi-gobject_2.0.24-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



  1   2   3   >