Bug#955211: release.debian.org: Transition r-base for 4.0.0

[Dylan Aïssi]

Hi,

Le jeu. 28 mai 2020 à 18:58, Dirk Eddelbuettel  a écrit :
>
> Thanks everybody for the help with the transition: 4.0.0-3 is now in testing.
>

\o/

Both transition trackers (r-api-4.0 and r-api-bioc-3.11) were not very
useful to determine the order to update Bioconductor packages.
Some Bioconductor packages were green in the first tracker but red in
the second one, because they were automatically rebuild without an
upgrade.
So, it was not possible to use the first tracker to follow the upgrade
order of Bioconductor packages.
And the second tracker did not consider the r-api-4.0 rebuild order,
so some packages in the first levels were not buildable until the
dependency chain was ready for r-api-4.0.

Next time there is a transition with these two r-api virtual packages,
we should use a unique ben file for them, something like this:

title = "r-api";
is_affected = .depends ~ "r-api-3.5" | .depends ~ "r-api-4.0" |
.depends ~ "r-api-bioc-3.10" | .depends ~ "r-api-bioc-3.11";
is_good = .depends ~ "r-api-4.0" | .depends ~ "r-api-bioc-3.11";
is_bad = .depends ~ "r-api-3.5" | .depends ~ "r-api-bioc-3.10";

Best,
Dylan

Bug#961779: obs-studio: FTBFS when using SIMDE

[Adrian Bunk]

Source: obs-studio
Version: 25.0.8+dfsg1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=obs-studio=sid

...
-- No Native SSE2 SIMD Support - Using SIMDE
...
CMake Error at libobs/CMakeLists.txt:482 (add_library):
  Cannot find source file:

util/simde/check.h
...

Bug#961765: roundcube-core: package needs work for sqlite

[Russell Coker]

Package: roundcube
Version: 1.3.11+dfsg.1-1~deb10u1
Severity: normal

The package install asks questions about MySQL but there's no option for
specifying sqlite.  As sqlite is simpler it should be able to configure all
sqlite stuff if the user selects sqlite as database type.

For reference something like the following in /etc/roundcube/debian-db.php is
all that's needed for it:
$dbtype='sqlite';
$basepath='/var/cache/apache2/roundcube';

Next when you go to the web page for roundcube when using sqlite you get a
database connection error.  To fix that you need /var/lib/roundcube/SQL to be
a symlink to /usr/share/roundcube/SQL .

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages roundcube-core depends on:
ii  dbconfig-common 2.0.11+deb10u1
ii  debconf [debconf-2.0]   1.5.71
ii  dpkg1.19.7
ii  libapache2-mod-php  2:7.3+69
ii  libapache2-mod-php7.0 [libapache2-mod-php]  7.0.33-0+deb9u3
ii  libapache2-mod-php7.3 [libapache2-mod-php]  7.3.14-1~deb10u1
ii  libmagic1   1:5.35-4+deb10u1
ii  php-auth-sasl   1.0.6-3
ii  php-common  2:69
ii  php-intl2:7.3+69
ii  php-mail-mime   1.10.2-0.1
ii  php-net-sieve   1.4.1-1
ii  php-net-smtp1.8.0-1
ii  php-net-socket  1.0.14-2
ii  php-pear1:1.10.6+submodules+notgz-1.1
ii  php7.0-cli [php-cli]7.0.33-0+deb9u3
ii  php7.0-json [php-json]  7.0.33-0+deb9u3
ii  php7.3-cli [php-cli]7.3.14-1~deb10u1
ii  php7.3-intl [php-intl]  7.3.14-1~deb10u1
ii  php7.3-json [php-json]  7.3.14-1~deb10u1
ii  roundcube-sqlite3   1.3.11+dfsg.1-1~deb10u1
ii  ucf 3.0038+nmu1

Versions of packages roundcube-core recommends:
ii  apache2 [httpd-cgi]  2.4.38-3+deb10u3
ii  php-gd   2:7.3+69
pn  php-pspell   
ii  php7.3-gd [php-gd]   7.3.14-1~deb10u1

Versions of packages roundcube-core suggests:
pn  php-crypt-gpg  
pn  php-net-ldap2  
pn  php-net-ldap3  
pn  roundcube-plugins  

Versions of packages roundcube depends on:
ii  dpkg  1.19.7

-- debconf information excluded

Bug#950645: src:gmp, add lib64 for i386 x32 mipsel etc

[Steven Robbins]

On Thu, 6 Feb 2020 15:07:49 +0800 YunQiang Su  wrote:
> Steven Robbins  ?2020?2?6??? ??3:05???
> >
> > On Thursday, February 6, 2020 12:51:23 A.M. CST YunQiang Su wrote:
> > > Steven Robbins  ?2020?2?6??? ??1:23???
> > >
> > > > On Tue, 4 Feb 2020 21:20:59 +0800 YunQiang Su  
wrote:
> > > > > Package: src:gmp
> > > > > Version: 6.2.0+dfsg-3
> > > > >
> > > > > Since binutils/gcc meet some problem due to 2GB/3GB memory 
limitation
> > > > > on 32bit system.
> > > >
> > > > Since GMP has built on all architectures, so I don't understand what
> > > > problem you are trying to solve.   Please enlighten me?
> > >
> > > The 32bit system has 2GiB/3GiB virtual memory space limitation.
> > > When a big object file need to compile/link, the ld/gcc/cc1 may need lots 
of
> > > memory, which may be more than 2GiB/3GiB.
> >
> > I understand that.  I know that some packages have trouble to build.  But 
gmp
> > is not one of them -- it has already built on all architectures.  So I 
don't
> > understand why gmp needs a patch.
> 
> Because gcc builddeps it.

That really doesn't answer my question.  Can you point to a gcc build failure 
that this will solve?



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

Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine

[Paul Wise]

On Thu, May 28, 2020 at 6:33 PM Roland Plüss wrote:

> What path do you think should I choose to be best conform with Debian?

I would package the games into Debian packages so that the source
data/code is available and built by the Debian packaging, using paths
something like /usr/share/dlauncher/games/. For games that don't have
Debian packages (I guess you plan to have a central store or
something), install the games to the ~/.local/share/dlauncher/games/
dir since different users will want different sets of games installed.
You could also add a directory in /usr/local that the sysadmin could
install games to for all users if they want.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#961768: The Vcs-Git field points to the wrong Debian package

[Timo Aaltonen]

On 29.5.2020 6.16, Louis-Philippe Véronneau wrote:
> Package: src:whipper
> Severity: important
> Version: 0.9.0-1+b1
> 
> Hi!
> 
> While investigation another bug I found, I tried to build the package
> from the VCS source and found out the "Vcs-Git" field in debian/control
> actually points to another repository, that ain't this package's
> repository but seems to be another independent packaging effort by
> Krzysztof Krzyzaniak (in CC).
> 
> If this package isn't maintained with git, it would be nice to remove
> the "Vcs-Git" field. If it is, it would be even nicer to push said git
> repository to Salsa (or your preferred hosting platform) for the benefit
> of all.
> 
> Cheers, and thanks again for working on this package, I'm siked.
> 

Hi, the reason was that these were independently packaged, and I didn't
check salsa for creating the git repo until after I had uploaded my
package (oops). The current git has versions that were never uploaded to
the archive, and is now versioned as 0.9.0-3. Also, the repository style
is different to what I'm used to, so I'll let Krzysztof maintain it from
now on :)


-- 
t

Bug#961778: flex: binary-all FTBFS

[Adrian Bunk]

Source: flex
Version: 2.6.4-7
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=flex=all=2.6.4-7=1590040409=0

...
   debian/rules override_dh_installexamples
make[1]: Entering directory '/<>'
I: flex_2.6.4
dh_installexamples
# Clean up embedded build paths in order to ensure reproducible builds.
sed -i  -e "s,-fdebug-prefix-map=/<>=\.,,g" \
-e "s,-ffile-prefix-map=/<>=\.,,g" \
-e "s,abs_.*/<>.*,,g" \
-e "s,/<>.*missing --run,,g" \
-e "s,/<>,./,g" \

/<>/debian/flex/usr/share/doc/flex/examples/fastwc/Makefile \
/<>/debian/flex/usr/share/doc/flex/examples/manual/Makefile
sed: can't read 
/<>/debian/flex/usr/share/doc/flex/examples/fastwc/Makefile: No 
such file or directory
sed: can't read 
/<>/debian/flex/usr/share/doc/flex/examples/manual/Makefile: No 
such file or directory
make[1]: *** [debian/rules:98: override_dh_installexamples] Error 2

Bug#961777: bamtools: binary-all FTBFS

[Adrian Bunk]

Source: bamtools
Version: 2.5.1+dfsg-6
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=bamtools=all=2.5.1%2Bdfsg-6=1590577989=0

...
   dh_auto_install -i
cd obj-x86_64-linux-gnu && make -j4 install 
DESTDIR=/<>/bamtools-2.5.1\+dfsg/debian/tmp AM_UPDATE_INFO_DIR=no 
"INSTALL=install --strip-program=true"
make[1]: Entering directory '/<>/obj-x86_64-linux-gnu'
/usr/bin/cmake -S/<> -B/<>/obj-x86_64-linux-gnu 
--check-build-system CMakeFiles/Makefile.cmake 0
make -f CMakeFiles/Makefile2 preinstall
make[2]: Entering directory '/<>/obj-x86_64-linux-gnu'
make[2]: Nothing to be done for 'preinstall'.
make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
Install the project...
/usr/bin/cmake -P cmake_install.cmake
-- Install configuration: "None"
-- Installing: 
/<>/debian/tmp/usr/include/bamtools/shared/bamtools_global.h
-- Installing: 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig/bamtools-1.pc
CMake Error at src/api/cmake_install.cmake:47 (file):
  file INSTALL cannot find
  "/<>/obj-x86_64-linux-gnu/src/api/libbamtools.so.2.5.1":
  No such file or directory.
Call Stack (most recent call first):
  src/cmake_install.cmake:50 (include)
  cmake_install.cmake:42 (include)


make[1]: *** [Makefile:89: install] Error 1

Bug#961501: remmina is calling home for update notifications

[Andre Heider]

On Wed, 27 May 2020 08:51:40 +0200 Antenore Gatta 
 wrote:

Hi all,

patch is on its way.

Progress can be tracked on our gitlab [0]

Any feedback is much appreciated as it'll easy the resolution of the bug.

Thanks!

Kind regards
Antenore

- [0] https://gitlab.com/Remmina/Remmina/-/merge_requests/2066


Thanks for this, I came here to look specifically for a fix for those 
annoying popups. Glad to see this resolved for the next version!

Bug#959138: nipy: resolve nipy autopkgtest failure due to numpy testing decorators

[Sandro Tosi]

On Wed, 20 May 2020 15:22:37 -0500 Matthieu Clemenceau
 wrote:
> Source: nipy
> Followup-For: Bug #959138
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu groovy ubuntu-patch
>
> Dear Maintainer,
>
> While working on numpy proposed-migration for groovy, I realize nipy
> autopkgtest was failing. It appears that numpy changed the pass to the
> module decorators from numpy.testing.decorators to
> numpy.testing._private.decorators.

OMG NO! how can you think that importing from a _private submodule is
the right approach?!

There's a PR open upstream since more than a month on how to
*properly* address this in nipy:
https://github.com/nipy/nipy/pull/458/files

Can someone from the Med team apply that PR to the packaging and upload?

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#960039: wiki2beamer: diff for NMU version 0.9.5-2

[Boyuan Yang]

Control: tags 960039 + patch
Control: tags 960039 + pending
X-Debbugs-CC: j...@debian.org

Dear maintainer,

