Bug#978310: umockdev: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 ninja test returned exit code 1

[Martin Pitt]

Control: tag -1 fixed-upstream pending
Control: forwarded -1 https://github.com/martinpitt/umockdev/issues/115

Hello Lucas,

Lucas Nussbaum [2020-12-26 22:57 +0100]:
> > Bail out! ERROR:../tests/test-umockdev.c:1135:t_testbed_usb_lsusb: 
> > assertion failed (exit_status == 0): (256 == 0)

I noticed that a few days as well, and someone else also noticed in 
https://github.com/martinpitt/umockdev/issues/115

The fix is already upstream, I'll do a new release ASAP.

Thanks for your report and your continous rebuild efforts! These are much
appreciated.

Martin

Bug#978171: aptitude: FTBFS: pkgcachegen.h:32:10: fatal error: xxhash.h: No such file or directory

[Sven Joachim]

On 2020-12-26 23:15 +0100, Axel Beckert wrote:

> Sven Joachim wrote:
>> > Looks like a missing dependency on libxxhash-dev on a first glance.
>> >
>> > Will check if that helps. (And I wonder where that one got lost.)
>>
>> It did not get lost, rather I suppose that the latest apt upload
>> introduced this new include without adding a proper dependency on
>> libxxhash-dev to libapt-pkg-dev.
>
> That's what I meant with "got lost" more or less. Thanks!
>
> So this should be fixed in src:apt then? (Cc'ing our deities. ;-)

Yes, there were at least three other bugs with the same problem, and one
of them had already been reassigned to libapt-pkg-dev.  I have merged
them all now.

Cheers,
   Sven

Bug#710938: Packard Bell EasyNote LV need i915.invert_brightness on Linux

[Petter Reinholdtsen]

For the record, I reinstalled the machine in question with Ubuntu
18.04 a few days ago, and upgraded it since to 20.04, and the
problem was not present there.

This make me suspect this issue is fixed in kernel 5.4.0
and possible earlier versions.

I am unable to test with a Debian kernel. :(

-- 
Happy hacking
Petter Reinholdtsen

Bug#928436: cracklib2 NMU with delay 10

[Martin Pitt]

Hello Helmut,

Helmut Grohne [2020-12-26 17:39 +0100]:
> given the prolonged silence on these bugs, I've uploaded a NMU with
> delay 10 fixing both and adding a Multi-Arch stanza. All of the changes
> seem quite safe to me. I've performed local test builds for various
> configurations (nocheck, nopython, cross, ...). A .debdiff of the
> proposed changes is attached. Please let me know if I should delay this
> any longer.

Thanks for the fixes! These look good to me, no objections from my side to not
just upload this with a smaller or no delay. Jan has the last word on this,
though.

Happy holidays,

Martin

Bug#978107: gajim: Crashes when video preview is turned off in settings dialog window

[Bruno Kleinert]

Am Samstag, dem 26.12.2020 um 13:35 +0100 schrieb Martin:
> On 2020-12-26 06:02, Bruno Kleinert wrote:
> > when I enter gajim's settings window (keyboard shortcut Ctrl+P), go to tab
> > 'Audio/Video' and check and uncheck the 'Live preview" checkbox, gajim
> > reproducibly crashes. Selecting different video input sources does not make 
> > a
> > difference.
> 
> It doesn't crash for me, but I'm already on 1.2.91+20201127.866fb9c1-1
> (local packaging), so there is a chance, that it is already fixed by
> upstream and the fix will be in the next release.

Alright, I'll check a newer version when it's available in the archive.

> 
> An (unrelated) observation:
> 
> > 26.12.2020 05:46:01 (E) gajim.p.previewError loading css: 
> > [Errno 2]
> > Datei oder Verzeichnis nicht gefunden: '/usr/lib/python3/dist-
> > packages/gajim/data/plugins/url_image_preview/preview.css'
> 
> Is gajim-urlimagepreview installed?

Yes, gajim-urlimagepreview 2.4.5-2 is installed. Is that an issue?


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

Bug#978022: libopenmpi3 Runtime failure opal_pmix_base_select failed

[Lucas Nussbaum]

Hi,

On 24/12/20 at 17:16 +0100, Michael Banck wrote:
> Package: libopenmpi3
> Version: 3.1.3-11
> Severity: serious
> 
> Even with the fixed libpmix2_4.0.0~rc1-2, I am getting runtime failures
> trying to run MPI programs, e.g. the nwchem autopkgtests all fail like
> this:

A simple way to reproduce is:

$ mpiexec -n 1 true
[groff:16932] [[40958,0],0] ORTE_ERROR_LOG: Not found in file 
../../../../../../orte/mca/ess/hnp/ess_hnp_module.c at line 320
--
It looks like orte_init failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems.  This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):

  opal_pmix_base_select failed
  --> Returned value Not found (-13) instead of ORTE_SUCCESS
--

It happens with those versions:

$ dpkg -l |grep -e openmpi -e pmi
ii  libopenmpi3:amd64 4.1.0-1  amd64
high performance message passing library -- shared library
ii  libpmix2:amd644.0.0~rc1-2  amd64
Process Management Interface (Exascale) library
ii  openmpi-bin   4.1.0-1  amd64
high performance message passing library -- binaries
ii  openmpi-common4.1.0-1  all  
high performance message passing library -- common files

It doesn't fail after downgrading openmpi to the version in testing
(4.0.5-7)

Lucas

Bug#941170: pulseaudio: Microphone audio is mixed with headset audio

[Chandra Sekar S]

I too face this issue on Debian testing with pulseaudio 13.0-5 installed.

$ lspci | fgrep -i audio
00:1f.3 Audio device: Intel Corporation Cannon Point-LP High Definition
Audio Controller (rev 30)

Bug#978045: apache2-bin: Immediate exit with "AH00141: Could not initialize random number generator"

[Ondřej Surý]

I believe it’s a reasonable assumption that the kernel matches the Debian 
release. If anybody is running with old kernel or disables getrandom I would 
say they are on their own - also other stuff will break, not only apache2.

Ondrej
--
Ondřej Surý  (He/Him)

> On 27. 12. 2020, at 0:24, Stefan Fritsch  wrote:
> 
> reassign 978045 libapr1
> found 978045 1.7.0-1
> thanks
> 
>> Am 25.12.20 um 03:18 schrieb David W:
>> You can see that the associated call/failure is happening inside APR here, on
>> line 216:
>> https://svn.apache.org/viewvc/apr/apr/trunk/misc/unix/rand.c?revision=1832691=markup#l216
>>  
>> 
>> The issue is that if the library is configured (at build time) to
>> USE_GETRANDOM, then it assumes that the getrandom() call will be available 
>> and
>> if it fails it becomes a fatal error. On my system, I don't have getrandom()
>> because I'm running an ancient kernel, but others could (more legitimately)
>> have the option disabled on a recent custom-built kernel.
>> I think the correct fix is to not use that build-time option, and go back to
>> using DEV_RANDOM or whatever was being used previously. Alternatively, at
>> least document that a kernel with getrandom() support is required to use
>> apache2.
>> I'm not sure exactly when the packaging on this changed, but I know it was
>> broken in 2.4.46-1 and I *think* it worked in 2.4.43-1, although I can't get 
>> a
>> copy of that to double-check anymore.
> 
> This changed in libapr1 1.7, re-assigning to apr. I am not sure about the 
> severity, though. According to the man page, getrandom has been introduced in 
> linux 3.17. Debian 9 already has 4.9 so you have to have a kernel that is 
> from Debian 8 to be affected by this.
> 

Bug#978413: src:chasquid: fails to migrate to testing for too long: Build-Depends on non-migrating package

[Paul Gevers]

Source: chasquid
Version: 1.3-1
Severity: serious
Control: close -1 1.5-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 961814

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#978412: src:picolibc: fails to migrate to testing for too long: maintainer built arch:all binaries

[Paul Gevers]

Source: picolibc
Version: 1.4.6-1
Severity: serious
Control: close -1 1.4.7-1
Tags: sid bullseye pending
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:picolibc 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.

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#978411: src:golang-gopkg-lxc-go-lxc.v2: fails to migrate to testing for too long: maintainer built arch:all binary

[Paul Gevers]

Source: golang-gopkg-lxc-go-lxc.v2
Version: 0.0+git20190625.f4822c6-1
Severity: serious
Control: close -1 0.0+git20201012.d1943fb-1
Tags: sid bullseye pending
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:golang-gopkg-lxc-go-lxc.v2 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.

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#978410: src:pipemeter: fails to migrate to testing for too long: FTBFS everywhere

[Paul Gevers]

Source: pipemeter
Version: 1.1.3-1
Severity: serious
Control: close -1 1.1.4-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 972958

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:pipemeter in
its current version in unstable has been trying to migrate for 63 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=pipemeter




OpenPGP_signature
Description: OpenPGP digital signature

Bug#978099: Please add support for riscv64

[Sebastiaan Couwenberg]

On 12/27/20 12:13 AM, Aurelien Jarno wrote:
> On 2020-12-26 08:05, Sebastiaan Couwenberg wrote:
>> On 12/25/20 11:17 PM, Logan Rosen wrote:
>>> libhdf4 currently FTBFS on riscv64. William Grant applied a patch in
>>> Ubuntu to add support for the architecture.
>>>
>>> Thanks for considering the patch.
>>
>> Thanks for the patch, it failed to apply, however. The existing patches
>> have been updated manually.
> 
> Thanks Logan for submitting the patch and Sebastiaan for applying it.
> This patch has been taken from debian-ports, however in the meantime we
> got an updated version that makes the testsuite to pass. Please find
> attach an update against the current diff. Could you please apply it?

Thanks for the additional patch, it's also applied in git.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#976913: golang-github-henrydcase-nobs: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_build: error: cd obj-powerpc64le-linux-gnu && go install -trimpath -v -p 160

[Roger Shimizu]

forwarded -1 https://github.com/henrydcase/nobs/issues/37

from upstream:
> only x86-64 and aarch64 is currently supported. why would you need i386 
> exactly?

So currently maybe we can only build for amd64 and arm64.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#978236: otb: FTBFS: unsatisfiable build-dependency: libnifti-dev (versioned dep on a virtual pkg?)

[Sebastiaan Couwenberg]

reassign 978236 src:insighttoolkit4
found 978236 insighttoolkit4/4.13.3withdata-dfsg1-3
affects 978236 src:otb
thanks

On 12/26/20 10:40 PM, Lucas Nussbaum wrote:
>> The following packages have unmet dependencies:
>>  libinsighttoolkit4-dev : Depends: libnifti-dev

This is not an issue in otb, but in insighttoolkit4, reassigning
accordingly. More specifically it's caused by the package split in
nifticlib (3.0.1-1) to fix #968730.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#978109: ITP: elpa-ligature -- display typographical ligatures in Emacs major modes

[Axel Beckert]

Hi,

Axel Beckert wrote:
> I intent to maintain this package under the umbrella of the Debian
> Emacsen Team (X-Debbugs-CC'ed). Until I get Salsa write access to their
> repos, I published my work temporarily at
> https://salsa.debian.org/abe/elpa-ligature

The repo has been moved to
https://salsa.debian.org/emacsen-team/elpa-ligature

I just uploaded the first version to Debian Experimental and it should
show up in the NEW queue within an hour or so.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#958117: uglifyjs: dead code: keep away from bullseye

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2020-04-18 19:02:15)
> UglifyJS 2 is dead upstream (no code commit since June 2017).
> 
> These packages will *not* be part of Bullseye:
> 
> src:uglifyjs
> libjs-uglify
> node-uglify
> 
> Projects now using UglifyJS 2 can either upgrade to UglifyJS 3 or 
> migrate to terser.
> 
> UglifyJS 3 has far fewer reverse dependencies than terser, and is 
> therefore more likely to be kept at newest release and is less likely 
> to be problematic to backport than terser.
> 
> UglifyJS 3 supports only EcmaScript 5, so more modern code need to use 
> Babel so "dumb down" code first, where terser can process more modern 
> dialects directly.
> 
> 
> These packages are part of UglifyJS 3:
> 
> src:uglify-js
> libjs-uglify-js
> node-uglify-js
> uglifyjs
> 
> These packages are part of terser:
> 
> src:node-terser
> node-terser
> uglifyjs.terser

Other alternatives include babel-minify ans esbuild.

I have now removed myself as uploader for src:uglifyjs.

See bug#968137 for the worrying amount of reverse package relations.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#978409: emacs-gtk: Cherry-pick upstream fix for "Attempt to shape unibyte text" crashes

[Axel Beckert]

Package: emacs-gtk
Version: 1:27.1+1-3
Severity: wishlist
Tags: patch fixed-upstream
Control: affects -1 elpa-ligature

Dear Rob,

I'm currently packaging ligature.el from
https://github.com/mickeynp/ligature.el at
https://salsa.debian.org/emacsen-team/elpa-ligature

According to
https://github.com/mickeynp/ligature.el#crash-issues-in-emacs-271 a fix
for occasional Emacs crashes with error message "Attempt to shape
unibyte text" when using ligature.el is available in upstream git, but
hasn't made it into the 27.1 upstream release:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=fe903c5ab7354b97f80ecf1b01ca3ff1027be446

It would be nice if you could cherry-pick this commit until the next
upstream release.

If you don't want to cherry-pick that commit, please at least keep this
bug report open for now and close it only with the upload of the next
Emacs upstream release which contains the above mentioned patch,
presumably 27.2.

Thanks in advance!

-- 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.9.0-4-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 emacs-gtk depends on:
ii  emacs-bin-common   1:27.1+1-3
ii  emacs-common   1:27.1+1-3
ii  libacl12.2.53-9
ii  libasound2 1.2.4-1
ii  libc6  2.31-6
ii  libcairo2  1.16.0-4
ii  libdbus-1-31.12.20-1
ii  libelogind0 [libsystemd0]  246.9.1-1+debian1
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.4+dfsg-1
ii  libgdk-pixbuf2.0-0 2.40.2-2
ii  libgif75.1.9-1
ii  libglib2.0-0   2.66.4-1
ii  libgmp10   2:6.2.1+dfsg-1
ii  libgnutls303.7.0-3
ii  libgpm21.20.7-6
ii  libgtk-3-0 3.24.24-1
ii  libharfbuzz0b  2.6.7-1
ii  libice62:1.0.10-1
ii  libjansson42.13.1-1
ii  libjpeg62-turbo1:2.0.5-1.1
ii  liblcms2-2 2.9-4+b1
ii  libm17n-0  1.8.0-2
ii  libotf00.9.13-7
ii  libpango-1.0-0 1.46.2-3
ii  libpng16-161.6.37-3
ii  librsvg2-2 2.50.2+dfsg-1
ii  libselinux13.1-2+b2
ii  libsm6 2:1.2.3-1
ii  libtiff5   4.2.0-1
ii  libtinfo6  6.2+20201114-1
ii  libx11-6   2:1.6.12-1
ii  libxext6   2:1.3.3-1.1
ii  libxfixes3 1:5.0.3-2
ii  libxml22.9.10+dfsg-6.3+b1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.11.dfsg-2

emacs-gtk recommends no packages.

Versions of packages emacs-gtk suggests:
pn  emacs-common-non-dfsg  

-- no debconf information

Bug#972574: libgit2: merge request with a proposition

[Utkarsh Gupta]

Hi Cédric,

On Sun, Dec 27, 2020 at 2:57 AM Cédric Boutillier  wrote:
> I've just created a merge request on salsa
> https://salsa.debian.org/debian/libgit2/-/merge_requests/3
> with a proposition.
> This adds an extra libgit2-fixtures binary package, shipping the
> examples under tests/resources in
> /usr/share/doc/libgit2-fixtures/examples.
>
> Feel free to suggest another path if you think it is more appropriate.
>
> This allows me to run correctly the testsuite of ruby-rugged, once
> indicating the correct location of libgit2 fixtures directory.

This is great, thank you so much for working on this! \o/
I've merged the MR and uploaded to NEW!


- u

Bug#977900: node-autoprefixer: FTBFS: ENOENT: no such file or directory, open 'path'

[Akshay S Dinesh]

A few observations.

1) The commit 
https://github.com/rollup/plugins/commit/1459cf0ab5e5eb7beee46f52bc4dbbb88d3e4335#diff-c68d63c5e10e04a850c0ea8abd479dbb77c794b3aadecf91483dcf3df96156df 
which prevents exceptions from being silently ignored maybe the reason 
why this is starting to err.



2) See this build log: 
https://salsa.debian.org/js-team/node-autoprefixer/-/jobs/1280125


Line 1757 has the dh_auto_configure output

   dh_auto_configure --buildsystem=nodejs -O--package=node-autoprefixer
mkdir node_modules
ln -s ../fractionjs node_modules/fraction.js
   debian/rules override_dh_auto_build

It only symlinks fractionjs.

I don't really read perl, but I think 
https://salsa.debian.org/js-team/pkg-js-tools/-/blob/master/lib/Debian/Debhelper/Buildsystem/nodejs.pm#L128 
says this:


next if $self->main_package and $component eq $self->main_package;

which probably means it will skip a component of the same name as the 
package. Here, component autoprefixer is probably clashing with the name 
"node-autoprefixer".


On line 1770 this causes

(!) Circular dependency
autoprefixer.js -> autoprefixer.js

where another filename clash makes import from "autoprefixer" to resolve 
to build/autoprefixer.js (probably because it doesn't have an 
autoprefixer in node_modules because of dh_auto_configure above)


3) 
https://salsa.debian.org/js-team/node-autoprefixer/-/blob/master/debian/patches/rearrange-plugins-order.patch 
seems to revert the changes to 
nodeResolve.customResolveOptions.moduleDirectory in the first patch.


Akshay

Bug#977988: /usr/bin/spectacle: does not start (libkImageAnnotator.so.0.3.2 not found)

[Boyuan Yang]

X-Debbugs-CC: p...@debian.org
On Wed, 23 Dec 2020 23:51:57 +0100 Pino Toscano 
wrote:
> reassign 977988 src:kimageannotator
> forcemerge 977649 977988
> thanks
> 
> In data mercoledì 23 dicembre 2020 22:26:13 CET, Dominik George ha
scritto:
> > Package: kde-spectacle
> > Version: 20.12.0-1
> > Severity: grave
> > File: /usr/bin/spectacle
> > Justification: renders package unusable
> > 
> > After a recent update, spectacle stoppede working, and errors out
on start with:
> > 
> >   spectacle: error while loading shared libraries:
libkImageAnnotator.so.0.3.2: cannot open shared object file: No such
file or directory
> > 
> > Maybe it needs a binNMU?
> 
> No, it needs a fixed SONAME and a fixed Debian package name matching
> it. See also #977649 (which this bug will be merged to).
> 
> In the meanwhile, I will disable the kimageannotator-related
features,
> as at least there will be a functional Spectacle.

Hi,

Since the upstream of kImageAnnotator has merged the proposed fix in
https://github.com/ksnip/kImageAnnotator/issues/185 , I have cherry-
picked the corresponding fixes in kimageannotator/0.4.0-2 as well as in
kcolorpicker. With the new version, the SONAME should be correctly set
to libkimageannotator0 this time.

I was aware of this issue when packaging the
kcolorpicker/kimageannotator/ksnip software chain but didn't have the
chance to work on fixing it since I treated the libraries as somewhat
private libs that solely serves the purpose of supporting ksnip. In
that case, I manually rebuild all packages follows the dependency chain
and raise version requirements to make sure all packages are
functioning. Since newer spectacle is also using these libraries, it's
time to implement SONAME formally. Thanks for your investigation and
patch!

Please test whether current kimageannotator is working after
kimageannotator/0.4.0-2 is available in Sid. After that, we will need
either a binNMU or a sourceful upload to let spectacle catch the
correct library file. Let me know if there's still any issues.

-- 
Thanks,
Boyuan Yang


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

Bug#975613: android-libboringssl: adb crashes with "invalid pointer" error

[Kurt Meyer]

Version 8.1.0 of android-libboringssl is also broken; ref bug report #933865 - 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933865.

Bug#963122: bucklespring: error loading shared objectfile

[Axel Beckert]

Control: reassign -1 libalure1
Control: forcemerge 960707 -1
Control: tag -1 + confirmed
Control: affects -1 + bucklespring

Hi,

jan de kruyf wrote in June 2020:
> Error loading libfluidsynth.so.1: libfluidsynth.so.1: cannot open shared 
> object
> file: No such file or directory

Just ran into the same issue. The second line only seems to come when
you run it the first time or so. At least I did get this line on my a
few tries today, but I cannot reproduce that second line when running
under strace. That part might be a coincidence or some kind of
heisenbug.

> But the program seems to run normally.

Can confirm. (Just had to turn up the volume to notice that it
nevertheless works. :-)

> I did
> jan@snowflake:~$ ldd /usr/games/buckle

So libfluidsynth does not appear in there. Strange. Maybe from another
program which is called by buckle?

An strace though shows that it's indeed trying to find that file in
quite some locations:

→ strace -e file -f buckle |& fgrep libfluidsynth.so
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/haswell/x86_64/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/haswell/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/x86_64/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/haswell/x86_64/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/haswell/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/x86_64/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/usr/lib/x86_64-linux-gnu/tls/haswell/x86_64/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/tls/haswell/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/tls/x86_64/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/tls/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/haswell/x86_64/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/haswell/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/x86_64/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/tls/haswell/x86_64/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/tls/haswell/libfluidsynth.so.1", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/tls/x86_64/libfluidsynth.so.1", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/tls/libfluidsynth.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
openat(AT_FDCWD, "/lib/haswell/x86_64/libfluidsynth.so.1", O_RDONLY|O_CLOEXEC) 
= -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/haswell/libfluidsynth.so.1", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64/libfluidsynth.so.1", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/libfluidsynth.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
such file or directory)
openat(AT_FDCWD, "/usr/lib/tls/haswell/x86_64/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/tls/haswell/libfluidsynth.so.1", O_RDONLY|O_CLOEXEC) 
= -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/tls/x86_64/libfluidsynth.so.1", O_RDONLY|O_CLOEXEC) 
= -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/tls/libfluidsynth.so.1", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/haswell/x86_64/libfluidsynth.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/haswell/libfluidsynth.so.1", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
penat(AT_FDCWD, "/usr/lib/x86_64/libfluidsynth.so.1", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/libfluidsynth.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)

