Bug#943327: mmdebstrap: Please support using pixz

[Johannes Schauer]

On Wed, 13 Nov 2019 18:36:43 +0100 Benjamin Drung 
 wrote:
> > > When I developed the patch, I just checked that the tarball was created
> > > and the file size matches, but I didn't check the content.
> > 
> > ah indeed. This is of course because mmdebstrap assembles the tarball
> > from two
> > parts and then runs the compressor outside of tar. A correct patch
> > probably
> > look more like this:
> > 
> > @@ -161,7 +161,7 @@ sub get_tar_compressor($) {
> >  } elsif ($filename =~ /\.lz4$/) {
> > return 'lz4';
> >  } elsif ($filename =~ /\.(xz|txz)$/) {
> > -   return 'xz';
> > +   return ('xz', '--threads=0');
> >  } elsif ($filename =~ /\.zst$/) {
> > return 'zstd';
> >  }
> 
> I have tested this proposed change by dirty patching the two exec
> lines:
> 
> exec ($tar_compressor, '--threads=0') or error "[...]";
> 
> It works and creates a tarball. The generated tarball is actually working
> (verified by using it).

fixed in git:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/9f2ea61265c36945b1fbbc27fd70099e58df794d


signature.asc
Description: signature

Bug#936207: biosig4c++: Python2 removal in sid/bullseye

[Alois Schloegl]

On Tue, 5 Nov 2019 12:27:42 -0800 Steve Langasek
 wrote:
> However, after applying that patch, the package fails to build because:
> 
>  - it tries to invoke python, which is not present.  Fixed by setting
>PYTHON=python3 in MAKEOPTS from debian/rules.
>  - the python3 pkgconfig handling is completely messed up in
>python/setup.py; it tries to find a pkgconfig file in the system
>directory (why, when it's part of the same source package we're just
>building right now?), and when it doesn't find it, under python3 it
>raises a different exception than ValueError, so the fallback code
>doesn't work.  And if I set PKG_CONFIG_PATH to point at the libbiosig.pc
>in the parent directory, it just fails later at linking time because ../
>isn't on the linker path.
> 
> I'm stopping my investigation there, it really looks like this needs some
> upstream cleanup.
> 
> -- 
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org


Dear Steve,


I'm not sure what debian expects, and what kind of changes you would
expect. If there is some documentation about this, please point me to
that, and I'll have a look what I can do.

If you say the "fallback code" does not work, beause of "rais[ing] a
different exception than ValueError", perhaps removing that part (see
attached
patch_remove-python-setup-pkgconfig-exception.diff
) might solve this.


In any case, the installation of biosig-python works if libbiosig is
available on the system, in which case one needs to do only

pip install numpy pkgconfig
pip install Biosig-1.9.1.tar.gz

where Biosig-1.9.1.tar.gz is just built in python/dist with this command:
cd python && make release

I provide the sources also here
 https://pub.ist.ac.at/~schloegl/biosig/prereleases/Biosig-1.9.1.tar.gz



Kind regards,
   Alois

diff --git a/biosig4c++/python/setup.py b/biosig4c++/python/setup.py
index 8539a20a..be9e437b 100644
--- a/biosig4c++/python/setup.py
+++ b/biosig4c++/python/setup.py
@@ -12,17 +12,11 @@ except ImportError:
 import os
 import numpy.distutils.misc_util as mu
 
-try:
-import pkgconfig
-PKG=pkgconfig.parse('libbiosig')
-CPATH=PKG['include_dirs']
-LIBS=PKG['libraries']
-LIBDIR=PKG['library_dirs']
-except ValueError:
-print('cannot load pkgconfig(libbiosig) - use default location')
-CPATH='/usr/local/include'
-LIBS='-lbiosig'
-LIBDIR='/usr/local/lib'
+import pkgconfig
+PKG=pkgconfig.parse('libbiosig')
+CPATH=PKG['include_dirs']
+LIBS=PKG['libraries']
+LIBDIR=PKG['library_dirs']
 
 module_biosig = Extension('biosig',
 define_macros = [('MAJOR_VERSION', '1'), ('MINOR_VERSION', '9')],

Bug#944923: mmdebstrap: depends on perl-doc seemingly nedlessly

[Johannes Schauer]

Control: tag -1 + pending

On Sun, 17 Nov 2019 23:23:54 +0100 Jonas Smedegaard  wrote:
> Good to hear that.  Happy to help just a tiny bit on this marvellous tool!

You are very welcome! Your input is very appreciated. :)

Fixed in git:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/aad36777e80a8094d1e97656918faa6bba96fa51


signature.asc
Description: signature

Bug#945814: audacity: various segfaults of audacity on startup

[Tjeerd Pinkert]

Package: audacity
Version: 2.2.2-1+b1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

thanks for creating a normally very stable and properly functioning system.

* What led up to the situation?
I tried to start the program audacity
$ audacity

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

* What was the outcome of this action?
various responces follow:

:~$ audacity
lo server running on 15889
../src/common/debugrpt.cpp(453): assert "IsOk()" failed in AddContext():
use IsOk() first [in thread 7f6f3c5f1700]
Segmentation fault

:~$ audacity -v
lo server running on 15901
munmap_chunk(): invalid pointer
Aborted

:~$ audacity
lo server running on 15907
Warning: failed to load part<>!
Segmentation fault

:~$ audacity
lo server running on 15911
../src/common/debugrpt.cpp(453): assert "IsOk()" failed in AddContext():
use IsOk() first [in thread 7f76eb92d700]
Segmentation fault

:~$ audacity
lo server running on 15918
Segmentation fault

:~$ audacity
lo server running on 15923
Segmentation fault

:~$ audacity --version
lo server running on 15942
double free or corruption (fasttop)
Aborted

:~$ audacity
lo server running on 15947
malloc_consolidate(): invalid chunk size
Aborted

:~$ audacity
lo server running on 15950
../src/common/debugrpt.cpp(453): assert "IsOk()" failed in AddContext():
use IsOk() first [in thread 7f70fa1a0700]
Segmentation fault

:~$ audacity
lo server running on 15953
../src/common/debugrpt.cpp(453): assert "IsOk()" failed in AddContext():
use IsOk() first [in thread 7f0f2862d700]
Segmentation fault

* What outcome did you expect instead?
I expected audacity to start
I was not able to resolve the problem.

I hope the problem may be solved...

Best regards,


Tjeerd Pinkert



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

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

Versions of packages audacity depends on:
ii  audacity-data  2.2.2-1
ii  libasound2 1.1.8-1
ii  libavcodec-extra58 [libavcodec58]  7:4.1.4-1~deb10u1
ii  libavformat58  7:4.1.4-1~deb10u1
ii  libavutil567:4.1.4-1~deb10u1
ii  libc6  2.28-10
ii  libexpat1  2.2.6-2+deb10u1
ii  libflac++6v5   1.3.2-3
ii  libflac8   1.3.2-3
ii  libgcc11:8.3.0-6
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libgtk2.0-02.24.32-3
ii  libid3tag0 0.15.1b-14
ii  liblilv-0-00.24.2~dfsg0-2
ii  libmad00.15.1b-10
ii  libmp3lame03.100-2+b1
ii  libogg01.3.2-1+b1
ii  libportaudio2  19.6.0-1
ii  libportsmf00.1~svn20101010-5
ii  libsndfile11.0.28-6
ii  libsoundtouch1 2.1.2+ds1-1
ii  libsoxr0   0.1.2-3
ii  libstdc++6 8.3.0-6
ii  libsuil-0-00.10.0~dfsg0-1
ii  libtwolame00.3.13-4
ii  libvamp-hostsdk3v5 2.7.1~repack0-1
ii  libvorbis0a1.3.6-2
ii  libvorbisenc2  1.3.6-2
ii  libvorbisfile3 1.3.6-2
ii  libwxbase3.0-0v5   3.0.4+dfsg-8
ii  libwxgtk3.0-0v53.0.4+dfsg-8

audacity recommends no packages.

