date:20210208

Control: reassign -1 dahdi-dkms 1:2.11.1.0.20170917~dfsg-7

Installing dahdi-dkms seems to break building other dkms kernel modules.


Andreas

Bug#969072: dahdi-tools FTBFS on armel/mipsel/hppa/powerpc: pre-grohtml: fatal error: cannot create temporary file: File exists

2021-02-08 Thread Ivo De Decker

Control: tags -1 patch pending

Hi Colin,

On 2/8/21 11:56 PM, Colin Watson wrote:

On Mon, Feb 08, 2021 at 07:17:57PM +0100, Ivo De Decker wrote:

On Sat, Nov 21, 2020 at 07:06:02PM +0200, Tzafrir Cohen wrote:

On abel in a armel chroot the issue is reproduced by running:
man -Thtml
even on an empty man page.

Right now you can try:

$ schroot -r -c session:tzafrir-dahdi-tools -- man -Thtml ~tzafrir/test.8
>/dev/null
pre-grohtml: fatal error: cannot create temporary file: File exists
man: command exited with status 1: /usr/lib/man-db/zsoelim |
/usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e
UTF-8 | tbl | groff -mandoc -Thtml

Not reproduced in a armhf chroot there or in a qemu armel chroot on my
laptop.

When running this with MAN_DISABLE_SECCOMP=1, the issue goes away, so it's
caused by the seccomp filter man is setting up when running groff. I guess
some system call must be (slightly) different on some of the architectures,
and it's not allowed by the filter.

So it seems this is a bug in man-db.

Ah yes, sorry for missing this. Running strace on abel, it looks like
clock_gettime64 is the offending syscall, which means that
https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=7315a9475d8fa37af49e9e7ed11e1534f23ef70b
should fix this; I've tested that on abel and it seems to do the job.
The upstream changes since 2.9.3 are not otherwise especially intrusive
(mostly new translations), so I think I'll deal with this by doing a new
upstream release and packaging that. I'm working on that now.

Thanks for that!

I was wondering if there is a way to make it clear that the seccomp
filter has actually blocked something, perhaps by showing a warning.
That would make it easier to debug something like this in the future.
Maybe that should be a separate (wishlist) bug.

Cheers,

Ivo

Bug#982340: maven-invoker-plugin: FTBFS with OpenJDK 17: module java.base does not "opens java.lang" to unnamed module

2021-02-08 Thread Emmanuel Bourg

Source: maven-invoker-plugin
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17

maven-invoker-plugin fails to build with OpenJDK 17, the tests fail with the 
following error:


  [INFO] ---
  [INFO]  T E S T S
  [INFO] ---
  [INFO] Running org.apache.maven.plugins.invoker.InterpolationTest
  SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
  SLF4J: Defaulting to no-operation (NOP) logger implementation
  SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.
  [ERROR] Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.959 
s <<< FAILURE! - in org.apache.maven.plugins.invoker.InterpolationTest
  [ERROR] 
testPomInterpolation(org.apache.maven.plugins.invoker.InterpolationTest)  Time 
elapsed: 0.749 s  <<< ERROR!
  com.google.common.util.concurrent.UncheckedExecutionException: 
java.lang.IllegalStateException: Unable to load cache item
  Caused by: java.lang.IllegalStateException: Unable to load cache item
  Caused by: java.lang.ExceptionInInitializerError
  Caused by: com.google.inject.internal.cglib.core.$CodeGenerationException: 
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final 
java.lang.Class 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
 throws java.lang.ClassFormatError accessible: module java.base does not "opens 
java.lang" to unnamed module @1d18b91a
  Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
protected final java.lang.Class 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
 throws java.lang.ClassFormatError accessible: module java.base does not "opens 
java.lang" to unnamed module @1d18b91a

Bug#982339: modello-maven-plugin: FTBFS with OpenJDK 17: module java.base does not "opens java.lang" to unnamed module

2021-02-08 Thread Emmanuel Bourg

Source: modello-maven-plugin
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17