Bug#978086: xscreensaver: should use scalable fonts by default and not depend on bitmap fonts

[Jamie Zawinski]

So, on your system where:

- xfonts-100dpi is not installed
- gsfonts-x11 is installed
- xterm uses Helvetica with: -fn 
'-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1'

What do you get from:

find /usr -name '*helvB18*'
find /usr -name fonts.dir | xargs grep -i 'helvetica-bold-r-.*180'

And of the matched font files, what packages are they from? E.g.:

% apt-file search /usr/share/fonts/X11/100dpi/helvB18.pcf.gz
xfonts-100dpi: /usr/share/fonts/X11/100dpi/helvB18.pcf.gz

--
Jamie Zawinski  https://www.jwz.org/  https://www.dnalounge.com/

Bug#978401: ibus-libpinyin: FTBFS on armel, armhf and mipsel: lua test failure

[Boyuan Yang]

Control: severity -1 important

在 2020-12-26星期六的 18:48 -0500，Boyuan Yang写道：
> Source: ibus-libpinyin
> Version: 1.12.0-2
> Severity: serious
> Tags: ftbfs sid
> 
> As shown on
> https://buildd.debian.org/status/package.php?p=ibus-libpinyin ,
> currently ibus-libpinyin FTBFS on armel armhf and mipsel due to
> errors
> around Lua in tests:
> 
> -
> Making check in lua
> make[2]: Entering directory '/<>/lua'
> make  check-TESTS
> make[3]: Entering directory '/<>/lua'
> make[4]: Entering directory '/<>/lua'
> ../test-driver: line 109: 20903 Trace/breakpoint trap   "$@" >
> $log_file 2>&1
> FAIL: test-lua-plugin
> ===
>    ibus-libpinyin 1.12.0: lua/test-suite.log
> ===
> 
> # TOTAL: 1
> # PASS:  0
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> .. contents:: :depth: 2
> 
> FAIL: test-lua-plugin
> =
> 
> starting test...
> ibus-libpinyin 1.4.0
> 
> (process:20903): GLib-ERROR **: 22:38:09.235:
> ../../../glib/gprintf.c:342: failed to allocate memory
> FAIL test-lua-plugin (exit status: 133)
> 
> 
> Since previous version did not enable lua plugin, I am not sure
> whether
> this is a bug in lua (lua5.4 currently using), in ibus-libpinyin, in
> GLib or whether this is an architecture-specific issue. Any help
> would
> be appreciated.

I have disabled lua support on these architectures and the builds are
now passing. This will still need to be fixed later. Bug severity is
downgraded to important.

Thanks,
Boyuan Yang

Bug#978163: go-dep: Not release with bullseye

[Hilko Bengen]

* Shengjing Zhu:

> dep is deprecated by upstream. The upstream repo is now read-only.
> Users should have migrated to Go modules.

I agree. Not because I think that the Go Modules concept is generally
more sensible, but because it has caused the go-dep project to stop.

> I was thinking just to request RM, but let's try removing it from
> testing first.

Feel free to file to turn this into an RM bug.

Cheers,
-Hilko

Bug#978408: libcommoncpp2: reproducible builds: man page names based on build path

[Vagrant Cascadian]

Source: libcommoncpp2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Two man pages shipped in libcommoncpp2-doc include names based on the
build path:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/libcommoncpp2.html

  usr/share/man/man8/_build_1st_libcommoncpp2-1.8.1_inc_.8.1_inc_.3.gz
  vs.
  usr/share/man/man8/_build_2_libcommoncpp2-1.8.1_2nd_inc_.8.1_2nd_inc_.3.gz


The attached patch fixes this by renaming these manpages in
a debian/rules dh_installman lintian override.


Thanks for maintaining libcommoncpp2!


live well,
  vagrant
From 112e5a6e417eb2c9128350def5f997930c6275e3 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 27 Dec 2020 01:15:11 +
Subject: [PATCH 3/3] debian/rules: Add dh_installman override to rename
 manpages with names based on the build path.

---
 debian/rules | 8 
 1 file changed, 8 insertions(+)

diff --git a/debian/rules b/debian/rules
index f227c11..ae36d6a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,6 +16,14 @@ override_dh_installexamples:
 	# Remove Makefile which embeds binary paths and build paths
 	rm -f debian/libcommoncpp2-doc/usr/share/doc/libcommoncpp2-dev/examples/Makefile
 
+override_dh_installman:
+	dh_installman
+	# Rename manpages with embedded build path
+	mv -vf debian/libcommoncpp2-doc/usr/share/man/man*/*_inc_cc_*.3 \
+		debian/libcommoncpp2-doc/usr/share/man/man3/libcommoncpp2_inc_cc_.3
+	mv -vf debian/libcommoncpp2-doc/usr/share/man/man*/*_inc_.3 \
+		debian/libcommoncpp2-doc/usr/share/man/man3/libcommoncpp2_inc_.3
+
 help2man:
 	/usr/bin/help2man -N -S 'Debian GNU/Linux' -o debian/ccgnu2-config.8 ccgnu2-config \
 	-n 'script to get information about the installed version of libcommoncpp2'
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#978407: libcommoncpp2: reproducible builds: Example Makefile contains variable build paths and binary paths

[Vagrant Cascadian]

Source: libcommoncpp2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath usrmerge shell
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The included file /usr/share/doc/libcommoncpp2-dev/examples/Makefile.gz
various paths dependent on the build environment:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/libcommoncpp2.html

  
ACLOCAL·=·${SHELL}·'/build/1st/libcommoncpp2-1.8.1/autoconf/missing'·aclocal-1.16
  vs.
  
ACLOCAL·=·${SHELL}·'/build/2/libcommoncpp2-1.8.1/2nd/autoconf/missing'·aclocal-1.16

  EGREP·=·/bin/grep·-E
  vs.
  EGREP·=·/usr/bin/grep·-E


The attached patch fixes this by removing the Makefile from the package,
while preserving the Makefile.in and Makefile.am files needed to
regenerate the Makefile should the user wish to use it.


Thanks for maintaining libcommoncpp2!


live well,
  vagrant
From f9304813d7191100159470e35f64127ed4a20a7c Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 27 Dec 2020 00:17:27 +
Subject: [PATCH 1/3] debian/rules: Remove example Makefile.

The Makefile contains information specific to the build environment
such as build paths and paths to specific binaries. Remove it as it
would need to be regenerated on the end user system in order to be
used.
---
 debian/rules | 5 +
 1 file changed, 5 insertions(+)

diff --git a/debian/rules b/debian/rules
index fec6698..f227c11 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,6 +11,11 @@ override_dh_install:
 override_dh_strip:
 	dh_strip --dbgsym-migration='libcommoncpp2-dbg (<< 1.8.1-7~)'
 
+override_dh_installexamples:
+	dh_installexamples
+	# Remove Makefile which embeds binary paths and build paths
+	rm -f debian/libcommoncpp2-doc/usr/share/doc/libcommoncpp2-dev/examples/Makefile
+
 help2man:
 	/usr/bin/help2man -N -S 'Debian GNU/Linux' -o debian/ccgnu2-config.8 ccgnu2-config \
 	-n 'script to get information about the installed version of libcommoncpp2'
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#839278: oathtool: has no secure way to provide a key

[Simon Josefsson]

Ilkka Virta  writes:

> On Fri, Nov 13, 2020 at 2:06 AM Simon Josefsson via OATH Toolkit general
> discussions  wrote:
>
>> Thank you for the patch -- this makes sense.  I'm not fond of the name
>> 'args-from-files' though.  How about this behaviour: if the supplied
>> strings for KEY and/or OTP contain '/' or '\' the strings are treated as
>> names of files to be read, instead of data strings?  And if the string
>> is '-' stdin is used.
>
> '@filename' would be somewhat common, I think.

I have pushed Ian's patch, but I dropped his newly introduced
command-line parameter and instead allowed for KEY and OTP parameters to
be - to mean stdin or @filename like you suggested Ilkka.

A string of '-' is not valid hex, base32 or base64, and @filename is not
valid hex, base32 or base64 either.

If someone wants to add support for reading from a numbered file
descriptor, I'm happy to merge that -- how about '*42'?  Just don't pick
a character that is in the base64 alphabet (right now only hex and
base32 are supported, but maybe base64 support will be added in the
future).  The '*' character would work.  Is this useful though?

https://gitlab.com/oath-toolkit/oath-toolkit/-/commit/56f28bde2059ebb87fead40fb371168ee44d840c

/Simon


signature.asc
Description: PGP signature

Bug#978406: Stop calling the "add-user" command on installation

[Laurent Bigonville]

Package: usbguard
Version: 0.7.8+ds-2
Severity: normal

Hello,

Currently the postinst script calls "usbguard add-user" to allow the
plugdev group.

This seems redundent to me as plugdev is already listed in the
usbguard-daemon.conf file.

Please stop calling this and rely on the usbguard-daemon.conf file
configuration

Kind regards,

Laurent Bigonville


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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages usbguard depends on:
ii  dbus 1.12.20-1
ii  init-system-helpers  1.60
ii  libaudit11:3.0-1
ii  libc62.31-6
ii  libcap-ng0   0.7.9-2.2+b1
ii  libgcc-s110.2.1-3
ii  libglib2.0-0 2.66.4-1
ii  libseccomp2  2.5.1-1
ii  libstdc++6   10.2.1-3
ii  libusbguard0 0.7.8+ds-2

usbguard recommends no packages.

usbguard suggests no packages.

-- Configuration Files:
/etc/usbguard/usbguard-daemon.conf [Errno 13] Permission non accordée: 
'/etc/usbguard/usbguard-daemon.conf'

-- no debconf information

Bug#978166: whipper: Missing dependency on flac

[Age Bosma]

Package: whipper
Version: 0.9.0-4
Severity: important
X-Debbugs-Cc: age.bo...@protonmail.com

Dear Maintainer,

   * What led up to the situation?

After a new/clean install of whipper, it's primary function, ripping a cd, does
not work, resulting in an error instead.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Run "whipper cd rip" (after having configured the drive)

   * What was the outcome of this action?

The first track will fail 5 times with error:

---
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/whipper/extern/task/task.py", line 518,
in c
callable_task(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/whipper/common/encode.py", line 63, in
_flac_encode
flac.encode(self.track_path, self.track_out_path)
  File "/usr/lib/python3/dist-packages/whipper/program/flac.py", line 15, in
encode
check_call(['flac', '--silent', '--verify', '-o', outfile,
  File "/usr/lib/python3.8/subprocess.py", line 359, in check_call
retcode = call(*popenargs, **kwargs)
  File "/usr/lib/python3.8/subprocess.py", line 340, in call
with Popen(*popenargs, **kwargs) as p:
  File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'flac'
---

   * What outcome did you expect instead?

No error and a ripped cd/track.

Installing the dependency 'flac', as instructed in the list of dependencies [1]
fixes the issue.

Yours faithfully,

Age


[1] https://github.com/whipper-team/whipper#required-dependencies



-- System Information:
Debian Release: bullseye/sid
  APT prefers groovy-updates
  APT policy: (500, 'groovy-updates'), (500, 'groovy-security'), (500, 
'groovy'), (100, 'groovy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages whipper depends on:
ii  cd-paranoia 10.2+2.0.0-1build1
ii  cdrdao  1:1.2.4-1build1
ii  libc6   2.32-0ubuntu3
ii  libsndfile1 1.0.28-8
ii  python3 3.8.6-0ubuntu1
ii  python3-cdio2.1.0-1build2
ii  python3-gi  3.38.0-1
ii  python3-musicbrainzngs  0.7.1-2
ii  python3-mutagen 1.45.0-1
ii  python3-requests2.23.0+dfsg-2
ii  python3-ruamel.yaml 0.16.12-2
ii  sox 14.4.2+git20190427-2

whipper recommends no packages.

whipper suggests no packages.

-- no debconf information

Bug#978042: libwebkit2gtk-4.0-37: fails to run plugin

[Ben Chin, KB]

Dear Alerto,

Thanks for your notification. I am sad to hear that the plugin support 
will be removed.


The plugin is our company's in house program to provide a way to 
communicate between C/C++ and JavaScript, makes it possible for the 
connected primitive hardware to play some roles in the evolving Internet 
world.


We don't use the full features of NPAPI, but just the calling/passing 
functions and information between the browser and the underneath lower 
level system/hardware resources.


If removing of the plugin is inevitable, we will need to find an 
alternative of WebKit to fulfill our goal.


Would it be possible to keep an older version of the plugin enabled 
WebKit? Like, the new WebKit would be version 3, and let the old one 
survive as WebKit 2 and stay as it is?


Thanks for your attention.

Regards
Ben


On 27/12/2020 2:42 am, Alberto Garcia wrote:

Control: found -1 2.30.1-1
Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=220154

On Fri, Dec 25, 2020 at 08:06:05AM +0800, Ben Chin wrote:

Package: libwebkit2gtk-4.0-37
Version: 2.30.4-1~deb10u1
Severity: normal

Dear Maintainer,

When loading plugin, webkit complains it couldn't find
WebKitPluginProcess

Thanks, this is an upstream bug and it affects all 2.30.x releases.

Out of curiosity, what plugin is that? Upstream will remove support
for NPAPI plugins altogether in future releases:

https://bugs.webkit.org/show_bug.cgi?id=215503

Berto

Bug#978405: Do not create the policy by default

[Laurent Bigonville]

Package: usbguard
Version: 0.7.4+ds-1
Severity: important 

Hello,

Curently, the postinstall script of the package is generating a default
policy that allows all USB devices conntected at the time of the
installation.

The problem is that there is no guarantee that the user has all the
needed USB devices connected and even that the package will be installed
on the final machine that will be used (VM cloned or chroot)

Looking at the other distributions (ie. Fedora) they are not doing that.

Not sure what should be done here, as no policy might also cause more
issues. Maybe playing with the AuthorizedDefault= option and set it to
internal or wired?

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages usbguard depends on:
ii  dbus 1.12.20-1
ii  init-system-helpers  1.60
ii  libaudit11:3.0-1
ii  libc62.31-6
ii  libcap-ng0   0.7.9-2.2+b1
ii  libgcc-s110.2.1-3
ii  libglib2.0-0 2.66.4-1
ii  libseccomp2  2.5.1-1
ii  libstdc++6   10.2.1-3
ii  libusbguard0 0.7.8+ds-2

usbguard recommends no packages.

usbguard suggests no packages.

-- Configuration Files:
/etc/usbguard/usbguard-daemon.conf [Errno 13] Permission non accordée: 
'/etc/usbguard/usbguard-daemon.conf'

-- no debconf information

Bug#912941: mozjs52: No longer maintained upstream

[Simon McVittie]

Control: clone -1 -2
Control: retitle -2 RM: mozjs52 -- ROM; superseded by mozjs78, no reverse 
dependencies remain
Control: severity -2 normal
Control: reassign -2 ftp.debian.org

On Sat, 26 Dec 2020 at 23:46:48 +0100, Aurelien Jarno wrote:
> I confirm that nothing else is using this package anymore:
> 
> | dak rm -n -R mozjs52
> | Will remove the following packages from unstable:
> | 
> | libmozjs-52-0 | 52.9.1-1.1 | amd64, arm64, armel, armhf, i386, mips64el, 
> mipsel, ppc64el, s390x
> | libmozjs-52-dev | 52.9.1-1.1 | amd64, arm64, armel, armhf, i386, mips64el, 
> mipsel, ppc64el, s390x
> |mozjs52 | 52.9.1-1.1 | source
...
> | Checking reverse dependencies...
> | No dependency problem found.
> 
> Can we just clone that bug and reassign it against ftp.debian.org to get
> this package removed from the archive?

I wanted to wait for the new cjs to migrate to testing before removing
mozjs52 from unstable, to make sure that if the Cinnamon team needed to
revert to an earlier version that still needed mozjs52, there would
still be a package available.

However, that seems to have already happened: "dak rm -R -n -s testing
mozjs52" says nothing in testing depends on it any more, either.

ftp team: please remove src:mozjs52 when convenient.

Thanks,
smcv

Bug#910545: unstable is not affected by this anymore

[Jeffrey Cliff]

this is basically resolved by the fact that unstable is on 3.x

Bug#978403: RFP: Jolokia -- remote JMX with JSON over HTTP

[Louis-Philippe Véronneau]

Package: wnpp
Severity: wishlist

* Package name: jolokia
  Version : 1.6.2
  Upstream Author : Roland Huß 
* URL : https://github.com/rhuss/jolokia
* License : Apache-2.0
  Programming Lang: Java
  Description : a fresh way to access JMX MBeans remotely using JSON
over HTTP

Jolokia is a fresh way to access JMX MBeans remotely. It is different
from JSR-160 connectors in that it is an agent-based approach which uses
JSON over HTTP for its communication in a REST-stylish way.

This is a dependency for trapperkeeper-metrics-clojure, and thus a
dependency for puppetserver.

At the moment we're patching it out, but it would be nice to have it in
Debian to include that functionality. We apparently only need
jolokia-core and not all the other binary package, so "only" that would
be enough :)

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature

Bug#978402: Please add support for v2 endpoints (Jolokia)

[Louis-Philippe Véronneau]

Package: libtrapperkeeper-metrics-clojure
Version: 1.3.1-1
Severity: wishlist

At the moment, libtrapperkeeper-metrics-clojure patches out Jolokia
entirely, as it's not in the archive.

It would be nice to remove that patch and add support for it, as v1
endpoints are being deprecated.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature

Bug#974011: xmille: Incorrect license/copyright for xmille

[Keith Packard]

Steven Robbins  writes:

> On Saturday, December 26, 2020 12:50:58 A.M. CST Keith Packard wrote:
>
>> I've tagged version '1.0' of this repository and created some (not
>> finished) debian packaging for it. This version has imported the mille
>> sources from 'upstream' which include copyright information for the
>> BSD-sourced files.
>> 
>> How would you like to go about getting these 'xmille' bits into the
>> archive as a replacement for the ancient bits now living there? 
>
> Personally speaking: if you're already working on debian packaging, my 
> preference is to just step aside and let you carry on.  If you're willing, 
> then I think it mainly becomes a problem of what to name the source package 
> as 
> the new sources are more than just xmille.

The upstream name is 'games', which is a bit generic, I suspect. I've
tentatively named the package 'kgames'.

> I don't mind co-maintaining but, realistically, I won't be much help.

Would be good to have more than one person able to upload, just in case.

> If you are NOT interested in maintaining the package, then I can continue.  
> Unless Adrian wants to do it?  ;-)

I'm easy; three is even better than two?

I've packaged everything in one bundle, even though there are 14 games
and a shared library. There are few man pages; not even the rules for
each game. I do have text for that from my palm pilot 'patience'
application; I can see about putting that into a man page for each game.

Just so you know, I've got my original 1990 edition of the 'X Window
System Toolkit' book sitting on my desk at present. It's getting
surprisingly yellowed with age, but the technical content remains as
accurate as ever. Talk about 'legacy software' :-)

-- 
-keith


signature.asc
Description: PGP signature

Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Samuel Thibault]

Santiago Vila, le dim. 27 déc. 2020 00:59:23 +0100, a ecrit:
> On Sun, Dec 27, 2020 at 12:29:01AM +0100, Samuel Thibault wrote:
> > Lucas Nussbaum, le sam. 26 déc. 2020 22:52:15 +0100, a ecrit:
> > > > INTLTOOL_EXTRACT="/usr/bin/intltool-extract" 
> > > > XGETTEXT="/usr/bin/xgettext" srcdir=. /usr/bin/intltool-update 
> > > > --gettext-package dasher --pot
> > > > xgettext: x-c.c:1666: phase5_get: Assertion `UNICODE_VALUE (c) >= 0 && 
> > > > UNICODE_VALUE (c) < 0x11' failed.
> > > > ERROR: xgettext failed to generate PO template file. Please consult
> > > >error message above if there is any.
> > 
> > And this is due to this part of dasher:
> > 
> >   EXPECT_STREQ("(Invalid Unicode 0xABCDFF)",
> >WideStringToUtf8(L"\xABCDFF", -1).c_str());
> > 
> > which is precisely *expected* to be an invalid code-point... Since this
> > string is not marked as to be translated, xgettext shouldn't error out
> > about it?
> 
> I don't know.
> 
> It must be noted that I uploaded gettext 0.21 for unstable recently
> and it propagated to testing today. Apparently the new gettext is more
> nitpicky than the old one.
> 
> My feeling is that somehow you are calling xgettext "implicitly", i.e.
> without being really aware that you are in fact calling xgettext.

Well, it does seem that upstream's intent really is to call xgettext
over the source code, to extract translatable strings.

> If required I can ask gettext upstream about this, but we would need a
> minimal test case and a little bit more of investigation on our side.

€ cat test.c

#include 

void f(const wchar_t *str) { }

void g(void) {
f(L"\xABCDFF");
}


€ xgettext test.c
xgettext: x-c.c:1666: phase5_get: Assertion `UNICODE_VALUE (c) >= 0 && 
UNICODE_VALUE (c) < 0x11' failed.

Samuel

Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Santiago Vila]

