Bug#981923: zookeeper: FTBFS with OpenJDK 17 due to ambiguous Record class

[Emmanuel Bourg]

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

zookeeper fails to build with OpenJDK 17 because it contains a Record class
that clashes with the new java.lang.Record class:

  build-generated:
  [javac] Using javac -source 1.6 is no longer supported, switching to 7
  [javac] Using javac -target 1.6 is no longer supported, switching to 7
  [javac] Compiling 57 source files to /<>/build/classes
  [javac] warning: [options] bootstrap class path not set in conjunction 
with -source 7
  [javac] warning: [options] source value 7 is obsolete and will be removed 
in a future release
  [javac] warning: [options] target value 7 is obsolete and will be removed 
in a future release
  [javac] warning: [options] To suppress warnings about obsolete options, 
use -Xlint:-options.
  [javac] 
/<>/src/java/generated/org/apache/zookeeper/data/ACL.java:25: 
error: reference to Record is ambiguous
  [javac] public class ACL implements Record {
  [javac] ^
  [javac]   both interface org.apache.jute.Record in org.apache.jute and 
class java.lang.Record in java.lang match
  [javac] 
/<>/src/java/generated/org/apache/zookeeper/data/Id.java:25: 
error: reference to Record is ambiguous
  [javac] public class Id implements Record {
  [javac]^
  [javac]   both interface org.apache.jute.Record in org.apache.jute and 
class java.lang.Record in java.lang match
  [javac] 
/<>/src/java/generated/org/apache/zookeeper/data/Stat.java:25: 
error: reference to Record is ambiguous
  [javac] public class Stat implements Record {
  [javac]  ^
  [javac]   both interface org.apache.jute.Record in org.apache.jute and 
class java.lang.Record in java.lang match
  [javac] 
/<>/src/java/generated/org/apache/zookeeper/data/StatPersisted.java:25:
 error: reference to Record is ambiguous
  [javac] public class StatPersisted implements Record {
  [javac]   ^

Bug#951921: vdr-plugin-xineliboutput: diff for NMU version 2.1.0+git20191101-1.1

[Adrian Bunk]

Control: tags 951921 + patch
Control: tags 951921 + pending

Dear maintainer,

I've prepared an NMU for vdr-plugin-xineliboutput (versioned as 
2.1.0+git20191101-1.1) and uploaded it to DELAYED/1. Please feel
free to tell me if I should cancel it.

cu
Adrian
diff -Nru vdr-plugin-xineliboutput-2.1.0+git20191101/debian/changelog vdr-plugin-xineliboutput-2.1.0+git20191101/debian/changelog
--- vdr-plugin-xineliboutput-2.1.0+git20191101/debian/changelog	2019-11-01 16:36:57.0 +0200
+++ vdr-plugin-xineliboutput-2.1.0+git20191101/debian/changelog	2021-02-05 09:21:31.0 +0200
@@ -1,3 +1,10 @@
+vdr-plugin-xineliboutput (2.1.0+git20191101-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fix for GLX FTBFS. (Closes: #951921)
+
+ -- Adrian Bunk   Fri, 05 Feb 2021 09:21:31 +0200
+
 vdr-plugin-xineliboutput (2.1.0+git20191101-1) unstable; urgency=medium
 
   * New Upstream Snapshot (commit 32a5ffc)
diff -Nru vdr-plugin-xineliboutput-2.1.0+git20191101/debian/patches/0001-configure-fix-GLX-check-when-using-pkg-config.patch vdr-plugin-xineliboutput-2.1.0+git20191101/debian/patches/0001-configure-fix-GLX-check-when-using-pkg-config.patch
--- vdr-plugin-xineliboutput-2.1.0+git20191101/debian/patches/0001-configure-fix-GLX-check-when-using-pkg-config.patch	1970-01-01 02:00:00.0 +0200
+++ vdr-plugin-xineliboutput-2.1.0+git20191101/debian/patches/0001-configure-fix-GLX-check-when-using-pkg-config.patch	2021-02-05 09:17:14.0 +0200
@@ -0,0 +1,42 @@
+From 21df3eed9745333c19f175b707df7da0963391c5 Mon Sep 17 00:00:00 2001
+From: Petri Hintukainen 
+Date: Thu, 2 Jul 2020 21:48:36 +0300
+Subject: configure: fix GLX check (when using pkg-config)
+
+---
+ configure | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/configure b/configure
+index b1138bb..1a443fd 100755
+--- a/configure
 b/configure
+@@ -238,6 +238,7 @@ FEATURES="
+   xrender
+   xshape
+   opengl
++  glx
+   pthread
+   dlfcn
+   vdpau
+@@ -345,6 +346,7 @@ check_deps(){
+   disabled vdr && disable libextractor libcap libbluray avahi-client
+   disabled dlfcn   && disable opengl
+   disabled pthread && disable opengl
++  disabled glx && disable opengl
+   disabled xrender && disable xshape xshm
+ }
+ 
+@@ -401,7 +403,8 @@ if enabled libxine; then
+ test_library X11  xshape   "X11/extensions/shape.h""-lXext"  "XShapeQueryExtension(0,0,0)"
+ test_library X11  xdpms"X11/extensions/dpms.h" "-lXext"  "DPMSDisable(0)"
+ test_library X11  xinerama "X11/extensions/Xinerama.h" "-lXinerama"  "XineramaQueryScreens(0,0)"
+-test_library X11  opengl   "GL/glx.h"  "-lGL -lGLU"  "glXQueryVersion(0,0,0)"
++test_library X11  opengl   "GL/gl.h"   "-lGL -lGLU"  "glTexCoord2f(0.0,0.0)"
++test_library X11  glx  "GL/glx.h"  "-lGLX"   "glXQueryVersion(0,0,0)"
+ test_library none vdpau"vdpau/vdpau_x11.h" "-lvdpau" "vdp_device_create_x11(0,0,0,0)"
+ test_library X11  dbus-glib-1  \
+   "dbus/dbus-glib.h" \
+-- 
+2.20.1
+
diff -Nru vdr-plugin-xineliboutput-2.1.0+git20191101/debian/patches/series vdr-plugin-xineliboutput-2.1.0+git20191101/debian/patches/series
--- vdr-plugin-xineliboutput-2.1.0+git20191101/debian/patches/series	2019-11-01 16:36:57.0 +0200
+++ vdr-plugin-xineliboutput-2.1.0+git20191101/debian/patches/series	2021-02-05 09:21:30.0 +0200
@@ -1 +1,2 @@
 disable-po-update.patch
+0001-configure-fix-GLX-check-when-using-pkg-config.patch

Bug#981922: irkerhook fails with mercurial and python 3

[Neil Muller]

Package: irker
Version: 2.18+dfsg-4
Severity: normal

Dear Maintainer,

irkerhook fails if run against mercurial using python 3.

With irkerhook set as a commit hook for testing, trying to commit a file
to a mercurial repo produces the following traceback

> error: commit.irker hook raised an exception: %b requires a bytes-like 
> object, or an object that implements __bytes__, not 'str'
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/mercurial/hook.py", line 117, in 
> pythonhook
> r = obj(ui=ui, repo=repo, hooktype=htype, **pycompat.strkwargs(args))
>   File "/usr/bin/irkerhook", line 442, in hg_hook
> extractor = HgExtractor([(ui, repo)])
>   File "/usr/bin/irkerhook", line 396, in __init__
> self.project = ui.config('irker', 'project')
>   File "/usr/lib/python3/dist-packages/mercurial/ui.py", line 609, in config
> value = self._config(
>   File "/usr/lib/python3/dist-packages/mercurial/ui.py", line 629, in _config
> msg %= (section, name)
> TypeError: %b requires a bytes-like object, or an object that implements 
> __bytes__, not 'str'


This has been fixed upstream - see
https://gitlab.com/esr/irker/-/commit/6e9372a2e297b0925d951d178ce39840d99277c6
- but not yet included in a release.

The 2 subsequent commits, fa0c06d9b51d758a4d41c99c0ea867cbda514cb7 &
ad8f8552bc8bb7ff31848ccdc729f79aa63e88aa alos look relevant as they
update irkerhook to recent mercurial changes.

-- System Information:
Debian Release: bullseye/sid
Architecture: i386 (x86_64)

Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages irker depends on:
ii  adduser   3.118
ii  lsb-base  11.1.0
ii  python3   3.9.1-1

irker recommends no packages.

irker suggests no packages.

-- no debconf information

--1612506787-eximdsn-675341442--

-- 
Neil Muller

Bug#980794: octave-iso2mesh: Arbitrary limitation of build architectures

[Rafael Laboissière]

Hi all,

Thanks to Adrian Bunk, Adrian Glaubitz, and Sébastien for the 
clarifications in this thread.


The discussion regarding the current Bug#980794 was triggered by my 
decision of limiting the set of architectures of package octave-iso2mesh. 
I agree that this hammer-like solution (in Adrian Glaubitz's words) is 
not the right thing to do and I will revert the change (and hence close 
this bug report).


However, we will get back to the previous situation, in which the 
autobuild of the package was failing systematically on armel, armhf and 
mipsel. If I understand correctly, the right way to cope with the issue 
is to contact individually the maintainers of each architecture with 
FTBFS and ask them to upload a correctly built binary package. This will 
have to be done for each new release of the package. Of course, I find 
this very counterproductive and time consuming. If there is no better way 
of coping with the problem, then we will have to stick to this 
sub-optimal solution, unless you see other ways of proceeding.


Best,

Rafael

* Sébastien Villemot  [2021-02-03 22:03]:


Dear Qianqian,

Le mercredi 03 février 2021 à 13:24 -0500, Qianqian Fang a écrit :

On 2/1/21 4:10 AM, Adrian Bunk wrote:

Physical RAM or disk space are not the problem, the problem is the
virtual address space of processes on 32bit architectures.

On mipsel, where every process has 2 GB of address space, both 
"g++ -O0 -g0" and "clang++ -O0 -g0" fail because they run out 
of address space.


For Debian testing migration purposes it only matters whether stale old 
binaries are in the archive, for that it does not make any difference 
whether binaries are missing due to architecture restrictions or FTBFS.


thanks for the comment, can you clarify a little bit more? are you 
suggesting us to remove the arch restriction or exclude all i386 
platforms? sorry it wasn't very clear to me.


What Adrian means is that you have to request the removal of the old 
armhf binary from unstable, otherwise the latest version of octave- 
iso2mesh won’t migrate to testing. Restricting the architecture list 
does not automatically remove the old binaries. As far as I can see, 
the removal request has not yet been done (the one Rafael mentioned is 
about another package).


More generally, it is true that restricting the architecture list is 
usually not the right thing to do. Making build failures visible is 
always more helpful to the porters.


There might however be one situation in which the restriction may make 
sense: if the failures are random. Because once a build succeeds on a 
release architecture, then subsequent failures prevent migration to 
testing until the binary has been removed from unstable. But I don’t 
know if octave-iso2mesh is in that situation.


--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org

Bug#978099: libhdf4: Please add support for riscv64

[Graham Inggs]

On Fri, 5 Feb 2021 at 08:30, Sebastiaan Couwenberg  wrote:
> No, riscv64 is not a release architecture and the soft freeze is next
> week. Ubuntu will have to carry this patch a little longer.

Ack, thanks.

Bug#445047: Irssi handling of IPv6 servers idiosyncratic

[Witold Baryluk]

Package: irssi
Version: 1.2.2-2+b1
Followup-For: Bug #445047
X-Debbugs-Cc: witold.bary...@gmail.com

Hi.

This still appears to be broken:

[(status)] /connect localhost 6697
06:40 -!- Irssi: Connection lost to localhost
06:40 -!- Irssi: Looking up localhost
06:40 -!- Irssi: Connecting to localhost [127.0.0.1] port 6697
06:40 -!- Irssi: Connection to localhost established



This is wrong, it should connect to ::1

Same with external servers, irssi still preferse IPv4 for some reasons.

Regards,
Witold


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

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

Versions of packages irssi depends on:
ii  libc6   2.31-9
ii  libglib2.0-02.66.4-1
ii  libperl5.32 5.32.0-6
ii  libssl1.1   1.1.1i-3
ii  libtinfo6   6.2+20201114-2
ii  perl5.32.0-6
ii  perl-base [perlapi-5.32.0]  5.32.0-6

irssi recommends no packages.

Versions of packages irssi suggests:
pn  irssi-scripts  

-- no debconf information

Bug#978099: libhdf4: Please add support for riscv64

[Sebastiaan Couwenberg]

On 2/5/21 7:10 AM, Graham Inggs wrote:
> Any chance of an upload soon?

No, riscv64 is not a release architecture and the soft freeze is next
week. Ubuntu will have to carry this patch a little longer.

Kind Regards,

Bas

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

Bug#981835: ugly workaround

[Petko Angelov]

I was in the same situation this morning but this help me to install the
libelf1:i386

/sudo mv /usr/share/locale/en@quot/LC_MESSAGES/elfutils.mo
/usr/share/locale/en@quot/LC_MESSAGES/elfutils.mo-back //
/

Bug#978099: libhdf4: Please add support for riscv64

[Graham Inggs]

Hi Maintainers

Any chance of an upload soon?

Regards
Graham

Bug#981920: dvd+rw-tools: please, remove me from the uploaders field

[Rogério Brito]

Package: dvd+rw-tools
Version: 7.1-14+b1
Severity: normal

Hi.

I am still listed as one of the uploaders of this package. I would love to
still have the credits under debian/copyright etc., but I would like to
request two things, if possible:

1 - That my email address rbr...@ime.usp.br is changed to rbr...@gmail.com,
as I will be losing access to the @ime.usp.br address in the very near
future ☹.

2 - If I were dropped from the Maintainer/Uploaders field of the package.


Thanks in advance,

Rogério Brito.

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

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

Versions of packages dvd+rw-tools depends on:
ii  genisoimage  9:1.1.11-3.1
ii  growisofs7.1-14+b1
ii  libc62.31-9
ii  libgcc-s1 [libgcc1]  10.2.1-6
ii  libstdc++6   10.2.1-6

dvd+rw-tools recommends no packages.

Versions of packages dvd+rw-tools suggests:
pn  cdrskin  

-- no debconf information

-- 
Rogério Brito : rbrito@{users.sf.net,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : salsa.debian.org/rbrito : 
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40gmail.com

Bug#981919: 981919: remove mkdirp-classic as well

[Andrius Merkys]

Hello,

mkdirp-classic can also be removed, as it has been packaged as
node-mkdirp-classic. I assume it is embedded here only because of tar-fs.

Andrius

Bug#981919: node-yarnpkg: use Debian-provided node-tar-fs

[Andrius Merkys]

Source: node-yarnpkg
Version: 1.22.10+~cs22.25.14-2

node-yarnpkg embeds tar-fs, which has been recently packaged as
node-tar-fs. Please consider using the Debian package instead the
embedded source.

Andrius

Bug#981911: RFS: molotov/1.0 -- bootable media creator from a Windows 10 image

[Cézar]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: molotov
   Version : 1.0
   Upstream Author : Cézar Augusto de Campos 
 * URL : https://github.com/cizordj/molotov
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/debian/molotov
   Section : misc

It builds those binary packages:

  molotov - bootable media creator from a Windows 10 image

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/m/molotov/molotov_1.0.dsc

Changes for the initial release:

 molotov (1.0) unstable; urgency=medium
 .
   * Initial Release.

I created molotov in order to make it easier for people to create bootable
USB drives from a Windows 10 iso image, it is a command line utility that
follows the Gnu coding standards and is made specifically for Debian. The
reason I did this is because there is no such programs available for Linux
that does this kind of stuff and if there is, these programs are distributed
in third-party repositories such as PPAs. Installing programs from such
repositories is considered unsafe and shall not be done on a sane Debian
installation.
The Molotov is quite small and only depends on Debian's native programs.

Regards,
--
  Cézar Augusto de Campos

Bug#981867: Info received ()

[Bapi Dey]

Nvidia Driver has nothing to do with loginctl. I just uninstalled nvidia
driver and use nouveau driver. Same problem happening. Tested with popOS
20.04. Problem is in systemd.

Bug#978729: ERROR build/debian-cd: E: The value 'unstable' is invalid for APT::Default-Release as such a release is not available in the sources when building buster image

[Vagrant Cascadian]

Control: reassign 978729 debian-cd

On 2020-12-31, Daniel Leidert wrote:
> I'm trying to build a custom Buster image. The host system is a Debian
> Sid/unstable. When I run the build right after "make image-tree" is invoked in
> /usr/share/simple-cdd/tools/build/debian-cd
>
> ERROR build/debian-cd: E: The value 'unstable' is invalid for 
> APT::Default-Release as such a release is not available in the sources when 
> building buster image
>
> because my local apt.conf has the default value set to 'unstable'. But my 
> local
> APT configuration IMHO shouldn't be of any concern to simple-cdd or debian-cd.
> So I have to edit this file to make it work. Maybe it should create a 
> temporary
> apt.conf setting APT::Default-Release to the value used for the --dist switch?

Reassigning to debian-cd, as simple-cdd is just calling debian-cd's
"make image-tree".

It might be possible for simple-cdd to workaround this or provide hooks
to workaround it, but seems better to have debian-cd not depend on local
apt configuration...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#981867: Info received ()

[Bapi Dey]

I used debian bullseye alpha 3 netboot version with nvidia-driver. Problem
persist.

Bug#981867: Info received ()

[Bapi Dey]

Yes picture is taken on Ubuntu, but I also tried on Debian, and I
experienced same thing. Also note I am currently using popOS, facing same
issue.

when a user logged out with nvidia attached seat the entire system forced
to logged out. It might be bug in loginctl.

Bug#981916: RM: apertium-ukr -- ROM; RC Buggy, obsolete by apertium-rus-ukr now

[Kartik Mistry]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: kar...@debian.org

Dear FTP Team,

Please remove apertium-ukr package from unstable. It is RC buggy and now
upstream has decoupled it by removing its dependency from apertium-rus-ukr
which is just accepted in unstable.

Thanks,
Kartik

Bug#981006: No way of adding task packages with dependencies (necessary for tasksel) - packages listed in .download should be included with their dependencies

[Vagrant Cascadian]

On 2021-01-25, Daniel Leidert wrote:
> Hm. Maybe strike that. I misread some recommended packages as depends. But
> still overwriting
>
> tasksel tasksel/first multiselect standard

I added this to a profiles/misc.preseed file:

  tasksel   tasksel/first multiselect
  tasksel   tasksel/first seen false
  tasksel   tasksel/tasks multiselect
  tasksel   tasksel/tasks seen false

And then it prompted for the tasksel tasks. It only displayed standard,
which the built iso image had all the dependencies for. This might be
worth testing a bit more and fleshing out the option. There's also a
tasksel/desktop that might be needed to get the desktop profiles
enabled; not sure exactly how that works.


> fails without a mirror set up. So I'm guessing some missing packages. I'm
> trying to debug this further.

Yeah, you'll need to specify all the packages the tasksel task needs to
make sure they're on the install media.

Packages in .downloads are somewhat treated like recommends; e.g. add
them to the install media if possible, but don't fail if they aren't
available.

Overall, profiles/*.packages are used to select packages to install with
simple-cdd instead of tasksel tasks.


I had looked into being able to specify tasksel tasks many, many years
ago and it was too complicated at the time... the idea was to create
profiles/*.tasks and then it would look up the required packages and add
them to the install media. Never figured out how to do that, and it is a
bit redundant with the simple-cdd profiles. Maybe someone else has a
better idea how to implement it or the tasksel code has changed to make
it easier now?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#981746: ftp.debian.org: decision to treat OpenSSL as a system library for GPLv2 is not in compliance with copyright holders' wishes

[brian m. carlson]

On 2021-02-04 at 13:00:39, Ansgar wrote:
> No, as far as I understand it the GNU Runtime Library Exception doesn't
> allow distributing the *source code* under terms compatible with the
> GPL-2, but that would be a requirement of the GPL-2-licensed software.
> 
> But the GCC Runtime Library Exception cannot remove the requirement
> for doing so from GPL-2-licensed software.

That's true.  I suppose it would be appropriate to ask for an exception
from the FSF.  It seems that a compiler that can't be used to ship GPLv2
code would have a serious defect.

> The GCC runtime libraries are under GPL-3 which is deliberately
> incompatible with respect to the GPL-2, see [1].
> 
> So to me asking Debian to not rely on the system library exceptions
> requires to at least:
> 
>  (1) Remove all GPL-2-licensed software (GPL-2-or-later would be okay)
>  that uses any GCC runtime library. And/or replace GCC.
> 
>  (2) Remove all GPL-2-licensed software that uses OpenSSL.
> 
>  (3) I think there might be more similar cases which would also need to
>  be dealt with.
> 
> This looks like a very disruptive change.

It does indeed look disruptive.  But I think the first step would be to
ask the FSF for an exception for (1), which would likely solve the
problem there.  In the case of (2), I think most of that software is
already using GnuTLS or Nettle or something else, so mostly it's already
in a good state.  So I think this might end up being a lot less
disruptive than originally thought.  Remember, in the case of (2), this
was already Debian's position until March 2020, so a lot of this
software is already correctly configured.

It's also possible that you could ask OpenSSL to reconsider their
position on the GPLv2 or add an exception to the Apache License 2.0 like
LLVM did, which would avoid the problem for OpenSSL.  You could then
upgrade to OpenSSL 3.0 when it comes out, which would solve the problem.

> On the other side Debian has tolerated (1) forever (or at least since
> GPL-3 and this particular problem exist) and even (2) for a far longer
> time than it seems as languages that use `dlopen()` instead of linking
> information in binary objects, were tolerated.  OpenSSL is for example
> pretty widely used in Python, including GPL-2-only projects.  (Writing
> `import something_using_ssl` vs `-lsomething_using_ssl` is a small
> technical difference, but both end up instructing the runtime linker to
> load some library.)

I see case (2) as being a case where Python and OpenSSL need license
compatibility, which they have.  The problem would be linking a GPLv2
library into Python at the same time as OpenSSL.  That's always been my
view, at least.

> So Debian could also treat OpenSSL the same as GCC runtime libraries and
> as it already does for other ways to link OpenSSL.  Other distributions
> like Fedora seem to do the same.  Some distributions do even more
> controversial things (ZFS on Ubuntu?)

The intent of this passage in the GPLv2 was to explicitly prohibit OS
distributors from shipping GPLv2 software linked against incompatible
libraries (specifically, proprietary Unix vendors from shipping GNU
utilities linking against a proprietary libc).  So this was literally
the intended interpretation of the text.

And unfortunately, I'm seeing people use Debian and Fedora's position to
link GPLv2 code to which I've contributed to OpenSSL without permission.
People say, "Debian and Fedora do it, therefore so can I," which is a
problem.

I appreciate that it's not your fault that this came to my attention,
but it did, and even if it's inconvenient, I'm asking you to do the
right thing by the authors and copyright holders of the software.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US


signature.asc
Description: PGP signature

Bug#981915: netkit-tftp: Please depend on xinetd instead of openbsd-inetd

[Logan Rosen]

Package: netkit-tftp
Version: 0.17-23
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi,

As described in this Launchpad bug [1], there are/were issues between
openbsd-inetd and netkit-tftp in terms of the correct tsize being
reported from the client to the server. Changing the dependency to
xinetd addressed these issues in Ubuntu.

It's possible that this is no longer relevant/needed, but I wanted to
forward it so that we can see if it makes sense for Debian/so that we
can drop our delta in Ubuntu.

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/control: Change dependency from openbsd-inetd to xinetd
so correct size is reported

Thanks for considering the patch.

Logan
diff -Nru netkit-tftp-0.17/debian/control netkit-tftp-0.17/debian/control
--- netkit-tftp-0.17/debian/control 2018-12-13 14:43:29.0 -0500
+++ netkit-tftp-0.17/debian/control 2021-02-04 21:33:20.0 -0500
@@ -17,7 +18,7 @@
 
 Package: tftpd
 Architecture: any
-Depends: openbsd-inetd | inet-superserver, ${shlibs:Depends}, ${misc:Depends}
+Depends: xinetd | inet-superserver, ${shlibs:Depends}, ${misc:Depends}
 Replaces: netstd
 Description: Trivial file transfer protocol server
  Tftpd is a server which supports the Internet Trivial File Transfer Protocol

Bug#981914: netkit-tftp: Please include Homepage field in debian/control

[Logan Rosen]

Package: netkit-tftp
Version: 0.17-23
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi,

The debian/control file for netkit-tftp does not currently contain a
Homepage field.

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/control: Added Homepage field.

Thanks for considering the patch.

Logan
diff -Nru netkit-tftp-0.17/debian/control netkit-tftp-0.17/debian/control
--- netkit-tftp-0.17/debian/control 2018-12-13 14:43:29.0 -0500
+++ netkit-tftp-0.17/debian/control 2021-02-04 21:33:20.0 -0500
@@ -3,6 +3,7 @@
 Priority: optional
 Maintainer: Alberto Gonzalez Iniesta 
 Standards-Version: 4.2.1
+Homepage: http://www.hcs.harvard.edu/~dholland/computers/netkit.html
 Build-Depends: debhelper (>= 11), cmake
 
 Package: tftp

Bug#981913: ITP: ognibuild -- Wrapper with common interface for invoking any kind of build tool

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ognibuild
  Version : 0.0.1
  Upstream Author : Jelmer Vernooij
* URL : https://github.com/jelmer/ognibuild
* License : GPL
  Programming Lang: Python
  Description : Wrapper with common interface for invoking any kind of 
build tool

Ognibuild is a simple wrapper with a common interface for invoking any kind of
build tool.

The ideas is that it can be run to build and install any source code directory
by detecting the build system that is in use and invoking that with the correct
parameters.

It can also detect and install missing dependencies.

(This code is currently a part of the Debian Janitor, and being factored
out)

Bug#964914: Additional info.

[Borden]

I don't suppose anyone has seen fit to address this bug or provide a 
workaround? Is there a setting we can change in config/ that will fix this? I 
can't find it.

Bug#962042: smuxi-frontend-gnome: clicking on a link does not open it in the web browser

[Mirco Bauer]

Hi,

[reply inline]

On Thu, 4 Feb 2021, 16:09 Raphael Hertzog,  wrote:

> Hi,
>
> On Thu, 04 Feb 2021, Mirco Bauer wrote:
> > The fix is Smuxi's upstream git repo [0] and will be landing Debian
> > unstable with the upcoming Smuxi 1.1 release in a few days.
>
> Nice! But it might be late to get into bullseye without asking for an
> unblock...
>

To my knowledge the general freeze is on the 12th of February, so I aim to
get 1.1 out and uploaded asap.


> > Hope this restores the Smuxi user experience for you and others :)
>
> To really restore a good user experience, https://bugs.debian.org/962290
> would have to be fixed too. :-)
>

Thanks for reminding me about that weird issue. That is a super bad bug! I
suspect a bug in the dbus library or the mono runtime. Smuxi does a lot of
processing in the background (if the operation leads to a blocking call to
the smuxi-server for example)...

Best,

Mirco


> Cheers,
> --
>   ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
>   ⣾⠁⢠⠒⠀⣿⡁
>   ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
>   ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
>

Bug#981912: libsdes4j-java: provoked IDS to block download thinking it's Unix.Trojan.Chalubo

[Martin Dorey]

Package: libsdes4j-java
Version: 1.1.4-1.1
Severity: normal

Dear Maintainer,

This isn't a bug in the package, just a warning about a problem getting the 
package.
Our debmirror job has been failing:

 Download of pool/main/s/sdes4j/libsdes4j-java-doc_1.1.4-1.1_all.deb failed: 
500 Status read failed: Connection reset by peer
 Download of pool/main/s/sdes4j/libsdes4j-java_1.1.4-1.1_all.deb failed: 500 
Status read failed: Connection reset by peer

And our intrusion detection system (name and vendor unknown to me) has been 
firing off alerts like:

Total Alerts in Database:  3058

Last Email Time: 2021-02-03 17:20:02
Current Time:2021-02-03 17:25:02

Total New Alerts: 1
Filter Matching : 1

++
Alerts (shown: 1/available: 1) (limit: 50)
++
Device : 
Timestamp: 2021-02-03 17:23:16
Protocol : tcp
Alert Message: MALWARE-CNC Unix.Trojan.Chalubo downloader connection 
(1:48281:3)
Session  : :37596 -> 64.50.233.100:80

[*] 0 more events originated from this Source IP

+---+
| Destination Port  Count
+---+
   80  1

+---+
|   Source IP  Count
+---+

   1

Experimenting with manual downloads of eg http://google.com/libsdes suggests 
that any URL containing libsdes is blocked.
Using https appears to be a work around.


-- System Information:
Debian Release: 9.12
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable'), (500, 
'oldstable-debug'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-12-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libsdes4j-java depends on:
ii  libcommons-codec-java  1.10-1

libsdes4j-java recommends no packages.

Versions of packages libsdes4j-java suggests:
pn  libsdes4j-java-doc  

Bug#825864: News about packagint

[Borden]

If Debian is going to let this languish for a half decade, is there at least a 
compiled deb or a workaround that we can install ourselves?

Seems a little odd to me that a standard like this would still not be 
implemented in Debian.

Bug#947261: ITP: python-poetry -- Python dependency management and packaging made easy

[Emmanuel Arias]

On Thu, Feb 04, 2021 at 09:49:44AM +0100, Christian Kastner wrote:
> Hi Emmanuel,
> 
> On 23.12.19 20:16, Emmanuel Arias wrote:
> > * Package name    : python-poetry
> 
> > Poetry helps you declare, manage and install dependencies of Python
> > projects, ensuring you have the right stack everywhere.
> > .
> > This package will be maintained as part of the Debian Python modules team.
> 
> I was happy to see that poetry-core was recently accepted ftp-master,
> and wanted to see how this package is progressing. Is there anything you
> could use help with?
>
Hi thanks for write me.

Yes please, I need some help finishing the packaging.
Currenlty, is failing a test, seems to be a incompatibility
on the pytest-mock, so fail a test that use `from pytest_mock.plugging
import MockFixture`.

In the other hand, would be great if we can package documentation.

For build the poetry, currenlty, you'll need build locally some packages that
are not in Debian yet. You can run sbuild in this way:

`gbp buildpackage --git-ignore-new 
--extra-package=/home/eamanu/Debian/DEPENDENCIES/python3-cleo_0.8.1-1_all.deb 
--extra-package=/home/eamanu/Debian/DEPENDENCIES/python3-clikit_0.6.2-1_all.deb 
--extra-package=/home/eamanu/Debian/DEPENDENCIES/python3-crashtest_0.3.1-1_all.deb
 
--extra-package=/home/eamanu/Debian/DEPENDENCIES/python3-pastel_0.2.1-1_all.deb 
--extra-package=/home/eamanu/Debian/DEPENDENCIES/python3-pylev_1.2.0-1_all.deb 
--extra-package=/home/eamanu/Debian/DEPENDENCIES/python3-shellingham_1.3.2-1_all.deb`

Please, if you need anything more please contact me.

Thanks for the help

Best,
Emmanuel
> Best,
> Christian

Bug#981804: yubioath-desktop: fails to read yubikey

[Norbert Preining]

Hi Nicoo,

> > — 
> > https://github.com/Yubico/yubioath-desktop/issues/693#issuecomment-773096570

Thanks for the info, that helps a lot. I will downgrade for the time
being.

Thanks for all you work on that!

Best

Norbert

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

Bug#981910: tracker.debian.org: please display key status for packages

[Carles Pina i Estany]

Hi,

I'm a bit new in the internals of tracker and around. Would this be the
best source for the list of "key" packages?
https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Or some other URL would be a better place?

Cheers,

Carles

On Feb/05/2021, Adam Borowski wrote:
> Package: tracker.debian.org
> Severity: wishlist
> 
> Hi!
> Looking up if a given package is "key" (in Release Team sense) is currently
> pretty tedious.  Could you please mention this on packages' pages?
> 
> 
> Meow!
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
> (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.11.0-rc6-00069-gc78e0fad19ee (SMP w/64 CPU threads)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
-- 
Carles Pina i Estany
https://carles.pina.cat

Bug#981910: tracker.debian.org: please display key status for packages

[Adam Borowski]

Package: tracker.debian.org
Severity: wishlist

Hi!
Looking up if a given package is "key" (in Release Team sense) is currently
pretty tedious.  Could you please mention this on packages' pages?


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

Kernel: Linux 5.11.0-rc6-00069-gc78e0fad19ee (SMP w/64 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#851650: How does moving XSL stuff fix misbuild PAM manpages

[Sam Hartman]

> "Adam" == Adam Borowski  writes:

Adam> Well, the problem I was fixing was patches not being applied
Adam> -- which obviously broke installability.

I understand now and regret my previous frustration.
Thanks for working with me.

So, it seems like we have a couple directions we could go.

1) Build the man pages all the time and get the dates right.

Advantages: building from source always.

disadvantages: getting the date right, and increasing the set of
dependencies for bootstrapping etc.

2) Build the man pages in the source.

advantages: faster build times, smaller build dependencies.

disadvantages: Annoying developer experience, we don't build from source
all the time.

For now, I've documented option 2 in README.source, mostly because Steve
expressed that preference earlier in the bug.

I don't know if the current patches actually include built versions of
all our man page changes, so I'm definitely not going to back out the
build-depends changes.

--Sam

Bug#981850: [DRE-maint] Bug#981850: Failed: rspec-core, rspec-support

[Antonio Terceiro]

On Thu, Feb 04, 2021 at 09:02:37PM +0530, Ritesh Raj Sarraf wrote:
> Package: ruby-rspec
> Version: 3.9.0c2e2m1s3-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source
> 
> Dear Maintainer,
> 
> During a rebuild of the package for Bullseye, it is seen that the
> package fails to build. The build failure snippet is below. It is also
> noticed that the same build failure is seen on the Reproducible Builds.
> 
> ```
> [  294s] Finished in 2.23 seconds (files took 0.50425 seconds to load)
> [  294s] 538 examples, 3 failures, 1 pending
> [  294s]
> [  294s] Failed examples:
> [  294s]
> [  294s] rspec ./spec/rspec/support/differ_spec.rb:315 # 
> RSpec::Support::Differ#diff outputs unified diff message of two hashes with 
> differing encoding
> [  294s] rspec ./spec/rspec/support/differ_spec.rb:328 # 
> RSpec::Support::Differ#diff outputs unified diff message of two hashes with 
> encoding different to key encoding
> [  294s] rspec ./spec/rspec/support/differ_spec.rb:158 # 
> RSpec::Support::Differ#diff uses the default external encoding when the two 
> strings have incompatible encodings
> [  294s]
> [  294s] Randomized with seed 8873
> [  294s]
> [  295s] cd -
> [  295s] Failed: rspec-core, rspec-support
> [  295s] ERROR: Test "ruby2.7" failed. Exiting.
> [  295s] dh_auto_install: error: dh_ruby --install 
> /usr/src/packages/BUILD/debian/tmp returned exit code 1
> [  295s] make: *** [debian/rules:99: binary] Error 25
> [  295s] dpkg-buildpackage: error: debian/rules binary subprocess returned 
> exit status 2
> ```

Can you please share more information about the environment where you
did this build?

I can reproduce a test failure with a non-UTF-8 locale, is that the
case?


signature.asc
Description: PGP signature

Bug#981669: Info received (Bug#981669: gettext: incorrect build dependencies for nojava architectures)

[Santiago Vila]

On Thu, Feb 04, 2021 at 06:19:53PM -0500, John David Anglin wrote:
> On 2021-02-04 3:03 p.m., Aurelien Jarno wrote:
> > Le 04/02/2021 à 16:46, John David Anglin a écrit :
> >> According to , nojava is 
> >> supposed to be a registered
> >> profile name.  However, it doesn't work for Debian ports.  Something must 
> >> need to be setup.
> >>
> >> The problem can be seen in the buildd status for gettext:
> >> https://buildd.debian.org/status/package.php?p=gettext=sid
> >>
> >> Thoughts?
> >
> > The buildds are not supposed to use any build profile, so this all looks 
> > normal to me. build profiles are used for bootstrapping, manual
> > building or derivatives.
> Thus, the [!hppa] target selector needs to be added in various places in the 
> control file, etc.

It may be argued that unreleased architectures are still in the
process of being bootstrapped. Therefore, it would make sense that
things like "nojava" are managed in a centralized way so that they
become automatic in cases like this one.

Thanks.

Bug#976462: Bug#631985: Compress debug

[Josh Triplett]

On Mon, 25 Jan 2021 12:01:02 -0700 Sean Whitton  
wrote:
> On Mon 07 Nov 2011 at 06:34PM +01, Bastien ROUCARIES wrote:
> > I agree it could be done by default with compat 9. Will decrease the
> > size of archive also. I need more than 10G in order to debug kde...
> 
> Does this sort of thing still apply in 2021?

Yes.

Apart from the running joke that the persistent state of most disks is
"full", this remains relevant because it can make the difference between
"leave the debug symbols installed, keep them updated, and be able to
debug quickly the next time" versus "install debug symbols, debug,
remove debug symbols until they're next needed".

- Josh Triplett

Bug#969516: Please support installing onto f2fs root filesystem

[Stephan Lachnit]

> I would be willing to sponsor this but I'm not sure whether such
> a change would be a good idea a little over a week from the soft
> freeze.

Can you sponsor the upload [1] already? This won't add the package
to the installer, but we will decide to have it include in bullseye
(which I really hope), we better upload it ASAP to NEW.

Regards,
Stephan

[1] https://mentors.debian.net/package/partman-f2fs/

Bug#981669: Info received (Bug#981669: gettext: incorrect build dependencies for nojava architectures)

[John David Anglin]

On 2021-02-04 3:03 p.m., Aurelien Jarno wrote:
> Le 04/02/2021 à 16:46, John David Anglin a écrit :
>> According to , nojava is supposed 
>> to be a registered
>> profile name.  However, it doesn't work for Debian ports.  Something must 
>> need to be setup.
>>
>> The problem can be seen in the buildd status for gettext:
>> https://buildd.debian.org/status/package.php?p=gettext=sid
>>
>> Thoughts?
>
> The buildds are not supposed to use any build profile, so this all looks 
> normal to me. build profiles are used for bootstrapping, manual
> building or derivatives.
Thus, the [!hppa] target selector needs to be added in various places in the 
control file, etc.

Regards,
Dave

-- 
John David Anglin  dave.ang...@bell.net

Bug#851650: How does moving XSL stuff fix misbuild PAM manpages

[Adam Borowski]

On Thu, Feb 04, 2021 at 05:28:41PM -0500, Sam Hartman wrote:
> > "Adam" == Adam Borowski  writes:
> 
> Adam> I think we should _always_ trigger a rebuild, to make sure the
> Adam> source we provide is the real source.
> 
> I'm really incredibly frustrated reading the above.
> I doubt that was your intent, but here's what happened from my
> standpoint.
> 
> I asked how your patch actually gets multiarch installability.
> It sounds like  it might happen to work   if all the binaries got built
> on the same day.
> But I don't think your change is guaranteed to work and I was trying to
> figure out if I was right.
> 
> Instead of working with me to figure out if your patch actually does
> guarantee multi-arch installability, you talked about your preferences
> for building source.
>
> Would you be willing to work with me to  figure out whether your patch
> actually guarantees multiarch installability.

Well, the problem I was fixing was patches not being applied -- which
obviously broke installability.

At the time (in 2016) I indeed did not take different build dates into
account, my bad.  That's another problem that may break multiarch.

As to dates: I'd give --date to pod2man


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄ `

Bug#981909: debci: ci.debian.net does not show all results

[Robert Luberda]

Package: debci
Severity: normal

Hi

My DDPO page contains a link to 
https://ci.debian.net/packages/s/sysstat/testing/amd64/ 
which currently has two build logs displayed in grey color (versions 12.5.2-2 
and 12.5.2-1
from unstable were tested against packages in testing):

  Version   Date   Trigger/Pinned packages  
  12.5.2-2  2021-02-03 09:37:11 UTCsysstat/12.5.2-2   
   src:sysstat from unstable
  12.5.2-1  2021-01-31 05:07:28 UTCsysstat/12.5.2-1
   src:sysstat from unstable

(note I stripped the other data to have the above lines shorter)

However the link to the above page is not shown on the the main page 
for sysstat at https://ci.debian.net/packages/s/sysstat/, which
currently contains:

  unstabletesting stable  oldstable
  amd64   12.5.2-1 fail   No test dataNo test dataNo test data
  arm64   12.5.2-1 fail   No test dataNo test dataNo test data
  armhf   No test dataNo test dataNo test dataNo test data
  i38612.5.2-1 fail   No test dataNo test dataNo test data
  ppc64el No test dataNo test dataNo test dataNo test data
  s390x   No test dataNo test dataNo test dataNo test data 

This means that to see for example results of run of systat 12.5.2 from
unstable against packages in testing for architectures other than amd64,
I need to manually change the link provided on my DDPO page. I can see
that such links point to valid pages, e.g. 
https://ci.debian.net/packages/s/sysstat/testing/i386/
https://ci.debian.net/packages/s/sysstat/testing/ppc64el/
so why not to provide access to them from the main index page for
package?

Regards,
robert

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Jan Korbel]

Dear Debian developers, maintainers etc.

I use Debian for many years. My primary and only installation for work
is unstable installed in 2003 and i updated this one *many times*. I
love Debian because of freedom from more points of view.

One PoV is possibility to choose software component which i prefer.
Because i don't like systemd (other story) i use sysvinit not on my
computer only but on many our servers too. My fault is, they are
without popcon, so not in stats (will fix it, i promise).

When i read about maintainer which broke thing (on my system too) and
rejected fix because... i still don't know why, i feel very sad. I
don't think this is a fair community work which is great otherwise.

So thanks Matthew and others they did not throw us overboard. I use
orphan-sysvinit-scripts now. Not best solution imho, but it is others
fault. Shame.

Sorry for some emotions and peace.

Regards,

J.

Bug#851650: How does moving XSL stuff fix misbuild PAM manpages

[Sam Hartman]

> "Adam" == Adam Borowski  writes:

Adam> I think we should _always_ trigger a rebuild, to make sure the
Adam> source we provide is the real source.

I'm really incredibly frustrated reading the above.
I doubt that was your intent, but here's what happened from my
standpoint.

I asked how your patch actually gets multiarch installability.
It sounds like  it might happen to work   if all the binaries got built
on the same day.
But I don't think your change is guaranteed to work and I was trying to
figure out if I was right.

Instead of working with me to figure out if your patch actually does
guarantee multi-arch installability, you talked about your preferences
for building source.

Would you be willing to work with me to  figure out whether your patch
actually guarantees multiarch installability.

--Sam

Bug#851650: How does moving XSL stuff fix misbuild PAM manpages

[Adam Borowski]

On Wed, Feb 03, 2021 at 12:20:25PM -0500, Sam Hartman wrote:
> In your NMU of pam 1.1.8-3.4, you moved the xsl build dependencies from
> build-depends-indep to build-depends.
> 
> This effectively enables rebuilding of man pages even for binary package
> builds.

Yes, as they are included in arch:any binaries.

> It looks like the goal was to work around problems in
> multi-arch installability.
> 
> But I don't see how it does that.  I'm assuming the problem is a date in
> the resulting man page or similar.
> 
> There's definitely a date in the nroff files.
> If all the binaries happened to get built on the same date, perhaps
> you'd get something that is multi-arch installable.

There's more than just date -- our patches weren't applied.

> But for example if there is a binnmu on one arch, it seems like things
> would break.
> 
> Why is this the right thing to do?  It seems like Steve's proposed
> solution in #851650 is a better solution.  In particular, make sure that
> patches to man pages include patches both to the nroff and xml so we
> never trigger a rebuild.

I think we should _always_ trigger a rebuild, to make sure the source we
provide is the real source.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄ `

Bug#981908: buildah: does not install on testing/bullseye

[Holger Fischer]

Package: buildah
Version: 1.18.0+dfsg1-2
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

 tried to install buildah with other packages via apt

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

 "apt update"

 followed by a 
 
 "apt install podman buildah skopeo"

   * What was the outcome of this action?

 apt install podman buildah skopeo
 Reading package lists... Done
 Building dependency tree
 Reading state information... Done
 Some packages could not be installed. This may mean that you have
 requested an impossible situation or if you are using the unstable
 distribution that some required packages have not yet been created
 or been moved out of Incoming.
 The following information may help to resolve the situation:

 The following packages have unmet dependencies:
  golang-github-containers-common : Breaks: buildah (< 1.18.0+dfsg1-3~~) 
but 1.18.0+dfsg1-2 is to be installed
 E: Unable to correct problems, you have held broken packages.

   * What outcome did you expect instead?

   a succesful installation of podman buildah and skopeo


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

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

Versions of packages buildah depends on:
ii  libc6   2.31-9
ii  libdevmapper1.02.1  2:1.02.175-2
ii  libglib2.0-02.66.4-1
ii  libgpgme11  1.14.0-1+b2
ii  libostree-1-1   2020.8-2
ii  libseccomp2 2.5.1-1
ii  libselinux1 3.1-2+b2
pn  uidmap  

Versions of packages buildah recommends:
pn  crun | runc 
pn  fuse-overlayfs  

Versions of packages buildah suggests:
pn  containers-storage  

Bug#981745: ser2net: breaks existing configuration on upgrades

[Corey Minyard]

On Thu, Feb 04, 2021 at 09:10:40AM -0300, Antonio Terceiro wrote:
> On Thu, Feb 04, 2021 at 08:30:58AM +0100, Marc Haber wrote:
> > On Wed, Feb 03, 2021 at 12:27:52PM -0600, Corey Minyard wrote:
> > > On Wed, Feb 03, 2021 at 10:40:46AM -0300, Antonio Terceiro wrote:
> > > > Package: ser2net
> > > > Version: 4.3.2-2
> > > > Severity: important
> > > > 
> > > > Hi,
> > > > 
> > > > Thanks for maintaining ser2net.
> > > > 
> > > > When upgrading from 3.5 to 4.3.2, it now uses /etc/ser2net.yaml instead
> > > > of the previously used /etc/ser2net.conf. This breaks any local
> > > > configuration on upgrade. I don't expect my existing configuration to be
> > > > automatically migrated over to the new format, but I would expect at
> > > > least an entry in NEWS.Debian alerting me of that fact.
> > > 
> > > Well, it's supposed to be backwards compatible.  But I was able to
> > > reproduce (I think, you didn't say what went wrong, which is always good
> > > information).
> > 
> > I think Antonio was rightfully complaining about the unannounced change
> > from the old config format to the new YAML format. I forgot to write a
> > NEWS file that is displayed on package update.
> > 
> > In Debian, there is a general expectation tha packages contain to
> > function during an update. I was too lazy to write a converter from the
> > old format to the new format. The least I could have done was writing a
> > NEWS file. I had that on my mind and thought I did, but I didn't. This
> > will be fixed in the next upload.
> 
> Beyond adding an NEWS entry, another easy thing you could do is
> replacing the current command in ExecStart= by a wrapper script that
> uses ser2net.conf if it exists (while printing a big fat warning), and
> ser2net.yaml otherwise.

This is how ser2net currently works.  It will load ser2net.yaml if it
exists.  If it does not, it will load ser2net.conf.  It doesn't print a
big fat warning, though.  I can add that.

Writing a converter wouldn't be too hard, I should have done that.
There is some trickiness dealing with colons in device names, but I
think that's the only hard thing.  If you don't do this, I can do it.

Bug#966941: libpsl: diff for NMU version 0.21.0-1.2

[Sebastian Ramacher]

Dear maintainer,

I've prepared an NMU for libpsl (versioned as 0.21.0-1.2). The diff is
attached to this message.

Cheers
-- 
Sebastian Ramacher
diff -Nru libpsl-0.21.0/debian/changelog libpsl-0.21.0/debian/changelog
--- libpsl-0.21.0/debian/changelog	2020-05-16 16:24:03.0 +0200
+++ libpsl-0.21.0/debian/changelog	2021-02-04 22:56:22.0 +0100
@@ -1,3 +1,15 @@
+libpsl (0.21.0-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Simon Josefsson ]
+  * B-D on libidn2-dev instead of obsolete libidn2-0-dev. (Closes: #974994)
+
+  [ Sebastian Ramacher ]
+  * debian/patches: Update Platform.sh example in test data (Closes: #966941)
+
+ -- Sebastian Ramacher   Thu, 04 Feb 2021 22:56:22 +0100
+
 libpsl (0.21.0-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru libpsl-0.21.0/debian/control libpsl-0.21.0/debian/control
--- libpsl-0.21.0/debian/control	2020-05-16 16:24:03.0 +0200
+++ libpsl-0.21.0/debian/control	2021-02-04 22:54:10.0 +0100
@@ -8,7 +8,7 @@
  autoconf-archive,
  automake,
  gtk-doc-tools,
- libidn2-0-dev (>=0.16),
+ libidn2-dev,
  libunistring-dev,
  pkg-config,
  publicsuffix (>= 20150507),
diff -Nru libpsl-0.21.0/debian/patches/0008-Update-Platform.sh-example-in-test-data.patch libpsl-0.21.0/debian/patches/0008-Update-Platform.sh-example-in-test-data.patch
--- libpsl-0.21.0/debian/patches/0008-Update-Platform.sh-example-in-test-data.patch	1970-01-01 01:00:00.0 +0100
+++ libpsl-0.21.0/debian/patches/0008-Update-Platform.sh-example-in-test-data.patch	2021-02-04 22:55:25.0 +0100
@@ -0,0 +1,23 @@
+From: Nikola Kotur 
+Date: Thu, 2 Jul 2020 16:41:58 +0200
+Subject: Update Platform.sh example in test data
+
+---
+ tests/test-is-public-builtin.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/tests/test-is-public-builtin.c b/tests/test-is-public-builtin.c
+index e9963b5..ea3a434 100644
+--- a/tests/test-is-public-builtin.c
 b/tests/test-is-public-builtin.c
+@@ -82,8 +82,8 @@ static void test_psl(void)
+ 		{ ".forgot.his.name", 1, 1 },
+ 		{ "whoever.his.name", 0, 0 },
+ 		{ "whoever.forgot.his.name", 0, 0 },
+-		{ "whatever.platform.sh", 1, 1 },
+-		{ ".platform.sh", 1, 1 },
++		{ "whatever.platformsh.site", 1, 1 },
++		{ ".platformsh.site", 1, 1 },
+ 		{ "whatever.yokohama.jp", 1, 1 },
+ 		{ ".yokohama.jp", 1, 1 },
+ 		{ ".", 1, 0 }, /* special case */
diff -Nru libpsl-0.21.0/debian/patches/series libpsl-0.21.0/debian/patches/series
--- libpsl-0.21.0/debian/patches/series	2020-03-04 18:39:16.0 +0100
+++ libpsl-0.21.0/debian/patches/series	2021-02-04 22:55:25.0 +0100
@@ -5,3 +5,4 @@
 0005-Add-missing-api-indeces-for-gtk-doc.patch
 0006-Use-NULL-and-FILE-overall-in-gtk-docs.patch
 0007-gtk-doc-do-not-include-tree_index.sgml.patch
+0008-Update-Platform.sh-example-in-test-data.patch


signature.asc
Description: PGP signature

Bug#957074: cdrkit: diff for NMU version 9:1.1.11-3.2

[John Paul Adrian Glaubitz]

Please don’t. I am planning to work on this in the following days. I was stuck 
with hfsprogs.

Thanks,
Adrian

> On Feb 4, 2021, at 10:41 PM, Sebastian Ramacher  wrote:
> 
> Control: tags 957074 + patch
> 
> Dear maintainer,
> 
> the ITA bug has been filed, but nothing happended since then. So I've
> prepared an NMU for cdrkit (versioned as 9:1.1.11-3.2). The diff is
> attached to this message.
> 
> Cheers
> -- 
> Sebastian Ramacher
> 

Bug#981907: nmu: gobgp_2.18.0-1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu gobgp_2.18.0-1 . ANY . unstable . -m "rebuild for outdated Built-Using"

Bug#963640: jansson: diff for NMU version 2.13.1-1.1

[Sebastian Ramacher]

Dear maintainer,

I've prepared an NMU for jansson (versioned as 2.13.1-1.1). The diff is
attached to this message.

Cheers
-- 
Sebastian Ramacher
diff -Nru jansson-2.13.1/debian/changelog jansson-2.13.1/debian/changelog
--- jansson-2.13.1/debian/changelog	2020-06-28 14:46:50.0 +0200
+++ jansson-2.13.1/debian/changelog	2021-02-04 22:47:01.0 +0100
@@ -1,3 +1,14 @@
+jansson (2.13.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+
+  [ Sebastien Bacher ]
+  * debian/patches/git_new_sphinx.patch:
+- backport an upstream change to fix the build with sphinx3
+  (Closes: #963640)
+
+ -- Sebastian Ramacher   Thu, 04 Feb 2021 22:47:01 +0100
+
 jansson (2.13.1-1) unstable; urgency=medium
 
   * New upstream release (Closes: #963842)
diff -Nru jansson-2.13.1/debian/patches/git_new_sphinx.patch jansson-2.13.1/debian/patches/git_new_sphinx.patch
--- jansson-2.13.1/debian/patches/git_new_sphinx.patch	1970-01-01 01:00:00.0 +0100
+++ jansson-2.13.1/debian/patches/git_new_sphinx.patch	2021-02-04 22:45:41.0 +0100
@@ -0,0 +1,66 @@
+From 798d40c3f3e0700501de1588274b69e2b128ad7c Mon Sep 17 00:00:00 2001
+From: Pierce Lopez 
+Date: Fri, 7 Aug 2020 01:54:45 -0400
+Subject: [PATCH] doc: convert refcounting directive to a class
+
+Directive functions are no longer supported in Sphinx-3.0
+but directive classes have been supported since early 1.x
+---
+ doc/ext/refcounting.py | 31 ---
+ 1 file changed, 20 insertions(+), 11 deletions(-)
+
+diff --git a/doc/ext/refcounting.py b/doc/ext/refcounting.py
+index bba26849..e72c481c 100644
+--- a/doc/ext/refcounting.py
 b/doc/ext/refcounting.py
+@@ -24,8 +24,8 @@
+ """
+ 
+ from docutils import nodes
++from docutils.parsers.rst import Directive
+ 
+-class refcounting(nodes.emphasis): pass
+ 
+ def visit(self, node):
+ self.visit_emphasis(node)
+@@ -40,16 +40,25 @@ def html_depart(self, node):
+ self.body.append('')
+ 
+ 
+-def refcounting_directive(name, arguments, options, content, lineno,
+-   content_offset, block_text, state, state_machine):
+-if arguments[0] == 'borrow':
+-text = 'Return value: Borrowed reference.'
+-elif arguments[0] == 'new':
+-text = 'Return value: New reference.'
+-else:
+-raise Error('Valid arguments: new, borrow')
++class refcounting(nodes.emphasis):
++pass
++
++class refcounting_directive(Directive):
++has_content = False
++required_arguments = 1
++optional_arguments = 0
++final_argument_whitespace = False
++
++def run(self):
++if self.arguments[0] == 'borrow':
++text = 'Return value: Borrowed reference.'
++elif self.arguments[0] == 'new':
++text = 'Return value: New reference.'
++else:
++raise Error('Valid arguments: new, borrow')
++
++return [refcounting(text, text)]
+ 
+-return [refcounting(text, text)]
+ 
+ def setup(app):
+ app.add_node(refcounting,
+@@ -57,4 +66,4 @@ def setup(app):
+  latex=(visit, depart),
+  text=(visit, depart),
+  man=(visit, depart))
+-app.add_directive('refcounting', refcounting_directive, 0, (1, 0, 0))
++app.add_directive('refcounting', refcounting_directive)
diff -Nru jansson-2.13.1/debian/patches/series jansson-2.13.1/debian/patches/series
--- jansson-2.13.1/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ jansson-2.13.1/debian/patches/series	2021-02-04 22:45:41.0 +0100
@@ -0,0 +1 @@
+git_new_sphinx.patch


signature.asc
Description: PGP signature

Bug#980655: lbzip2: diff for NMU version 2.5-2.1

[Boyuan Yang]

Control: tags 980655 + patch
Control: tags 980655 + pending

Dear maintainer,

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

Regards.

diff -Nru lbzip2-2.5/debian/changelog lbzip2-2.5/debian/changelog
--- lbzip2-2.5/debian/changelog 2016-11-09 06:08:17.0 -0500
+++ lbzip2-2.5/debian/changelog 2021-02-04 16:37:24.0 -0500
@@ -1,3 +1,13 @@
+lbzip2 (2.5-2.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * debian/control: Replace obsolete Priority: extra with
+Priority: optional.
+  * debian/patches/0001-configure-ac: Bump AC_PREREQ to 2.64.
+This fixes FTBFS with newer gnulib. (Closes: #980655)
+
+ -- Boyuan Yang   Thu, 04 Feb 2021 16:37:24 -0500
+
 lbzip2 (2.5-2) unstable; urgency=low
 
   * debian/rules: Switch to default dpkg-deb compression
diff -Nru lbzip2-2.5/debian/control lbzip2-2.5/debian/control
--- lbzip2-2.5/debian/control   2016-11-09 06:08:17.0 -0500
+++ lbzip2-2.5/debian/control   2021-02-04 16:35:48.0 -0500
@@ -1,6 +1,6 @@
 Source: lbzip2
 Section: utils
-Priority: extra
+Priority: optional
 Maintainer: Mikolaj Izdebski 
 Build-Depends: debhelper (>= 9), gnulib (>= 20130805), autoconf,
automake (>= 1.14)
 Standards-Version: 3.9.8
diff -Nru lbzip2-2.5/debian/patches/0001-configure.ac-Bump-AC_PREREQ-
to-2.64.patch lbzip2-2.5/debian/patches/0001-configure.ac-Bump-
AC_PREREQ-to-2.64.patch
--- lbzip2-2.5/debian/patches/0001-configure.ac-Bump-AC_PREREQ-to-
2.64.patch  1969-12-31 19:00:00.0 -0500
+++ lbzip2-2.5/debian/patches/0001-configure.ac-Bump-AC_PREREQ-to-
2.64.patch  2021-02-04 16:37:18.0 -0500
@@ -0,0 +1,24 @@
+From: Boyuan Yang 
+Date: Thu, 4 Feb 2021 16:36:47 -0500
+Subject: configure.ac: Bump AC_PREREQ to 2.64
+
+Required by new gnulib.
+
+Bug-Debian: https://bugs.debian.org/980655
+---
+ configure.ac | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index a20abe0..9c198f1 100644
+--- a/configure.ac
 b/configure.ac
+@@ -16,7 +16,7 @@
+ 
+ dnl TODO: check for GCC builtins: expect, prefetch, ctz, ctzl, ctzll
+ 
+-AC_PREREQ([2.63])
++AC_PREREQ([2.64])
+ AC_INIT([lbzip2], [2.5])
+ 
+ AC_CONFIG_SRCDIR([src/main.c])
diff -Nru lbzip2-2.5/debian/patches/series lbzip2-
2.5/debian/patches/series
--- lbzip2-2.5/debian/patches/series1969-12-31 19:00:00.0
-0500
+++ lbzip2-2.5/debian/patches/series2021-02-04 16:36:49.0
-0500
@@ -0,0 +1 @@
+0001-configure.ac-Bump-AC_PREREQ-to-2.64.patch


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

Bug#957074: cdrkit: diff for NMU version 9:1.1.11-3.2

[Sebastian Ramacher]

Control: tags 957074 + patch

Dear maintainer,

the ITA bug has been filed, but nothing happended since then. So I've
prepared an NMU for cdrkit (versioned as 9:1.1.11-3.2). The diff is
attached to this message.

Cheers
-- 
Sebastian Ramacher
diff -Nru cdrkit-1.1.11/debian/changelog cdrkit-1.1.11/debian/changelog
--- cdrkit-1.1.11/debian/changelog	2020-01-09 20:22:43.0 +0100
+++ cdrkit-1.1.11/debian/changelog	2021-02-04 22:36:29.0 +0100
@@ -1,3 +1,11 @@
+cdrkit (9:1.1.11-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches: Apply patch from Fedora to fix build with GCC 10 (Closes:
+#957074)
+
+ -- Sebastian Ramacher   Thu, 04 Feb 2021 22:36:29 +0100
+
 cdrkit (9:1.1.11-3.1) unstable; urgency=medium
 
   * Non-maintainer upload (With Steve approval).
diff -Nru cdrkit-1.1.11/debian/patches/gcc10.patch cdrkit-1.1.11/debian/patches/gcc10.patch
--- cdrkit-1.1.11/debian/patches/gcc10.patch	1970-01-01 01:00:00.0 +0100
+++ cdrkit-1.1.11/debian/patches/gcc10.patch	2021-02-04 22:35:26.0 +0100
@@ -0,0 +1,12 @@
+diff -up cdrkit-1.1.11/genisoimage/genisoimage.h.me cdrkit-1.1.11/genisoimage/genisoimage.h
+--- cdrkit-1.1.11/genisoimage/genisoimage.h.me	2020-02-24 15:10:35.542998992 +0100
 cdrkit-1.1.11/genisoimage/genisoimage.h	2020-02-24 15:10:50.011130450 +0100
+@@ -377,7 +377,7 @@ extern int	use_fileversion;
+ extern int	split_SL_component;
+ extern int	split_SL_field;
+ extern char	*trans_tbl;
+-char		*outfile;
++extern char	*outfile;
+ 
+ #define	JMAX		64	/* maximum Joliet file name length (spec) */
+ #define	JLONGMAX	103	/* out of spec Joliet file name length */
diff -Nru cdrkit-1.1.11/debian/patches/series cdrkit-1.1.11/debian/patches/series
--- cdrkit-1.1.11/debian/patches/series	2020-01-09 18:36:13.0 +0100
+++ cdrkit-1.1.11/debian/patches/series	2021-02-04 22:35:33.0 +0100
@@ -2,3 +2,4 @@
 fix_typo.patch
 fix_libcap_detection.patch
 add-efi-boot.patch
+gcc10.patch


signature.asc
Description: PGP signature

Bug#981906: pyfuse3 FTBFS on 32bit

[Adrian Bunk]

Source: pyfuse3
Version: 3.2.0-1
Severity: important
Tags: ftbfs patch
Forwarded: 
https://github.com/libfuse/pyfuse3/commit/fb94a809da286a950862910a9760468aee2654fd
Control: affects -1 src:s3ql

https://github.com/libfuse/pyfuse3/commit/fb94a809da286a950862910a9760468aee2654fd

...
=== FAILURES ===
 test_rounding _
Traceback (most recent call last):
  File "/<>/test/test_rounding.py", line 31, in test_rounding
entry.st_atime_ns = total
  File "src/pyfuse3.pyx", line 295, in 
pyfuse3.EntryAttributes.st_atime_ns.__set__
OverflowError: Python int too large to convert to C long
=== short test summary info 
FAILED ../../../test/test_rounding.py::test_rounding - OverflowError: Python ...
!! stopping after 1 failures !!!
=== 1 failed, 5 passed, 11 skipped in 2.36s 
E: pybuild pybuild:353: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.9_pyfuse3/build; python3.9 -m pytest 
--installed "{dir}/test/"
rm -fr -- /tmp/dh-xdg-rundir-DuLDOBGF
dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit 
code 13
make: *** [debian/rules:10: build-arch] Error 25

Bug#981905: mysql-8.0: missing runtime dependency on -dev package

[Gianfranco Costamagna]

Source: mysql-8.0
Version: 8.0.23-1
Severity: serious
tags: patch

Hello, the dev package exposes zstd build flags, but doesn't depend on it.
e.g. you can see boinc build log failing

checking mysql libraries... -L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread 
-lz -lzstd -lm -lrt -lssl -lcrypto -ldl -lresolv
checking mysql includes... -I/usr/include/mysql 
[...]
libtool: link: /usr/bin/g++ -Wall -Wextra -Wshadow -Wredundant-decls 
-Wdisabled-optimization -Wpointer-arith -Wstrict-aliasing -Wcast-align -g -O2 
-ffile-prefix-map=/<>/boinc-7.16.16+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -O3 -funroll-loops -fforce-addr 
-ffast-math -flto -Wall -Wl,-Bsymbolic-functions -Wl,-z -Wl,relro -Wl,-z 
-Wl,now -Wl,--as-needed -flto -g -O2 
-ffile-prefix-map=/<>/boinc-7.16.16+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -O3 -funroll-loops -fforce-addr 
-ffast-math -flto -o .libs/adjust_user_priority adjust_user_priority.o  
../sched/.libs/libsched.so ../lib/.libs/libboinc_crypt.so 
../lib/.libs/libboinc.so -L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread 
-lz -lzstd -lm -lrt -ldl -lresolv -lssl -lcrypto -pthread
/usr/bin/ld: cannot find -lzstd
collect2: error: ld returned 1 exit status


this patch should do the trick
diff -Nru mysql-8.0-8.0.23/debian/control mysql-8.0-8.0.23/debian/control
--- mysql-8.0-8.0.23/debian/control 2021-01-19 15:07:46.0 +0100
+++ mysql-8.0-8.0.23/debian/control 2021-02-04 22:30:12.0 +0100
@@ -62,6 +62,7 @@
 Section: libdevel
 Depends: libmysqlclient21 (= ${binary:Version}),
  libssl-dev,
+ libzstd-dev,
  zlib1g-dev,
  ${misc:Depends},
  ${shlibs:Depends}


Gianfranco

Bug#978667: libv4l-dev: ioctl(rfd, VIDIOC_QBUF, ) fails

[Sebastian Ramacher]

Control: severity -1 normal
Control: tags -1 moreinfo

On 2020-12-29 15:55:11 -0500, william wrote:
> Package: libv4l-dev
> Version: 1.16.3-3
> Severity: serious
> Justification: Policy 2.5 - important - Unix is a multi-port operating system
> 
> Dear Maintainer,
> 
> 
>* What led up to the situation?
>  Attempted to open access to a second device (camera)
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  wrote the attached program which minimally opens the stream from the second 
> camera
>* What was the outcome of this action?
>  The program reportes that although the first camera was accessible, 
> identical code opening a stream for a second camera was not successful
>* What outcome did you expect instead?
>  Expected ioctl to return r==0, indicating successful system call

I'm afraid that this bug reports lacks a lot of information and does not
qualify as release critical. Does the second camera work if you switch
ports? Also this package does not implement handling of the ioctl, so
this bug would need to be assigned elsewhere.

Cheers

> 
> 
> -- System Information:
> Debian Release: 10.7
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-13-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libv4l-dev depends on:
> ii  libv4l-01.16.3-3
> ii  libv4l2rds0 1.16.3-3
> ii  libv4lconvert0  1.16.3-3
> 
> libv4l-dev recommends no packages.
> 
> Versions of packages libv4l-dev suggests:
> ii  pkg-config  0.29-6
> 
> -- no debconf information

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#570704: duplicate /usr/share/doc/xfsprogs/changelog{,.Debian}.gz

[Bastian Germann]

On Sat, 20 Feb 2010 20:53:37 +0100 Piotr Engelking 
 wrote:

Package: xfsprogs
Version: 3.1.1
Severity: minor

There are two identical Debian changelogs in the xfsprogs binary
package:

/usr/share/doc/xfsprogs/changelog.Debian.gz
/usr/share/doc/xfsprogs/changelog.gz

Please remove one of them.


It's changelog.gz and CHANGES.gz that have the same content.

Bug#981904: RM: goxel [mips64el mipsel s390x] -- NBS; architectures are no longer built

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

goxel (0.10.6-3) unstable; urgency=high

  * Remove architectures failing to build

 -- Federico Ceratto   Sun, 31 Jan 2021 21:51:33 +

Bug#981903: puppetdb: autopkgtest failure

[Adrian Bunk]

Source: puppetdb
Version: 6.2.0-5
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/p/puppetdb/10223214/log.gz

...
autopkgtest [03:52:37]: test puppet: [---
Adding user `puppetdb' to group `puppet' ...
Adding user puppetdb to group puppet
Done.
Waiting for PuppetDB to start
Timed out
cp: cannot stat '/var/log/puppetdb/puppetdb.log': No such file or directory
autopkgtest [03:54:46]: test puppet: ---]
autopkgtest [03:54:46]: test puppet:  - - - - - - - - - - results - - - - - - - 
- - -
puppet   FAIL non-zero exit status 1
autopkgtest [03:54:47]: test puppet:  - - - - - - - - - - stderr - - - - - - - 
- - -
cp: cannot stat '/var/log/puppetdb/puppetdb.log': No such file or directory
autopkgtest [03:54:47]:  summary
standalone   FAIL non-zero exit status 1
puppet   FAIL non-zero exit status 1

Bug#981902: facterdb: autopkgtest failure

[Adrian Bunk]

Source: facterdb
Version: 1.6.0-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/f/facterdb/10218718/log.gz

...
Failures:

  1) FacterDB.facterdb_fact_files returns the deduplicated combination of 
.default_fact_files and .external_fact_files
 Failure/Error: expect(facterdb_fact_files.count).to 
eq(described_class.default_fact_files.count)

   expected: 1577
got: 1702

   (compared using ==)
 # ./spec/facterdb_spec.rb:153:in `block (3 levels) in '

  2) Default Facts 
../../../../../usr/share/rubygems-integration/all/gems/facterdb-1.6.0/facts/2.2/archlinux-x86_64.facts
 contains an ipaddress fact
 Failure/Error: expect(content['ipaddress']).to not_be_nil.and not_be_empty

  expected: not nil
   got: nil

   ...and:

  expected nil to respond to `empty?`
 # ./spec/facts_spec.rb:105:in `block (4 levels) in '

  3) Default Facts 
../../../../../usr/share/rubygems-integration/all/gems/facterdb-1.6.0/facts/3.2/aix-53-powerpc.facts
 contains an ipaddress fact
 Failure/Error: expect(content['ipaddress']).to not_be_nil.and not_be_empty

  expected: not nil
   got: nil

   ...and:

  expected nil to respond to `empty?`
 # ./spec/facts_spec.rb:105:in `block (4 levels) in '

  4) Default Facts 
../../../../../usr/share/rubygems-integration/all/gems/facterdb-1.6.0/facts/3.2/aix-61-powerpc.facts
 contains an ipaddress fact
 Failure/Error: expect(content['ipaddress']).to not_be_nil.and not_be_empty

  expected: not nil
   got: nil

   ...and:

  expected nil to respond to `empty?`
 # ./spec/facts_spec.rb:105:in `block (4 levels) in '

  5) Default Facts 
../../../../../usr/share/rubygems-integration/all/gems/facterdb-1.6.0/facts/3.2/aix-71-powerpc.facts
 contains an ipaddress fact
 Failure/Error: expect(content['ipaddress']).to not_be_nil.and not_be_empty

  expected: not nil
   got: nil

   ...and:

  expected nil to respond to `empty?`
 # ./spec/facts_spec.rb:105:in `block (4 levels) in '

  6) Default Facts 
../../../../../usr/share/rubygems-integration/all/gems/facterdb-1.6.0/facts/1.7/archlinux-x86_64.facts
 contains an ipaddress fact
 Failure/Error: expect(content['ipaddress']).to not_be_nil.and not_be_empty

  expected: not nil
   got: nil

   ...and:

  expected nil to respond to `empty?`
 # ./spec/facts_spec.rb:105:in `block (4 levels) in '

  7) Default Facts 
../../../../../usr/share/rubygems-integration/all/gems/facterdb-1.6.0/facts/2.1/archlinux-x86_64.facts
 contains an ipaddress fact
 Failure/Error: expect(content['ipaddress']).to not_be_nil.and not_be_empty

  expected: not nil
   got: nil

   ...and:

  expected nil to respond to `empty?`
 # ./spec/facts_spec.rb:105:in `block (4 levels) in '

  8) Default Facts 
../../../../../usr/share/rubygems-integration/all/gems/facterdb-1.6.0/facts/2.3/archlinux-x86_64.facts
 contains an ipaddress fact
 Failure/Error: expect(content['ipaddress']).to not_be_nil.and not_be_empty

  expected: not nil
   got: nil

   ...and:

  expected nil to respond to `empty?`
 # ./spec/facts_spec.rb:105:in `block (4 levels) in '

  9) Default Facts 
../../../../../usr/share/rubygems-integration/all/gems/facterdb-1.6.0/facts/3.0/ubuntu-15.10-x86_64.facts
 contains an ipaddress fact
 Failure/Error: expect(content['ipaddress']).to not_be_nil.and not_be_empty

  expected: not nil
   got: nil

   ...and:

  expected nil to respond to `empty?`
 # ./spec/facts_spec.rb:105:in `block (4 levels) in '

  10) Default Facts 
../../../../../usr/share/rubygems-integration/all/gems/facterdb-1.6.0/facts/3.0/ubuntu-15.10-i386.facts
 contains an ipaddress fact
  Failure/Error: expect(content['ipaddress']).to not_be_nil.and not_be_empty

   expected: not nil
got: nil

...and:

   expected nil to respond to `empty?`
  # ./spec/facts_spec.rb:105:in `block (4 levels) in '

  11) Default Facts 
../../../../../usr/share/rubygems-integration/all/gems/facterdb-1.6.0/facts/2.4/archlinux-x86_64.facts
 contains an ipaddress fact
  Failure/Error: expect(content['ipaddress']).to not_be_nil.and not_be_empty

   expected: not nil
got: nil

...and:

   expected nil to respond to `empty?`
  # ./spec/facts_spec.rb:105:in `block (4 levels) in '

  12) Default Facts 
../../../../../usr/share/rubygems-integration/all/gems/facterdb-1.6.0/facts/3.6/pcs-6-x86_64.facts
 contains an ipaddress fact
  Failure/Error: expect(content['ipaddress']).to not_be_nil.and not_be_empty

   expected: not nil
got: nil

...and:

   expected nil to respond to `empty?`
  # ./spec/facts_spec.rb:105:in `block (4 levels) in '

  13) 

Bug#981901: basix: Nedelec 2nd kind H(curl) test fails on 32-bit systems

[Drew Parsons]

Source: basix
Version: 0.0.1~git20210122.4f10ef2-1
Severity: normal
Control: forwarded -1 https://github.com/FEniCS/basix/issues/111

Judging by the build errors at
https://buildd.debian.org/status/package.php?p=basix, looks like
Nedelec 2nd kind H(curl) is not compatible with 32 bit systems. e.g.

i386   
https://buildd.debian.org/status/fetch.php?pkg=basix=i386=0.0.1%7Egit20210122.4f10ef2-1=1612391676=0
armel  
https://buildd.debian.org/status/fetch.php?pkg=basix=armel=0.0.1%7Egit20210122.4f10ef2-1=1612398463=0
armhf  
https://buildd.debian.org/status/fetch.php?pkg=basix=armhf=0.0.1%7Egit20210122.4f10ef2-1=1612392128=0

The error message is

__ test_permutation_of_tabulated_data_tetrahedron[5-Nedelec 2nd kind H(curl)] __

element_name = 'Nedelec 2nd kind H(curl)', order = 5

@pytest.mark.parametrize("element_name", tetrahedron_elements)
@pytest.mark.parametrize("order", range(1, 6))
def test_permutation_of_tabulated_data_tetrahedron(element_name, order):
if element_name == "Crouzeix-Raviart" and order != 1:
pytest.xfail()

e = basix.create_element(element_name, "tetrahedron", order)

N = 4
points = np.array([[i / N, j / N, k / N]
   for i in range(N + 1) for j in range(N + 1 - i) for 
k in range(N + 1 - i - j)])
values = e.tabulate(0, points)[0]

start = sum(e.entity_dofs[0])
ndofs = e.entity_dofs[1][0]
if ndofs != 0:
# Check that the 0th permutation undoes the effect of reflecting 
edge 0
reflected_points = np.array([[p[0], p[2], p[1]] for p in points])
reflected_values = e.tabulate(0, reflected_points)[0]

if e.mapping_name == "affine":
pass
elif e.mapping_name == "covariant piola":
for i, r in enumerate(reflected_values):
for j in range(e.dim):
reflected_values[i][j + e.dim::e.dim] = r[j + 
e.dim::e.dim][::-1]
elif e.mapping_name == "contravariant piola":
for i, r in enumerate(reflected_values):
for j in range(e.dim):
reflected_values[i][j] = -r[j]
reflected_values[i][j + e.dim::e.dim] = -r[j + 
e.dim::e.dim][::-1]
elif e.mapping_name == "double covariant piola":
pytest.skip()  # TODO: implement double covariant piola
else:
raise ValueError(f"Unknown mapping: {e.mapping_name}")

for i, j in zip(values, reflected_values):
for d in range(e.value_size):
i_slice = i[d * e.dim:(d + 1) * e.dim]
j_slice = j[d * e.dim:(d + 1) * e.dim]
>   assert 
> np.allclose((e.base_permutations[0].dot(i_slice))[start: start + ndofs],
   j_slice[start: start + ndofs])
E   assert False
E+  where False = (array([ 
0., -0., -0., -0., -0.,  0.]), array([-1.34, -1.12, -0.28,  0.68,  0.8 , -1.5 
]))
E+where  = np.allclose

test/test_permutations.py:227: AssertionError

Since only this one test fails (for only this one element), I'll just
skip this test in the 32-bit Debian builds.  This is a relatively rare
Finite Element, so the package is still useful for providing the others.

Once the test is skipped the error won't show in future builds (but
will still be there). So I'm filing this bug to keep track of the
problem.



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

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

Bug#949638: debdiff for 949638 "tesseract: uses -march=native"

[Paul Gevers]

Dear maintainer,

I have just uploaded tesseract to the archive to fix this bug. debdiff
based on the work of plugwash attached.

Paul
diff -Nru tesseract-4.1.1/debian/changelog tesseract-4.1.1/debian/changelog
--- tesseract-4.1.1/debian/changelog2020-01-19 06:48:59.0 +0100
+++ tesseract-4.1.1/debian/changelog2021-02-04 21:49:33.0 +0100
@@ -1,3 +1,11 @@
+tesseract (4.1.1-2.1) unstable; urgency=medium
+
+  [ Peter Green ]
+  * Edit configure.ac to disable -march=native (Closes: #949638)
+  * Edit control/rules to enable autoreconf.
+
+ -- Paul Gevers   Thu, 04 Feb 2021 21:49:33 +0100
+
 tesseract (4.1.1-2) unstable; urgency=medium
 
   * Update debian/control:
diff -Nru tesseract-4.1.1/debian/control tesseract-4.1.1/debian/control
--- tesseract-4.1.1/debian/control  2020-01-19 06:47:02.0 +0100
+++ tesseract-4.1.1/debian/control  2021-02-04 21:49:33.0 +0100
@@ -5,7 +5,7 @@
 Build-Depends: debhelper (>= 9), libleptonica-dev (>= 1.75.3),
automake, libtool, libarchive-dev, libpango1.0-dev, 
libcairo2-dev, libicu-dev,
libpng-dev, libjpeg-dev, libtiff-dev, zlib1g-dev, git, 
autoconf-archive, asciidoc,
-   xsltproc, docbook-xsl, docbook-xml, tesseract-ocr-eng (>= 4.00~)
+   xsltproc, docbook-xsl, docbook-xml, tesseract-ocr-eng (>= 
4.00~), dh-autoreconf
 Standards-Version: 4.4.1
 Homepage: https://github.com/tesseract-ocr/
 Vcs-Git: https://github.com/AlexanderP/tesseract-debian.git
diff -Nru tesseract-4.1.1/debian/patches/no-march-native 
tesseract-4.1.1/debian/patches/no-march-native
--- tesseract-4.1.1/debian/patches/no-march-native  1970-01-01 
01:00:00.0 +0100
+++ tesseract-4.1.1/debian/patches/no-march-native  2021-02-04 
21:49:33.0 +0100
@@ -0,0 +1,28 @@
+Description:  Edit configure.ac to disable -march=native
+ -march=native is inappropriate for a binary distribution like Debian.
+Author: Peter Michael Green 
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: , 
+Bug: 
+Bug-Debian: https://bugs.debian.org/
+Bug-Ubuntu: https://launchpad.net/bugs/
+Forwarded: 
+Reviewed-By: 
+Last-Update: 2020-01-23
+
+--- tesseract-4.1.1.orig/configure.ac
 tesseract-4.1.1/configure.ac
+@@ -136,7 +136,7 @@ AM_CONDITIONAL([FMA_OPT], $fma)
+ AX_CHECK_COMPILE_FLAG([-msse4.1], [sse41=true], [sse41=false], [$WERROR])
+ AM_CONDITIONAL([SSE41_OPT], $sse41)
+ 
+-AX_CHECK_COMPILE_FLAG([-march=native], [arch_native=true], 
[arch_native=false], [$WERROR])
++AX_CHECK_COMPILE_FLAG([-march=native], [arch_native=false], 
[arch_native=false], [$WERROR])
+ AM_CONDITIONAL([MARCH_NATIVE_OPT], $arch_native)
+ 
+ AC_ARG_WITH([extra-includes],
diff -Nru tesseract-4.1.1/debian/patches/series 
tesseract-4.1.1/debian/patches/series
--- tesseract-4.1.1/debian/patches/series   2019-12-26 21:46:07.0 
+0100
+++ tesseract-4.1.1/debian/patches/series   2021-02-04 21:49:33.0 
+0100
@@ -2,3 +2,4 @@
 #fix-up-headers
 helptext
 #shebang.diff
+no-march-native
diff -Nru tesseract-4.1.1/debian/rules tesseract-4.1.1/debian/rules
--- tesseract-4.1.1/debian/rules2019-12-26 21:46:07.0 +0100
+++ tesseract-4.1.1/debian/rules2021-02-04 21:49:33.0 +0100
@@ -16,7 +16,7 @@
 endif
 
 %:
-   dh $@ --parallel
+   dh $@ --parallel --with autoreconf
 
 override_dh_auto_build:
make -j$(NUMJOBS)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#981900: s3ql: autopkgtest failure: No module named 'pytest_trio'

[Adrian Bunk]

Source: s3ql
Version: 3.7.0+dfsg-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/s/s3ql/10265797/log.gz

...
autopkgtest [16:12:24]: test upstream-standard: [---
ImportError while loading conftest 
'/tmp/autopkgtest-lxc.weivh3tb/downtmp/build.pvb/src/tests/conftest.py'.
tests/conftest.py:22: in 
import pytest_trio
E   ModuleNotFoundError: No module named 'pytest_trio'
autopkgtest [16:12:25]: test upstream-standard: ---]
autopkgtest [16:12:26]: test upstream-standard:  - - - - - - - - - - results - 
- - - - - - - - -
upstream-standardFAIL non-zero exit status 4
autopkgtest [16:12:26]: test upstream-standard:  - - - - - - - - - - stderr - - 
- - - - - - - -
ImportError while loading conftest 
'/tmp/autopkgtest-lxc.weivh3tb/downtmp/build.pvb/src/tests/conftest.py'.
tests/conftest.py:22: in 
import pytest_trio
E   ModuleNotFoundError: No module named 'pytest_trio'
autopkgtest [16:12:26]: test upstream-with-fuse: preparing testbed
Reading package lists...
Building dependency tree...
Reading state information...
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up autopkgtest-satdep (0) ...
(Reading database ... 15096 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [16:12:30]: test upstream-with-fuse: [---
ImportError while loading conftest 
'/tmp/autopkgtest-lxc.weivh3tb/downtmp/build.pvb/src/tests/conftest.py'.
tests/conftest.py:22: in 
import pytest_trio
E   ModuleNotFoundError: No module named 'pytest_trio'
autopkgtest [16:12:31]: test upstream-with-fuse: ---]
autopkgtest [16:12:31]: test upstream-with-fuse:  - - - - - - - - - - results - 
- - - - - - - - -
upstream-with-fuse   FAIL non-zero exit status 4
autopkgtest [16:12:31]: test upstream-with-fuse:  - - - - - - - - - - stderr - 
- - - - - - - - -
ImportError while loading conftest 
'/tmp/autopkgtest-lxc.weivh3tb/downtmp/build.pvb/src/tests/conftest.py'.
tests/conftest.py:22: in 
import pytest_trio
E   ModuleNotFoundError: No module named 'pytest_trio'
autopkgtest [16:12:32]:  summary
upstream-standardFAIL non-zero exit status 4
upstream-with-fuse   FAIL non-zero exit status 4

Bug#981849: podman build does not use the cache

[Reinhard Tartler]

Control: reassign -1 buildah 1.19.3+dfsg1-1
Control: affects -1 podman

On Thu, Feb 4, 2021 at 12:55 PM Antonio Terceiro 
wrote:

> Control: forwarded -1 https://github.com/containers/podman/issues/9233
>
> There.
>

Awesome. As it turns out, this is actually an issue in buildah
and needs to be fixed there. The patch for this can be found here:
https://patch-diff.githubusercontent.com/raw/containers/buildah/pull/2967.patch

As for timing, I'd prefer to let the current packages migrate to testing
first,
but if you (or anyone else) feels strongly and where to raise this to RC,
I'd prioritize the upload.
--
regards,
Reinhard

Bug#981899: adequate: autopkgtest failure

[Adrian Bunk]

Source: adequate
Version: 0.15.4
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/a/adequate/10235236/log.gz

...
./run-tests adequate-testpkg_1_amd64.changes
install adequate-testpkg-bin-or-sbin-binary-requires-usr-lib-library ... ok
check adequate-testpkg-bin-or-sbin-binary-requires-usr-lib-library ... FAIL
-adequate-testpkg-bin-or-sbin-binary-requires-usr-lib-library: 
bin-or-sbin-binary-requires-usr-lib-library /bin/adequate-usrlib1 => 
/usr/lib/libadequate-usrlib.so.0
-adequate-testpkg-bin-or-sbin-binary-requires-usr-lib-library: 
bin-or-sbin-binary-requires-usr-lib-library /sbin/adequate-usrlib2 => 
/usr/lib/libadequate-usrlib.so.0
remove adequate-testpkg-bin-or-sbin-binary-requires-usr-lib-library ... ok
install adequate-testpkg-broken-symlink ... ok
check adequate-testpkg-broken-symlink ... ok
remove adequate-testpkg-broken-symlink ... ok
install adequate-testpkg-incompatible-licenses ... ok
check adequate-testpkg-incompatible-licenses ... ok
remove adequate-testpkg-incompatible-licenses ... ok
install adequate-testpkg-incompatible-licenses-dep5 ... ok
check adequate-testpkg-incompatible-licenses-dep5 ... ok
remove adequate-testpkg-incompatible-licenses-dep5 ... ok
install adequate-testpkg-library-not-found ... ok
check adequate-testpkg-library-not-found ... ok
remove adequate-testpkg-library-not-found ... ok
install adequate-testpkg-missing-alternative ... ok
check adequate-testpkg-missing-alternative ... ok
remove adequate-testpkg-missing-alternative ... ok
install adequate-testpkg-missing-copyright-file ... ok
check adequate-testpkg-missing-copyright-file ... ok
remove adequate-testpkg-missing-copyright-file ... ok
install adequate-testpkg-missing-pkgconfig-dependency ... ok
check adequate-testpkg-missing-pkgconfig-dependency ... ok
remove adequate-testpkg-missing-pkgconfig-dependency ... ok
install adequate-testpkg-missing-symbol-version-information ... ok
check adequate-testpkg-missing-symbol-version-information ... ERROR (non-empty 
stderr)
! adequate: ldd -r /usr/bin/adequate-test-msvi: Inconsistency detected by 
ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! 
_dl_name_match_p (version->filename, map)' failed!
remove adequate-testpkg-missing-symbol-version-information ... ok
install adequate-testpkg-obsolete-conffile (1) ... ok
check adequate-testpkg-obsolete-conffile ... ok
upgrade adequate-testpkg-obsolete-conffile (1 => 2) ... ok
check adequate-testpkg-obsolete-conffile ... ok
remove adequate-testpkg-obsolete-conffile ... ok
install adequate-testpkg-program-name-collision ... ok
check adequate-testpkg-program-name-collision ... FAIL
 adequate-testpkg-program-name-collision: program-name-collision 
/usr/games/true (bash builtin command)
 adequate-testpkg-program-name-collision: program-name-collision 
/usr/games/true /bin/true
+adequate-testpkg-program-name-collision: program-name-collision 
/usr/games/true /usr/bin/true
remove adequate-testpkg-program-name-collision ... ok
install adequate-testpkg-py-file-not-bytecompiled ... ok
check adequate-testpkg-py-file-not-bytecompiled ... ok
remove adequate-testpkg-py-file-not-bytecompiled ... ok
install adequate-testpkg-symbol-size-mismatch ... ok
check adequate-testpkg-symbol-size-mismatch ... ok
remove adequate-testpkg-symbol-size-mismatch ... ok
install adequate-testpkg-undefined-symbol ... ok
check adequate-testpkg-undefined-symbol ... FAIL
-adequate-testpkg-undefined-symbol: undefined-symbol /usr/bin/adequate-test-us1 
=> this_symbol_might_be_undefined
-adequate-testpkg-undefined-symbol: undefined-symbol /usr/bin/adequate-test-us2 
=> this_symbol_might_be_undefined@ADEQUATE_TEST 
(libadequate-test-versioning.so.0)
+adequate-testpkg-undefined-symbol: undefined-symbol /usr/bin/adequate-test-us2 
=> this_symbol_might_be_undefined@ADEQUATE_TEST
remove adequate-testpkg-undefined-symbol ... ok
make: *** [Makefile:15: run] Error 1
autopkgtest [11:55:28]: test full-test: ---]
autopkgtest [11:55:28]: test full-test:  - - - - - - - - - - results - - - - - 
- - - - -
full-testFAIL non-zero exit status 2
autopkgtest [11:55:28]: test full-test:  - - - - - - - - - - stderr - - - - - - 
- - - -
make: *** [Makefile:15: run] Error 1
autopkgtest [11:55:29]:  summary
smoke-test   PASS
full-testFAIL non-zero exit status 2

Bug#942078: [high quality bug] baloo crash, can't recover; forced reindex does not fix; unusable via dolphin C-f

[Aurélien COUDERC]

Dear Nicholas,

Le jeudi 4 février 2021, 04:23:36 CET Nicholas D Steeves a écrit :
> Norbert Preining  writes:
> 
> > Control: tag -1 +unreproducible
> >
> > Hi Nicholas,
> >
> > to be clear, tagging this bug as "unreproducible" means that **we** the
> > developer cannot reproduce it. So please don't change it. Thanks.
> >
> > Also, moreinfo is still needed, and you didn't provide it.
> >
> 
> I did. The minimum dataset needed to trigger was with an extensive set
> of exclusion patterns that result in 436767 indexed files, with the
> following results returned for balooctl indexSize
> 
> Actual Size: 3.27 GiB
> Expected Size: 2.12 GiB
> 
>PostingDB: 424.52 MiB19.516 %
>   PositionDB: 845.84 MiB38.884 %
> DocTerms: 344.65 MiB15.844 %
> DocFilenameTerms:  47.45 MiB 2.181 %
>DocXattrTerms:0 B 0.000 %
>   IdTree:   7.64 MiB 0.351 %
>   IdFileName:  35.77 MiB 1.645 %
>  DocTime:  22.29 MiB 1.024 %
>  DocData:  23.21 MiB 1.067 %
>ContentIndexingDB:0 B 0.000 %
>  FailedIdsDB:0 B 0.000 %
>  MTimeDB:   2.59 MiB 0.119 %

I beat you although by a small margin ;)

Baloo File Indexer is not running
Total files indexed: 438,883
Files waiting for content indexing: 0
Files failed to index: 0
Current size of index is 4.26 GiB

File Size: 4,26 Gio
Used:  2,17 Gio

   PostingDB: 584,37 Mio26.301 %
  PositionDB: 946,16 Mio42.585 %
DocTerms: 499,82 Mio22.496 %
DocFilenameTerms:  57,64 Mio 2.594 %
   DocXattrTerms:0 o 0.000 %
  IdTree:   9,84 Mio 0.443 %
  IdFileName:  45,09 Mio 2.029 %
 DocTime:  28,65 Mio 1.290 %
 DocData:  43,68 Mio 1.966 %
   ContentIndexingDB:0 o 0.000 %
 FailedIdsDB:0 o 0.000 %
 MTimeDB:   6,57 Mio 0.296 %

… and I can’t reproduce the bug either… :(
I’m using it for searches on a nearly daily basis and it’s been working 
reliably for as long as I can remember. Both with file names and file contents.

[…]

> >> Has anyone on the team tried testing baloo with a large $HOME?  Mine is
> >> 131GB, in 142460 mixed files and directories.  At the moment my
> >> baloo_file process is consuming over a terabyte (!) of memory.  After
> >> resetting baloo and forcing a full reindex it takes a couple of weeks
> >> before it gets out of control again and crashes.
> >
> > Well, maybe you should disable the service since it obviously is not
> > able to cope with the amount of data/files/size you are asking it to
> > index.
> >
> 
> Right, that's why I filed this bug.  With a non-toy dataset, baloo is
> more often than not unusable.  Typical lore says to disable baloo and
> use the more robust recoll.  I'm willing to conceded that it's possible
> that there's something special about my data/files, and that they're
> causing baloo to fail in a corner-case.  If that's the case, what data
> do you need?  Other than all my files ;-)

As said above, this has not been my experience on a definitely non-toy dataset.
Maybe there’s something more specific to the crash you experienced that would 
need investigating before it can be fixed.

I had an issue on a a secondary machine where it would crash / stop due to 
starvation of inotify watches. This was clearly visible in .xsession-errors 
with the advices to increase fs.inotify.max_user_watches plainy written, and 
baloo was not the only piece of software having issues in this situation. 
Probably not your case but I’m mentioning it here just in case.

> >> Please don't sweep baloo bugs under the rug by tagging bugs containing
> >> crashes with obvious misbehaviour as severity "normal", eg:
> >
> > Again, since it is not reproducible and nobody else has either reported
> > this problem and none of us see this problem, it is normal, would you
> > please kindly trust the decision of the maintainers?
> > And thanks, you don't have to educate me about severities.
> >
> 
> Important: "a bug which has a major effect on the usability of a
> package, without rendering it completely unusable to everyone."  It is
> clear that this bug meets Debian criteria for "important".  If no one
> else on the team (I'm a team member too) is testing baloo with a medium
> size set of diverse file types than no one else one the team will be
> able to reproduce it.
> 
> A politic of "normal + unreproducible" is a contributing factor to
> why baloo is never fixed.  In other words, it's a politic of ignoring
> problems in baloo.

Given that we failed to reproduce the issue so far, with little indication as 
to what could actually help reproducing it, this looks really overkill to me.


Happy hacking !
--
Aurélien

Bug#981898: python-fsquota: autopkgtest failure: No module named 'fsquota'

[Adrian Bunk]

Source: python-fsquota
Version: 0.1.0+dfsg1-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-fsquota/10254027/log.gz

...
autopkgtest [05:38:58]: test autodep8-python3: set -e ; for py in $(py3versions 
-d 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c 
"import fsquota; print(fsquota)" ; done
autopkgtest [05:38:58]: test autodep8-python3: [---
Testing with python3.9:
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'fsquota'
autopkgtest [05:39:01]: test autodep8-python3: ---]
autopkgtest [05:39:01]: test autodep8-python3:  - - - - - - - - - - results - - 
- - - - - - - -
autodep8-python3 FAIL non-zero exit status 1
autopkgtest [05:39:01]:  summary
autodep8-python3 FAIL non-zero exit status 1

Bug#977324: doesn't run: 'xml.etree.ElementTree.Element' object has no attribute 'getchildren'

[Jean-Michel Vourgère]

Control: severity -1 grave
Control: tag -1 + patch

Hi

Same issue here: ocrfeeder crashes immediately when started, and is unusable. 
So I'm raising the severity.

The good news is that the patch works like a charm.

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

Bug#981897: put-dns: Removing package fails

[Adrian Bunk]

Package: put-dns
Version: 0.0.2-1
Severity: serious

https://piuparts.debian.org/sid/fail/put-dns_0.0.2-1.log

...
  Removing put-dns (0.0.2-1) ...
  rmdir: failed to remove '/var/lib/put-dns': No such file or directory
  dpkg: error processing package put-dns (--remove):
   installed put-dns package post-removal script subprocess returned error exit 
status 1
  dpkg: too many errors, stopping
  Errors were encountered while processing:
   put-dns
  Processing was halted because there were too many errors.
  E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#539723: xfsprogs: {mkfs.xfs] Please provide GNU --long options

[Bastian Germann]

Tags: upstream wontfix
Control: notfound -1 xfsprogs/3.0.2

On Mon, 03 Aug 2009 12:32:57 +0300 Jari Aalto  wrote:

Please add support for GNU --long options that are readable
alternatives. An Example:

mkfs.xfs --force /dev/sda7
 ===



It is not common for mkfs.* programs to have --long options.
So most probably this will not be implemented.

Bug#981896: RFS: iptotal/0.3.3-14 [QA] -- monitor for IP traffic, not requiring SNMP

[João Paulo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name    : iptotal
   Version : 0.3.3-14
   Upstream Author : [fill in name and email of upstream]
 * URL : http://sourceforge.net/projects/iptotal
 * License : GPL-2+
 * Vcs : [fill in URL of packaging vcs]
   Section : admin

It builds those binary packages:

  iptotal - monitor for IP traffic, not requiring SNMP

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/i/iptotal/iptotal_0.3.3-14.dsc

Changes since the last upload:

 iptotal (0.3.3-14) unstable; urgency=medium
 .
   * QA upload.
   * Using new DH level format. Consequently:
   - debian/compat: removed.
   - debian/control: changed from 'debhelper' to 'debhelper-compat'
 in Build-Depends field and bumped level to 13.
   * debian/control:
   - Add Pre-Depends: ${misc:Pre-Depends} to fix lintian flag.
   - Add missing lsb-base dependency
   - Bumped Standards-Version to 4.5.1.
   - Drop obsolete Dm-Upload-Allowed field
   - Set section and priority fields matching override.
    * debian/copyright: Update header to suit DEP5
    * debian/postinst: Remove recursive chown -R argument in postinst 
 script (which is vulnerable to hardlink attacks).
    * debian/rules: Put helper binaries in /usr/libexec as allowed by
 FHS 3.0.
    * debian/README.Debian: Fix spelling error.
    * debian/watch: Update version from 3 to 4.

Regards,

Bug#981835: libelf1 violates Multi-Arch: same / unreproducible

[Helmut Grohne]

Control: clone -1 -2
Control: retitle -2 handle gettext PO-Revision-Date
Control: reassign -2 libstrip-nondeterminism-perl
Control: block -1 by -2

On Thu, Feb 04, 2021 at 06:51:49PM +, Simon McVittie wrote:
> 0.182+20210203-1.1 doesn't seem to solve this as intended, and triggers
> a similar failure mode on a more frequently co-installed pair of
> architectures:
> 
> $ apt-get download libelf1 libelf1:i386
> $ aunpack libelf1_0.182+20210203-1.1_amd64.deb
> $ aunpack libelf1_0.182+20210203-1.1_i386.deb
> $ diff -ru libelf1_0.182+20210203-1.1_*/usr/share/
> Binary files 
> libelf1_0.182+20210203-1.1_amd64/usr/share/locale/en@boldquot/LC_MESSAGES/elfutils.mo
>  and 
> libelf1_0.182+20210203-1.1_i386/usr/share/locale/en@boldquot/LC_MESSAGES/elfutils.mo
>  differ
> Binary files 
> libelf1_0.182+20210203-1.1_amd64/usr/share/locale/en@quot/LC_MESSAGES/elfutils.mo
>  and 
> libelf1_0.182+20210203-1.1_i386/usr/share/locale/en@quot/LC_MESSAGES/elfutils.mo
>  differ

Thank you. After a little longer irc discussion, we mostly concluded
that this should be stripped by dh_strip_nondeterminism for now.

It already fixes the POT-Creation-Date, but does not touch the
PO-Revision-Date, because this field usually is only changed by
translators. Unfortunately, there are also some "mechanical" translators
in the form of sed scripts copied from gettext using autotools. Those
translators are used to create the en@quot and en@boldquot locales.
Given that they are translated at build time, they PO-Revision-Date is
"now" and if they are not corrected, then we see what we see here.

I'm attaching a patch to dh-strip-nondeterminism. Can $someone upload it
real soon as the libelf1 breakage has a high impact here? Once uploaded,
we'll have to binNMU elfutils.

Helmut
--- strip-nondeterminism-1.10.0.orig/lib/File/StripNondeterminism/handlers/gettext.pm
+++ strip-nondeterminism-1.10.0/lib/File/StripNondeterminism/handlers/gettext.pm
@@ -82,17 +82,18 @@
 		my $trans_len = unpack($fmt, substr($buf, $trans_to + $i*8));
 		my $trans_offset = unpack($fmt, substr($buf, $trans_to + $i*8 + 4));
 		my $trans_msg = substr($buf, $trans_offset, $trans_len);
-		next unless $trans_msg =~ m/^POT-Creation-Date: (.*)/m;
+		next unless $trans_msg =~ m/^(POT-Creation-Date|PO-Revision-Date): (.*)/m;
 
-		my $pot_date = $1;
+		my $date_key = $1;
+		my $date_value = $2;
 		my $time;
-		eval {$time = Time::Piece->strptime($pot_date, "%Y-%m-%d %H:%M%z");};
+		eval {$time = Time::Piece->strptime($date_value, "%Y-%m-%d %H:%M%z");};
 		next if $@;
 		next if $time <= $norm_time;
 
 		my $new_time = strftime("%Y-%m-%d %H:%M%z", gmtime($norm_time));
 		$trans_msg
-		  =~ s/\QPOT-Creation-Date: $pot_date\E/POT-Creation-Date: $new_time/;
+		  =~ s/\Q$date_key: $date_value\E/$date_key: $new_time/;
 		next if length($trans_msg) != $trans_len;
 
 		$buf

Bug#981894: go-dlib FTBFS: test failure

[Adrian Bunk]

Source: go-dlib
Version: 5.6.0.9+dfsg-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=go-dlib=all=5.6.0.9%2Bdfsg-1=1612409395=0

...
FAIL: group_test.go:57: testWrapper.TestGetGroupEntry

group_test.go:60:
c.Check(groups[0].Name, C.Equals, "root")
... obtained string = "porter-any"
... expected string = "root"

OOPS: 2 passed, 1 FAILED
--- FAIL: Test (0.00s)
FAIL
FAILpkg.deepin.io/lib/users/group   0.019s
...

Bug#981893: libcacard FTCBFS: fails running building tests despite DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: libcacard
Version: 1:2.8.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libcacard fails to cross build from source, because it fails building
unit tests despite DEB_BUILD_OPTIONS=nocheck. Please consider applying
the attached patch to fully disable tests for the nocheck option. Doing
so makes libcacard cross buildable again.

Helmut
diff --minimal -Nru libcacard-2.8.0/debian/changelog 
libcacard-2.8.0/debian/changelog
--- libcacard-2.8.0/debian/changelog2021-01-06 17:39:33.0 +0100
+++ libcacard-2.8.0/debian/changelog2021-02-04 13:55:36.0 +0100
@@ -1,3 +1,10 @@
+libcacard (1:2.8.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Disable tests for DEB_BUILD_OPTIONS=nocheck. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 04 Feb 2021 13:55:36 +0100
+
 libcacard (1:2.8.0-3) unstable; urgency=medium
 
   * libcacard-dev also build-depends on libpcsclite-dev.
diff --minimal -Nru libcacard-2.8.0/debian/rules libcacard-2.8.0/debian/rules
--- libcacard-2.8.0/debian/rules2020-12-30 12:21:13.0 +0100
+++ libcacard-2.8.0/debian/rules2021-02-04 13:55:36.0 +0100
@@ -2,3 +2,6 @@
 
 build-arch build-indep build clean install-indep install-arch install 
binary-arch binary-indep binary: %:
dh $@
+
+override_dh_auto_configure:
+   dh_auto_configure -- -Ddisable_tests=$(if $(filter 
nocheck,$(DEB_BUILD_OPTIONS)),true,false)

Bug#981892: lakai FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: lakai
Version: 0.1-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

lakai fails to cross build from source, because it does not pass cross
tools to make. The easiest way of fixing that - using dh_auto_build -
makes lakai cross buildable. Please consider applying the attached
patch.

Helmut
diff -u lakai-0.1/debian/changelog lakai-0.1/debian/changelog
--- lakai-0.1/debian/changelog
+++ lakai-0.1/debian/changelog
@@ -1,3 +1,10 @@
+lakai (0.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 04 Feb 2021 19:16:16 +0100
+
 lakai (0.1-2) unstable; urgency=medium
 
   * Set maintainer to Debian Multimedia (Closes: #838228)
diff -u lakai-0.1/debian/rules lakai-0.1/debian/rules
--- lakai-0.1/debian/rules
+++ lakai-0.1/debian/rules
@@ -32,7 +32,7 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE)
+   dh_auto_build
#/usr/bin/docbook-to-man debian/lakai.sgml > lakai.1
 
touch build-stamp

Bug#981891: paraview: autopkgtest failure: TypeError: Initialize argument 3: method requires a VTK object

[Adrian Bunk]

Source: paraview
Version: 5.9.0-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/p/paraview/10117274/log.gz

...
autopkgtest [03:43:55]: test paraviewtest.py: [---
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.91pw_4ca/downtmp/build.hgG/src/debian/tests/paraviewtest.py",
 line 5, in 
from paraview.simple import *
  File "/usr/lib/python3/dist-packages/paraview/simple.py", line 41, in 
from paraview import servermanager
  File "/usr/lib/python3/dist-packages/paraview/servermanager.py", line 3290, 
in 
vtkInitializationHelper.Initialize(sys.executable,
TypeError: Initialize argument 3: method requires a VTK object
autopkgtest [03:44:06]: test paraviewtest.py: ---]
autopkgtest [03:44:06]: test paraviewtest.py:  - - - - - - - - - - results - - 
- - - - - - - -
paraviewtest.py  FAIL non-zero exit status 1
autopkgtest [03:44:06]: test paraviewtest.py:  - - - - - - - - - - stderr - - - 
- - - - - - -
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.91pw_4ca/downtmp/build.hgG/src/debian/tests/paraviewtest.py",
 line 5, in 
from paraview.simple import *
  File "/usr/lib/python3/dist-packages/paraview/simple.py", line 41, in 
from paraview import servermanager
  File "/usr/lib/python3/dist-packages/paraview/servermanager.py", line 3290, 
in 
vtkInitializationHelper.Initialize(sys.executable,
TypeError: Initialize argument 3: method requires a VTK object
autopkgtest [03:44:07]:  summary
paraviewtest.py  FAIL non-zero exit status 1

Bug#981890: O: apt-listchanges -- package change history notification tool

[Robert Luberda]

Package: wnpp
Severity: normal

I intend to orphan the apt-listchanges package. I don't have time to
properly maintain it. I will upload 3.23 shortly with maintainer set 
to Debian QA Group.

Regards,
robert



signature.asc
Description: PGP signature

Bug#976862: python3-plaso: log2timeline.py and image_export.py throw many Python 3.9 SyntaxWarnings

[Axel Beckert]

Control: reassign -1 python3-xlsxwriter 1.1.2-0.2
Control: affects -1 python3-plaso

Hi,

Axel Beckert wrote:
> Since the upgrade to Python 3.9, log2timeline.py and image_export.py
> throw the following SyntaxWarnings from the files included by both tools:
> 
> /usr/lib/python3/dist-packages/xlsxwriter/worksheet.py:358: SyntaxWarning: 
> "is" with a literal. Did you mean "=="?
>   if token is '':
> /usr/lib/python3/dist-packages/xlsxwriter/worksheet.py:2437: SyntaxWarning: 
> "is" with a literal. Did you mean "=="?
>   if options['min_type'] is 'min' and options['min_value'] == 0:
> /usr/lib/python3/dist-packages/xlsxwriter/worksheet.py:2440: SyntaxWarning: 
> "is" with a literal. Did you mean "=="?
>   if options['max_type'] is 'max' and options['max_value'] == 0:
> /usr/lib/python3/dist-packages/xlsxwriter/worksheet.py:4999: SyntaxWarning: 
> "is" with a literal. Did you mean "=="?
>   if props[i]['type'] is 'number':
> /usr/lib/python3/dist-packages/xlsxwriter/worksheet.py:6827: SyntaxWarning: 
> "is not" with a literal. Did you mean "!="?
>   if data_bar['bar_axis_position'] is not 'none':
> /usr/lib/python3/dist-packages/xlsxwriter/worksheet.py:6862: SyntaxWarning: 
> "is" with a literal. Did you mean "=="?
>   if data_bar['bar_direction'] is 'left':
> /usr/lib/python3/dist-packages/xlsxwriter/worksheet.py:6865: SyntaxWarning: 
> "is" with a literal. Did you mean "=="?
>   if data_bar['bar_direction'] is 'right':
> /usr/lib/python3/dist-packages/xlsxwriter/worksheet.py:6875: SyntaxWarning: 
> "is" with a literal. Did you mean "=="?
>   if data_bar['bar_axis_position'] is 'middle':
> /usr/lib/python3/dist-packages/xlsxwriter/worksheet.py:6878: SyntaxWarning: 
> "is" with a literal. Did you mean "=="?
>   if data_bar['bar_axis_position'] is 'none':
> /usr/lib/python3/dist-packages/xlsxwriter/chart.py:2497: SyntaxWarning: "is" 
> with a literal. Did you mean "=="?
>   if val is 'right':
> /usr/lib/python3/dist-packages/xlsxwriter/chart.py:2500: SyntaxWarning: "is" 
> with a literal. Did you mean "=="?
>   if val is 'left':

Actually this is an issue in python3-xlsxwriter, not directly in
plaso. Reassigning accordingly.

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#981889: nomad: CVE-2021-3283

[Salvatore Bonaccorso]

Source: nomad
Version: 0.12.9+dfsg1-3
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for nomad.

CVE-2021-3283[0]:
| HashiCorp Nomad and Nomad Enterprise up to 0.12.9 exec and java task
| drivers can access processes associated with other tasks on the same
| node. Fixed in 0.12.10, and 1.0.3.

Some details are in [1] and said to be fixed in 0.12.10 for nomad.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3283
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3283
[1] 
https://discuss.hashicorp.com/t/hcsec-2021-01-nomad-s-exec-and-java-task-drivers-did-not-isolate-processes/20332

Regards,
Salvatore

Bug#981669: Info received (Bug#981669: gettext: incorrect build dependencies for nojava architectures)

[Aurelien Jarno]

Le 04/02/2021 à 16:46, John David Anglin a écrit :

According to , nojava is supposed to 
be a registered
profile name.  However, it doesn't work for Debian ports.  Something must need 
to be setup.

The problem can be seen in the buildd status for gettext:
https://buildd.debian.org/status/package.php?p=gettext=sid

Thoughts?


The buildds are not supposed to use any build profile, so this all looks 
normal to me. build profiles are used for bootstrapping, manual building 
or derivatives.


Aurelien

Bug#981664: buster-pu: package privoxy/3.0.28-2

[Roland Rosenfeld]

Hi Moritz!

On Do, 04 Feb 2021, Moritz Mühlenhoff wrote:

> Am Tue, Feb 02, 2021 at 07:15:37PM +0100 schrieb Roland Rosenfeld:
> > Package: release.debian.org
> > Severity: normal
> > Tags: buster
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > 
> > This fixes CVE-2021-20216 and CVE-2021-20217.
> > Since both are tagged " (Minor issue)" in security tracker, I
> > tend to send this into the next point release of buster.

> yesterday upstream assigned a few additional CVE IDs (also no-dsa):
> https://www.openwall.com/lists/oss-security/2021/02/03/3, maybe you
> also want to fold these in?

You're right, I just did so and updated the buster package to
incorporate all additional patches.

An updated patch is attached.

Greetings
Roland
diff -Nru privoxy-3.0.28/debian/changelog privoxy-3.0.28/debian/changelog
--- privoxy-3.0.28/debian/changelog 2019-01-06 13:07:14.0 +0100
+++ privoxy-3.0.28/debian/changelog 2021-02-04 20:38:58.0 +0100
@@ -1,3 +1,30 @@
+privoxy (3.0.28-2+deb10u1) buster; urgency=medium
+
+  * 38_CVE-2021-20217: Prevent an assertion by a crafted CGI request
+(CVE-2021-20217).
+  * 39_decompress_iob: Fix detection of insufficient data.
+  * 40_CVE-2021-20216: Fix a memory leak (CVE-2021-20216).
+  * 41_CVE-2020-35502: Fixed memory leaks when a response is buffered and
+the buffer limit is reached or Privoxy is running out of memory
+(CVE-2020-35502).
+  * 42_CVE-2021-20209: Fixed a memory leak in the show-status CGI handler
+when no action files are configured (CVE-2021-20209).
+  * 43_CVE-2021-20210: Fixed a memory leak in the show-status CGI handler
+when no filter files are configured (CVE-2021-20210).
+  * 44_CVE-2021-20211: Fixes a memory leak when client tags are active
+(CVE-2021-20211).
+  * 45_CVE-2021-20212: Fixed a memory leak if multiple filters are
+executed and the last one is skipped due to a pcre error (CVE-2021-20212).
+  * 46_CVE-2021-20213: Prevent an unlikely dereference of a NULL-pointer
+that could result in a crash if accept-intercepted-requests was
+enabled, Privoxy failed to get the request destination from the Host
+header and a memory allocation failed (CVE-2021-20213).
+  * 47_CVE-2021-20214: Fixed memory leaks in the client-tags CGI handler
+when client tags are configured and memory allocations fail
+(CVE-2021-20214).
+
+ -- Roland Rosenfeld   Thu, 04 Feb 2021 20:38:58 +0100
+
 privoxy (3.0.28-2) unstable; urgency=medium
 
   * d/tests/privoxy-regression-test: Remove tmpdir on exit.
diff -Nru privoxy-3.0.28/debian/gitlab-ci.yml 
privoxy-3.0.28/debian/gitlab-ci.yml
--- privoxy-3.0.28/debian/gitlab-ci.yml 2019-01-06 13:07:14.0 +0100
+++ privoxy-3.0.28/debian/gitlab-ci.yml 1970-01-01 01:00:00.0 +0100
@@ -1,16 +0,0 @@
-include: 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
-
-build:
-extends: .build-unstable
-
-reprotest:
-extends: .test-reprotest
-
-lintian:
-extends: .test-lintian
-
-autopkgtest:
-extends: .test-autopkgtest
-
-piuparts:
-extends: .test-piuparts
diff -Nru privoxy-3.0.28/debian/patches/38_CVE-2021-20217.patch 
privoxy-3.0.28/debian/patches/38_CVE-2021-20217.patch
--- privoxy-3.0.28/debian/patches/38_CVE-2021-20217.patch   1970-01-01 
01:00:00.0 +0100
+++ privoxy-3.0.28/debian/patches/38_CVE-2021-20217.patch   2021-02-04 
20:38:58.0 +0100
@@ -0,0 +1,34 @@
+commit 5bba5b89193fa2eeea51aa39fb6525c47b59a82a
+Author: Fabian Keil 
+Date:   Sat Jan 30 15:04:17 2021 +0100
+Applied-Upstream: 
https://www.privoxy.org/gitweb/?p=privoxy.git;a=commit;h=5bba5b
+Subject: Prevent an assertion by a crafted CGI request (CVE-2021-20217)
+
+parse_cgi_parameters(): Make sure the maximum number of segments is large 
enough
+
+... for ssplit() to succeed.
+
+Prevents an assertion from getting triggered. OVE-20210130-0001.
+
+Reported by: Joshua Rogers (Opera)
+
+--- a/cgi.c
 b/cgi.c
+@@ -645,16 +645,7 @@ static struct map *parse_cgi_parameters(
+ *  The same hack is used in get_last_url() so it looks like
+ *  a real solution is needed.
+ */
+-   size_t max_segments = strlen(argstring) / 2;
+-   if (max_segments == 0)
+-   {
+-  /*
+-   * XXX: If the argstring is empty, there's really
+-   *  no point in creating a param list, but currently
+-   *  other parts of Privoxy depend on the list's existence.
+-   */
+-  max_segments = 1;
+-   }
++   size_t max_segments = strlen(argstring) / 2 + 1;
+vector = malloc_or_die(max_segments * sizeof(char *));
+ 
+cgi_params = new_map();
diff -Nru privoxy-3.0.28/debian/patches/39_decompress_iob.patch 
privoxy-3.0.28/debian/patches/39_decompress_iob.patch
--- privoxy-3.0.28/debian/patches/39_decompress_iob.patch   1970-01-01 
01:00:00.0 +0100
+++ privoxy-3.0.28/debian/patches/39_decompress_iob.patch   2021-02-04 
20:38:58.0 +0100
@@ -0,0 +1,22 @@

Bug#981888: iwyu FTBFS on mipsel: Linking CXX executable bin/include-what-you-use fails

[Paul Gevers]

Source: iwyu
Version: 8.15-2
Severity: serious
Tags: ftbfs

Hi,

iwyu FTBFS on mispel.

https://buildd.debian.org/status/fetch.php?pkg=iwyu=mipsel=8.15-2=1612343226=0

Maybe the relevant part is this:

[100%] Linking CXX executable bin/include-what-you-use
/usr/bin/cmake -E cmake_link_script
CMakeFiles/include-what-you-use.dir/link.txt --verbose=1
/usr/bin/c++  -fPIC -fno-shrink-wrap -fvisibility-inlines-hidden
-Werror=date-time -w -ffunction-sections -fdata-sections -Wl,-z,relro
-Wl,-rpath-link,  -Wl,-O3 -Wl,--gc-sections
CMakeFiles/include-what-you-use.dir/iwyu.cc.o
CMakeFiles/include-what-you-use.dir/iwyu_ast_util.cc.o
CMakeFiles/include-what-you-use.dir/iwyu_cache.cc.o
CMakeFiles/include-what-you-use.dir/iwyu_driver.cc.o
CMakeFiles/include-what-you-use.dir/iwyu_getopt.cc.o
CMakeFiles/include-what-you-use.dir/iwyu_globals.cc.o
CMakeFiles/include-what-you-use.dir/iwyu_include_picker.cc.o
CMakeFiles/include-what-you-use.dir/iwyu_lexer_utils.cc.o
CMakeFiles/include-what-you-use.dir/iwyu_location_util.cc.o
CMakeFiles/include-what-you-use.dir/iwyu_output.cc.o
CMakeFiles/include-what-you-use.dir/iwyu_path_util.cc.o
CMakeFiles/include-what-you-use.dir/iwyu_preprocessor.cc.o
CMakeFiles/include-what-you-use.dir/iwyu_verrs.cc.o -o
bin/include-what-you-use
-Wl,-rpath,"\$ORIGIN/../lib:/usr/lib/llvm-11/lib" -lpthread
/usr/lib/llvm-11/lib/libclang-cpp.so.11
/usr/lib/llvm-11/lib/libLLVM-11.so.1
CMakeFiles/include-what-you-use.dir/iwyu.cc.o: in function
`std::char_traits::compare(char const*, char const*, unsigned int)':
iwyu.cc:(.text._ZNSt11char_traitsIcE7compareEPKcS2_j[_ZNSt11char_traitsIcE7compareEPKcS2_j]+0x50):
relocation truncated to fit: R_MIPS_CALL16 against `memcmp@@GLIBC_2.0'
CMakeFiles/include-what-you-use.dir/iwyu.cc.o: in function
`std::__cxx11::to_string(int)':
iwyu.cc:(.text._ZNSt7__cxx119to_stringEi[_ZNSt7__cxx119to_stringEi]+0x90):
relocation truncated to fit: R_MIPS_CALL16 against
`std::allocator::allocator()@@GLIBCXX_3.4'
iwyu.cc:(.text._ZNSt7__cxx119to_stringEi[_ZNSt7__cxx119to_stringEi]+0xb8):
relocation truncated to fit: R_MIPS_CALL16 against
`std::__cxx11::basic_string,
std::allocator >::basic_string(unsigned int, char,
std::allocator const&)@@GLIBCXX_3.4.21'
iwyu.cc:(.text._ZNSt7__cxx119to_stringEi[_ZNSt7__cxx119to_stringEi]+0xd4):
relocation truncated to fit: R_MIPS_CALL16 against
`std::allocator::~allocator()@@GLIBCXX_3.4'
iwyu.cc:(.text._ZNSt7__cxx119to_stringEi[_ZNSt7__cxx119to_stringEi]+0xf4):
relocation truncated to fit: R_MIPS_CALL16 against
`std::__cxx11::basic_string,
std::allocator >::operator[](unsigned int)@@GLIBCXX_3.4.21'
CMakeFiles/include-what-you-use.dir/iwyu.cc.o: in function
`llvm::alignTo(unsigned long long, unsigned long long, unsigned long long)':
iwyu.cc:(.text._ZN4llvm7alignToEyyy[_ZN4llvm7alignToEyyy]+0x60):
relocation truncated to fit: R_MIPS_CALL16 against
`__assert_fail@@GLIBC_2.0'
iwyu.cc:(.text._ZN4llvm7alignToEyyy[_ZN4llvm7alignToEyyy]+0x78):
relocation truncated to fit: R_MIPS_CALL16 against `__umoddi3@@GLIBC_2.0'
iwyu.cc:(.text._ZN4llvm7alignToEyyy[_ZN4llvm7alignToEyyy]+0x118):
relocation truncated to fit: R_MIPS_CALL16 against `__udivdi3@@GLIBC_2.0'
CMakeFiles/include-what-you-use.dir/iwyu.cc.o: in function
`llvm::StringRef::strLen(char const*)':
iwyu.cc:(.text._ZN4llvm9StringRef6strLenEPKc[_ZN4llvm9StringRef6strLenEPKc]+0x28):
relocation truncated to fit: R_MIPS_CALL16 against `strlen@@GLIBC_2.0'
CMakeFiles/include-what-you-use.dir/iwyu.cc.o: in function
`llvm::StringRef::str[abi:cxx11]() const':
iwyu.cc:(.text._ZNK4llvm9StringRef3strB5cxx11Ev[_ZNK4llvm9StringRef3strB5cxx11Ev]+0x44):
relocation truncated to fit: R_MIPS_CALL16 against
`std::__cxx11::basic_string,
std::allocator >::basic_string()@@GLIBCXX_3.4.21'
iwyu.cc:(.text._ZNK4llvm9StringRef3strB5cxx11Ev[_ZNK4llvm9StringRef3strB5cxx11Ev]+0x78):
additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
make[4]: *** [CMakeFiles/include-what-you-use.dir/build.make:288:
bin/include-what-you-use] Error 1
make[4]: Leaving directory '/<>/iwyu-build'
make[3]: *** [CMakeFiles/Makefile2:131:
CMakeFiles/include-what-you-use.dir/all] Error 2
make[3]: Leaving directory '/<>/iwyu-build'
make[2]: *** [Makefile:163: all] Error 2
make[2]: Leaving directory '/<>/iwyu-build'
dh_auto_build: error: cd iwyu-build && make -j4 "INSTALL=install
--strip-program=true" VERBOSE=1 returned exit code 2
make[1]: *** [debian/rules:29: override_dh_auto_build] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:21: build-arch] Error 2

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#981887: ITP: ruby-asciidoctor-kroki -- Asciidoctor extension to convert diagrams to images using Kroki

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

Packaging of https://rubygems.org/gems/asciidoctor-kroki

Dependency of gitlab 13.7

Bug#981886: intellij-community-idea build depends on openjdk-8-jdk-headless that will not be in bullseye

[Adrian Bunk]

Source: intellij-community-idea
Version: 183.5153.4-2
Severity: serious
Tags: ftbfs

Migration status: Blocked. Can't migrate due to a non-migratable dependency. 
Check status below.
Build-Depends(-Arch): intellij-community-idea openjdk-8 (not considered)
Invalidated by build-dependency

Bug#981669: Info received (Bug#981669: gettext: incorrect build dependencies for nojava architectures)

[John David Anglin]

On 2021-02-04 10:46 a.m., John David Anglin wrote:
> According to , nojava is supposed 
> to be a registered
> profile name.  However, it doesn't work for Debian ports.  Something must 
> need to be setup.
>
> The problem can be seen in the buildd status for gettext:
> https://buildd.debian.org/status/package.php?p=gettext=sid
If I export DEB_BUILD_PROFILES=nojava, gettext builds successfully with 
dpkg-buildpackage and sbuild on hppa:
https://buildd.debian.org/status/fetch.php?pkg=gettext=hppa=0.21-4=1612467203=0

By itself, gettext does not build with the sbuild --profiles=nojova option.  
This suggests that adding the $build_profiles
option to the sbuild configuration won't work by itself.

Don't know how to address webpage and wanna-build issue.

Regards,
Dave

-- 
John David Anglin  dave.ang...@bell.net

Bug#981867:

[Michael Biebl]

Control: tags -1 + moreinfo

Am I seeing this correctly, that you are using Ubuntu?
In that case, why not file the bug report against Ubuntu?

I also vaguely remember that the closed source NVIDIA drivers can be 
problematic. And since they are closed source and not provided by 
Debian, we can't really provide support for them.


Regards,
Michael





OpenPGP_signature
Description: OpenPGP digital signature

Bug#969516: Please support installing onto f2fs root filesystem

[John Paul Adrian Glaubitz]

On 2/4/21 8:16 PM, Stephan Lachnit wrote:
>> I would be willing to sponsor this but I'm not sure whether such
>> a change would be a good idea a little over a week from the soft
>> freeze.
> 
> Can you sponsor the upload [1] already? This won't add the package
> to the installer, but we will decide to have it include in bullseye
> (which I really hope), we better upload it ASAP to NEW.

Has anyone reviewed the package yet and has there been any input from
other d-i maintainers? I think at least KiBi should give his OK whether
he wants to introduce such a change this late in the release process.

FWIW, someone already tried to upload it without prior coordination
on this mailing list but the upload got rejected because that person
just has DM rights. It's not really okay to make such uploads without
coordination with the d-i team when we're just before the Bullseye
release - although I understand the motivation.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#981725: libdap-dev no longer provides dap-config

[Sebastiaan Couwenberg]

reopen 981725
notfixed 981725 libdap/3.20.7-5
thanks

On 2/4/21 5:39 AM, Sebastiaan Couwenberg wrote:
> On 2/3/21 12:37 PM, Sebastiaan Couwenberg wrote:
>> On 2/3/21 12:03 PM, Sebastiaan Couwenberg wrote:
>>> On 2/3/21 10:48 AM, Gianfranco Costamagna wrote:
 Hello, the new libdap broke in some way the gdal configure script, and now 
 the configure step fails with:

 checking for libqhull/libqhull.h... yes
 checking for qh_new_qhull in -lqhull... no
 configure: error: --with-qhull requested, but library not found!


 I don't really understand what is going on here, looks like qhull is not 
 found anymore.

 libdap might be the library to blame here, feel free to reassign if needed
>>>
>>> libdap-dev no longer provides /usr/bin/dap-config, gdal configure then
>>> adds dap++ to LIBS which breaks the compile test for qhull.
>>>
>>> dap-config should really be provided by libdap-dev instead of
>>> libdap-bin. Or libdap-bin needs to be a dependency of libdap-dev.
>>
>> This is also the cause of the autopkgtest failure which prevents testing
>> migration:
>>
>>  Test-Command: set -e
>>; dap-config --help 2> /dev/null
>>  Depends: libdap-dev
>>
>> The attached patch should fix the issue.
> 
> The patch has been updated with the changed from -4.
> 
> To clarify the issue:
> 
> Moving dap-config* from libdap-dev to libdap-bin is wrong,
> from the Debian Library Packaging guide:
> 
> "
> -DEV package (e.g. libfooX-dev) should contain the development symlink
> used when linking, static libraries, and header files, and if they
> exist, package configuration scripts.
> 
> Table 4.1. Annotated list of files that usually reside in -DEV package
> 
> +--+
> |files |meaning|
> |--+---|
> |usr/lib/*.so  |development linkage file, used when other  |
> |  |programs are linked with -lxxx |
> |--+---|
> |usr/lib/*.a   |static link files  |
> |--+---|
> |usr/lib/*.la  |libtool linkage information file   |
> |--+---|
> |usr/include/* |Development include files  |
> |--+---|
> |usr/bin/*-config  |Some configuration script used in obtaining|
> |  |the library paths, like gtk-config |
> |--+-- |
> |usr/lib/pkgconfig/*.pc|Some information required for pkgconfig|
> +--+
> "
> 
> https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id249952
> 
> Alastair, if you won't move dap-config* back to the -dev package (e.g.
> by applying the attached patch), you must add Depends: libdap-bin to
> libdap-dev to have dap-config available when installing libdap-dev.

Alastair, you should have applied the patch, the changes in -5 are not
sufficient:

 * debian/control

 ** libdap-dev lacks:

Breaks: libdap-bin (<< 3.20.7-5~)
Replaces: libdap-bin (<< 3.20.7-5~)

These need to be added.

 ** libdap-doc still has erroneous Breaks/Replaces:

Breaks: libdap-dev (<< 3.20.7)
Replaces: libdap-dev (<< 3.20.7)

These need to be removed.

 * debian/libdap-bin.install

   Still includes:

   usr/bin/dap-config-pkgconfig
   usr/share/man/man1/dap-config.1

   These should move to libdap-dev.install too.

 * debian/rules

   Installs debian/dap-config.pkg in libdap-bin via
   override_dh_installdocs.

   It should be installed in override_dh_auto_install.

   Now the upstream dap-config is included in libdap-dev and the debian
   one in libdap-bin creating a conflict.

Kind Regards,

Bas

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

Bug#981885: apt: [INTL:nl] Dutch po file for the apt package

[Frans Spiesschaert]

 
 
Package: apt 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the apt package. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#981882: dpkg: [INTL:nl] Dutch po file for the dpkg package

[Frans Spiesschaert]

 
 
Package: dpkg 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the dpkg package. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#981664: buster-pu: package privoxy/3.0.28-2

[Moritz Mühlenhoff]

Am Tue, Feb 02, 2021 at 07:15:37PM +0100 schrieb Roland Rosenfeld:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> This fixes CVE-2021-20216 and CVE-2021-20217.
> Since both are tagged " (Minor issue)" in security tracker, I
> tend to send this into the next point release of buster.

Hi Roland,
yesterday upstream assigned a few additional CVE IDs (also no-dsa):
https://www.openwall.com/lists/oss-security/2021/02/03/3, maybe you
also want to fold these in?

Cheers,
Moritz

Bug#919348: many new releases since -- still "too buggy"?

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2021-02-04 at 14:43 +0200, Adrian Bunk wrote:
> Yves-Alexis, do you have any objections to closing this bug now?

Yes. I have xfce4-screensaver (4.16) running on a Debian sid install and it
still happens every once in a while that the desktop of the locked box appears
(for example at resume). I'm still not confident it should actually be used on
a production install it's just not robust enough, but I don't have the time or
motivation to investigate and fix it myself.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmAcRBUACgkQ3rYcyPpX
RFugAAgA3B0u6cT682/Ks+TPVPy4eW7z9YsrtNz0MS2aMhxsDNbgu4iI2IKviGd2
4z4Pai+0MxlwDA0r5/jFAmyqrsqJ/ze7B0SdoizaDG976/62qQ1+KH8pPeP/h+zJ
1qYxr/8tRubTOaUBEdPoTkPNuzWWpQzKtggsV/J/HpRa7Lr94rsiie+Buig474hS
Wl7oqw1CkCHnBFf8n+ZA9Y9DByqdXS0tNHu3fMeDWDdzl7/pL5J6amJY+sXkYuVo
f0FoFth7GmbKKZKBNhPhjtgyo8Q8kG6A3kSlq8WDqlUeIFbYP/ScmfsjiLhCw4fb
8TjW7HaWaprxaJlAJlrSEmwQHpEqKA==
=JzSz
-END PGP SIGNATURE-

Bug#981881: packaging-tutorial: [INTL:nl] Dutch po file for the packaging-tutorial package's documentation

[Frans Spiesschaert]

 
 
Package: packaging-tutorial 
Severity: wishlist 
Tags: l10n patch 
 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for packaging-tutorial.
It has been submitted for review to the 
debian-l10n-dutch mailing list. Please add it to your next package 
revision. It should be put as "po4a/po/nl.po" in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#981880: RM: mlpack [armel armhf mipsel] -- RoQA; no longer builds with less than 4 GB address space

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

mlpack no longer builds with less than 4 GB address space.

Bug#981835: libelf1 violates Multi-Arch: same / unreproducible

[Simon McVittie]

Control: reopen -1

On Thu, 04 Feb 2021 at 13:34:09 +0100, Helmut Grohne wrote:
> libelf1 is presently marked Multi-Arch: same, but coinstallation on e.g.
> amd64 + mipsel fails with a file conflict:
> 
> | Unpacking libelf1:mipsel (0.182+20210203-1) ...
> | dpkg: error processing archive 
> /tmp/apt-dpkg-install-rORIn3/121-libelf1_0.182+20210203-1_mipsel.deb 
> (--unpack):
> |  trying to overwrite shared 
> '/usr/share/locale/en@boldquot/LC_MESSAGES/elfutils.mo', which is different 
> from other instances of package libelf1:mipsel
> | dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> 
> At its core, this is a reproducible issue that can be easily solved by
> calling dh_strip_nondeterminism.

0.182+20210203-1.1 doesn't seem to solve this as intended, and triggers
a similar failure mode on a more frequently co-installed pair of
architectures:

$ apt-get download libelf1 libelf1:i386
$ aunpack libelf1_0.182+20210203-1.1_amd64.deb
$ aunpack libelf1_0.182+20210203-1.1_i386.deb
$ diff -ru libelf1_0.182+20210203-1.1_*/usr/share/
Binary files 
libelf1_0.182+20210203-1.1_amd64/usr/share/locale/en@boldquot/LC_MESSAGES/elfutils.mo
 and 
libelf1_0.182+20210203-1.1_i386/usr/share/locale/en@boldquot/LC_MESSAGES/elfutils.mo
 differ
Binary files 
libelf1_0.182+20210203-1.1_amd64/usr/share/locale/en@quot/LC_MESSAGES/elfutils.mo
 and 
libelf1_0.182+20210203-1.1_i386/usr/share/locale/en@quot/LC_MESSAGES/elfutils.mo
 differ

smcv

Bug#981879: RFS: austin/2.1.1-1 -- Frame stack sampler for CPython

[Gabriele]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: austin
   Version : 2.1.1-1
   Upstream Author : Gabriele N. Tornetta 
 * URL : https://github.com/P403n1x87/austin
 * License : GPL-3+
 * Vcs : https://github.com/P403n1x87/austin
   Section : devel

It builds those binary packages:

  austin - Frame stack sampler for CPython

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/austin/austin_2.1.1-1.dsc

Changes since the last upload:

 austin (2.1.1-1) unstable; urgency=medium
 .
   Improved general Python support on all the supported platforms.
 .
   Allowed specifying argument for time-like parameters using units (e.g. 10ms).
 .
   Error reporting has been made more accurate and informative.
 .
   Bugfix: Fixed line number reporting.
 .
   Bugfix: Fix symbol name clash on BSD systems with strtonum.

Regards,
-- 
  Gabriele N. Tornetta

Bug#981878: ruby-gitlab-pg-query downloads from the internet during the build

[Adrian Bunk]

Source: ruby-gitlab-pg-query
Version: 1.3.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=ruby-gitlab-pg-query=amd64=1.3.1-2=1612462914=0

...
Building native extensions. This could take a while...
current directory: 
/<>/debian/ruby-gitlab-pg-query/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/gitlab-pg_query-1.3.1/ext/pg_query
["/usr/bin/ruby2.7", "-I", "/usr/lib/ruby/vendor_ruby", "-r", 
"./siteconf20210204-26550-1qve3p5.rb", "extconf.rb"]
ERROR:  Error installing /tmp/d20210204-26547-bcny2z/gitlab-pg_query-1.3.1.gem:
ERROR: Failed to build gem native extension.

current directory: 
/<>/debian/ruby-gitlab-pg-query/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/gitlab-pg_query-1.3.1/ext/pg_query
/usr/bin/ruby2.7 -I /usr/lib/ruby/vendor_ruby -r 
./siteconf20210204-26550-1qve3p5.rb extconf.rb
Building has failed. See above output for more information on the failure.
extconf failed, exit code 1

Gem files will remain installed in 
/<>/debian/ruby-gitlab-pg-query/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/gitlab-pg_query-1.3.1
 for inspection.
Results logged to 
/<>/debian/ruby-gitlab-pg-query/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/extensions/x86_64-linux/2.7.0/gitlab-pg_query-1.3.1/gem_make.out
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=/usr/bin/$(RUBY_BASE_NAME)2.7
/usr/lib/ruby/2.7.0/net/http.rb:960:in `initialize': Failed to open TCP 
connection to codeload.github.com:443 (Network is unreachable - connect(2) for 
"codeload.github.com" port 443) (Errno::ENETUNREACH)
from /usr/lib/ruby/2.7.0/net/http.rb:960:in `open'
from /usr/lib/ruby/2.7.0/net/http.rb:960:in `block in connect'
from /usr/lib/ruby/2.7.0/timeout.rb:95:in `block in timeout'
from /usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
from /usr/lib/ruby/2.7.0/net/http.rb:958:in `connect'
from /usr/lib/ruby/2.7.0/net/http.rb:943:in `do_start'
from /usr/lib/ruby/2.7.0/net/http.rb:932:in `start'
from /usr/lib/ruby/2.7.0/open-uri.rb:346:in `open_http'
from /usr/lib/ruby/2.7.0/open-uri.rb:764:in `buffer_open'
from /usr/lib/ruby/2.7.0/open-uri.rb:235:in `block in open_loop'
from /usr/lib/ruby/2.7.0/open-uri.rb:233:in `catch'
from /usr/lib/ruby/2.7.0/open-uri.rb:233:in `open_loop'
from /usr/lib/ruby/2.7.0/open-uri.rb:174:in `open_uri'
from /usr/lib/ruby/2.7.0/open-uri.rb:744:in `open'
from /usr/lib/ruby/2.7.0/open-uri.rb:50:in `open'
from extconf.rb:19:in `block in '
from extconf.rb:18:in `open'
from extconf.rb:18:in `'
/usr/lib/ruby/2.7.0/net/http.rb:960:in `initialize': Network is unreachable - 
connect(2) for "codeload.github.com" port 443 (Errno::ENETUNREACH)
from /usr/lib/ruby/2.7.0/net/http.rb:960:in `open'
from /usr/lib/ruby/2.7.0/net/http.rb:960:in `block in connect'
from /usr/lib/ruby/2.7.0/timeout.rb:95:in `block in timeout'
from /usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
from /usr/lib/ruby/2.7.0/net/http.rb:958:in `connect'
from /usr/lib/ruby/2.7.0/net/http.rb:943:in `do_start'
from /usr/lib/ruby/2.7.0/net/http.rb:932:in `start'
from /usr/lib/ruby/2.7.0/open-uri.rb:346:in `open_http'
from /usr/lib/ruby/2.7.0/open-uri.rb:764:in `buffer_open'
from /usr/lib/ruby/2.7.0/open-uri.rb:235:in `block in open_loop'
from /usr/lib/ruby/2.7.0/open-uri.rb:233:in `catch'
from /usr/lib/ruby/2.7.0/open-uri.rb:233:in `open_loop'
from /usr/lib/ruby/2.7.0/open-uri.rb:174:in `open_uri'
from /usr/lib/ruby/2.7.0/open-uri.rb:744:in `open'
from /usr/lib/ruby/2.7.0/open-uri.rb:50:in `open'
from extconf.rb:19:in `block in '
from extconf.rb:18:in `open'
from extconf.rb:18:in `'
/usr/lib/ruby/vendor_ruby/gem2deb.rb:54:in `run': /usr/bin/ruby2.7 -S gem 
install --config-file /dev/null --verbose --local --verbose --no-document 
--ignore-dependencies --install-dir 
debian/ruby-gitlab-pg-query/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0 
/tmp/d20210204-26547-bcny2z/gitlab-pg_query-1.3.1.gem (Gem2Deb::CommandFailed)
from /usr/lib/ruby/vendor_ruby/gem2deb/gem_installer.rb:195:in `run_gem'
from /usr/lib/ruby/vendor_ruby/gem2deb/gem_installer.rb:113:in `block 
in install_files_and_build_extensions'
from /usr/lib/ruby/vendor_ruby/gem2deb/gem_installer.rb:61:in `each'
from 

Bug#981877: yasm: Please mark the package with Multi-Arch: foreign or allowed

[Nicholas Guriev]

Package: yasm
Severity: wishlist

Dear Maintainer,

Please add a Multi-Arch field into a paragraph about a binary package to
allow installing for cross-building. When a package build depends on
yasm, it likely would invoke the program on a build machine for
assembling.

I do not fully understand how this field works. But I noticed the cmake,
the dpkg-dev, the make, the perl or the python3.9 packages specify
Multi-Arch: foreign or allowed and "apt build-dep" command installs
their native variants (Build-Depends has no architecture qualifiers).



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

Bug#973659: qtdeclarative5-dev-tools: qmlcachegen segfaults on hppa

[John David Anglin]

On 2021-02-04 1:25 p.m., Dmitry Shachnev wrote:
> I know almost nothing about hppa, and I don’t have much time to debug this,
> but if you provide a patch that will make more tests pass on hppa (and does
> not break other architectures), I will be happy to apply it (and help with
> pushing it upstream).
That's the dichotomy.  I know hppa but not Qt.  It painful to find the parts of 
Qt that
depend on endianness, stack layout, and possibly the NaN representation.
>
> Quick search showed me #810859 which looks like a similar problem in a
> different package.
Yes.  That bug was caused by the different representation of quiet and 
signalling NaNs.

Regards,
Dave

-- 
John David Anglin  dave.ang...@bell.net

Bug#973659: qtdeclarative5-dev-tools: qmlcachegen segfaults on hppa

[Dmitry Shachnev]

Hi John!

On Tue, Feb 02, 2021 at 10:07:52AM -0500, John David Anglin wrote:
> In looking at the JS Value encoding in src/qml/common/qv4staticvalue_p.h,
> I suspect there might be an issue with NaN/Inf values on hppa.  hppa and
> early mips used a different representation for signalling and quiet NaNs.
> This would need to be taken into account in converting between JS and
> hardware values.

Thanks a lot for your investigation!

I know almost nothing about hppa, and I don’t have much time to debug this,
but if you provide a patch that will make more tests pass on hppa (and does
not break other architectures), I will be happy to apply it (and help with
pushing it upstream).

Quick search showed me #810859 which looks like a similar problem in a
different package.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#981876: gdpc: flaky autopkgtest on i386

[Paul Gevers]

Source: gdpc
Version: 2.2.5-10
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, I looked into
the history of your autopkgtest [1] on i386 (because it is blocking
glib2.0) and I noticed it fails regularly, while a rerun passes. I
copied some of the output at the bottom of this report.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Please do get in touch if we need to dive into this together. Or if you
want to discuss this issue. I noticed that all the failed runs I checked
were done on the same worker. Could the problem be a timing issue? (The
worker has a spinning disk and is slower than our other workers).

Paul

https://ci.debian.net/data/autopkgtest/testing/i386/g/gdpc/10255341/log.gz

autopkgtest [04:19:42]: test run-unit-test: [---
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ...
or kill -l [sigspec]
autopkgtest [04:19:52]: test run-unit-test: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976354: git - tests fail with dash

[Nicolas Boulenguez]

Package: git
Followup-For: Bug #976354

The test scripts include test-lib.sh, which deliberately assumes bash.
# checkbashisms test-lib.sh

possible bashism in test-lib.sh line 381 ($BASH_SOMETHING):
 if test -n "$BASH_VERSION" && eval '
This part happens to work for other shells, but the comments around it
suggest that the intent is only to check the bash version.

possible bashism in test-lib.sh line 1491 (builtin):
 builtin pwd -W
The 'builtin' builtin only exists in bash.

So I suggest to apply Bastian’s suggestion:
# sed -i '1 s_^#!/bin/sh$_#!/bin/bash_' t/t*.sh

Bug#981875: RM: r-cran-projpred [armel] -- RoQA; build dependencies are no longer fulfillable on armel

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

The build dependencies are no longer fulfillable on armel.