modello-maven-plugin fails to build with OpenJDK 17, the tests fail with the 
following error:


  [INFO] ---
  [INFO]  T E S T S
  [INFO] ---
  [INFO] Running org.codehaus.modello.maven.ModelloJavaMojoTest
  [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.35 
s <<< FAILURE! - in org.codehaus.modello.maven.ModelloJavaMojoTest
  [ERROR] testModelloJavaMojo(org.codehaus.modello.maven.ModelloJavaMojoTest)  
Time elapsed: 0.33 s  <<< ERROR!
  com.google.common.util.concurrent.UncheckedExecutionException: 
java.lang.IllegalStateException: Unable to load cache item
  at 
org.codehaus.modello.maven.ModelloJavaMojoTest.testModelloJavaMojo(ModelloJavaMojoTest.java:42)
  Caused by: java.lang.IllegalStateException: Unable to load cache item
  at 
org.codehaus.modello.maven.ModelloJavaMojoTest.testModelloJavaMojo(ModelloJavaMojoTest.java:42)
  Caused by: java.lang.ExceptionInInitializerError
  at 
org.codehaus.modello.maven.ModelloJavaMojoTest.testModelloJavaMojo(ModelloJavaMojoTest.java:42)
  Caused by: com.google.inject.internal.cglib.core.$CodeGenerationException: 
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final 
java.lang.Class 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
 throws java.lang.ClassFormatError accessible: module java.base does not "opens 
java.lang" to unnamed module @1d18b91a
  at 
org.codehaus.modello.maven.ModelloJavaMojoTest.testModelloJavaMojo(ModelloJavaMojoTest.java:42)
  Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
protected final java.lang.Class 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
 throws java.lang.ClassFormatError accessible: module java.base does not "opens 
java.lang" to unnamed module @1d18b91a
  at 
org.codehaus.modello.maven.ModelloJavaMojoTest.testModelloJavaMojo(ModelloJavaMojoTest.java:42)
  
  [INFO] Running org.codehaus.modello.maven.ModelloConvertersMojoTest
  [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.002 
s <<< FAILURE! - in org.codehaus.modello.maven.ModelloConvertersMojoTest
  [ERROR] 
testModelloConvertersMojo(org.codehaus.modello.maven.ModelloConvertersMojoTest) 
 Time elapsed: 0.001 s  <<< ERROR!
  com.google.common.util.concurrent.UncheckedExecutionException: 
java.lang.IllegalStateException: Unable to load cache item
  at 
org.codehaus.modello.maven.ModelloConvertersMojoTest.testModelloConvertersMojo(ModelloConvertersMojoTest.java:42)
  Caused by: java.lang.IllegalStateException: Unable to load cache item
  at 
org.codehaus.modello.maven.ModelloConvertersMojoTest.testModelloConvertersMojo(ModelloConvertersMojoTest.java:42)
  Caused by: java.lang.ExceptionInInitializerError
  Caused by: com.google.inject.internal.cglib.core.$CodeGenerationException: 
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final 
java.lang.Class 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
 throws java.lang.ClassFormatError accessible: module java.base does not "opens 
java.lang" to unnamed module @1d18b91a
  Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
protected final java.lang.Class 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
 throws java.lang.ClassFormatError accessible: module java.base does not "opens 
java.lang" to unnamed module @1d18b91a

Bug#982337: rpki-trust-anchors: [INTL:pt] Portuguese translation - debconf messages

Package: rpki-trust-anchors
Version: 20200621-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for rpki-trust-anchors's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


rpki-trust-anchors_20200621-1_pt.po.gz
Description: application/gzip

Bug#982336: maven-source-plugin: FTBFS with OpenJDK 17: module java.base does not "opens java.lang" to unnamed module

2021-02-08 Thread Emmanuel Bourg

Source: maven-source-plugin
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17

maven-source-plugin fails to build with OpenJDK 17, the tests fail with the 
following error:


  [INFO] ---
  [INFO]  T E S T S
  [INFO] ---
  [INFO] Running org.apache.maven.plugins.source.SourceJarMojoTest
  SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
  SLF4J: Defaulting to no-operation (NOP) logger implementation
  SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.
  [ERROR] Tests run: 6, Failures: 0, Errors: 6, Skipped: 0, Time elapsed: 0.935 
s <<< FAILURE! - in org.apache.maven.plugins.source.SourceJarMojoTest
  [ERROR] testExcludes(org.apache.maven.plugins.source.SourceJarMojoTest)  Time 
elapsed: 0.635 s  <<< ERROR!
  com.google.common.util.concurrent.UncheckedExecutionException: 
java.lang.IllegalStateException: Unable to load cache item
  Caused by: java.lang.IllegalStateException: Unable to load cache item
  Caused by: java.lang.ExceptionInInitializerError
  Caused by: com.google.inject.internal.cglib.core.$CodeGenerationException: 
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final 
java.lang.Class 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
 throws java.lang.ClassFormatError accessible: module java.base does not "opens 
java.lang" to unnamed module @2ee4f460
  Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
protected final java.lang.Class 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
 throws java.lang.ClassFormatError accessible: module java.base does not "opens 
java.lang" to unnamed module @2ee4f460
  
  [ERROR] testNoSources(org.apache.maven.plugins.source.SourceJarMojoTest)  
Time elapsed: 0.058 s  <<< ERROR!
  com.google.common.util.concurrent.UncheckedExecutionException: 
java.lang.IllegalStateException: Unable to load cache item
  Caused by: java.lang.IllegalStateException: Unable to load cache item
  Caused by: java.lang.ExceptionInInitializerError
  Caused by: com.google.inject.internal.cglib.core.$CodeGenerationException: 
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final 
java.lang.Class 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
 throws java.lang.ClassFormatError accessible: module java.base does not "opens 
java.lang" to unnamed module @2ee4f460
  Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
protected final java.lang.Class 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
 throws java.lang.ClassFormatError accessible: module java.base does not "opens 
java.lang" to unnamed module @2ee4f460
  
  [ERROR] 
testIncludeMavenDescriptorWhenExplicitlyConfigured(org.apache.maven.plugins.source.SourceJarMojoTest)
  Time elapsed: 0.062 s  <<< ERROR!
  com.google.common.util.concurrent.UncheckedExecutionException: 
java.lang.IllegalStateException: Unable to load cache item
  Caused by: java.lang.IllegalStateException: Unable to load cache item
  Caused by: java.lang.ExceptionInInitializerError
  Caused by: com.google.inject.internal.cglib.core.$CodeGenerationException: 
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final 
java.lang.Class 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
 throws java.lang.ClassFormatError accessible: module java.base does not "opens 
java.lang" to unnamed module @2ee4f460
  Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
protected final java.lang.Class 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
 throws java.lang.ClassFormatError accessible: module java.base does not "opens 
java.lang" to unnamed module @2ee4f460
  
  [ERROR] testIncludePom(org.apache.maven.plugins.source.SourceJarMojoTest)  
Time elapsed: 0.05 s  <<< ERROR!
  com.google.common.util.concurrent.UncheckedExecutionException: 
java.lang.IllegalStateException: Unable to load cache item
  Caused by: java.lang.IllegalStateException: Unable to load cache item
  Caused by: java.lang.ExceptionInInitializerError
  Caused by: com.google.inject.internal.cglib.core.$CodeGenerationException: 
java.lang.reflect.InaccessibleObjectException-->Unable to make protected final 
java.lang.Class 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
 throws java.lang.ClassFormatError accessible: module java.base does not "opens 
java.lang" to unnamed module @2ee4f460
  Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
protected final java.lang.Class 
java.lang.ClassLoader.defineClass(java.l

Bug#982335: RFP: gamehub -- unified library for games from multiple sources

2021-02-08 Thread Phil Morrell

Package: wnpp
Severity: wishlist

* Package name: gamehub
  Version : 0.16.0
  Upstream Author : Anatoliy Kashkin 
* URL : https://tkashkin.tk/projects/gamehub/
* License : GPL-3.0
  Programming Lang: Vala
  Description : unified library for games from multiple sources

GameHub is a unified library for all your games. It allows you to store
your games from different platforms into one program to make it easier
for you to manage your games.  With GameHub, you can:

* store your games in one place
* login to multiple platforms
* install games from the supported sources
* download game installers, DLCs and bonus content
* automatically find artwork for games on SteamGridDB
* setup emulators and automatically import emulated games
* Overlays — multiple directories applied on top of each other to manage DLCs 
and mods
* Tweaks — environment variable and command line overrides
* multiple compatibility layers: Wine, Proton, DOSBox, RetroArch, ScummVM, 
WineWrap
* multiple game platforms: Steam, GOG, Humble Bundle, itch.io

---

Somewhat similar to lutris, but through its use of https://www.igdb.com/
is able to merge different sources into a single entry. It allows the
management of custom tags for filters making it more of a library
manager rather like calibre rather than just a package manager.

Games Team managed, just like all the other helper tools available.


signature.asc
Description: PGP signature

Bug#982334: iptables-netflow-dkms: fails to build module for Linux 5.10

Package: iptables-netflow-dkms
Version: 2.5.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to build a
kernel module for Linux 5.10:

DKMS make.log for ipt-netflow-2.5.1 for kernel 5.10.0-3-amd64 (x86_64)
Tue Feb  9 00:17:25 CET 2021
./gen_compat_def > compat_def.h
Test symbol xt_family linux/netfilter_ipv4/ip_tables.h
Error: unexpected error from compiler
make -s -C /lib/modules/5.10.0-3-amd64/build 
M=/var/lib/dkms/ipt-netflow/2.5.1/build/cc-test-build modules
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.

  ERROR: Kernel configuration is invalid.
 include/generated/autoconf.h or include/config/auto.conf are missing.
 Run 'make oldconfig && make prepare' on kernel src to fix it.

make[2]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:717: 
include/config/auto.conf] Error 1
make[1]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:185: __sub-make] 
Error 2

make: *** [Makefile:28: compat_def.h] Error 3


Andreas

Bug#982333: libcifpp: [INTL:pt] Portuguese translation - debconf messages

Package: libcifpp
Version: 1.0.1-3
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for libcifpp's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


libcifpp_1.0.1-3_pt.po.gz
Description: application/gzip

Bug#979379: [pkg-gnupg-maint] Bug#979379: ITS: src:gnupg2

2021-02-08 Thread Daniel Kahn Gillmor

Hi Christoph and gniibe--

Many thanks to you both for preparing and proposing fixes for the GnuPG
packaging in debian.

I've done some review and cleanup and just uploaded 2.2.27-1 to unstable
based on your work.  In particular, i pulled from gniibe's git
repository (which included Christoph's dependency tightening patches),
and i cleaned up a bunch of fairly inconsequential lintian warnings.

We're still shipping a lot of binaries in /usr/lib/gnupg and home-grown
manpages, but without convincing upstream to adopt the manpages, or to
ship the binaries someplace else, i don't know how the debian packaging
is going to do that differently.

On Fri 2021-01-22 10:17:45 +0100, Christoph Biedl wrote:

> So consider this a request to join the team. I'm also in the IRC channel
> but it seems you are not (or you have changed the nick).

I'm back on the #debian-gnupg IRC channel, sorry for my absence from
there earlier.

I welcome and encourage more work on the packages maintained by this
team, and though i don't think we have any formal membership process, i
can say that you have more contributions to the packaging than many
people who have been considered "team members" over the last few years.
So please do keep contributing!

Regards,

--dkg

signature.asc
Description: PGP signature

Bug#982332: dahdi-dkms: fails to build module for Linux 5.10

Package: dahdi-dkms
Version: 1:2.11.1.0.20170917~dfsg-7
Severity: serious
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to build a
kernel module for Linux 5.10:

DKMS make.log for dahdi-DEB_VERSION for kernel 5.10.0-3-amd64 (x86_64)
Tue Feb  9 00:11:41 CET 2021
make -C /lib/modules/5.10.0-3-amd64/build 
SUBDIRS=/var/lib/dkms/dahdi/DEB_VERSION/build/drivers/dahdi 
DAHDI_INCLUDE=/var/lib/dkms/dahdi/DEB_VERSION/build/include 
DAHDI_MODULES_EXTRA="dahdi_dummy.o dahdi_echocan_oslec.o " HOTPLUG_FIRMWARE=yes 
modules DAHDI_BUILD_ALL=m
make[1]: Entering directory '/usr/src/linux-headers-5.10.0-3-amd64'
  SYNCinclude/config/auto.conf.cmd
sh: 0: cannot open /usr/src/linux-headers-5.10.0-3-common/scripts/mkmakefile: 
No such file
make[3]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:548: 
outputmakefile] Error 2
/usr/src/linux-headers-5.10.0-3-common/Makefile:687: 
include/config/auto.conf.cmd: No such file or directory
make[2]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:709: 
include/config/auto.conf.cmd] Error 2
make[2]: *** [include/config/auto.conf.cmd] Deleting file 
'include/generated/autoconf.h'
make[1]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:185: __sub-make] 
Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.10.0-3-amd64'
make: *** [Makefile:74: modules] Error 2
make -C /lib/modules/5.10.0-3-amd64/build 
SUBDIRS=/var/lib/dkms/dahdi/DEB_VERSION/build/drivers/dahdi 
DAHDI_INCLUDE=/var/lib/dkms/dahdi/DEB_VERSION/build/include 
DAHDI_MODULES_EXTRA=" " HOTPLUG_FIRMWARE=yes modules DAHDI_BUILD_ALL=m
make[1]: Entering directory '/usr/src/linux-headers-5.10.0-3-amd64'
  SYNCinclude/config/auto.conf.cmd
sh: 0: cannot open /usr/src/linux-headers-5.10.0-3-common/scripts/mkmakefile: 
No such file
make[3]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:548: 
outputmakefile] Error 2
/usr/src/linux-headers-5.10.0-3-common/Makefile:687: 
include/config/auto.conf.cmd: No such file or directory
make[2]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:709: 
include/config/auto.conf.cmd] Error 2
make[1]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:185: __sub-make] 
Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.10.0-3-amd64'
make: *** [Makefile:74: modules] Error 2
make -C drivers/dahdi/firmware firmware-loaders
make[1]: Entering directory 
'/var/lib/dkms/dahdi/DEB_VERSION/build/drivers/dahdi/firmware'
Attempting to download dahdi-fwload-vpmadt032-1.25.0.tar.gz
--2021-02-09 00:11:43--  
http://downloads.digium.com/pub/telephony/firmware/releases/dahdi-fwload-vpmadt032-1.25.0.tar.gz
Connecting to 127.0.0.1:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: 149360 (146K) [application/x-gzip]
Saving to: 'dahdi-fwload-vpmadt032-1.25.0.tar.gz'

 0K .. .. .. .. .. 34%  204K 0s
50K .. .. .. .. .. 68%  398K 0s
   100K .. .. .. .. . 100%  382K=0.5s

2021-02-09 00:11:44 (297 KB/s) - 'dahdi-fwload-vpmadt032-1.25.0.tar.gz' saved 
[149360/149360]

make[1]: Leaving directory 
'/var/lib/dkms/dahdi/DEB_VERSION/build/drivers/dahdi/firmware'
make -C /lib/modules/5.10.0-3-amd64/build 
SUBDIRS=/var/lib/dkms/dahdi/DEB_VERSION/build/drivers/dahdi 
DAHDI_INCLUDE=/var/lib/dkms/dahdi/DEB_VERSION/build/include 
DAHDI_MODULES_EXTRA=" " HOTPLUG_FIRMWARE=yes modules DAHDI_BUILD_ALL=m
make[1]: Entering directory '/usr/src/linux-headers-5.10.0-3-amd64'
  SYNCinclude/config/auto.conf.cmd
sh: 0: cannot open /usr/src/linux-headers-5.10.0-3-common/scripts/mkmakefile: 
No such file
make[3]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:548: 
outputmakefile] Error 2
/usr/src/linux-headers-5.10.0-3-common/Makefile:687: 
include/config/auto.conf.cmd: No such file or directory
make[2]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:709: 
include/config/auto.conf.cmd] Error 2
make[1]: *** [/usr/src/linux-headers-5.10.0-3-common/Makefile:185: __sub-make] 
Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.10.0-3-amd64'
make: *** [Makefile:74: modules] Error 2


Andreas

Bug#982331: prometheus-blackbox-exporter: [INTL:pt] Portuguese translation - debconf messages

Package: prometheus-blackbox-exporter
Version: 0.18.0+ds-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for prometheus-blackbox-exporter's debconf 
messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