I've prepared an NMU for wiki2beamer (versioned as 0.9.5-2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru wiki2beamer-0.9.5/debian/changelog wiki2beamer-
0.9.5/debian/changelog
--- wiki2beamer-0.9.5/debian/changelog  2013-05-26 06:17:33.0 -0400
+++ wiki2beamer-0.9.5/debian/changelog  2020-05-29 00:35:25.0 -0400
@@ -1,3 +1,13 @@
+wiki2beamer (0.9.5-2) unstable; urgency=medium
+
+  * Take over package maintenance via ITS process. (Closes: #960039)
+  * debian/control:
++ Update Vcs-* fields to use git packaging repo under Salsa Debian
+  Group.
++ Use Priority: optional instead of obsolete value extra.
+
+ -- Boyuan Yang   Fri, 29 May 2020 00:35:25 -0400
+
 wiki2beamer (0.9.5-1) unstable; urgency=low
 
   * [c6d5cf3a] Imported Upstream version 0.9.5
diff -Nru wiki2beamer-0.9.5/debian/control wiki2beamer-0.9.5/debian/control
--- wiki2beamer-0.9.5/debian/control2013-05-25 13:28:08.0 -0400
+++ wiki2beamer-0.9.5/debian/control2020-05-29 00:35:03.0 -0400
@@ -1,12 +1,12 @@
 Source: wiki2beamer
 Section: text
-Priority: extra
-Maintainer: Jan Hauke Rahm 
+Priority: optional
+Maintainer: Boyuan Yang 
 Build-Depends: debhelper (>= 7.0.50~)
 Standards-Version: 3.9.4
 Homepage: http://wiki2beamer.sourceforge.net/
-Vcs-Git: git://git.debian.org/collab-maint/wiki2beamer.git
-Vcs-Browser: http://git.debian.org/?p=collab-maint/wiki2beamer.git;a=summary
+Vcs-Git: https://salsa.debian.org/debian/wiki2beamer.git
+Vcs-Browser: https://salsa.debian.org/debian/wiki2beamer
 
 Package: wiki2beamer
 Architecture: all


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

Bug#961776: nmu: openrc_0.42-1

[Boyuan Yang]

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

Since the last upload of package openrc was not a source-only upload,
I'm requesting a binNMU to have amd64 packages rebuilt on buildd.

nmu openrc_0.42-1 . amd64 . unstable . -m "Rebuild on buildd"

-- 
Regards,
Boyuan Yang

Bug#937052: mirage: Python2 removal in sid/bullseye

[Thomas Ross]

I've finished my initial porting efforts and released a 0.10.0 release
candidate here: https://gitlab.com/thomasross/mirage/-/tags/0.10.0-rc1

The port isn't perfect yet, it still uses many deprecated functions, but
I plan on continuing to maintain Mirage and make it more current as time
goes on, this is simply an initial Python3/GTK+3 port.

I will be releasing a final 0.10.0 version in the next few days and then
begin work on packaging it for Debian. If a DD would like to sponsor the
next Mirage upload, please let me know.

Thanks!
Thomas.
Thomas.

On Fri, 27 Mar 2020 22:46:38 +0100 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?=
 wrote:
> On Fri, Jan 03, 2020 at 02:42:22AM -0500, Thomas Ross wrote:
> > I've started to port Mirage to Python 3 + PyGObject here:
> > https://gitlab.com/thomasross/mirage/tree/python3
> 
> What's the status? If this isn't complete, could we upload
> that to experimental and remove mirage from unstable (which
> avoids a roundtrip through the NEW queue), mirage is among
> the last handful of packages blocking the pygtk removal at
> this points.
> 
> Cheers,
> Moritz
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#885353: mirage: Depends on unmaintained pygtk

[Thomas Ross]

I've finished my initial porting efforts and released a 0.10.0 release
candidate here: https://gitlab.com/thomasross/mirage/-/tags/0.10.0-rc1

The port isn't perfect yet, it still uses many deprecated functions, but
I plan on continuing to maintain Mirage and make it more current as time
goes on, this is simply an initial Python3/GTK+3 port.

I will be releasing a final 0.10.0 version in the next few days and then
begin work on packaging it for Debian. If a DD would like to sponsor the
next Mirage upload, please let me know.

Thanks!
Thomas.

On Tue, 26 Dec 2017 10:08:13 -0500 Jeremy Bicha  wrote:
> Source: mirage
> Version: 0.9.5.2-1
> Severity: serious
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs pygtk
> Tags: sid buster
> 
> pygtk is unmaintained upstream. It has not had a release since GNOME 3
> was released in 2011.
> 
> The way forward is to port your app to use GObject Introspection
> bindings (and gtk3).
> 
> For more information on GObject Introspection see [1] and [2].
> 
> Please try to do this before the Buster release as we're going to
> try to remove pygtk this cycle.
> 
> If you have any question don't hesitate to ask.
> 
> [1] https://wiki.gnome.org/Projects/GObjectIntrospection
> [2] https://wiki.gnome.org/Projects/PyGObject
> 
> On behalf of the Debian GNOME team,
> Jeremy Bicha
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#961775: mark node-jquery Multi-Arch: foreign

[Helmut Grohne]

Package: node-jquery
Version: 3.5.1+dfsg-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:abinit src:advi src:akonadi

Around 900 source packages have unsatisfiable cross Build-Depends,
because they transitively depend on node-jquery. I've listed three
example packages in affects. In general, Architecture: all packages can
never satisfy cross Build-Depends unless marked Multi-Arch: foreign. The
problem was made a lot worse recently as cmake-extra-modules switched
its libjs-jquery dependency to node-jquery.  libjs-jquery is already
thus marked, but node-jquery isn't. This makes a large part of the
qt/kde stack fail cross building. Since node-jquery doesn't use any node
extension libraries, we can thus mark it. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru node-jquery-3.5.1+dfsg/debian/changelog 
node-jquery-3.5.1+dfsg/debian/changelog
--- node-jquery-3.5.1+dfsg/debian/changelog 2020-05-06 11:09:20.0 
+0200
+++ node-jquery-3.5.1+dfsg/debian/changelog 2020-05-29 06:04:36.0 
+0200
@@ -1,3 +1,10 @@
+node-jquery (3.5.1+dfsg-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Also mark node-jquery Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 29 May 2020 06:04:36 +0200
+
 node-jquery (3.5.1+dfsg-3) unstable; urgency=medium
 
   * Team upload
diff --minimal -Nru node-jquery-3.5.1+dfsg/debian/control 
node-jquery-3.5.1+dfsg/debian/control
--- node-jquery-3.5.1+dfsg/debian/control   2020-05-05 22:22:29.0 
+0200
+++ node-jquery-3.5.1+dfsg/debian/control   2020-05-29 06:04:30.0 
+0200
@@ -26,6 +26,7 @@
 
 Package: node-jquery
 Architecture: all
+Multi-Arch: foreign
 Depends:
  ${misc:Depends}
 Description: NodeJS wrapper for jQuery

Bug#961774: pbcopper: libpbcopper1.6.0 not built on alpha

[Adrian Bunk]

Source: pbcopper
Version: 1.6.0+dfsg-2
Severity: important
Tags: ftbfs
Control: affects -1 libpbcopper-dev src:pbbam

alpha is missing in the architecture list of libpbcopper1.6.0
in debian/control, which makes libpbcopper-dev not installable
on alpha.

Bug#961772: fossil FTCBFS: attempts to run a host tool to check for sqlite3

[Helmut Grohne]

Source: fossil
Version: 1:2.10-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

fossil fails to cross build from source, because it introduced a new
check for sqlite3 compatibility that runs a host program. Unfortunately,
there is not much we can do here but trust that it actually works when
cross compiling. Please consider applying the attached patch to make
fossil cross buildable again.

Helmut
--- fossil-2.11.orig/auto.def
+++ fossil-2.11/auto.def
@@ -171,9 +171,11 @@
 if {!$ok} {
   user-error "unable to compile SQLite compatibility test program"
 }
-set err [catch {exec-with-stderr ./conftest__} result errinfo]
-if {$err} {
-  user-error $result
+if {[get-define build] eq [get-define host]} {
+  set err [catch {exec-with-stderr ./conftest__} result errinfo]
+  if {$err} {
+user-error $result
+  }
 }
 file delete ./conftest__
   }

Bug#961773: stella FTCBFS: builds for the build architecture

[Helmut Grohne]

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

stella fails to cross build from source, because it builds for the build
architecture. It uses a hand-crafted configure script that doesn't
behave like the usual autoconf ones. Still it consumes the standard
--host option. Unfortunately, it does not derive a tool prefix from the
pass host so cross tools need to be passed separately. Please consider
applying the attached to pass both --host and cross tools. After doing
so, stella cross builds successfully.

Helmut
diff --minimal -Nru stella-6.1.2/debian/changelog stella-6.1.2/debian/changelog
--- stella-6.1.2/debian/changelog   2020-05-23 19:36:27.0 +0200
+++ stella-6.1.2/debian/changelog   2020-05-28 16:30:22.0 +0200
@@ -1,3 +1,10 @@
+stella (6.1.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass both --host and CXX to configure. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 28 May 2020 16:30:22 +0200
+
 stella (6.1.2-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru stella-6.1.2/debian/rules stella-6.1.2/debian/rules
--- stella-6.1.2/debian/rules   2019-07-16 18:06:28.0 +0200
+++ stella-6.1.2/debian/rules   2020-05-28 16:30:22.0 +0200
@@ -2,6 +2,10 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+include /usr/share/dpkg/architecture.mk
+DPKG_EXPORT_BUILDTOOLS=1
+-include /usr/share/dpkg/buildtools.mk
+
 %:
dh $@
 
@@ -11,7 +15,7 @@
dh_auto_clean
 
 override_dh_auto_configure:
-   ./configure --prefix=/usr
+   ./configure --prefix=/usr $(if $(filter 
$(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)),,--host=$(DEB_HOST_GNU_TYPE))
 
 override_dh_auto_install:
dh_auto_install

Bug#961770: whipper reports being version 0.0.0

[Louis-Philippe Véronneau]

Package: whipper
Severity: normal
Version: 0.9.0-1+b1
Tag: patch

Hi!

Running whipper reports the wrong version:

$ whipper --version
> whipper 0.0.0

This is pretty annoying, since it messes up the log files and we can't
modify them manually since they include a checksum :(

Looking at the upstream code, __init.py__ is where the version gets decided:

```
try:
__version__ = get_distribution(__name__).version
except (DistributionNotFound, RequirementParseError):
# not installed as package or is being run from source/git checkout
from setuptools_scm import get_version
__version__ = get_version()
```

So `get_distribution(__name__).version` looks at
whipper-0.0.0.egg-info/PKG-INFO and read the version there, which is 0.0.0

Looking at the upstream issue tracker[1], it seems what should be done
is set SETUPTOOLS_SCM_PRETEND_VERSION during build.

Anyways, all this to say, here's a patch: I've built the package
successfully and it seems to fix the issue.

Cheers!

[1]: https://github.com/whipper-team/whipper/issues/428

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄
diff --git a/debian/control b/debian/control
index 74ef5b4..4be5225 100644
--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,7 @@ Build-Depends:
  python3-dev,
  python3-musicbrainzngs,
  python3-setuptools,
+ python3-setuptools-scm,
 ## tests
 # cd-paranoia,
 # cdrdao,
diff --git a/debian/patches/dont-require-setuptools-scm.diff b/debian/patches/dont-require-setuptools-scm.diff
index b9e69ef..dde5589 100644
--- a/debian/patches/dont-require-setuptools-scm.diff
+++ b/debian/patches/dont-require-setuptools-scm.diff
@@ -2,15 +2,6 @@ diff --git a/setup.py b/setup.py
 index 96bebf5..464cbeb 100644
 --- a/setup.py
 +++ b/setup.py
-@@ -2,7 +2,7 @@ from setuptools import setup, find_packages, Extension
- 
- setup(
- name="whipper",
--use_scm_version=True,
-+#use_scm_version=True,
- description="a secure cd ripper preferring accuracy over speed",
- author=['Thomas Vander Stichele', 'The Whipper Team'],
- maintainer=['The Whipper Team'],
 @@ -10,7 +10,7 @@ setup(
  license='GPL3',
  python_requires='>=3.5',
diff --git a/debian/rules b/debian/rules
index 81fdfa0..fe8518a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+export SETUPTOOLS_SCM_PRETEND_VERSION=$(DEB_VERSION_UPSTREAM)
+
 %:
 	dh $@ --with python3 --buildsystem=pybuild
 


signature.asc
Description: OpenPGP digital signature

Bug#961771: tilde FTCBFS: strips with the build architecture strip

[Helmut Grohne]

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

tilde fails to cross build from source, because make install strips
using the build architecture strip via install -s. Beyond breaking cross
compilation, this also breaks generation of -dbgsym packages as well as
DEB_BUILD_OPTIONS=nostrip. It is best to defer stripping to dh_strip.
Please consider applying the attached patch to fix all of the mentioned
issues.

Helmut
diff --minimal -Nru tilde-1.1.2/debian/changelog tilde-1.1.2/debian/changelog
--- tilde-1.1.2/debian/changelog2019-12-12 06:44:36.0 +0100
+++ tilde-1.1.2/debian/changelog2020-05-28 17:27:05.0 +0200
@@ -1,3 +1,10 @@
+tilde (1.1.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass a non-stripping install to make install. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 28 May 2020 17:27:05 +0200
+
 tilde (1.1.2-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru tilde-1.1.2/debian/rules tilde-1.1.2/debian/rules
--- tilde-1.1.2/debian/rules2019-12-12 06:44:36.0 +0100
+++ tilde-1.1.2/debian/rules2020-05-28 17:27:04.0 +0200
@@ -6,3 +6,6 @@
 
 override_dh_auto_configure:
dh_auto_configure -- --with-verbose-compile
+
+override_dh_auto_install:
+   dh_auto_install -- INSTALL='install --strip-program=true'

Bug#766441: RFA: scala-mode-el -- Emacs major mode for editing scala source code

[Nicholas D Steeves]

Hi Sławomir,

Sławomir Wójcik  writes:

> On 22.05.2020 05:14, Nicholas D Steeves wrote:
>
> I've merged my changes into new repo initialized by gbp import-dsc from 
> the old package, it's here: 
> https://salsa.debian.org/Valdaer/scala-mode-el. Documented all of it in 
> the new changelog entry.
>
> The newly built package is here: 
> https://mentors.debian.net/package/scala-mode-el

Thank you for your work on this package; this one needs a fair bit of
work before it will meet current standards.  Sorry, it's not ready to
sponsor yet.

I'm short on time for the next week, and am exhausted right now, but
here's a very quick review.  Please read it as if I had written "please"
before every point, and sorry it seems terse or vague.  I just wanted to
send you the list of things to work on before I'll have time to review
again--probably in about a week:

Hint to save time: checkout the commit where you merged the upstream
tag, then 'git checkout -b merged-new-upstream-source'.  If ever you
need to rebase you can then rebase against that branch; if you need to
rebase, this will help avoid the sticky mess of non-fastforwarding master
branch that might not be a child of upstream.

Leave the changelog in UNRELEASED state for now.
Push upstream version tags.
Copyright file issues:
  * 2 files stanzas are missing
  * 2 people are missing
  * at least 1 license is missing
  * always dedicate one line to each year[s] copyright_holder_name 
  * "updated license and author" is too vague, and isn't entirely
  accurate (see above).  Also, why did the licenses and authors change?
  Documenting these facts is part of writing a good changelog entry ;-)
  * date ranges can be tricky.  I believe you see the value in combining
  them, but it's also important to guard against false matches.  For a
  small package like this comprehensive detail is expected.
  Silversearcher-ag (or similar) may make it faster to check for (C), ©,
  and Copyright.
Control file issues:
  * revert that section change; editors is correct, lintian's claim
  notwithstanding.  Thank you for reading lintian output, btw.
  * use debhelper-compat 13 (p.s. apt install -t buster-backports
  lintian.  Lintian should have caught this)
  * Standards-Version needs to be updated.  See Debian Policy and its
  upgrading checklist.  Start at the version from the last upload and
  work your way through from there. <- Please defer this until the
  beginning of our next review cycle unless you run out of things to
  do.
  * drop emacs25
  * expand the long description by a line or two (did this version lose
  the ability to send sexps to a scala process?  If so, document it in
  NEWS)  Is it just a boring mode that does very little or does it have
  any outstanding and/or cool features?
- NOTE: if this this new upstream source has less functionality than
the previous one it might be worth documenting the changes.  If it
has a significantly different keymap or workflow, or breaks existing
users' configs then do you think users would appreciate
notification?  If so, read up on the NEWS file (found in
debian/NEWS) and how to use it.
  * missing dummy transitional package, Breaks, and Provides; at present
  an upgrade path has not been provided.
  
elpa-test:
  * nice catch on the ert_eval! :-)

I'll review the changelog in more depth in the next cycle.  eg:

changelog:
  * "Removed old and no longer necessary files" <- removed what, and
  what was it that made it no longer necessary?  Was it part of a larger
  objective?  Was it an upstream change, a change in Debian tooling, a
  change you made, etc.

If you're in a time zone where no one seems to every be active in
#debian-emacs, try #debian-mentors, otherwise someone else on this list
may have the time to point you in the right direction--assuming I'm too
busy.  'hope this list is just the right length, without being too long
or two hard, and that you find the learning process rewarding.  The good
news is that there's a reason for most everything and there should be
high-quality documentation somewhere, the bad news (for people who don't
like to read) is that it's a lot to read and some things can be tricky
to find until one figures out the key words.  Feel free to take as many
breaks and as much time as you need; that said, before 2021 would be
nice--to unblock my ITP for smartparens ;-)


Have fun!
Nicholas


signature.asc
Description: PGP signature

Bug#961769: kernel-patch-grsecurity2: Suggested package: kernel-patch-grsecurity2 is missing from Debian Testing

[hyiltiz]

Package: kernel-patch-grsecurity2
Version: gradm2
Severity: important

gradm2 package description suggests installing kernel-patch-grsecurity2 to have 
grsecurity supported by the kernel.
However, that package is no longer available in Debian (Testing).

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 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

Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock

[Dirk Eddelbuettel]

On 29 May 2020 at 01:13, Mo Zhou wrote:
| Control: severity -1 important
| Control: tags -1 +moreinfo
| Clarification: possibly a Ubuntu bug

You may be right!  I just double checked the earliest report (on the
r-sig-debian list) and it too was on Ubuntu 20.04!

| Hello guys,
| 
| The way to reproduce with docker + ubuntu devel (20.10)
| 
| 1. docker image pull ubuntu:devel
| 2. docker run -ti ubuntu:devel
| 3. apt update -y ; apt upgrade -y
| 4. apt install -y r-base-core
| 5. Rscript -e "example(solve)"  # good with netlib
| 6. apt install -y libopenblas-dev
| 7. Rscript -e "example(solve)"  # hang
| 
| The way to reproduce with nspawn/chroot + ubuntu focal (20.04)
| if you don't have docker
| 
| 1. mkdir Focal
| 2. debootstrap focal Focal/
| 3. systemd-nspawn -D Focal
| 4. apt update -y; apt upgrade -y
| 5. apt install -y r-base-core
| 6. Rscript -e "example(solve)"  # good with netlib
| 7. apt install -y libopenblas-dev
| 8. Rscript -e "example(solve)"  # hang
| 
| The way to reproduce with *. + debian
| 
| 1. Not yet reproducible.

That is ... interesting.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#961768: The Vcs-Git field points to the wrong Debian package

[Louis-Philippe Véronneau]

Package: src:whipper
Severity: important
Version: 0.9.0-1+b1

Hi!

While investigation another bug I found, I tried to build the package
from the VCS source and found out the "Vcs-Git" field in debian/control
actually points to another repository, that ain't this package's
repository but seems to be another independent packaging effort by
Krzysztof Krzyzaniak (in CC).

If this package isn't maintained with git, it would be nice to remove
the "Vcs-Git" field. If it is, it would be even nicer to push said git
repository to Salsa (or your preferred hosting platform) for the benefit
of all.

Cheers, and thanks again for working on this package, I'm siked.

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



signature.asc
Description: OpenPGP digital signature

Bug#961767: transmission-remote-gtk: Add Hash information in Torrent Details > General tab

[Sandro Tosi]

Package: transmission-remote-gtk
Version: 1.4.1-1
Severity: normal
Tags: patch
Control: forwarded -1 
https://github.com/bbarenblat/debian-transmission-remote-gtk/pull/2

Hello,
i've just submitted a patch upstream to add the Hash information to the
General tab of the Torrent details section.

Maybe you also want to apply it to the debian package before upstream release
a new version?

Regards,
Sandro

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

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

Versions of packages transmission-remote-gtk depends on:
ii  libc6   2.30-2
ii  libcurl47.64.0-4
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libgeoip1   1.6.12-1
ii  libglib2.0-02.64.2-1
ii  libgtk-3-0  3.24.5-1
ii  libjson-glib-1.0-0  1.4.4-2
ii  libnotify4  0.7.7-4
ii  libpango-1.0-0  1.42.4-6
ii  libproxy1v5 0.4.15-13

transmission-remote-gtk recommends no packages.

transmission-remote-gtk suggests no packages.

-- no debconf information

Bug#961314: RFP: python3-s2sphere -- Python implementation of a part of the C++ S2 geometry library

[Emmanuel Arias]

Hi!

I would like to ITP under DPMT umbrella


Cheers,
Arias Emmanuel
@eamanu
yaerobi.com

Bug#961760: Inclusion of C-Root Slows Down Some Networks

[Matt Corallo]

Package: dns-root-data
Version: 2019052802

The C-Root is unreachable over IPv6 from some chunk of the Internet due to the 
ongoing (many-year) peering wars between
Cogent and Hurricane Electric/Google. The website for the C root even describes 
the issue and suggests that there is no
desire to address the issue (after all, the C root operator is a party to the 
dispute). This delays DNS requests for
some users. It probably makes sense to patch out at least the v6 entry for the 
C Root.

Bug#961766: Enable reproducible builds by switching to help2man from Debian.

[Vagrant Cascadian]

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

The help2man version shipped in grub embeds timestamps without
respecting the SOURCE_DATE_EPOCH environment variable.

  
https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_manpages_generated_by_help2man_issue.html

The attached patch switches grub to use help2man from Debian, which
generates manpages with a reproducible timestamp.


live well,
  vagrant

From 30203aa2acb600698782127472cbe3f0d499b609 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 29 May 2020 01:58:35 +
Subject: [PATCH] Enable reproducible builds by switching to help2man from
 Debian.

The help2man version shipped in grub embeds timestamps without
respecting the SOURCE_DATE_EPOCH environment variable.
---
 debian/control |  1 +
 debian/rules   | 10 --
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/debian/control b/debian/control
index df10b42..3f3c22e 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,7 @@ Maintainer: GRUB Maintainers 
 Uploaders: Robert Millan , Felix Zielcke , Colin Watson 
 Build-Depends: debhelper-compat (= 12),
  dh-exec,
+ help2man,
  texinfo,
  libncurses5-dev | libncurses-dev,
  gcc-multilib [amd64]
diff --git a/debian/rules b/debian/rules
index 9524c6d..d9658eb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,13 +14,11 @@ override_dh_auto_configure:
 override_dh_auto_build-arch:
 	dh_auto_build
 
-	chmod +x docs/help2man
-
 	## the creation of these manpages here is temporary,
 	## when building grub finally works with the version
 	## of autoconf in debian we can use MAINTAINER_MODE_TRUE
 	# create man page for grub
-	( cd docs && ./help2man \
+	( cd docs && help2man \
 	--name="the grub shell" \
 	--include=grub.8.additions \
 	--section=8 --output=grub.8 \
@@ -28,21 +26,21 @@ override_dh_auto_build-arch:
 
 	# create man page for grub-install
 	( cd util && chmod 755 grub-install )
-	( cd docs && ./help2man \
+	( cd docs && help2man \
 	--name="install GRUB on your drive" \
 	--include=grub-install.8.additions \
 	--section=8 --output=grub-install.8 \
 	../util/grub-install )
 
 	# create man page for mbchk
-	( cd docs && ./help2man \
+	( cd docs && help2man \
 	--name="check the format of a Multiboot kernel" \
 	--section=1 --output=mbchk.1 \
 	../util/mbchk )
 
 	# create man page for grub-md5-crypt
 	( cd util && chmod 755 grub-md5-crypt )
-	( cd docs && ./help2man \
+	( cd docs && help2man \
 	--name="Encrypt a password in MD5 format" \
 	--section=8 --output=grub-md5-crypt.8 \
 	../util/grub-md5-crypt )
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#766441: RFA: scala-mode-el -- Emacs major mode for editing scala source code

[Sławomir Wójcik]

On 22.05.2020 05:14, Nicholas D Steeves wrote:

Hi,

Sławomir Wójcik  writes:


Thanks for the quick reply,



You're welcome :-)  I'm happy I was able to--sometimes it may take a
while to reply.


On 21.05.2020 01:30, Nicholas D Steeves wrote:

Sławomir Wójcik  writes:

[snip]

The issue isn't the "repo" so much as continuity with the existing
source package.  Two people's occasional contributions over three years
are valuable, and erasing them from Debian history would be unjust.

I have imported from dsc by gbp-import-dsc in a new fresh repo, so I
should be able to merge my changes(basically replacing all debian/* files)


More or less, but it's a bit more involved than this, because a large
part of the work of maintaining a package is documenting that work.  At
a minimum, this means one must document changes from the previous
version in debian/changelog.  If you're maintaining the package in git
(highly recommended, and also generally expected for team packages),
then "good git hygiene" means each step is contained within a single
commit.

For example, updating a new upstream version should be one commit.
Adopting the package, or adopting it into the team, should be another.
Adding yourself to Uploaders should be another, etc.  As an example of
when it's ok to combine micro operations, I think it's ok to
combine changing debhelper to debhelper-compat and deleting
debian/compat in a "Switch to debhelper-compat $version" step.

Each of these actions must be documented in debian/changelog.

Your changelog entry (everything from the "package-name
(version-debian_revision)…" line at the top, to the " -- Your Name
 `date -R`" line should be appended to the top of the existing
changelog.  Generally I will use 'dch -v$upstream_version-1' for this.

" * Adopt package. (Closes: #ITA-bug-number)" should be the first line
of the entry.  Then "New upstream version." or "New upstream release.",
as you prefer, and additionally closing a bug if there's a bug
requesting a new version.  Then other items.

Finally, you're welcome to update the changelog all at once at the end,
as a separate commit.  Some people prefer to stage individual changelog
lines with the commit associated with the work.  You don't have to
follow that practise if you don't want to, but if you do then "magit"
can be used to do all your work at once, then stage and commit changes
into discrete commits.

All of this information should already be documented at:

   https://www.debian.org/doc/manuals/maint-guide
   https://www.debian.org/doc/manuals/debmake-doc

Please study those guides.  It's also recommended to look at other
packages from our team for hints, and to get a sense of what the
existing conventions are.  Fair warning: I was taught that " * Bump foo"
was an unacceptable practise.

If someone has a link in-hand to one of the conversations about
" * Bump foo" please share it!


-if we want to adhere to EmacsenTeam Addons packaging policy
(https://wiki.debian.org/EmacsenTeam) and I think we should for better
collaboration and consistency then the package name should be changed to
elpa-scala-mode and existing https://packages.debian.org/sid/scala-mode-el
should be marked as transitional dummy package installing new one, right?


The binary package name should be elpa-scala-mode, but the source
package should remain scala-mode-el.

Actually upstream project name is
emacs-scala-mode(https://github.com/hvesalai/emacs-scala-mode
) rather than
scala-mode-el, but I guess binary package name is more important for
debian users and if source package name will stay the same it won't be
such a big deal, right?


Exactly :-)  When I was a new member I also felt a strong inclination to
rename source packages to sate my desire for correctness, but after a
while I came to agree with more experienced developers; they expressed
to me the perspective that it was a waste of time, and after seeing my
packages wait for months in the "Debian NEW queue", waiting for an
ftpmaster to review the package, I came to understand that source
package renames burden the overworked/understaffed ftpmaster team with
extra work, for little gain.

For more info about why the binary package name is important, read the
dh-elpa and dh-make-elpa documentation, and feel free to ask for
clarification if anything there seems unclear.


-upstream version in existing package and most of debian files are very old
or outdated


Yup, that's part of the work of adopting a package that needs work ;-)


Please, let me know what should be done. As I pointed out here:
https://lists.debian.org/debian-emacsen/2020/05/msg00039.html
it would be the best if someone from Debian Emacsen Packaging Team will work
with me on this and other packages but maybe someone else will be
interested to
give his/her opinion.


If you proceed with this ITP I'd like to work with you and/or comaintain
it, because it's a blocker for my smartparens ITP.

That would be great.

Bug#961763: Missing dependency: sox

[Louis-Philippe Véronneau]

Package: whipper
Severity: important
Version: 0.9.0-1+b1

Hi!

It seems `sox` is also missing from d/control :(

findINFO:whipper.command.cd:ripping track 0 of 22 (try 3): 00 - Hidden
Track One Audio.flac
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/whipper/extern/task/task.py",
line 518, in c
callable_task(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/whipper/common/encode.py", line
45, in _sox_peak
self.peak = sox.peak_level(self.track_path)
  File "/usr/lib/python3/dist-packages/whipper/program/sox.py", line 20,
in peak_level
sox = Popen([SOX, track_path, "-n", "stats", "-b", "16"], stderr=PIPE)
  File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'sox'

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





signature.asc
Description: OpenPGP digital signature

Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock

[Mo Zhou]

Control: severity -1 important
Control: tags -1 +moreinfo
Clarification: possibly a Ubuntu bug

Hello guys,

The way to reproduce with docker + ubuntu devel (20.10)

1. docker image pull ubuntu:devel
2. docker run -ti ubuntu:devel
3. apt update -y ; apt upgrade -y
4. apt install -y r-base-core
5. Rscript -e "example(solve)"  # good with netlib
6. apt install -y libopenblas-dev
7. Rscript -e "example(solve)"  # hang

The way to reproduce with nspawn/chroot + ubuntu focal (20.04)
if you don't have docker

1. mkdir Focal
2. debootstrap focal Focal/
3. systemd-nspawn -D Focal
4. apt update -y; apt upgrade -y
5. apt install -y r-base-core
6. Rscript -e "example(solve)"  # good with netlib
7. apt install -y libopenblas-dev
8. Rscript -e "example(solve)"  # hang

The way to reproduce with *. + debian

1. Not yet reproducible.

Bug#961764: texi2html: texi2html embeds User and Date information in generated .html files

[Vagrant Cascadian]

Package: texi2html
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain timestamps username
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Files generated by texi2html often embed the build user and build date.

The attached patch removes the code which embeds the build date and
build user in order to achieve reproducible builds for the texi2html
package itself, as well as several other packages identified by the
reproducible builds project:

  
https://tests.reproducible-builds.org/debian/issues/unstable/texi2html_captures_users_gecos_issue.html

Maybe additional packages would benefit from this patch as well.


Unfortunately, texi2html appears dead upstream, so I'm not sure there's
anywhere to forward this patch to.


live well,
  vagrant

From: Vagrant Cascadian 
Date: Fri, 29 May 2020 00:27:27 +
X-Dgit-Generated: 1.82+dfsg1-5 990d56af9f181e30e6a2315766afed1040a6ca7b
Subject: Strip out user and date from generated documentation to ensure

reproducible builds.

---

--- texi2html-1.82+dfsg1.orig/texi2html.init
+++ texi2html-1.82+dfsg1/texi2html.init
@@ -1325,25 +1325,6 @@ EOT
 
 sub T2H_DEFAULT_program_string()
 {
-my $user = $Texi2HTML::THISDOC{'user'};
-my $date = $Texi2HTML::THISDOC{'today'};
-$user = '' if (!defined($user));
-$date = '' if (!defined($date));
-if (($user ne '') and ($date ne ''))
-{
-return  &$I('This document was generated by @emph{%{user}} on @emph{%{date}} using @uref{%{program_homepage}, @emph{%{program}}}.', {
-   'user' => $user, 'date' => $date, 'program_homepage' => $Texi2HTML::THISDOC{'program_homepage'}, 'program' => $Texi2HTML::THISDOC{'program'} }, {'duplicate'=>1});
-}
-elsif ($user ne '')
-{
-return  &$I('This document was generated by @emph{%{user}} using @uref{%{program_homepage}, @emph{%{program}}}.', {
-   'user' => $user, 'program_homepage' => $Texi2HTML::THISDOC{'program_homepage'}, 'program' => $Texi2HTML::THISDOC{'program'} }, {'duplicate'=>1});
-}
-elsif ($date ne '')
-{
-return  &$I('This document was generated on @i{%{date}} using @uref{%{program_homepage}, @i{%{program}}}.', {
-   'date' => $date, 'program_homepage' => $Texi2HTML::THISDOC{'program_homepage'}, 'program' => $Texi2HTML::THISDOC{'program'} },{'duplicate'=>1});
-}
 return &$I('This document was generated using @uref{%{program_homepage}, @emph{%{program}}}.', {
'program_homepage' => $Texi2HTML::THISDOC{'program_homepage'}, 'program'
 => $Texi2HTML::THISDOC{'program'} },{'duplicate'=>1});


signature.asc
Description: PGP signature

Bug#961762: firefox-esr: WebRTC broken

[Matt Marjanovic]

Package: firefox-esr
Version: 68.8.0esr-1
Severity: important

Dear Maintainer,

After upgrading firefox-esr to 68.8.0esr-1 (from 68.6.0esr-1 maybe?),
WebRTC is broken.  More specifically, whatever aspect of WebRTC that
does the sending and receiving of audio/video streams to/from other
hosts is not working.  The result is videochats where the browser
neither sends a/v data to other participants, nor receives streams
from other participants.  In my case, this happens reproducibly with
Google Meet, Google Hangouts, Jitsi, and Nextcloud.

Note, however, that stock Firefox 68.8.0esr downloaded directly from
Mozilla works just fine.

Nothing changes (for either the debian-packaged or stock) when run
in safe-mode.

-mm



-- Package-specific info:

-- Extensions information
Name: Amazon.com
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Default theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: eBay
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: HTTPS Everywhere
Location: /usr/share/webext/https-everywhere
Package: webext-https-everywhere
Status: user-disabled

Name: KeePassXC-Browser
Location: /usr/share/webext/keepassxc-browser
Package: webext-keepassxc-browser
Status: user-disabled

Name: Light theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Lightbeam 3.0
Location: /usr/share/webext/lightbeam
Package: webext-lightbeam
Status: user-disabled

Name: Media Panel
Location: ${PROFILE_EXTENSIONS}/{68d048f4-9449-4c97-8425-6dac7f743b14}.xpi
Status: enabled

Name: NoScript
Location: /usr/share/webext/noscript
Package: webext-noscript
Status: user-disabled

Name: Privacy Badger
Location: /usr/share/webext/privacy-badger
Package: webext-privacy-badger
Status: user-disabled

Name: Twitter
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: uBlock Origin
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ublo...@raymondhill.net
Package: webext-ublock-origin
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

-- Plugins information
Name: Shockwave Flash (32.0.0.371)
Location: /usr/lib/flashplayer-mozilla/libflashplayer.so
Package: flashplayer-mozilla
Status: enabled



-- Addons package information
ii  firefox-esr  68.8.0esr-1   amd64Mozilla Firefox web
browser - Extended Support Release (ESR)
ii  flashplayer-mozilla  3:32.0.0.371-dmo3 amd64Adobe Flash Player
ii  webext-https-everywhere  2020.3.16-1   all  Extension to force
the use of HTTPS on many sites
ii  webext-keepassxc-browser 1.6.3+repack1-1   all  Web browser
extension to organize web site credentials in KeePassXC
ii  webext-lightbeam 3.0.1-1   all  visualize sites
that may be tracking you around the internet
ii  webext-noscript  10.1.9.6-2all  permissions manager
for Firefox
ii  webext-privacy-badger2020.5.12-1   all  Privacy Badger
automatically learns to block invisible trackers
ii  webext-ublock-origin 1.22.2+dfsg-2 all  general-purpose
lightweight ads, malware, trackers blocker (Web Extension)

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.9.1
ii  fontconfig2.13.1-4.2
ii  libasound21.2.2-2.1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.30-8
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-2
ii  libdbus-glib-1-2  0.110-5
ii  libevent-2.1-72.1.11-stable-1
ii  libffi7   3.3-4
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.10.1-2
ii  libgcc-s1 10.1.0-2
ii  libgdk-pixbuf2.0-02.40.0+dfsg-4
ii  libglib2.0-0  2.64.2-1
ii  libgtk-3-03.24.20-1
ii  libjsoncpp1   1.7.4-3.1
ii  libnspr4  2:4.25-1
ii  

Bug#961745: [Pkg-utopia-maintainers] Bug#961745: udisks2 2.9.0-1 problems

[Michael Biebl]

Apparently doublecmd calls udisksctl mount -b
I'm not really speaking Pascal: Maybe it is parsing the output of that
command (which is brittle).
I notice the difference between 2.8.x and 2.9.x

2.8.x:
udisksctl mount -b /dev/sdb2
Mounted /dev/sdb2 at /media/michael/Test.

2.9.x:
udisksctl mount -b /dev/sdb2
Mounted /dev/sdb2 at /media/michael/Test

(note the missing '.')

Maybe doublecmd get's confused by that.



signature.asc
Description: OpenPGP digital signature

Bug#961745: [Pkg-utopia-maintainers] Bug#961745: udisks2 2.9.0-1 problems

[Michael Biebl]

Control: reassign -1 doublecmd-gtk

[again, please CC the bug report on replies]

Am 29.05.20 um 00:05 schrieb Сергей Фёдоров:
> Installed the udisks2 package version 2.8.4-2
> Mounted all 4 disks via doublecmd. All disks were mounted normally.
> Rebooted Debian 10.4.
> Installed the udisks2 package version 2.9.0-1. Mounted all 4 disks via 
> doublecmd.
> When attempting to mount disk "H", the message" Transition to /media/u1/H 
> failed "is displayed and device" H "is being mounted" H1 "in the"/media/u1/H1 
> " directory. And so for all disks. Accordingly,
> D1 with the message "Transition to the /media/u1/D directory failed".
> E-D1 with the message "Transition to the /media/u1/E-D directory failed".
> S11 with the message "Transition to the /media/u1/S1 directory failed".
> And, for some reason, S2, not S21 with the message "Transition to the 
> directory /media/u1/S failed".
> Rebooted Debian 10.4.
> And so around the circle 3 more times.
> Installed the udisks2 package version 2.8.4-2
> Mounted all 4 disks via doublecmd. All disks were mounted normally.
> Rebooted Debian 10.4.
> Installed the udisks2 package version 2.9.0-1. Mounted all 4 disks via 
> doublecmd.
> When attempting to mount the "S1" partition, the message "Transition to the 
> /media/u1/H directory failed" is displayed, and the "S1" device is mounted 
> "S11 "in the"/media/u1/S11 " directory. All other disks are mounted normally.
> Rebooted Debian 10.4.
> Mounted all 4 disks via doublecmd. All disks were mounted normally. And it's 
> been working fine ever since.
> Question — what happened?
> Answer: I don't know!

Let's reassign this to doublecmd, this apparently is the program
triggering this error message.

Dear doublecmd maintainer, please reassign back, if this turns out to be
a genuine udisks problem.

Michael



signature.asc
Description: OpenPGP digital signature

Bug#961761: psmisc: killall fails to kill processes with names longer than 15 characters

[Frank Heckenbach]

Package: psmisc
Version: 23.2-1
Severity: serious

killall fails to kill processes with names longer than 15
characters.

According to the manpage:

  -e, --exact
 Require an exact match for very long names.  If a command
 name is longer than 15 characters, the full name may be
 unavailable (i.e.  it is swapped  out). In  this case,
 killall will kill everything that matches within the first
 15 characters.  With -e, such entries are skipped.  [...]

So without "-e" it should kill everything that matches within the
first 15 characters.

That was apparently the behaviour in previous versions, but that's
broken now. To reproduce:

(echo "#!/bin/sh"; echo "while true; do sleep 1; echo 'Still running!'; done") 
> killall-bug-with-long-names-demo
chmod 755 killall-bug-with-long-names-demo
./killall-bug-with-long-names-demo &
killall killall-bug-with-long-names-demo

I think that's at least "serious", because it makes killall by name
basically unusable, at least in automated contexts, unless you want
to replace:

  killall "$x"

everywhere with some beast such as (untested):

  killall "$(echo "$x" | cut -c-15)"

It could even have more adverse consequences if you rely on a script
killing some process with killall, which has worked before and
breaks now, especially if this process continues to waste resources
or give access to privileges you meant to stop etc. (That's almost
what happened to me when I found the problem, though in my case the
worst thing it caused, fortunately, was blocking a network port.)

In the worst case, this could be security-critical. (Not sure if
this justifies "grave"!?)

Sure, you may say one should check the status of each command,
including killall, but that's hard to do when the status is the
same (1) as in the case when the program isn't running at all, so
one would have to check with something like pidof before (which does
still find long program names), worry about race-conditions etc.

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

Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE=de_DE 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages psmisc depends on:
ii  libc62.28-10
ii  libselinux1  2.8-1+b1
ii  libtinfo66.1+20181013-2+deb10u2

psmisc recommends no packages.

psmisc suggests no packages.

-- debconf-show failed

Bug#936798: Please port KisSplice to Python3 (Was: Bug#936798: kissplice: Python2 removal in sid/bullseye)

[Nilesh Patra]

Hi,

On Fri, 29 May 2020, 01:08 Andreas Tille,  wrote:

> Hi Moritz,
>
> On Thu, May 28, 2020 at 08:48:41PM +0200, Moritz Mühlenhoff wrote:
> >
> > JFTR, this is now fixed upstream in 2.5.0 and later:
> > http://kissplice.prabi.fr/download/:
> >
> > --
> > Kissplice Version 2.5.0 (2020-04-06)
> >
> > New features:
> >Now compatible with python3
> > --
>
> Thanks for the hint.  Unfortunately there are remaining issues
> in build time test and autopkgtest. even of version 2.5.1 .:-(
>

I've Fixed the autopkgtest

For the failing build tests: this is what I observe - this try matching
strings containing a few values with kissplice result.

For instance,  this is one of the failures:

Expected:
0a: Single SNPs, Inexact Repeats or sequencing substitution errors, 69 found

Actual:
0a: Single SNPs, Inexact Repeats or sequencing substitution errors, 22 found

There's definitely a difference between the outputs of previous kissplice
version and current kissplice version, I tried this manually as well.

Just _maybe_, the upstream data has been changed, and the correct data
hasn't been injected; or the implementation has changed in version,
2.5.1and this should output 22, but the tests haven't been changed
accordingly ; or maybe this is a bug with kissplice itself.

In either case, I'm not really about this. Maybe we should ask upstream
about it.

Thanks and regards
Nilesh

Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine

[Roland Plüss]

Hi,

> Hi,
>
> Long story short, this hasn't reached a satisfactory quality. I will
> point out issues
> I found but there are more to fix.

> * Please make sure the debian/files file does not exist in your packaging
added "rm" to the clean step.

> * Your debian/postinst script is missing the #DEBHELPER# placeholder.
fixed

> * Your debian/postinst file has to recognize whether it is being
called during installation, upgrade or removal.
modified the postinst to operate only on "configure"

> * Official Debian packages in "main" section should not manipulate
files under /opt/ directory at any time.
this one will be interesting. the /opt/delauncher/games is where the
user installs to the games he wants to play. in my opinion these are
optional packages the user manually installs and uninstalls.

That said this path can be configured at compile time. According to a
page on the internet about FHS+Games
(http://www.roguebasin.com/index.php?title=Filesystem_hierarchy_standard_for_game_developers)
these possible locations are named (terms I used from that page):

- /usr/games/: standard installation

- /usr/share/games/: architecture-independent static game data

"*.delga" files contain by definition no binary code, only data and
script code (depending on what the developer chooses) and thus are never
executable. From this point of view the "architecture-independent static
game data" directory seems a suitable choice. This directory would then
be /usr/share/games/delauncher/games .

But the user (I choose group "games" to be part of) has to have write
access to this directory so he can install/uninstall *.delga files. In
this situation the "standard installation" seems better. This would then
be /usr/games/delauncher/games .

What path do you think should I choose to be best conform with Debian?

> * You are using "3.0 (native)" format, which is not suitable for a
non-Debian-specific project.
modified file.

> * Your "Build-Depends" field is missing way too many build dependencies.
Looks like the changes to debian/control did not commit correctly.
Pardon me for having overlooked this. I'll fix it right away.

> * Your package bundles way too many external libraries under /extern/
directories.
These are used for the "live-mode" build. Only three of them are
actually used because the respective debian package is not existing or
failing configure. I've added now "debian/source/options" with
"tar-ignore" lines for each not used external file. I hope this helps.

I'll re-upload with these changes. I would then appreciate more
reviewing to iron out the remaining problems as good as i can.

-- 

Mit freundlichen Grüssen

Plüss Roland

Game Development and Game Engine Technologies https://dragondreams.ch




signature.asc
Description: OpenPGP digital signature

Bug#961729: education-networked-common: Please remove Recommends: haveged

[Chris Hofstaedtler]

* Wolfgang Schweer  [200528 18:56]:
> On Thu, May 28, 2020 at 01:25:25PM +, Holger Levsen wrote:
> > On Thu, May 28, 2020 at 03:24:22PM +0200, Chris Hofstaedtler wrote:
> > > The topic came up on IRC, and for me it is about removing bloat from
> > > ("default") installs.
> 
> d-i still uses haveged-udeb, see:
> https://lists.debian.org/debian-boot/2020/03/msg00207.html 
> for the latest mail on this issue.
> 
> Please correct me if I'm wrong.

In my tests, in a KVM VM with cpu=core2duo (no RDRAND), with Linux
5.6.0-2-amd64, the "crng init done" message appears ~7sec
after boot, at the same time as systemd tries to mount the so-called
"Root and Kernel File Systems", so before haveged would start.

Notably, there is no boot hang/delay caused by this.

Sure, if the VM has a HWRNG attached, the "crng init done" message
appears a lot earlier, but as long as nothing blocks, then there's
no point of having haveged.

Chris

Bug#953745: stretch-pu: package proftpd-dfsg/1.3.5b-4+deb9u5

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Tue, 2020-05-19 at 09:07 +0200, Hilmar Preuße wrote:
> Am 09.05.2020 um 16:22 teilte Adam D. Barratt mit:
> > On Sat, 2020-05-09 at 15:57 +0200, Hilmar Preuße wrote:
> 
> Hi Adam,
> 
> > > Ho about that one: will deb9u5 accepted for next oldstable
> > > release?
> > 
> > As Julien mentioned in a mail that you should have received on
> > April 26th, if you want to remove the debconf calls in stretch then
> > they need to be removed in unstable first.
> > 
> I did not get any many from Julien.

Apparently web.de has blacklisted his mail server (and/or surrounding
network) for some reason.

> Anyway: I've uploaded the requested
> change to Debian unstable yesterday. Is this sufficient to get deb9u5
> into oldstable?
> 

Sure, please go ahead.

Regards,

Adam

Bug#961759: libpbcopper1.6.0: missing Breaks+Replaces: libpbcopper1.3.0 (>= 1.6)

[Andreas Beckmann]

Package: libpbcopper1.6.0
Version: 1.6.0+dfsg-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

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

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

  Preparing to unpack .../libpbcopper1.6.0_1.6.0+dfsg-3_amd64.deb ...
  Unpacking libpbcopper1.6.0:amd64 (1.6.0+dfsg-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libpbcopper1.6.0_1.6.0+dfsg-3_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libpbcopper.so.1.6.0', which 
is also in package libpbcopper1.3.0:amd64 1.6.0+dfsg-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libpbcopper1.6.0_1.6.0+dfsg-3_amd64.deb

It's only neccessary to break the buggy libpbcopper1.3.0 shipping the wrong
soname. Co-installation with the version in testing is fine.

cheers,

Andreas


libpbcopper1.3.0=1.6.0+dfsg-1_libpbcopper1.6.0=1.6.0+dfsg-3.log.gz
Description: application/gzip

Bug#702914: CVE-2013-1841 still unsolved?

[Rob Brown]

Oh, you're right! The code still appears to be bad to me.

Please provide a patch that performs a gethostbyname() on the
gethostbyaddr() to compare to ensure it matches the $addr before gleefully
bricking over {'peerhost'}.

On Thu, May 28, 2020 at 2:25 PM Petter Reinholdtsen  wrote:

> [Rob Brown]
> > Is this Issue still open? Is it still a problem in the latest version?
> > Or can I close this RT Ticket now?
>
> The code in question seem to be this section from Net/Server.pm version
> 2.009:
>
> if ($addr && defined $prop->{'reverse_lookups'}) {
> if ($INC{'Socket6.pm'} && Socket6->can('getnameinfo')) {
> my @res = Socket6::getnameinfo($addr, 0);
> $prop->{'peerhost'} = $res[0] if @res > 1;
> }else{
> $prop->{'peerhost'} = gethostbyaddr($addr, AF_INET);
> }
> }
>
> As far as I can tell, it only do reverse lookup without comparing it to
> the addresses returned by a lookup of the name returned by the reverse
> lookup, which seem to be the problem described in the CVE.
>
> In short, I believe the problem from 2013 still is unsolved in version
> 2.009, but do not know the code and might have overlooked something.
>
> --
> Happy hacking
> Petter Reinholdtsen
>

Bug#961758: Missing dependency: cdrdao

[Louis-Philippe Véronneau]

Package: whipper
Severity: important
Version: 0.9.0-1+b1

Hi!

Thank you so much for packaging whipper, it makes me really happy.

It seems there is a missing dependency in the current sid version:

foo@bar:~/git/whipper/man$ whipper offset find
INFO:whipper.command.offset:checking device /dev/sr0
CRITICAL:whipper.command.main:exception FileNotFoundError at
/usr/lib/python3.8/subprocess.py:1702: _execute_child(): [Errno 2] No
such file or directory: 'cdrdao'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/whipper/extern/task/task.py",
line 506, in _startWrap
task.start(self)
  File "/usr/lib/python3/dist-packages/whipper/program/cdrdao.py", line
98, in start
self._popen = asyncsub.Popen(cmd,
  File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'cdrdao'


By installing the 'cdrdao' package this command seems to run fine.

Thanks again,

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



signature.asc
Description: OpenPGP digital signature

Bug#961757: zsh-doc: Please install the FAQ

[Daniel Shahaf]

Package: zsh-doc
Version: 5.8-4
Severity: wishlist

Dear Maintainer,

Please consider building and installing the upstream FAQ as well.

Currently, the following get installed:

usr/share/doc/zsh-common/html/The-Zsh-FAQ.html
usr/share/doc/zsh-common/META-FAQ

But neither of these is the FAQ.  The first one is a section in the
zsh(1) man page; the latter is the META-FAQ, generated from
Doc/META-FAQ.yo, as opposed to the FAQ, which is generated from,
Etc/FAQ.yo.

The following seems to do the trick, but I suspect a change to
debian/zsh-doc.doc-base is needed as well.

diff --git a/debian/rules b/debian/rules
index 557d0ee..a1b6bc3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -63,6 +63,7 @@ build-static:
 
 override_dh_auto_build-indep:
dh_auto_build -B obj -- pdf
+   $(MAKE) -C obj/Etc # FAQ
 
 override_dh_auto_test-arch:
if dpkg-architecture -qDEB_BUILD_ARCH_OS | grep -qv hurd; then \
diff --git a/debian/zsh-doc.docs b/debian/zsh-doc.docs
index 60cb238..1611c61 100644
--- a/debian/zsh-doc.docs
+++ b/debian/zsh-doc.docs
@@ -1 +1,2 @@
 obj/Doc/zsh.pdf
+obj/Etc/FAQ*

With this, the following are also built and installed:

usr/share/doc/zsh-common/FAQ06.html
usr/share/doc/zsh-common/FAQ05.html
usr/share/doc/zsh-common/FAQ04.html
usr/share/doc/zsh-common/FAQ03.html
usr/share/doc/zsh-common/FAQ02.html
usr/share/doc/zsh-common/FAQ01.html
usr/share/doc/zsh-common/FAQ.html
usr/share/doc/zsh-common/FAQ.gz

Cheers,

Daniel

Bug#958668: u-boot: Please consider enabling rpi4 support

[Andreas Henriksson]

Control: forwarded -1 https://salsa.debian.org/debian/u-boot/-/merge_requests/11

Hello,

I've updated the patch and sent it as a merge-request on salsa instead.
I listed both me and Lucas as contacts for the rpi_4 target.

Regards,
Andreas Henriksson

Bug#961442: stretch-pu: package libclamunrar/0.102.3-0+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-05-24 at 17:47 +0200, Sebastian Andrzej Siewior wrote:
> As part of clamav's new 0.102.3 they also updated their unrar code to
> version 5.9.2, the previous version was based on 5.6.5. I can't tell
> based on the diff if it contains any code fixes or improved support
> of the rar archive. rarlabs / upstream does not provide a revision
> history (or it does and I I did not find it).
> 
> As part of this update I also introduce the `libclamunrar' package
> which only purpose is to depend on libclamunrar9. On the last soname
> bump not everyone noticed that the soname of libclamunrar changed and
> ended up with no unrar support. Due to its non-free nature we can't
> depend on it so it has been suggested to use this package which will
> remain on the next soname bump and pull-in the new libclamunrarX
> library.
> 

Please go ahead.

Regards,

Adam

Bug#961755: dh-golang: dh_golang_autopkgtest no longer detects debian/rules targets with make-4.3

[Michael Banck]

On Thu, May 28, 2020 at 09:57:04PM +0200, Michael Banck wrote:
> with make_4.2.3-1:

I meant 4.2.1-1.3.
 
> |# make -pRrq -f debian/rules : | awk -v RS= -F: '/^# File/,/^# Finished Make 
> data base/ { if ($1 !~ "^[#.]") {print $1} }'
> |
> |autopkgtest
> |build
> |override_dh_auto_test
> |override_dh_installsystemd
> |debian/rules
> |override_dh_installinit
> |#
> 
> with make_4.3-1:
> 
> |# make -pRrq -f debian/rules : | awk -v RS= -F: '/^# File/,/^# Finished  
> Make data base/ { if ($1 !~ "^[#.]") {print $1} }'
> |#
> 
> i.e. no output.

The difference is in the make output; make-4.2.1-1.3 puts a new line
before '# Files', like:

|# 1 implicit rules, 0 (0.0%) terminal.
|
|# Files

But make-4.3 no longer does that:

|# 1 implicit rules, 0 (0.0%) terminal.
|# Files

That (in combination with setting RS to empty and IFS to :) makes awk's
pattern-match no longer find /^# File/.

Not sure what the best fix would be.


Michael

Bug#961729: education-networked-common: Please remove Recommends: haveged

[Wolfgang Schweer]

On Thu, May 28, 2020 at 10:17:37PM +0200, Petter Reinholdtsen wrote:
> I tried searching the web for information about the added entropy
> sources in the kernel, but came up short

Maybe this one::
https://github.com/torvalds/linux/blob/master/crypto/jitterentropy.c

Wolfgang


signature.asc
Description: PGP signature

Bug#961441: buster-pu: package libclamunrar/0.102.3-0+deb10u1

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Thu, 2020-05-28 at 14:20 +0200, Sebastian Andrzej Siewior wrote:
> On 2020-05-27 22:28:44 [+0100], Adam D. Barratt wrote:
> > Control: tags -1 + moreinfo
> > 
> > On Sun, 2020-05-24 at 17:47 +0200, Sebastian Andrzej Siewior wrote:
> > > As part of this update I also introduce the `libclamunrar'
> > > package
> > > which only purpose is to depend on libclamunrar9. On the last
> > > soname
> > > bump not everyone noticed that the soname of libclamunrar changed
> > > and
> > > ended up with no unrar support. Due to its non-free nature we
> > > can't
> > > depend on it so it has been suggested to use this package which
> > > will
> > > remain on the next soname bump and pull-in the new libclamunrarX
> > > library.
> > 
> > Does anything pull the metapackage in on user systems, or is the
> > assumption that they will read the changelog and install it?
> 
> Not yet. In packaging git for clamav there has been a Suggests: added
> for libclamunrar. This is as far as we can go given the non-free
> nature.
> I didn't add the Suggests to the clamav package for (old)-stable
> because we don't have it in unstable just yet and I didn't want to
> upload it with this as the only change.
> If you approve / prefer / makes sense I could go ahead and add it to
> the pu before we have it in unstable.

I meant more from the perspective of existing users of libclamunrar,
for those who previously missed the package name change and would
benefit most from the metapackage. I'm not sure what specifically would
help, though.

I'd be OK with the Suggests from the clamav side, assuming it is going
to end up in unstable before too long.

> > > This version of libclamunrar was in unstable 20th. I didn't
> > > backport the packaging related changes while preparing this
> > > version (I did include the update of the copyright file).
> > 
> > There seem to be a few, e.g. the removal of the dh_auto_install
> > override, the dropping of "--disable-clamav --without-pcre" from
> > the configure invocation, and most of the Build-Depends being
> > removed.
> 
> The override of dh_auto_install was required to remove the .la files
> so they don't end up in the final package. With the addition of the
> package, the folders changed and so the removal is no longer
> required.
> 
> The libclamunrar is a split of the clamav package and historically
> included its (clamav's) configure.ac with the required m4 folder and
> a stripped down Makefile.am. The only reason why pcre was disabled or
> libssl-dev listed as a dependency was to keep the configure script
> happy. None of this was really required by the libclamunrar package.

Thanks for explaining. It would have helped to include that information
in the original request. :-) (I'm not sure if it's worth noting in the
changelog.)

Please feel free to go ahead.

Regards,

Adam

Bug#961756: glib-networking: CVE-2020-13645: GTlsClientConnection silently ignores unset server identity

[Salvatore Bonaccorso]

Source: glib-networking
Version: 2.64.2-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/glib-networking/-/issues/135

Hi,

The following vulnerability was published for glib-networking.

CVE-2020-13645[0]:
| In GNOME glib-networking through 2.64.2, the implementation of
| GTlsClientConnection skips hostname verification of the server's TLS
| certificate if the application fails to specify the expected server
| identity. This is in contrast to its intended documented behavior, to
| fail the certificate verification. Applications that fail to provide
| the server identity, including Balsa before 2.5.11 and 2.6.x before
| 2.6.1, accept a TLS certificate if the certificate is valid for any
| host.


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-2020-13645
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13645
[1] https://gitlab.gnome.org/GNOME/glib-networking/-/issues/135

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#702914: CVE-2013-1841 still unsolved?

[Petter Reinholdtsen]

[Rob Brown]
> Is this Issue still open? Is it still a problem in the latest version?
> Or can I close this RT Ticket now?

The code in question seem to be this section from Net/Server.pm version
2.009:

if ($addr && defined $prop->{'reverse_lookups'}) {
if ($INC{'Socket6.pm'} && Socket6->can('getnameinfo')) {
my @res = Socket6::getnameinfo($addr, 0);
$prop->{'peerhost'} = $res[0] if @res > 1;
}else{
$prop->{'peerhost'} = gethostbyaddr($addr, AF_INET);
}
}

As far as I can tell, it only do reverse lookup without comparing it to
the addresses returned by a lookup of the name returned by the reverse
lookup, which seem to be the problem described in the CVE.

In short, I believe the problem from 2013 still is unsolved in version
2.009, but do not know the code and might have overlooked something.

-- 
Happy hacking
Petter Reinholdtsen

Bug#961729: education-networked-common: Please remove Recommends: haveged

[Petter Reinholdtsen]

[Chris Hofstaedtler]
> your package currently Recommends: haveged. On modern kernels, so
> whatever will ship in bulleye, the kernel will provide enough entropy,
> so there should be no need for haveged, except in exceptional
> situations.

This sound very good indeed.  Where can I read more about the entropy
sources enabled in the Linux kernel by default for the bullseye kernel?

Earlier we ran into problems with low entropy on LTSP machine (aka
machines with no disk), where there is no disk IO and very few
interrupts.  Very glad to hear that these kind of machines will no
longer run short on entropy. :)

I tried searching the web for information about the added entropy
sources in the kernel, but came up short, unless the idea is that the
kernel will use hardware entropy sources like the TPU.  I hope these
drivers also work on older hardware.

-- 
Happy hacking
Petter Reinholdtsen

Bug#961755: dh-golang: dh_golang_autopkgtest no longer detects debian/rules targets with make-4.3

[Michael Banck]

Package: dh-golang
Version: 1.48
Severity: important

Dear Maintainer,

dh_golang_autopkgtest's prepar() function tries to determine the targets
in debian/rules. In current unstable, TARGETS= is empty and it exits out
silently with return code 1 (due to set -e at the top I think).

with make_4.2.3-1:

|# make -pRrq -f debian/rules : | awk -v RS= -F: '/^# File/,/^# Finished Make 
data base/ { if ($1 !~ "^[#.]") {print $1} }'
|
|autopkgtest
|build
|override_dh_auto_test
|override_dh_installsystemd
|debian/rules
|override_dh_installinit
|#

with make_4.3-1:

|# make -pRrq -f debian/rules : | awk -v RS= -F: '/^# File/,/^# Finished  Make 
data base/ { if ($1 !~ "^[#.]") {print $1} }'
|#

i.e. no output.


Michael

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

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

Versions of packages dh-golang depends on:
ii  debhelper 12.1.1
ii  dpkg  1.19.7
ii  libdpkg-perl  1.19.7
ii  perl  5.28.1-6

dh-golang recommends no packages.

dh-golang suggests no packages.

Bug#961754: inotify-tools needs updating to 3.20

[Adam Spiers]

Package: inotify-tools
Version: 3.14-7

Hi there,

AFAICS Debian is still on v3.14 of inotify-tools, which was released in
2010.  This is true even of bullseye and sid:

https://packages.debian.org/search?keywords=inotify-tools

and also buster backports:


https://packages.debian.org/search?suite=buster-backports=names=inotify-tools

3.20.2.2 was released on Feb 1, 2020:

https://github.com/inotify-tools/inotify-tools/releases

so it would be great if Debian could be updated to that, on sid at very
least.

Thanks for listening!
Adam

Bug#961753: ITP: suru-icon-theme -- Suru icon theme for Lomiri Operating Environment

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: suru-icon-theme
  Version : 20.05
  Upstream Author : Marius Gripsgard 
* URL : https://gitlab.com/ubports/core/suru-icon-theme/
* License : CC-BY-SA-3.0
  Programming Lang: 
  Description : Suru icon theme for Lomiri Operating Environment

 Lomiri Operating Environment is a convergent work shell designed
 for use cases on phone, tablet or desktop devices.
 .
 The Suru Icon Theme is the default icon theme in Lomiri (former Unity8).
 In Ubuntu, the suru-icon-theme bin:pkg is shipped as part of the ubuntu-theme
 src:pkg. The proposal is to share one suru-icon-theme between Debian
 Ubuntu (Desktop) and UBports' Ubuntu Touch.
 .
 See https://bugs.launchpad.net/ubuntu-themes/+bug/1881180 for details.
 .
 The package will be maintained by the Debian UBports team under the
 umbrella of the Debian Desktop Theme Team.
.

Bug#961752: nss: CVE-2020-12399

[Salvatore Bonaccorso]

Source: nss
Version: 2:3.52-1
Severity: important
Tags: security upstream
Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1631576


Hi,

The following vulnerability was published for nss.

CVE-2020-12399[0]:
| Force a fixed length for DSA exponentiation

It was fixed in 3.52.1 and 3.44.1 specifically.

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-2020-12399
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12399
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1631576 (not public)
[2] 
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.44.4_release_notes
[3] 
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.52.1_release_notes
[4] 
https://hg.mozilla.org/projects/nss/rev/daa823a4a29bcef0fec33a379ec83857429aea2e

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#936798: Please port KisSplice to Python3 (Was: Bug#936798: kissplice: Python2 removal in sid/bullseye)

[Andreas Tille]

Hi Moritz,

On Thu, May 28, 2020 at 08:48:41PM +0200, Moritz Mühlenhoff wrote:
> 
> JFTR, this is now fixed upstream in 2.5.0 and later:
> http://kissplice.prabi.fr/download/:
> 
> --
> Kissplice Version 2.5.0 (2020-04-06)
> 
> New features:
>Now compatible with python3
> --

Thanks for the hint.  Unfortunately there are remaining issues
in build time test and autopkgtest. even of version 2.5.1 .:-(

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#922544: lintian: Mass tag rename to unify naming convention

[Felix Lechner]

Hi,

On Tue, Feb 19, 2019 at 2:30 PM Chris Lamb  wrote:
>
> > As I mentioned initially, I don't think the patch is ready as is, it
> > even has syntax errors

The suggestions from this bug report will be adopted in the near future.

Kind regards
Felix Lechner

Bug#534938: lintian: Pending rename for some shared library tags

[Felix Lechner]

Control: tags -1 - wontfix

Hi,

> Probably only one prefix (shlib or shared-lib) should be used.

I agree with this sentiment. This will be implemented in the near
future. The new prefix will be shared-lib.

> I'm not sure that it's worth the disruption

The tag rename facility will make this process somewhat easier on maintainers.

Also, overrides are available in a Postgres database. Any impact can
be assessed beforehand. The number of affected overrides will be
documented.

Kind regards
Felix Lechner

Bug#811980: libusbtc08: FTBFS with GCC 6: symbol changes

[Moritz Mühlenhoff]

On Sat, Feb 11, 2017 at 11:16:19AM +0100, Maximiliano Curia wrote:
> ¡Hola Nobuhiro!
> 
> El 2017-02-11 a las 15:48 +0900, Nobuhiro Iwamatsu escribió:
> > Control: tags 811980 + patch
> 
> > > This package fails to build with GCC 6.  GCC 6 has not been released
> > > yet, but it's expected that GCC 6 will become the default compiler
> > > for stretch.
> 
> > > Note that only the first error is reported; there might be more.
> > > You can find a snapshot of GCC 6 in experimental.  To build with GCC
> > > 6, you can set CC=gcc-6 CXX=g++-6 explicitly.
> 
> > > You may be able to find out more about this issue at
> > > https://gcc.gnu.org/gcc-6/changes.html
> 
> > I create a patch which update symboles file. Could you check this patch?
> 
> I've considered requesting the removal of libusbtc08 as I'm no longer using
> it, it seems that there aren't any users for it, and upstream stopped
> distributing their source code for the newer versions
> (https://www.picotech.com/downloads/linux).

I've filed an RM bug now.

Cheers,
Moritz

Bug#961744: devscripts: uscan: please add capability to download gzipped content

[Xavier]

Le 28/05/2020 à 18:17, Gianfranco Costamagna a écrit :
> Source: devscripts
> Version: 2.20.3
> X-Debbugs-CC: y...@debian.org
> 
> Hello, looks like ghc watch file is not able to work anymore
> 
> version=3
> opts="pgpsigurlmangle=s/$/.sig/,dirversionmangle=s/-rc/~rc/,repacksuffix=+dfsg1,dversionmangle=s/\+dfsg\d*$//"
>  \
> https://downloads.haskell.org/~ghc/(\d[\d.rc-]*)/ghc-(\d[\d.]*)-src.tar.(?:bz2|xz|gz)
> 
> 
> the problem is that the https://downloads.haskell.org/~ghc/ page is 
> configured to send gzipped content
> (something that browsers handle natively).
> 
> I'm not able to speak perl, but I crafted a "fake patch" that worked for me 
> to grab the new version, and I would like to share it with you.
> (note: I was not able to gunzip a buffer variable, so I saved the content 
> into a file and loaded it from there, sorry but my perl-foo is really NULL)
> 
> This is a POC that works for ghc, but of course it needs to be changed to 
> selectively allow gzipped content via configuration switch, or by detecting 
> the type of received stream, or something else

Hi,

thanks, I'll look at this. Note that this is a server side bug: it
should not send compressed data if request doesn't specify
"Accept-Encoging: gzip"

Bug#961751: RM: libusbtc08 -- RoQA; RC-buggy, current versions no longer distribute source

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove libusbtc08. It FTBFSes for over four years (811980) and current 
releases
no longer ship the source.

Cheers,
Moritz

Bug#961746: openvswitch-switch restart service when upgraded

[Hiro]

Noticed reportbug filled the system information from my system. Please
let me know if you'd like some info from the systems where we are
dealing with this.


On Thu, 28 May 2020 19:43:48 +0200 Silvia Puglisi - Hiro
 wrote:

> Package: openvswitch-switch
> Version: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12+deb10u2
> Severity: normal
>
> Dear Maintainer,
>
> We have noticed that openvswitch-switch service is restarted when the
package is upgraded.
>
> It could be that openvswitch-switch.postinst restarts the service.
>
> We noticed this issue on a ganeti cluster (bug:
https://trac.torproject.org/projects/tor/ticket/34185).
>
>
> -- System Information:
> Debian Release: 10.4
> APT prefers stable
> APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.107-1.pvops.qubes.x86_64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages openvswitch-switch depends on:
> ii kmod 26-1
> ii lsb-base 10.2019051400
> ii netbase 5.6
> pn openvswitch-common 
> ii procps 2:3.3.15-2
> ii python 2.7.16-1
> pn uuid-runtime 
>
> openvswitch-switch recommends no packages.
>
> openvswitch-switch suggests no packages.
>
>

Bug#936796: kiki-the-nano-bot: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Mon, Sep 16, 2019 at 12:08:24AM +0200, Peter De Wachter wrote:
> Package: kiki-the-nano-bot
> Version: 1.0.2+dfsg1-8
> Followup-For: Bug #936796
> 
> This one is heading for removal I fear. The last upstream release was
> 10+ years ago, I don't think we can expect a new release.
> 
> I investigated a bit what a port would involve. The C++ part only
> needs a few small adjustments I think (this is a mixed C++/Python
> project).  But 2to3 does a very poor job on the Python code, all that
> code will need to be reviewed and fixed by hand.  Also, because so
> much of the game is implemented in Python, each level will have to be
> playtested and compared to the original. That's much more work than
> I'm willing to do for this game.

Let's remove, then?

Cheers,
Moritz

Bug#936798: Please port KisSplice to Python3 (Was: Bug#936798: kissplice: Python2 removal in sid/bullseye)

[Moritz Mühlenhoff]

On Tue, Dec 17, 2019 at 08:41:02AM +0100, Andreas Tille wrote:
> On Wed, Oct 09, 2019 at 08:06:27AM +0200, Andreas Tille wrote:
> > 
> > > When would be the deadline for updating our debian KisSplice package 
> > > before removal ?
> > 
> > There is no actual date.  Debian 11 will be released in 2021 so the
> > current bug is not yet release critical.  You will be on the safe side
> > if you get out KisSplice at the end of this year not only from a
> > Debian point of view but also in general for other users who do not
> > might want to run unsupported software like Python2.
> 
> The Debian Med team is currently an Advent bug squashing party.  You could 
> help
> us closing as much as possible bugs if you would be able to release before
> Christmas. ;-)

JFTR, this is now fixed upstream in 2.5.0 and later:
http://kissplice.prabi.fr/download/:

--
Kissplice Version 2.5.0 (2020-04-06)

New features:
   Now compatible with python3
--

Cheers,
Moritz

Bug#961527: RFS: vnstat/2.6-2 -- console-based network traffic monitor

[Christian Göttsche]

Am Mo., 25. Mai 2020 um 23:09 Uhr schrieb Adam Borowski :
>
> This will make the package likely to FTBFS whenever the default compiler is
> upgraded, someone tries to build with clang, etc.  It's usually a bad idea
> but somewhat manageable if you're looking carefully.  In Debian proper, that
> is -- derivatives will be pretty unhappy.
>
> ... but you also have -Wextra which makes the above FTBFS guaranteed.
>
> I'd say uploads with this combo belong in experimental -- a worthy
> development check -- but not in in a suite that's going to be released (and
> most derivatives have a different cadence than Debian).
>

I thought as upstream is quite wide checked [1], this might help to
detect possible
issue on uncommon architectures (as the build-warnings helper on PTS is
somewhat unreliable).

Uploaded a new version without enabling -Werror.


[1]: https://github.com/vergoh/vnstat/blob/master/.travis.yml

Bug#950291: fixed in version 2.1.1

[Wm M Fender-Westwind]

This bug seems to have been fixed in the most recent version of wlfreerdp
(freerdp2-wayland 2.1.1+dfsg1-1)

-- 
... Had this been an actual emergency, we would have fled in terror, and
you would not have been informed.

Bug#961750: varnish: "service varnish configtest" fails

[Johnathon Tinsley]

Package: varnish
Version: 6.1.1-1+deb10u1
Severity: normal

Dear Maintainer,


   * What led up to the situation?
   Varnish running on default port, 6081. run "service varnish configtest" to 
verify custom configuration.
   configtest reports could not bind to socket, instead of verifying
   configuration. 

   * What was the outcome of this action?
   Errors as follows;
   Error: Could not get socket :6081: Address already in use
   (-? gives usage)

   * What outcome did you expect instead?
   Runs configtest and tries to compile VCL, alerting on any errors. 



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

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

Versions of packages varnish depends on:
ii  adduser   3.118
ii  gcc   4:8.3.0-1
ii  libc6 2.28-10
ii  libc6-dev [libc-dev]  2.28-10
ii  libedit2  3.1-20181209-1
ii  libjemalloc2  5.1.0-3
ii  libncursesw6  6.1+20181013-2+deb10u2
ii  libpcre3  2:8.39-12
ii  libtinfo6 6.1+20181013-2+deb10u2
ii  libvarnishapi26.1.1-1+deb10u1
ii  lsb-base  10.2019051400

varnish recommends no packages.

Versions of packages varnish suggests:
pn  varnish-doc  

-- Configuration Files:
/etc/varnish/default.vcl changed [not included]

-- no debconf information

Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine

[Roland Plüss]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dragengine"

* Package name : dragengine
Version : 1.1
Upstream Author : rol...@rptd.ch
* URL : https://dragondreams.ch
* License : LGPL-3.0+
* Vcs : upstream debianization branch:
https://github.com/LordOfDragons/dragengine/tree/debian
Section : x11

It builds those binary packages:

dragengine - Drag[en]gine Game Engine
dragengine-dev - Drag[en]gine Game Engine Development
deigde - Drag[en]gine Game Development Environment
deigde-dev - Drag[en]gine IGDE Development

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

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

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

dget -x
https://mentors.debian.net/debian/pool/main/d/dragengine/dragengine_1.1.dsc

Changes since the last upload:

* Initial debianization.

Regards,


-- 
Mit freundlichen Grüssen
Plüss Roland

Game Development and Game Engine Technologies https://dragondreams.ch



signature.asc
Description: OpenPGP digital signature

Bug#961749: RM: xenomai -- RoQA; RC-buggy, orphaned, missed two stable releases

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove xenomai. It's orphaned without an adopter since 2016, only
provides patches for vintage kernels (925453) and depends on removed
kernel-package (925451). It also missed the last two stable releases
already.

Cheers,
Moritz

Bug#961748: Does CVE-2018-8956 affect ntpsec?

[Moritz Muehlenhoff]

Source: ntpsec
Severity: normal
Tags: security

There was a "new" CVE assignment for ntp (2018 ID, but appeared today):
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8956

Does this affect ntpsec?

And congrats to becoming a DD :-)

Cheers,
Moritz

Bug#898408: ITP: python3-aiohue -- Python3 asyncio package to talk to Philips Hue

[Jonas Smedegaard]

Control: forcemerge 898408 917079

It seems you are doing duplicate work here.  You probably want to 
coordinate your efforts.


 - Jonas

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

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

signature.asc
Description: signature

Bug#961747: libstatgrab: Fix reproducibility issues in example Makefile

[Vagrant Cascadian]

Source: libstatgrab
Version: 0.91-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The example Makefile shipped in libstatgrab-dev changes depending on the
build path and if the system was build with a merged /usr
(a.k.a. usrmerge) filesystem layout.

The attached patches fix these issues, though it might be worth
considering dropping the example Makefile from the package entirely; the
end-user would have to regenerate it themselves in order for it to be
functional.


live well,
  vagrant

From 9e8f7ff6e357ca9d97d7be3d4a1087e06d9bd61e Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 28 May 2020 17:43:55 +
Subject: [PATCH 1/2] Fix varying paths in example Makefile.

Pass values for various binaries to configure to ensure reproducible
builds when built on a usrmerged system.
---
 debian/rules | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/debian/rules b/debian/rules
index 3cc4d57..dad932a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,3 +5,14 @@
 
 %:
 	dh $@ --with autoreconf
+
+override_dh_auto_configure:
+	# Ensure consistant paths for binaries to ensure reproducible
+	# builds on usrmerge vs. non-usrmerge systems.
+	dh_auto_configure -- \
+		GREP=/bin/grep \
+		EGREP="/bin/grep -E" \
+		FGREP="/bin/grep -F" \
+		MKDIR_P="/bin/mkdir -p" \
+		SED=/bin/sed \
+		SHELL=/bin/sh
-- 
2.20.1

From 549a33130543cd93a83d50f285dda208a7896408 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 28 May 2020 17:46:48 +
Subject: [PATCH 2/2] Remove build paths from example Makefile to ensure
 reproducible builds.

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

diff --git a/debian/rules b/debian/rules
index dad932a..dbdb749 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,3 +16,13 @@ override_dh_auto_configure:
 		MKDIR_P="/bin/mkdir -p" \
 		SED=/bin/sed \
 		SHELL=/bin/sh
+
+override_dh_install:
+	# Clean up embedded build paths in order to ensure reproducible builds.
+	sed -i -e "s,-fdebug-prefix-map=$(CURDIR)=\.,,g" \
+		-e "s,-ffile-prefix-map=$(CURDIR)=\.,,g" \
+		-e "s,abs_.*$(CURDIR).*,,g" \
+		-e "s,$(CURDIR).*missing --run,,g" \
+		-e "s,$(CURDIR),./,g" \
+		$(CURDIR)/examples/Makefile
+	dh_install
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#936146: archivemail - Python 3 porting

[Scott Talbert]

On Tue, 26 May 2020, Jonathan Dowland wrote:

archivemail seems to be a good candidate to RM due to dead upstream. 
However, it still has a relatively high popcon, so people seem to be using 
it.


I'm willing to take a stab at porting to Python 3 if anyone is available to 
test it?  The port effort doesn't look that bad at first glance, but I 
don't use this package.


I'm happy to test anything you produce, but I'd warn you that I think
it's quite a significant piece of work. From what I remember when I last
looked at hacking a feature into it (#736327), archivemail uses the
older of two different APIs provided by the python "mailbox" library,
and only the newer one was carried forward to Python 3. So moving away
from that older API is a big part of the work.


You were right.  This was harder than I expected.  :)  Mainly it is 
exactly as you described - the rfc822.Message class (which doesn't exist 
in Python 3) does not map exactly to the email.message.Message class.  I'm 
stuck at the moment with figuring out how to calculate the message size. 
In rfc822.Message, you could access the file handle directly and get the 
size that way.


Scott

Bug#922961: ITP: vorta -- Desktop Backup Client for Borg

[Nicholas D Steeves]

On Tue, May 26, 2020 at 03:59:56PM -0400, Nicholas D Steeves wrote:
> 
> P.S. I suspect this ITP will take a while to resolve, because the
> upstream is very much in the "release a standalone bundle with
> everything vendored" camp..

This was perhaps an unfair assessment.  Things are moving smoothly
upstream now, and I am more optimistic.


signature.asc
Description: PGP signature

Bug#961745: [Pkg-utopia-maintainers] Bug#961745: udisks2 2.9.0-1 problems

[Michael Biebl]

[Please always CC the bug report on replies]

Am 28.05.20 um 19:37 schrieb Сергей Фёдоров:
> /etc/fstab :
> 
> # /etc/fstab: static file system information.
> #
> # Use 'blkid' to print the universally unique identifier for a
> # device; this may be used with UUID= as a more robust way to name devices
> # that works even if disks are added and removed. See fstab(5).
> #
> #
> # / was on /dev/sda5 during installation
> UUID=5dede9d6-ff78-4669-8e74-cc035749b9ba /   ext4
> errors=remount-ro 0   1
> # /boot was on /dev/sda1 during installation
> UUID=bf20f503-0791-4f37-b907-80468173eb57 /boot   ext4defaults
> 0   2
> # /home was on /dev/sda10 during installation
> UUID=0f21095a-b02c-4d69-b1f9-1f0cacb783ee /home   ext4defaults
> 0   2
> # /tmp was on /dev/sda7 during installation
> UUID=c5e3a2fb-ddf6-433a-b39d-cab7175bbe0e /tmpext4defaults
> 0   2
> # /usr was on /dev/sda9 during installation
> UUID=ee0b9fca-2326-4b2d-b6b5-bc0541eaf0f2 /usrext4defaults
> 0   2
> # /var was on /dev/sda8 during installation
> UUID=50a8bdc3-886f-4115-8066-f994ca45d743 /varext4defaults
> 0   2
> # swap was on /dev/sda6 during installation
> UUID=92183ea7-4dc3-43a0-8346-b4ec643d6956 noneswapsw  
> 0   0
> /dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0
> 
> : lsblk -f
> NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% 
> MOUNTPOINT
> sda 
> ├─sda1
> │ext4   1.0 bf20f503-0791-4f37-b907-80468173eb578,4G 2% 
> /boot
> ├─sda2
> │   
> ├─sda3
> │ext4   1.0   DebRepo2
> │   b507efaf-6d1f-4173-9804-6f7d0d4f5a31  406,8G60% 
> /mnt/repo/
> ├─sda5
> │ext4   1.0 5dede9d6-ff78-4669-8e74-cc035749b9ba   15,4G10% /
> ├─sda6
> │swap   1   92183ea7-4dc3-43a0-8346-b4ec643d6956
> [SWAP]
> ├─sda7
> │ext4   1.0 c5e3a2fb-ddf6-433a-b39d-cab7175bbe0e   86,4G 0% 
> /tmp
> ├─sda8
> │ext4   1.0 50a8bdc3-886f-4115-8066-f994ca45d743   85,6G 1% 
> /var
> ├─sda9
> │ext4   1.0 ee0b9fca-2326-4b2d-b6b5-bc0541eaf0f2  286,9G 5% 
> /usr
> └─sda10
>  ext4   1.0 0f21095a-b02c-4d69-b1f9-1f0cacb783ee   58,7G14% 
> /home
> sdb 
> ├─sdb1
> │ext4   1.0   s1319ffa1e-d977-4248-8df1-d33acf965314  296,9G62% 
> /media/u1/
> └─sdb2
>  ext4   1.0   s26548b874-6a70-436f-beb7-8ab4612b55a5
> sdc 
> └─sdc1
>  ext4   1.0   D f8f76019-e459-4f5c-b4d0-b2ed4bcbed90
> sdd 
> └─sdd1
>  ext4   1.0   E-G   ffbe6520-1584-44a0-adcc-d951c09b24e1
> sde 
> └─sde1
>  ext4   1.0   H bc0046f3-e5c2-4e3e-9359-7a9d3b088833
> sr0   


Those error messages you see, where are they coming from? Your desktop
environment? Which one do you use? Can you attach a screenshot?
Do you get any error messages in the journal?




signature.asc
Description: OpenPGP digital signature

Bug#961206: improve sphinx usage for cross building

[Drew Parsons]

Source: sphinx
Followup-For: Bug #961206

I've just updated numba from Build-Depends: python3-sphinx
to Build-Depends: sphinx as recommended here (#961741).

The change is giving me a lintian error:

E: numba source: missing-build-dependency-for-dh-addon sphinxdoc => 
python-sphinx | python3-sphinx | dh-sequence-sphinxdoc


Should the lintian test be updated for the new sphinx structure (e.g.
to include sphinx as an alternative)?

Bug#961746: openvswitch-switch restart service when upgraded

[Silvia Puglisi - Hiro]

Package: openvswitch-switch
Version: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12+deb10u2
Severity: normal

Dear Maintainer,

We have noticed that openvswitch-switch service is restarted when the package 
is upgraded.

It could be that openvswitch-switch.postinst restarts the service. 

We noticed this issue on a ganeti cluster (bug: 
https://trac.torproject.org/projects/tor/ticket/34185).


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

Kernel: Linux 4.19.107-1.pvops.qubes.x86_64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openvswitch-switch depends on:
ii  kmod26-1
ii  lsb-base10.2019051400
ii  netbase 5.6
pn  openvswitch-common  
ii  procps  2:3.3.15-2
ii  python  2.7.16-1
pn  uuid-runtime

openvswitch-switch recommends no packages.

openvswitch-switch suggests no packages.

Bug#961745: [Pkg-utopia-maintainers] Bug#961745: udisks2 2.9.0-1 problems

[Michael Biebl]

Control: tags -1 + moreinfo


Please attach your /etc/fstab and the output of
lsblk -f



signature.asc
Description: OpenPGP digital signature

Bug#961745: udisks2 2.9.0-1 problems

[Сергей Фёдоров]

Package: udisks2
Version: 2.9.0-1
Severity: normal



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

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

Versions of packages udisks2 depends on:
ii  dbus   1.12.16-2
ii  libacl12.2.53-8
ii  libatasmart4   0.19-5
ii  libblockdev-fs22.24-1
ii  libblockdev-loop2  2.24-1
ii  libblockdev-part2  2.24-1
ii  libblockdev-swap2  2.24-1
ii  libblockdev-utils2 2.24-1
ii  libblockdev2   2.24-1
ii  libc6  2.30-8
ii  libglib2.0-0   2.64.2-1
ii  libgudev-1.0-0 233-1
ii  libmount1  2.35.2-2
ii  libpam-systemd 245.5-3
ii  libpolkit-agent-1-00.105-26
ii  libpolkit-gobject-1-0  0.105-26
ii  libsystemd0245.5-3
ii  libudisks2-0   2.9.0-1
ii  libuuid1   2.35.2-2
ii  parted 3.3-4
ii  udev   245.5-3

Versions of packages udisks2 recommends:
ii  dosfstools   4.1-2
ii  e2fsprogs1.45.6-1
ii  eject2.35.2-2
ii  exfat-utils  1.3.0-1
ii  libblockdev-crypto2  2.24-1
ii  ntfs-3g  1:2017.3.23AR.3-3
ii  policykit-1  0.105-26

Versions of packages udisks2 suggests:
pn  btrfs-progs  
pn  f2fs-tools   
pn  libblockdev-mdraid2  
pn  mdadm
pn  nilfs-tools  
pn  reiserfsprogs
pn  udftools 
pn  udisks2-bcache   
pn  udisks2-btrfs
pn  udisks2-lvm2 
pn  udisks2-zram 
pn  xfsprogs 

-- no debconf information

The udisks2 package version 2.8.4-2 worked fine.
Updated to version 2.9.0-1 package
In addition to the boot disk, there are 4 disks labeled "D", "H", "E-D" and a 
disk with two partitions labeled "S1"and " S2".
The boot disk is mounted automatically and normally.
When attempting to mount disk "H", the message" Transition to /media/u1/H 
failed "is displayed and device" H " is being mounted "H1" in the 
"/media/u1/H1" directory. And so for all disks. Accordingly,
D1 with the message "Transition to the /media/u1/D directory failed".
E-D1 with the message "Transition to the /media/u1/E-D directory failed".
S11 with the message "Transition to the /media/u1/S1 directory failed".
And, for some reason, S2, not S21 with the message "Transition to the directory 
/media/u1/S failed".
Returned to udisks2 version 2.8.4-2.

Bug#909210: Does it make sense to ship automake-1.15 in bullseye?

[Ivo De Decker]

Control: severity -1 serious
Control: retitle -1 don't ship automake-1.15 in bullseye

Hi,

On Thu, May 28, 2020 at 09:34:18AM -0700, Vagrant Cascadian wrote:
> On 2020-02-04, Vagrant Cascadian wrote:
> > On 2019-01-12, Ivo De Decker wrote:
> >> On Wed, Sep 19, 2018 at 09:31:13PM +0300, Adrian Bunk wrote:
> >>> The 1.15 -> 1.16 changes were relatively minor.
> >>> 
> >>> All FTBFS it caused should already be filed as bugs,
> >>> and most have already been fixed.
> >>> 
> >>> So far I haven't seen a single one that would have
> >>> been difficult to fix.
> >>> 
> >>> There are currently no reverse (build) dependencies
> >>> on automake-1.15 in unstable, and I do not think
> >>> there should ever be any.
> >>
> >> cabextract b-d on automake-1.15
> >
> > Unless I've missed some, Seems the only build-depends left in bullseye
> > are:
> >
> >   cabextract
> >   rsyncrypto
> >
> > I've just submitted patches for both, and marked as blocking this bug.
> 
> I *think* they are now no remaining depends or build-depends on
> automake-1.15, seems like it could be removed now?

dak rm seems to agree, so I added a testing removal hint (and upgraded this
bug so it doesn't come back). It's probably time to file an ftp removal bug
for unstable?

Cheers,

Ivo

Bug#961741: python3-sphinx: new release broke sphinx-build OUTPUTDIR

[Drew Parsons]

Control: reassign -1 src:numba

On 2020-05-29 00:36, Simon McVittie wrote:

On Fri, 29 May 2020 at 00:02:46 +0800, Drew Parsons wrote:
  http_proxy='127.0.0.1:9' 
/usr/share/sphinx/scripts/python3/sphinx-build /usr/bin/sphinx-build 
-N -bhtml \

   .pybuild/cpython3_3.8_numba/build/docs/source/ \
   debian/numba-doc/usr/share/doc/numba-doc/html/


This looks wrong? It seems like it's running
/usr/share/sphinx/scripts/python3/sphinx-build with first argument set
to /usr/bin/sphinx-build. The argument parser will probably think
/usr/bin/sphinx-build is the SOURCEDIR,
.pybuild/cpython3_3.8_numba/build/docs/source/ is the OUTPUTDIR
and debian/numba-doc/usr/share/doc/numba-doc/html/ is in FILENAMES.

From numba's d/rules:


SPHINX_BUILD = $(shell dpkg -L python3-sphinx | grep "sphinx-build$$")


I think this is why. In previous versions this would have only found
one result, but that's really fragile: the fact that there was only one
filename ending with sphinx-build in the package was an implementation
detail that you can't rely on, and in the new version it isn't true
any more.

If what you want is to run "the version of sphinx that is packaged as
python3-sphinx, whatever that might be", use:

SPHINX_BUILD = python3 -m sphinx

But you might be better off using Depends: sphinx
and "SPHINX_BUILD = sphinx-build" in future: see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961206 for details.

I think this should probably be reassigned to numba, and any other
packages that were finding sphinx-build in the same fragile way.



I see, the numba build is pulling out both
/usr/share/sphinx/scripts/python3/sphinx-build and
/usr/bin/sphinx-build now.

I'll reassign and apply those changes in numba.

Thanks for the swift analysis, Simon.

Drew

Bug#955211: release.debian.org: Transition r-base for 4.0.0

[Dirk Eddelbuettel]

Thanks everybody for the help with the transition: 4.0.0-3 is now in testing.

Which is lovely as upstream is already at work with 4.0.1 which will drop on
June 6 [1]. I'll likely make an rc upload.

Special thanks to Graham for calmly pulling a few strings here and there.

Cheers, Dirk


[1] Details as always at http://developer.r-project.org/, and just to be
plain it is of course _not_ a binary change needing an API change.
-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#702914: CVE-2013-1841 still unsolved?

[Rob Brown]

Is this Issue still open? Is it still a problem in the latest version? Or
can I close this RT Ticket now?

-- Rob

On Thu, May 28, 2020 at 3:52 AM Petter Reinholdtsen  wrote:

>
> Dear libnet-server-perl developers,
>
> You get this message as the upstream developers of the
> libnet-server-perl Debian package.  There is an security issue
> accociated with the perl module, discussed in
> https://rt.cpan.org/Ticket/Display.html?id=83909 > and
> https://security-tracker.debian.org/CVE-2013-1841 >.
>
> Is the CVE-2013-1841 issue still unsolved, or was it solved in one of
> the releases 2.008 or 2.009 without being mentioned in the changelog?
>
> Cc to issue #702914 in the Debian bug tracker, to make the maintainer
> aware of any replies.
>
> --
> Happy hacking
> Petter Reinholdtsen
>

Bug#961729: education-networked-common: Please remove Recommends: haveged

[Wolfgang Schweer]

On Thu, May 28, 2020 at 01:25:25PM +, Holger Levsen wrote:
> On Thu, May 28, 2020 at 03:24:22PM +0200, Chris Hofstaedtler wrote:
> > The topic came up on IRC, and for me it is about removing bloat from
> > ("default") installs.

d-i still uses haveged-udeb, see:
https://lists.debian.org/debian-boot/2020/03/msg00207.html 
for the latest mail on this issue.

Please correct me if I'm wrong.

Wolfgang


signature.asc
Description: PGP signature

Bug#961741: python3-sphinx: new release broke sphinx-build OUTPUTDIR

[Simon McVittie]

On Fri, 29 May 2020 at 00:02:46 +0800, Drew Parsons wrote:
>   http_proxy='127.0.0.1:9' /usr/share/sphinx/scripts/python3/sphinx-build 
> /usr/bin/sphinx-build -N -bhtml \
>  .pybuild/cpython3_3.8_numba/build/docs/source/ \
>  debian/numba-doc/usr/share/doc/numba-doc/html/

This looks wrong? It seems like it's running
/usr/share/sphinx/scripts/python3/sphinx-build with first argument set
to /usr/bin/sphinx-build. The argument parser will probably think
/usr/bin/sphinx-build is the SOURCEDIR,
.pybuild/cpython3_3.8_numba/build/docs/source/ is the OUTPUTDIR
and debian/numba-doc/usr/share/doc/numba-doc/html/ is in FILENAMES.

>From numba's d/rules:

> SPHINX_BUILD = $(shell dpkg -L python3-sphinx | grep "sphinx-build$$")

I think this is why. In previous versions this would have only found
one result, but that's really fragile: the fact that there was only one
filename ending with sphinx-build in the package was an implementation
detail that you can't rely on, and in the new version it isn't true
any more.

If what you want is to run "the version of sphinx that is packaged as
python3-sphinx, whatever that might be", use:

SPHINX_BUILD = python3 -m sphinx

But you might be better off using Depends: sphinx
and "SPHINX_BUILD = sphinx-build" in future: see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961206 for details.

I think this should probably be reassigned to numba, and any other
packages that were finding sphinx-build in the same fragile way.

smcv

Bug#909210: Does it make sense to ship automake-1.15 in bullseye?

[Vagrant Cascadian]

On 2020-02-04, Vagrant Cascadian wrote:
> On 2019-01-12, Ivo De Decker wrote:
>> On Wed, Sep 19, 2018 at 09:31:13PM +0300, Adrian Bunk wrote:
>>> The 1.15 -> 1.16 changes were relatively minor.
>>> 
>>> All FTBFS it caused should already be filed as bugs,
>>> and most have already been fixed.
>>> 
>>> So far I haven't seen a single one that would have
>>> been difficult to fix.
>>> 
>>> There are currently no reverse (build) dependencies
>>> on automake-1.15 in unstable, and I do not think
>>> there should ever be any.
>>
>> cabextract b-d on automake-1.15
>
> Unless I've missed some, Seems the only build-depends left in bullseye
> are:
>
>   cabextract
>   rsyncrypto
>
> I've just submitted patches for both, and marked as blocking this bug.

I *think* they are now no remaining depends or build-depends on
automake-1.15, seems like it could be removed now?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#961744: devscripts: uscan: please add capability to download gzipped content

[Gianfranco Costamagna]

Source: devscripts
Version: 2.20.3
X-Debbugs-CC: y...@debian.org

Hello, looks like ghc watch file is not able to work anymore

version=3
opts="pgpsigurlmangle=s/$/.sig/,dirversionmangle=s/-rc/~rc/,repacksuffix=+dfsg1,dversionmangle=s/\+dfsg\d*$//"
 \
https://downloads.haskell.org/~ghc/(\d[\d.rc-]*)/ghc-(\d[\d.]*)-src.tar.(?:bz2|xz|gz)


the problem is that the https://downloads.haskell.org/~ghc/ page is configured 
to send gzipped content
(something that browsers handle natively).

I'm not able to speak perl, but I crafted a "fake patch" that worked for me to 
grab the new version, and I would like to share it with you.
(note: I was not able to gunzip a buffer variable, so I saved the content into 
a file and loaded it from there, sorry but my perl-foo is really NULL)

This is a POC that works for ghc, but of course it needs to be changed to 
selectively allow gzipped content via configuration switch, or by detecting the 
type of received stream, or something else


diff -Nru devscripts-2.20.3/lib/Devscripts/Uscan/http.pm 
devscripts-2.20.4/lib/Devscripts/Uscan/http.pm
--- devscripts-2.20.3/lib/Devscripts/Uscan/http.pm  2020-04-25 
21:01:45.0 +0200
+++ devscripts-2.20.4/lib/Devscripts/Uscan/http.pm  2020-04-25 
21:15:48.0 +0200
@@ -6,6 +6,7 @@
 use Devscripts::Uscan::Utils;
 use Devscripts::Uscan::_xtp;
 use Moo::Role;
+use IO::Uncompress::Gunzip qw(gunzip $GunzipError) ;
 
 *http_newfile_base = \::Uscan::_xtp::_xtp_newfile_base;
 
@@ -239,6 +240,12 @@
 }
 
 my $content = $response->content;
+open(FH, '>', '/tmp/content') or die $!;
+print FH $content;
+close(FH);
+
+my $input = new IO::File "< /tmp/content";
+gunzip $input => \$content;
 uscan_debug
   "received content:\n$content\n[End of received content] by HTTP";
 

Bug#961743: /usr/share/vim/addons/tlib.txt: should be in /usr/share/vim/addons/doc/

[Lazarus Long]

Package: vim-tlib
Version: 1.27-4
Severity: grave
File: /usr/share/vim/addons/tlib.txt
Tags: patch
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Most likelly to be found after installing package vim-snipmate, which is
the only that depends on this one.

Attached is a patch to apply on source dir after extracting the .dsc
file.

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

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

Versions of packages vim-tlib depends on:
ii  vim2:8.2.0716-3
ii  vim-addon-manager  0.5.10
ii  vim-nox [vim]  2:8.2.0716-3

vim-tlib recommends no packages.

vim-tlib suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iF0EAREKAB0WIQT6ja0o8lKdd1y4TPqd6/XxTNdf7wUCXs/iTgAKCRCd6/XxTNdf
7yBdAJ9iSVZ+vKYlukziK5F0e1R1gaBJ3gCgrCnCf6olsoQzGeLqt0QDzY/EFQg=
=dNYp
-END PGP SIGNATURE-
diff -Nru vim-tlib-1.27.original/debian/vim-tlib.install 
vim-tlib-1.27/debian/vim-tlib.install
--- vim-tlib-1.27.original/debian/vim-tlib.install  2020-04-26 
12:13:15.0 +0100
+++ vim-tlib-1.27/debian/vim-tlib.install   2020-05-28 13:04:55.599673875 
+0100
@@ -1,4 +1,4 @@
-doc/tlib.txt  usr/share/vim/addons
+doc/tlib.txt  usr/share/vim/addons/doc
 etc/  usr/share/vim/addons
 macros/   usr/share/vim/addons
 plugin/   usr/share/vim/addons

Bug#961740: printf attempts to parse options and fails to print --help

[Michael Stone]

On Thu, May 28, 2020 at 05:56:09PM +0200, Melvin Vermeeren wrote:

On Thursday, 28 May 2020 17:50:20 CEST Michael Stone wrote:

Yes, running printf with the single argument --help will print help. A
portable and posix-compliant alternative would be to run "printf '%s'
--help". This is extremely unlikely to change.


This is not the only problem that occurs, printing -- does not work either.


same solution will work!


Coreutils should aim for POSIX compliancy, perhaps it would be better if I
take this bug upstream?


You certainly can, but they will probably also consider this to be of 
purely academic interest. The solution I provided above is the only 
portable way to make what you're trying to do work, regardless of POSIX. 
Even if I changed the debian package today, you'd have to continue to do 
the above basically forever because of the enormous installed base of 
implementations don't work the way you're requesting. And not having the 
help output will likely confuse more people who won't know why it 
wouldn't work.

Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock

[Dirk Eddelbuettel]

On 28 May 2020 at 16:55, Sébastien Villemot wrote:
| Hi Dirk,
| 
| Le jeudi 28 mai 2020 à 07:07 -0500, Dirk Eddelbuettel a écrit :
| > Package: libopenblas-dev
| > Version: 0.3.8+ds-1
| > Severity: serious
| 
| > In short, when libopenblas-dev is installed (as e.g. from r-base-dev as a
| > dependency from libblas-dev, liblapack-dev) then
| > 
| > libopenblas0-pthread
| > 
| > is installed first via our depends ranking as libopenblas-pthread-dev comes
| > first.
| > 
| > This has served us well over the years but can exhibit a bug which I for
| > example saw with (Ubuntun's) 0.3.8+ds-1 package. Running a simple
| > 
| > example(solve)
| > 
| > in R hangs in an unsuspendable session (ie no Ctrl-C, kill is needed).
| > Simplest test is on the command-line via
| > 
| > $ Rscript -e 'example(solve)'
| > 
| > Removing libopenbkas0-pthread and installing libopenblas-openmp-dev helps. 
As
| > does a manual reordering of the alternatives.
| > 
| > This bug is reproducible on my system with a i7-8700k.
| 
| I’ve tried to reproduce it on my i7-8700K, without success. I used a
| clean sid chroot (with r-base 4.0.0-3 and openblas 0.3.9+ds-1).
| Downgrading to openblas 0.3.8+ds-1 (which is the version against which
| you reported the bug) does not change anything.
| 
| So it’s not clear that this bug is tied to a specific hardware. At
| least, a given CPU model is not a guarantee of reproducibility.

Darn.  What next?  Shall we compare environment variables (I don't set too
many and can't think of one that does it.)

Or shall we be speculative and try a 'private' package with the two defines
Mo suggested to see if that helps on my side?

Did the Parisian student ever contact you?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#961742: ITP: nsntrace -- perform network trace of a single process by using network namespaces

[Sudip Mukherjee]

Package: wnpp
Severity: wishlist
Owner: Sudip Mukherjee 
X-Debbugs-CC: p...@debian.org

* Package name: nsntrace
  Version : v3 or v4
  Upstream Author : Jonas Danielsson 
* URL : https://github.com/nsntrace/nsntrace
* License : GPL-2+
  Programming Lang: C
  Description : perform network trace of a single process by using network 
namespaces

 Uses Linux network namespaces to perform network traces of a single
 application. The traces are saved as pcap files. And can later be analyzed
 by for instance Wireshark.

Note: This is a reintroduction of the package.

Bug#961741: python3-sphinx: new release broke sphinx-build OUTPUTDIR

[Drew Parsons]

Package: python3-sphinx
Version: 2.4.3-3
Severity: grave
Justification: renders package unusable

The new release 2.4.3-3 appears to have broken sphinx-build. It no
longer recognises the OUTPUTDIR argument.

This causes numba to FTBFS (OUTPUTDIR here is
debian/numba-doc/usr/share/doc/numba-doc/html/):

 dh_install -i -O--buildsystem=pybuild
 debian/rules override_dh_installdocs
  make[1]: Entering directory '/home/projects/python/build/numba'
  dh_installdocs -A README.rst
  dh_installdocs: warning: Cannot auto-detect main package for numba-doc.  If 
the default is wrong, please use --doc-main-package
  cp -a docs CHANGE_LOG examples .pybuild/cpython3_3.8_numba/build
  http_proxy='127.0.0.1:9' /usr/share/sphinx/scripts/python3/sphinx-build 
/usr/bin/sphinx-build -N -bhtml \
   .pybuild/cpython3_3.8_numba/build/docs/source/ \
   debian/numba-doc/usr/share/doc/numba-doc/html/
  usage: sphinx-build [OPTIONS] SOURCEDIR OUTPUTDIR [FILENAMES...]
  sphinx-build: error: cannot find files 
['debian/numba-doc/usr/share/doc/numba-doc/html/']
  make[1]: *** [debian/rules:27: override_dh_installdocs] Error 2


numba was building successfully with sphinx 2.4.3-2

Marking severity grave since it means other packages can't use sphinx
(via sphinx-build at least). It should be prevented from migration to
testing if that's the case.


-- 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.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-sphinx depends on:
ii  python33.8.2-3
ii  python3-alabaster  0.7.8-1.1
ii  python3-babel  2.8.0+dfsg.1-3
ii  python3-distutils  3.8.3-2
ii  python3-docutils   0.16+dfsg-2
ii  python3-imagesize  1.2.0-2
ii  python3-jinja2 2.11.1-1
ii  python3-packaging  20.3-1.2
ii  python3-pygments   2.3.1+dfsg-3
ii  python3-requests   2.23.0+dfsg-2
ii  sphinx-common  2.4.3-3

Versions of packages python3-sphinx recommends:
ii  make 4.3-1
ii  python3-pil  7.0.0-4+b1

Versions of packages python3-sphinx suggests:
ii  dvipng 1.15-1.1+b1
ii  fonts-freefont-otf 20120503-10
ii  imagemagick-6.q16  8:6.9.10.23+dfsg-2.1+b2
ii  latexmk1:4.69a-0.1
ii  libjs-mathjax  2.7.8+dfsg-1
ii  python3-lib2to33.8.3-2
ii  python3-sphinx-rtd-theme   0.4.3+dfsg-3
pn  python3-stemmer
pn  sphinx-doc 
ii  texlive-fonts-recommended  2020.20200522-1
ii  texlive-latex-extra2020.20200522-1
ii  texlive-latex-recommended  2020.20200522-1
ii  texlive-plain-generic  2020.20200522-1

-- no debconf information

Bug#961334: octave-mapping FTBFS on big endian: test failures

[Rafael Laboissière]

* Adrian Bunk  [2020-05-28 12:40]:


Control: reassign -1 octave-io 2.6.1-1
Control: affects -1 src:octave-mapping
Control: close -1 2.6.1-2

On Thu, May 28, 2020 at 09:32:04AM +0200, Rafael Laboissière wrote:

* Adrian Bunk  [2020-05-23 15:33]:


Source: octave-mapping
Version: 1.4.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=octave-mapping=s390x=1.4.0-1=1586986257=0

... shaperead: file /tmp/oct-fdWy3e.dbf couldn't be read;   no 
attributes appended ! test failed ASSERT errors for:  assert (sum 
(ism),numel (ism))


 Location  |  Observed  |  Expected  |  Reason
()   35 Abs err 2 exceeds tol 0 by 2
... shaperead: file /tmp/oct-mxym2n.dbf couldn't be read;   no 
attributes appended ! test failed ASSERT errors for:  assert (sum 
(ism),numel (ism))


 Location  |  Observed  |  Expected  |  Reason
()   46 Abs err 2 exceeds tol 0 by 2
... Summary: 386 tests, 384 passed, 0 known failures, 0 skipped Some 
tests failed.  Giving up... make: *** [debian/rules:5: binary-arch] 
Error 1


The bug is actually in the dbfwrite and dbfread functions in the octave-io 
package, which are used in the unit test of function shapewrite of the 
octave-mapping package, whose failure is shown above.


I filed a bug report in the upstream bug tracker, regarding this issue: 
https://savannah.gnu.org/bugs/index.php?58457


I will patch the octave-io package, in order to fix the problem.


Thanks, octave-mapping built now. 
I am updating the bug metadata.


I uploaded version 1.4.0-2 of the octave-mapping package, which 
build-depends on octave-io >= 2.6.1-2.


Thanks,

Rafael

Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel

[Dirk Eddelbuettel]

Hi Paul,

On 28 May 2020 at 08:23, Paul Gevers wrote:
| Hi Dirk,
| 
| On 28-05-2020 01:14, Dirk Eddelbuettel wrote:
| > Shall I close this one 'by hand'?  Or will it get closed by migrating
| > quantlib-swig?  I just close the other one (#956830) that was at the start 
of
| > this by hand.
| 
| I closed the bug the moment I filed it. Albeit that's a bit weird, I
| have multiple reasons to do that (I use a template for these bugs):
| 
| - The Release Team considers the version in TESTING from having an RC
| issue. So, the version in unstable is fine, and if it migrates, the
| Release Team's concern is addressed.
| 
| - If the package migrates without a new upload, it's easy for the
| maintainer to forget to close the issue. Then we need manual actions to
| close it, or QA needs to find these unclosed bugs later. The BTS doesn't
| archive unclosed bugs.

Strange. I could swear I saw it as open when looking from my QA page...

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#961709: lintian: Warn if R binary packages don't depend on virtual r-api-* package

[Dirk Eddelbuettel]

On 28 May 2020 at 10:10, Dylan Aïssi wrote:
| Package: lintian
| Version: 2.77.1
| Severity: wishlist
| X-Debbugs-CC: debia...@lists.debian.org
| 
| Hi,
| 
| I just saw a R binary package (r-cran-isospec) with wrong dependencies
| (bug not yet opened). Lintian doesn't warn about a problem in its
| dependencies, so it would be cool to add a new warning (maybe
| "missing-dependency-on-r-api") to warn if any R binary packages (
| r-{cran|bioc|other}-* ) don't depend at least to a virtual r-api-*
| package.

Not a bad idea.

OTOH the way we implement the tag doesn't it get added automagically by the
r-base-core package when constructing an r-{cran,bioc,...}-* package?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#961733: freedombox: Please remove Recommends: haveged

[Sunil Mohan Adapa]

On 28/05/20 6:43 am, Chris Hofstaedtler wrote:
> Package: freedombox
> Version: 20.9
> Severity: wishlist
> 
> Dear Maintainer,
> 
> your package currently Recommends: haveged. On modern kernels, so
> whatever will ship in bulleye, the kernel will provide enough entropy,
> so there should be no need for haveged, except in exceptional
> situations.
> 
> Please remove the Recommends: haveged.
> 

Hi Chris,

Thank you for the bug report. Since the report indicates that Buster
will likely still need it, do you see any issue with keeping it for
Bullseye (currently we are testing the same code base for Bullseye and
Buster backports)? Also, any pointers to the behavior of modern kernels
would be nice.

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine

[Boyuan Yang]

Hi,

(see bottom)

Roland Plüss  于2020年5月28日周四 上午10:45写道：
>
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "dragengine"
>
> * Package name : dragengine
> Version : 1.1
> Upstream Author : rol...@rptd.ch
> * URL : https://dragondreams.ch
> * License : LGPL-3.0+
> * Vcs : upstream debianization branch:
> https://github.com/LordOfDragons/dragengine/tree/debian
> Section : x11
>
> It builds those binary packages:
>
> dragengine - Drag[en]gine Game Engine
> dragengine-dev - Drag[en]gine Game Engine Development
> deigde - Drag[en]gine Game Development Environment
> deigde-dev - Drag[en]gine IGDE Development
>
> To access further information about this package, please visit the
> following URL:
>
> https://mentors.debian.net/package/dragengine

Long story short, this hasn't reached a satisfactory quality. I will
point out issues
I found but there are more to fix.

* Please make sure the debian/files file does not exist in your packaging.
This file is automatically created and should not be created manually.

* Your debian/postinst script is missing the #DEBHELPER# placeholder.

* Your debian/postinst file has to recognize whether it is being
called during installation,
upgrade or removal. See
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html for
details.
I guess the best way is to take a look at existing postinst scripts
written by others.

* Official Debian packages in "main" section should not manipulate
files under /opt/ directory at any time.
Your package will be part of the system, not some so called "Optional
application software packages".
Please place files following the File Hierarchy Standard (FHS) using
directories under /usr/.

* You are using "3.0 (native)" format, which is not suitable for a
non-Debian-specific project.
See 
https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#native-dh-make
for details. Please use "3.0 (quilt)" format.

* Your "Build-Depends" field is missing way too many build
dependencies. An easy example
is that if scons is not installed on your system, your package surely
cannot build. Please list
all non-trivial build-dependencies required to build your package. See
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydeps
for details.

* Your package bundles way too many external libraries under /extern/
directories. You must
either document license information for those project or exclude those
files from your source code.
If building your package needs those libraries, please use existing
libraries in current Debian archive.

There are other issues but I'd rather stop here. Since you yourself is
also the upstream,
it could be possible for you to actually review the software
buildsystem (scons scripts) since it seems
to have diverted from traditional software installation procedures on
UNIX-like platforms. In any case,
the source repository and packaging scripts your provided need improvement.

-- 
Regards,
Boyuan Yang

Bug#961740: printf attempts to parse options and fails to print --help

[Melvin Vermeeren]

Package: coreutils
Version: 8.30-3

Hi,

POSIX specifies printf has no options, meaning this should print "--help". 
Arguments parsing must simply not be attempted at all in order to be compliant 
as far as I know.

$ /usr/bin/printf --help
Usage: /usr/bin/printf FORMAT [ARGUMENT]...
  or:  /usr/bin/printf OPTION

  ...

>From https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html:
> SYNOPSIS
>
>printf format [argument...]
>
> ...
>
> OPTIONS
>
>None.

Bash also does not handle this correctly. However bash is not POSIX sh, hence 
it is not a bug. (It appears bash some some "printf -v var" extension.) I also 
tested zsh, which appears to be fully compliant.

Thanks,

-- 
Melvin Vermeeren

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

Bug#961739: printf attempts to parse options and fails to print -h or similar

[Melvin Vermeeren]

Package: dash
Version: 0.5.10.2-5

Hi,

POSIX specifies printf has no options, meaning these should print "-h" and "--
help" respectively. Arguments parsing must simply not be attempted at all in 
order to be compliant as far as I know.

$ printf -h
sh: 1: printf: Illegal option -h
$ printf --help
sh: 2: printf: Illegal option --

>From https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html:
> SYNOPSIS
>
>printf format [argument...]
>
> ...
>
> OPTIONS
>
>None.

Bash also does not handle this correctly. However bash is not POSIX sh, hence 
it is not a bug. (It appears bash some some "printf -v var" extension.) I also 
tested zsh, which appears to be fully compliant.

Thanks

-- 
Melvin Vermeeren

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