On Sun, Dec 27, 2020 at 12:29:01AM +0100, Samuel Thibault wrote:
> Hello gettext maintainers,
> 
> Lucas Nussbaum, le sam. 26 déc. 2020 22:52:15 +0100, a ecrit:
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> > 
> > > INTLTOOL_EXTRACT="/usr/bin/intltool-extract" XGETTEXT="/usr/bin/xgettext" 
> > > srcdir=. /usr/bin/intltool-update --gettext-package dasher --pot
> > > xgettext: x-c.c:1666: phase5_get: Assertion `UNICODE_VALUE (c) >= 0 && 
> > > UNICODE_VALUE (c) < 0x11' failed.
> > > ERROR: xgettext failed to generate PO template file. Please consult
> > >error message above if there is any.
> 
> And this is due to this part of dasher:
> 
>   EXPECT_STREQ("(Invalid Unicode 0xABCDFF)",
>WideStringToUtf8(L"\xABCDFF", -1).c_str());
> 
> which is precisely *expected* to be an invalid code-point... Since this
> string is not marked as to be translated, xgettext shouldn't error out
> about it?

I don't know.

It must be noted that I uploaded gettext 0.21 for unstable recently
and it propagated to testing today. Apparently the new gettext is more
nitpicky than the old one.

My feeling is that somehow you are calling xgettext "implicitly", i.e.
without being really aware that you are in fact calling xgettext.

If required I can ask gettext upstream about this, but we would need a
minimal test case and a little bit more of investigation on our side.

Thanks.

Bug#894158: libogg: diff for NMU version 1.3.4-0.1

[Aurelien Jarno]

On 2020-12-27 00:04, Simon McVittie wrote:
> On Sun, 27 Dec 2020 at 00:45:43 +0100, Aurelien Jarno wrote:
> > Looking at the licenses, both RFC included in the tarball are definitely
> > non-free
> 
> According to the replies to #894158, d/copyright contains permission to
> distribute those RFCs under DFSG licenses, if I'm reading correctly. I
> would prefer it if this was documented by Lintian overrides, but the
> maintainer doesn't seem to want to re-upload this package for any reason
> that is not a significant (important? RC?) bug.

Thanks, I have just noticed that preparing the NMU, looks like our mails
crossed.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#894158: libogg: diff for NMU version 1.3.4-0.1

[Aurelien Jarno]

On 2020-12-27 00:45, Aurelien Jarno wrote:
> clone 894158 -1
> retitle -1 libogg contains RFC released under a non-free license
> severity -1 serious
> thanks
> 
> On 2018-03-27 11:09, Simon McVittie wrote:
> > If the RFCs are false-positives and they are actually Free Software,
> > please add Lintian overrides to document this for future contributors. If
> > they're non-free, then that's considered a release-critical bug (I can't
> > say I'm entirely convinced that applying the DFSG equally to documentation
> > is proportionate, but there have been GRs that say it's project consensus
> > that we do).
> 
> On 2020-02-29 15:22, Aurelien Jarno wrote:
> > control: tags 894158 - pending
> > control: tags 894207 - pending
> > 
> > On 2020-02-05 21:46, Adrian Bunk wrote:
> > > Control: tags 894158 + patch
> > > Control: tags 894158 + pending
> > > Control: tags 894207 + pending
> > > 
> > > Dear maintainer,
> > > 
> > > I've prepared an NMU for libogg (versioned as 1.3.4-0.1) and uploaded
> > > it to DELAYED/15. Please feel free to tell me if I should cancel it.
> > > 
> > 
> > The package has been rejected:
> > 
> > | libogg source: lintian output: 'license-problem-non-free-RFC 
> > doc/rfc3533.txt', automatically rejected package.
> > | libogg source: If you have a good reason, you may override this lintian
> > 
> > Removing the pending tags accordingly.
> 
> Looking at the licenses, both RFC included in the tarball are definitely
> non-free:
> 
> * doc/rfc3533.txt:
> 
> | Full Copyright Statement
> | 
> |Copyright (C) The Internet Society (2003).  All Rights Reserved.
> | 
> |This document and translations of it may be copied and furnished to
> |others, and derivative works that comment on or otherwise explain it
> |or assist in its implementation may be prepared, copied, published
> |and distributed, in whole or in part, without restriction of any
> |kind, provided that the above copyright notice and this paragraph are
> |included on all such copies and derivative works.  However, this
> |document itself may not be modified in any way, such as by removing
> |the copyright notice or references to the Internet Society or other
> |Internet organizations, except as needed for the purpose of
> |developing Internet standards in which case the procedures for
> |copyrights defined in the Internet Standards process must be
> |followed, or as required to translate it into languages other than
> |English.
> | 
> |The limited permissions granted above are perpetual and will not be
> |revoked by the Internet Society or its successors or assigns.
> | 
> |This document and the information contained herein is provided on an
> |"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
> |TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
> |BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
> |HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
> |MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>  
> * doc/rfc5334.txt:
>  
> |Copyright (C) The IETF Trust (2008).
> | 
> |This document is subject to the rights, licenses and restrictions
> |contained in BCP 78, and except as set forth therein, the authors
> |retain all their rights.
> | 
> |This document and the information contained herein are provided on an
> |"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
> |OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
> |THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
> |OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
> |THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
> |WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> I am therefore cloning that bug, and I am preparing an NMU based on
> latest Adrian's upload.

Preparing the NMU, I realised that exceptions have been granted for
these two RFCs in debian/copyright. Sorry for not noticing about that
earlier.

I am therefore closing the bug I have just opened. I am still preparing
an NMU based on latest Adrian's upload, this time added lintian
overrides so that the package do not get rejected by dak.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#894158: libogg: diff for NMU version 1.3.4-0.1

[Simon McVittie]

On Sun, 27 Dec 2020 at 00:45:43 +0100, Aurelien Jarno wrote:
> Looking at the licenses, both RFC included in the tarball are definitely
> non-free

According to the replies to #894158, d/copyright contains permission to
distribute those RFCs under DFSG licenses, if I'm reading correctly. I
would prefer it if this was documented by Lintian overrides, but the
maintainer doesn't seem to want to re-upload this package for any reason
that is not a significant (important? RC?) bug.

smcv

Bug#974949: closed by Debian FTP Masters (reply to Axel Beckert ) (Bug#974949: fixed in systray-mdstat 1.2.0-2)

[Axel Beckert]

Ciao Francesco,

Francesco Poli wrote:
> >* Add hard dependency on virtual package notification-daemon.
> >  + Mention in README.Debian that not all notification-daemon
> >implementations start up automatically upon user login.
> >  + Closes: #974949
> 
> Thank you Axel!   :-)

Sorry it took so long. Couldn't decide how to tackle this for a while.

This is now the low-effort-but-should-be-good-enough-and-needs-no-new-
upstream-release-variant. I currently have other work in Debian which
I consider more important and more urgent.

I might tackle this differently upstream in the future by e.g. either:

* detecting this situation and writing appropriate suggestions to
  STDERR, or

* detecting this situation and starting the available notification
  daemon automatically.

The latter is probably the most transparent solution, but seems much
harder as it needs knowledge about which notification daemons exist
and how they can be started. And my gut feeling also says this is out
of scope of that project.

Additionally I first need to find a setup where I can easily test that
situation in the first place.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#978401: ibus-libpinyin: FTBFS on armel, armhf and mipsel: lua test failure

[Boyuan Yang]

Source: ibus-libpinyin
Version: 1.12.0-2
Severity: serious
Tags: ftbfs sid

As shown on
https://buildd.debian.org/status/package.php?p=ibus-libpinyin ,
currently ibus-libpinyin FTBFS on armel armhf and mipsel due to errors
around Lua in tests:

-
Making check in lua
make[2]: Entering directory '/<>/lua'
make  check-TESTS
make[3]: Entering directory '/<>/lua'
make[4]: Entering directory '/<>/lua'
../test-driver: line 109: 20903 Trace/breakpoint trap   "$@" >
$log_file 2>&1
FAIL: test-lua-plugin
===
   ibus-libpinyin 1.12.0: lua/test-suite.log
===

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test-lua-plugin
=

starting test...
ibus-libpinyin 1.4.0

(process:20903): GLib-ERROR **: 22:38:09.235:
../../../glib/gprintf.c:342: failed to allocate memory
FAIL test-lua-plugin (exit status: 133)


Since previous version did not enable lua plugin, I am not sure whether
this is a bug in lua (lua5.4 currently using), in ibus-libpinyin, in
GLib or whether this is an architecture-specific issue. Any help would
be appreciated.

Thanks,
Boyuan Yang


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

Bug#978400: RM: mochikit -- ROM; no longer used anywhere in Debian

[Marcelo Jorge Vieira]

Package: ftp.debian.org
Severity: normal

Hi,

As subject says, please drop mochikit from unstable, as it is no
longer used anywhere in Debian.


Cheers,




-- 
Marcelo Jorge Vieira
xmpp:me...@jabber-br.org
http://metaldot.alucinados.com


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

Bug#894158: libogg: diff for NMU version 1.3.4-0.1

[Aurelien Jarno]

clone 894158 -1
retitle -1 libogg contains RFC released under a non-free license
severity -1 serious
thanks

On 2018-03-27 11:09, Simon McVittie wrote:
> If the RFCs are false-positives and they are actually Free Software,
> please add Lintian overrides to document this for future contributors. If
> they're non-free, then that's considered a release-critical bug (I can't
> say I'm entirely convinced that applying the DFSG equally to documentation
> is proportionate, but there have been GRs that say it's project consensus
> that we do).

On 2020-02-29 15:22, Aurelien Jarno wrote:
> control: tags 894158 - pending
> control: tags 894207 - pending
> 
> On 2020-02-05 21:46, Adrian Bunk wrote:
> > Control: tags 894158 + patch
> > Control: tags 894158 + pending
> > Control: tags 894207 + pending
> > 
> > Dear maintainer,
> > 
> > I've prepared an NMU for libogg (versioned as 1.3.4-0.1) and uploaded
> > it to DELAYED/15. Please feel free to tell me if I should cancel it.
> > 
> 
> The package has been rejected:
> 
> | libogg source: lintian output: 'license-problem-non-free-RFC 
> doc/rfc3533.txt', automatically rejected package.
> | libogg source: If you have a good reason, you may override this lintian
> 
> Removing the pending tags accordingly.

Looking at the licenses, both RFC included in the tarball are definitely
non-free:

* doc/rfc3533.txt:

| Full Copyright Statement
| 
|Copyright (C) The Internet Society (2003).  All Rights Reserved.
| 
|This document and translations of it may be copied and furnished to
|others, and derivative works that comment on or otherwise explain it
|or assist in its implementation may be prepared, copied, published
|and distributed, in whole or in part, without restriction of any
|kind, provided that the above copyright notice and this paragraph are
|included on all such copies and derivative works.  However, this
|document itself may not be modified in any way, such as by removing
|the copyright notice or references to the Internet Society or other
|Internet organizations, except as needed for the purpose of
|developing Internet standards in which case the procedures for
|copyrights defined in the Internet Standards process must be
|followed, or as required to translate it into languages other than
|English.
| 
|The limited permissions granted above are perpetual and will not be
|revoked by the Internet Society or its successors or assigns.
| 
|This document and the information contained herein is provided on an
|"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 
* doc/rfc5334.txt:
 
|Copyright (C) The IETF Trust (2008).
| 
|This document is subject to the rights, licenses and restrictions
|contained in BCP 78, and except as set forth therein, the authors
|retain all their rights.
| 
|This document and the information contained herein are provided on an
|"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

I am therefore cloning that bug, and I am preparing an NMU based on
latest Adrian's upload.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#978340: proftpd-mod-dnsbl: FTBFS: Cannot compile mod_dnsbl using prxs

[Hilmar Preuße]

Am 26.12.2020 um 23:08 teilte Lucas Nussbaum mit:

Source: proftpd-mod-dnsbl
Version: 0.1.5-5
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 ftbfs-bullseye

Hi,

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


https://tracker.debian.org/news/1200727/accepted-proftpd-dfsg-137a-2-source-amd64-all-into-unstable-unstable/

   * Development of mod_dnsbl has moved to proftp main package years ago.
 Build the module from this package, add fields for file move.

We'll file a RoM bug.

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#978369: apertium-eo-ca: FTBFS: Error: Invalid dictionary (hint: entry on the right beginning with whitespace)

[Tino Didriksen]

forwarded 978369 https://github.com/apertium/apertium-eo-ca/issues/2
thanks

Fixed in upstream.

-- Tino Didriksen

Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Samuel Thibault]

Hello gettext maintainers,

Lucas Nussbaum, le sam. 26 déc. 2020 22:52:15 +0100, a ecrit:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> > INTLTOOL_EXTRACT="/usr/bin/intltool-extract" XGETTEXT="/usr/bin/xgettext" 
> > srcdir=. /usr/bin/intltool-update --gettext-package dasher --pot
> > xgettext: x-c.c:1666: phase5_get: Assertion `UNICODE_VALUE (c) >= 0 && 
> > UNICODE_VALUE (c) < 0x11' failed.
> > ERROR: xgettext failed to generate PO template file. Please consult
> >error message above if there is any.

And this is due to this part of dasher:

  EXPECT_STREQ("(Invalid Unicode 0xABCDFF)",
   WideStringToUtf8(L"\xABCDFF", -1).c_str());

which is precisely *expected* to be an invalid code-point... Since this
string is not marked as to be translated, xgettext shouldn't error out
about it?

Samuel

Bug#978359: apertium-br-fr: FTBFS: Error: Invalid dictionary (hint: entry on the right beginning with whitespace)

[Tino Didriksen]

forwarded 978359 https://github.com/apertium/apertium-br-fr/issues/4
thanks

Fixed in upstream.

-- Tino Didriksen

Bug#978045: apache2-bin: Immediate exit with "AH00141: Could not initialize random number generator"

[Stefan Fritsch]

reassign 978045 libapr1
found 978045 1.7.0-1
thanks

Am 25.12.20 um 03:18 schrieb David W:
You can see that the associated call/failure is happening inside APR 
here, on

line 216:
https://svn.apache.org/viewvc/apr/apr/trunk/misc/unix/rand.c?revision=1832691=markup#l216 



The issue is that if the library is configured (at build time) to
USE_GETRANDOM, then it assumes that the getrandom() call will be 
available and

if it fails it becomes a fatal error. On my system, I don't have getrandom()
because I'm running an ancient kernel, but others could (more legitimately)
have the option disabled on a recent custom-built kernel.

I think the correct fix is to not use that build-time option, and go back to
using DEV_RANDOM or whatever was being used previously. Alternatively, at
least document that a kernel with getrandom() support is required to use
apache2.

I'm not sure exactly when the packaging on this changed, but I know it was
broken in 2.4.46-1 and I *think* it worked in 2.4.43-1, although I can't 
get a

copy of that to double-check anymore.


This changed in libapr1 1.7, re-assigning to apr. I am not sure about 
the severity, though. According to the man page, getrandom has been 
introduced in linux 3.17. Debian 9 already has 4.9 so you have to have a 
kernel that is from Debian 8 to be affected by this.

Bug#978397: libudunits2-0: trying to overwrite '/usr/share/xml/udunits/udunits2-accepted.xml', which is also in package libudunits2-data 2.2.28-1

[Axel Beckert]

Hi,

Axel Beckert wrote:
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-hDYr38/054-libudunits2-0_2.2.28-1_amd64.deb (--unpack):
>  trying to overwrite '/usr/share/xml/udunits/udunits2-accepted.xml', which is 
> also in package libudunits2-data 2.2.28-1
[...]
> Seems as if either that file accidentially also got included in
> libudunits2-0, or—in case it was a deliberate file move between
> packages—according Breaks and Replaces headers are missing in
> libudunits2-0.

Seems to be the first case as the file in question is in the same
package version of libudunits2-data.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Samuel Thibault]

Samuel Thibault, le dim. 27 déc. 2020 00:13:55 +0100, a ecrit:
> FTR, the file that poses problem is Testing/gtest/test/gtest_unittest.cc
> This is not something that contains anything to be translated, we'd need
> some option to just ignore Testing/ entirely.

More precisely, it is line 

  EXPECT_STREQ("(Invalid Unicode 0xABCDFF)",
   WideStringToUtf8(L"\xABCDFF", -1).c_str());

which is *expected* to be an invalid code-point...

Samuel

Bug#978099: Please add support for riscv64

[Aurelien Jarno]

On 2020-12-26 08:05, Sebastiaan Couwenberg wrote:
> Control: tags -1 pending
> 
> On 12/25/20 11:17 PM, Logan Rosen wrote:
> > libhdf4 currently FTBFS on riscv64. William Grant applied a patch in
> > Ubuntu to add support for the architecture.
> > 
> > Thanks for considering the patch.
> 
> Thanks for the patch, it failed to apply, however. The existing patches
> have been updated manually.

Thanks Logan for submitting the patch and Sebastiaan for applying it.
This patch has been taken from debian-ports, however in the meantime we
got an updated version that makes the testsuite to pass. Please find
attach an update against the current diff. Could you please apply it?

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--- /dev/null
+++ b/debian/patches/riscv64.diff
@@ -0,0 +1,22 @@
+--- a/mfhdf/ncgen/ncgen.l
 b/mfhdf/ncgen/ncgen.l
+@@ -113,7 +113,7 @@
+ yyerror(errstr);
+ }
+ 
+-#if defined __alpha || (_MIPS_SZLONG == 64) || defined __ia64 || (defined __sun && defined _LP64) || defined AIX5L64 || defined __x86_64__ || __powerpc64__ || defined __s390x__ || defined __aarch64__
++#if defined __alpha || (_MIPS_SZLONG == 64) || defined __ia64 || (defined __sun && defined _LP64) || defined AIX5L64 || defined __x86_64__ || __powerpc64__ || defined __s390x__ || defined __aarch64__ || (defined __riscv && __riscv_xlen == 64)
+ if (dd < INT_MIN  ||  dd > INT_MAX)
+ #else
+ if (dd < LONG_MIN  ||  dd > LONG_MAX)
+--- a/mfhdf/ncgen/ncgenyy.c
 b/mfhdf/ncgen/ncgenyy.c
+@@ -991,7 +991,7 @@
+ yyerror(errstr);
+ }
+ 
+-#if defined __alpha || (_MIPS_SZLONG == 64) || defined __ia64 || (defined __sun && defined _LP64) || defined AIX5L64 || defined __x86_64__ || defined __powerpc64__ || defined __aarch64__
++#if defined __alpha || (_MIPS_SZLONG == 64) || defined __ia64 || (defined __sun && defined _LP64) || defined AIX5L64 || defined __x86_64__ || defined __powerpc64__ || defined __aarch64__ || (defined __riscv && __riscv_xlen == 64)
+ if (dd < INT_MIN  ||  dd > INT_MAX)
+ #else
+ if (dd < LONG_MIN  ||  dd > LONG_MAX)
diff --git a/debian/patches/series b/debian/patches/series
index 9455ead..77e024a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -15,3 +15,4 @@ mips64.diff
 spelling-errors.patch
 manpage-has-errors-from-man.patch
 reproducible-builds.patch
+riscv64.diff
--- a/debian/rules
+++ b/debian/rules
@@ -37,7 +37,7 @@ ifneq (,$(findstring verbose,$(DEB_BUILD_OPTIONS)))
export DH_VERBOSE
 endif
 
-ifneq (,$(filter $(DEB_BUILD_ARCH),s390x riscv64 sparc64))
+ifneq (,$(filter $(DEB_BUILD_ARCH),s390x sparc64))
DISABLE_TESTS=1
 else
DISABLE_TESTS=0

Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Samuel Thibault]

FTR, the file that poses problem is Testing/gtest/test/gtest_unittest.cc
This is not something that contains anything to be translated, we'd need
some option to just ignore Testing/ entirely.

Samuel

Bug#978398: reportbug: add src: shortcut for --source option

[Paul Wise]

Package: reportbug
Version: 7.9.0
Severity: wishlist

Sometimes when I am on a bug page I want to file another bug, but
against the source package, so I copy-paste src:foo but then reportbug
doesn't accept that on the command-line.

Similarly when I want to report a bug against a source package, I go to
a terminal and type `reportbug src:foo` since I very rarely remember
the --source option exists and src:foo is more familiar from BTS pages.

Similarly when I start reportbug without arguments I then sometimes
want to be able to report a bug against a source package but reportbug
doesn't accept src:foo in the package selection prompt.

It would be nice to have a src: shortcut for --source option and a src:
shortcut for the package name selection prompt.

   $ reportbug
   Please enter the name of the package in which you have found a problem,
   or type 'other' to report a more general problem. If you don't know
   what package the bug is in, please contact
   debian-u...@lists.debian.org for assistance.
   > src:reportbug
   src:reportbug is not a valid package name.
   ...
   
   $ reportbug src:reportbug
   Detected character set: UTF-8
   Please change your locale if this is incorrect.
   
   Using 'Paul Wise ' as your from address.
   Getting status for src:reportbug...
   W: Unable to locate package src:reportbug
   No matching source or binary packages.
   ...

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#978397: libudunits2-0: trying to overwrite '/usr/share/xml/udunits/udunits2-accepted.xml', which is also in package libudunits2-data 2.2.28-1

[Axel Beckert]

Package: libudunits2-0
Version: 2.2.28-1
Severity: serious

Hi,

upgrading libudunits2-0 from 2.2.26-5+b1 to 2.2.28-1 fails for me as
follows:

Preparing to unpack .../054-libudunits2-0_2.2.28-1_amd64.deb ...
Unpacking libudunits2-0 (2.2.28-1) over (2.2.26-5+b1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-hDYr38/054-libudunits2-0_2.2.28-1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/xml/udunits/udunits2-accepted.xml', which is 
also in package libudunits2-data 2.2.28-1
[…]
dpkg: dependency problems prevent configuration of libudunits2-dev:
 libudunits2-dev depends on libudunits2-0 (= 2.2.28-1); however:
  Version of libudunits2-0:amd64 on system is 2.2.26-5+b1.

dpkg: error processing package libudunits2-dev (--configure):
 dependency problems - leaving unconfigured
[…]
Errors were encountered while processing:
 libudunits2-dev

Seems as if either that file accidentially also got included in
libudunits2-0, or—in case it was a deliberate file move between
packages—according Breaks and Replaces headers are missing in
libudunits2-0.

-- 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.9.0-4-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 libudunits2-0 depends on:
ii  dpkg  1.20.5
ii  install-info  6.7.0.dfsg.2-5+b1
ii  libc6 2.31-6
ii  libexpat1 2.2.10-1
ii  libudunits2-data  2.2.28-1

libudunits2-0 recommends no packages.

libudunits2-0 suggests no packages.

-- no debconf information

Bug#978158: [upgrade-system] upgrade-system wants to delete package deluge and everything it depends on

[Martin-Éric Racine]

la 26. jouluk. 2020 klo 21.30 Rick Thomas (rbtho...@rcthomas.org) kirjoitti:
>
> Package: upgrade-system
> Version: 1.7.3.1
> Severity: normal
>
> --- Please enter the report below this line. ---
>
> The package "deluge" is manually (i.e. not "auto") installed on my
> system.  I use it daily. But when I try to run "upgrade-system" it lists
> deluge and a bunch of other packages that deluge depends on as needing
> to be removed.  Why is this?

Check the deborphan options you have configured in
/etc/upgrade-system.conf for something that tries to purge python
packages. To manually fine-tune this, you can run 'sudo deborphan'
with different combinations of --guess options.

Martin-Éric

Bug#978395: sympa: Debconf upgrade script does not take into account on mounted arc subdir

[Marco Gaiarin]

Package: sympa
Version: 6.2.40~dfsg-1+deb10u1
Severity: normal

Dear Maintainer,

I've tried to upgrade sympa, and lead to debocnf error because i've mounted a 
filesystem
for 'arc' subdir:

 root@mail:~# df -h
 File system Dim. Usati Dispon. Uso% Montato su
 /dev/loop1  2,9G  1,9G904M  68% /
 /dev/loop11 9,8G  744M8,6G   8% /home
 /dev/loop12 4,9G  1,6G3,1G  35% /var/lib/sympa/arc

and debconf complain that cannot chown 'lost+found' dir (and indeed is true).

I've tried to modify the postinst script, and at last i've commented the guilty 
find,
let debconf to end:

 --- /var/lib/dpkg/info/sympa.postinst.dist 2020-12-10 14:39:54.0 
+0100
 +++ /var/lib/dpkg/info/sympa.postinst  2020-12-26 23:01:15.342509840 +0100
 @@ -221,9 +221,9 @@
  
  # It's better to search files and directories with wrong owner/group and fix
  # them instead of recursively doing it, even if it's not needed (see #630384)
 -find /var/spool/sympa /var/lib/sympa \
 -\( -not -user sympa -or -not -group sympa \) \
 --exec chown sympa:sympa {} \;
 +#find /var/spool/sympa /var/lib/sympa \
 +#\( -not -user sympa -or -not -group sympa \) -not -name 'lost+found' \
 +#-exec chown sympa:sympa {} \;
  
  # Fix permissions on CGI wrappers
  chown sympa:sympa /usr/lib/cgi-bin/sympa/wwsympa-wrapper.fcgi \

I think a better find have to be setup, but i was not able to do that...


Thanks.

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

Kernel: Linux 4.15.18-14-pve (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sympa depends on:
ii  adduser3.118
ii  ca-certificates20200601~deb10u1
ii  dbconfig-common2.0.11+deb10u1
ii  debconf [debconf-2.0]  1.5.71
ii  exim4-daemon-heavy [mail-transport-agent]  4.92-8+deb10u4
ii  fonts-font-awesome 5.0.10+really4.7.0~dfsg-1
ii  libarchive-zip-perl1.64-1
ii  libc6  2.28-10
ii  libcgi-fast-perl   1:2.13-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-singleton-perl1.5-1
ii  libcrypt-eksblowfish-perl  0.009-2+b5
ii  libcrypt-openssl-x509-perl 1.8.12-1
ii  libcrypt-smime-perl0.25-1+b1
ii  libdatetime-format-mail-perl   0.4030-1
ii  libdbd-csv-perl0.5300-1
ii  libdbd-mysql-perl  4.050-2
ii  libdbd-pg-perl 3.7.4-3
ii  libdbd-sqlite3-perl1.62-3
ii  libdbi-perl1.642-1+deb10u1
ii  libfcgi-perl   0.78-2+b3
ii  libfile-copy-recursive-perl0.44-1
ii  libfile-nfslock-perl   1.29-1
ii  libhtml-format-perl2.12-1
ii  libhtml-stripscripts-parser-perl   1.03-2
ii  libhtml-tree-perl  5.07-2
ii  libintl-perl   1.26-2
ii  libio-stringy-perl 2.111-3
ii  libjs-jquery   3.3.1~dfsg-3
ii  libjs-jquery-migrate-1 1.4.1-1
ii  libjs-jquery-minicolors2.2.6+dfsg-3
ii  libjs-jquery-ui1.12.1+dfsg-5
ii  libmail-dkim-perl  0.54-1
ii  libmailtools-perl  2.18-1
ii  libmime-charset-perl   1.012.2-1
ii  libmime-encwords-perl  1.014.3-2
ii  libmime-lite-html-perl 1.24-3
ii  libmime-tools-perl 5.509-1
ii  libnet-cidr-perl   0.19-1
ii  libnet-dns-perl1.19-1
ii  libnet-ldap-perl   1:0.6500+dfsg-1
ii  libnet-netmask-perl1.9104-1
ii  libregexp-common-perl  2017060201-1
ii  libsoap-lite-perl  1.27-1
ii  libtemplate-perl   2.27-1+b1
ii  libterm-progressbar-perl   2.22-1
ii  libunicode-linebreak-perl  0.0.20190101-1
ii  libxml-libxml-perl 2.0134+dfsg-1
ii  lsb-base   10.2019051400
ii  mhonarc2.6.19-2
ii  perl   5.28.1-6+deb10u1
ii  rsyslog [system-log-daemon]8.1901.0-1
ii  sqlite33.27.2-3+deb10u1

Versions of packages sympa recommends:
ii  apache2-suexec-custom [apache2-suexec]  2.4.38-3+deb10u4
ii  

Bug#978394: mark python3-ruffus Multi-Arch: foreign

[Helmut Grohne]

Package: python3-ruffus
Version: 2.8.4-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:sga

sga cannot be cross built, because its dependency on python3-ruffus is
not satisfiable. In general, Architecture: all packages can never
satisfy cross Build-Depends unless marked Multi-Arch: foreign or
annotated :native. In this case, the foreign annotation seems correct.
python3-ruffus is a pure python module. All of its runtime dependencies
are either marked Multi-Arch: foreign or annotated :any. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru python-ruffus-2.8.4/debian/changelog 
python-ruffus-2.8.4/debian/changelog
--- python-ruffus-2.8.4/debian/changelog2020-06-10 01:49:34.0 
+0200
+++ python-ruffus-2.8.4/debian/changelog2020-12-26 21:45:00.0 
+0100
@@ -1,3 +1,10 @@
+python-ruffus (2.8.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark python3-ruffus Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 26 Dec 2020 21:45:00 +0100
+
 python-ruffus (2.8.4-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru python-ruffus-2.8.4/debian/control 
python-ruffus-2.8.4/debian/control
--- python-ruffus-2.8.4/debian/control  2020-06-10 01:49:34.0 +0200
+++ python-ruffus-2.8.4/debian/control  2020-12-26 21:44:31.0 +0100
@@ -19,6 +19,7 @@
 
 Package: python3-ruffus
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends},
  ${python3:Depends},
  graphviz

Bug#978393: RFP: cygwin -- library and headers providing POSIX functionality on Windows

[John Scott]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: sk...@debian.org

* Package name: cygwin
* URL : http://cygwin.com
* License : LGPL
  Programming Lang: C, C++
  Description : library and headers providing POSIX functionality on Windows

As an alternative to MinGW, Cygwin is much more useful for those porting
software on Windows. At its core, it's a fork of Newlib that provides POSIX
functionality on top of the Windows API so that POSIX software can be ported
with little to no change. In effect, it's the opposite of Winelib.

Cygwin needs MinGW to be built, and building a toolchain on one's own is
difficult to do from scratch. A Debian package with just the core library
would be helpful to enable providing cross compilers later on.

I'm somewhat familiar with Cygwin, but find the lack of a cross compiler
very inconvenient. It can be run under Wine—its main audience is for use
under Windows—but relying on their opaque unbootstrappable binary
with the hassle of a separate Wine prefix for dependencies makes this a
great deal of trouble.

Although there are compatibility libraries like Gnulib to try and bridge the
gap, I know of no other project that provides such complete POSIX and even
Linux-specific functionality, even when it challenges the capabilities of
Windows (e.g. providing symbolic links).

I won't be able to maintain it at least until I get my noggin wrapped around
how it's built—bootstrappability is low on their list of priorities, although
it reportedly can be done—but this adds more to the value of a Debian
package that can get it right.

To reduce duplication, MinGW binaries can usually be built passing an
argument to the compiler to omit linking to the Cygwin DLL. Thus a Cygwin
compiler may fill in the role of a MinGW one as well.

A good start for me would probably be investigating how the MinGW packages
are built. I've CC'd the maintainer of the MinGW packages, should he have any
remarks.

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

Bug#912941: Cinnamon fix upstream and in salsa

[Aurelien Jarno]

On 2020-11-08 22:06, Bryan Quigley wrote:
> This package is brought in by cinnamon through cjs.
> 
> The cinnamon upstream project has been ported to mozjs78 in
> https://github.com/linuxmint/cinnamon/pull/9624
> 
> And the switchover is included in an unreleased version in salsa -
> https://salsa.debian.org/cinnamon-team/cinnamon/-/commit/9f21e2426c3325ab8b67de40a474166618d6cec0

I confirm that nothing else is using this package anymore:

| dak rm -n -R mozjs52
| Will remove the following packages from unstable:
| 
| libmozjs-52-0 | 52.9.1-1.1 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
| libmozjs-52-dev | 52.9.1-1.1 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
|mozjs52 | 52.9.1-1.1 | source
| 
| Maintainer: Debian GNOME Maintainers 

| 
| --- Reason ---
| 
| --
| 
| Checking reverse dependencies...
| No dependency problem found.

Can we just clone that bug and reassign it against ftp.debian.org to get
this package removed from the archive?

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#839278: oathtool: has no secure way to provide a key

[Ian Jackson]

Simon Josefsson writes ("Re: Bug#839278: oathtool: has no secure way to provide 
a key"):
> I have pushed Ian's patch, but I dropped his newly introduced
> command-line parameter and instead allowed for KEY and OTP parameters to
> be - to mean stdin or @filename like you suggested Ilkka.

Thanks.

> A string of '-' is not valid hex, base32 or base64, and @filename is not
> valid hex, base32 or base64 either.

Right.  So this is unambiguous.  It's also sufficient for my use case.

> If someone wants to add support for reading from a numbered file
> descriptor, I'm happy to merge that -- how about '*42'?  Just don't pick
> a character that is in the base64 alphabet (right now only hex and
> base32 are supported, but maybe base64 support will be added in the
> future).  The '*' character would work.  Is this useful though?

On many operating systems @/dev/fd/N would work nicely.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#956811: cura: UI not usable because of OpenGL renderer

[Christoph Berg]

Re: Peter Felecan
> Package: cura
> Version: 4.5.0-1
> Severity: important
> 
> Dear maintainers,
> 
> I have a very annoying behavior since a long time but only recently I
> understood the origin of the problem. By the way, it's similar to the
> bug report #951033  "cura: UI not usable in 4.4.1" by having a garbled
> user interface, with buttons not sown and other annoying issues.
> 
> The problem appear when logged in my graphical session, KDE
> Plasma. However, when I open a session through ssh, for example
> "ssh -X myself@localhost" the problem disappears and I have a well
> behaved user interface.
> 
> The only difference that I found is the OpenGL renderer used in the 2
> situations:
> 
> 1. When I'm connected in my graphical session, the renderer is, as
>provided by 'glxinfo':
> 
> Vendor: X.Org (0x1002)
> Device: AMD VEGAM (DRM 3.35.0, 5.4.0-4-amd64, LLVM 9.0.1) (0x694e)
> Version: 19.3.3
> Accelerated: yes
> Video memory: 4096MB
> Unified memory: no
> Preferred profile: core (0x1)
> Max core profile version: 4.5
> Max compat profile version: 4.5
> Max GLES1 profile version: 1.1
> Max GLES[23] profile version: 3.2
> 
> 2. When I open a session, in the same graphical environment but
>through ssh, as shown above, the renderer is, as provided by
>'glxinfo':
> 
> Vendor: VMware, Inc. (0x)
> Device: llvmpipe (LLVM 9.0.1, 256 bits) (0x)
> Version: 19.3.3
> Accelerated: no
> Video memory: 32104MB
> Unified memory: no
> Preferred profile: core (0x1)
> Max core profile version: 3.3
> Max compat profile version: 3.1
> Max GLES1 profile version: 1.1
> Max GLES[23] profile version: 3.1
> 
> My conclusion is that the Cura user interface is not working correctly
> when the renderer used is the one provided by my GPU but works
> correctly on a software renderer.
> 
> Unfortunately I do not have enough experience in the OpenGL context
> but willing to provide more information to or try experiments from
> more experienced users.

Hi Peter,

does the current version 4.8 still exhibit this problem?

Christoph

Bug#978392: epm: reproducible builds: /usr/bin/epm contains embedded build path

[Vagrant Cascadian]

Source: epm
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The file /usr/bin/epm contains an embedded build path:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/epm.html

  
Use·the·named·setup·data·file·directory·instead·of·/build/1st/epm-4.2/debian/epm/usr/share/epm.
  vs.
  
Use·the·named·setup·data·file·directory·instead·of·/build/2/epm-4.2/2nd/debian/epm/usr/share/epm.

The attached patches fix this by patching Makefile.in to support DESTDIR
and passing the appropriate prefix arguments to configure.


live well,
  vagrant
From d8a94f04217a88162b4846004d4790d29d67949a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 26 Dec 2020 22:05:05 +
Subject: [PATCH 1/2] Makefile.in: Add support for DESTDIR.

---
 Makefile.in | 119 +++-
 1 file changed, 53 insertions(+), 66 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index b90597e..2f711a9 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -165,58 +165,45 @@ clang-changes:
 #
 
 install: all @INSTALL_GUIS@ @INSTALL_OSX@
-	@echo Installing EPM programs in $(bindir)
-	-$(MKDIR) $(bindir)
-	$(RM) $(bindir)/epm
-	$(CP) epm $(bindir)
-	$(STRIP) $(bindir)/epm
-	$(RM) $(bindir)/epminstall
-	$(CP) epminstall $(bindir)
-	$(STRIP) $(bindir)/epminstall
-	$(RM) $(bindir)/mkepmlist
-	$(CP) mkepmlist $(bindir)
-	@echo Installing EPM manpages in $(mandir)/man1
-	-$(MKDIR) $(mandir)/man1
-	$(RM) $(mandir)/man1/epm.1
-	$(CP) $(srcdir)/doc/epm.man $(mandir)/man1/epm.1
-	$(RM) $(mandir)/man1/epminstall.1
-	$(CP) $(srcdir)/doc/epminstall.man $(mandir)/man1/epminstall.1
-	$(RM) $(mandir)/man1/mkepmlist.1
-	$(CP) $(srcdir)/doc/mkepmlist.man $(mandir)/man1/mkepmlist.1
-	$(RM) $(mandir)/man1/setup.1
-	$(CP) $(srcdir)/doc/setup.man $(mandir)/man1/setup.1
-	@echo Installing EPM manpages in $(mandir)/man5
-	-$(MKDIR) $(mandir)/man5
-	$(RM) $(mandir)/man5/epm.list.5
-	$(CP) $(srcdir)/doc/epm.list.man $(mandir)/man5/epm.list.5
-	$(RM) $(mandir)/man5/setup.types.5
-	$(CP) $(srcdir)/doc/setup.types.man $(mandir)/man5/setup.types.5
-	@echo Installing EPM documentation in $(docdir)
-	-$(MKDIR) $(docdir)
-	$(RM) $(docdir)/COPYING
-	$(CP) $(srcdir)/COPYING $(docdir)
-	$(RM) $(docdir)/README
-	$(CP) $(srcdir)/README $(docdir)
-	$(RM) $(docdir)/epm-book.html
-	$(CP) $(srcdir)/doc/epm-book.html $(docdir)
+	@echo Installing EPM programs in $(DESTDIR)$(bindir)
+	-$(MKDIR) $(DESTDIR)$(bindir)
+	$(CP) epm $(DESTDIR)$(bindir)
+	$(STRIP) $(DESTDIR)$(bindir)/epm
+	$(CP) epminstall $(DESTDIR)$(bindir)
+	$(STRIP) $(DESTDIR)$(bindir)/epminstall
+	$(CP) mkepmlist $(DESTDIR)$(bindir)
+	@echo Installing EPM manpages in $(DESTDIR)$(mandir)/man1
+	-$(MKDIR) $(DESTDIR)$(mandir)/man1
+	$(CP) $(srcdir)/doc/epm.man $(DESTDIR)$(mandir)/man1/epm.1
+	$(CP) $(srcdir)/doc/epminstall.man $(DESTDIR)$(mandir)/man1/epminstall.1
+	$(CP) $(srcdir)/doc/mkepmlist.man $(DESTDIR)$(mandir)/man1/mkepmlist.1
+	$(CP) $(srcdir)/doc/setup.man $(DESTDIR)$(mandir)/man1/setup.1
+	@echo Installing EPM manpages in $(DESTDIR)$(mandir)/man5
+	-$(MKDIR) $(DESTDIR)$(mandir)/man5
+	$(CP) $(srcdir)/doc/epm.list.man $(DESTDIR)$(mandir)/man5/epm.list.5
+	$(CP) $(srcdir)/doc/setup.types.man $(DESTDIR)$(mandir)/man5/setup.types.5
+	@echo Installing EPM documentation in $(DESTDIR)$(docdir)
+	-$(MKDIR) $(DESTDIR)$(docdir)
+	$(CP) $(srcdir)/COPYING $(DESTDIR)$(docdir)
+	$(CP) $(srcdir)/README $(DESTDIR)$(docdir)
+	$(CP) $(srcdir)/doc/epm-book.html $(DESTDIR)$(docdir)
 
 install-guis:	setup uninst
-	@echo Installing EPM setup/uninst in $(libdir)/epm
-	$(RM) -r $(libdir)/epm
-	-$(MKDIR) $(libdir)/epm
-	$(CP) setup $(libdir)/epm
-	-$(STRIP) $(libdir)/epm/setup
-	$(CP) uninst $(libdir)/epm
-	-$(STRIP) $(libdir)/epm/uninst
+	@echo Installing EPM setup/uninst in $(DESTDIR)$(libdir)/epm
+	-$(MKDIR) $(DESTDIR)$(libdir)/epm
+	$(CP) setup $(DESTDIR)$(libdir)/epm
+	-$(STRIP) $(DESTDIR)$(libdir)/epm/setup
+	$(CP) uninst $(DESTDIR)$(libdir)/epm
+	-$(STRIP) $(DESTDIR)$(libdir)/epm/uninst
 
 install-osx:
-	@echo Installing EPM OSX data files in $(datadir)/epm
-	$(RM) -r $(datadir)/epm
-	-$(MKDIR) $(datadir)/epm
-	$(CP) macosx/setup.icns $(datadir)/epm
-	$(CP) macosx/setup.info $(datadir)/epm
-	$(CP) macosx/uninst.icns $(datadir)/epm
-	$(CP) macosx/uninst.info $(datadir)/epm
+	@echo Installing EPM OSX data files in $(DESTDIR)$(datadir)/epm
+	$(RM) -r $(DESTDIR)$(datadir)/epm
+	-$(MKDIR) $(DESTDIR)$(datadir)/epm
+	$(CP) macosx/setup.icns $(DESTDIR)$(datadir)/epm
+	$(CP) macosx/setup.info $(DESTDIR)$(datadir)/epm
+	$(CP) macosx/uninst.icns $(DESTDIR)$(datadir)/epm
+	$(CP) macosx/uninst.info $(DESTDIR)$(datadir)/epm
 
 
 #
@@ -224,24 +211,24 @@ install-osx:
 #
 
 uninstall:
-	@echo Uninstalling EPM programs from $(bindir)
-	$(RM) $(bindir)/epm
-	$(RM) $(bindir)/epminstall
-	$(RM) $(bindir)/mkepmlist
-	@echo Uninstalling EPM manpages from $(mandir)/man1
-	$(RM) 

Bug#978391: gdb-source no longer ships the gdb source

[Stephen Kitt]

Package: gdb-source
Version: 10.1-1.5
Severity: grave
Justification: renders package unusable

Dear Maintainer,

gdb-source now only contains the following:

/usr/share/doc/gdb-source/NEWS.Debian.gz
/usr/share/doc/gdb-source/changelog.Debian.gz
/usr/share/doc/gdb-source/changelog.gz
/usr/share/doc/gdb-source/copyright

In particular it's missing /usr/src/gdb.tar.*, making it useless.

Regards,

Stephen


-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'), 
(100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100, 
'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#978390: node-rollup-plugin-typescript: FTBFS: src/index.ts(69,54): error TS2345: Argument of type 'NormalizedOutputOptions' is not assignable to parameter of type 'OutputOptions'.

[Lucas Nussbaum]

Source: node-rollup-plugin-typescript
Version: 6.0.0+~1.0.1-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 --buildsystem=nodejs
> Found debian/nodejs/legacy/build
>   cd ./legacy && sh -ex ../debian/nodejs/legacy/build
> + rollup -c
> 
> src/index.js → dist/rollup-plugin-typescript.cjs.js, 
> dist/rollup-plugin-typescript.es.js...
> (!) Entry module "src/index.js" is implicitly using "default" export mode, 
> which means for CommonJS output that its default export is assigned to 
> "module.exports". For many tools, such CommonJS output will not be 
> interchangeable with the original ES module. If this is intended, explicitly 
> set "output.exports" to either "auto" or "default", otherwise you might want 
> to consider changing the signature of "src/index.js" to use named exports 
> only.
> https://rollupjs.org/guide/en/#outputexports
> src/index.js
> created dist/rollup-plugin-typescript.cjs.js, 
> dist/rollup-plugin-typescript.es.js in 47ms
> # Step 1: build a temporary @rollup/plugin-typescript
> cd packages/typescript && \
>   ln -s ../../../node_modules/@types/resolve node_modules/ && \
>   mkdir dist && \
>   NODE_PATH=node_modules tsc --module CommonJS --esModuleInterop 
> src/index.ts
> src/index.ts(69,54): error TS2345: Argument of type 'NormalizedOutputOptions' 
> is not assignable to parameter of type 'OutputOptions'.
>   Types of property 'amd' are incompatible.
> Type 'NormalizedAmdOptions' is not assignable to type 'AmdOptions'.
>   Type '{ autoId: false; id?: string; } & { define: string; }' is not 
> assignable to type 'AmdOptions'.
> Type '{ autoId: false; id?: string; } & { define: string; }' is not 
> assignable to type '{ autoId?: false; id: string; } & { define?: string; }'.
>   Type '{ autoId: false; id?: string; } & { define: string; }' is not 
> assignable to type '{ autoId?: false; id: string; }'.
> Property 'id' is optional in type '{ autoId: false; id?: string; 
> } & { define: string; }' but required in type '{ autoId?: false; id: string; 
> }'.
> src/index.ts(70,54): error TS2345: Argument of type 'NormalizedOutputOptions' 
> is not assignable to parameter of type 'OutputOptions'.
> make[1]: *** [debian/rules:25: override_dh_auto_build] Error 2

The full build log is available from:
   
http://qa-logs.debian.net/2020/12/26/node-rollup-plugin-typescript_6.0.0+~1.0.1-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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978171: [Aptitude-devel] Bug#978171: Bug#978171: aptitude: FTBFS: pkgcachegen.h:32:10: fatal error: xxhash.h: No such file or directory

[Axel Beckert]

Hi Sven,

Sven Joachim wrote:
> > Looks like a missing dependency on libxxhash-dev on a first glance.
> >
> > Will check if that helps. (And I wonder where that one got lost.)
> 
> It did not get lost, rather I suppose that the latest apt upload
> introduced this new include without adding a proper dependency on
> libxxhash-dev to libapt-pkg-dev.

That's what I meant with "got lost" more or less. Thanks!

So this should be fixed in src:apt then? (Cc'ing our deities. ;-)

Otherwise I'd do a 0.8.13-3 upload with that b-d added.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

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

[Lucas Nussbaum]

Source: malcontent
Version: 0.10.0-1
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 -- -Dprivileged_group=sudo 
> -Dpamlibdir=/lib/x86_64-linux-gnu/security -Dui=enabled
>   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 -Dprivileged_group=sudo 
> -Dpamlibdir=/lib/x86_64-linux-gnu/security -Dui=enabled
> The Meson build system
> Version: 0.56.0
> Source dir: /<>
> Build dir: /<>/obj-x86_64-linux-gnu
> Build type: native build
> Project name: malcontent
> Project version: 0.10.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'
> C compiler for the host machine: cc (gcc 10.2.1 "cc (Debian 10.2.1-3) 10.2.1 
> 20201224")
> C linker for the host machine: cc ld.bfd 2.35.1
> 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'
> Host machine cpu family: x86_64
> Host machine cpu: x86_64
> Found pkg-config: /usr/bin/pkg-config (0.29.2)
> Run-time dependency dbus-1 found: YES 1.12.20
> Run-time dependency polkit-gobject-1 found: YES 0.105
> Configuring config.h using configuration
> Compiler for C supports arguments -fno-strict-aliasing: YES 
> Compiler for C supports arguments -fstack-protector-strong: YES 
> Compiler for C supports arguments -Waggregate-return: YES 
> Compiler for C supports arguments -Wall: YES 
> Compiler for C supports arguments -Wunused: YES 
> Compiler for C supports arguments -Warray-bounds: YES 
> Compiler for C supports arguments -Wcast-align: YES 
> Compiler for C supports arguments -Wclobbered: YES 
> Compiler for C supports arguments -Wno-declaration-after-statement: YES 
> Compiler for C supports arguments -Wdiscarded-qualifiers: YES 
> Compiler for C supports arguments -Wduplicated-branches: YES 
> Compiler for C supports arguments -Wduplicated-cond: YES 
> Compiler for C supports arguments -Wempty-body: YES 
> Compiler for C supports arguments -Wformat=2: YES 
> Compiler for C supports arguments -Wformat-nonliteral: YES 
> Compiler for C supports arguments -Wformat-security: YES 
> Compiler for C supports arguments -Wformat-signedness: YES 
> Compiler for C supports arguments -Wignored-qualifiers: YES 
> Compiler for C supports arguments -Wimplicit-function-declaration: YES 
> Compiler for C supports arguments -Wincompatible-pointer-types: YES 
> Compiler for C supports arguments 
> -Wincompatible-pointer-types-discards-qualifiers: NO 
> Compiler for C supports arguments -Winit-self: YES 
> Compiler for C supports arguments -Wint-conversion: YES 
> Compiler for C supports arguments -Wlogical-op: YES 
> Compiler for C supports arguments -Wmisleading-indentation: YES 
> Compiler for C supports arguments -Wmissing-declarations: YES 
> Compiler for C supports arguments -Wmissing-format-attribute: YES 
> Compiler for C supports arguments -Wmissing-include-dirs: YES 
> Compiler for C supports arguments -Wmissing-noreturn: YES 
> Compiler for C supports arguments -Wmissing-parameter-type: YES 
> Compiler for C supports arguments -Wmissing-prototypes: YES 
> Compiler for C supports arguments -Wnested-externs: YES 
> Compiler for C supports arguments -Wno-error=cpp: YES 
> Compiler for C supports arguments -Wmissing-field-initializers: YES 
> Compiler for C supports arguments -Wno-suggest-attribute=format: YES 
> Compiler for C supports arguments -Wno-unused-parameter: YES 
> Compiler for C supports arguments -Wnull-dereference: YES 
> Compiler for C supports arguments -Wold-style-definition: YES 
> Compiler for C supports arguments -Woverflow: YES 
> Compiler for C supports arguments -Woverride-init: YES 
> Compiler for C supports arguments -Wparentheses: YES 
> Compiler for C supports arguments -Wpointer-arith: YES 
> Compiler for C supports arguments -Wredundant-decls: YES 
> Compiler for C supports arguments -Wreturn-type: YES 
> Compiler for C supports arguments -Wshadow: YES 
> Compiler for C supports arguments -Wsign-compare: YES 
> Compiler for C suppor

Bug#978389: easyh10: FTBFS: configure.in:184: error: possibly undefined macro: AM_LANGINFO_CODESET (caused by gettext 0.19 -> 0.21?)

[Lucas Nussbaum]

Source: easyh10
Version: 1.5-4
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 autoreconf
>dh_update_autotools_config
>dh_autoreconf
> aclocal: warning: autoconf input should be named 'configure.ac', not 
> 'configure.in'
> configure.in:184: warning: macro 'AM_LANGINFO_CODESET' not found in library
> libtoolize: putting auxiliary files in '.'.
> libtoolize: copying file './ltmain.sh'
> libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.in,
> libtoolize: and rerunning libtoolize and aclocal.
> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> aclocal: warning: autoconf input should be named 'configure.ac', not 
> 'configure.in'
> configure.in:184: warning: macro 'AM_LANGINFO_CODESET' not found in library
> configure.in:184: error: possibly undefined macro: AM_LANGINFO_CODESET
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.
> autoreconf: /usr/bin/autoconf failed with exit status: 1
> dh_autoreconf: error: autoreconf -f -i returned exit code 1
> make: *** [debian/rules:8: build] Error 25

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/easyh10_1.5-4_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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978386: xdemorse: FTBFS: configure:5266: error: possibly undefined macro: AM_INTL_SUBDIR (caused by gettext 0.19 -> 0.21?)

[Lucas Nussbaum]

Source: xdemorse
Version: 3.6.2-1
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 ftbfs-bullseye

Hi,

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

Relevant part (hopefully):
> DC-Build-Header: xdemorse 3.6.2-1 / 2020-12-26 18:40:08 +
> DC-Task: type:rebuild-full source:xdemorse version:3.6.2-1 chroot:unstable 
> esttime:58 logfile:/tmp/xdemorse_3.6.2-1_unstable.log modes:
> DC-Sbuild-call: su user42 -c 'sbuild -n -A -s --force-orig-source 
> --apt-update -d unstable -v --no-run-lintian xdemorse_3.6.2-1'
> sbuild (Debian sbuild) 0.78.1 (09 February 2019) on 
> ip-172-31-1-222.eu-central-1.compute.internal
> 
> +==+
> | xdemorse 3.6.2-1 (amd64) Sat, 26 Dec 2020 18:40:09 
> + |
> +==+
> 
> Package: xdemorse
> Version: 3.6.2-1
> Source Version: 3.6.2-1
> Distribution: unstable
> Machine Architecture: amd64
> Host Architecture: amd64
> Build Architecture: amd64
> Build Type: full
> 
> I: NOTICE: Log filtering will replace 
> 'var/run/schroot/mount/sid-amd64-sbuild-e7df248f-ddfa-48e3-8aa7-7a8b4c41c497' 
> with '<>'
> I: NOTICE: Log filtering will replace 'build/xdemorse-ss4TSw/resolver-j8vHvh' 
> with '<>'
> 
> +--+
> | Update chroot   
>  |
> +--+
> 
> Get:1 http://127.0.0.1:12990/debian sid InRelease [153 kB]
> Get:2 http://127.0.0.1:12990/debian sid/main Sources.diff/Index [27.9 kB]
> Get:3 http://127.0.0.1:12990/debian sid/main amd64 Packages.diff/Index [27.9 
> kB]
> Get:4 http://127.0.0.1:12990/debian sid/main Sources 2020-12-26-0800.12.pdiff 
> [3765 B]
> Get:5 http://127.0.0.1:12990/debian sid/main Sources 2020-12-26-1401.32.pdiff 
> [20.3 kB]
> Get:5 http://127.0.0.1:12990/debian sid/main Sources 2020-12-26-1401.32.pdiff 
> [20.3 kB]
> Get:6 http://127.0.0.1:12990/debian sid/main amd64 Packages 
> 2020-12-26-0800.12.pdiff [3354 B]
> Get:7 http://127.0.0.1:12990/debian sid/main amd64 Packages 
> 2020-12-26-1401.32.pdiff [25.2 kB]
> Get:7 http://127.0.0.1:12990/debian sid/main amd64 Packages 
> 2020-12-26-1401.32.pdiff [25.2 kB]
> Fetched 262 kB in 1s (260 kB/s)
> Reading package lists...
> Reading package lists...
> Building dependency tree...
> Calculating upgrade...
> The following packages will be upgraded:
>   libsystemd0 libudev1
> 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 540 kB of archives.
> After this operation, 0 B of additional disk space will be used.
> Get:1 http://127.0.0.1:12990/debian sid/main amd64 libsystemd0 amd64 247.2-3 
> [374 kB]
> Get:2 http://127.0.0.1:12990/debian sid/main amd64 libudev1 amd64 247.2-3 
> [166 kB]
> debconf: delaying package configuration, since apt-utils is not installed
> Fetched 540 kB in 0s (9194 kB/s)
> (Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 12355 files and directories currently installed.)
> Preparing to unpack .../libsystemd0_247.2-3_amd64.deb ...
> Unpacking libsystemd0:amd64 (247.2-3) over (247.2-2) ...
> Setting up libsystemd0:amd64 (247.2-3) ...
> (Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 12355 files and directories currently installed.)
> Preparing to unpack .../libudev1_247.2-3_amd64.deb ...
> Unpacking libudev1:amd64 (247.2-3) over (247.2-2) ...
> Setting up libudev1:amd64 (247.2-3) ...
> Processing triggers for libc-bin (2.31-6) ...
> 
> +--

Bug#978387: runawk: FTBFS: bmake[2]: "/usr/share/mk-configure/mk/mkc_imp.platform.sys.mk" line 112: 'Settings for gcc-10.2.1 is not available, run "mkc_compiler_settings" utility'

[Lucas Nussbaum]

Source: runawk
Version: 1.6.0-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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=mkcmake
> dh: warning: Compatibility levels before 10 are deprecated (level 9 in use)
>dh_update_autotools_config -O--buildsystem=mkcmake
>dh_auto_configure -O--buildsystem=mkcmake
> dh_auto_configure: warning: Compatibility levels before 10 are deprecated 
> (level 9 in use)
>dh_auto_build -O--buildsystem=mkcmake
> dh_auto_build: warning: Compatibility levels before 10 are deprecated (level 
> 9 in use)
>   mkcmake PREFIX=/usr MANDIR=/usr/share/man INFODIR=/usr/share/info 
> SYSCONFDIR=/etc STRIPFLAG= LIBDIR=/usr/lib/x86_64-linux-gnu 
> LIBEXECDIR=/usr/lib/x86_64-linux-gnu
> ==
> all ===> runawk
> checking C compiler type... gcc 10.2.1
> bmake[2]: "/usr/share/mk-configure/mk/mkc_imp.platform.sys.mk" line 112: 
> 'Settings for gcc-10.2.1 is not available, run "mkc_compiler_settings" 
> utility'
> *** Error code 1
> dh_auto_build: error: mkcmake PREFIX=/usr MANDIR=/usr/share/man 
> INFODIR=/usr/share/info SYSCONFDIR=/etc STRIPFLAG= 
> LIBDIR=/usr/lib/x86_64-linux-gnu LIBEXECDIR=/usr/lib/x86_64-linux-gnu 
> returned exit code 1
> make: *** [debian/rules:6: build] Error 25

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/runawk_1.6.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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978385: elpa: FTBFS: tests failed

[Lucas Nussbaum]

Source: elpa
Version: 2019.11.001-4
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>/build'
> FAIL: validate_c_version_complex_double_eigenvectors_1stage_random_default.sh
> FAIL: 
> validate_c_version_complex_double_eigenvectors_2stage_default_kernel_random_default.sh
> FAIL: validate_c_version_real_double_eigenvectors_1stage_random_default.sh
> FAIL: 
> validate_c_version_real_double_eigenvectors_2stage_default_kernel_random_default.sh
> FAIL: validate_c_version_complex_double_generalized_1stage_random_default.sh
> FAIL: validate_c_version_real_double_generalized_1stage_random_default.sh
> FAIL: 
> validate_c_version_complex_double_generalized_decomp_1stage_random_default.sh
> FAIL: 
> validate_c_version_real_double_generalized_decomp_1stage_random_default.sh
> SKIP: 
> validate_complex_double_eigenvectors_1stage_analytic_all_layouts_extended.sh
> FAIL: validate_complex_double_eigenvectors_1stage_analytic_default.sh
> SKIP: 
> validate_complex_double_eigenvectors_2stage_all_kernels_analytic_all_layouts_extended.sh
> SKIP: 
> validate_complex_double_eigenvectors_2stage_default_kernel_analytic_all_layouts_extended.sh
> SKIP: 
> validate_complex_double_eigenvectors_2stage_all_kernels_analytic_extended.sh
> FAIL: 
> validate_complex_double_eigenvectors_2stage_default_kernel_analytic_default.sh
> SKIP: 
> validate_real_double_eigenvectors_1stage_analytic_all_layouts_extended.sh
> FAIL: validate_real_double_eigenvectors_1stage_analytic_default.sh
> SKIP: 
> validate_real_double_eigenvectors_2stage_all_kernels_analytic_all_layouts_extended.sh
> SKIP: 
> validate_real_double_eigenvectors_2stage_default_kernel_analytic_all_layouts_extended.sh
> SKIP: 
> validate_real_double_eigenvectors_2stage_all_kernels_analytic_extended.sh
> FAIL: 
> validate_real_double_eigenvectors_2stage_default_kernel_analytic_default.sh
> SKIP: validate_real_double_eigenvalues_1stage_frank_all_layouts_extended.sh
> FAIL: validate_real_double_eigenvalues_1stage_frank_default.sh
> SKIP: 
> validate_real_double_eigenvalues_2stage_default_kernel_frank_all_layouts_extended.sh
> FAIL: validate_real_double_eigenvalues_2stage_default_kernel_frank_default.sh
> SKIP: validate_real_double_eigenvectors_1stage_frank_all_layouts_extended.sh
> FAIL: validate_real_double_eigenvectors_1stage_frank_default.sh
> SKIP: 
> validate_real_double_eigenvectors_2stage_all_kernels_frank_all_layouts_extended.sh
> SKIP: 
> validate_real_double_eigenvectors_2stage_default_kernel_frank_all_layouts_extended.sh
> SKIP: validate_real_double_eigenvectors_2stage_all_kernels_frank_extended.sh
> FAIL: validate_real_double_eigenvectors_2stage_default_kernel_frank_default.sh
> SKIP: 
> validate_real_double_hermitian_multiply_1stage_frank_all_layouts_extended.sh
> FAIL: validate_real_double_hermitian_multiply_1stage_frank_default.sh
> SKIP: validate_complex_double_cholesky_1stage_random_all_layouts_extended.sh
> FAIL: validate_complex_double_cholesky_1stage_random_default.sh
> SKIP: validate_real_double_cholesky_1stage_random_all_layouts_extended.sh
> FAIL: validate_real_double_cholesky_1stage_random_default.sh
> FAIL: validate_real_double_cholesky_1stage_random_split_comm_myself_default.sh
> SKIP: 
> validate_complex_double_eigenvectors_1stage_random_all_layouts_extended.sh
> FAIL: validate_complex_double_eigenvectors_1stage_random_default.sh
> SKIP: 
> validate_complex_double_eigenvectors_2stage_all_kernels_random_all_layouts_extended.sh
> SKIP: 
> validate_complex_double_eigenvectors_2stage_default_kernel_random_all_layouts_extended.sh
> SKIP: 
> validate_complex_double_eigenvectors_2stage_all_kernels_random_extended.sh
> FAIL: 
> validate_complex_double_eigenvectors_2stage_default_kernel_random_default.sh
> SKIP: validate_real_double_eigenvectors_1stage_random_all_layouts_extended.sh
> FAIL: validate_real_double_eigenvectors_1stage_random_default.sh
> FAIL: 
> validate_real_double_eigenvectors_1stage_random_split_comm_myself_default.sh
> SKIP: 
> validate_real_double_eigenvectors_2stage_all_kernels_random_all_layouts_extended.sh
> SKIP: 
> validate_real_double_eigenvectors_2stage_default_kernel_random_all_layouts_extended.sh
> SKIP: validate_real_double_eigenvectors_2stage_all_kernels_random_extended.sh
> FAIL: 
> validate_real_double_eigenvectors_2stage_default_kernel_random_default.sh
> FAIL: 
> validate_real_double_eigenvectors_2stage_default_kernel_random_split_comm_myself_default.sh
> FAIL: validate_complex_double_generalized_1stage_

Bug#978384: node-ast-types: FTBFS: node_modules/@babel/parser/typings/babel-parser.d.ts(14,11): error TS7016: Could not find a declaration file for module '@babel/types'. '/<>/node_module

[Lucas Nussbaum]

Source: node-ast-types
Version: 0.14.1-4
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>'
> mkdir -p node_modules/@types
> for toto in @babel esprima minimatch tslib; do \
>   cp -R /usr/share/nodejs/$toto node_modules/ ; \
> done
> for toto in esprima estree glob minimatch mocha node; do \
>   cp -R /usr/share/nodejs/@types/$toto node_modules/@types/ ; \
> done
> tsc
> node_modules/@babel/parser/typings/babel-parser.d.ts(14,11): error TS7016: 
> Could not find a declaration file for module '@babel/types'. 
> '/<>/node_modules/@babel/types/lib/index.js' implicitly has an 
> 'any' type.
>   Try `npm i --save-dev @types/babel__types` if it exists or add a new 
> declaration (.d.ts) file containing `declare module '@babel/types';`
> node_modules/@babel/parser/typings/babel-parser.d.ts(22,11): error TS7016: 
> Could not find a declaration file for module '@babel/types'. 
> '/<>/node_modules/@babel/types/lib/index.js' implicitly has an 
> 'any' type.
>   Try `npm i --save-dev @types/babel__types` if it exists or add a new 
> declaration (.d.ts) file containing `declare module '@babel/types';`
> test/ecmascript.ts(6,29): error TS7016: Could not find a declaration file for 
> module '@babel/types'. 
> '/<>/node_modules/@babel/types/lib/index.js' implicitly has an 
> 'any' type.
>   Try `npm i --save-dev @types/babel__types` if it exists or add a new 
> declaration (.d.ts) file containing `declare module '@babel/types';`
> make[1]: *** [debian/rules:10: override_dh_auto_build] Error 2

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/node-ast-types_0.14.1-4_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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978383: macopix: FTBFS: configure:17428: error: possibly undefined macro: AM_INTL_SUBDIR (caused by gettext 0.19 -> 0.21?)

[Lucas Nussbaum]

Source: macopix
Version: 3.4.0+dfsg.1-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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_autoreconf /<>/autogen.sh
> **警告**: ./configure を引数無しで実行します。
>   もし引数を指定したいのであれば、
>   '/<>/autogen.sh' の引数に指定してください。
> 処理中...
> 削除中... .deps/ ディレクトリ ...
> 確認中... ドキュメントファイル ...
> 確認中... NEWS... 空です。必ず中身を作成してください
> 確認中... README...完了
> 確認中... AUTHORS...完了
> 確認中... ChangeLog...完了
> 確認中... po ファイル ...
> 確認中... po/ja.po ...完了
> 実行中... libtoolize...
> libtoolize: putting auxiliary files in '.'.
> libtoolize: copying file './ltmain.sh'
> libtoolize: putting macros in 'm4'.
> libtoolize: copying file 'm4/libtool.m4'
> libtoolize: copying file 'm4/ltoptions.m4'
> libtoolize: copying file 'm4/ltsugar.m4'
> libtoolize: copying file 'm4/ltversion.m4'
> libtoolize: copying file 'm4/lt~obsolete.m4'
> libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
> libtoolize: and rerunning libtoolize and aclocal.
> 実行中... aclocal  ...
> ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer 
> supported.
> configure.ac:224: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
> /usr/share/aclocal/gettext.m4:55: AM_GNU_GETTEXT is expanded from...
> configure.ac:224: the top level
> configure.ac:389: warning: AC_CACHE_VAL(gnutls_libs, ...): suspicious 
> cache-id, must contain _cv_ to be cached
> ../../lib/autoconf/general.m4:2042: AC_CACHE_VAL is expanded from...
> ../../lib/autoconf/general.m4:2063: AC_CACHE_CHECK is expanded from...
> configure.ac:389: the top level
> 実行中... autoconf...
> ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer 
> supported.
> configure.ac:224: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
> aclocal.m4:77: AM_GNU_GETTEXT is expanded from...
> configure.ac:224: the top level
> configure.ac:389: warning: AC_CACHE_VAL(gnutls_libs, ...): suspicious 
> cache-id, must contain _cv_ to be cached
> ../../lib/autoconf/general.m4:2042: AC_CACHE_VAL is expanded from...
> ../../lib/autoconf/general.m4:2063: AC_CACHE_CHECK is expanded from...
> configure.ac:389: the top level
> configure:17428: error: possibly undefined macro: AM_INTL_SUBDIR
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.
> make[1]: Leaving directory '/<>'
>debian/rules override_dh_auto_configure
> make[1]: Entering directory '/<>'
> dh_auto_configure -- --bindir=/usr/games
>   ./configure --build=x86_64-linux-gnu --prefix=/usr 
> --includedir=\${prefix}/include --mandir=\${prefix}/share/man 
> --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
> --disable-option-checking --disable-silent-rules 
> --libdir=\${prefix}/lib/x86_64-linux-gnu 
> --libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
> --disable-maintainer-mode --disable-dependency-tracking --bindir=/usr/games
> checking build system type... x86_64-pc-linux-gnu
> checking host system type... x86_64-pc-linux-gnu
> checking target system type... x86_64-pc-linux-gnu
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> /bin/bash: /<>/missing: No such file or directory
> configure: WARNING: 'missing' script is too old or missing
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... no
> checking for mawk... mawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether to enable maintainer-specific portions of Makefiles... no
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking whether gcc understands -c and -o together... yes
> checking whether make supports the include directive... yes (GNU style)
> checking dependency style of gcc... none
> checking for library containing strerror... none required
> checking for gcc... (cached) gcc
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> checking for gcc option to accept ISO C89... (cached) none needed
> checking whether gcc understands -c and -o toget

Bug#978382: phpmyadmin: FTBFS: Test directory "./test/engines" not found

[Lucas Nussbaum]

Source: phpmyadmin
Version: 4:4.9.7+dfsg1-1
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>'
> # keep in sync with debian/tests/phpunit
> find test/ -type f -print0 | xargs -0 sed -i 's/function 
> setUpBeforeClass()/function setUpBeforeClass(): void/g'
> find test/ -type f -print0 | xargs -0 sed -i 's/function setUp()/function 
> setUp(): void/g'
> find test/ -type f -print0 | xargs -0 sed -i 's/function tearDown()/function 
> tearDown(): void/g'
> LC_ALL=en_US.UTF-8 phpunit --config phpunit.xml.nocoverage --exclude-group 
> selenium,network,git-revision,environment,extension-iconv
> PHPUnit 9.5.0 by Sebastian Bergmann and contributors.
> 
> Test directory "./test/engines" not found
> make[1]: *** [debian/rules:16: override_dh_auto_test] Error 2

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/phpmyadmin_4.9.7+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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978381: google-recaptcha: FTBFS: TypeError: Argument 2 passed to PHPUnit\Framework\Assert::assertContains() must be iterable, string given, called in /<>/tests/ReCaptcha/RequestMethod

[Lucas Nussbaum]

Source: google-recaptcha
Version: 1.2.4-1
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>'
> # keep in sync with debian/tests/phpunit
> find tests/ -type f -print0 | xargs -0 sed -i 's/function setUp()/function 
> setUp(): void/g'
> find tests/ -type f -print0 | xargs -0 sed -i 's/function tearDown()/function 
> tearDown(): void/g'
> phpunit --no-coverage
> PHPUnit 9.5.0 by Sebastian Bergmann and contributors.
> 
> Runtime:   PHP 7.4.11
> Configuration: /<>/phpunit.xml.dist
> Warning:   Your XML configuration validates against a deprecated schema.
> Suggestion:Migrate your XML configuration using "--migrate-configuration"!
> 
> E.E   51 / 51 
> (100%)
> 
> Time: 00:00.012, Memory: 6.00 MB
> 
> There were 6 errors:
> 
> 1) ReCaptcha\ReCaptchaTest::testExceptionThrownOnInvalidSecret with data set 
> #0 ('')
> RuntimeException: No secret provided
> 
> /<>/src/ReCaptcha/ReCaptcha.php:136
> /<>/tests/ReCaptcha/ReCaptchaTest.php:48
> 
> 2) ReCaptcha\ReCaptchaTest::testExceptionThrownOnInvalidSecret with data set 
> #1 (null)
> RuntimeException: No secret provided
> 
> /<>/src/ReCaptcha/ReCaptcha.php:136
> /<>/tests/ReCaptcha/ReCaptchaTest.php:48
> 
> 3) ReCaptcha\ReCaptchaTest::testExceptionThrownOnInvalidSecret with data set 
> #2 (0)
> RuntimeException: No secret provided
> 
> /<>/src/ReCaptcha/ReCaptcha.php:136
> /<>/tests/ReCaptcha/ReCaptchaTest.php:48
> 
> 4) ReCaptcha\ReCaptchaTest::testExceptionThrownOnInvalidSecret with data set 
> #3 (stdClass Object ())
> RuntimeException: The provided secret must be a string
> 
> /<>/src/ReCaptcha/ReCaptcha.php:140
> /<>/tests/ReCaptcha/ReCaptchaTest.php:48
> 
> 5) ReCaptcha\ReCaptchaTest::testExceptionThrownOnInvalidSecret with data set 
> #4 (array())
> RuntimeException: No secret provided
> 
> /<>/src/ReCaptcha/ReCaptcha.php:136
> /<>/tests/ReCaptcha/ReCaptchaTest.php:48
> 
> 6) ReCaptcha\RequestMethod\PostTest::testHTTPContextOptions
> TypeError: Argument 2 passed to PHPUnit\Framework\Assert::assertContains() 
> must be iterable, string given, called in 
> /<>/tests/ReCaptcha/RequestMethod/PostTest.php on line 118
> 
> /<>/tests/ReCaptcha/RequestMethod/PostTest.php:118
> /<>/tests/ReCaptcha/RequestMethod/PostTest.php:145
> /<>/src/ReCaptcha/RequestMethod/Post.php:80
> /<>/tests/ReCaptcha/RequestMethod/PostTest.php:61
> 
> ERRORS!
> Tests: 51, Assertions: 139, Errors: 6.
> make[1]: *** [debian/rules:11: override_dh_auto_test] Error 2

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/google-recaptcha_1.2.4-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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978380: ssl-utils-clojure: FTBFS: missing deps