prometheus-blackbox-exporter_0.18.0+ds-2_pt.po.gz
Description: application/gzip

Bug#969072: dahdi-tools FTBFS on armel/mipsel/hppa/powerpc: pre-grohtml: fatal error: cannot create temporary file: File exists

2021-02-08 Thread Colin Watson

On Mon, Feb 08, 2021 at 07:17:57PM +0100, Ivo De Decker wrote:
> On Sat, Nov 21, 2020 at 07:06:02PM +0200, Tzafrir Cohen wrote:
> >On abel in a armel chroot the issue is reproduced by running:
> >  man -Thtml
> >even on an empty man page.
> > 
> >Right now you can try:
> > 
> >$ schroot -r -c session:tzafrir-dahdi-tools -- man -Thtml ~tzafrir/test.8
> >>/dev/null
> >pre-grohtml: fatal error: cannot create temporary file: File exists
> >man: command exited with status 1: /usr/lib/man-db/zsoelim |
> >/usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e
> >UTF-8 | tbl | groff -mandoc -Thtml
> > 
> >Not reproduced in a armhf chroot there or in a qemu armel chroot on my
> >laptop.
> 
> When running this with MAN_DISABLE_SECCOMP=1, the issue goes away, so it's
> caused by the seccomp filter man is setting up when running groff. I guess
> some system call must be (slightly) different on some of the architectures,
> and it's not allowed by the filter.
> 
> So it seems this is a bug in man-db.

Ah yes, sorry for missing this.  Running strace on abel, it looks like
clock_gettime64 is the offending syscall, which means that
https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=7315a9475d8fa37af49e9e7ed11e1534f23ef70b
should fix this; I've tested that on abel and it seems to do the job.
The upstream changes since 2.9.3 are not otherwise especially intrusive
(mostly new translations), so I think I'll deal with this by doing a new
upstream release and packaging that.  I'm working on that now.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#950761: RFS: ipmitool/1.8.18-11 [RC] -- utility for IPMI control with kernel driver or LAN interface (daemon)

2021-02-08 Thread Thomas Goirand

Hi Jorg,

I've applied the upstream patches to the current codebase of Ipmitool in
Unstable. Please find the attched debdiff.

The only place where I had to rework things a little bit was
CVE-2020-5208_4-channel-Fix-buffer-overflow.patch where the constant
MAX_CIPHER_SUITE_DATA_LEN was not present in
include/ipmitool/ipmi_channel.h, so I took it from the top of the Git
upstream.

Where is the other place that you spotted that wouldn't work with the
current codebase? I didn't take the necessary time to even read the
other patches yet. (which makes this debdiff only half of the work).

Your thoughts?
Cheers,

Thomas Goirand (zigo)
diff -Nru ipmitool-1.8.18/debian/changelog ipmitool-1.8.18/debian/changelog
--- ipmitool-1.8.18/debian/changelog2020-09-14 14:35:04.0 +0200
+++ ipmitool-1.8.18/debian/changelog2021-02-08 17:57:56.0 +0100
@@ -1,3 +1,18 @@
+ipmitool (1.8.18-10.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * CVE-2020-5208: buffer overflows and potentially to remote code execution.
+Applied upstream patches:
+- CVE-2020-5208_1_Fix_buffer_overflow_vulnerabilities.patch
+- CVE-2020-5208_2-fru-Fix-buffer-overflow-in-ipmi_spd_print_fru.patch
+- 
CVE-2020-5208_3-session-Fix-buffer-overflow-in-ipmi_get_session_info.patch
+- CVE-2020-5208_4-channel-Fix-buffer-overflow.patch
+- CVE-2020-5208_5_lanp-Fix-buffer-overflows-in-get_lan_param_select.patch
+- CVE-2020-5208_6-fru-sdr-Fix-id_string-buffer-overflows.patch
+(Closes: #950761).
+
+ -- Thomas Goirand   Mon, 08 Feb 2021 17:57:56 +0100
+
 ipmitool (1.8.18-10) unstable; urgency=medium
 
   * Add "Restrictions: superficial" to debian/tests/control (Closes: #969834).
diff -Nru 
ipmitool-1.8.18/debian/patches/CVE-2020-5208_1_Fix_buffer_overflow_vulnerabilities.patch
 
ipmitool-1.8.18/debian/patches/CVE-2020-5208_1_Fix_buffer_overflow_vulnerabilities.patch
--- 
ipmitool-1.8.18/debian/patches/CVE-2020-5208_1_Fix_buffer_overflow_vulnerabilities.patch
1970-01-01 01:00:00.0 +0100
+++ 
ipmitool-1.8.18/debian/patches/CVE-2020-5208_1_Fix_buffer_overflow_vulnerabilities.patch
2021-02-08 17:57:56.0 +0100
@@ -0,0 +1,120 @@
+Description: fru: Fix buffer overflow vulnerabilities
+ Partial fix for CVE-2020-5208, see
+ https://github.com/ipmitool/ipmitool/security/advisories/GHSA-g659-9qxw-p7cp
+ .
+ The `read_fru_area_section` function only performs size validation of
+ requested read size, and falsely assumes that the IPMI message will not
+ respond with more than the requested amount of data; it uses the
+ unvalidated response size to copy into `frubuf`. If the response is
+ larger than the request, this can result in overflowing the buffer.
+ .
+ The same issue affects the `read_fru_area` function.
+Author: Chrostoper Ertl 
+Date: Thu, 28 Nov 2019 16:33:59 +
+
+Index: ipmitool-1.8.18/lib/ipmi_fru.c
+===
+--- ipmitool-1.8.18.orig/lib/ipmi_fru.c
 ipmitool-1.8.18/lib/ipmi_fru.c
+@@ -615,7 +615,10 @@ int
+ read_fru_area(struct ipmi_intf * intf, struct fru_info *fru, uint8_t id,
+   uint32_t offset, uint32_t length, uint8_t *frubuf)
+ {
+-  uint32_t off = offset, tmp, finish;
++  uint32_t off = offset;
++  uint32_t tmp;
++  uint32_t finish;
++  uint32_t size_left_in_buffer;
+   struct ipmi_rs * rsp;
+   struct ipmi_rq req;
+   uint8_t msg_data[4];
+@@ -628,10 +631,12 @@ read_fru_area(struct ipmi_intf * intf, s
+ 
+   finish = offset + length;
+   if (finish > fru->size) {
++  memset(frubuf + fru->size, 0, length - fru->size);
+   finish = fru->size;
+   lprintf(LOG_NOTICE, "Read FRU Area length %d too large, "
+   "Adjusting to %d",
+   offset + length, finish - offset);
++  length = finish - offset;
+   }
+ 
+   memset(&req, 0, sizeof(req));
+@@ -667,6 +672,7 @@ read_fru_area(struct ipmi_intf * intf, s
+   }
+   }
+ 
++  size_left_in_buffer = length;
+   do {
+   tmp = fru->access ? off >> 1 : off;
+   msg_data[0] = id;
+@@ -707,9 +713,18 @@ read_fru_area(struct ipmi_intf * intf, s
+   }
+ 
+   tmp = fru->access ? rsp->data[0] << 1 : rsp->data[0];
++  if(rsp->data_len < 1
++ || tmp > rsp->data_len - 1
++ || tmp > size_left_in_buffer)
++  {
++  printf(" Not enough buffer size");
++  return -1;
++  }
++
+   memcpy(frubuf, rsp->data + 1, tmp);
+   off += tmp;
+   frubuf += tmp;
++  size_left_in_buffer -= tmp;
+   /* sometimes the size returned in the Info command
+   * is too large.  return 0 so higher level function
+   * still attempts to parse what was returned */
+@@ -742,7 +757,9 @@ read_fru_area_sectio

Bug#982330: x2gothinclient: [INTL:pt] Portuguese translation - debconf messages

Package: x2gothinclient
Version: 1.5.0.1-6
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for x2gothinclient's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


x2gothinclient_1.5.0.1-6_pt.po.gz
Description: application/gzip

Bug#982323: [pcp] Bug#982323: pcp-export-pcp2{graphite,influxdb}: missing Breaks+Replaces: pcp (<< 5.2.5)

2021-02-08 Thread Nathan Scott

Hi Andreas,

On Tue, Feb 9, 2021 at 8:55 AM Andreas Beckmann  wrote:
> [...]
> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
> [...]

Thanks for the report.  It's strange - I performed a similar
upgrade from 5.2.3 but didn't run into this.  I'll fix it up via
your suggested change and upload a -2 build soon.

cheers.

--
Nathan

Bug#850424: nbd-server: IPv4 clients not authorized

2021-02-08 Thread Graham Cobb

Package: nbd-server
Version: 1:3.20-1
Followup-For: Bug #850424

By the way, the auth file accepts the "mixed" format for v6-mapped v4 addresses.
So, for example, 192.168.1.23 can be entered as :::192.168.1.23 instead of 
having to
work out the hex bytes.

But don't forget that if you specify a mask length (e.g. /20) you need to add 
96 to it
when entering it in the v6-mapped format.

I have a patch to fix the problem and allow IPv4 addresses to 'just work' which 
I plan
to submit to upstream.

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

Kernel: Linux 5.9.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_IE.utf8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nbd-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.31-4
ii  libglib2.0-0   2.62.3-1
ii  libgnutls303.7.0-5
ii  ucf3.0043

nbd-server recommends no packages.

nbd-server suggests no packages.

-- debconf-show failed

Bug#978673: RFS: paho.mqtt.cpp/1.2.0-1 [ITP] -- Eclipse Paho MQTT C++ Client Library - development files

2021-02-08 Thread Matthias Klein

Dear mentors,

I am looking for a sponsor for my package "paho.mqtt.cpp":

 * Package name: paho.mqtt.cpp
   Version : 1.2.0-1
   Upstream Author : Eclipse Paho Development Team 
 * URL : https://github.com/eclipse/paho.mqtt.cpp/
 * License : EPL-2.0
 * Vcs : https://salsa.debian.org/matthiasklein/paho.mqtt.cpp
   Section : libs

It builds those binary packages:

  libpaho-mqttpp-dev - Eclipse Paho MQTT C++ Client Library - development files
  libpaho-mqttpp3-1 - Eclipse Paho MQTT C++ Client Library - shared libraries

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

  https://mentors.debian.net/package/paho.mqtt.cpp/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/paho.mqtt.cpp/paho.mqtt.cpp_1.2.0-1.dsc

Changes for the initial release:

 paho.mqtt.cpp (1.2.0-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #977740

Regards,
-- 
  Matthias Klein

Bug#982287: wsjtx: Fails on launch

2021-02-08 Thread Christoph Berg

Control: tags -1 confirmed
Control: retitle -1 wsjtx fails to start without en_US.UTF-8 locale

Re: Hilary Snaden
> On launch, the program immediately exits:
> 
> $ wsjtx
> Error: locale::facet::_S_create_c_locale name not valid

Oh, good catch. I had the same problem here but forgot to investigate
further after "apt install locales-all" had made the problem
disappear.

The problem is this in main():

  std::locale::global (std::locale ("en_US.UTF-8"));

I'll change that to C.UTF-8.

Until then, `dpkg-reconfigure locales` and enabling en_US.UTF-8 will
do the trick.

Christoph

Bug#980122: tagging 980122

On Mon, Feb 08, 2021 at 01:53:17AM +0100, Chris Hofstaedtler wrote:
> * Adrian Bunk wrote:
> > tags 980122 + moreinfo

Sorry, I wanted to write an email about this but got distracted.

> * Moritz Muehlenhoff wrote:
> > depends on legacy packages (Py2, GTK2),
> > is dead upstream
> 
> These points haven't changed, even with Adrian's NMU, right?

fbpanel never had a runtime dependency on Python,
and build dependencies on Python 2 are permitted in bullseye.
This might change in bookworm, but that is behind the horizon.

GTK2 dependencies are not a reason for removal, and #967335 says 
"perhaps removing GTK 2 from Debian will never be feasible".

"dead upstream" is true for large parts of the archive,
unless there is security exposure this is acceptable.

"RC-buggy" was the only known real problem with this package,
and I fixed this with the patches from Ubuntu.

> Chris

cu
Adrian

Bug#981277: shellcheck: git snapshot for Bullseye?

Hello Diederik,

Thanks for reporting this,

We try not to package git snapshots unless there are specific reasons
for it, as we might inadvertently introduce bugs and increase the
complexity of dealing with the package for our users.

Is there anything specific that you're looking for in these changes?
Like a bugfix or a new feature?

Cheers,

-- 
Samuel Henrique

Bug#953986: nmap-mac-prefixes outdated

Hello Carsten,

I know what you mean now, thanks for clarifying, what you're
requesting is an up-to-date nmap-mac-prefixes for stable and possibly
oldstable packages of nmap (since we don't package new releases in
there).

Your suggestion to wget the file at install time wouldn't work as we
cannot download anything from the internet at install time (or rely on
the internet at all). But there might be a solution for this problem.

I'm thinking about providing updates to packages in our
stable/oldstable releases with the updated file.

I'll see what I can do and will let you know,

Thanks,


-- 
Samuel Henrique

Bug#982329: knot-resolver: [INTL:pt] Portuguese translation - debconf messages

Package: knot-resolver
Version: 5.2.1-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for knot-resolver's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


knot-resolver_5.2.1-1_pt.po.gz
Description: application/gzip

Bug#959732: scilab: Scilab graphic window is empty when plotting

2021-02-08 Thread ian . schindler

I have the same bug.  Is there any update?

Ian
On Mon, 04 May 2020 19:09:22 +0200 Jacek Sobczak  wrote:
> Package: scilab
> Version: 6.1.0+dfsg1-3
> Severity: important
> 
> Dear Maintainer,
> 
> When plottin scilab just opens an empty graphic window. Should be
> reproducible with the simplest example:
> 
> x=[0:0.1:2*%pi];
> plot(x,sin(x))
> 
> In the console these messages are shown (repeated multiple times)
> whenever trying to plot:
> 
> Exception in thread "AWT-EventQueue-0" com.jogamp.opengl.GLException: Caught 
> GLException: Profile GL4bc is not available on X11GraphicsDevice[type .x11, 
> connection :0, unitID 0, handle 0x7fbc2489d650, owner true, 
> ResourceToolkitLock[obj 0x2865a089, isOwner true, <78c52e3b, 5dae9bd8>[count 
> 1, qsz 0, owner ]]], but: [GLProfile[GL4ES3/GL4.hw], 
> GLProfile[GL2ES2/GL4.hw], GLProfile[GL4/GL4.hw], GLProfile[GL4/GL4.hw], 
> GLProfile[GL3/GL4.hw], GLProfile[GL2GL3/GL4.hw]]
> at 
> com.jogamp.opengl.awt.GLJPanel$OffscreenBackend.initialize(GLJPanel.java:1795)
> at 
> com.jogamp.opengl.awt.GLJPanel.initializeBackendImpl(GLJPanel.java:1377)
> at com.jogamp.opengl.awt.GLJPanel.paintComponent(GLJPanel.java:549)
> at java.desktop/javax.swing.JComponent.paint(JComponent.java:1074)
> at 
> java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:907)
> at java.desktop/javax.swing.JComponent.paint(JComponent.java:1083)
> at 
> java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:907)
> at java.desktop/javax.swing.JComponent.paint(JComponent.java:1083)
> at java.desktop/javax.swing.JLayeredPane.paint(JLayeredPane.java:590)
> at 
> java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:907)
> at java.desktop/javax.swing.JComponent.paint(JComponent.java:1083)
> at java.desktop/javax.swing.JViewport.paint(JViewport.java:737)
> at 
> java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:907)
> at java.desktop/javax.swing.JComponent.paint(JComponent.java:1083)
> at 
> java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:907)
> at 
> org.scilab.modules.gui.bridge.tab.SwingScilabDockablePanel.paintChildren(Unknown
>  Source)
> at java.desktop/javax.swing.JComponent.paint(JComponent.java:1083)
> at 
> java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:907)
> at java.desktop/javax.swing.JComponent.paint(JComponent.java:1083)
> at 
> org.flexdock.docking.defaults.DefaultDockingPort.paint(DefaultDockingPort.java:1983)
> at 
> java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:907)
> at java.desktop/javax.swing.JComponent.paint(JComponent.java:1083)
> at 
> java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:907)
> at java.desktop/javax.swing.JComponent.paint(JComponent.java:1083)
> at java.desktop/javax.swing.JLayeredPane.paint(JLayeredPane.java:590)
> at 
> java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:907)
> at java.desktop/javax.swing.JComponent.paint(JComponent.java:1083)
> at 
> java.desktop/javax.swing.JComponent.paintToOffscreen(JComponent.java:5255)
> at 
> java.desktop/javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:246)
> at 
> java.desktop/javax.swing.RepaintManager.paint(RepaintManager.java:1323)
> at 
> java.desktop/javax.swing.JComponent._paintImmediately(JComponent.java:5203)
> at 
> java.desktop/javax.swing.JComponent.paintImmediately(JComponent.java:5013)
> at 
> java.desktop/javax.swing.RepaintManager$4.run(RepaintManager.java:888)
> at 
> java.desktop/javax.swing.RepaintManager$4.run(RepaintManager.java:848)
> at java.base/java.security.AccessController.doPrivileged(Native 
> Method)
> at 
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
> at 
> java.desktop/javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:848)
> at 
> java.desktop/javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:823)
> at 
> java.desktop/javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:772)
> at 
> java.desktop/javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1890)
> at 
> java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
> at 
> java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)