Versions of packages audacity suggests:
ii  amb-plugins [ladspa-plugin]   0.8.1-7
ii  ambdec [ladspa-plugin]0.7.1-1
ii  autotalent [ladspa-plugin]0.2-5
ii  blepvco [ladspa-plugin]   0.1.0-3+b1
ii  blop [ladspa-plugin]  0.2.8-6.1
ii  bs2b-ladspa [ladspa-plugin]   0.9.1-3
ii  caps [ladspa-plugin]  0.9.26-1
ii  cmt [ladspa-plugin]   1.16-2
ii  csladspa [ladspa-plugin]  1:6.11.1-1
ii  fil-plugins [ladspa-plugin]   0.3.0-6
ii  guitarix-ladspa [ladspa-plugin]   0.36.1-1+b1
ii  invada-studio-plugins-ladspa [ladspa-plugin]  0.3.1-5
ii  ladspa-sdk [ladspa-plugin]1.13-3
ii  mcp-plugins [ladspa-plugin]   0.4.0-6
ii  omins [ladspa-plugin] 0.2.0-7.1
ii  rev-plugins [la

Bug#937213: openslide-python: diff for NMU version 1.1.1-4.1

[Andreas Tille]

Thanks a lot, commited to Git.

On Thu, Nov 28, 2019 at 09:37:46PM -0500, Sandro Tosi wrote:
> Control: tags 937213 + patch
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for openslide-python (versioned as 1.1.1-4.1). The diff
> is attached to this message.
> 
> Regards.
> 

> diff -Nru openslide-python-1.1.1/debian/changelog 
> openslide-python-1.1.1/debian/changelog
> --- openslide-python-1.1.1/debian/changelog   2018-10-29 05:37:28.0 
> -0400
> +++ openslide-python-1.1.1/debian/changelog   2019-11-28 21:35:22.0 
> -0500
> @@ -1,3 +1,10 @@
> +openslide-python (1.1.1-4.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Deop python support; Closes: #937213
> +
> + -- Sandro Tosi   Thu, 28 Nov 2019 21:35:22 -0500
> +
>  openslide-python (1.1.1-4) unstable; urgency=medium
>  
>* debhelper 11
> diff -Nru openslide-python-1.1.1/debian/control 
> openslide-python-1.1.1/debian/control
> --- openslide-python-1.1.1/debian/control 2018-10-29 05:37:28.0 
> -0400
> +++ openslide-python-1.1.1/debian/control 2019-11-28 21:35:03.0 
> -0500
> @@ -6,9 +6,6 @@
>  Priority: optional
>  Build-Depends: debhelper (>= 11~),
> dh-python,
> -   python-dev,
> -   python-pil,
> -   python-setuptools,
> python3-all-dev,
> python3-pil,
> python3-setuptools,
> @@ -18,39 +15,6 @@
>  Vcs-Git: https://salsa.debian.org/med-team/openslide-python.git
>  Homepage: http://openslide.org
>  
> -Package: python-openslide
> -Architecture: any
> -Depends: ${shlibs:Depends},
> - ${misc:Depends},
> - ${python:Depends},
> - libopenslide0 (>= 3.4.0),
> - python-pil | python-imaging
> -Recommends: python-openslide-examples
> -Provides: ${python:Provides}
> -Description: Python 2 wrapper for reading whole slide image files
> - OpenSlide is a C library that provides a simple interface to read 
> whole-slide
> - images also known as virtual slides.
> - .
> - Whole-slide images, also known as virtual slides, are large, high resolution
> - images used in digital pathology. Reading these images using standard image
> - tools or libraries is a challenge because these tools are typically designed
> - for images that can comfortably be uncompressed into RAM or a swap file.
> - Whole-slide images routinely exceed RAM sizes, often occupying tens of
> - gigabytes when uncompressed. Additionally, whole-slide images are typically
> - multi-resolution, and only a small amount of image data might be needed at a
> - particular resolution.
> - .
> - This library currently supports:
> -  - Aperio (.svs, .tif)
> -  - Hamamatsu (.vms, .vmu, .ndpi)
> -  - Leica (.scn)
> -  - MIRAX (.mrxs)
> -  - Sakura (.svslide)
> -  - Trestle (.tif)
> -  - Generic tiled TIFF (.tif)
> - .
> - This package contains the Python 2 module needed to run OpenSlide 
> applications.
> -
>  Package: python3-openslide
>  Architecture: any
>  Depends: ${shlibs:Depends},
> @@ -86,9 +50,9 @@
>  Package: python-openslide-examples
>  Architecture: all
>  Depends: ${misc:Depends},
> - python-flask | python3-flask,
> + python3-flask,
>   libjs-jquery,
> - python-openslide | python3-openslide
> + python3-openslide
>  Description: Python examples for python-openslide and python3-openslide
>   OpenSlide is a C library that provides a simple interface to read 
> whole-slide
>   images also known as virtual slides.
> diff -Nru openslide-python-1.1.1/debian/rules 
> openslide-python-1.1.1/debian/rules
> --- openslide-python-1.1.1/debian/rules   2018-10-29 05:37:28.0 
> -0400
> +++ openslide-python-1.1.1/debian/rules   2019-11-28 21:35:15.0 
> -0500
> @@ -5,7 +5,7 @@
>  export DEB_BUILD_MAINT_OPTIONS = hardening=+all
>  
>  %:
> - dh $@ --with python2,python3 --buildsystem=pybuild
> + dh $@ --with python3 --buildsystem=pybuild
>  
>  override_dh_installexamples:
>   dh_installexamples -ppython-openslide-examples -Xjquery.js examples/*

> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Bug#945813: spfft -- Sparse 3D FFT library with MPI, OpenMP, CUDA / ROCm support

[merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name    : spfft
  Version : 0.9.9
  Upstream Author : ETH Zurich, Simon Frasch
* URL : https://github.com/eth-cscs/SpFFT
* License : BSD-3-Clause
  Programming Lang: C
  Description : Sparse 3D FFT library with MPI, OpenMP, CUDA / ROCm
support (development files)
 SpFFT was originally intended for transforms of data with spherical
cutoff in
 frequency domain, as required by some computational material science codes.
 For distributed computations, SpFFT uses a slab decomposition in space
domain
 and pencil decomposition in frequency domain (all sparse data within a
pencil
 must be on one rank). If desired, the libray can be compiled without any
 parallelization (MPI, OpenMP, CUDA / ROCm).
 .
 This package contains development files.

spfft is required by Sirius [1], a domain specific library for
electronic structure calculations, which I intend to eventually package.

[1] https://github.com/electronic-structure/SIRIUS

Remark: This package is to be maintained with Debian Science Maintainers at
   https://salsa.debian.org/science-team/spfft

Bug#855151: #855151: tasksel: should not be Priority: important

[Cyril Brulebois]

Hi,

Holger Wansing  (2019-11-29):
> For specific reasons (I was unable to build the installer / the netboot
> target here locally because I was still on oldstable, for other reasons)

FWIW I'm still running stretch but having schroots around to build
whatever needs built in a different environment is rather fine. ;)

> I could not test the impacts of reducing the priority to optional.
> So my approach was the try-and-error way to simply see what happens
> (sorry for my ignorance on this, assuming such approach is acceptable
> in this early development stage).

I don't think you could realistically double check what happens without
hacking your own (possibly partial) archive since priorities in packages
are still overridden on the archive side…

> Because of some hassle with the Debian archive while processing the
> tasksel 3.57 upload (done by nicoo), my tasksel_3.58 upload did not worked as
> usual, and 3.58 did not reached unstable until now.
> Thus, the 'dropping priority of tasksel to optional' changing did not 
> reach the daily builds of d-i yet :-((
> 
> ...

I've noticed those problems thanks to questions from Nicolas on the
#debian-release IRC channel, that's what got me interested in latest
tasksel versions.

> Given that I upgraded my machine to Buster last week, there is a new
> chance, that I can now give it a try, and test what happens actually
> with the latest tasksel changes ...

Thinking about this change a little more, even if we were to publish D-I
Bullseye Alpha 1 right now, which will be tested to be working… I think
once ftp-masters update their overrides, this will break the published
Alpha immediately.

Instead of rushing a change right now (it's been months without a
release already), I think I'll ask them to postpone updating their
overrides until we're up for an Alpha 2. Which means we'll have a clear
breakage at the timing of our choosing, a way to double check the
effects of the bug, and to ensure proposed patches do the work
appropriately, instead of implementing things blindly in a hurry, right
now.


Possible timeframe for another Alpha: once a newer major kernel version
hits testing.

Cc-ing the submitter back, since Ansgar was requesting the change but
might also end up being the one pushing the buttons on the ftp-master
side.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#945119: mmdebstrap: Fail to mmdebstrap Jessie with systemd components (missing /dev/urandom)

[Johannes Schauer]

Control: tag -1 + pending

On Thu, 21 Nov 2019 20:40:00 +0100 Johannes Schauer  wrote:
> Quoting Vincent Caron (2019-11-20 02:45:07)
> > Thanks a lot for mmdebstrap, I use it to generate images for my Xen
> > cluster, it's efficient and works like a charm.
> > 
> > I have a small bug when using it to generate Jessie images with systemd
> > components, when systemd's postinst invokes 'systemd-machine-id-setup'
> > and this one fails because it cannot find any /dev/urandom. Reproduce
> > with :
> > 
> > ./mmdebstrap --mode=unshare --include systemd jessie jessie.tar.gz
> > ...
> > Setting up systemd (215-17+deb8u7) ...
> > Failed to read /proc/cmdline. Ignoring: No such file or directory
> > Failed to open /dev/urandom: Function not implemented
> > dpkg: error processing package systemd (--install):
> >  subprocess installed post-installation script returned error exit
> > status 1
> > 
> > I've worked around this by adding a
> > --setup-hook='systemd-machine-id-setup --root $1' which is quite a hack
> > and works because my host has systemd.
> 
> yes, I can reproduce this behaviour. I never tested mmdebstrap with Jessie, so
> I'm surprised that there are not more bugs. :)
> 
> The reason is simple: when installing the Essential:yes packages, mmdebstrap
> does this without first mounting /proc and /sys or setting up /dev. This is 
> not
> a problem with stretch, buster, testing or unstable because none of those have
> any packages in the Essential:yes set which requires this setup. In Jessie
> though, the package "init" is Essential:yes and thus, systemd will get
> installed and that one needs all this setup.
> 
> The solution is thus also simple: also run the initial installation of
> Essential:yes packages with the proper setup of /proc, /sys and /dev. I tried
> this locally and it doesn't seem to break any test in the testsuite.

fixed in git:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/de8b6a457d8ea5fa67394107fee796c44f37c32e

> 
> > And then I encounter a last (related?) bug :
> > 
> > ./mmdebstrap --mode=unshare --setup-hook='systemd-machine-id-setup --
> > root $1' --include systemd jessie jessie.tar.gz
> > ...
> > I: installing apt...
> > done
> > E: run_chroot failed: E: cannot make_path ./dev/pts/
> > 
> > It seems than around line 777 when creating type==5/directory it goes
> > thru the havemknod==false path and fails. But if I bypass this block, it
> > proceeds with bind-mouting /dev/pts which works, and I get my working
> > tarball.
> 
> This is a good find, thank you! Mmdebstrap uses File::Path::make_path and then
> throws an error if no path was created. In your case, ./dev/pts already
> existed, so an error is wrongly emitted. Instead, the make_path call not
> error out when the path already exists.

fixed in git:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/f5afbfaab095c713d9f1ae877606b6924e3e44c9


signature.asc
Description: signature

Bug#943325: mmdebstrap requires that the correct keyring is specified

[Johannes Schauer]

Hi,

On Wed, 13 Nov 2019 18:53:28 +0100 Johannes Schauer  wrote:
> Quoting Benjamin Drung (2019-11-13 18:47:09)
> > Thanks for implementing it. Specifying --keyring before --aptopt fails:
> > 
> > mmdebstrap --keyring=/usr/share/keyrings/debian-archive-keyring.gpg \
> >   -v --aptopt='Acquire::http { Proxy "123"; }' \
> >   buster /tmp/buster.tar.xz
> I know. The situation is actually worse. The problem is, that apt only allows 
> a
> single keyring file or directory. This means that we cannot have apt use the
> keyrings on the host and any manually specified keyrings at the same time. 
> This
> is a problem.
> 
> A solution would be to copy all keyring material from the host plus all
> additionally specified keys into the chroot. But this would dirty the chroot
> with all kinds of keyrings from the host, many of which are probably not meant
> to end up in every chroot the user creates.
> 
> I'm still thinking about the right solution to this problem...

okay, I think I have a solution that might fix all of this.

By default, when not manually passing a string like "deb http://... dist comp"
as a MIRROR argument, mmdebstrap will add the signed-by option to the
sources.list for known distributions. This would mean that for Debian, Ubuntu,
Taglu und Kali, apt would automatically choose the single right key file from
/usr/share/keyrings instead of using /etc/apt/trusted.gpg.

Since apt only supports only a single Dir::Etc::Trusted or
Dir::Etc::TrustedParts option, the --keyring option can be made to override the
default of /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d, respectively.

Alternatively, (but this already works today) the user can always use the
MIRROR argument together with the signed-by option to pass a custom keyring
location for a specific mirror.

I think this should cover all possible use-cases.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#944677: mmdebstrap: /var/log/apt/eipp.log.xz remains in tarball/output

[Johannes Schauer]

Control: tag -1 + pending

On Wed, 13 Nov 2019 17:39:59 +0100 Benjamin Drung 
 wrote:
> I noticed that /var/log/apt/eipp.log.xz remains in the tarball/output.  This
> is a log file from APT and should be better removed to make the output better
> reproducible.

fixed in git:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/3a1d5413e23a68395616e3e748a15dbc6d09cad3


signature.asc
Description: signature

Bug#945763: gcc-9 ftbfs on mipsel

[YunQiang Su]

在 2019-11-29五的 07:00 +0100，Matthias Klose写道：
> On 28.11.19 18:09, YunQiang Su wrote:
> > Matthias Klose  于2019年11月28日周四 下午5:51写道：
> > > On 28.11.19 10:44, Matthias Klose wrote:
> > > > Package: src:gcc-9
> > > > Version: 9.2.1-20
> > > > Severity: serious
> > > > Tags: sid bullseye
> > > > 
> > > > gcc-9 ftbfs on mipsel with a bootstrap comparison failure, most
> > > > likely triggered
> > > > by the LTO build enabled in -20.
> > > > 
> > > > bootstrap comparison failure!
> > > > libbacktrace/elf.o differs
> > > > libbacktrace/.libs/elf.o differs
> > > > make[4]: *** [Makefile:24878: compare] Error 1
> > > 
> > > Please could you have a look?
> > 
> > sure. I will look at it tomorrow
> 
> hmm, that also fails in gcc-7, which didn't see any code changes from
> 7.5.0-1 to
> 7.5.0-2.

Maybe, it meets a buggy machine?

Bug#944295: thunderbird: Spellcheck fixed to "English (United States)"

[intrigeri]

Hi,

Carsten Schoenert:
> Adding as a quick test a line

> export DICPATH=/usr/share/hunspell

> to the wrapper script /usr/bin/thunderbird brings back all the
> dictionaries I've installed long ago.

Note that the same issue in Firefox was fixed like this:

  * debian/browser.links.in, debian/rules, debian/vendor.js: Use the
spellchecker.dictionary_path pref to set the hunspell directory.

I confirm that setting this pref fixes the problem with Thunderbird 68:

  pref("spellchecker.dictionary_path", "/usr/share/hunspell");

I'll let Carsten decide whether that's any better than setting
$DICPATH :)

Cheers,
-- 
intrigeri

Bug#945812: virtualbox-dkms: Missing changeset 81586 in vbox

[Michael Ott]

Package: virtualbox-dkms
Version: 6.0.14-dfsg-3
Severity: important

Dear Maintainer,

In changelog it seems that you add the changeset 81587 but not the
changeset 81586 (https://www.virtualbox.org/changeset/81586/vbox)

I cannot compile the kernel module from virtualbox for kerneln 5.4 with
the following error message:
In file included from 
/var/lib/dkms/virtualbox/6.0.14/build/vboxdrv/r0drv/linux/alloc-r0drv-linux.c:31:
/var/lib/dkms/virtualbox/6.0.14/build/vboxdrv/r0drv/linux/alloc-r0drv-linux.c: 
In function ‘VBoxHost_RTMemContAlloc’:
/var/lib/dkms/virtualbox/6.0.14/build/vboxdrv/r0drv/linux/the-linux-kernel.h:340:47:
 error: implicit declaration of function ‘set_pages_x’; did you mean 
‘set_pages_rw’? [-Werror=implicit-function-declaration]
  340 | # define MY_SET_PAGES_EXEC(pPages, cPages)set_pages_x(pPages, 
cPages)
  |   ^~~
/var/lib/dkms/virtualbox/6.0.14/build/vboxdrv/r0drv/linux/alloc-r0drv-linux.c:447:13:
 note: in expansion of macro ‘MY_SET_PAGES_EXEC’
  447 | MY_SET_PAGES_EXEC(&paPages[iPage], 1);
  | ^
  CC [M]  
/var/lib/dkms/virtualbox/6.0.14/build/vboxdrv/r0drv/linux/mp-r0drv-linux.o
/var/lib/dkms/virtualbox/6.0.14/build/vboxdrv/r0drv/linux/alloc-r0drv-linux.c: 
In function ‘VBoxHost_RTMemContFree’:
/var/lib/dkms/virtualbox/6.0.14/build/vboxdrv/r0drv/linux/the-linux-kernel.h:341:47:
 error: implicit declaration of function ‘set_pages_nx’; did you mean 
‘set_pages_rw’? [-Werror=implicit-function-declaration]
  341 | # define MY_SET_PAGES_NOEXEC(pPages, cPages)  set_pages_nx(pPages, 
cPages)
  |   ^~~~
/var/lib/dkms/virtualbox/6.0.14/build/vboxdrv/r0drv/linux/alloc-r0drv-linux.c:495:13:
 note: in expansion of macro ‘MY_SET_PAGES_NOEXEC’
  495 | MY_SET_PAGES_NOEXEC(&paPages[iPage], 1);
  | ^~~
cc1: some warnings being treated as errors
  CC [M]  
/var/lib/dkms/virtualbox/6.0.14/build/vboxdrv/r0drv/linux/mpnotification-r0drv-linux.o
make[3]: *** 
[/usr/src/linux-headers-5.4.0-trunk-common/scripts/Makefile.build:271: 
/var/lib/dkms/virtualbox/6.0.14/build/vboxdrv/r0drv/linux/alloc-r0drv-linux.o] 
Error 1

After add the changeset I can compile it

CU
  Michael 

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (710, 'unstable'), (670, 'testing'), (660, 'experimental'), (600, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages virtualbox-dkms depends on:
ii  dkms  2.8.1-3

Versions of packages virtualbox-dkms recommends:
ii  virtualbox  6.0.14-dfsg-3

virtualbox-dkms suggests no packages.

-- no debconf information

Bug#945763: gcc-9 ftbfs on mipsel

[Matthias Klose]

On 28.11.19 18:09, YunQiang Su wrote:
> Matthias Klose  于2019年11月28日周四 下午5:51写道：
>>
>> On 28.11.19 10:44, Matthias Klose wrote:
>>> Package: src:gcc-9
>>> Version: 9.2.1-20
>>> Severity: serious
>>> Tags: sid bullseye
>>>
>>> gcc-9 ftbfs on mipsel with a bootstrap comparison failure, most likely 
>>> triggered
>>> by the LTO build enabled in -20.
>>>
>>> bootstrap comparison failure!
>>> libbacktrace/elf.o differs
>>> libbacktrace/.libs/elf.o differs
>>> make[4]: *** [Makefile:24878: compare] Error 1
>>
>> Please could you have a look?
> 
> sure. I will look at it tomorrow

hmm, that also fails in gcc-7, which didn't see any code changes from 7.5.0-1 to
7.5.0-2.

Bug#945811: maskprocessor FTCBFS: help2man

[Helmut Grohne]

Source: maskprocessor
Version: 0.73+git20170609.1708898-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

maskprocessor fails to cross build from source, because it uses
help2man. This doesn't work at all during cross compilation.
Fortunately, maskprocessor has so few dependencies that we can simply
build it twice: Once for help2man and once for real. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru maskprocessor-0.73+git20170609.1708898/debian/changelog 
maskprocessor-0.73+git20170609.1708898/debian/changelog
--- maskprocessor-0.73+git20170609.1708898/debian/changelog 2018-09-07 
09:51:46.0 +0200
+++ maskprocessor-0.73+git20170609.1708898/debian/changelog 2019-11-29 
06:34:08.0 +0100
@@ -1,3 +1,10 @@
+maskprocessor (0.73+git20170609.1708898-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Build twice for help2man. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 29 Nov 2019 06:34:08 +0100
+
 maskprocessor (0.73+git20170609.1708898-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru maskprocessor-0.73+git20170609.1708898/debian/rules 
maskprocessor-0.73+git20170609.1708898/debian/rules
--- maskprocessor-0.73+git20170609.1708898/debian/rules 2018-09-07 
09:04:41.0 +0200
+++ maskprocessor-0.73+git20170609.1708898/debian/rules 2019-11-29 
06:34:08.0 +0100
@@ -1,5 +1,6 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
@@ -10,7 +11,12 @@
rm -f mp64.1
 
 override_dh_auto_build:
-   $(MAKE) -C src
+   dpkg-architecture -f -a$(DEB_BUILD_ARCH) -c dh_auto_build 
--sourcedirectory=src
help2man -i debian/extra-man-info.txt \
  -n 'high-performance word generator with a per-position configurable 
charset' \
   -N ./src/mp64 > mp64.1
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+   rm src/mp64
+   dh_auto_build --sourcedirectory=src
+endif
+

Bug#945810: jpylyzer: diff for NMU version 1.18.0-3.1

[Sandro Tosi]

Package: jpylyzer
Version: 1.18.0-3
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for jpylyzer (versioned as 1.18.0-3.1). The diff
is attached to this message.

You claim this package is maintainer under the DPMT umbrella, but the repo
is not up to date with the uploads to the Debian archive since 4 years!

Regards.

diff -Nru jpylyzer-1.18.0/debian/changelog jpylyzer-1.18.0/debian/changelog
--- jpylyzer-1.18.0/debian/changelog	2018-10-11 15:24:05.0 -0400
+++ jpylyzer-1.18.0/debian/changelog	2019-11-29 00:30:33.0 -0500
@@ -1,3 +1,10 @@
+jpylyzer (1.18.0-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add a python3-jpylyzer package
+
+ -- Sandro Tosi   Fri, 29 Nov 2019 00:30:33 -0500
+
 jpylyzer (1.18.0-3) unstable; urgency=medium
 
   * Bump Std-Vers. No changes needed
diff -Nru jpylyzer-1.18.0/debian/control jpylyzer-1.18.0/debian/control
--- jpylyzer-1.18.0/debian/control	2018-10-11 15:19:51.0 -0400
+++ jpylyzer-1.18.0/debian/control	2019-11-29 00:27:15.0 -0500
@@ -8,6 +8,7 @@
lmodern,
pandoc,
python (>= 2.6.6-3~), python-setuptools,
+   python3 (>= 2.6.6-3~), python3-setuptools,
texlive-fonts-recommended,
texlive-xetex
 Standards-Version: 4.2.1
@@ -18,6 +19,18 @@
 Architecture: all
 Depends: ${misc:Depends}, ${python:Depends}
 Suggests: pirl-image-tools
+Description: JP2 (JPEG 2000 Part 1) validator and properties extractor (Python 2)
+ Validator and feature extractor for JP2 (JPEG 2000 Part 1 - ISO/IEC 15444-1)
+ images. Jpylyzer was specifically created to check that a JP2 file really
+ conforms to the format's specifications. Additionally jpylyzer is able to
+ extract the technical characteristics of each image.
+ .
+ This package contains the Python 2 version of jpylyzer .
+
+Package: python3-jpylyzer
+Architecture: all
+Depends: ${misc:Depends}, ${python3:Depends}
+Suggests: pirl-image-tools
 Description: JP2 (JPEG 2000 Part 1) validator and properties extractor
  Validator and feature extractor for JP2 (JPEG 2000 Part 1 - ISO/IEC 15444-1)
  images. Jpylyzer was specifically created to check that a JP2 file really
diff -Nru jpylyzer-1.18.0/debian/jpylyzer jpylyzer-1.18.0/debian/jpylyzer
--- jpylyzer-1.18.0/debian/jpylyzer	2016-02-09 05:07:54.0 -0500
+++ jpylyzer-1.18.0/debian/jpylyzer	2019-11-29 00:29:39.0 -0500
@@ -1,4 +1,4 @@
-#! /usr/bin/env python
+#! /usr/bin/env python3
 from jpylyzer.jpylyzer import main
 
 if __name__ == "__main__":
diff -Nru jpylyzer-1.18.0/debian/python3-jpylyzer.install jpylyzer-1.18.0/debian/python3-jpylyzer.install
--- jpylyzer-1.18.0/debian/python3-jpylyzer.install	1969-12-31 19:00:00.0 -0500
+++ jpylyzer-1.18.0/debian/python3-jpylyzer.install	2019-11-28 23:25:20.0 -0500
@@ -0,0 +1,2 @@
+/usr/lib/python3*
+debian/jpylyzer usr/bin
diff -Nru jpylyzer-1.18.0/debian/python-jpylyzer.install jpylyzer-1.18.0/debian/python-jpylyzer.install
--- jpylyzer-1.18.0/debian/python-jpylyzer.install	2016-02-09 05:12:47.0 -0500
+++ jpylyzer-1.18.0/debian/python-jpylyzer.install	2019-11-28 23:25:04.0 -0500
@@ -1,2 +1 @@
-/usr/lib/python*
-debian/jpylyzer usr/bin
+/usr/lib/python2*
diff -Nru jpylyzer-1.18.0/debian/rules jpylyzer-1.18.0/debian/rules
--- jpylyzer-1.18.0/debian/rules	2018-10-11 15:19:06.0 -0400
+++ jpylyzer-1.18.0/debian/rules	2019-11-29 00:28:03.0 -0500
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with python2
+	dh $@ --with python2,python3 --buildsystem=pybuild
 
 VERSION=$(shell dpkg-parsechangelog | grep '^Version' | cut -d' ' -f2 | cut -f1 -d-)
 

Bug#945809: calibre-bin contains duplicate man pages which prevent installation

[Anthony Fok]

Package: calibre-bin
Version: 4.5.0+dfsg-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

calibre-bin 4.5.0+dfsg-1 fails to install because it contains duplicate
man page files which already exist in the calibre package:

Preparing to unpack .../calibre-bin_4.5.0+dfsg-1_amd64.deb ...
Unpacking calibre-bin (4.5.0+dfsg-1) over (4.4.0+dfsg-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/calibre-bin_4.5.0+dfsg-1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/ar/man1/calibre-customize.1.gz', which 
is also in package calibre 4.5.0+dfsg-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/calibre-bin_4.5.0+dfsg-1_amd64.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

4.4.0+dfsg-1 was fine, i.e. calibre-bin containing only the architecture
dependent plugins.

Thanks in advance!

Anthony

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

Versions of packages calibre-bin depends on:
ii  libc6 2.29-3
ii  libchm1   2:0.40a-5+b1
ii  libfontconfig12.13.1-2+b1
ii  libfreetype6  2.10.1-2
ii  libgcc1   1:9.2.1-20
it  libglib2.0-0  2.62.3-1
ii  libhunspell-1.7-0 1.7.0-2+b1
ii  libicu63  63.2-2
ii  libmtp9   1.1.16-2
ii  libpodofo0.9.60.9.6+dfsg-5
ii  libpython2.7  2.7.17-1
ii  libqt5core5a [qtbase-abi-5-12-5]  5.12.5+dfsg-2
ii  libqt5dbus5   5.12.5+dfsg-2
ii  libqt5gui55.12.5+dfsg-2
ii  libqt5widgets55.12.5+dfsg-2
ii  libssl1.1 1.1.1d-2
ii  libstdc++69.2.1-20
ii  libusb-1.0-0  2:1.0.23-1
ii  python-sip [sip-api-12.7] 4.19.19+dfsg-2+b1
ii  python2.7 2.7.17-1
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages calibre-bin recommends:
iu  calibre  4.5.0+dfsg-1

calibre-bin suggests no packages.

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEFCQhsZrUqVmW+VBy6iUAtBLFms8FAl3gq+kACgkQ6iUAtBLF
ms/lqA/7B/92gPFryoDt5Opuy8pGJ1G29BHHAsN3YP/tHJ6kvsP06p7E5twwGjLn
zyFTHaXZNf2BHfcD7cnKCW3ThQLM2sDeqifZf8RsldqaevjgDw8jFNwdWPGVo6dn
GHaJ1jJI5iiaWjRMKEainm+HpBAgoHJva7RBRKfqjyrYGBYAp9QtupYmZgmKcR6f
z7TftKHcpZWfrPwfntKTq3iqwLXhObxqRkKW14p3vhemZ1kXC8nMUtTLfdR2SAnB
Lrp/DwRGyNKQlyOvHZC5J7y87Ffw6t0lxDrojtpfxaFiS2YkdSv7PVjrabjxv48K
3ezoMunWotOUvL3Ghr1GvFuASMeAp9Z1OL6XUF5usgVCYQb/ceRyL0td+M1lAhVQ
0Plvc0wmcp8rFkMI5BGoHVdvIeZzCheMJWyZo7wupnXBHYJr3hloDjAI1DD7dtbM
SIAkRO5DeL/TAJZf2pf6WDkcoJS0+svc53qDKx6itz9rGeQwIBTbk0CtwjMPGhoQ
XDVKkmlz0bDDeJA9975Gq6zUwQaHg21tm3PQ0Kj1l71qccfA1Zdv8dZJaQaWedtc
9ApPoAmOveT72/TJ6jG4DbAu5yuf7SI8vMwOX6vjhWz+FwXVUM78KPGIZ8Vywa7k
iTqybH2G+0UdHL+tnH0FNR2RUccXESwmwoBxGUTvYv4V2Isun1A=
=pgvq
-END PGP SIGNATURE-

Bug#945796: [Pkg-rust-maintainers] Bug#945796: rust-url-serde: (build-)depends on obsolete virtual package.

[Wolfgang Silbermayr]

On 11/28/19 9:04 PM, peter green wrote:
> Package: rust-url-serde
> Version: 0.2.0-1
> Severity: serious
> Tags: bullseye, sid
> 
> librust-url-serde-dev depends on and rust-url-serde build-depends on
> librust-url-1+default-dev which is no longer provided by rust-url. It
> seems to have been replaced by librust-url-2+default-dev

The url_serde crate has been updated the last time to 0.2.0 on April 30,
2017. It lived in the servo rust-url repository, where it got removed on
July 15, 2019. To me it seems to be obsolete. Nothing (build-)depends on
it yet. I assume it got packaged as a dependency for something else, but
either that something didn't get packaged yet, or it doesn't require
this crate any more.

@paride can you please check and file a ROM if no longer needed?

Thanks.

Bug#945808: RM: hachoir-core -- RoQA; python2-only; dead upstream; no rdeps (just other hachoir packages filed for RM)

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#945806: RM: hachoir-regex -- RoQA; python2-only; dead upstream; no rdeps (src:hachoir-subfile is filed for RM too)

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#945805: RM: hachoir-subfile -- RoQA; python2-only; dead upstream; no rdeps

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#945807: RM: hachoir-parser -- RoQA; python2-only; dead upstream; no rdeps (just other hachoir packages filed for RM)

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#945804: RM: hachoir-urwid -- RoQA; python2-only; dead upstream; no rdeps

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#945803: RM: hachoir-wx -- RoQA; python2-only; dead upstream; no rdeps

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#936338: cpuset: diff for NMU version 1.6-3.1

[Roberto C . Sánchez]

On Thu, Nov 28, 2019 at 09:20:30PM -0500, Sandro Tosi wrote:
> Control: tags 936338 + patch
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for cpuset (versioned as 1.6-3.1). The diff
> is attached to this message.
> 
Hi Sandro,

Many thanks for taking care of this.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#945769: python-dmsh: 1

[Drew Parsons]

Source: python-dmsh
Followup-For: Bug #945769
Control: forwarded -1 https://github.com/nschloe/dmsh/issues/10

Yeah, this one has us scratching our heads.  Can't reproduce locally.

The precision need to pass on debci would be more than 10%, which is
getting a little ridiculous though we might have to stoop to it to get
the package through.


-- 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.3.0-2-amd64 (SMP w/4 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#937213: openslide-python: diff for NMU version 1.1.1-4.1

[Sandro Tosi]

Control: tags 937213 + patch


Dear maintainer,

I've prepared an NMU for openslide-python (versioned as 1.1.1-4.1). The diff
is attached to this message.

Regards.

diff -Nru openslide-python-1.1.1/debian/changelog openslide-python-1.1.1/debian/changelog
--- openslide-python-1.1.1/debian/changelog	2018-10-29 05:37:28.0 -0400
+++ openslide-python-1.1.1/debian/changelog	2019-11-28 21:35:22.0 -0500
@@ -1,3 +1,10 @@
+openslide-python (1.1.1-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Deop python support; Closes: #937213
+
+ -- Sandro Tosi   Thu, 28 Nov 2019 21:35:22 -0500
+
 openslide-python (1.1.1-4) unstable; urgency=medium
 
   * debhelper 11
diff -Nru openslide-python-1.1.1/debian/control openslide-python-1.1.1/debian/control
--- openslide-python-1.1.1/debian/control	2018-10-29 05:37:28.0 -0400
+++ openslide-python-1.1.1/debian/control	2019-11-28 21:35:03.0 -0500
@@ -6,9 +6,6 @@
 Priority: optional
 Build-Depends: debhelper (>= 11~),
dh-python,
-   python-dev,
-   python-pil,
-   python-setuptools,
python3-all-dev,
python3-pil,
python3-setuptools,
@@ -18,39 +15,6 @@
 Vcs-Git: https://salsa.debian.org/med-team/openslide-python.git
 Homepage: http://openslide.org
 
-Package: python-openslide
-Architecture: any
-Depends: ${shlibs:Depends},
- ${misc:Depends},
- ${python:Depends},
- libopenslide0 (>= 3.4.0),
- python-pil | python-imaging
-Recommends: python-openslide-examples
-Provides: ${python:Provides}
-Description: Python 2 wrapper for reading whole slide image files
- OpenSlide is a C library that provides a simple interface to read whole-slide
- images also known as virtual slides.
- .
- Whole-slide images, also known as virtual slides, are large, high resolution
- images used in digital pathology. Reading these images using standard image
- tools or libraries is a challenge because these tools are typically designed
- for images that can comfortably be uncompressed into RAM or a swap file.
- Whole-slide images routinely exceed RAM sizes, often occupying tens of
- gigabytes when uncompressed. Additionally, whole-slide images are typically
- multi-resolution, and only a small amount of image data might be needed at a
- particular resolution.
- .
- This library currently supports:
-  - Aperio (.svs, .tif)
-  - Hamamatsu (.vms, .vmu, .ndpi)
-  - Leica (.scn)
-  - MIRAX (.mrxs)
-  - Sakura (.svslide)
-  - Trestle (.tif)
-  - Generic tiled TIFF (.tif)
- .
- This package contains the Python 2 module needed to run OpenSlide applications.
-
 Package: python3-openslide
 Architecture: any
 Depends: ${shlibs:Depends},
@@ -86,9 +50,9 @@
 Package: python-openslide-examples
 Architecture: all
 Depends: ${misc:Depends},
- python-flask | python3-flask,
+ python3-flask,
  libjs-jquery,
- python-openslide | python3-openslide
+ python3-openslide
 Description: Python examples for python-openslide and python3-openslide
  OpenSlide is a C library that provides a simple interface to read whole-slide
  images also known as virtual slides.
diff -Nru openslide-python-1.1.1/debian/rules openslide-python-1.1.1/debian/rules
--- openslide-python-1.1.1/debian/rules	2018-10-29 05:37:28.0 -0400
+++ openslide-python-1.1.1/debian/rules	2019-11-28 21:35:15.0 -0500
@@ -5,7 +5,7 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_installexamples:
 	dh_installexamples -ppython-openslide-examples -Xjquery.js examples/*

Bug#937889: python-librtmp: diff for NMU version 0.3.0-1.1

[Sandro Tosi]

Control: tags 937889 + patch


Dear maintainer,

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

Regards.

diff -Nru python-librtmp-0.3.0/debian/changelog python-librtmp-0.3.0/debian/changelog
--- python-librtmp-0.3.0/debian/changelog	2016-02-10 16:03:19.0 -0500
+++ python-librtmp-0.3.0/debian/changelog	2019-11-28 21:22:52.0 -0500
@@ -1,3 +1,10 @@
+python-librtmp (0.3.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937889
+
+ -- Sandro Tosi   Thu, 28 Nov 2019 21:22:52 -0500
+
 python-librtmp (0.3.0-1) unstable; urgency=low
 
   * New upstream version
diff -Nru python-librtmp-0.3.0/debian/control python-librtmp-0.3.0/debian/control
--- python-librtmp-0.3.0/debian/control	2016-02-10 14:07:49.0 -0500
+++ python-librtmp-0.3.0/debian/control	2019-11-28 21:22:52.0 -0500
@@ -6,44 +6,23 @@
 Build-Depends: debhelper (>= 9),
  dh-python,
  librtmp-dev,
- python-all-dev,
  python3-all-dev,
- python-all-dbg,
  python3-all-dbg,
- python-cffi,
  python3-cffi,
- python-cffi-backend-dbg,
  python3-cffi-backend-dbg,
- python-setuptools,
  python3-setuptools,
- python-singledispatch,
- python3 (>= 3.4) | python3-singledispatch
+ python3 (>= 3.4)
 Homepage: http://pythonhosted.org/python-librtmp/
 Vcs-Git: https://github.com/breunigs/python-librtmp-debian
 Vcs-Browser: https://github.com/breunigs/python-librtmp-debian
 
-Package: python-librtmp
-Architecture: any
-Depends: ${misc:Depends},
- ${python:Depends},
- ${shlibs:Depends},
- python-cffi,
- python-singledispatch,
- librtmp1
-Provides: ${python:Provides}
-Description: librtmp binding for Python 2
- librtmp allows one to dump the media content streamed over
- the RTMP protocol.
- .
- This package provides the binding for Python 2.
-
 Package: python3-librtmp
 Architecture: any
 Depends: ${misc:Depends},
  ${python3:Depends},
  ${shlibs:Depends},
  python3-cffi,
- python3 (>= 3.4) | python3-singledispatch,
+ python3 (>= 3.4),
  librtmp1
 Provides: ${python3:Provides}
 Description: librtmp binding for Python 3
@@ -52,27 +31,12 @@
  .
  This package provides the binding for Python 3.
 
-Package: python-librtmp-dbg
-Section: debug
-Architecture: any
-Priority: extra
-Depends: ${misc:Depends},
- ${python:Depends},
- ${shlibs:Depends},
- python-dbg,
- python-librtmp (= ${binary:Version})
-Description: librtmp binding for Python 2 - Debugging symbols
- librtmp allows one to dump the media content streamed over
- the RTMP protocol.
- .
- This package contains debugging symbols for Python 2.
-
 Package: python3-librtmp-dbg
 Section: debug
 Architecture: any
 Priority: extra
 Depends: ${misc:Depends},
- ${python:Depends},
+ ${python3:Depends},
  ${shlibs:Depends},
  python3-dbg,
  python3-librtmp (= ${binary:Version})
diff -Nru python-librtmp-0.3.0/debian/rules python-librtmp-0.3.0/debian/rules
--- python-librtmp-0.3.0/debian/rules	2016-02-10 14:07:49.0 -0500
+++ python-librtmp-0.3.0/debian/rules	2019-11-28 21:22:48.0 -0500
@@ -4,7 +4,7 @@
 export PYBUILD_NAME=librtmp
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_installchangelogs:
 	dh_installchangelogs HISTORY.rst

Bug#936338: cpuset: diff for NMU version 1.6-3.1

[Sandro Tosi]

Control: tags 936338 + patch


Dear maintainer,

I've prepared an NMU for cpuset (versioned as 1.6-3.1). The diff
is attached to this message.

Regards.

diff -Nru cpuset-1.6/debian/changelog cpuset-1.6/debian/changelog
--- cpuset-1.6/debian/changelog	2019-09-03 14:28:49.0 -0400
+++ cpuset-1.6/debian/changelog	2019-11-28 21:12:13.0 -0500
@@ -1,3 +1,10 @@
+cpuset (1.6-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #936338
+
+ -- Sandro Tosi   Thu, 28 Nov 2019 21:12:13 -0500
+
 cpuset (1.6-3) unstable; urgency=medium
 
   * python-cpuset: Add dependency on python-future (Closes: #939116)
diff -Nru cpuset-1.6/debian/control cpuset-1.6/debian/control
--- cpuset-1.6/debian/control	2019-09-03 14:28:49.0 -0400
+++ cpuset-1.6/debian/control	2019-11-28 21:10:58.0 -0500
@@ -2,13 +2,13 @@
 Maintainer: Roberto C. Sanchez 
 Section: utils
 Priority: optional
-Build-Depends: debhelper (>= 10), python-all (>= 2.6.6-3~), python3-all, dh-python, quilt
+Build-Depends: debhelper (>= 10), python3-all, dh-python, quilt
 Standards-Version: 4.4.0
 Homepage: https://github.com/lpechacek/cpuset
 
 Package: cpuset
 Architecture: all
-Depends: python-cpuset (= ${binary:Version}), ${python:Depends}, ${misc:Depends}
+Depends: python3-cpuset (= ${binary:Version}), ${python3:Depends}, ${misc:Depends}
 Description: Allows manipluation of cpusets and provides higher level fun
  Cpuset is a Python application to make using the cpusets facilities in the
  Linux kernel easier. The actual included command is called cset and it allows
@@ -17,20 +17,6 @@
  .
  This package contains the cset command-line utility.
 
-Package: python-cpuset
-Section: python
-Architecture: all
-Depends: python-future, ${python:Depends}, ${misc:Depends}
-Replaces: cpuset (<< 1.6~)
-Breaks: cpuset (<< 1.6~)
-Description: manipluation of cpusets and provides higher level fun - Python 2.x
- Cpuset is a Python application to make using the cpusets facilities in the
- Linux kernel easier. The actual included command is called cset and it allows
- manipulation of cpusets on the system and provides higher level functions such
- as implementation and control of a basic CPU shielding setup.
- .
- This package contains the Python 2.x modules.
-
 Package: python3-cpuset
 Section: python
 Architecture: all
diff -Nru cpuset-1.6/debian/rules cpuset-1.6/debian/rules
--- cpuset-1.6/debian/rules	2019-09-03 14:28:49.0 -0400
+++ cpuset-1.6/debian/rules	2019-11-28 21:12:04.0 -0500
@@ -15,13 +15,11 @@
 export PYBUILD_NAME=cpuset
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_install:
 	dh_auto_install
 	mkdir -p $(CURDIR)/debian/cpuset/usr/bin
-	mv $(CURDIR)/debian/python-cpuset/usr/bin/cset $(CURDIR)/debian/cpuset/usr/bin
-	rm -rf $(CURDIR)/debian/python-cpuset/usr/share/doc/cpuset \
-		$(CURDIR)/debian/python3-cpuset/usr/share/doc/cpuset \
-		$(CURDIR)/debian/python-cpuset/usr/bin \
+	mv $(CURDIR)/debian/python3-cpuset/usr/bin/cset $(CURDIR)/debian/cpuset/usr/bin
+	rm -rf $(CURDIR)/debian/python3-cpuset/usr/share/doc/cpuset \
 		$(CURDIR)/debian/python3-cpuset/usr/bin

Bug#945802: sshfp: should this package be removed?

[Sandro Tosi]

Package: sshfp
Severity: serious

Hello,
i believe sshfp should be removed:

* it's python2-only
* no upstream release in 8+ years
* it's a leaf package.

If i dont hear back in 7 days with a good reason to keep tis pacakge, i'll file
for its removal.

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

Versions of packages sshfp depends on:
ii  libpython2.7-stdlib [python-argparse]  2.7.16-2
ii  openssh-client 1:7.9p1-10
ii  python 2.7.16-1
pn  python-dnspython   
pn  python-ipcalc  
pn  python-ldns

sshfp recommends no packages.

sshfp suggests no packages.

Bug#945771: found possible fix

[Juha Heinanen]

After reporting the bug, I found this article:

https://hobo.house/2018/05/18/fix-for-intel-i915-gpu-freeze-on-recent-linux-kernels/

and tried what is suggested, i.e., added file

cat > /etc/X11/xorg.conf.d/10-intel.conf <

Bug#945426: pylint doesn't ship the test libraries anymore

[Joseph Herlant]

Hi,

FYI what I'm looking for is the test_functional-related classes
and those have been moved to pylint/testutils.py in the upcoming
version 2.5 so we can also wait until that new version is released and
leave the tests in the source package only tooif you want.

Thanks,
Joseph

Bug#945618:

[thomasw]

I have to appologize for an error I made when reporting this. It can actually 
be reproduced in both Arch and Debian. The difference was that I didn't have 
pulseaudio installed on my Arch system. I am blind and use Orca. If I have Orca 
playing through pulse, the pc states are not entered in both Arch and Debian 
with the newer kernels. If pulse is on but Orca is disabled, I can enter the pc 
states. I am not sure if all sounds playing through pulse cause the pc states 
to not be entered or if this is specifically an 
Orca/speech-dispatcher/espeak-ng problem. I had sighted assistance reading 
powertop with Orca disabled and could only test this one case with no sounds 
playing (sighted help is limited in my current living situation). The 
information in my first message about the kernels where this occurs and those 
in which this does not occur is still accurate. I don't think this matters but 
I will include that I use the Mate desktop.

Bug#944588: lib-st-console-perl: Strange naming convention for a perl package

[Thiago]

Hi,
Thanks for your tip.
I will rename the package to a default naming convention for a perl module.
I believe that in future other packages may use this math module, do you 
have another opinion?


Regards,

--
...
⢀⣴⠾⠻⢶⣦⠀ Thiago Andrade Marques
⣾⠁⢰⠒⠀⣿⡁ GPG: 4096R/F8CDB08B
⢿⡄⠘⠷⠚⠋⠀ GPG Fingerprint: 1D38 EE3C 624F 955C E1FA  3C85 5A30 3591 F8CD B08B
⠈⠳⣄

Bug#945801: wish: file picker: enable lookahead search again

[Michael Meier]

Package: libgtk-3-0
Version: 3.24.5-1
Severity: wishlist

Since years the recursive search of the gtk file picker is driving me nuts each
time I have to use it (fortunately only a very few programs use it). As it
seems there is no option which lets the user choose what he prefers...
At least archlinux does have a package (patch?) which enables the old typeahead
search (only in the same folder) again.

https://aur.archlinux.org/packages/gtk3-typeahead/

Would there be any chance that could be incorporated into debian?



-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (400, 'testing'), (300, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme   3.30.1-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.34.0-3~bpo10+1
ii  libatk1.0-0  2.34.0-1~bpo10+1
ii  libc62.29-3
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcolord2   1.4.3-4
ii  libcups2 2.2.10-6+deb10u1
ii  libepoxy01.5.3-0.1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.10.1-2
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-common  3.24.5-1
ii  libharfbuzz0b2.3.1-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangoft2-1.0-01.42.4-7~deb10u1
ii  librest-0.7-00.8.1-1
ii  libsoup2.4-1 2.64.2-2
ii  libwayland-client0   1.16.0-1
ii  libwayland-cursor0   1.16.0-1
ii  libwayland-egl1  1.16.0-1
ii  libx11-6 2:1.6.7-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxinerama1 2:1.1.4-2
ii  libxkbcommon00.8.2-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  shared-mime-info 1.10-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin  3.24.5-1

Versions of packages libgtk-3-0 suggests:
pn  gvfs 
ii  librsvg2-common  2.44.10-2.1

Versions of packages libgtk-3-0 is related to:
pn  appmenu-gtk3-module   
pn  fcitx-frontend-gtk3   
pn  gcin-gtk3-immodule
pn  gtk-vector-screenshot 
pn  gtk3-engines-xfce 
pn  gtk3-im-libthai   
pn  hime-gtk3-immodule
pn  ibus-gtk3 
pn  imhangul-gtk3 
ii  libcanberra-gtk3-module   0.30-7
pn  libcaribou-gtk3-module
pn  libgtk3-nocsd0
pn  maliit-inputcontext-gtk3  
pn  packagekit-gtk3-module
pn  scim-gtk-immodule 
pn  topmenu-gtk3  
pn  uim-gtk3  
pn  uim-gtk3-immodule 

-- no debconf information

Bug#936169: autopep8: Python2 removal in sid/bullseye

[Nicholas D Steeves]

Hi Sylvestre and Matthias,

Matthias and/or Scott, please see below and comment, I might have found
a way to slightly speed up Python 2 removal.

Sylvestre Ledru  writes:

> Le 28/11/2019 à 23:46, Nicholas D Steeves a écrit :
>> Hi Matthias and Sylvestre,
>>
>> On Fri, Aug 30, 2019 at 07:10:59AM +, Matthias Klose wrote:
>>> - Convert your Package to Python3. This is the preferred option.  In
>>>case you are providing a Python module foo, please consider dropping
>>>the python-foo package, and only build a python3-foo package.  Please
>>>don't drop Python2 modules, which still have reverse dependencies,
>>>just document them.
>>>
>>>This is the preferred option.
>> I took care of this using the preferred option, and resolved
>> associated issues, and I'll leave the upload up to you.
> Many thanks
>>   Please note
>> that py-autopep8-el and vim-autopep8 still block this upload.
>
> What do you mean by that? your changes build fine?
>

* check for reverse dependencies (including build-depends)
* if there are any, you cannot remove it yet!
https://wiki.debian.org/Python/2Removal

Yup, it builds fine! :-)  Also, I just checked to make sure it runs
properly, and found that the py3 variant depends on python3-lib2to3 (not
sure why that wasn't autodetected)

I've fixed py-autopep8-el in git, but someone else need to update
vim-autopep8.  Then we should coordinate to all upload on the same day,
to minimise breakage.  IMHO there is no need to stage this change in
experimental, because there are only three affected packages, including
this one.

It would also be nice to see the following three issues fixed for the
next upload, but of course I'll understand if you're too busy, and none
of them are RC:

1. Add autopkgtests
2. Switch to debhelper-compat 12 (should be safe, but it's always a good
idea to diffoscope the results)
3. Fix the bad header in the manpage generated with help2man.  Ideally
it'd be nice to solve this with Sphinx, rst2man, or some other method.

> thanks again :)

No problem, any time!

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#855151: #855151: tasksel: should not be Priority: important

[Holger Wansing]

Hi,

Cyril Brulebois  wrote:
> Holger Wansing  (2019-11-01):
> > Holger Levsen  wrote:
> > > On Wed, Oct 23, 2019 at 11:52:22PM +0200, Holger Wansing wrote:
> > > > > > tasksel is currently at Priority: important and thus installed in 
> > > > > > every
> > > > > > installation, including chroots installed via debootstrap.  It 
> > > > > > doesn't
> > > > > > seem a useful package to install in chroots though.
> > > > > > 
> > > > > > It would be nice if d-i would install tasksel (and maybe remove it 
> > > > > > at
> > > > > > the end of the installation again?) so the priority of the tasksel 
> > > > > > and
> > > > > > tasksel-data packages could be downgraded.
> > > > > I think that's indeed a fair topic for the buster release cycle.
> > > > Should we downgrade tasksel to something like optional now?
> > > 
> > > now indeed seems to be a good moment for this. (and I'd appreciate this
> > > change for the reasons Ansgar pointed out.)
> > 
> > Just committed, thanks.
> 
> AFAICT from reading the bug log, it seems the part where the priority is
> downgraded was implemented. But was there any modifications to ensure
> that d-i would still install it, so that pkgsel can run tasksel? Or was
> such modifications not needed at all?

For specific reasons (I was unable to build the installer / the netboot
target here locally because I was still on oldstable, for other reasons)
I could not test the impacts of reducing the priority to optional.
So my approach was the try-and-error way to simply see what happens
(sorry for my ignorance on this, assuming such approach is acceptable in this 
early development stage).

Because of some hassle with the Debian archive while processing the
tasksel 3.57 upload (done by nicoo), my tasksel_3.58 upload did not worked as
usual, and 3.58 did not reached unstable until now.
Thus, the 'dropping priority of tasksel to optional' changing did not 
reach the daily builds of d-i yet :-((

...

Given that I upgraded my machine to Buster last week, there is a new chance,
that I can now give it a try, and test what happens actually with the latest
tasksel changes ...



So long
holgerw




-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#945800: libhwloc-plugins needs to be updated/transitioned to work with libhwloc15 as libhwloc5 is being removed/purged

[shirish शिरीष]

at bottom :-

On 28/11/2019, Samuel Thibault  wrote:
> Hello,
>
> shirish शिरीष, le jeu. 28 nov. 2019 23:16:40 +, a ecrit:
>> While updating today got hit by this bug -
>>
>> oc-plugins:amd64 depends on libhwloc5 (>= 1.11.13~).
>>  libhwlodpkg: libhwloc5:amd64: dependency problems, but removing anyway as 
>> you
>> requested:
>>  libhwloc-plugins:amd64 depends on libhwloc5 (>= 1.11.13~).
>>  libhwloc-plugins:amd64 depends on libhwloc5 (<< 1.11.13A).
>>  libhwlc-plugins:amd64 depends on libhwloc5 (<< 1.11.13A).
>>
>> So it would be nice if it works with libhwloc15 which AFAIK is
>> supposed to take over the functions of libhwloc5.
>
> I don't understand why you are getting any issue at all.
> libhwloc-plugins is available in version 2.1.0+dfsg-2, which should be
> alright. What is preventing your apt from just upgrading it?
>
> When I try the upgrade, I'm getting:
>
> # apt-get dist-upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Done
> The following NEW packages will be installed:
>   libhwloc15
> The following packages will be upgraded:
>   libhwloc-dev libhwloc-plugins
> 2 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0 B/367 kB of archives.
> After this operation, 483 kB of additional disk space will be used.
> Do you want to continue? [Y/n]
> debconf: delaying package configuration, since apt-utils is not installed
> Selecting previously unselected package libhwloc15:amd64.
> (Reading database ... 16186 files and directories currently installed.)
> Preparing to unpack .../libhwloc15_2.1.0+dfsg-2_amd64.deb ...
> Unpacking libhwloc15:amd64 (2.1.0+dfsg-2) ...
> Preparing to unpack .../libhwloc-dev_2.1.0+dfsg-2_amd64.deb ...
> Unpacking libhwloc-dev:amd64 (2.1.0+dfsg-2) over (1.11.13-1) ...
> Preparing to unpack .../libhwloc-plugins_2.1.0+dfsg-2_amd64.deb ...
> Unpacking libhwloc-plugins:amd64 (2.1.0+dfsg-2) over (1.11.13-1) ...
> Setting up libhwloc15:amd64 (2.1.0+dfsg-2) ...
> Setting up libhwloc-dev:amd64 (2.1.0+dfsg-2) ...
> Setting up libhwloc-plugins:amd64 (2.1.0+dfsg-2) ...
> Processing triggers for libc-bin (2.29-3) ...
> #
>
> Samuel
>

At my end, I do have both the new packages. What I was talking about
is dpkg complaining . Perhaps the postinstall script or something
still has the old dependancy somewhere ?

$ dpkg -l libhwloc-plugins libhwloc-dev
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---==
ii  libhwloc-dev:amd64 2.1.0+dfsg-2 amd64Hierarchical view
of the machine - static libs and headers
ii  libhwloc-plugins:amd64 2.1.0+dfsg-2 amd64Hierarchical view
of the machine - plugins

Also not sure what A means in aptitude show below -

$ aptitude why libhwloc15
i   libpmix2 Depends libhwloc-plugins
i A libhwloc-plugins Depends libhwloc15 (< 2.1.0+dfsgA)

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#945800: libhwloc-plugins needs to be updated/transitioned to work with libhwloc15 as libhwloc5 is being removed/purged

[Samuel Thibault]

Hello,

shirish शिरीष, le jeu. 28 nov. 2019 23:16:40 +, a ecrit:
> While updating today got hit by this bug -
> 
> dpkg: libhwloc5:amd64: dependency problems, but removing anyway as you
> requested:
>  libhwloc-plugins:amd64 depends on libhwloc5 (>= 1.11.13~).
>  libhwloc-plugins:amd64 depends on libhwloc5 (<< 1.11.13A).
>  libhwloc-plugins:amd64 depends on libhwloc5 (>= 1.11.13~).
>  libhwloc-plugins:amd64 depends on libhwloc5 (<< 1.11.13A).
> 
> So it would be nice if it works with libhwloc15 which AFAIK is
> supposed to take over the functions of libhwloc5.

I don't understand why you are getting any issue at all.
libhwloc-plugins is available in version 2.1.0+dfsg-2, which should be
alright. What is preventing your apt from just upgrading it?

When I try the upgrade, I'm getting:

# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  libhwloc15
The following packages will be upgraded:
  libhwloc-dev libhwloc-plugins
2 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/367 kB of archives.
After this operation, 483 kB of additional disk space will be used.
Do you want to continue? [Y/n]
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package libhwloc15:amd64.
(Reading database ... 16186 files and directories currently installed.)
Preparing to unpack .../libhwloc15_2.1.0+dfsg-2_amd64.deb ...
Unpacking libhwloc15:amd64 (2.1.0+dfsg-2) ...
Preparing to unpack .../libhwloc-dev_2.1.0+dfsg-2_amd64.deb ...
Unpacking libhwloc-dev:amd64 (2.1.0+dfsg-2) over (1.11.13-1) ...
Preparing to unpack .../libhwloc-plugins_2.1.0+dfsg-2_amd64.deb ...
Unpacking libhwloc-plugins:amd64 (2.1.0+dfsg-2) over (1.11.13-1) ...
Setting up libhwloc15:amd64 (2.1.0+dfsg-2) ...
Setting up libhwloc-dev:amd64 (2.1.0+dfsg-2) ...
Setting up libhwloc-plugins:amd64 (2.1.0+dfsg-2) ...
Processing triggers for libc-bin (2.29-3) ...
#

Samuel

Bug#945800: libhwloc-plugins needs to be updated/transitioned to work with libhwloc15 as libhwloc5 is being removed/purged

[shirish शिरीष]

Package: libhwloc-plugins
Version: 2.1.0+dfsg-2
Severity: normal

Dear Maintainer,
While updating today got hit by this bug -

dpkg: libhwloc5:amd64: dependency problems, but removing anyway as you
requested:
 libhwloc-plugins:amd64 depends on libhwloc5 (>= 1.11.13~).
 libhwloc-plugins:amd64 depends on libhwloc5 (<< 1.11.13A).
 libhwloc-plugins:amd64 depends on libhwloc5 (>= 1.11.13~).
 libhwloc-plugins:amd64 depends on libhwloc5 (<< 1.11.13A).

So it would be nice if it works with libhwloc15 which AFAIK is
supposed to take over the functions of libhwloc5.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages libhwloc-plugins depends on:
ii  libc62.29-3
ii  libhwloc15   2.1.0+dfsg-2
ii  libltdl7 2.4.6-11
ii  libpciaccess00.14-1
ii  libxml2  2.9.4+dfsg1-8
ii  ocl-icd-libopencl1 [libopencl1]  2.2.12-2

libhwloc-plugins recommends no packages.

libhwloc-plugins suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#936169: autopep8: Python2 removal in sid/bullseye

[Sylvestre Ledru]

Hello,

Le 28/11/2019 à 23:46, Nicholas D Steeves a écrit :

Hi Matthias and Sylvestre,

On Fri, Aug 30, 2019 at 07:10:59AM +, Matthias Klose wrote:

Package: src:autopep8
Version: 1.4.4-1
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.

- Convert your Package to Python3. This is the preferred option.  In
   case you are providing a Python module foo, please consider dropping
   the python-foo package, and only build a python3-foo package.  Please
   don't drop Python2 modules, which still have reverse dependencies,
   just document them.
   
   This is the preferred option.

I took care of this using the preferred option, and resolved
associated issues, and I'll leave the upload up to you.

Many thanks

  Please note
that py-autopep8-el and vim-autopep8 still block this upload.


What do you mean by that? your changes build fine?

thanks again :)

S

Bug#945120: the bug hit me today in testing while updating -

[shirish शिरीष]

Dear all,

Somehow the fixes didn't make it to testing and perhaps it slipped by
people that the one which has issues has managed to land in testing.
JFTR -

Package: libopenmpi-dev
Version: 4.0.2-4+b1
Severity: normal

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages libopenmpi-dev depends on:
ii  gfortran [gfortran-mod-15]4:9.2.1-3.1
ii  gfortran-8 [gfortran-mod-15]  8.3.0-24
ii  gfortran-9 [gfortran-mod-15]  9.2.1-19
ii  libevent-dev  2.1.11-stable-1
ii  libhwloc-dev  2.1.0+dfsg-2
ii  libibverbs-dev26.0-2
ii  libopenmpi3   4.0.2-4+b1
ii  openmpi-bin   4.0.2-4+b1
ii  openmpi-common4.0.2-4

Versions of packages libopenmpi-dev recommends:
ii  libcoarrays-openmpi-dev  2.7.1-1

Versions of packages libopenmpi-dev suggests:
pn  openmpi-doc  

-- no debconf information


And this is what upgrade looked like, messy -


Setting up openmpi-common (4.0.2-4) ...
Setting up libopenmpi3:amd64 (4.0.2-4+b1) ...
Setting up openmpi-bin (4.0.2-4+b1) ...
Installing new version of config file /etc/openmpi/openmpi-mca-params.conf ...
Setting up libopenmpi-dev:amd64 (4.0.2-4+b1) ...
update-alternatives: warning: forcing reinstallation of alternative
/usr/lib/x86_64-linux-gnu/openmpi/include because link group
mpi-x86_64-linux-gnu is broken
update-alternatives: warning: skip creation of
/usr/lib/x86_64-linux-gnu/libmpi++.so because associated file
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so (of link group
mpi-x86_64-linux-gnu) doesn't exist
update-alternatives: warning: skip creation of
/usr/lib/x86_64-linux-gnu/libmpi.so because associated file
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so (of link group
mpi-x86_64-linux-gnu) doesn't exist


and as can be seen adequate also talks about the broken-symlink -

openmpi-bin: broken-symlink /usr/bin/ompi-server -> orte-server

It probably will be fixed in say another 24 hrs. but still documenting
the same.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#936169: autopep8: Python2 removal in sid/bullseye

[Nicholas D Steeves]

Hi Matthias and Sylvestre,

On Fri, Aug 30, 2019 at 07:10:59AM +, Matthias Klose wrote:
> Package: src:autopep8
> Version: 1.4.4-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
> 
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.
>   
>   This is the preferred option.

I took care of this using the preferred option, and resolved
associated issues, and I'll leave the upload up to you.  Please note
that py-autopep8-el and vim-autopep8 still block this upload.


Best,
Nicholas


signature.asc
Description: PGP signature

Bug#942282: O: php-horde-core -- Core Horde Framework library (AND all php-horde*!)

[debian]

Hello Mike,

with this manual
https://salsa.debian.org/horde-team/tools/blob/master/README.md

I was successfully building horde packages 6 months ago.
If you want, you can add me to horde team.

Best Regards,
Juri Grabowski

Bug#945799: RM: hachoir-metadata -- RoQA; dead upstream, depends on Py2/Qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove hachoir-metadata. It's dead upstream, depends on Python 2
and Qt4.

Cheers,
Moritz

Bug#945798: RM: hachoir-core -- RoQA; Py2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove hachoir-metadata. It's dead upstream, uses Py2
and has no reverse deps left.

Cheers,
Moritz

Bug#938847: patch

[Moritz Mühlenhoff]

tags 938847 patch
thanks

There are no rev deps left for the Python 2 package, patch attached.

Cheers,
Moritz
diff -Naur xlsxwriter-1.1.2.orig/debian/control xlsxwriter-1.1.2/debian/control
--- xlsxwriter-1.1.2.orig/debian/control	2019-01-22 22:17:12.0 +0100
+++ xlsxwriter-1.1.2/debian/control	2019-11-28 23:11:23.041913286 +0100
@@ -6,33 +6,11 @@
 Section: python
 Priority: optional
 Standards-Version: 4.3.0
-Build-Depends: debhelper (>= 12), dh-python, python, python3,
+Build-Depends: debhelper (>= 12), dh-python, python3,
 #Vcs-Git: https://salsa.debian.org/python-team/modules/xlsxwriter.git
 #Vcs-Browser: https://salsa.debian.org/python-team/modules/xlsxwriter
 Homepage: http://xlsxwriter.readthedocs.org/en/latest/
 
-Package: python-xlsxwriter
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Description: Python module for creating Excel XLSX files
- XlsxWriter is a Python module for writing files in the Excel 2007+ XLSX
- file format.
- .
- XlsxWriter can be used to write text, numbers, formulas and hyperlinks to
- multiple worksheets and it supports features such as formatting and many more,
- including:
- .
-  * 100% compatible Excel XLSX files
-  * Full formatting
-  * Merged cells
-  * Defined names
-  * Charts
-  * Autofilters
-  * Data validation and drop down lists
-  * Conditional formatting
-  * Worksheet PNG/JPEG images
-  * Rich multi-format strings
-
 Package: python3-xlsxwriter
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Naur xlsxwriter-1.1.2.orig/debian/python-xlsxwriter.doc-base xlsxwriter-1.1.2/debian/python-xlsxwriter.doc-base
--- xlsxwriter-1.1.2.orig/debian/python-xlsxwriter.doc-base	2019-01-22 19:15:58.0 +0100
+++ xlsxwriter-1.1.2/debian/python-xlsxwriter.doc-base	1970-01-01 01:00:00.0 +0100
@@ -1,9 +0,0 @@
-Document: xlsxwriter-python-2
-Title: XlsxWriter Manual (Python 2)
-Author: John McNamara 
-Abstract: This manual describes what XlsxWriter is, and how it can be used.
-Section: Programming/Python
-
-Format: HTML
-Index: /usr/share/doc/python-xlsxwriter/docs/readme.html
-Files: /usr/share/doc/python-xlsxwriter/docs/*.html
diff -Naur xlsxwriter-1.1.2.orig/debian/python-xlsxwriter.docs xlsxwriter-1.1.2/debian/python-xlsxwriter.docs
--- xlsxwriter-1.1.2.orig/debian/python-xlsxwriter.docs	2019-01-22 19:15:58.0 +0100
+++ xlsxwriter-1.1.2/debian/python-xlsxwriter.docs	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-docs/
diff -Naur xlsxwriter-1.1.2.orig/debian/python-xlsxwriter.examples xlsxwriter-1.1.2/debian/python-xlsxwriter.examples
--- xlsxwriter-1.1.2.orig/debian/python-xlsxwriter.examples	2019-01-22 21:48:07.0 +0100
+++ xlsxwriter-1.1.2/debian/python-xlsxwriter.examples	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-examples/*
diff -Naur xlsxwriter-1.1.2.orig/debian/rules xlsxwriter-1.1.2/debian/rules
--- xlsxwriter-1.1.2.orig/debian/rules	2019-01-22 21:48:07.0 +0100
+++ xlsxwriter-1.1.2/debian/rules	2019-11-28 23:11:12.309844464 +0100
@@ -2,4 +2,4 @@
 export PYBUILD_NAME=xlsxwriter
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild

Bug#937609: patch

[Moritz Mühlenhoff]

tags 937609 patch
thanks

There are no rev deps left for the Python 2 package, patch attached.

Cheers,
Moritz
diff -Naur python-biplist-1.0.3.orig/debian/control python-biplist-1.0.3/debian/control
--- python-biplist-1.0.3.orig/debian/control	2018-02-22 11:16:31.0 +0100
+++ python-biplist-1.0.3/debian/control	2019-11-28 23:06:38.713524815 +0100
@@ -5,13 +5,9 @@
 Priority: optional
 Build-Depends: debhelper (>= 9),
dh-python,
-   python-all,
python3-all,
-   python-coverage,
python3-coverage,
-   python-nose,
python3-nose,
-   python-setuptools,
python3-setuptools
 X-Python-Version: >= 2.7
 Standards-Version: 4.1.3
@@ -19,17 +15,6 @@
 Vcs-Git: https://salsa.debian.org/python-team/modules/python-biplist.git
 Vcs-Browser: https://salsa.debian.org/python-team/modules/python-biplist
 
-Package: python-biplist
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Description: Python 2 library for reading/writing Mac OS X binary plists
- biplist is a binary plist parser/generator for Python. Binary Property List
- (plist) files provide a faster and smaller serialization format for property
- lists on Mac OS X. This is a library for generating binary plists which can
- be read by Mac OS X, iOS, or other clients.
- .
- This package contains the Python 2 version of biplist.
-
 Package: python3-biplist
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Naur python-biplist-1.0.3.orig/debian/rules python-biplist-1.0.3/debian/rules
--- python-biplist-1.0.3.orig/debian/rules	2017-05-15 11:11:23.0 +0200
+++ python-biplist-1.0.3/debian/rules	2019-11-28 23:06:23.896765389 +0100
@@ -3,4 +3,4 @@
 export PYBUILD_NAME=biplist
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild

Bug#943012: patch

[Moritz Mühlenhoff]

tags 943012 patch
tags 936389 patch
thanks

There are no rev deps left for the Py2 package, patch attached.

Cheers,
Moritz
diff -aur dfwinreg-20190122.orig/debian/control dfwinreg-20190122/debian/control
--- dfwinreg-20190122.orig/debian/control	2019-01-23 10:45:15.0 +0100
+++ dfwinreg-20190122/debian/control	2019-11-28 22:59:41.867272977 +0100
@@ -4,37 +4,19 @@
 Maintainer: Debian Security Tools 
 Uploaders: Hilko Bengen 
 Build-Depends: debhelper (>= 12), dh-python,
- python-dtfabric (>= 20170524), python3-dtfabric (>= 20170524),
- python, python3,
- python-setuptools, python3-setuptools,
- python-dfdatetime (>= 20160814), python3-dfdatetime (>= 20160814),
- python-libregf (>=20150315), python3-libregf (>=20150315),
- python-mock, python3-mock,
- python-six (>= 1.1.0), python3-six (>= 1.1.0),
- python-yaml (>= 3.10),  python3-yaml (>= 3.10),
+ python3-dtfabric (>= 20170524),
+ python3,
+ python3-setuptools,
+ python3-dfdatetime (>= 20160814),
+ python3-libregf (>=20150315),
+ python3-mock,
+ python3-six (>= 1.1.0),
+ python3-yaml (>= 3.10),
 Standards-Version: 4.3.0
 Homepage: https://github.com/log2timeline/dfwinreg
 Vcs-Git: https://salsa.debian.org/pkg-security-team/dfwinreg.git
 Vcs-Browser: https://salsa.debian.org/pkg-security-team/dfwinreg
 
-Package: python-dfwinreg
-Architecture: all
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends},
- python-dtfabric (>= 20170524),
- python-dfdatetime (>= 20160814),
- python-libregf (>=20150315),
- python-mock,
- python-six (>= 1.1.0),
- python-yaml (>= 3.10)
-Description: Digital Forensics Windows Registry library for Python 2
- dfWinReg, or Digital Forensics Windows Registry, provides read-only
- access to Windows Registry objects. The goal of dfWinReg is to
- provide a generic interface for accessing Windows Registry objects
- that resembles the Registry key hierarchy as seen on a live Windows
- system.
- .
- This package contains the library for Python 2.
-
 Package: python3-dfwinreg
 Architecture: all
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends},
diff -aur dfwinreg-20190122.orig/debian/rules dfwinreg-20190122/debian/rules
--- dfwinreg-20190122.orig/debian/rules	2019-01-14 10:46:40.0 +0100
+++ dfwinreg-20190122/debian/rules	2019-11-28 23:00:14.524145178 +0100
@@ -7,19 +7,16 @@
 export PYBUILD_NAME:=dfwinreg
 
 %:
-	dh $@ --with=python2,python3 --buildsystem=pybuild
+	dh $@ --with=python3 --buildsystem=pybuild
 
 override_dh_install:
 	dh_install
 	mv debian/python3-dfwinreg/usr/share/doc/dfwinreg \
 	   debian/python3-dfwinreg/usr/share/doc/python3-dfwinreg
-	mv debian/python-dfwinreg/usr/share/doc/dfwinreg \
-	   debian/python-dfwinreg/usr/share/doc/python-dfwinreg
 	find ./debian -name "LICENSE" -delete
 
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-	python run_tests.py
 	python3 run_tests.py
 endif
 

Bug#944243: logrotate fails with "Permission denied" on LXC guest

[Pierre-Elliott Bécue]

Le mercredi 06 novembre 2019 à 17:27:28+0100, Lukáš Jelínek a écrit :
> journalctl -u logrotate:
>
> Nov 06 17:12:22 syslog systemd[1]: Starting Rotate log files...
> Nov 06 17:12:22 syslog systemd[381]: logrotate.service: Failed to set up 
> mount namespacing: Permission denied
> Nov 06 17:12:22 syslog systemd[381]: logrotate.service: Failed at step 
> NAMESPACE spawning /usr/sbin/logrotate: Permission denied
> Nov 06 17:12:22 syslog systemd[1]: logrotate.service: Main process exited, 
> code=exited, status=226/NAMESPACE
> Nov 06 17:12:22 syslog systemd[1]: logrotate.service: Failed with result 
> 'exit-code'.
> Nov 06 17:12:22 syslog systemd[1]: Failed to start Rotate log files.
>
>
> systemctl status logrotate
>
> ● logrotate.service - Rotate log files
>Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor 
> preset: enabled)
>Active: failed (Result: exit-code) since Wed 2019-11-06 17:12:22 CET; 
> 11min ago
>  Docs: man:logrotate(8)
>man:logrotate.conf(5)
>   Process: 381 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf 
> (code=exited, status=226/NAMESPACE)
>  Main PID: 381 (code=exited, status=226/NAMESPACE)
>
> Nov 06 17:12:22 syslog systemd[1]: Starting Rotate log files...
> Nov 06 17:12:22 syslog systemd[381]: logrotate.service: Failed to set up 
> mount namespacing: Permission denied
> Nov 06 17:12:22 syslog systemd[381]: logrotate.service: Failed at step 
> NAMESPACE spawning /usr/sbin/logrotate: Permission denied
> Nov 06 17:12:22 syslog systemd[1]: logrotate.service: Main process exited, 
> code=exited, status=226/NAMESPACE
> Nov 06 17:12:22 syslog systemd[1]: logrotate.service: Failed with result 
> 'exit-code'.
> Nov 06 17:12:22 syslog systemd[1]: Failed to start Rotate log files.

The systemd service file for logrotate has hardening options[0] that can't
run properly in an unprivileged container (and could also run badly in a
privileged one).

It's not really what I'd call a bug. It's more like a limitation for the
current way things are designed.

[0] cat /lib/systemd/system/logrotate.service

[...]
PrivateDevices=true
PrivateTmp=true
ProtectControlGroups=true
ProtectKernelModules=true
ProtectSystem=full
[...]

If you wish to have things work properly in your container, there are a
couple of solutions. One of these is to systemctl edit logrotate.service
and put this:

[Service]
PrivateDevices=false
PrivateTmp=false
ProtectControlGroups=false
ProtectKernelModules=false
ProtectSystem=false

Save and then you should be good (may take a systemctl daemon-reload,
though).

It's plausible that you don't have to disable all hardening options, I'm
merely pointing these, but maybe some work properly in your container.
It's up to you to get which one is the problem.

man systemd.exec to get the description of the effect of each these
options.

Cheers.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#944389: Add missing log file

[Pierre-Elliott Bécue]

Le samedi 09 novembre 2019 à 01:56:29+0100, Michael Biebl a écrit :
> log file attached
> 
> Probably relevant part is
> 
> > lxc-start autopkgtest-sid 20191109004244.136 WARN cgfsng - 
> > cgroups/cgfsng.c:get_hierarchy:205 - There is no useable devices controller
> > lxc-start autopkgtest-sid 20191109004244.136 ERRORcgfsng - 
> > cgroups/cgfsng.c:cg_legacy_set_data:2299 - Failed to setup limits for the 
> > "devices" controller. The controller seems to be unused by "cgfsng" cgroup 
> > driver or not enabled on the cgroup hierarchy
> > lxc-start autopkgtest-sid 20191109004244.136 WARN cgfsng - 
> > cgroups/cgfsng.c:__cg_legacy_setup_limits:2341 - Failed to set 
> > "devices.deny" to "a"
> 

Thanks for the report, I'll keep an eye on this.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#939168: systemd: LXC container fails to start after stretch->buster update inside container

[Pierre-Elliott Bécue]

Le lundi 02 septembre 2019 à 22:10:52+0300, Sergey Aleynikov a écrit :
> > You should probably attach the output of
> > reportbug --template lxc
> > to this bug report so the lxc maintainers have some context.
> 
> I'm attaching 'lxc-start -n testupg --logfile=lxc.log -l DEBUG' and
> 'reportbug --template lxc' outputs to this message.
> 
> > Checking the existing bug reports, there are already a few which concern
> > sysvinit.
> > I would suggest that you check them out like
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869892
> 
> I've looked at them yesterday, just in case, and didn't see anything
> obviously related. For example, for this one, I already have
> cgroupfs-mount installed and /sys/fs/cgroup present. And while I see
> mounting errors for the container after upgrade (not the attached log,
> but the original container i've tried to upgrade), they do not seem to
> be an immediate cause for the startup failure.

I gave a look at this.

First you're not providing a full context.

 1. Are your containers privileged or unprivileged?
 2. Do you have any LSM installed on the host?

From the log file, it seems that init in the container (systemd) is
returning upon startup.

It is not clear what makes it return, but I'd guess it tries to access
resources it can't.

There was a time when running a container based on systemd on a host
using sysvinit was not working properly. It seems you are encountering
another fragrance of this time.

There are probably ways to debug that, but to me it's due to two
factors:

 1. Containers aren't fully isolated
 2. From 1. systemd relies on resources it can access when the init on
the host is systemd whereas it can't when the init on the host is
something else.

I'd be happy to help if I could, but I have no comparable setup to yours
and I lack time to design an experiment to try and reproduce this bug.

Sorry for that.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#944968: popularity-contest: Program accesses internal dpkg database

[Bill Allombert]

On Thu, Nov 28, 2019 at 08:55:00PM +, Niels Thykier wrote:
> While it would take a bit of restructuring / refactoring, I think it
> would be possible to use a single dpkg-query for everything and still be
> able to process the data in a "streaming" fashion.

Yes this could work, however this is assuming that dpkg-query is not
allocating everything in memory at once.

Cheers,
Bill

Bug#945797: Package is missing pkg-config metadata file

[David Bürgin]

Package: libmilter-dev
Version: 8.15.2-15

The libmilter-dev package does not include a pkg-config metadata file,
and so cannot be used out of the box with pkg-config.

$ pkg-config --libs milter
Package milter was not found in the pkg-config search path.
...

Often (usually?) library development file packages include a pkg-config
metadata file. For example, on my system there are dozens of .pc files
in /usr/lib/x86_64-linux-gnu/pkgconfig that were installed by such
packages.

It would be nice if libmilter-dev could also install a conventional
‘milter.pc’ metadata file. Perhaps there’s even Debian packaging tooling
to generate it?


signature.asc
Description: PGP signature

Bug#944968: popularity-contest: Program accesses internal dpkg database

[Niels Thykier]

On Tue, 19 Nov 2019 11:27:56 +0100 Bill Allombert 
wrote:
> On Tue, Nov 19, 2019 at 09:34:57AM +0100, Guillem Jover wrote:
> > Hi!
> > 
> > On Mon, 2019-11-18 at 06:51:00 +, Niels Thykier wrote:
> > > On Sun, 17 Nov 2019 22:59:58 +0100 Bill Allombert wrote:
> > > > On Sun, Nov 17, 2019 at 10:44:02PM +0100, Guillem Jover wrote:
> > > > > Source: popularity-contest
> > > > > Source-Version: 1.69
> > > > > Severity: important
> > > > > User: debian-d...@lists.debian.org
> > > > > Usertags: dpkg-db-access-blocker
> > 
> > > > > This package contains the «popularity-contest» program, which directly
> > > > > accesses the dpkg internal database, instead of using one of the 
> > > > > public
> > > > > interfaces provided by dpkg.
> > > > > 
> > > > > The program should stop reading the files list files, and switched to
> > > > > use something like:
> > > > > 
> > > > >   «dpkg-query \
> > > > > --showformat 'Package: ${Package}\nFiles:\n${db-fsys:Files}\n' \
> > > > > --show»
> > > > > 
> > > > > to get them.
> > 
> > > > the last time this comes up the performance of using dpkg-query was 
> > > > poor. 
> > > > Was it improved ? What is the first release to support this syntax ?
> > 
> > Just to clarify, the command above, does not need packages specified,
> > it will dump contents for the entire database.
> 
> ...which is a problem because then it requires much more memory to proceed 
> than the
> current popcon.
> 
> So last time the solution was to do a separate dpkg-query for each packages,
> but this was much slower.
> 
> Cheers,
> -- 
> Bill. 
> 
> Imagine a large red swirl here. 
> 
> 

Hi,

While it would take a bit of restructuring / refactoring, I think it
would be possible to use a single dpkg-query for everything and still be
able to process the data in a "streaming" fashion.

As an example, using the following:

  dpkg-query --show \
--showformat='${status} ${package}\n${db-fsys:Files}\n\n'

Will give you a format of:

"""
install ok installed 0ad
 /.
 /usr
 /usr/games
 /usr/games/0ad
 /usr/games/pyrogenesis
 /usr/lib
 [...]
 /usr/share/pixmaps
 /usr/share/pixmaps/0ad.png
 /usr/share/man/man6/pyrogenesis.6.gz


install ok installed 0ad-data
 /.
 /usr
 /usr/share
 [...]
 /usr/share/games/0ad/mods/public
 /usr/share/games/0ad/mods/public/public.zip


install ok installed 0ad-data-common
 /.
 /usr
 /usr/share
 /usr/share/doc
 /usr/share/doc/0ad-data-common
 /usr/share/doc/0ad-data-common/changelog.Debian.gz
 /usr/share/doc/0ad-data-common/copyright
 /usr/share/games
 [...]

[...]
"""

This should be reasonably doable to parse in a streaming fashion without
having to keep all the file paths in memory.  The performance for this
dpkg-query command is comparable with the previous timings I showed.


Thanks,
~Niels

Bug#935852: SOLVED

[Andrea Villa]

Through a lengthy I finally found this:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1654448

Which hinted to the fact that "Heaphone Mic Boost" is to blame for this.
Issuing:

$ amixer -c 0 set 'Headphone Mic Boost',0 1

makes the problem totally disappear for me. But why it depends on which
kernel has being booted?

Hope this helps somebody out there; I found this problem very obnoxious.

Bug#710477:

[Damyan Ivanov]

-=| Chris Denley, 28.11.2019 08:02:52 -0600 |=-
> client_ip and remote_ip do not work. Is there no way to get this value 
> anymore?
> 
> Can't locate object method "remote_ip" via package "Apache2::Connection"
> Can't locate object method "client_ip" via package "Apache2::Connection"
> Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 mod_apreq2-20090110/2.8.0 mod_perl/2.0.10
> Perl/v5.26.1

the following works for me:

my $conn = $r->connection;

my $ip_addr
= $conn->can('client_ip')
? $conn->client_ip
: $conn->remote_ip;

so one of them works, and I bet it is 'client_ip'

(Debian/sid and Debian/buster (and several releases before that))

Can you share the code that fails for you?

-- Damyan

Bug#945602: wrong path for constants.xml/presets.xml prevent the program from starting

[nodiscc]

Thqnk you, is there any chance for this fix to land in Debian stable?
Or do we have to wait for the next release (i believe it will be
available in stable due to the high severity)

Thanks again

Le jeu. 28 nov. 2019 à 09:52, Gürkan Myczko  a écrit :
>
> Hi,
>
> I can confirm this is really broken, however it was working for me for
> whatever reason,
> or how else did I create the
> https://screenshots.debian.net/package/qwinff screenshot?
>
> Anyways, a fixed version is on it's way:
> http://phd-sid.ethz.ch/debian/qwinff/
>
> Best,

Bug#945793: RM: gif2png -- ROM; Affected by Python 2 Removal

[Erik Schanze]

Hi all,


I'm fine with removal.

Thank you, Boyuan, for step in.


Bye,

Erik




signature.asc
Description: OpenPGP digital signature

Bug#931695: libgit-raw-perl: FTBFS with libgit2 0.28

[gregor herrmann]

On Thu, 28 Nov 2019 18:02:20 +, Peter Green wrote:

> On 28/11/2019 16:19, gregor herrmann wrote:
> > > A debdiff should appear soon at 
> > > https://debdiffs.raspbian.org/main/libg/libgit-raw-perl
> > … this is still a 404 (and the pool/ directory also still has the old
> > version)
> Apologies, it appears that rust built-using generation does not
> like binnmus and this has snarled up our update process. I am
> working on un-snarling it now and the debdiff will be generated
> when it is unsnarled.

No worries, and good luck in fixing the build infrastructure.

> > As I don't see any obvious problems with the clean target (I can also
> > build twice in a row), could you send your fix to the BTS please?
> 
> override_dh_auto_clean:
>     dh_auto_clean
>     rm -f t/merge_repo/test1

I see, thank you.
 
> It would not surprise me if said file is only left behind after the
> build fails with a testsuite failure, and not after a successful
> build.

Right, that makes sense.

*quick grep*

== t/15-merge.t ==

my $path = rel2abs(catfile('t', 'merge_repo'));
make_path($path);

…

rmtree $path; 


So yeah, t/merge_repo is removed in the test which failed
before the patch.
Hm, I guess if the build fails with a failing test we are not very
worried about a stray subdirectory in t/ :)


Ok, I uploaded -7 earlier tonight, so unless new problems emerge
you should be able to sync it from Debian/bullseye in a couple of
days.


Thanks again,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Bjørn Berge: Heartbreaker


signature.asc
Description: Digital Signature

Bug#945796: rust-url-serde: (build-)depends on obsolete virtual package.

[peter green]

Package: rust-url-serde
Version: 0.2.0-1
Severity: serious
Tags: bullseye, sid

librust-url-serde-dev depends on and rust-url-serde build-depends on 
librust-url-1+default-dev which is no longer provided by rust-url. It seems to 
have been replaced by librust-url-2+default-dev

Bug#945795: [signing-party] gpg-key2ps prints ed25519 key as eddsa256 key

[Mikaela Suomalainen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: signing-party
Version: 2.10-2
Severity: normal

- --- Please enter the report below this line. ---

Dear maintainer,

I wish to report that when I use gpg-key2ps with my main GPG key,
`gpg-key2ps 69FF455A869F9031A691E0F199392F62BAE30723 >
69FF455A869F9031A691E0F199392F62BAE30723.ps`, my key is printed as
eddsa256/BAE30723, while I believe it should be ed25519 as reported by
`gpg --list-keys`.

I think this issue may be only cosmetic as the key fingerprint is
still correct.

You can easily generate an ed25519 key by `gpg --quick-gen-key
address@domain.example future-default`.

- --- System information. ---
Architecture: Kernel:   Linux 5.3.0-2-amd64

Debian Release: bullseye/sid
  990 testing vwakviie2ienjx6t.onion   990 testing
sdscoq7snqtznauu.onion   990 testing deb.torproject.org   990
testing deb.debian.org   900 testing-debug
ktqxbqrhg5ai2c7f.onion   900 testing-debug   deb.debian.org   500
trusty  brave-browser-apt-release.s3.brave.com   500 syncthing
  apt.syncthing.net   500 stable  linux.teamviewer.com
500 stable  dl.google.com   500 buster
download.docker.com
- --- Package information. ---
Depends(Version) | Installed
-+-===
perl:any | python3:any
  | libc6  (>= 2.14) | libmd0
   (>= 0.0.0) | gnupg
   | libclass-methodmaker-perl|
libgnupg-interface-perl  | libmailtools-perl
  | libmime-tools-perl   |
libnet-idn-encode-perl   | libterm-readkey-perl
  | libtext-template-perl| qprint
  |

Recommends(Version) | Installed
===-+-===
default-mta |  OR mail-transport-agent
| dialog  | 1.3-20190808-1
 OR whiptail| 0.52.21-3+b1
libgd-gd2-noxpm-perl|  OR libgd-gd2-perl
| libpaper-utils  | 1.1.28+b1


Suggests   (Version) | Installed
-+-===
fonts-noto-cjk   | fonts-noto-mono
  | 20181227-1
imagemagick  | 8:6.9.10.23+dfsg-2.1+
b2
 OR graphicsmagick-imagemagick-compat| mutt
  |  OR neomutt
   | qrencode |
texlive-font-utils   | texlive-latex-extra
 | texlive-latex-recommended
  | texlive-xetex| wipe
  |

- -- 
Mikaela Suomalainen
https://mikaela.info/
69FF 455A 869F 9031 A691  E0F1 9939 2F62 BAE3 0723

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQRp/0Vahp+QMaaR4PGZOS9iuuMHIwUCXeAnBgAKCRCZOS9iuuMH
I9FkAQCmGgffTI+XB9MAV3c/iVZY11xT5DndWDA4FsZSrFO1ywEArVxjsAiAWJBS
7AegpUph2CUt0r01VZyMJDQTSUx2IAU=
=AMFZ
-END PGP SIGNATURE-

Bug#799358: Angband 4.2.x is out and is Free

[Matthew Vernon]

Hi,

Any chance of a 4.2 package, please? It's quite a major rewrite of the 
game, and it's DFSG-free, so could move this into main, which would be 
really good :)


Thanks,

Matthew

Bug#945780: I think we can close this

[Frank McCormick]

Sorry sent from the wrong address.

For some unknown reasons, it seems to be running fine now. Perhaps the 
reboot after the new X, or another pebkac.


I would close it but I don't know how.

Sorry for the noise.

Bug#945794: ITS: mawk

[Boyuan Yang]

Package: mawk
Severity: important
Version: 1.3.3-17
X-Debbugs-CC: vor...@debian.org

Dear mawk maintainer,

After looking into the package you maintain (mawk, 
https://tracker.debian.org/pkg/mawk), I found that this package received no
updates since 2012 and is not in good shape. As a result, I am filing an ITS
(Intent to Salvage) request against your package according to section 5.12 in 
Debian's Developers' Reference [1].

Please let me know if you are still willing to maintain this package.
According to the criteria listed at [2], I will upload a Non-maintainer Upload
(NMU) of mawk onto DELAYED/7 after 21 days (Dec. 20, 2019) to continue with
the package salvaging. If it's necessary to pause the ITS process, please let
me know immediately by replying this bug report.

Thank you for your previous work in Debian and looking forward to your reply.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Best Regards,
Boyuan Yang


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

Bug#945780: I think we can close this

[Frank McCormick]

For some unknown reasons, it seems to be running fine now. Perhaps the 
reboot after the new X, or another pebkac.


I would close it but I don't know how.

Sorry for the noise.

Bug#945793: RM: gif2png -- ROM; Affected by Python 2 Removal

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: er...@debian.org

As requested by the package maintainer in https://bugs.debian.org/930858 , the
maintainer requested to orphan the package or get it removed. Since no one has
taken the step to package gif2png 3.x (which is golang-written) and that this
package is currently affected by Python 2 removal, I am sending the removal
request.

Erik: If you have some other thoughts, please let me know now.

Thanks,
Boyuan Yang


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

Bug#937300: plaso: Python2 removal in sid/bullseye

[Sandro Tosi]

rescheduled to now as 937300 became RC

On Fri, Nov 22, 2019 at 5:35 PM Sandro Tosi  wrote:
>
> I've opened https://salsa.debian.org/pkg-security-team/plaso/merge_requests/1
> and uploaded the same change sto DELAYED-7
>
> On Fri, Nov 22, 2019 at 2:28 PM Moritz Mühlenhoff  wrote:
> >
> > On Wed, Nov 13, 2019 at 04:26:52PM -0500, Sandro Tosi wrote:
> > > Hi Hilko,
> > >
> > > On Fri, 30 Aug 2019 07:31:12 + Matthias Klose  wrote:
> > > > Package: src:plaso
> > > > Version: 20190131-1
> > > > Severity: normal
> > > > Tags: sid bullseye
> > > > User: debian-pyt...@lists.debian.org
> > > > Usertags: py2removal
> > >
> > > can you just go ahead and remove py2 support here? thanks!
> >
> > And please also drop python-hachoir-core, python-hachoir-metadata and
> > python-hachoir-parser from build deps. They're only used in the Py2
> > package and blocking the removal of python-qt4 (and transitively
> > Qt4).
> >
> > Cheers,
> > Moritz
>
>
>
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi



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

Bug#945792: RM: fpconst -- RoM; obsolete; no Python 3 support and no reverse deps

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

The only release was in 2005. https://www.python.org/dev/peps/pep-0754/
was abouyt including it into stdlib and it failed.

The only revdep, jack-mixer, was recently removed from the archive.

Popcon 17k, much higher than jack-mixer had, but it was 110k in 2014 so I
suspect it's just an old dep of some long gone or updated package.


Reverse deps checked with dak rm -Rnb python-fpconst

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#936877: [Pkg-gtkpod-devel] Bug#936902: Bug#936902: libplist: Python2 removal in sid/bullseye

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2019-09-22 at 11:04 +0200, Yves-Alexis Perez wrote:
> Obviously there might be people using python-plist and python-imobiledevice
> directly in python scripts and they'll have to migrate them to python3,
> which
> is not perfect, but I don't have other ideas for now.
> 
> I'll try to update the whole istuff stack at once in the following
> days/weeks.

Package with (hopefully) python3 support are currently sitting in NEW, so this
is in the hand of the ftpmasters.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3gF40ACgkQ3rYcyPpX
RFuvXAgAuwC/9meDd+Wxq6c+Pfn6BsA0ppqctdODrg2oC2tzrRy6SERmud3QJFZy
UmmbsRuUFTfq9NXJzNuTFolWRwdKW95G2V/oKtRCWXA0td7JMkGFe13gJMVMa9D/
RmyLq/nb4lxcwS5tFuJpCufnksyH+2HR38PANWsMhOwqXM1tCHrvL1x2i/IrMVfA
08MyZYuar31Wi9+CI+O9RPFejq2goiSVsXq2+ThV3WdDJ4wSAEIdQmfHCk94RbNf
Qyu2xmbX2MWefJRvc8aqcYoUrmiod9qQ0iOW0eB+0ThT+dU9qeam7UcIgwdpsQlu
wmsWXdk/bFpws0VwlI1CudYtOFFEqw==
=wQFE
-END PGP SIGNATURE-

Bug#945791: libopenblas0-openmp: undefined symbol: GOMP_parallel

[Jörg-Volker Peetz]

Package: libopenblas0-openmp
Version: 0.3.7+ds-4
Severity: serious

Dear Debian Science Team,

when trying to exchange libopenblas0-openmp for libopenblas0-pthread,
I get the following error from a self compiled program:

  /usr/lib/x86_64-linux-gnu/libblas.so.3: undefined symbol:  GOMP_parallel

The library is actually /usr/lib/x86_64-linux-gnu/openblas-openmp/libblas.so.3.
Although this package depends on libgomp1, it seems to me that the
library /usr/lib/x86_64-linux-gnu/openblas-openmp/libblas.so.3 is not
linked against /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0:

$ ldd /usr/lib/x86_64-linux-gnu/openblas-openmp/libblas.so.3
linux-vdso.so.1 (0x7ffccf5e5000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f671fe5d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f671fe3c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f671fc7c000)
/lib64/ld-linux-x86-64.so.2 (0x7f6721a27000)

Any idea?

Regards,
Jörg.


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

Kernel: Linux 5.3.11 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libopenblas0-openmp depends on:
ii  libc6 2.29-1
ii  libgfortran5  9.2.1-19
ii  libgomp1  9.2.1-19

libopenblas0-openmp recommends no packages.

libopenblas0-openmp suggests no packages.

-- no debconf information

Bug#945480: [PATCH 0/1] Drop remaining usage of python2

[Lars Wirzenius]

On Thu, 2019-11-28 at 10:40 -0600, Gunnar Wolf wrote:
> Lars Wirzenius dijo [Thu, Nov 28, 2019 at 11:27:54AM +0200]:
> > Thanks, I've applied the changes and pushed them to git.liw.fi and
> > gitlab.
> 
> Thanks for your prompt attention, Lars!
> 
> I am about to board a plane, but will try to work on this bug later
> today. Lars, do you want to tag a release? Or should I do again the
> "+git20191128" way?

If you could do the +git... thing this time, I'd appreciate it.

Safe travels.


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

Bug#945790: libshiboken2-dev: SHIBOKEN_PYTHON_MODULE_DIR contains wrong path causing a cmake find error

[Linus Jahn]

Package: libshiboken2-dev
Version: 5.13.2-2
Severity: normal

Dear Maintainer,

when I try to find Shiboken2 with cmake I get the following error:

CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/Shiboken2-5.13.2/Shiboken2Config.cpython-37m-x86_64-linux-gnu.cmake:14
 (message):
  File or directory /usr/lib/lib/python3.7/site-packages/shiboken2 referenced
  by variable SHIBOKEN_PYTHON_MODULE_DIR does not exist !
Call Stack (most recent call first):
  
/usr/lib/x86_64-linux-gnu/cmake/Shiboken2-5.13.2/Shiboken2Config.cpython-37m-x86_64-linux-gnu.cmake:62
 (set_and_check)
  /usr/lib/x86_64-linux-gnu/cmake/Shiboken2-5.13.2/Shiboken2Config.cmake:5 
(include)
  py/CMakeLists.txt:118 (find_package)


-- Configuring incomplete, errors occurred!

The path for SHIBOKEN_PYTHON_MODULE_DIR is invalid 
(/usr/lib/lib/python3.7/site-packages/shiboken2).


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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 libshiboken2-dev depends on:
ii  libshiboken2-py3-5.13  5.13.2-2
ii  python3-dev3.7.5-3

libshiboken2-dev recommends no packages.

libshiboken2-dev suggests no packages.

-- no debconf information

Bug#945195: [PATCH v2 1/7] email-print-mime-structure: decrypt PGP/MIME parts as bytes

[Sean Whitton]

control: tag -1 +pending

Hello,

On Thu 28 Nov 2019 at 01:00AM -05, Daniel Kahn Gillmor wrote:

> Hm, this is actually *not quite* "no functional change".
>
> In particular, it means we're passing around a bytestream version of the
> inner part, not the potentially-encoded (base64 or quoted-printable)
> string-like variant.
>
> This actually will have an impact on how we handle some messages -- it's
> not just a code reorganization.  for example, if someone were to make an
> OpenPGP encrypted message, and they didn't ASCII-armor the encrypted
> part, but rather attached it as a binary blob, then their MUA would
> probably wrap it in a Content-Transfer-Encoding: base64.
>
> If we then passed the un-decoded blob to an OpenPGP decryptor, it
> wouldn't have the OpenPGP armor header, and it wouldn't have the right
> bytestream to mark it as a "raw" OpenPGP packet.  so the decryptor
> wouldn't be able to handle it.
>
> In practice, all the encrypted messages that i've found to throw at
> email-print-mime-structure thus far have had OpenPGP-specific
> ASCII-Armoring already, and thus haven't needed to be decoded, and for
> *those* messages, there is no functional change needed.
>
> But that won't be the case for the PKCS7 (S/MIME) objects we encounter
> later in the series, so it's nice to also make this more robust for
> PGP/MIME messages as well.
>
> Hope this makes sense,

It does, thank you.  Adding a link to your e-mail to the changelog.

-- 
Sean Whitton

Bug#933878: tesseract: training files are split across libtesseract-dev and tesseract-ocr

[Stefan Weil]

On Sun, 04 Aug 2019 18:49:24 +0100 Julian Gilbey  wrote:
[...]
> At the same time, the training binaries are in tesseract-ocr, such as
> classifier_tester, lstmtraining and so on. Would it not make more
> sense to have *only* /usr/bin/tesseract in tesseract-ocr, and all of
> the other binaries, along with the shell scripts noted above, in a
> separate package called something like tesseract-training?

Hi Julian,

it makes sense to put the executables which are required for training
into an extra package - not for 4.x because that would break existing
installations, but for 5.x.

The training shell scripts are less relevant and might be replaced
in the future by the already existing Python scripts.

In addition, more and more people run Tesseract training without
that scripts. Instead of those scripts, they use the Makefile
provided by https://github.com/tesseract-ocr/tesstrain/.

Regards,
Stefan

Bug#931695: libgit-raw-perl: FTBFS with libgit2 0.28

[Peter Green]

On 28/11/2019 16:19, gregor herrmann wrote:

A debdiff should appear soon at 
https://debdiffs.raspbian.org/main/libg/libgit-raw-perl

… this is still a 404 (and the pool/ directory also still has the old
version)

Apologies, it appears that rust built-using generation does not like binnmus 
and this has snarled up our update process. I am working on un-snarling it now 
and the debdiff will be generated when it is unsnarled.
  
As I don't see any obvious problems with the clean target (I can also

build twice in a row), could you send your fix to the BTS please?


override_dh_auto_clean:
    dh_auto_clean
    rm -f t/merge_repo/test1

It would not surprise me if said file is only left behind after the build fails 
with a testsuite failure, and not after a successful build.

Bug#940475: /usr/sbin/libvirtd: libvirtd fail to start with "internal error: Some activation file descriptors are unclaimed"

[Tomas Janousek]

Hi,

On Mon, Oct 07, 2019 at 02:40:17PM +0200, Mirko wrote:
> The problem seems related to systemd starting.
> 
> I have tried to find a solutions by myself but without success.

In my case, this helped:

1. set unix_sock_dir = "/run/libvirt" in /etc/libvirt/libvirtd.conf
2. systemctl stop libvirtd-admin.socket libvirtd-ro.socket libvirtd-tcp.socket 
libvirtd-tls.socket libvirtd.socket virtlockd-admin.socket virtlockd.socket 
virtlogd-admin.socket virtlogd.socket libvirtd.service
3. systemctl start libvirtd.service

"service libvirtd start" still doesn't work.

(Additionally, one must be extra careful to manually stop all libvirt networks
and restart firewalld before attempting to restart libvirtd, otherwise it will
refuse to start the network afterwards, but that's a separate regression.)

Seems to me that the "[4dcbe93] Revert "Disable libvirtd socket activation"
(Closes: #935883)" entry in changelog is what broke this.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935883#8 claims that socket
activation actually works fine, but it does not, and the Revert should
probably be Reverted again.

-- 
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/

Bug#945789: ITP: ruby-elasticsearch-model -- ActiveModel/Record integrations for Elasticsearch

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: ruby-elasticsearch-model
  Version : 7.0.0
  Upstream Author : Karel Minarik
* URL : https://github.com/elasticsearch/elasticsearch-rails/
* License : Apache-2
  Description : ActiveModel/Record integrations for Elasticsearch.
 The elasticsearch-model library builds on top of the elasticsearch 
library. It
 aims to simplify integration of Ruby classes ("models"), commonly 
found e.g.

 in Ruby on Rails applications, with the Elasticsearch search and analytics
 engine.

Bug#945768: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')

[Ondrej Novy]

Hi,

čt 28. 11. 2019 v 17:11 odesílatel Andreas Tille  napsal:

> Hmmm, what are the chances to get this applied?  I've added
>

tbh dunno :)


> in Git - but this will not reall fix the test.  The only solution I'd see
> otherwise is to deactivate the test.
>

you have two options:
1. deactivate the test (remove Testsuite: autopkgtest-pkg-python from
d/control)
2. call `autodep8 >debian/tests/control` and edit result

-- 
Best regards
 Ondřej Nový

Bug#945788: lightdm: Language support is broken

[Santiago Castillo Oli]

Package: lightdm
Version: 1.26.0-4
Severity: important
Tags: l10n

Dear Maintainer,

I would like to use the language selector of lightdm but I found that it 
doesn't work.


I see there are several bug reports about this (864154, 784065, 765077, 
690899, 691446), but they are only addressing small parts of the problem 
and those bugs doesn't have a proper solution.


So i will try to offer a more general view of the problem.


- First of all, chosen language at lightdm greeter is overridden if LANG 
is defined in /etc/default/locale. This is because /etc/pam.d/lightdm 
contains:


session  required pam_env.so readenv=1 envfile=/etc/default/locale

No matter what Language you choose in lightdm selector. You'll have 
system wide LANG setting.


So first step for language selector to work is to comment the above line.



- After commenting the above line, you can choose language with lightdm 
greeter at login time, but it won't work with that session. It will work 
the next session.


Let me explain it with an example:

Before login, according to /home/user/.dmrc, 
/var/lib/AccountsService/users/user and /var/cache/lightdm/user.dmrc you 
have Language=de_DE.utf8 (German)


In lightdm greeter login you choose "fr_FR.utf8" (French), enter login 
name and password, and a plasma (in my case) session with German 
language will start.


/home/user/.dmrc, /var/lib/AccountsService/users/user and 
/var/cache/lightdm/user.dmrc files are updated to fr_FR.utf8 but that 
first session have the previous language settings.


The next time you start a session from lightdm the language will be 
French, no matter what you choose at language selector.


The language selector doesn't set the language for the very next login 
but  the "next login after this login".


In other words, the language of the session will be the one we chose the 
previous login, not what we have choose this login.




- There is a third problem with language selector. If accountsservice is 
installed, files in /var/lib/AccountsService/users/ are read and 
written, this is correct. But, If accountsservice is uninstalled, and 
there are files in /var/lib/AccountsService/users/, those files are 
still read, and this is wrong.


If, lets say, a user with accountservice installed choose one language 
at lightdm greeter, that settings is save in a file in 
/var/lib/AccountsService/users/. Then, if the user uninstall 
accountsservice but don't delete the file at 
/var/lib/AccountsService/users he will always use the Language defined 
there, no matter what he choose at language selector. Lightdm will read 
that file, that won't be updated to newer choices of language because 
accountsservice is no longer running.




could this be fixed, please?

Thank you very much.



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

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_ES.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lightdm depends on:
ii  adduser    3.118
ii  dbus   1.12.16-1
ii  debconf [debconf-2.0]  1.5.71
ii  libaudit1  1:2.8.4-3
ii  libc6  2.28-10
ii  libgcrypt20    1.8.4-5
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libpam-systemd [logind]    241-7~deb10u2
ii  libpam0g   1.3.1-5
ii  libxcb1    1.13.1-2
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.6-1
ii  lsb-base   10.2019051400

Versions of packages lightdm recommends:

ii  xserver-xorg  1:7.7+19

Versions of packages lightdm suggests:
pn  accountsservice  
ii  upower   0.99.10-1
pn  xserver-xephyr   

-- Configuration Files:
/etc/pam.d/lightdm changed [not included]

-- debconf information:
  lightdm/daemon_name: /usr/sbin/lightdm
* shared/default-x-display-manager: lightdm



--

Santiago Castillo Oliscasti...@aragon.es
Técnico de Sistemas Informáticos976 71 50 06
Biblioteca de Aragón
Doctor Cerrada 22, 50005 Zaragoza

Bug#942022: librsvg: FTBFS on ppc64el: assertion failed: bounds.x1 >= bounds.x0

[Olivier Tilloy]

Philip Chimento started preparing the 2.46 update and I continued the
work, this is now ready for review and sponsoring:
https://salsa.debian.org/gnome-team/librsvg/merge_requests/5

Bug#933538: Proposed fix for stable

[Hanno Stock]

Patch applies to version in stable.

See attached debdiff.

I have built the package in a buster chroot and installed on a buster
system where I previously encountered the bug.

This patch fixes the bug and otherwise SSL connections still seem to
work fine.

diff -Nru gnutls28-3.6.7/debian/changelog gnutls28-3.6.7/debian/changelog
--- gnutls28-3.6.7/debian/changelog 2019-06-12 19:21:23.0 +0200
+++ gnutls28-3.6.7/debian/changelog 2019-11-28 17:03:35.0 +0100
@@ -1,3 +1,13 @@
+gnutls28 (3.6.7-4+deb10u1~1.gbp7c6fcb) UNRELEASED; urgency=medium
+
+  ** SNAPSHOT build @7c6fcba7e7c4e5cfe6f7aa145ec8598876b7db97 **
+
+  * UNRELEASED
+  * 40_rel3.6.10_01-gnutls_epoch_set_keys-do-not-forbid-random-padding.patch
+from upstream GIT master: Fix interop problems with gnutls 2.x. Closes: 
#933538
+
+ -- Hanno Stock   Thu, 28 Nov 2019 17:03:35 +0100
+
 gnutls28 (3.6.7-4) unstable; urgency=medium
 
   * Cherry-pick important bug-fixes from 3.6.8:
diff -Nru 
gnutls28-3.6.7/debian/patches/40_rel3.6.10_01-gnutls_epoch_set_keys-do-not-forbid-random-padding.patch
 
gnutls28-3.6.7/debian/patches/40_rel3.6.10_01-gnutls_epoch_set_keys-do-not-forbid-random-padding.patch
--- 
gnutls28-3.6.7/debian/patches/40_rel3.6.10_01-gnutls_epoch_set_keys-do-not-forbid-random-padding.patch
  1970-01-01 01:00:00.0 +0100
+++ 
gnutls28-3.6.7/debian/patches/40_rel3.6.10_01-gnutls_epoch_set_keys-do-not-forbid-random-padding.patch
  2019-11-28 16:54:28.0 +0100
@@ -0,0 +1,63 @@
+From daa49b9e455d262a1a2bc1b641e72dc004e2cb3e Mon Sep 17 00:00:00 2001
+From: Nikos Mavrogiannopoulos 
+Date: Sat, 3 Aug 2019 21:51:58 +0200
+Subject: [PATCH] _gnutls_epoch_set_keys: do not forbid random padding in
+ TLS1.x CBC ciphersuites
+
+Since some point in 3.6.x we updated the calculation of maximum record size,
+however that did not include the possibility of random record padding available
+for CBC ciphersuites which exceeds the maximum. This commit allows for larger
+sizes for these ciphersuites to account for random padding as applied by
+gnutls 2.12.x.
+
+Resolves: #811
+
+Signed-off-by: Nikos Mavrogiannopoulos 
+---
+ NEWS   |  4 
+ lib/constate.c | 11 +--
+ lib/record.c   |  4 ++--
+ 3 files changed, 15 insertions(+), 4 deletions(-)
+
+diff --git a/lib/constate.c b/lib/constate.c
+index 51a4eca30..4c6ca0fd0 100644
+--- a/lib/constate.c
 b/lib/constate.c
+@@ -707,10 +707,17 @@ int _gnutls_epoch_set_keys(gnutls_session_t session, 
uint16_t epoch, hs_stage_t
+   return gnutls_assert_val(ret);
+   }
+ 
+-  if (ver->tls13_sem) {
++  /* The TLS1.3 limit of 256 additional bytes is also enforced under CBC
++   * ciphers to ensure we interoperate with gnutls 2.12.x which could add 
padding
++   * data exceeding the maximum. */
++  if (ver->tls13_sem || _gnutls_cipher_type(params->cipher) == 
CIPHER_BLOCK) {
+   session->internals.max_recv_size = 256;
+   } else {
+-  session->internals.max_recv_size = _gnutls_record_overhead(ver, 
params->cipher, params->mac, 1);
++  session->internals.max_recv_size = 0;
++  }
++
++  if (!ver->tls13_sem) {
++  session->internals.max_recv_size += 
_gnutls_record_overhead(ver, params->cipher, params->mac, 1);
+   if (session->internals.allow_large_records != 0)
+   session->internals.max_recv_size += EXTRA_COMP_SIZE;
+   }
+diff --git a/lib/record.c b/lib/record.c
+index 39d2a16be..7c7e36561 100644
+--- a/lib/record.c
 b/lib/record.c
+@@ -1219,8 +1219,8 @@ static int recv_headers(gnutls_session_t session,
+ 
+   if (record->length == 0 || record->length > 
max_record_recv_size(session)) {
+   _gnutls_audit_log
+-  (session, "Received packet with illegal length: %u\n",
+-   (unsigned int) record->length);
++  (session, "Received packet with illegal length: %u (max: 
%u)\n",
++   (unsigned int) record->length, 
(unsigned)max_record_recv_size(session));
+ 
+   if (record->length == 0) {
+   /* Empty, unencrypted records are always unexpected. */
+-- 
+2.23.0
+
diff -Nru gnutls28-3.6.7/debian/patches/series 
gnutls28-3.6.7/debian/patches/series
--- gnutls28-3.6.7/debian/patches/series2019-06-12 19:21:15.0 
+0200
+++ gnutls28-3.6.7/debian/patches/series2019-11-28 16:56:31.0 
+0100
@@ -5,3 +5,4 @@
 40_rel3.6.8_10-ext-record_size_limit-distinguish-sending-and-receiv.patch
 40_rel3.6.8_15-Apply-STD3-ASCII-rules-in-gnutls_idna_map.patch
 40_rel3.6.8_20-pubkey-remove-deprecated-TLS1_RSA-flag-check.patch
+40_rel3.6.10_01-gnutls_epoch_set_keys-do-not-forbid-random-padding.patch


signature.asc
Description: OpenPGP digital signature

Bug#939260: websploit: Python2 removal in sid/bullseye

[Raphael Hertzog]

Control: forwarded -1 https://github.com/websploit/websploit/issues/24

On Mon, 02 Sep 2019, Stefano Rivera wrote:
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

I have forwarded this request to the upstream developer through
the above issue and I'm putting him in copy too because I haven't
seen any recent activity from him, neither on GitHub nor on Sourceforge.

Fardin, do you have plans to update websploit to Python 3?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#945763: gcc-9 ftbfs on mipsel

[YunQiang Su]

Matthias Klose  于2019年11月28日周四 下午5:51写道：
>
> On 28.11.19 10:44, Matthias Klose wrote:
> > Package: src:gcc-9
> > Version: 9.2.1-20
> > Severity: serious
> > Tags: sid bullseye
> >
> > gcc-9 ftbfs on mipsel with a bootstrap comparison failure, most likely 
> > triggered
> > by the LTO build enabled in -20.
> >
> > bootstrap comparison failure!
> > libbacktrace/elf.o differs
> > libbacktrace/.libs/elf.o differs
> > make[4]: *** [Makefile:24878: compare] Error 1
>
> Please could you have a look?

sure. I will look at it tomorrow

>


-- 
YunQiang Su

Bug#813487: pgbouncer: Upgrading pgbouncer drops connections when run with systemd

[Christoph Berg]

Control: tags -1 upstream

Re: Chris Butler 2016-02-02 
<20160202131415.28076.48745.report...@taskrunner.staging.trac.jobs>
> In the good old sysvinit days, an upgrade to pgbouncer could be done 
> seamlessly
> because the init script used the -R flag to tell pgbouncer to take over from 
> the
> existing daemon. However, it seems like this doesn't happen when using 
> systemd.
> 
> Is there any way to bring back zero connection loss upgrades under systemd?

Hi,

I always meant to bring back this behavior with the systemd service
file, but after chatting about this with one of the upstream authors,
Peter Eisentraut, at the last PGconf.EU, we figured that it's
unfortunately unfixable. The problem is that pgbouncer spawns a new
process, transfers the open file descriptors, and exits. Systemd
doesn't like that the original process goes away.

Not sure if there's a way around that, certainly not with TLS
connections (but that doesn't work without systemd either). Possibly
moving the connections to a helper process first, and then exec()ing
to the new version, and moving the connections back to the original
PID would work.

Peter?

Christoph

Bug#945480: [PATCH 0/1] Drop remaining usage of python2

[Gunnar Wolf]

Lars Wirzenius dijo [Thu, Nov 28, 2019 at 11:27:54AM +0200]:
> Thanks, I've applied the changes and pushed them to git.liw.fi and
> gitlab.

Thanks for your prompt attention, Lars!

I am about to board a plane, but will try to work on this bug later
today. Lars, do you want to tag a release? Or should I do again the
"+git20191128" way?

Greetings,


signature.asc
Description: PGP signature

Bug#944847: rpki-trust-anchors: [INTL:de] Initial German debconf translation

[Chris Leick]

Hi Marco,

you can delete it.

Kind regards,
Chris


Am 28.11.19 um 16:49 schrieb Marco d'Itri:

Any comments?

On Nov 23, Marco d'Itri  wrote:


On Nov 16, Chris Leick  wrote:


please find attached the newest German translation. I've marked a typo

What is this line about?

# Copyright (C) 2010-2016 Hadley Wickham .

--
ciao,
Marco

Bug#945787: haskell-haddock-library: package description references non-existent "haddock" package

[Jonathan Dowland]

Source: haskell-haddock-library
Version: 1.5.0.1-2+b1
Severity: minor
Tags: newcomer

As per subject:

>   Description: library exposing some functionality of Haddock
>Haddock is a documentation-generation tool for Haskell
>libraries. These modules expose some functionality of it
>without pulling in the GHC dependency.
>.
>For interacting with Haddock itself, see the ‘haddock’ package.
   ^^^

The haddock package was removed in 2010.

Bug#942032: openjazz: please provide a launcher for Jazz Jackrabbit Holiday Hare '95

[Fabian Greffrath]

Am Mittwoch, den 27.11.2019, 10:35 +0100 schrieb Fabian Greffrath:
> if you could add this symlink to the openjazz executable to the g-d-p
> generated package, I will update the openjazz package with the
> required changes, i.e. the .desktop file.

Ah, whatever! I just made facts and uploaded a new openjazz package
with the requested desktop file. Now g-d-p has to follow suit. ;)

Cheers,

 - Fabian



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

Bug#945786: ITP: ruby-sixarm-ruby-unaccent -- replaces a string's accented characters with unaccented characters

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: ruby-sixarm-ruby-unaccent
  Version : 1.2.0
  Upstream Author : SixArm
* URL : https://github.com/SixArm/sixarm_ruby_unaccent
* License : Apache-2.0 or Artistic-2 or BSD-3-clause or GPL-3 or
Expat or MPL-2.0
  Description : replaces a string's accented characters with
unaccented characters
Replace a string's accent characters with ASCII characters. Based on
Perl Text::Unaccent from CPAN.




signature.asc
Description: PGP signature

Bug#931695: libgit-raw-perl: FTBFS with libgit2 0.28

[gregor herrmann]

On Thu, 28 Nov 2019 02:18:55 +, Peter Green wrote:

> Some poking around revealed that upstream fixed this by removing
> the last (NULL) parameter from the call. This was done in a commit
> titled "minor fixes".
> https://github.com/jacquesg/p5-Git-Raw/commit/30f7a4491ab453d28ae1fa1b393fcd023f6c344d

Thanks!
I can confirm that the second hunk of the patch makes the package
build (module tests) in Debian/sid as well.
 
> . There was also another apparently unrelated change in the commit,
> which did not seem relavent to the version in Debian.

That's already there as debian/patches/fix-33-worktree.patch

> A couple of tests failed, but that could have just been my build
> environment, I decided this was good enough to disable the
> testsuite and upload to raspbian.

I also found fixes for the tests in the upstream git repo.
 
> While working on this I ran into an issue with the clean target not
> cleaning up properly, so I fixed that too.

That sounds interesting but
 
> A debdiff should appear soon at 
> https://debdiffs.raspbian.org/main/libg/libgit-raw-perl

… this is still a 404 (and the pool/ directory also still has the old
version)
 
As I don't see any obvious problems with the clean target (I can also
build twice in a row), could you send your fix to the BTS please?


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Carole King: Eventually


signature.asc
Description: Digital Signature

Bug#945768: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')

[Sandro Tosi]

On Thu, Nov 28, 2019 at 11:11 AM Andreas Tille  wrote:
>
> On Thu, Nov 28, 2019 at 04:18:07PM +0100, Ondrej Novy wrote:
> >
> > > Is there any trick to enable autopkgtest-pkg-python detecting the correct
> > > module name?
> > >
> >
> > no (not yet? See: https://salsa.debian.org/ci-team/autodep8/merge_requests/6
> > )
>
> Hmmm, what are the chances to get this applied?  I've added
>
>X-Python-Module-Name: pubsub
>
> in Git - but this will not reall fix the test.  The only solution I'd see
> otherwise is to deactivate the test.

if you install `pubsub` as top-level module, your package must be
named pythonN-pubsub, if not it violates the policy and it's RC buggy.
please rename the package.

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

Bug#945785: ITP: ruby-sixarm-ruby-unaccent -- replaces a string's accented characters with unaccented characters

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: ruby-sixarm-ruby-unaccent
  Version : 1.2.0
  Upstream Author : SixArm
* URL : https://github.com/SixArm/sixarm_ruby_unaccent
* License : Apache-2.0 or Artistic-2 or BSD-3-clause or GPL-3 or
Expat or MPL-2.0
  Description : replaces a string's accented characters with
unaccented characters
Replace a string's accent characters with ASCII characters. Based on
Perl Text::Unaccent from CPAN.



signature.asc
Description: OpenPGP digital signature

Bug#945768: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')

[Andreas Tille]

On Thu, Nov 28, 2019 at 04:18:07PM +0100, Ondrej Novy wrote:
> 
> > Is there any trick to enable autopkgtest-pkg-python detecting the correct
> > module name?
> >
> 
> no (not yet? See: https://salsa.debian.org/ci-team/autodep8/merge_requests/6
> )

Hmmm, what are the chances to get this applied?  I've added

   X-Python-Module-Name: pubsub

in Git - but this will not reall fix the test.  The only solution I'd see
otherwise is to deactivate the test.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#945197: libgrpc-dev,libgpr3-dev: both ship libgpr.a, libgpr.so

[Nicolas Boulenguez]

Hello.

I have contacted the upstream for gpbruild (AdaCore) months ago,
without answer for now.  Google (for grpc) will probably also have
more urgent concerns that avoiding a name clash with an unrelated
library.  I hope that the issue has been reported there too, so that
they avoid third-letter global identifiers in the future :-).

In Debian, libgpr has been introduced by:
  grpc on 2015-08-16
  gprbuild on 2016-08-11
Unless someone suggests a better fix, I intend to rename
gprbuild/libgpr to gprbuild/libgnatprj.

Bug#945784: [vino] fix libvncserver bundle security issues

[Mike Gabriel]

Package: vino
Version: 3.22.0-5
Tags: security upstream

Dear maintainers of vino,

last month, I have started working on a audit regarding  
libvncserver+libvncclient in Debian. Code portions from either of  
those libraries have been bundled in the Debian src:pkg "vino":


CVE-2019-15681[0]:
| LibVNC commit before d01e1bb4246323ba6fcee3b82ef1faa9b1dac82a contains
| a memory leak (CWE-655) in VNC server code, which allow an attacker to
| read stack memory and can be abused for information disclosure.
| Combined with another vulnerability, it can be used to leak stack
| memory and bypass ASLR. This attack appear to be exploitable via
| network connectivity. These vulnerabilities have been fixed in commit
| d01e1bb4246323ba6fcee3b82ef1faa9b1dac82a.

CVE-2018-7225
| An issue was discovered in LibVNCServer through 0.9.11.
| rfbProcessClientNormalMessage() in rfbserver.c does not
| sanitize msg.cct.length, leading to access to uninitialized and
| potentially sensitive data or possibly unspecified other impact
| (e.g., an integer overflow) via specially crafted VNC packets.

CVE-2014-6053
| The rfbProcessClientNormalMessage function in libvncserver/rfbserver.c
| in LibVNCServer 0.9.9 and earlier does not properly handle attempts to
| send a large amount of ClientCutText data, which allows remote attackers
| to cause a denial of service (memory consumption or daemon crash) via
| a crafted message that is processed by using a single unchecked malloc.

Find attached a .debdiff (targetting the vino version in  
testing/unstable) that resolves the above libvncserver related issues  
in vino.


With my LTS team member hat on, I will upload vino to jessie LTS  
within the next hours.


Please let me know, if you will also handle uploads to  
stretch-security and buster-security. Thanks.


Please note, that I have not runtime-tested the vino 3.22.0-5.1  
version, the .debdiff is a simple forward port of what I have been  
working on for Debian jessie LTS. Thanks.


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

diff -Nru vino-3.22.0/debian/changelog vino-3.22.0/debian/changelog
--- vino-3.22.0/debian/changelog2018-12-28 00:58:27.0 +0100
+++ vino-3.22.0/debian/changelog2019-11-28 16:37:03.0 +0100
@@ -1,3 +1,16 @@
+vino (3.22.0-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Porting of libvncserver security patches:
+- CVE-2014-6053: Check malloc() return value on client->server 
ClientCutText
+  message.
+- CVE-2018-7225: Uninitialized and potentially sensitive data could be
+  accessed by remote attackers because the msg.cct.length in rfbserver.c 
was
+  not sanitized.
+- CVE-2019-15681: rfbserver: don't leak stack memory to the remote.
+
+ -- Mike Gabriel   Thu, 28 Nov 2019 16:37:03 +0100
+
 vino (3.22.0-5) unstable; urgency=medium
 
   * Build-Depend on debhelper-compat 12 and drop debian/compat
diff -Nru vino-3.22.0/debian/patches/libvncserver_CVE-2014-6053.patch 
vino-3.22.0/debian/patches/libvncserver_CVE-2014-6053.patch
--- vino-3.22.0/debian/patches/libvncserver_CVE-2014-6053.patch 1970-01-01 
01:00:00.0 +0100
+++ vino-3.22.0/debian/patches/libvncserver_CVE-2014-6053.patch 2019-11-28 
15:57:25.0 +0100
@@ -0,0 +1,22 @@
+Description: Check malloc() return value (CVE-2014-6053)
+ Check malloc() return value on client->server ClientCutText
+ message. Client can send up to 2**32-1 bytes of text, and such a large
+ allocation is likely to fail in case of high memory pressure. This would in a
+ server crash (write at address 0).
+Origin: 
https://github.com/newsoft/libvncserver/commit/6037a9074d52b1963c97cb28ea1096c7c14cbf28
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/server/libvncserver/rfbserver.c
 b/server/libvncserver/rfbserver.c
+@@ -851,6 +851,11 @@
+   msg.cct.length = Swap32IfLE(msg.cct.length);
+ 
+   str = (char *)malloc(msg.cct.length);
++  if (str == NULL) {
++  rfbLogPerror("rfbProcessClientNormalMessage: not enough 
memory");
++  rfbCloseClient(cl);
++  return;
++  }
+ 
+   if ((n = ReadExact(cl, str, msg.cct.length)) <= 0) {
+   if (n != 0)
diff -Nru vino-3.22.0/debian/patches/libvncserver_CVE-2018-7225.patch 
vino-3.22.0/debian/patches/libvncserver_CVE-2018-7225.patch
--- vino-3.22.0/debian/patches/libvncserver_CVE-2018-7225.patch 1970-01-01 
01:00:00.0 +0100
+++ vino-3.22.0/debian/patches/libvncserver_CVE-2018-7225.patch 2019-11-28 
16:11:44.0 +0100
@@ -0,0 +1,46 @@
+From: Markus Koschany 
+Date: Tue, 5 Jun 2018 14:04:07 +0200
+Subject: CVE-2018-7225
+
+Bug-Debian: https://bugs.debian.org/894045
+Origin: 
https://github.com/Lib

Bug#945703: python-falcon: Python2 removal in sid/bullseye

[Sandro Tosi]

> Py2 is already removed from python-falcon. I looked into the package,
> and didn't see any autopkgtest either... Or did I miss something?

did you check https://people.debian.org/~morph/mass-bug-py2removal_take3.txt
as suggested in the bug text?

python-falcon 1.4.1-1 ['Build-Depends->cython']

https://salsa.debian.org/openstack-team/python/python-falcon/blob/debian/train/debian/control#L8

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

Bug#944847: rpki-trust-anchors: [INTL:de] Initial German debconf translation

[Marco d'Itri]

Any comments?

On Nov 23, Marco d'Itri  wrote:

> On Nov 16, Chris Leick  wrote:
> 
> > please find attached the newest German translation. I've marked a typo
> What is this line about?
> 
> # Copyright (C) 2010-2016 Hadley Wickham .
> 
> -- 
> ciao,
> Marco



-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#907489: Fixing sambamba 0.8.6

[Pjotr Prins]

When 1.18 arrives I think it is a good time to get sambamba and biod
in Debian again.

On Thu, Nov 28, 2019 at 03:42:20PM +0100, Matthias Klumpp wrote:
> Am Do., 28. Nov. 2019 um 15:19 Uhr schrieb Andreas Tille :
> >
> > Hi Pjotr,
> >
> > On Thu, Nov 28, 2019 at 07:50:34AM -0600, Pjotr Prins wrote:
> > > Dear Andreas and Matthias,
> > >
> > > Good news, I think I have fixed the Sambamba bug! After a 3 day bug
> > > hunt. Thanks Andreas for pushing me again. Let me ping you when I have
> > > a new release. I need to do some performance testing still. But no
> > > more segfaults using the Debian ldc 1.17 compiler.
> >
> > Very cool!  Just waiting for your ping. :-)
> >
> > > With regard to BioD I suggest the following:
> > >
> > > 1. We create libraries libbiod.so and libbiod.a which ship with D
> > >source code - they act like header files in C.
> > > 2. sambamba uses these header files to build (not linking against the
> > >shared lib)
> > >
> > > The reason is simply performance. The ldc compiler is capable of heavy
> > > optimizations (mostly unrolling loops and inlining code) when it has
> > > all code available. Point I am making that code is available anyway.
> > >
> > > You can choose to change that compile time behaviour by linking
> > > against a shared lib, but just realise you'll end with a much slower
> > > sambamba. The BioD source code shoud be included because you can't
> > > build anything without it.
> >
> > As we discussed at BioHackathon: I just got your point but I have no
> > idea how to implement that source code shipping model for the
> > libbiod-dev package.  I'm fine with whatever is done with D packaging
> > in Debian.
> >
> > To get some numbers:  Do you think rinning test/test_suite.sh could
> > give some impression about the performance gain / loss?
> 
> So, we absolutely have to build this separately, ideally using Meson,
> in Debian - otherwise transitions to newer or different D compilers
> will become an even bigger mess than they already are. Also, embedded
> code copies are explicitly forbidden by the Debian Policy.
> So, libbiod needs a Meson build file or Makefile or anything that
> generates a library installed to a system path that sambamba can find
> later.
> BUT it doesn't mean that the library has to be a shared library. If
> you find that linking libbiod statically into sambamba increases
> performance significantly, we can make the libbiod package generate
> both a shared and static library and then make sambamba prefer the
> static library. This should make transition handling possible as it
> used to (our tracker is smart enough to detect this), satisfy Debian
> policy and reduce the speed impact on sambamba.
> 
> I have been on vacation for a while and then needed to go through a
> lot of stuff @work, so sorry for replying late and also I hope I
> understand the problem correctly.
> FWIW, very, very soon (maybe this week) LDC 1.18 will land in Debian,
> so these packages will go through yet another transition. If you can
> make sure they build & work with LDC 1.18, it would be very great.
> 
> Cheers,
> Matthias
> 
> 
> 
> 
> -- 
> I welcome VSRE emails. See http://vsre.info/

Bug#945783: decrypt_gnupg-sc: Add possibility to use password fallback

[Erik Nellessen]

Package: cryptsetup
Version: 2:2.1.0-5+deb10u2
Severity: wishlist

This wishlist bug is a follow up to bug #903163: https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=903163

In bug #903163 it was requested to add OpenPGP smartcard support to unlock
encrypted volumes. The feature has already been added and the bug has been
resolved.

The work was based by the solution that Peter Lebbing first created and I
adapted for the debian stretch release. It can be found here:
https://gitlab.com/eriknellessen/gpg-encrypted-root/

The use case was to decrypt the root volume at boot time. I could verify (with
the help of Peter Lebbing and Guilhem Moulin) that it is possible to decrypt
the root volume at boot time with a smartcard using the new cryptsetup
features. I documented how to do it here: https://gitlab.com/eriknellessen/gpg-
encrypted-root/blob/cryptsetup-tutorial/CRYPTSETUP.md

One feature however does not yet work with the cryptsetup solution. In the
former solution from my GitLab repository, it is possible to have a password
fallback decryption in case the smartcard gets broken/stolen/lost/etc. The
cryptsetup solution does not offer such a possibility yet (as far as I can
see). I tried using the former approach by encrypting the decryption key both
with the public key from the smartcard and a password, but this did not work.
At boot time, I was never asked for a password but got a bunch of error
messages (I can provide those error messages if necessary). I documented the
steps I took here: https://gitlab.com/eriknellessen/gpg-encrypted-
root/blob/cryptsetup-tutorial-password-fallback/CRYPTSETUP.md

I would like to find a possibility to decrypt the root volume with a password
when having set up the smartcard decryption. Extending the decrypt_gnupg-sc
script to also allow password decryption could be a way. Then there is also the
concept of key slots in cryptsetup. Falling back to another key slot when one
is not working might also be an option. Are there any other ways I am missing?

In the end, I would like to have the setup for the root volume smartcard
decryption included in the debian installer. When finding a solution for the
password fallback problem, it would be interesting for me to see how it
complies with the debian installer.



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

Kernel: Linux 4.19.0-6-amd64 (SMP w/6 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cryptsetup depends on:
pn  cryptsetup-initramfs  
pn  cryptsetup-run

cryptsetup recommends no packages.

cryptsetup suggests no packages.