[Lucas Nussbaum]

Source: ssl-utils-clojure
Version: 3.1.0-1
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>'
> lein pom debian/pom.xml
> Cannot access central (https://repo1.maven.org/maven2/) in offline mode and 
> the artifact com.fasterxml.jackson.core:jackson-core:jar:debian has not been 
> downloaded from it before.
> Cannot access clojars (https://repo.clojars.org/) in offline mode and the 
> artifact com.fasterxml.jackson.core:jackson-core:jar:debian has not been 
> downloaded from it before.
> Cannot access central (https://repo1.maven.org/maven2/) in offline mode and 
> the artifact 
> com.fasterxml.jackson.dataformat:jackson-dataformat-smile:jar:debian has not 
> been downloaded from it before.
> Cannot access clojars (https://repo.clojars.org/) in offline mode and the 
> artifact com.fasterxml.jackson.dataformat:jackson-dataformat-smile:jar:debian 
> has not been downloaded from it before.
> Cannot access central (https://repo1.maven.org/maven2/) in offline mode and 
> the artifact 
> com.fasterxml.jackson.dataformat:jackson-dataformat-cbor:jar:debian has not 
> been downloaded from it before.
> Cannot access clojars (https://repo.clojars.org/) in offline mode and the 
> artifact com.fasterxml.jackson.dataformat:jackson-dataformat-cbor:jar:debian 
> has not been downloaded from it before.
> This could be due to a typo in :dependencies, file system permissions, or 
> network issues.
> If you are behind a proxy, try setting the 'http_proxy' environment variable.
> make[1]: *** [debian/rules:17: override_dh_auto_build] Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/ssl-utils-clojure_3.1.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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978379: zhcon: FTBFS: configure:5812: error: possibly undefined macro: AM_INTL_SUBDIR (caused by gettext 0.19 -> 0.21?)

[Lucas Nussbaum]

Source: zhcon
Version: 1:0.2.6-17
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>'
> touch config.rpath
> make[1]: Leaving directory '/<>'
>dh_autoreconf
> aclocal: warning: autoconf input should be named 'configure.ac', not 
> 'configure.in'
> ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer 
> supported.
> configure.in:106: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
> /usr/share/aclocal/gettext.m4:55: AM_GNU_GETTEXT is expanded from...
> configure.in:106: the top level
> ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer 
> supported.
> configure.in:106: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
> aclocal.m4:77: AM_GNU_GETTEXT is expanded from...
> configure.in:106: the top level
> autoreconf: configure.in: AM_GNU_GETTEXT is used, but not 
> AM_GNU_GETTEXT_VERSION
> ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer 
> supported.
> configure.in:106: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
> aclocal.m4:77: AM_GNU_GETTEXT is expanded from...
> configure.in:106: the top level
> configure:5812: error: possibly undefined macro: AM_INTL_SUBDIR
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.
> autoreconf: /usr/bin/autoconf failed with exit status: 1
> dh_autoreconf: error: autoreconf -f -i returned exit code 1
> make: *** [debian/rules:6: binary] Error 25

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/zhcon_0.2.6-17_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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978378: php-gettext: FTBFS: test failed

[Lucas Nussbaum]

Source: php-gettext
Version: 1.0.12-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>'
> phpunit --verbose tests
> PHPUnit 9.5.0 by Sebastian Bergmann and contributors.
> 
> Runtime:   PHP 7.4.11
> 
> Warning:   Test case class not matching filename is deprecated
>in /<>/tests/LocalesTest.php
>Class name was 'LocaleTest', expected 'LocalesTest'
> 
> .E... 65 / 93 ( 
> 69%)
>   93 / 93 
> (100%)
> 
> Time: 00:00.015, Memory: 6.00 MB
> 
> There was 1 error:
> 
> 1) ParsingTest::test_select_string_disallows_nonint_numbers
> InvalidArgumentException: Select_string only accepts integers: 
> (file_put_contents('/tmp/pgzeqVqj', 'boom'))
> 
> /<>/gettext.php:321
> /<>/tests/ParsingTest.php:66
> 
> ERRORS!
> Tests: 93, Assertions: 631, Errors: 1.
> make[1]: *** [Makefile:26: check] Error 2

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/php-gettext_1.0.12-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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978377: apertium-eo-fr: FTBFS: Error: Invalid dictionary (hint: entry on the right beginning with whitespace)

[Lucas Nussbaum]

Source: apertium-eo-fr
Version: 0.9.0~r57551-3
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>'
> apertium-validate-dictionary apertium-eo-fr.fr.dix
> apertium-eo-fr.fr.dix:4195: element pardef: Schemas validity error : Element 
> 'pardef': Duplicate key-sequence ['fa/illir__vblex'] in unique 
> identity-constraint 'pardef-unique'.
> apertium-eo-fr.fr.dix:6615: element pardef: Schemas validity error : Element 
> 'pardef': Duplicate key-sequence ['épou/x__n'] in unique identity-constraint 
> 'pardef-unique'.
> lt-comp lr apertium-eo-fr.fr.dix fr-eo.automorf.bin apertium-eo-fr.fr.acx
> apostrophes@postblank 3758 5345
> final@inconditional 69 424
> main@standard 92977 155700
> negations@standard 35117 49188
> negations_apost@postblank 3334 4708
> unstandard_orth@standard 4572 6896
> unstandard_orth_apost@postblank 139 180
> apertium-validate-dictionary apertium-eo-fr.eo-fr.dix
> lt-comp rl apertium-eo-fr.eo-fr.dix fr-eo.autobil.bin
> Error: Invalid dictionary (hint: entry on the right beginning with whitespace)
> make[2]: *** [Makefile:783: fr-eo.autobil.bin] Error 1

The full build log is available from:
   
http://qa-logs.debian.net/2020/12/26/apertium-eo-fr_0.9.0~r57551-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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978376: paexec: FTBFS: bmake[2]: "/usr/share/mk-configure/mk/mkc_imp.platform.sys.mk" line 112: 'Settings for gcc-10.2.1 is not available, run "mkc_compiler_settings" utility'

[Lucas Nussbaum]

Source: paexec
Version: 1.1.1-1
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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=mkcmake
>dh_update_autotools_config -O--buildsystem=mkcmake
>dh_autoreconf -O--buildsystem=mkcmake
>dh_auto_configure -O--buildsystem=mkcmake
>dh_auto_build -O--buildsystem=mkcmake
>   mkcmake PREFIX=/usr MANDIR=/usr/share/man INFODIR=/usr/share/info 
> SYSCONFDIR=/etc STRIPFLAG= LIBDIR=/usr/lib/x86_64-linux-gnu 
> LIBEXECDIR=/usr/lib/x86_64-linux-gnu
> checking custom test custom_awk_fflush... 1
> checking for program runawk... /usr/bin/runawk
> ==
> all ===> paexec
> checking C compiler type... gcc 10.2.1
> bmake[2]: "/usr/share/mk-configure/mk/mkc_imp.platform.sys.mk" line 112: 
> 'Settings for gcc-10.2.1 is not available, run "mkc_compiler_settings" 
> utility'
> *** Error code 1
> dh_auto_build: error: mkcmake PREFIX=/usr MANDIR=/usr/share/man 
> INFODIR=/usr/share/info SYSCONFDIR=/etc STRIPFLAG= 
> LIBDIR=/usr/lib/x86_64-linux-gnu LIBEXECDIR=/usr/lib/x86_64-linux-gnu 
> returned exit code 1
> make: *** [debian/rules:7: build] Error 25

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/paexec_1.1.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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978375: gkdebconf: FTBFS: error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.19 but the autoconf macros are from gettext version 0.20

[Lucas Nussbaum]

Source: gkdebconf
Version: 2.1.0
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>'
> Making all in po
> make[3]: Entering directory '/<>/po'
> *** error: gettext infrastructure mismatch: using a Makefile.in.in from 
> gettext version 0.19 but the autoconf macros are from gettext version 0.20
> make[3]: *** [Makefile:168: stamp-po] Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/gkdebconf_2.1.0_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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978374: sundials: FTBFS: tests failed

[Lucas Nussbaum]

Source: sundials
Version: 4.1.0+dfsg-3
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>'
> (cd debian/build; OMPI_MCA_rmaps_base_oversubscribe=1 ../nofakeroot ctest)
> Test project /<>/debian/build
>   Start  1: ark_analytic
>  1/76 Test  #1: ark_analytic ..   Passed  
>   0.00 sec
>   Start  2: cvRoberts_dns
>  2/76 Test  #2: cvRoberts_dns .   Passed  
>   0.00 sec
>   Start  3: cvsRoberts_dns
>  3/76 Test  #3: cvsRoberts_dns    Passed  
>   0.00 sec
>   Start  4: idaRoberts_dns
>  4/76 Test  #4: idaRoberts_dns    Passed  
>   0.00 sec
>   Start  5: idasRoberts_dns
>  5/76 Test  #5: idasRoberts_dns ...   Passed  
>   0.00 sec
>   Start  6: kinRoberts_fp
>  6/76 Test  #6: kinRoberts_fp .   Passed  
>   0.00 sec
>   Start  7: test_nvector_serial_1000_0
>  7/76 Test  #7: test_nvector_serial_1000_0    Passed  
>   0.00 sec
>   Start  8: test_nvector_serial_1_0
>  8/76 Test  #8: test_nvector_serial_1_0 ...   Passed  
>   0.04 sec
>   Start  9: test_nvector_mpi_1000_0
>  9/76 Test  #9: test_nvector_mpi_1000_0 ...***Failed  
>   0.03 sec
>   Start 10: test_nvector_mpi_4_1000_0
> 10/76 Test #10: test_nvector_mpi_4_1000_0 .***Failed  
>   0.01 sec
>   Start 11: test_nvector_parhyp_1000_0
> 11/76 Test #11: test_nvector_parhyp_1000_0 ***Failed  
>   0.02 sec
>   Start 12: test_nvector_parhyp_4_1000_0
> 12/76 Test #12: test_nvector_parhyp_4_1000_0 ..***Failed  
>   0.01 sec
>   Start 13: test_nvector_openmp_1000_1_0
> 13/76 Test #13: test_nvector_openmp_1000_1_0 ..   Passed  
>   0.01 sec
>   Start 14: test_nvector_openmp_1000_2_0
> 14/76 Test #14: test_nvector_openmp_1000_2_0 ..   Passed  
>   0.01 sec
>   Start 15: test_nvector_openmp_1000_4_0
> 15/76 Test #15: test_nvector_openmp_1000_4_0 ..   Passed  
>   0.01 sec
>   Start 16: test_nvector_openmp_1_1_0
> 16/76 Test #16: test_nvector_openmp_1_1_0 .   Passed  
>   0.05 sec
>   Start 17: test_nvector_openmp_1_2_0
> 17/76 Test #17: test_nvector_openmp_1_2_0 .   Passed  
>   0.03 sec
>   Start 18: test_nvector_openmp_1_4_0
> 18/76 Test #18: test_nvector_openmp_1_4_0 .   Passed  
>   0.03 sec
>   Start 19: test_nvector_petsc_1000_0
> 19/76 Test #19: test_nvector_petsc_1000_0 .***Failed  
>   0.02 sec
>   Start 20: test_nvector_petsc_4_1000_0
> 20/76 Test #20: test_nvector_petsc_4_1000_0 ...***Failed  
>   0.01 sec
>   Start 21: test_sunmatrix_dense_100_100_0
> 21/76 Test #21: test_sunmatrix_dense_100_100_0    Passed  
>   0.00 sec
>   Start 22: test_sunmatrix_dense_200_1000_0
> 22/76 Test #22: test_sunmatrix_dense_200_1000_0 ...   Passed  
>   0.01 sec
>   Start 23: test_sunmatrix_dense_2000_100_0
> 23/76 Test #23: test_sunmatrix_dense_2000_100_0 ...   Passed  
>   0.01 sec
>   Start 24: test_sunmatrix_band_10_2_3_0
> 24/76 Test #24: test_sunmatrix_band_10_2_3_0 ..   Passed  
>   0.00 sec
>   Start 25: test_sunmatrix_band_300_7_4_0
> 25/76 Test #25: test_sunmatrix_band_300_7_4_0 .   Passed  
>   0.00 sec
>   Start 26: test_sunmatrix_band_1000_8_8_0
> 26/76 Test #26: test_sunmatrix_band_1000_8_8_0    Passed  
>   0.00 sec
>   Start 27: test_sunmatrix_band_5000_3_20_0
> 27/76 Test #27: test_sunmatrix_band_5000_3_20_0 ...   Passed  
>   0.02 sec
>   Start 28: test_sunmatrix_sparse_400_400_0_0
> 28/76 Test #28: test_sunmatrix_sparse_400_400_0_0 .   Passed  
>   0.02 sec
>   Start 29: test_sunmatrix_sparse_450_450_1_0
> 29/76 Test #29: test_sunmatrix_sparse_450_450_1_0 .   Passed  
>   0.02 sec
>   Start 30: test_sunmatrix_sparse_200_1000_0_0
> 30/76 Test #30: test_sunmatrix_sparse_200_1000_0_0    Passed  
>   0.01 sec
>   Start 31: test_sunmatrix_sparse_6000_350_0_0
> 31/76 Test #31: test_sunmatrix_sparse_6000_350_0_0    Pas

Bug#978373: node-deep-eql: FTBFS: Error: module type-detect in /<> not found

[Lucas Nussbaum]

Source: node-deep-eql
Version: 4.0.0-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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
> browserify-lite ./index.js --standalone deepEqual --outfile deep-eql.tmp.js
> /usr/share/nodejs/browserify-lite/cli.js:29
>   if (err) throw err;
>^
> 
> Error: module type-detect in /<> not found
> at trySearchPath (/usr/share/nodejs/browserify-lite/index.js:269:32)
> at /usr/share/nodejs/browserify-lite/index.js:274:7
> at /usr/share/nodejs/browserify-lite/index.js:294:21
> at FSReqCallback.oncomplete (fs.js:168:21)
> make[1]: *** [debian/rules:14: override_dh_auto_build] Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/node-deep-eql_4.0.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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978372: ap-utils: FTBFS: configure:5103: error: possibly undefined macro: AM_INTL_SUBDIR (caused by gettext 0.19 -> 0.21?)

[Lucas Nussbaum]

Source: ap-utils
Version: 1.5-4
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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
>dh_update_autotools_config
>dh_autoreconf
> aclocal: warning: autoconf input should be named 'configure.ac', not 
> 'configure.in'
> ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer 
> supported.
> configure.in:56: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
> /usr/share/aclocal/gettext.m4:55: AM_GNU_GETTEXT is expanded from...
> configure.in:56: the top level
> ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer 
> supported.
> configure.in:56: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
> aclocal.m4:77: AM_GNU_GETTEXT is expanded from...
> configure.in:56: the top level
> autoreconf: configure.in: AM_GNU_GETTEXT is used, but not 
> AM_GNU_GETTEXT_VERSION
> ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer 
> supported.
> configure.in:56: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
> aclocal.m4:77: AM_GNU_GETTEXT is expanded from...
> configure.in:56: the top level
> configure:5103: error: possibly undefined macro: AM_INTL_SUBDIR
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.
> autoreconf: /usr/bin/autoconf failed with exit status: 1
> dh_autoreconf: error: autoreconf -f -i returned exit code 1
> make: *** [debian/rules:18: build] Error 25

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/ap-utils_1.5-4_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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978371: gnokii: FTBFS: configure.in:74: error: possibly undefined macro: AM_LANGINFO_CODESET (caused by gettext 0.19 -> 0.21?)

[Lucas Nussbaum]

Source: gnokii
Version: 0.6.30+dfsg-1.2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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
> dh_autoreconf
> aclocal: warning: autoconf input should be named 'configure.ac', not 
> 'configure.in'
> configure.in:74: warning: macro 'AM_LANGINFO_CODESET' not found in library
> configure.in:112: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected 
> in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from...
> m4/libtool.m4:1022: _LT_SYS_MODULE_PATH_AIX is expanded from...
> m4/libtool.m4:4170: _LT_LINKER_SHLIBS is expanded from...
> m4/libtool.m4:5253: _LT_LANG_C_CONFIG is expanded from...
> m4/libtool.m4:138: _LT_SETUP is expanded from...
> m4/libtool.m4:67: LT_INIT is expanded from...
> m4/libtool.m4:102: AC_PROG_LIBTOOL is expanded from...
> configure.in:112: the top level
> configure.in:112: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected 
> in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from...
> m4/libtool.m4:4170: _LT_LINKER_SHLIBS is expanded from...
> m4/libtool.m4:5253: _LT_LANG_C_CONFIG is expanded from...
> m4/libtool.m4:138: _LT_SETUP is expanded from...
> m4/libtool.m4:67: LT_INIT is expanded from...
> m4/libtool.m4:102: AC_PROG_LIBTOOL is expanded from...
> configure.in:112: the top level
> configure.in:112: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected 
> in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from...
> m4/libtool.m4:1022: _LT_SYS_MODULE_PATH_AIX is expanded from...
> m4/libtool.m4:4170: _LT_LINKER_SHLIBS is expanded from...
> m4/libtool.m4:5253: _LT_LANG_C_CONFIG is expanded from...
> m4/libtool.m4:138: _LT_SETUP is expanded from...
> m4/libtool.m4:67: LT_INIT is expanded from...
> m4/libtool.m4:102: AC_PROG_LIBTOOL is expanded from...
> configure.in:112: the top level
> configure.in:112: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected 
> in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from...
> m4/libtool.m4:4170: _LT_LINKER_SHLIBS is expanded from...
> m4/libtool.m4:5253: _LT_LANG_C_CONFIG is expanded from...
> m4/libtool.m4:138: _LT_SETUP is expanded from...
> m4/libtool.m4:67: LT_INIT is expanded from...
> m4/libtool.m4:102: AC_PROG_LIBTOOL is expanded from...
> configure.in:112: the top level
> configure.in:112: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected 
> in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from...
> m4/libtool.m4:1022: _LT_SYS_MODULE_PATH_AIX is expanded from...
> m4/libtool.m4:4170: _LT_LINKER_SHLIBS is expanded from...
> m4/libtool.m4:5253: _LT_LANG_C_CONFIG is expanded from...
> m4/libtool.m4:138: _LT_SETUP is expanded from...
> m4/libtool.m4:67: LT_INIT is expanded from...
> m4/libtool.m4:102: AC_PROG_LIBTOOL is expanded from...
> configure.in:112: the top level
> configure.in:112: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected 
> in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from...
> m4/libtool.m4:4170: _LT_LINKER_SHLIBS is expanded from...
> m4/libtool.m4:5253: _LT_LANG_C_CONFIG is expanded from...
> m4/libtool.m4:138: _LT_SETUP is expanded from...
> m4/libtool.m4:67: LT_INIT is expanded from...
> m4/libtool.m4:102: AC_PROG_LIBTOOL is expanded from...
> configure.in:112: the top level
> libtoolize: putting auxiliary files in '.'.
> libtoolize: copying file './ltmain.sh'
> libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
> libtoolize: copying file 'm4/libtool.m4'
> libtoolize: copying file 'm4/ltoptions.m4'
> libtoolize: copying file 'm4/ltsugar.m4'
> libtoolize: copying file 'm4/ltversion.m4'
> libtoolize: copying file 'm4/lt~o

Bug#978370: lgeneral: FTBFS: configure:5729: error: possibly undefined macro: AM_INTL_SUBDIR (caused by gettext 0.19 -> 0.21?)

[Lucas Nussbaum]

Source: lgeneral
Version: 1.4.3-1
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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
>dh_update_autotools_config
>dh_autoreconf
> aclocal: warning: autoconf input should be named 'configure.ac', not 
> 'configure.in'
> ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer 
> supported.
> configure.in:6: warning: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET
> ../../lib/autoconf/general.m4:1844: AC_CANONICAL_TARGET is expanded from...
> configure.in:6: the top level
> configure.in:41: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
> /usr/share/aclocal/gettext.m4:55: AM_GNU_GETTEXT is expanded from...
> configure.in:41: the top level
> ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer 
> supported.
> configure.in:6: warning: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET
> ../../lib/autoconf/general.m4:1844: AC_CANONICAL_TARGET is expanded from...
> configure.in:6: the top level
> configure.in:41: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
> aclocal.m4:77: AM_GNU_GETTEXT is expanded from...
> configure.in:41: the top level
> autoreconf: configure.in: AM_GNU_GETTEXT is used, but not 
> AM_GNU_GETTEXT_VERSION
> ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer 
> supported.
> configure.in:6: warning: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET
> ../../lib/autoconf/general.m4:1844: AC_CANONICAL_TARGET is expanded from...
> configure.in:6: the top level
> configure.in:41: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
> aclocal.m4:77: AM_GNU_GETTEXT is expanded from...
> configure.in:41: the top level
> configure:5729: error: possibly undefined macro: AM_INTL_SUBDIR
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.
> autoreconf: /usr/bin/autoconf failed with exit status: 1
> dh_autoreconf: error: autoreconf -f -i returned exit code 1
> make: *** [debian/rules:8: build] Error 25

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/lgeneral_1.4.3-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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978369: apertium-eo-ca: FTBFS: Error: Invalid dictionary (hint: entry on the right beginning with whitespace)

[Lucas Nussbaum]

Source: apertium-eo-ca
Version: 1:0.9.1~r60655-4
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>'
> apertium-validate-dictionary apertium-eo-ca.ca.dix
> apertium-validate-dictionary apertium-eo-ca.eo-ca.dix
> ./transliterate.sh apertium-eo-ca.eo-ca.dix >apertium-eo-ca.eo-ca.dix.translit
> apertium-validate-dictionary apertium-eo-ca.eo.dix
> ./transliterate.sh apertium-eo-ca.eo.dix >apertium-eo-ca.eo.dix.translit
> lt-comp rl apertium-eo-ca.eo.dix ca-eo.autogen.bin
> apertium-validate-dictionary apertium-eo-ca.post-eo.dix
> lt-comp lr apertium-eo-ca.post-eo.dix ca-eo.autopgen.bin
> main@standard 29 45
> ./transliterate.sh apertium-eo-ca.post-eo.dix 
> >apertium-eo-ca.post-eo.dix.translit
> apertium-validate-transfer apertium-eo-ca.ca-eo.t1x
> apertium-eo-ca.ca.dix:867: element pardef: Schemas validity error : Element 
> 'pardef': Duplicate key-sequence ['/ampli__adj'] in unique 
> identity-constraint 'pardef-unique'.
> apertium-eo-ca.ca.dix:3606: element pardef: Schemas validity error : Element 
> 'pardef': Duplicate key-sequence ['angl/ès__n'] in unique identity-constraint 
> 'pardef-unique'.
> apertium-eo-ca.ca.dix:8883: element pardef: Schemas validity error : Element 
> 'pardef': Duplicate key-sequence ['fo/ndre__vblex'] in unique 
> identity-constraint 'pardef-unique'.
> apertium-eo-ca.ca.dix:15192: element pardef: Schemas validity error : Element 
> 'pardef': Duplicate key-sequence ['concórr/er__vblex'] in unique 
> identity-constraint 'pardef-unique'.
> apertium-preprocess-transfer apertium-eo-ca.ca-eo.t1x ca-eo.t1x.bin
> lt-comp lr apertium-eo-ca.ca.dix ca-eo.automorf.bin apertium-eo-ca.ca.acx
> Warning (3135): Paths to rule 25 blocked by rule 7.
> Warning (4174): Paths to rule 33 blocked by rule 27.
> Warning (4174): Paths to rule 33 blocked by rule 27.
> lt-comp rl apertium-eo-ca.eo-ca.dix ca-eo.autobil.bin
> Warning (7438): Paths to rule 61 blocked by rule 60.
> Warning (7438): Paths to rule 61 blocked by rule 60.
> Warning (7438): Paths to rule 61 blocked by rule 60.
> Warning (7438): Paths to rule 61 blocked by rule 60.
> Warning (11728): Paths to rule 94 blocked by rule 93.
> Warning (11728): Paths to rule 94 blocked by rule 93.
> Warning (11728): Paths to rule 94 blocked by rule 93.
> Warning (11728): Paths to rule 94 blocked by rule 93.
> Warning (11728): Paths to rule 94 blocked by rule 93.
> Warning (11728): Paths to rule 94 blocked by rule 93.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (12094): Paths to rule 97 blocked by rule 96.
> Warning (13173): Paths to rule 109 blocked by rule 24.
> Warning (13173): Paths to rule 109 blocked by rule 24.
> Warning (13173): Paths to rule 109 blocked by rule 24.
> Warning (13173): Paths to rule 109 blocked by rule 24.
> final@inconditional 15 60
> main@standard 45269 82925
> apertium-validate-interchunk apertium-eo-ca.ca-eo.antaux_t2x
> apertium-preprocess-transfer apertium-eo-ca.ca-eo.antaux_t2x 
> ca-eo.antaux_t2x.bin
> apertium-validate-interchunk apertium-eo-ca.ca-eo.antaux2_t2x
> apertium-preprocess-transfer apertium-eo-ca.ca-eo.antaux2_t2x 
> ca-eo.antaux2_t2x.bin
> apertium-validate-interchunk apertium-eo-ca.ca-eo.t2x
> apertium-preprocess-transfer apertium-eo-ca.ca-eo.t2x ca-eo.t2x.bin
> Warning (2020): Paths to rule 29 blocked by rule 26.
> Warning (2020): Paths to rule 29 blocked by rule 26.
> Warning (2020): Paths to rule 29 blocked by rule 26.
> Warning (2020): Paths to rule 29 blocked by rule 26.
> Warning (2020): Paths to rule 29 blocked by rule 26.
> Warning (2020): Paths to rule 29 blocked by rule 26.
> Warning (2020): Paths to rule 29 blocked by rule 26.
> Warning (2020

Bug#978368: ibus-anthy: FTBFS: error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.19 but the autoconf macros are from gettext version 0.20

[Lucas Nussbaum]

Source: ibus-anthy
Version: 1.5.11-1
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>/m4'
> make[3]: Nothing to be done for 'all'.
> make[3]: Leaving directory '/<>/m4'
> Making all in po
> make[3]: Entering directory '/<>/po'
> *** error: gettext infrastructure mismatch: using a Makefile.in.in from 
> gettext version 0.19 but the autoconf macros are from gettext version 0.20
> make[3]: *** [Makefile:234: stamp-po] Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/ibus-anthy_1.5.11-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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978367: libmaa: FTBFS: bmake[2]: "/usr/share/mk-configure/mk/mkc_imp.platform.sys.mk" line 112: 'Settings for gcc-10.2.1 is not available, run "mkc_compiler_settings" utility'

[Lucas Nussbaum]

Source: libmaa
Version: 1.4.7-1
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 libmaa
> dpkg-buildpackage: info: source version 1.4.7-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Robert Luberda 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
> dpkg-source: info: using options from libmaa-1.4.7/debian/source/options: 
> --diff-ignore --tar-ignore
>  debian/rules clean
> dh "clean" --buildsystem=mkcmake
>dh_auto_clean -O--buildsystem=mkcmake
>   mkcmake PREFIX=/usr MANDIR=/usr/share/man INFODIR=/usr/share/info 
> SYSCONFDIR=/etc STRIPFLAG= LIBDIR=/usr/lib/x86_64-linux-gnu 
> LIBEXECDIR=/usr/lib/x86_64-linux-gnu distclean
> bmake[1]: "/usr/share/mk-configure/mk/mkc_imp.mk" line 8: warning: "Target 
> 'distclean' is deprecated, please use 'cleandir'"
> ==
> cleandir ===> doc
> rm -f  /<>/_mkc_* pod2htmd.tmp pod2htmi.tmp   
> ==
> cleandir ===> maa
> rm -f  /<>/_mkc_* .depend_maa *.d  arggram.c pod2htmd.tmp 
> pod2htmi.tmp export.sym.tmp   *.o *.os *.op libmaa.a libmaa_pic.a libmaa_p.a 
> libmaa.so libmaa.so.4  libmaa.so.4.0   
> ==
> cleandir ===> tests/arg
> rm -f  /<>/_mkc_* .depend_arg *.d  check_mkc_err_msg 
> /<>/tests/arg/arg.test.out pod2htmd.tmp pod2htmi.tmp   *.o 
> argtest  
> ==
> cleandir ===> tests/base
> rm -f  /<>/_mkc_* .depend_base *.d  check_mkc_err_msg 
> /<>/tests/base/base.test.out pod2htmd.tmp pod2htmi.tmp   *.o 
> basetest  
> ==
> cleandir ===> tests/basics
> rm -f  /<>/_mkc_* .depend_basics *.d  check_mkc_err_msg 
> /<>/tests/basics/basics.test.out pod2htmd.tmp pod2htmi.tmp   *.o 
> basicstest  
> ==
> cleandir ===> tests/bit
> rm -f  /<>/_mkc_* .depend_bit *.d  check_mkc_err_msg 
> /<>/tests/bit/bit.test.out pod2htmd.tmp pod2htmi.tmp   *.o 
> bittest  
> ==
> cleandir ===> tests/debug
> rm -f  /<>/_mkc_* .depend_debug *.d  check_mkc_err_msg 
> /<>/tests/debug/debug.test.out pod2htmd.tmp pod2htmi.tmp   *.o 
> debugtest  
> ==
> cleandir ===> tests/hash
> rm -f  /<>/_mkc_* .depend_hash *.d  check_mkc_err_msg 
> /<>/tests/hash/hash.test.out pod2htmd.tmp pod2htmi.tmp   *.o 
> hashtest  
> ==
> cleandir ===> tests/list
> rm -f  /<>/_mkc_* .depend_list *.d  check_mkc_err_msg 
> /<>/tests/list/list.test.out pod2htmd.tmp pod2htmi.tmp   *.o 
> listtest  
> ==
> cleandir ===> tests/log
> rm -f  /<>/_mkc_* .depend_log *.d  check_mkc_err_msg 
> /<>/tests/log/log.test.out pod2htmd.tmp pod2htmi.tmp   *.o 
> logtest  
> ==
> cleandir ===> tests/memstr
> rm -f  /<>/_mkc_* .depend_memstr *.d  check_mkc_err_msg 
> /<>/tests/memstr/memstr.test.out pod2htmd.tmp pod2htmi.tmp   *.o 
> memstrtest  
> ==
> cleandir ===> tests/memobj
> rm -f  /<>/_mkc_* .depend_memobj *.d  check_mkc_err_msg 
> /<>/tests/memobj/memobj.test.out pod2htmd.tmp pod2htmi.tmp   *.o 
> memobjtest  
> ==
> cleandir ===> tests/prime
> rm -f  /<>/_mkc_* .depend_prime *.d  check_mkc_err_msg 
> /<>/tests/prime/prime.test.out pod2htmd.tmp pod2htmi.tmp   *.o 
> primetest  
> ==
> cleandir ===> tests/pr
> rm -f  /<>/_mkc_* .depend_pr *.d  check_mkc_err_msg 
> /<>/tests/pr/pr.test.out pod2htmd.tmp pod2htmi.tmp   *.o prtest  
> ==
> cleandir ===> tests/prm
> rm -f  /<>/_mkc_* .depend_prm *.d  check_mkc_err_msg 
> /<>/tests/prm/prm.test.out pod2htmd.tmp pod2htmi.tmp   *.o 
> prmtest  
> ==
> cleandir ===> tests/set
> rm -f  /<>/_m

Bug#978366: xracer: FTBFS: configure:13143: error: possibly undefined macro: AM_INTL_SUBDIR (caused by gettext 0.19 -> 0.21?)

[Lucas Nussbaum]

Source: xracer
Version: 0.96.9.1-10
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>'
> ln -sf /usr/share/gettext/config.rpath ./xracer-0.96.9
> cd xracer-0.96.9 && libtoolize -f -c
> libtoolize: putting auxiliary files in '.'.
> libtoolize: copying file './ltmain.sh'
> libtoolize: You should add the contents of the following files to 
> 'aclocal.m4':
> libtoolize:   '/usr/share/aclocal/libtool.m4'
> libtoolize:   '/usr/share/aclocal/ltoptions.m4'
> libtoolize:   '/usr/share/aclocal/ltsugar.m4'
> libtoolize:   '/usr/share/aclocal/ltversion.m4'
> libtoolize:   '/usr/share/aclocal/lt~obsolete.m4'
> libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.in,
> libtoolize: and rerunning libtoolize and aclocal.
> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> cd xracer-0.96.9 && autoreconf -fi
> aclocal: warning: autoconf input should be named 'configure.ac', not 
> 'configure.in'
> ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer 
> supported.
> configure.in:37: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
> /usr/share/aclocal/gettext.m4:55: AM_GNU_GETTEXT is expanded from...
> configure.in:37: the top level
> ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer 
> supported.
> configure.in:37: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
> aclocal.m4:77: AM_GNU_GETTEXT is expanded from...
> configure.in:37: the top level
> autoreconf: configure.in: AM_GNU_GETTEXT is used, but not 
> AM_GNU_GETTEXT_VERSION
> libtoolize: putting auxiliary files in '.'.
> libtoolize: copying file './ltmain.sh'
> libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.in,
> libtoolize: and rerunning libtoolize and aclocal.
> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> aclocal: warning: autoconf input should be named 'configure.ac', not 
> 'configure.in'
> configure.in:37: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
> /usr/share/aclocal/gettext.m4:55: AM_GNU_GETTEXT is expanded from...
> configure.in:37: the top level
> ERROR: Use of AM_GNU_GETTEXT without [external] argument is no longer 
> supported.
> configure.in:37: warning: AM_INTL_SUBDIR is m4_require'd but not m4_defun'd
> aclocal.m4:77: AM_GNU_GETTEXT is expanded from...
> configure.in:37: the top level
> configure:13143: error: possibly undefined macro: AM_INTL_SUBDIR
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.
> autoreconf: /usr/bin/autoconf failed with exit status: 1
> make[1]: *** [debian/rules:23: override_dh_auto_configure] Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/xracer_0.96.9.1-10_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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978365: fonts-inter: FTBFS: fontmake: Error: In 'src/Inter.glyphs' -> 'master_ufo/Inter.designspace' -> 'master_ufo/instance_ufo/Inter-Thin.ufo': Compiling UFO failed: master_ufo/instance_ufo/Inte

[Lucas Nussbaum]

Source: fonts-inter
Version: 3.15+ds-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>'
> fontmake -i -o otf -g src/Inter.glyphs
> INFO:fontmake.font_project:Building master UFOs and designspace from Glyphs 
> source
> INFO:glyphsLib.classes:Parsing "src/Inter.glyphs" file into 
> WARNING:glyphsLib.builder.components:Glyph 'A': All components of the 
> background layer of 'Black' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'Lambda': All components of the 
> background layer of 'Regular' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'Lambda': All components of the 
> background layer of 'Black' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'AE': All components of the 
> background layer of 'Regular' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'AE': All components of the 
> background layer of 'Black' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'AE': All components of the 
> background layer of 'Italic' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'C': All components of the 
> background layer of 'Regular' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'C': All components of the 
> background layer of 'Black' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'C': All components of the 
> background layer of 'Black Italic' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'F': All components of the 
> background layer of 'Regular' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'F': All components of the 
> background layer of 'Black' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'G': All components of the 
> background layer of 'Regular' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'G': All components of the 
> background layer of 'Black' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'G': All components of the 
> background layer of 'Black Italic' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'G.1': All components of the 
> background layer of 'Regular' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'G.1': All components of the 
> background layer of 'Black' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'uni01F6': All components of the 
> background layer of 'Regular' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'uni01F6': All components of the 
> background layer of 'Black' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'Khook': All components of the 
> background layer of 'Regular' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'Khook': All components of the 
> background layer of 'Black' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'Khook': All components of the 
> background layer of 'Italic' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'Khook': All components of the 
> background layer of 'Black Italic' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'Rx': All components of the 
> background layer of 'Regular' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'Rx': All components of the 
> background layer of 'Italic' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'Thook': All components of the 
> background layer of 'Regular' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'Thook': All components of the 
> background layer of 'Black' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'ae': All components of the 
> background layer of 'Regular' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'ae': All components of the 
> background layer of 'Black Italic' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'b': All components of the 
> background layer of 'Regular' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'b': All components of the 
> background layer of 'Black' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'b': All components of the 
> background layer of 'Black Italic' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'bhook': All components of the 
> background layer of 'Regular' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'bhook': All components of the 
> background layer of 'Black' will be decomposed.
> WARNING:glyphsLib.builder.components:Glyph 'c': All components of the 
> backgr

Bug#978358: transmission-remote-gtk: FTBFS: error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.19 but the autoconf macros are from gettext version 0.20

[Lucas Nussbaum]

Source: transmission-remote-gtk
Version: 1.4.1-4
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>/po'
> sed -e '/^#/d' remove-potcdate.sin > t-remove-potcdate.sed
> mv t-remove-potcdate.sed remove-potcdate.sed
> package_gnu=""; \
> test -n "$package_gnu" || { \
>   if { if (LC_ALL=C find --version) 2>/dev/null | grep GNU >/dev/null; then \
>LC_ALL=C find -L .. -maxdepth 1 -type f \
>  -size -1000c -exec grep 'GNU 
> transmission-remote-gtk' \
>  /dev/null '{}' ';' 2>/dev/null; \
>else \
>LC_ALL=C grep 'GNU transmission-remote-gtk' ../* 2>/dev/null; \
>fi; \
>  } | grep -v 'libtool:' >/dev/null; then \
>  package_gnu=yes; \
>else \
>  package_gnu=no; \
>fi; \
> }; \
> if test "$package_gnu" = "yes"; then \
>   package_prefix='GNU '; \
> else \
>   package_prefix=''; \
> fi; \
> if test -n '' || test 
> 'https://github.com/transmission-remote-gtk/transmission-remote-gtk/issues' = 
> '@'PACKAGE_BUGREPORT'@'; then \
>   msgid_bugs_address=''; \
> else \
>   
> msgid_bugs_address='https://github.com/transmission-remote-gtk/transmission-remote-gtk/issues';
>  \
> fi; \
> case `/usr/bin/xgettext --version | sed 1q | sed -e 's,^[^0-9]*,,'` in \
>   '' | 0.[0-9] | 0.[0-9].* | 0.1[0-5] | 0.1[0-5].* | 0.16 | 0.16.[0-1]*) \
> /usr/bin/xgettext --default-domain=transmission-remote-gtk --directory=.. 
> \
>   --add-comments=TRANSLATORS: --from-code=UTF-8 --keyword=_ --keyword=N_ 
> --keyword=C_:1c,2 --keyword=NC_:1c,2 --keyword=g_dngettext:2,3 --add-comments 
>  \
>   --files-from=./POTFILES.in \
>   --copyright-holder='' \
>   --msgid-bugs-address="$msgid_bugs_address" \
> ;; \
>   *) \
> /usr/bin/xgettext --default-domain=transmission-remote-gtk --directory=.. 
> \
>   --add-comments=TRANSLATORS: --from-code=UTF-8 --keyword=_ --keyword=N_ 
> --keyword=C_:1c,2 --keyword=NC_:1c,2 --keyword=g_dngettext:2,3 --add-comments 
>  \
>   --files-from=./POTFILES.in \
>   --copyright-holder='' \
>   --package-name="${package_prefix}transmission-remote-gtk" \
>   --package-version='1.4.1' \
>   --msgid-bugs-address="$msgid_bugs_address" \
> ;; \
> esac
> /usr/bin/xgettext: warning: a fallback ITS rule file 
> '/usr/share/gettext-0.21/its/metainfo.its' is used; it may not be in sync 
> with the upstream
> test ! -f transmission-remote-gtk.po || { \
>   if test -f ./transmission-remote-gtk.pot-header; then \
> sed -e '1,/^#$/d' < transmission-remote-gtk.po > 
> transmission-remote-gtk.1po && \
> cat ./transmission-remote-gtk.pot-header transmission-remote-gtk.1po > 
> transmission-remote-gtk.po; \
> rm -f transmission-remote-gtk.1po; \
>   fi; \
>   if test -f ./transmission-remote-gtk.pot; then \
> sed -f remove-potcdate.sed < ./transmission-remote-gtk.pot > 
> transmission-remote-gtk.1po && \
> sed -f remove-potcdate.sed < transmission-remote-gtk.po > 
> transmission-remote-gtk.2po && \
> if cmp transmission-remote-gtk.1po transmission-remote-gtk.2po >/dev/null 
> 2>&1; then \
>   rm -f transmission-remote-gtk.1po transmission-remote-gtk.2po 
> transmission-remote-gtk.po; \
> else \
>   rm -f transmission-remote-gtk.1po transmission-remote-gtk.2po 
> ./transmission-remote-gtk.pot && \
>   mv transmission-remote-gtk.po ./transmission-remote-gtk.pot; \
> fi; \
>   else \
> mv transmission-remote-gtk.po ./transmission-remote-gtk.pot; \
>   fi; \
> }
> make[4]: Leaving directory '/<>/po'
> *** error: gettext infrastructure mismatch: using a Makefile.in.in from 
> gettext version 0.19 but the autoconf macros are from gettext version 0.20
> make[3]: *** [Makefile:265: stamp-po] Error 1

The full build log is available from:
   
http://qa-logs.debian.net/2020/12/26/transmission-remote-gtk_1.4.1-4_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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978360: python-whoosh: FTBFS: AttributeError: 'NullMatcherClass' object has no attribute '__name__'

[Lucas Nussbaum]

Source: python-whoosh
Version: 2.7.4+git6-g9134ad92-5
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 --buildsystem=pybuild
> dh_auto_build: warning: Compatibility levels before 10 are deprecated (level 
> 9 in use)
> I: pybuild base:232: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/externalsort.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/idsets.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/scoring.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/fields.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/__init__.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/index.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/highlight.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/columns.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/searching.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/compat.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/sorting.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/spelling.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/legacy.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/formats.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/multiproc.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/classify.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/collectors.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/writing.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/system.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> copying src/whoosh/reading.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh
> creating /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/analysis
> copying src/whoosh/analysis/analyzers.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/analysis
> copying src/whoosh/analysis/__init__.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/analysis
> copying src/whoosh/analysis/ngrams.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/analysis
> copying src/whoosh/analysis/tokenizers.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/analysis
> copying src/whoosh/analysis/intraword.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/analysis
> copying src/whoosh/analysis/acore.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/analysis
> copying src/whoosh/analysis/morph.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/analysis
> copying src/whoosh/analysis/filters.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/analysis
> creating /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/util
> copying src/whoosh/util/versions.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/util
> copying src/whoosh/util/cache.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/util
> copying src/whoosh/util/text.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/util
> copying src/whoosh/util/__init__.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/util
> copying src/whoosh/util/varints.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/util
> copying src/whoosh/util/loading.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/util
> copying src/whoosh/util/times.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/util
> copying src/whoosh/util/numlists.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/util
> copying src/whoosh/util/filelock.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/util
> copying src/whoosh/util/numeric.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/util
> copying src/whoosh/util/testing.py -> 
> /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/util
> creating /<>/.pybuild/cpython3_3.9_whoosh/build/whoosh/qparser
> copyin

Bug#978364: apertium-ukr: FTBFS: Error: Invalid dictionary (hint: the left side of an entry is empty)

[Lucas Nussbaum]

Source: apertium-ukr
Version: 0.1.0~r82563-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>'
> apertium-validate-dictionary apertium-ukr.ukr.dix
> /bin/mkdir -p .deps
> lt-comp lr apertium-ukr.post-ukr.dix ukr.autopgen.bin
> /usr/bin/cg-comp apertium-ukr.ukr.rlx ukr.rlx.bin
> touch .deps/.d
> apertium-validate-modes modes.xml
> main@standard 6 14
> apertium-validate-dictionary apertium-ukr.ukr.dix
> Sections: 1, Rules: 29, Sets: 67, Tags: 138
> 10 rules cannot be skipped by index.
> apertium-gen-modes modes.xml
> lt-comp lr apertium-ukr.ukr.dix ukr.automorf.bin apertium-ukr.ukr.acx
> lt-comp rl apertium-ukr.ukr.dix ukr.autogen.bin apertium-ukr.ukr.acx
> final@inconditional 34 301
> gci@standard 583 789
> main@standard 16515 38654
> lt-print ukr.autogen.bin | gzip -9 -c -n > ukr.autogen.att.gz
> Error: Invalid dictionary (hint: the left side of an entry is empty)
> make[1]: *** [Makefile:729: ukr.automorf.bin] Error 1

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/apertium-ukr_0.1.0~r82563-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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978363: node-debug-fabulous: FTBFS: tests failed

[Lucas Nussbaum]

Source: node-debug-fabulous
Version: 1.1.0-1
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>'
> mocha -R spec ./test/**/*test.js
> 
> 
>   lazy-eval
> enabled
>   ✓ handles functions
>   1) leak
>   ✓ normal
> disabled
>   2) handles functions
>   3) normal
> lazy-eval-test.js Total time: 8
> 
>   spawn
> namespaces are unique
>   ✓ 1 off
>   ✓ 2 off
>   ✓ grandchildren
>   ✓ grandchildren
>   ✓ great grandchildren
> 
> 
>   7 passing (14ms)
>   3 failing
> 
>   1) lazy-eval
>enabled
>  leak:
>  AssertionError: expected null to be truthy
>   at /<>/test/src/lazy-eval.test.js:27:40
>   at Socket.stream.write (/usr/share/nodejs/hook-std/index.js:26:32)
>   at Function.log (/usr/share/nodejs/debug/src/node.js:194:24)
>   at debug (/usr/share/nodejs/debug/src/common.js:111:10)
>   at wrapped (src/lazy-eval.js:13:17)
>   at leakTest (test/src/lazy-eval.test.js:44:9)
>   at Context. (test/src/lazy-eval.test.js:40:9)
>   at callFn (/usr/share/nodejs/mocha/lib/runnable.js:364:21)
>   at Test.Runnable.run (/usr/share/nodejs/mocha/lib/runnable.js:352:5)
>   at Runner.runTest (/usr/share/nodejs/mocha/lib/runner.js:677:10)
>   at /usr/share/nodejs/mocha/lib/runner.js:801:12
>   at next (/usr/share/nodejs/mocha/lib/runner.js:594:14)
>   at /usr/share/nodejs/mocha/lib/runner.js:604:7
>   at next (/usr/share/nodejs/mocha/lib/runner.js:486:14)
>   at Immediate._onImmediate (/usr/share/nodejs/mocha/lib/runner.js:572:5)
>   at processImmediate (internal/timers.js:461:21)
> 
>   2) lazy-eval
>disabled
>  handles functions:
>  TypeError: unhook is not a function
>   at Context. (test/src/lazy-eval.test.js:78:7)
>   at callFn (/usr/share/nodejs/mocha/lib/runnable.js:364:21)
>   at Test.Runnable.run (/usr/share/nodejs/mocha/lib/runnable.js:352:5)
>   at Runner.runTest (/usr/share/nodejs/mocha/lib/runner.js:677:10)
>   at /usr/share/nodejs/mocha/lib/runner.js:801:12
>   at next (/usr/share/nodejs/mocha/lib/runner.js:594:14)
>   at /usr/share/nodejs/mocha/lib/runner.js:604:7
>   at next (/usr/share/nodejs/mocha/lib/runner.js:486:14)
>   at Immediate._onImmediate (/usr/share/nodejs/mocha/lib/runner.js:572:5)
>   at processImmediate (internal/timers.js:461:21)
> 
>   3) lazy-eval
>disabled
>  normal:
>  TypeError: unhook is not a function
>   at Context. (test/src/lazy-eval.test.js:90:7)
>   at callFn (/usr/share/nodejs/mocha/lib/runnable.js:364:21)
>   at Test.Runnable.run (/usr/share/nodejs/mocha/lib/runnable.js:352:5)
>   at Runner.runTest (/usr/share/nodejs/mocha/lib/runner.js:677:10)
>   at /usr/share/nodejs/mocha/lib/runner.js:801:12
>   at next (/usr/share/nodejs/mocha/lib/runner.js:594:14)
>   at /usr/share/nodejs/mocha/lib/runner.js:604:7
>   at next (/usr/share/nodejs/mocha/lib/runner.js:486:14)
>   at Immediate._onImmediate (/usr/share/nodejs/mocha/lib/runner.js:572:5)
>   at processImmediate (internal/timers.js:461:21)
> 
> 
> 
> make[1]: *** [debian/rules:13: override_dh_auto_test] Error 3