-- 
 Sent with Tutanota, the secure & ad-free mailbox: 
 https://tutanota.com

Bug#980923: acngtools eats all the CPU and doesn’t finish daily cron with merged pdiffs

2021-02-08 Thread David Prévot


Hi,

Le 08/02/2021 à 13:36, Eduard Bloch a écrit :

notfound 980923 3.6-1

[…]

At least that issue should be solved in 3.6 now.


Indeed, I managed to finish a manual maintenance task (and gain back ten 
of the fifteen Go I’ve recently needed to add in /var). I’ll come back 
to you in case the daily task is not as happy.


Thank you.

Regards

David

Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles

2021-02-08 Thread Mike Hommey

On Sun, Feb 07, 2021 at 04:18:50PM +0100, Antoine Le Gonidec wrote:
> With firefox 85.0.1-1, my extensions installed from Debian repositories are 
> no longer disabled on launch.
> 
> I made sure to restart Firefox several times to not get tricked by the 
> temporary normal behaviour right after a firefox update. I browsed a couple 
> Web pages too, to check that the add-ons are actually working and not merely 
> showing as active.
> 
> - firefox 85.0.1-1
> - webext-ublock-origin-firefox 1.32.0+dfsg-1
> - webext-umatrix 1.4.0+dfsg-1
> 

I can confirm, but while I was also able to reproduce with older
versions of Firefox, I can't reproduce it anymore... so I'm not sure...

Mike

Bug#982327: ddclient: [INTL:pt] Updated Portuguese translation - debconf messages

Package: ddclient
Version: 3.9.1-7
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for ddclient's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


ddclient_3.9.1-7_pt.po.gz
Description: application/gzip

Bug#982313: grub-common: excessive dependency on mtools

2021-02-08 Thread Colin Watson

On Mon, Feb 08, 2021 at 06:00:45PM +0100, Sven Joachim wrote:
> In response to #774910, grub-common gained a dependency on mtools, but I
> do not think this makes much sense.  Creating a rescue disk with
> grub-mkrescue also requires xorriso, so the dependency on mtools alone
> is useless.
> 
> Personally I rely on third party rescue systems like GRML and do not use
> grub-mkrescue at all, so I think mtools should be demoted to Suggests,
> like xorriso.  Having both in Recommends might sense as well, but a hard
> dependency looks excessive.

On Mon, Feb 08, 2021 at 01:18:55PM -0800, Josh Triplett wrote:
> I agree; I think it'd be perfectly reasonable to have Recommends on both
> mtools and xorriso, but a hard dependency suggests that grub can't work
> without them. grub works fine without either mtools or xorriso
> installed; one utility, grub-mkrescue, doesn't. There's plenty of
> precedent in other packages, especially common packages that many people
> will have installed, for using Recommends for packages needed by one of
> many scripts within a package.