The full build log is available from:
   http://qa-logs.debian.net/2020/12/26/node-debug-fabulous_1.1.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!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

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#978362: node-eslint-plugin-node: FTBFS: tests failed

[Lucas Nussbaum]

Source: node-eslint-plugin-node
Version: 11.1.0~ds-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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_PATH=debian/node_modules eslint --format tap lib tests/lib
> TAP version 13
> 1..106
> ok 1 - /<>/lib/configs/_commons.js
> ok 2 - /<>/lib/configs/recommended-module.js
> ok 3 - /<>/lib/configs/recommended-script.js
> ok 4 - /<>/lib/configs/recommended.js
> ok 5 - /<>/lib/index.js
> not ok 6 - /<>/lib/rules/callback-return.js
>   ---
>   message: >-
> The meta properties should be placed in a consistent order: [docs, 
> fixable,
> messages, schema, type].
>   severity: error
>   data:
> line: 10
> column: 9
> ruleId: '@mysticatea/eslint-plugin/meta-property-ordering'
>   messages:
> - message: >-
> The meta properties should be placed in a consistent order: [docs,
> fixable, messages, schema, type].
>   severity: error
>   data:
> line: 23
> column: 9
> ruleId: '@mysticatea/eslint-plugin/meta-property-ordering'
>   ...
> not ok 7 - /<>/lib/rules/exports-style.js
>   ---
>   message: >-
> The meta properties should be placed in a consistent order: [docs, 
> fixable,
> schema, type].
>   severity: error
>   data:
> line: 152
> column: 9
> ruleId: '@mysticatea/eslint-plugin/meta-property-ordering'
>   ...
> ok 8 - /<>/lib/rules/file-extension-in-import.js
> not ok 9 - /<>/lib/rules/global-require.js
>   ---
>   message: >-
> The meta properties should be placed in a consistent order: [docs, 
> fixable,
> messages, schema, type].
>   severity: error
>   data:
> line: 53
> column: 9
> ruleId: '@mysticatea/eslint-plugin/meta-property-ordering'
>   messages:
> - message: >-
> The meta properties should be placed in a consistent order: [docs,
> fixable, messages, schema, type].
>   severity: error
>   data:
> line: 63
> column: 9
> ruleId: '@mysticatea/eslint-plugin/meta-property-ordering'
>   ...
> not ok 10 - /<>/lib/rules/handle-callback-err.js
>   ---
>   message: >-
> The meta properties should be placed in a consistent order: [docs, 
> fixable,
> messages, schema, type].
>   severity: error
>   data:
> line: 10
> column: 9
> ruleId: '@mysticatea/eslint-plugin/meta-property-ordering'
>   messages:
> - message: >-
> The meta properties should be placed in a consistent order: [docs,
> fixable, messages, schema, type].
>   severity: error
>   data:
> line: 23
> column: 9
> ruleId: '@mysticatea/eslint-plugin/meta-property-ordering'
>   ...
> not ok 11 - /<>/lib/rules/no-callback-literal.js
>   ---
>   message: >-
> The meta properties should be placed in a consistent order: [docs, 
> fixable,
> schema, type].
>   severity: error
>   data:
> line: 18
> column: 9
> ruleId: '@mysticatea/eslint-plugin/meta-property-ordering'
>   ...
> not ok 12 - /<>/lib/rules/no-deprecated-api.js
>   ---
>   message: >-
> The meta properties should be placed in a consistent order: [docs, 
> fixable,
> schema, type].
>   severity: error
>   data:
> line: 692
> column: 9
> ruleId: '@mysticatea/eslint-plugin/meta-property-ordering'
>   ...
> ok 13 - /<>/lib/rules/no-exports-assign.js
> not ok 14 - /<>/lib/rules/no-extraneous-import.js
>   ---
>   message: >-
> The meta properties should be placed in a consistent order: [docs, 
> fixable,
> schema, type].
>   severity: error
>   data:
> line: 25
> column: 9
> ruleId: '@mysticatea/eslint-plugin/meta-property-ordering'
>   ...
> not ok 15 - /<>/lib/rules/no-extraneous-require.js
>   ---
>   message: >-
> The meta properties should be placed in a consistent order: [docs, 
> fixable,
> schema, type].
>   severity: error
>   data:
> line: 25
> column: 9
> ruleId: '@mysticatea/eslint-plugin/meta-property-ordering'
>   ...
> not ok 16 - /<>/lib/rules/no-hide-core-modules.js
>   ---
>   message: >-
> The meta properties should be placed in a consistent order: [deprecated, 
> docs,
> fixable, schema, type].
>   severity: error
>   data:
> line: 62
> column: 9
> ruleId: '@mysti

Bug#978361: hg-git: FTBFS: tests failed

[Lucas Nussbaum]

Source: hg-git
Version: 0.9.0-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 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 '/<>'
> cd tests && python3 run-tests.py --with-hg=`which hg` --blacklist 
> /<>/debian/hg-git.test_blacklist
> running 41 tests using 4 parallel processes 
> sss
> --- /<>/tests/test-file-removal.t
> +++ /<>/tests/test-file-removal.t.err
> @@ -2,6 +2,16 @@
>$ . "$TESTDIR/testutil"
>  
>$ git init gitrepo
> +  hint: Using 'master' as the name for the initial branch. This default 
> branch name
> +  hint: is subject to change. To configure the initial branch name to use in 
> all
> +  hint: of your new repositories, which will suppress this warning, call:
> +  hint: 
> +  hint:  git config --global init.defaultBranch 
> +  hint: 
> +  hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> +  hint: 'development'. The just-created branch can be renamed via this 
> command:
> +  hint: 
> +  hint:  git branch -m 
>Initialized empty Git repository in $TESTTMP/gitrepo/.git/
>$ cd gitrepo
>$ echo alpha > alpha
> @@ -96,6 +106,16 @@
>  
>$ cd ..
>$ git init --bare gitrepo2
> +  hint: Using 'master' as the name for the initial branch. This default 
> branch name
> +  hint: is subject to change. To configure the initial branch name to use in 
> all
> +  hint: of your new repositories, which will suppress this warning, call:
> +  hint: 
> +  hint:  git config --global init.defaultBranch 
> +  hint: 
> +  hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> +  hint: 'development'. The just-created branch can be renamed via this 
> command:
> +  hint: 
> +  hint:  git branch -m 
>Initialized empty Git repository in $TESTTMP/gitrepo2/
>  
>$ hg clone gitrepo hgrepo | grep -v '^updating'
> 
> ERROR: test-file-removal.t output changed
> !..
> --- /<>/tests/test-git-submodules.t
> +++ /<>/tests/test-git-submodules.t.err
> @@ -2,6 +2,16 @@
>$ . "$TESTDIR/testutil"
>  
>$ git init gitrepo1
> +  hint: Using 'master' as the name for the initial branch. This default 
> branch name
> +  hint: is subject to change. To configure the initial branch name to use in 
> all
> +  hint: of your new repositories, which will suppress this warning, call:
> +  hint: 
> +  hint:  git config --global init.defaultBranch 
> +  hint: 
> +  hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> +  hint: 'development'. The just-created branch can be renamed via this 
> command:
> +  hint: 
> +  hint:  git branch -m 
>Initialized empty Git repository in $TESTTMP/gitrepo1/.git/
>$ cd gitrepo1
>$ echo alpha > alpha
> @@ -10,6 +20,16 @@
>$ cd ..
>  
>$ git init gitsubrepo
> +  hint: Using 'master' as the name for the initial branch. This default 
> branch name
> +  hint: is subject to change. To configure the initial branch name to use in 
> all
> +  hint: of your new repositories, which will suppress this warning, call:
> +  hint: 
> +  hint:  git config --global init.defaultBranch 
> +  hint: 
> +  hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> +  hint: 'development'. The just-created branch can be renamed via this 
> command:
> +  hint: 
> +  hint:  git branch -m 
>Initialized empty Git repository in $TESTTMP/gitsubrepo/.git/
>$ cd gitsubrepo
>$ echo beta > beta
> 
> ERROR: test-git-submodules.t output changed
> !
> --- /<>/tests/test-hg-author.t
> +++ /<>/tests/test-hg-author.t.err
> @@ -2,6 +2,16 @@
>$ . "$TESTDIR/testutil"
>  
>$ git init gitrepo
> +  hint: Using 'master' as the name for the initial branch. This default 
> branch name
> +  hint: is subject to change. To configure the initial branch name to use in 
> all
> +  hint: of your new repositories, which will suppress this warning, call:
> +  hint: 
> +  hint:  git config --global init.defaultBranch 
> +  hint: 
> +  hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> +  hint: 'development'. The just-created branch can be renamed via this 
> command:
> +  hint: 
> +  hint:  git branch -m 
>Initialized empty Git repository in $TESTTMP/gitrepo/.git/
>$ cd gitrepo
>$ echo alpha > alpha
> 
> ERROR: test-hg-author.t output changed
> !
> --- /<>/tests/test-octopus.t
> +++ /<>/tests/test-octopus.t.