These are reasonable points, given that grub-common is installed nearly
everywhere and grub-mkrescue is not so frequently used.

I think what I'll do is drop mtools to Suggests alongside the existing
xorriso, but add a note to the package description indicating that
grub-mkrescue needs those packages (with a UEFI caveat in the case of
mtools).  This is still more of a package relationship than existed
before I dealt with #774910, and means that a simple "apt show" will
explain the situation.

If the two opposing requirements remain in tension after that, then I
think the way out is likely to be a separate binary package called
something like grub-tools or grub-utils that can hold things like
grub-mkrescue and grub-mkstandalone.  However, it's too late in the
bullseye release cycle for that option to be available just at the
moment.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz

2021-02-08 Thread Craig Small

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,
  The first problem I can see is you haven't pushed the git tags. Salsa
doesn't know about the 4.9.1 update[1]
git push --tags should do it

So it fails to build for me here
$ gbp buildpackage --git-pbuilder
gbp:info: Building with (cowbuilder) for sid
gbp:error: upstream/4.9.1 is not a valid treeish

"not valid teeish" = cant find the tag.

For your problem, I think you've not included some file, but can't see the
problem myself as I need the tag.

Don't give up, it does look all bewildering but you'll get there in the
end.

 - Craig

1: https://salsa.debian.org/debian/manpages-l10n/-/tags

On 2021-02-08 at 20:42, deb...@helgefjell.de wrote:
> Hello Craig,
> I updated the packge but now this gdb-thingy (sorry) is on strike and I
> have now idea why:
>
> helge@samd:/tmp/debian-manpages-l10n$ LC=ALL=C gbp buildpackage
> gbp:info: Performing the build
>  dpkg-buildpackage -us -uc -ui -i -I
>  dpkg-buildpackage: Information: Quellpaket manpages-l10n
> …
>  debian-manpages-l10n/po/ro/Makefile.in
>  dpkg-source: Fehler: Abbruch aufgrund unerwarteter Änderungen in den
>  Originalquellen, siehe /tmp/manpages-l10n_4.9.1-2.diff.n75akF
>  dpkg-source: Information: Sie können die lokalen Änderungen mit
>  dpkg-source --commit integrieren
>  dpkg-buildpackage: Fehler: Unterprozess dpkg-source -i -I -b .
>  lieferte Exitstatus 2
>  debuild: fatal error at line 1182:
>  dpkg-buildpackage -us -uc -ui -i -I failed
>  gbp:error: 'debuild -i -I' failed: it exited with 29
>
> Probably with some git magic I could repair this, but even
> helge@samd:/tmp/debian-manpages-l10n$ gbp import-orig --uscan
> gbp:info: Launching uscan...
> gbp:info: package is up to date, nothing to do.
> …
>
> Looks like no more localized manpages in Debian.
>
> I simply fail to understand this complicated toolchain, sorry.
>
> Greetings
>
>   Helge
>
> --
>   Dr. Helge Kreutzmann deb...@helgefjell.de
>Dipl.-Phys.
http://www.helgefjell.de/debian.php
> 64bit GNU powered gpg signed mail preferred
>Help keep free software "libre": http://www.ffii.de/
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.0.2
Comment: Seamlessly send and receive encrypted email

wsFzBAEBCgAGBQJgIa5ZACEJEAIhZsD/PITjFiEEXT3w9TizJ8CqeneiAiFm
wP88hOOprw/+ILu++4+zftk8uHeSqbpnBpT6nnMzwOiiprPfjTNGoAWduR3S
WoF64sUqNj3sqhJgQhAOlIQSYwfZ9h65FsZIoU1nOr4pIZABF49HBAtI5M4T
eOhmdcmkX5N9JuRKbbGLOnHNAjiR2rpw5ThsdL6YSs5DCrz7IQ68xWW5Lgvb
YTxK0jDVcOdxMsst7paONkI7k0uiOvxe3XKhuoKvKt750p6+0sQfki3WXo2Y
wbFrxJU+ht5oqvjR563Ah+mplHBvPp3llatywiSRYgNPBUMXz7Rlm7UB736g
Tft0qv0S6lW7ljfxrJ0N2RpHTj5OXaI6pVygJqBwNPiIjfiYwUrUOpwWJkRs
/JxW3MGOkNpLlIE7fdvXi2d9JDA+dHu6f0kUGsmgdvZn8dOf2sGLX/szVjoF
pEtdj/qJYN+ynOxC9EsxhIqJPxn/61bc+Y6c2or8clymUsfVChuyJ8TxzrBg
wTHeChgGzz2VIVKmn1IBlBY5dHdQeci1CvXoSnSZdgDEx/OPJfR7GatolZy2
J8gEuCOy8MfFSJC16PN+xFa0aHaLx+vsaMaFUVFUlJYgRKukCXcTjdSsprUR
Kh912pDW8jPlvPmhF6JTVML8JfVMRPBaB2jzTxQX6aT9CfAQXk7TyGRwIjLr
KJIVIJRz3bhAIPmac3g/uvNvfmYAXGN+e14=
=LWG0
-END PGP SIGNATURE-

Bug#982313: grub-common: excessive dependency on mtools

2021-02-08 Thread Josh Triplett

Package: grub-common
Followup-For: Bug #982313
X-Debbugs-Cc: j...@joshtriplett.org

I agree; I think it'd be perfectly reasonable to have Recommends on both
mtools and xorriso, but a hard dependency suggests that grub can't work
without them. grub works fine without either mtools or xorriso
installed; one utility, grub-mkrescue, doesn't. There's plenty of
precedent in other packages, especially common packages that many people
will have installed, for using Recommends for packages needed by one of
many scripts within a package.

Bug#961929: rsync: syntax for multiple files from remote host seems not working when files are in different modules

Hello Kurt,

Thanks for reporting the issue, it doesn't seem to be related to our
packaging of rsync, could you try contacting upstream about it?

Thanks,


-- 
Samuel Henrique

Bug#978759: rsync: --noatime rename breaks rsync with older versions

Hello Mara,

Thanks for reporting the issue,

Unfortunately this was an expected behavior, upstream changed the
parameter as the previous one was not part of the official release (it
was an upstream provided patch), I haven't looked into the details yet
to know if a compatibility patch can be provided but if so, I suggest
contacting upstream.

I'm happy to know that the backports package was useful :)

Thanks,

-- 
Samuel Henrique

Bug#977440: gmusicbrowser: New version not in testing

2021-02-08 Thread Paolo Inaudi

I suppose 1.1.16 does not solve the underlying issue of gmusicbrowser 
relying on gtk2.


However 1.1.99.1 beta is out supporting gtk3, so it might be worth 
packaging for experimental!

Development is active upstream. Not frenetic, but definitely not dead.

Paolo

Bug#982326: convert android-libbase-dev to Architecture: any

2021-02-08 Thread Helmut Grohne

Package: android-libbase-dev
Version: 1:10.0.0+r36-7
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:android-platform-build 
src:android-platform-frameworks-base src:android-platform-libnativehelper 
src:android-platform-system-extras src:android-platform-system-tools-aidl 
src:android-platform-system-tools-hidl

The affected packages cannot satisfy their cross Build-Depends, because
their transitive dependency on android-libbase-dev is not satisfiable.
In general, Architecture: all packages can never satisfy cross build
dependencies unless marked Multi-Arch: foreign or annotated :native. A
foreign marking would be fatal in this case, because it would mask the
architecture constraint and android-libbase would be installed for the
build architecture while requested for the host architecture. In a
similar vein, :native does not solve the problem. This is known as the
"multiarch interpreter problem" and the standard workaround is
converting affected packages to Architecture: any. Please consider
applying the attached patch.

I suspect that more binary packages from this source package are
affected by this issue. Likely and android-*-dev Arch: all package that
depends on an Arch: any package containing a shared library needs to be
converted. Can you handle that as well?

Helmut
diff --minimal -Nru android-platform-system-core-10.0.0+r36/debian/changelog 
android-platform-system-core-10.0.0+r36/debian/changelog
--- android-platform-system-core-10.0.0+r36/debian/changelog2021-01-19 
21:09:43.0 +0100
+++ android-platform-system-core-10.0.0+r36/debian/changelog2021-02-08 
16:34:23.0 +0100
@@ -1,3 +1,10 @@
+android-platform-system-core (1:10.0.0+r36-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch android-libbase-dev to Architecture: any. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 08 Feb 2021 16:34:23 +0100
+
 android-platform-system-core (1:10.0.0+r36-7) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru android-platform-system-core-10.0.0+r36/debian/control 
android-platform-system-core-10.0.0+r36/debian/control
--- android-platform-system-core-10.0.0+r36/debian/control  2021-01-19 
21:09:05.0 +0100
+++ android-platform-system-core-10.0.0+r36/debian/control  2021-02-08 
16:34:21.0 +0100
@@ -268,9 +268,8 @@
 
 Package: android-libbase-dev
 Section: libdevel
-Architecture: all
-Depends: android-libbase (>= ${binary:Version}),
- android-libbase (<< ${binary:Version}.1~),
+Architecture: any
+Depends: android-libbase (= ${binary:Version}),
  ${misc:Depends}
 Description: Android base library - Development files
  This library provides APIs for basic tasks like handling files, Unicode

Bug#978371: gnokii: diff for NMU version 0.6.30+dfsg-1.3

Control: tags 978371 + patch
Control: tags 978371 + pending

Dear maintainer,

I've prepared an NMU for gnokii (versioned as 0.6.30+dfsg-1.3) and 
uploaded it to DELAYED/15. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru gnokii-0.6.30+dfsg/debian/changelog gnokii-0.6.30+dfsg/debian/changelog
--- gnokii-0.6.30+dfsg/debian/changelog	2016-12-09 18:39:06.0 +0200
+++ gnokii-0.6.30+dfsg/debian/changelog	2021-02-08 22:53:35.0 +0200
@@ -1,3 +1,11 @@
+gnokii (0.6.30+dfsg-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream workaround for FTBFS with gettext >= 0.20.
+(Closes: #978371)
+
+ -- Adrian Bunk   Mon, 08 Feb 2021 22:53:35 +0200
+
 gnokii (0.6.30+dfsg-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gnokii-0.6.30+dfsg/debian/patches/0001-Add-codeset.m4-to-m4-to-prevent-build-failure-with-g.patch gnokii-0.6.30+dfsg/debian/patches/0001-Add-codeset.m4-to-m4-to-prevent-build-failure-with-g.patch
--- gnokii-0.6.30+dfsg/debian/patches/0001-Add-codeset.m4-to-m4-to-prevent-build-failure-with-g.patch	1970-01-01 02:00:00.0 +0200
+++ gnokii-0.6.30+dfsg/debian/patches/0001-Add-codeset.m4-to-m4-to-prevent-build-failure-with-g.patch	2021-02-08 22:51:47.0 +0200
@@ -0,0 +1,44 @@
+From 4dd198d121ca366c9881d022a56394c2e56936d0 Mon Sep 17 00:00:00 2001
+From: Pawel Kot 
+Date: Thu, 2 Jan 2020 13:13:45 +0100
+Subject: Add codeset.m4 to m4/ to prevent build failure with gettext >= 0.20
+
+Add codeset.m4 to m4/ as it is missing from gettext distribution from
+version 0.20.
+
+Fixes: https://savannah.nongnu.org/bugs/?57509
+
+diff --git a/m4/codeset.m4 b/m4/codeset.m4
+new file mode 100644
+index ..da1b2aef
+--- /dev/null
 b/m4/codeset.m4
+@@ -0,0 +1,25 @@
++# codeset.m4 serial 5 (gettext-0.18.2)
++dnl Copyright (C) 2000-2002, 2006, 2008-2014, 2016 Free Software Foundation,
++dnl Inc.
++dnl This file is free software; the Free Software Foundation
++dnl gives unlimited permission to copy and/or distribute it,
++dnl with or without modifications, as long as this notice is preserved.
++
++dnl From Bruno Haible.
++
++AC_DEFUN([AM_LANGINFO_CODESET],
++[
++  AC_CACHE_CHECK([for nl_langinfo and CODESET], [am_cv_langinfo_codeset],
++[AC_LINK_IFELSE(
++   [AC_LANG_PROGRAM(
++  [[#include ]],
++  [[char* cs = nl_langinfo(CODESET); return !cs;]])],
++   [am_cv_langinfo_codeset=yes],
++   [am_cv_langinfo_codeset=no])
++])
++  if test $am_cv_langinfo_codeset = yes; then
++AC_DEFINE([HAVE_LANGINFO_CODESET], [1],
++  [Define if you have  and nl_langinfo(CODESET).])
++  fi
++])
++
+-- 
+2.20.1
+
diff -Nru gnokii-0.6.30+dfsg/debian/patches/series gnokii-0.6.30+dfsg/debian/patches/series
--- gnokii-0.6.30+dfsg/debian/patches/series	2011-04-24 01:08:43.0 +0300
+++ gnokii-0.6.30+dfsg/debian/patches/series	2021-02-08 22:53:34.0 +0200
@@ -1,2 +1,3 @@
 change_configfile_order.patch
 debian-changes-0.6.30+dfsg-1
+0001-Add-codeset.m4-to-m4-to-prevent-build-failure-with-g.patch

Bug#982325: exim4: Please compile with AUTH_EXTERNAL=yes

2021-02-08 Thread Bob Ham

Package: exim4
Version: 4.92-8+deb10u4
Severity: normal

Please could you compile the exim4 packages with AUTH_EXTERNAL=yes set
in the Makefile?  This is needed for sending mail with TLS certificate
authentication using K-9 Mail which requires SASL EXTERNAL.  The new
"external" driver was committed in January 2019:

https://github.com/Exim/exim/commit/b53c265b5c

Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz

2021-02-08 Thread Helge Kreutzmann

Hello Craig,
I updated the packge but now this gdb-thingy (sorry) is on strike and I
have now idea why:

helge@samd:/tmp/debian-manpages-l10n$ LC=ALL=C gbp buildpackage
gbp:info: Performing the build
 dpkg-buildpackage -us -uc -ui -i -I
 dpkg-buildpackage: Information: Quellpaket manpages-l10n
…
 debian-manpages-l10n/po/ro/Makefile.in
 dpkg-source: Fehler: Abbruch aufgrund unerwarteter Änderungen in den
 Originalquellen, siehe /tmp/manpages-l10n_4.9.1-2.diff.n75akF
 dpkg-source: Information: Sie können die lokalen Änderungen mit
 dpkg-source --commit integrieren
 dpkg-buildpackage: Fehler: Unterprozess dpkg-source -i -I -b .
 lieferte Exitstatus 2
 debuild: fatal error at line 1182:
 dpkg-buildpackage -us -uc -ui -i -I failed
 gbp:error: 'debuild -i -I' failed: it exited with 29

Probably with some git magic I could repair this, but even 
helge@samd:/tmp/debian-manpages-l10n$ gbp import-orig --uscan
gbp:info: Launching uscan...
gbp:info: package is up to date, nothing to do.
…

Looks like no more localized manpages in Debian.

I simply fail to understand this complicated toolchain, sorry.

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#978261: swiglpk: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p 3.9 returned exit code 13

Control: tags -1 patch fixed-upstream

On Sat, Dec 26, 2020 at 10:45:50PM +0100, Lucas Nussbaum wrote:
> Source: swiglpk
> Version: 4.65.0-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201226 ftbfs-bullseye
>...
> > ==
> > ERROR: Failure: ImportError 
> > (/<>/.pybuild/cpython3_3.9_swiglpk/build/swiglpk/_swiglpk.cpython-39-x86_64-linux-gnu.so:
> >  undefined symbol: glp_netgen_prob)
> > --
> > Traceback (most recent call last):
> >   File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest
> > raise self.exc_val.with_traceback(self.tb)
> >   File "/usr/lib/python3/dist-packages/nose/loader.py", line 416, in 
> > loadTestsFromName
> > module = self.importer.importFromPath(
> >   File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in 
> > importFromPath
> > return self.importFromDir(dir_path, fqname)
> >   File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in 
> > importFromDir
> > mod = load_module(part_fqname, fh, filename, desc)
> >   File "/usr/lib/python3.9/imp.py", line 244, in load_module
> > return load_package(name, filename)
> >   File "/usr/lib/python3.9/imp.py", line 216, in load_package
> > return _load(spec)
> >   File "", line 711, in _load
> >   File "", line 680, in _load_unlocked
> >   File "", line 790, in exec_module
> >   File "", line 228, in 
> > _call_with_frames_removed
> >   File 
> > "/<>/.pybuild/cpython3_3.9_swiglpk/build/swiglpk/__init__.py", 
> > line 1, in 
> > from .swiglpk import *
> >   File 
> > "/<>/.pybuild/cpython3_3.9_swiglpk/build/swiglpk/swiglpk.py", 
> > line 13, in 
> > from . import _swiglpk
> > ImportError: 
> > /<>/.pybuild/cpython3_3.9_swiglpk/build/swiglpk/_swiglpk.cpython-39-x86_64-linux-gnu.so:
> >  undefined symbol: glp_netgen_prob
> > 
> > --
>...

Attached are the relevant parts from the upstream fix.

After that, it is worth trying whether this fixed python-cobra.

cu
Adrian
>From ec985c15ae507139de70b943c56f1042acd79a8a Mon Sep 17 00:00:00 2001
From: Jonathon Fletcher 
Date: Tue, 2 Feb 2021 00:56:27 -0800
Subject: ignore problematic functions via swig directives in glpk.i (#43)

diff --git a/scripts/find_newest_glpk_release.py b/scripts/find_newest_glpk_release.py
index bf79f74..e4254df 100755
--- a/scripts/find_newest_glpk_release.py
+++ b/scripts/find_newest_glpk_release.py
@@ -12,7 +12,8 @@ if response.ok:
 new_major, new_minor = int(match[0][0]), int(match[0][1])
 if new_major > major:
 major = new_major
-if new_minor > minor:
+minor = new_minor
+if new_major >= major and new_minor > minor:
 minor = new_minor
 
 print('{}.{}'.format(major, minor), end='')
diff --git a/setup.py b/setup.py
index fbf76a1..e8d81b1 100644
--- a/setup.py
+++ b/setup.py
@@ -22,39 +22,38 @@ from distutils.command.build import build
 import subprocess
 import versioneer
 
-def copy_glpk_header():
-if os.path.isfile('glpk.h'):
+
+def find_glpk_header():
+if os.environ.get("GLPK_HEADER_PATH", None) and os.path.isdir(os.environ.get("GLPK_HEADER_PATH", None)):
+print('glpk.h found in GLPK_HEADER_PATH environment variable')
+glpk_header_path = os.path.join(os.environ.get("GLPK_HEADER_PATH", None), 'glpk.h')
+elif os.path.isfile('glpk.h'):
 print('glpk.h found in source directory')
-glpk_header_path = os.path.join('./', 'glpk.h')
+glpk_header_path = os.path.join(os.getcwd(), 'glpk.h')
 else:
 print('Trying to determine glpk.h location')
-glpsol_path = os.path.dirname(subprocess.check_output(['which', 'glpsol']))
-glpk_header_path = os.path.join(os.path.dirname(glpsol_path).decode("utf-8"), 'include', 'glpk.h')
-print('glpk.h found at {}'.format(glpk_header_path))
+glpsol_dirname = os.path.dirname(subprocess.check_output(['which', 'glpsol']))
+glpk_header_path = os.path.join(os.path.dirname(glpsol_dirname).decode("utf-8"), 'include', 'glpk.h')
 if os.path.exists(glpk_header_path):
-with open('swiglpk/glpk_clean.h', 'w') as out_handle:
-with open(glpk_header_path) as in_handle:
-for line in in_handle:
-if line == 'void glp_vprintf(const char *fmt, va_list arg);\n':
-out_handle.write('// The following line is commented out because it is causing problems with swig\n')
-out_handle.write('// void glp_vprintf(const char *fmt, va_list arg);')
-else:
-out_handle.write(line)
+print('glpk.h found at {}'.format(glpk_header_path))
+return os.path.dirname(os.path.abspath(glpk_header_path))
 else:
 raise Exception('C

Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz

2021-02-08 Thread Helge Kreutzmann

Hello Craig,
On Tue, Feb 09, 2021 at 06:54:54AM +1100, Craig Small wrote:
> On Tue, 9 Feb 2021 at 05:16, Helge Kreutzmann  wrote:
> > On Sun, Feb 07, 2021 at 04:51:14PM -0500, Craig Small wrote:
> > >   I think you have the control lines wrong.  You have both the lines from
> > > psmisc and manpages-de there.
> > >
> > > Breaks: manpages-de (<= 2.16-1), psmisc (<< 23.4-2)
> > > Replaces: manpages-de (<= 2.16-1)
> >
> > This is correct, it also breaks (and replaces) older manpages-de from
> > stable.
> >
> As the standard part of dpkg installing a newer version of package, it
> uninstalls all previous versions on the same package.

Correct.

> > This is not related to this bug but stems from the fact that the
> > source package manpages-de was replaced manpages-l10n which in turn
> > now builds manpages-de amongst others.
> >
> They are source packages, the binary package is still manpages-de.  Think
> about it, have you ever been able to have two versions of the same package
> installed no matter what the source package name was?

> > For #982059 yes, but if you perform an update from stable (without
> > psmic involved) then the other breaks is needed as well, see #959846.
> >
> Let's have a look at #959846...
> 
> manpages-de: missing Breaks+Replaces: manpages-de-dev (<< 4)
> 
> manpages-de-***dev*** is the conflicting package name. So yes, you should
> have something about manpages-de-dev otherwise you get:
> 
> dpkg: error processing archive
> /var/cache/apt/archives/manpages-de_4.0.0-3_all.deb (--unpack):
>trying to overwrite '/usr/share/man/de/man4/console_ioctl.4.gz',
> which is also in package manpages-de-dev 2.12-1
> 
> And probably other problems too.
> 
> If you can find a reference somewhere where changing the source package
> means you need something for the corresponding binary package of the same
> name, I'm happy to see it but I've never seen that before.

I'm not a specialist in this kind of relationsships. 

I'll update the package accordingly, thanks for the explanation.

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#982117: RM: gdpc [i386 s390x armel armhf mipsel] -- ROM; test failures

2021-02-08 Thread Étienne Mollier

Control: retitle -1 RM: gdpc [i386 s390x armel armhf mipsel] -- ROM; test 
failures

Greetings,

Further testing on real hardware shown the architecture armhf
was also affected by buffer overflow errors (#981876).  Since
the issue did not occur in qemu-user-static context, I'm
suspecting the bug might affect all other 32 bits architectures.
Thus I updated the removal request title to remove armel, armhf,
and mipsel in addition to i386 (and s390x which has different
symptoms).

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/5, please excuse my verbosity.

Bug#978201: autobahn-cpp: diff for NMU version 17.5.1+git7cc5d37-2.1

Control: tags 978201 + patch
Control: tags 978201 + pending

Dear maintainer,

I've prepared an NMU for autobahn-cpp (versioned as 
17.5.1+git7cc5d37-2.1) and uploaded it to DELAYED/14.
Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru autobahn-cpp-17.5.1+git7cc5d37/debian/changelog autobahn-cpp-17.5.1+git7cc5d37/debian/changelog
--- autobahn-cpp-17.5.1+git7cc5d37/debian/changelog	2017-11-21 23:58:08.0 +0200
+++ autobahn-cpp-17.5.1+git7cc5d37/debian/changelog	2021-02-08 22:23:04.0 +0200
@@ -1,3 +1,10 @@
+autobahn-cpp (17.5.1+git7cc5d37-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for FTBFS with Boost 1.74. (Closes: #978201)
+
+ -- Adrian Bunk   Mon, 08 Feb 2021 22:23:04 +0200
+
 autobahn-cpp (17.5.1+git7cc5d37-2) unstable; urgency=medium
 
   * Include forgotten headers wamp_publish_options.*
diff -Nru autobahn-cpp-17.5.1+git7cc5d37/debian/patches/0001-Make-sure-all-used-placeholders-are-in-scope.patch autobahn-cpp-17.5.1+git7cc5d37/debian/patches/0001-Make-sure-all-used-placeholders-are-in-scope.patch
--- autobahn-cpp-17.5.1+git7cc5d37/debian/patches/0001-Make-sure-all-used-placeholders-are-in-scope.patch	1970-01-01 02:00:00.0 +0200
+++ autobahn-cpp-17.5.1+git7cc5d37/debian/patches/0001-Make-sure-all-used-placeholders-are-in-scope.patch	2021-02-08 22:21:14.0 +0200
@@ -0,0 +1,30 @@
+From eac22bd61117ac18b5efee3c6da16a97835055de Mon Sep 17 00:00:00 2001
+From: Robin Linden 
+Date: Fri, 2 Oct 2020 23:49:29 +0200
+Subject: Make sure all used placeholders are in scope
+
+---
+ autobahn/wamp_websocketpp_websocket_transport.ipp | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/autobahn/wamp_websocketpp_websocket_transport.ipp b/autobahn/wamp_websocketpp_websocket_transport.ipp
+index 78398aa..9a8bdb2 100644
+--- a/autobahn/wamp_websocketpp_websocket_transport.ipp
 b/autobahn/wamp_websocketpp_websocket_transport.ipp
+@@ -48,11 +48,12 @@ namespace autobahn {
+ {
+ // Bind the handlers we are using
+ using websocketpp::lib::placeholders::_1;
++using websocketpp::lib::placeholders::_2;
+ using websocketpp::lib::bind;
+ m_client.set_open_handler(bind(&wamp_websocketpp_websocket_transport::on_ws_open, this, _1));
+ m_client.set_close_handler(bind(&wamp_websocketpp_websocket_transport::on_ws_close, this, _1));
+ m_client.set_fail_handler(bind(&wamp_websocketpp_websocket_transport::on_ws_fail, this, _1));
+-m_client.set_message_handler(bind(&wamp_websocketpp_websocket_transport::on_ws_message, this, ::_1, ::_2));
++m_client.set_message_handler(bind(&wamp_websocketpp_websocket_transport::on_ws_message, this, _1, _2));
+ if(!debug_enabled) {
+ m_client.clear_access_channels(websocketpp::log::alevel::all);
+ }
+-- 
+2.20.1
+
diff -Nru autobahn-cpp-17.5.1+git7cc5d37/debian/patches/series autobahn-cpp-17.5.1+git7cc5d37/debian/patches/series
--- autobahn-cpp-17.5.1+git7cc5d37/debian/patches/series	2017-11-21 23:58:08.0 +0200
+++ autobahn-cpp-17.5.1+git7cc5d37/debian/patches/series	2021-02-08 22:23:03.0 +0200
@@ -1 +1,2 @@
 include_forgotten_headers.patch
+0001-Make-sure-all-used-placeholders-are-in-scope.patch

Bug#978434: paho.mqtt.c: Sponsor for package upload?

2021-02-08 Thread Matthias Klein




Am 8. Februar 2021 20:22:48 schrieb Adam Borowski :


I've just uploaded 1.3.8-1.


Thank you very much!

Best regards,
Matthias

Bug#982324: ksplashqml crash at plasma workspace startup

2021-02-08 Thread Tobias Rupf

Package: plasma-workspace
Version: 4:5.20.5-3

Hello,

I just have migrated my laptop from Debian buster to unstable. I'm using KDE 
with x11. At login I get a message that ksplashqml produced a segmentation 
fault.
Afterwards I get a black screen, but can add miniprograms (applets?) via mous 
right-click. This way I can add an application starter to the desktop and start 
applications as normal, even systemsettings. In systemsettings the Breeze theme 
is not shown, although all is installed if I look on synaptic (just the same 
plasma packages as I have installed on my desktop).

If I use Gnome it starts as normal, so I guess it is not a video driver setting 
but has something to do with the upgrade process - but I cannot find out what 
went wrong.

Regards,
trupf


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

Bug#982117: Bug#981876: gdpc: flaky autopkgtest on i386

2021-02-08 Thread Étienne Mollier

Greetings,

Alas, the autopkgtest failed with buffer overflow on armhf[1] at
the same point as on i386:

xvfb-run --auto-servernum \
/usr/bin/gdpc m 2 d 10 erase xyz 2 3 4 5 md.test 2>&1 \
| tee --append test.log &
sleep 10
*** buffer overflow detected ***: terminated
Aborted
check_n_cleanup
error: gdpc crashed before the end of the test

[1] https://ci.debian.net/data/autopkgtest/testing/armhf/g/gdpc/10311835/log.gz

This regression does not appear while testing on Qemu, so I
heavily suspect it might affect other 32 bits architectures such
as armel and mipsel.  I will update the package to remove these
three architectures, and update the archive removal request
accordingly.

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#982323: pcp-export-pcp2{graphite,influxdb}: missing Breaks+Replaces: pcp (<< 5.2.5)

Package: pcp-export-pcp2graphite,pcp-export-pcp2influxdb
Version: 5.2.5-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../pcp-export-pcp2graphite_5.2.5-1_amd64.deb ...
  Unpacking pcp-export-pcp2graphite (5.2.5-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/pcp-export-pcp2graphite_5.2.5-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/bash-completion/completions/pcp2graphite', 
which is also in package pcp 5.2.3-1
  Errors were encountered while processing:
   /var/cache/apt/archives/pcp-export-pcp2graphite_5.2.5-1_amd64.deb

  Preparing to unpack .../pcp-export-pcp2influxdb_5.2.5-1_amd64.deb ...
  Unpacking pcp-export-pcp2influxdb (5.2.5-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/pcp-export-pcp2influxdb_5.2.5-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/bash-completion/completions/pcp2influxdb', 
which is also in package pcp 5.2.3-1
  Errors were encountered while processing:
   /var/cache/apt/archives/pcp-export-pcp2influxdb_5.2.5-1_amd64.deb


Apparently the bash completions were moved between the packages in the
last upload.


cheers,

Andreas


pcp=5.2.3-1_pcp-export-pcp2graphite=5.2.5-1.log.gz
Description: application/gzip

Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz

2021-02-08 Thread Craig Small

On Tue, 9 Feb 2021 at 05:16, Helge Kreutzmann  wrote:

> On Sun, Feb 07, 2021 at 04:51:14PM -0500, Craig Small wrote:
> >   I think you have the control lines wrong.  You have both the lines from
> > psmisc and manpages-de there.
> >
> > Breaks: manpages-de (<= 2.16-1), psmisc (<< 23.4-2)
> > Replaces: manpages-de (<= 2.16-1)
>
> This is correct, it also breaks (and replaces) older manpages-de from
> stable.
>
As the standard part of dpkg installing a newer version of package, it
uninstalls all previous versions on the same package.


> This is not related to this bug but stems from the fact that the
> source package manpages-de was replaced manpages-l10n which in turn
> now builds manpages-de amongst others.
>
They are source packages, the binary package is still manpages-de.  Think
about it, have you ever been able to have two versions of the same package
installed no matter what the source package name was?


> For #982059 yes, but if you perform an update from stable (without
> psmic involved) then the other breaks is needed as well, see #959846.
>
Let's have a look at #959846...

manpages-de: missing Breaks+Replaces: manpages-de-dev (<< 4)

manpages-de-***dev*** is the conflicting package name. So yes, you should
have something about manpages-de-dev otherwise you get:

dpkg: error processing archive
/var/cache/apt/archives/manpages-de_4.0.0-3_all.deb (--unpack):
   trying to overwrite '/usr/share/man/de/man4/console_ioctl.4.gz',
which is also in package manpages-de-dev 2.12-1

And probably other problems too.

If you can find a reference somewhere where changing the source package
means you need something for the corresponding binary package of the same
name, I'm happy to see it but I've never seen that before.

 - Craig

Bug#982322: lintian: data/files/generic-header-files: add utils\.h

Package: lintian
Version: 2.15.0
Severity: normal

On 5/12/18 12:27 PM, Chris Lamb wrote to #898377:
>>> Any other suggestions for overly-generic /usr/include/foo.h files
>>> whilst we are at it?
>>
>> Not really. We will see what the future brings.
> 
> Ah, how wistful. :)  Anyway, fixed in Git, pending upload:

Now I do have a new suggestion: two packages (elektroid, libcdparanoia-dev)
just came around with 

/usr/include/utils.h


Andreas

Bug#982321: libcdparanoia-dev: overly generic header name: /usr/include/utils.h

Package: libcdparanoia-dev
Version: 3.10.2+debian-13
Severity: serious
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package uses a very generic
header file name that now clashes with other packages:

/usr/include/utils.h


Andreas

Bug#982320: elektroid: overly generic header name: /usr/include/utils.h

Package: elektroid
Version: 1.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package uses a very generic
header file name that now clashes with other packages:

/usr/include/utils.h


Andreas

Bug#982319: sympy: [INTL:pt] Portuguese translation - debconf messages

Package: sympy
Version: 1.7.1-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for sympy's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


sympy_1.7.1-1_pt.po.gz
Description: application/gzip

Bug#964438: closed by Michael Biebl (Re: Bug#964438: apt-listbugs: dns error when running from cron job)

2021-02-08 Thread Oswald Buddenhagen

guys, are you serious? it's fine that you document a dependency on a 
missing systemd feature for a clean solution (if you actually file a 
request upstream), but the bug is nonetheless in the current 
implementation of the apt-listbugs package, and can be worked around 
there (e.g., by polling the network for ten seconds before proceeding).

Bug#979132: auto-apt-proxy takes a long time to run under schroot

2021-02-08 Thread Francesco P. Lovergine


On Sat, Feb 06, 2021 at 08:55:41PM +0100, Francesco P. Lovergine wrote:
Sorry for the long delay, your answer has been probably victim of my antispam 
systems.


First of all, I managed to still reproduce the issue with my current 
sid chroot in buster. Something changed, because now the delays 
appears only

the first time after purge and reinstall of auto-apt-proxy apparently.
Then it can run again in the same schroot session without delay... 
until the next schroot session and then again: it delays at the first 
run only :-(


Here it is the run of the command you requested:

00:00:00 + [ 204 -gt 60 ]
00:00:00 + rm -f /tmp/.auto-apt-proxy-1000/cache
00:00:00 + [ -f /tmp/.auto-apt-proxy-1000/cache ]
00:00:00 + __detect__
00:00:00 + detect_DNS_SRV_record
00:00:00 + + shuf
00:00:00 hostname --domain
00:00:00 + awk /^[^#]/{print "http://"; $1 ":" $4;found=1;exit}END{exit !found}
00:00:00 + /usr/lib/apt/apt-helper srv-lookup _apt_proxy._tcp.lovergine.com
00:00:00 + command -v ip
00:00:00 + ip route
00:00:00 + awk /default/ { print($3) }
00:00:00 + gateway=192.168.1.1
00:00:00 + getent hosts apt-proxy
00:00:00 + awk /[:blank:]/ { print($1) }
00:00:29 + explicit_proxy= 
 <- HERE!?
00:00:00 + detect_apt_cacher_ng 127.0.0.1
00:00:00 + local ip=127.0.0.1
00:00:00 + local proxy=http://127.0.0.1:3142
00:00:00 + hit -o Acquire::http::Proxy::127.0.0.1=DIRECT http://127.0.0.1:3142
00:00:00 + timeout 5 /usr/lib/apt/apt-helper -o Acquire::http::Proxy=DIRECT 
download-file -o Acquire::http::Proxy::127.0.0.1=DIRECT http://127.0.0.1:3142 
/tmp/tmp.hr4l6p
hnyH
00:00:00 + grep -q -i 406.*usage.information
00:00:00 + echo http://127.0.0.1:3142
00:00:00 + return 0
00:00:00 + return 0
00:00:00 + cat /tmp/.auto-apt-proxy-1000/cache
00:00:00 http://127.0.0.1:3142
00:00:00 + cleanup
00:00:00 + rm -f /tmp/tmp.hr4l6phnyH

real0m28.218s
user0m0.049s
sys 0m0.021s
(sid)frankie@aragorn:~
$



Another box, in this case a bullseye that host a buster chroot:

(buster)frankie@klecker:~
$ time auto-apt-proxy http://127.0.0.1:3142

real1m0.139s
user0m0.068s
sys 0m0.000s

The cache system is apt-cacher in that case. And the delay is present at each 
invocation. Note that this box lives in another network (other DNS servers, 
different domain, different interfaces and so on).


--
Francesco P. Lovergine

Bug#979491: raise severity

2021-02-08 Thread Andreas Henriksson

Control: severity -1 serious

In my opinion this (and other) bugs in the current version in
testing/bullseye makes the package unfit for release.

Shipping the package in the 0.8.5-3 state in bullseye is a complete
waste of time for any user that attempts to install and use it
for if not all atleast some of the main use-cases for this
software.

Raising the severity of this to highlight the importance of
the 0.10.0-1 upload migrating to testing before bullseye release.

Regards,
Andreas Henriksson

Bug#978434: paho.mqtt.c: Sponsor for package upload?

2021-02-08 Thread Adam Borowski

On Sun, Feb 07, 2021 at 03:11:16PM +0100, Matthias Klein wrote:
> Hello Roman,
> 
> thank you for preparing the update to version 1.3.8 in git [1].
> 
> Since you don't answer my mails, I would like to try again via the bug 
> tracker and the mailing list.
> 
> What is the reason that the package does not make it from the Mentors site
> [2] to the Debian archive for weeks?

We sponsors are lazy buggers, and once a package moves out of the top of the
queue^Wstack, it tends to be forgotten, and requires pinging.

> Is the original sponsor no longer available?  Does it make sense to ask
> for a new sponsor here on the mailing list?

Uploads for paho.mqtt.c:
1.3.5-1 to unstable: Nobuhiro Iwamatsu 
1.3.2-1 to unstable: Nobuhiro Iwamatsu 
1.3.0-1 to unstable: Nobuhiro Iwamatsu 

Apparently Iwamatsu-san did not receive the request, or was/is busy.
Asking the same sponsor is good as that person has prior knowledge of
your package, but otherwise a public request is faster.

I've just uploaded 1.3.8-1.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ How to exploit the Bible for weight loss:
⢿⡄⠘⠷⠚⠋⠀ Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.
⠈⠳⣄

Bug#982318: ldh-gui-suite: [INTL:pt] Updated Portuguese translation - debconf messages

Package: ldh-gui-suite
Version: 0.1_20200908-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for ldh-gui-suite's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


ldh-gui-suite_0.1_20200908-2_pt.po.gz
Description: application/gzip

Bug#982305: RFS: htmldoc/1.9.11-2 -- HTML processor that generates indexed HTML, PS, and PDF

2021-02-08 Thread Håvard Flaget Aasen

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: htmldoc
   Version : 1.9.11-2
   Upstream Author : Michael R Sweet 
 * URL : https://www.msweet.org/htmldoc/
 * License : IJG, GPL-2, BSD-2-Clause, PNG, bitstream, MIT-CMU,
GPL-2 with document exception, zlib, Apache-2.0, Apache-2.0 with
(L)GPL-2 exception
 * Vcs : [fill in URL of packaging vcs]
   Section : web

It builds those binary packages:

  htmldoc-common - Common arch-independent files for htmldoc
  htmldoc - HTML processor that generates indexed HTML, PS, and PDF

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/h/htmldoc/htmldoc_1.9.11-2.dsc

Changes since the last upload:

 htmldoc (1.9.11-2) unstable; urgency=medium
 .
   * Update build-dependency to libfltk1.3-dev Closes: #982276

Regards,
Håvard

Bug#981123: [diffoscope] diffoscope 166 released 💠

2021-02-08 Thread Holger Levsen

On Mon, Feb 08, 2021 at 05:55:04PM -, Chris Lamb wrote:
> That provides some of the contents of the directories; thanks. Can you
> also provide some of the contents of the "argv" files? These should
> contain the actual command-line passed to diffoscope and, as part of
> that, the crucial package name so that we can reproduce this locally.

see attached, that was generated by running this:

cd /tmp ; for i in $(du -sch diffo*|egrep 'M|G'|grep -v total |cut -b 5-) ; 
 do cat $i/argv > ${i}.argv_981123 ; done

IOW, the argv files of the biggest offenders :) All archlinux packages!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect." (Bruce Schneier)


argv.tgz
Description: application/gtar-compressed


signature.asc
Description: PGP signature

Bug#982317: ircd-hybrid: [INTL:pt] Updated Portuguese translation - debconf messages