date:20210311

Bug#985042: webext-browserpass: not working on chrome (and probably firefox)

2021-03-11 Thread wim

Package: webext-browserpass
Version: 2.0.22-2
Severity: important

Hello,

after installing this package,

it seems to be an incomplete setup (or defunct)

this first complaint when clicking on the icon is that there is no 
.password-store file or dir,
after manually creating this dir,
the error goes away,
but no credentials get stored

as such, this extension seems unusable,
or undocumented on how to get this to work

hth,
Wim

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

Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/16 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=nl_BE.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 webext-browserpass depends on:
ii  libc6  2.28-10

Versions of packages webext-browserpass recommends:
ii  chromium 88.0.4324.182-1~deb10u1
ii  firefox-esr  78.8.0esr-1~deb10u1

webext-browserpass suggests no packages.

-- no debconf information

Bug#964914: Fixed

2021-03-11 Thread Roland Clobus

tags 964914 + pending
thanks

Hi,

this issue has been fixed in merge request 247.

With kind regards,
Roland Clobus



OpenPGP_signature
Description: OpenPGP digital signature

Bug#929214: release.debian.org - Add package constraint for cloud images

2021-03-11 Thread Bastian Blank

Hi

Sorry that I missed to follow up on that task for some time.

On Wed, Jun 12, 2019 at 05:57:00PM +0200, Ivo De Decker wrote:
> > | Package: debian-cloud-images-packages
> > | Architecture: amd64
> > | Depends: apparmor, awscli, chrony, cloud-init, cloud-initramfs-growroot, 
> > google-compute-engine, grub-cloud-amd64, grub-pc, libpam-systemd, 
> > linux-image-amd64, linux-image-cloud-amd64, openssh-server, python, 
> > python-boto, python3-boto, sudo, unattended-upgrades, waagent
> > 
> > Please acknowledge that such a package would be okay for using as
> > constraint.  After that I'll upload that change.
> If you create such a package, having a binary per architecture as you
> describe, should do what you want. It can be added to the list as soon as it
> is in testing.

The binary package is in testing since some time.  Please add it to the
key packages list.

Regards,
Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0

Bug#985041: portaudio19: Outdated package git repository

2021-03-11 Thread Paul Menzel


Package: src:portaudio19
Version: 19.6.0-1.1
Severity: minor


Dear Debian folks,


```
$ LANG=C debcheckout libportaudio2
declared git repository at 
https://anonscm.debian.org/cgit/pkg-voip/portaudio19.git
git clone https://anonscm.debian.org/cgit/pkg-voip/portaudio19.git 
libportaudio2 ...

Cloning into 'libportaudio2'...
fatal: repository 
'https://anonscm.debian.org/cgit/pkg-voip/portaudio19.git/' not found

checkout failed (the command above returned a non-zero exit code)
```

The new location seems to be at salsa.debian.org [1].


Kind regards,

Paul


[1]: https://salsa.debian.org/pkg-voip-team/portaudio19

Bug#985040: qemu-system-data: too tight dependencies breaking on binNMUs

2021-03-11 Thread Sven Joachim

Package: qemu-system-data
Version: 1:5.2+dfsg-6
Severity: serious

The fix for #956377 has made the latest binNMU of qemu-system-x86
uninstallable:

,
| $ LANG=C apt -s install qemu-system-x86
| NOTE: This is only a simulation!
|   apt needs root privileges for real execution.
|   Keep also in mind that locking is deactivated,
|   so don't depend on the relevance to the real current situation!
| Reading package lists... Done
| Building dependency tree... Done
| Reading state information... Done
| Some packages could not be installed. This may mean that you have
| requested an impossible situation or if you are using the unstable
| distribution that some required packages have not yet been created
| or been moved out of Incoming.
| The following information may help to resolve the situation:
|
| The following packages have unmet dependencies:
|  qemu-system-data : Depends: qemu-system-x86 (= 1:5.2+dfsg-6) or
|  qemu-system-arm (= 1:5.2+dfsg-6) or
|  qemu-system-mips (= 1:5.2+dfsg-6) or
|  qemu-system-ppc (= 1:5.2+dfsg-6) or
|  qemu-system-sparc (= 1:5.2+dfsg-6) or
|  qemu-system-misc (= 1:5.2+dfsg-6) or
|  qemu-system-s390x (= 1:5.2+dfsg-6) or
|  qemu-system-x86-xen (= 1:5.2+dfsg-6) but it is 
not installable
| E: Unable to correct problems, you have held broken packages.
`

The reason is that there was a binNMU bumping the version of
qemu-system-x86 et al to 1:5.2+dfsg-6+b1, but qemu-system-data is
arch:all and therefore still at version 1:5.2+dfsg-6.


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

Kernel: Linux 5.10.23-nouveau (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qemu-system-data depends on:
ii  qemu-system-x86  1:5.2+dfsg-6

qemu-system-data recommends no packages.

qemu-system-data suggests no packages.

-- no debconf information

Bug#941199: Upstream has valid debian packaging

2021-03-11 Thread Seunghun Han

On Fri, Mar 12, 2021 at 2:16 AM Andreas Metzler  wrote:
>
> Control: unblock 941199 by 958509
>
> On 2020-04-17 Seunghun Han  wrote:
> [...]
> > Dear Laurent Bigonville and Christian Ehrhardt,
>
> > I would like to package this one.
>
> > Best regards,
>
> Hello Seunghun,
>
> are you still working on this or should I retitle this to ITP?

Hello Andreas,

Thank you for the notification. I am still working on this and would
finish it soon.

Best regards,

Seunghun

> cu Andreas

Bug#985038: deluge-common: Warning when running deluge-web --fork with Python 3.8+

2021-03-11 Thread nb

Package: deluge-common
Version: 2.0.3-3
Severity: minor
Tags: patch

Dear Maintainer,

Running deluge-web --fork leads to the following message

Unable to initialize gettext/locale!
'ngettext'
Traceback (most recent call last):
 File "/usr/lib/python3/dist-packages/deluge/i18n/util.py", line 118, in 
setup_translation
   builtins.__dict__['_n'] = builtins.__dict__['ngettext']
KeyError: 'ngettext'

It's only a warning.
Solution is very simple and is here:
https://git.deluge-torrent.org/deluge/commit/?h=develop=d6c96d629183e8bab2167ef56457f994017e7c85

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

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

Versions of packages deluge-common depends on:
ii  python3 3.9.2-2
ii  python3-chardet 4.0.0-1
ii  python3-mako1.1.3+ds1-2
ii  python3-openssl 20.0.1-1
ii  python3-pil 8.1.2-1
ii  python3-pkg-resources   52.0.0-3
ii  python3-pyasn1  0.4.8-1
ii  python3-rencode 1.0.6-1+b3
ii  python3-setproctitle1.2.1-1+b1
ii  python3-six 1.15.0-2
ii  python3-twisted 20.3.0-4
ii  python3-xdg 0.27-2
ii  python3-zope.interface  5.2.0-1

Versions of packages deluge-common recommends:
ii  geoip-database  20191224-3
ii  python3-dbus1.2.16-5
ii  python3-geoip   1.3.2-3+b3

deluge-common suggests no packages.

-- no debconf information

Bug#985004: gemma: flaky armhf autopkgtest: regularly times out after 2:47 h

2021-03-11 Thread Andreas Tille

Hi,

I recommend to remove armhf from the list of architectures.
This kind of software is possibly not used on armhf and
upstream (in CC) will probably confirm this.

Kind regards
Andreas.

On Thu, Mar 11, 2021 at 09:08:15PM +0100, Paul Gevers wrote:
> Source: gemma
> Version: 0.98.3+dfsg-1
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: flaky
> 
> Dear maintainer(s),
> 
> Your package has an autopkgtest, great. However, I looked into
> the history of your autopkgtest [1,2] and I noticed it fails regularly
> on armhf, while sporadically a rerun passes. I copied some of the output
> at the bottom of this report.
> 
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.
> 
> Paul
> 
> [1] https://ci.debian.net/packages/g/gemma/testing/armhf/
> [2] https://ci.debian.net/packages/g/gemma/unstable/armhf/
> 
> https://ci.debian.net/data/autopkgtest/testing/armhf/g/gemma/10238800/log.gz
> 
> https://ci.debian.net/data/autopkgtest/testing/armhf/g/gemma/10042898/log.gz
> 
> autopkgtest [20:25:33]: test run-sample-analysis: [---
> GEMMA 0.98.3 (2020-11-28) by Xiang Zhou and team (C) 2012-2020
> Reading Files ...
> ## number of total individuals = 1940
> ## number of analyzed individuals = 1410
> ## number of covariates = 1
> ## number of phenotypes = 1
> ## number of total SNPs/var=12226
> ## number of analyzed SNPs =10768
> Calculating Relatedness Matrix ...
>0%
>    8%
>    16%
>    25%
>    33%
>    41%
>    49%
>    57%
>    65%
>    74%
>    82%
>    90%
> =  98%
> == 100%
>  INFO: Done.
> GEMMA 0.98.3 (2020-11-28) by Xiang Zhou and team (C) 2012-2020
> Reading Files ...
> ## number of total individuals = 1940
> ## number of analyzed individuals = 1410
> ## number of covariates = 1
> ## number of phenotypes = 1
> ## number of total SNPs/var=12226
> ## number of analyzed SNPs =10768
> Start Eigen-Decomposition...
> pve estimate =0.608801
> se(pve) =0.032774
>0%
>    8%
>    16%
>    25%
>    33%
>    41%
>    49%
>    57%
>    65%
>    74%
>    82%
>    90%
> =  98%
> == 100%
> == 100%
>  INFO: Done.
> GEMMA 0.98.3 (2020-11-28) by Xiang Zhou and team (C) 2012-2020
> Reading Files ...
> ## number of total individuals = 1940
> ## number of analyzed individuals = 1197
> ## number of covariates = 1
> ## number of phenotypes = 2
> ## number of total SNPs/var=12226
> ## number of analyzed SNPs =10758
> Start Eigen-Decomposition...
> REMLE estimate for Vg in the null model:
> 1.3940
> -0.2267   2.0817  
> se(Vg):
> 0.1567
> 0.13630.2359  
> REMLE estimate for Ve in the null model:
> 0.3489
> 0.04910.4144  
> se(Ve):
> 0.0206
> 0.01660.0267  
> REMLE likelihood = -2855.1664
> MLE estimate for Vg in the null model:
> 1.3959
> -0.2267   2.0854  
> se(Vg):
> 0.1568
> 0.13650.2361  
> MLE estimate for Ve in the null model:
> 0.3483
> 0.04900.4136  
> se(Ve):
> 0.0206
> 0.01660.0266  
> MLE likelihood = -2856.0280
>0%
>    8%
>    16%
>

Bug#983873: retroarch: Menu freezes shortly after start

2021-03-11 Thread Ryan Tandy


Control: tag -1 moreinfo

Hello Pelle and thank you for reporting this retroarch issue.

On Tue, 02 Mar 2021 16:10:32 +0100 Pelle  wrote:

When launching RetroArch, the menu freezes up instantly or after a couple of
seconds.


This isn't happening on my system. I can use the menu normally, launch 
content, etc.


Can you provide some more information about your environment? I'm using 
X11 (not Wayland) on an Intel GPU. I also don't have any controller 
connected, only mouse and keyboard.


Could you please run it as "retroarch --verbose" and post some or all of 
the output up to the point where it freezes? There are also some 
troubleshooting tips on the upstream site:

https://docs.libretro.com/guides/generating-retroarch-logs/

Would it be possible for you to install the debug symbols and capture a 
backtrace when it's frozen?

https://wiki.debian.org/HowToGetABacktrace


A work-around is to change the settings in .config/retroarch/retroarch.cfg
menu_driver = "rgui"
video_driver = "sdl2"


Just to confirm, I checked my config after starting it for the first 
time, and I got these defaults:


menu_driver = "xmb"
video_driver = "gl"

and did not experience any freezes.


The issue appears to be resolved in v1.9.0 which is the version currently
available as flatpak.


If the 1.9.0 you tested was the flatpak, I wonder whether it's possible 
for you to also to test a flatpak of 1.7.3, in case there is a relevant 
difference in the build environment or the libraries used?


Thank you!

Ryan

Bug#985036: Package: selinux-basics

2021-03-11 Thread Winn Johnston

Package: selinux-basics
Version: 5.6
Severity: important
Package selinux-basics

which check-selinux-installation
/usr/sbin/check-selinux-installation

type check-selinux-installation
check-selinux-installation is /usr/sbin/check-selinux-installation

dpkg --search /usr/sbin/check-selinux-installation
selinux-basics: /usr/sbin/check-selinux-installation

dpkg --list selinux-basics
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  selinux-basics 0.5.6all  SELinux basic support

dpkg --status selinux-basics
Package: selinux-basics
Status: install ok installed
Priority: optional
Section: admin
Installed-Size: 50
Maintainer: Debian SELinux maintainers <
selinux-de...@lists.alioth.debian.org>
Architecture: all
Version: 0.5.6
Depends: checkpolicy, policycoreutils (>= 2.4), selinux-utils, perl:any,
python3:any (>= 3.3.2-2~)
Recommends: policycoreutils-python-utils (>= 2.4), selinux-policy-default,
setools
Suggests: logcheck, syslog-summary
Breaks: selinux-policy-default (<= 2:0.2.20100524-4)
Description: SELinux basic support
 This package will pull in basic SELinux stuff to ease installation, as well
 as provide scripts and helpers to work around common problems.

Bug Output:
check-selinux-installation
Traceback (most recent call last):
  File "/usr/sbin/check-selinux-installation", line 33, in 
results += test.test()
  File "/usr/share/selinux-basics/tests/24_fsckfix.py", line 24, in test
raise IOError("/etc/default/rcS not found, is this Debian?")
OSError: /etc/default/rcS not found, is this Debian?

Bug#984555: Fwd: Bug#984555: gavodachs2-server: fails to install/upgrade. breaks on executing SQL script.

2021-03-11 Thread James Van Zandt

On Fri, 5 Mar 2021 12:08:06 +0100 Markus Demleitner <
msdem...@ari.uni-heidelberg.de> wrote:
> > createdb: database creation failed: ERROR:  database "gavo" already
exists
> > Creation of gavo database failed; assuming it's already there
> > and carrying on.
>
> This means that there has been a DaCHS on that machine before, i.e.,
> that this is an upgrade.  Is that right?  If so, then this message
> is expected (and we ought to hide it one of these days).
>
> > /usr/lib/python3/dist-packages/gavo/user/initdachs.py:310: UserWarning:
SQL
> > script file for /usr/share/postgresql/contrib/pg_sphere.sql not found.
>
> This is where things go wrong.  DaCHS should not even try to load the
> pgsphere SQL, as all pgspheres that can possibly in use now already
> use the new Postgres extension system.
>
> So, why does it try this?  This:
>
> > Versions of packages gavodachs2-server depends on:
> > ii  postgresql-pgsphere [postgresql-11-pgsphere]  1.1.1+2018.10.13-1
>
> is essentially as it should be.  I wonder if it has been like this at
> the time of the DaCHS installation.
>
> But let's see if things are properly there now.  Could you run
>
>   psql gavo
>
> and then in psql
>
>   select * from pg_available_extensions where name='pg_sphere';
>
> What does that say?
>
>

For what it's worth, I had the same error:
Setting up gavodachs2-server (2.3+dfsg-1) ...
createdb: database creation failed: ERROR:  database "gavo" already exists
Creation of gavo database failed; assuming it's already there
and carrying on.
createuser: creation of new role failed: ERROR:  role "dachsroot" already
exists
/usr/lib/python3/dist-packages/gavo/user/initdachs.py:310: UserWarning: SQL
script file for /usr/share/postgresql/contrib/pg_sphere.sql not found.
There are many reasons why that may be ok, but unless you know what you are
doing, you probably should install the corresponding postgres extension.
  warnings.warn("SQL script file for %s not found.  There are many"
/usr/lib/python3/dist-packages/gavo/user/initdachs.py:328: UserWarning: SQL
script file /usr/share/postgresql/contrib/pg_sphere.sql failed.  Try
running manually using psql.  While it hasn't run, the pgSphere extension
is not available.
  warnings.warn("SQL script file %s failed.  Try running manually"
/usr/lib/python3/dist-packages/gavo/user/initdachs.py:310: UserWarning: SQL
script file for /usr/share/postgresql/contrib/q3c.sql not found.  There are
many reasons why that may be ok, but unless you know what you are doing,
you probably should install the corresponding postgres extension.
  warnings.warn("SQL script file for %s not found.  There are many"
/usr/lib/python3/dist-packages/gavo/user/initdachs.py:328: UserWarning: SQL
script file /usr/share/postgresql/contrib/q3c.sql failed.  Try running
manually using psql.  While it hasn't run, the q3c extension is not
available.
  warnings.warn("SQL script file %s failed.  Try running manually"
*** Error: While executing DB query:

  select * from dc.rdmeta where sourceRD='__system__/dc_tables'

the database engine reported:

  ERROR:  schema "dc" does not exist
LINE 1: select * from dc.rdmeta where
sourceRD='__system__/dc_tables...
  ^

I tried your suggestion, but didn't get very far:
$ psql gavo
psql: error: FATAL:  role "jrv" does not exist

Let me know if there's something else you want to cross-check.
(I am a fairly knowledgeable Debian user, but not an SQL user. )

  - Jim Van Zandt

Bug#985028: RFS: age/1.0.0~rc1-1 -- simple, modern and secure encryption tool

2021-03-11 Thread Johan Fleury

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: age
   Version : 1.0.0~rc1-1
   Upstream Author : Filippo Valsorda 
 * URL : https://github.com/FiloSottile/age
 * License : Expat, BSD-3-clause, ISC
 * Vcs : https://salsa.debian.org/go-team/packages/age
   Section : utils

It builds those binary packages:

  age - simple, modern and secure encryption tool

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/a/age/age_1.0.0~rc1-1.dsc

Changes since the last upload:

 age (1.0.0~rc1-1) UNRELEASED; urgency=medium
 .
   [ nicoo ]
   * d/rules: Do not build PIE binaries on architectures where go cannot
 (Closes: #981412)
   * d/control: Declare compliance with policy v4.5.1
   * New upstream version 1.0.0~beta6
 + New `-R` flag to specify a file with a list of recipients.
 + Armored encoding now up to 20× faster
 .
   [ Johan Fleury ]
   * New upstream version 1.0.0~rc1 (Closes: #981413)
 + age: when writing to an existing file, its content will be overwritten
 + age: new `-e`/`--encrypt` flag
 + age-keygen: new `-y` flag to convert identity file to recipient file

Regards

-- 

Johan Fleury

signature.asc
Description: OpenPGP digital signature

Bug#985035: ITP: pydata-sphinx-theme -- Bootstrap-based Sphinx theme from the PyData community

2021-03-11 Thread Sandro Tosi

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org
Owner: Sandro Tosi 

* Package name: pydata-sphinx-theme
  Version : 0.5.0
  Upstream Author : Joris Van den Bossche 
* URL : https://github.com/pydata/pydata-sphinx-theme
* License : BSD
  Programming Lang: Python
  Description : bootstrap-based Sphinx theme from the PyData community

Binary package names: python3-pydata-sphinx-theme

 originally developed for the pandas docs, work is being done to make this more
 generic and more easily extensible to suit the needs of the different projects;
 noteworthy project using this theme:
 .
  * Pandas: https://pandas.pydata.org/docs/
  * NumPy: https://numpy.org/devdocs/
  * Bokeh: https://docs.bokeh.org/en/dev/
  * JupyterHub and Binder: https://docs.mybinder.org/, 
http://z2jh.jupyter.org/en/latest/, 
https://repo2docker.readthedocs.io/en/latest/, 
https://jupyterhub-team-compass.readthedocs.io/en/latest/
  * Jupyter Book beta version uses an extension of this theme: 
https://beta.jupyterbook.org
  * Fairlearn: https://fairlearn.github.io/master/quickstart.html

Bug#985034: debbugs: test multi-user usertags

2021-03-11 Thread Paul Wise

Package: bugs.debian.org
Usertags: pabs-test-usertags-for-pabs
User: bugs.debian@packages.debian.org
Usertags: pabs-test-usertags-for-bugs
User: debb...@packages.debian.org
Usertags: pabs-test-usertags-for-debbugs

This is a test of the multi-user usertags stuff (see #582171).

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#985033: debian/copyright is not up-to-date: coderay seems to have been relicensed under MIT license

2021-03-11 Thread Daniel Leidert

Source: coderay
Version: 1.1.3-3
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It seem the coderay sources are now licensed under the MIT license and not
under the LGPL license. debian/copyright seems to be outdated and wrong here.

Regards, Daniel


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

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmBKthsACgkQS80FZ8KW
0F387w//ezc1er6Hv8c7swmmwgK8XfokzAcxFbktXyIsUOwN+s2fKlFwjinFkArU
PP8lOe7qzB2vB5eol19vofYdDzJoOqo/RCzsS+Q8Rm3gUzcyTF2pIeubzlNqZMf2
KMYaERHnfrGlLklcOzt+x8JfRvmxS2MAFHNLBuws0k9yISdWfW36DeCFiz0Miqik
VrPAaWMRFUzaqnH3lXEoi342OomkDq2wmx7YnqRd4ESHTWdpAY5b9dC8r6tCnynj
zcspt/0uPnXBKKPuBKXsucBoLr80te+x/7DZ/iLILAbIdEZ+o1jzCu3pCRXQUFdK
vNOnwaBVhDl9aciXTrj1ocbNS1shximlu6vJMaMTB5MXVNt5ph691jazr6bYXjn2
MZU8EK5fkPnYIkX3DOGGZMjuQ5wMN55Z3Udgf+pUE9oXDprc+0vxuLmq6UtLrHKy
uQm/WOd3Fj+r71s5zaRqlf7gShQU2oV23/4PLWC84nswoGkZTnk9yj5X4tw+HdfS
82+iOGayRny2a+EkglGT4IvOvXSdPnXnucjronzpf6s5kw/JP9BRyyF85AWM87q2
6zjycLQo+j3xh3CV4jgNC9pRC6yUTj5YsxnYPIM7v0YWgQBwEzAz6JLBMU/2zEvO
JRHm+XskHA+U6PsV4ccyA4m7zEKPsV10xRrqrZhQekf96BvaQ8Y=
=GfoC
-END PGP SIGNATURE-

Bug#985032: RFS: rgbds/0.4.2-1 [ITP] -- Game Boy ASM programming tools

2021-03-11 Thread Eldred HABERT


Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: rgbds
   Version : 0.4.2-1
   Upstream Author : Eldred Habert 
 * URL : https://rgbds.gbdev.io
 * License : Expat
 * Vcs : https://github.com/gbdev/rgbds
   Section : devel

It builds those binary packages:

  rgbds - Game Boy ASM programming tools

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/r/rgbds/rgbds_0.4.2-1.dsc

Changes for the initial release:

 rgbds (0.4.2-1) experimental; urgency=medium
 .
   * Initial release (Closes: #984927)

(Note: The upload to experimental was suggested to me on IRC to avoid pushing a 
non-bullseye package to sid.)

Regards,
~ Eldred HABERT

Bug#985031: Get a fresher version of tidy

2021-03-11 Thread 積丹尼 Dan Jacobson

Package: tidy
Version: 2:5.6.0-11
Severity: wishlist

https://github.com/htacg/tidy-html5/issues/924#issuecomment-797046261
mentions ways to get a fresher version of tidy. So maybe Debian can get
a fresher version of tidy.

Bug#985029: git-phab: non-functional bash-completion script

2021-03-11 Thread Kevin Locke

On Thu, 2021-03-11 at 23:46 +0100, Andrej Shadura wrote:
> On Thu, 11 Mar 2021, at 22:53, Kevin Locke wrote:
>> I've attached a patch with a functional bash-completion script based on
>> the output of register-python-argcomplete3.  See patch for specific
>> details.
> 
> Thanks a lot!

My pleasure.  Thank you for the lightning-fast fix and upload!

Cheers,
Kevin

Bug#985029: git-phab: non-functional bash-completion script

2021-03-11 Thread Andrej Shadura

Hi,

On Thu, 11 Mar 2021, at 22:53, Kevin Locke wrote:
> The bash-completion script which git-phab installs has a syntax error
> (missing } to end the function) and calls a function which is not
> defined (_python_argcomplete_global).  The errors were hidden due to
> bash-completion redirecting stdout/stderr when loading completion
> scripts, which is being changed in an upcoming version.  See
> https://github.com/scop/bash-completion/issues/506
> 
> I've attached a patch with a functional bash-completion script based on
> the output of register-python-argcomplete3.  See patch for specific
> details.

Thanks a lot!

-- 
Cheers,
  Andrej

Bug#985030: thunarx-python: v0.5.2 would work with Python 3.9

2021-03-11 Thread Florian Diesch

Package: thunarx-python
Version: 0.5.1-2
Severity: important
X-Debbugs-Cc: de...@florian-diesch.de

Dear Maintainer,

thunarx-python v0.5.1 doesn't seem to work with Python3 in unstable
and is schedules to bve removed.

I've successfully compiled anmd tested v0.5.2 in unstable. Please update 
the package to the new version.

Thanks for your work!


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

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

Versions of packages thunarx-python depends on:
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-9
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.7-2
ii  libgtk-3-0   3.24.24-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpython2.7 2.7.18-6
ii  libthunarx-3-0   4.16.4-1
ii  thunar   4.16.4-1

thunarx-python recommends no packages.

thunarx-python suggests no packages.

-- no debconf information

Bug#984917: feedgnuplot: dynamic plots (--stream) do not work

2021-03-11 Thread Detlev Zundel

Hi Dima,

> Hi. Yeah, wayland is almost certainly the cuplrit. If you can talk to
> the gnuplot upstream to get it resolved, that'd be awesome.

Ok, I'll see what I can do.

And thanks for the awesome tool and the outstanding support!

Cheers
  Detlev

-- 
Warning: this comic occasionally contains strong language (which may be unsuit-
able for children), unusual humor (which may be unsuitable for adults), and ad-
vanced mathematics (which may be unsuitable for liberal-arts majors). /xkcd.org

Bug#985029: git-phab: non-functional bash-completion script

2021-03-11 Thread Kevin Locke

Package: git-phab
Version: 2.9.0~git20170531+6877964-1
Severity: normal
Tags: patch

Dear Maintainer,

The bash-completion script which git-phab installs has a syntax error
(missing } to end the function) and calls a function which is not
defined (_python_argcomplete_global).  The errors were hidden due to
bash-completion redirecting stdout/stderr when loading completion
scripts, which is being changed in an upcoming version.  See
https://github.com/scop/bash-completion/issues/506

I've attached a patch with a functional bash-completion script based on
the output of register-python-argcomplete3.  See patch for specific
details.

Thanks,
Kevin
>From 5d3f5f2a52dcae25509384bc4c1fe708f4b5fb90 Mon Sep 17 00:00:00 2001
Message-Id: 
<5d3f5f2a52dcae25509384bc4c1fe708f4b5fb90.1615499214.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Thu, 11 Mar 2021 13:55:19 -0700
Subject: [PATCH] fix bash-completion script

The previous bash-completion script was non-functional.  Replace it with
a functional bash-completion script generated using:

register-python-argcomplete3 git-phab | sed '
s/_python_argcomplete/_git_phab/
s/"$1"/git-phab/
s/COMP_LINE="$COMP_LINE"/COMP_LINE="${COMP_LINE\/git phab\/git-phab}"/'

The first replacement renames the completion function to _git_phab,
which is required by the bash-completion script for git to complete `git
phab`.

The second replacement invokes git-phab to perform the completion,
rather than the first function argument, since the git bash-completion
script does not pass any arguments to the completion function.

The third replaces 'git phab' with 'git-phab' in $COMP_LINE so that
argcomplete can recognize the script name when parsing $COMP_LINE.

Note: It would be possible to Build-Depend on python3-argcomplete and
generate this script during build.  (See diffoscope for an example.)
However, making the above changes would be fragile, since the output of
register-python-argcomplete3 may change arbitrarily, so this patch uses
the edited script.

Signed-off-by: Kevin Locke 
---
 debian/bash_completion.d/git-phab | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/debian/bash_completion.d/git-phab 
b/debian/bash_completion.d/git-phab
index 6603f72..e9a3ea5 100644
--- a/debian/bash_completion.d/git-phab
+++ b/debian/bash_completion.d/git-phab
@@ -1,7 +1,22 @@
-function _git_phab()
-{
-  COMP_WORDS=(git-phab ${COMP_WORDS[@]:2})
-  COMP_CWORD=$((COMP_CWORD - 1))
-  COMP_LINE=${COMP_LINE/git phab/git-phab}
-  _python_argcomplete_global git-phab
 
+_git_phab() {
+local IFS=$'\013'
+local SUPPRESS_SPACE=0
+if compopt +o nospace 2> /dev/null; then
+SUPPRESS_SPACE=1
+fi
+COMPREPLY=( $(IFS="$IFS" \
+  COMP_LINE="${COMP_LINE/git phab/git-phab}" \
+  COMP_POINT="$COMP_POINT" \
+  COMP_TYPE="$COMP_TYPE" \
+  _ARGCOMPLETE_COMP_WORDBREAKS="$COMP_WORDBREAKS" \
+  _ARGCOMPLETE=1 \
+  _ARGCOMPLETE_SUPPRESS_SPACE=$SUPPRESS_SPACE \
+  git-phab 8>&1 9>&2 1>/dev/null 2>/dev/null) )
+if [[ $? != 0 ]]; then
+unset COMPREPLY
+elif [[ $SUPPRESS_SPACE == 1 ]] && [[ "$COMPREPLY" =~ [=/:]$ ]]; then
+compopt -o nospace
+fi
+}
+complete -o nospace -o default -F _git_phab "git-phab"
-- 
2.30.1

Bug#985006: python3-overpass: SyntaxWarning during package installation

2021-03-11 Thread Sandro Tosi

> Severity: important

mind explaining the severity? according to
https://www.debian.org/Bugs/Developer#severities

important: a bug which has a major effect on the usability of a
package, without rendering it completely unusable to everyone.

and this bug has 0 effect on the usability of the package, it's a minor at best

minor: a problem which doesn't affect the package's usefulness, and is
presumably trivial to fix.

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

Bug#985027: claws-mail: Please compile claws-mail with NetworkManager support

2021-03-11 Thread Benjamin Sigonneau

Package: claws-mail
Version: 3.17.8-1+b1
Severity: wishlist
X-Debbugs-Cc: benjamin+deb...@dromaludaire.info

Dear Maintainer,

I currently hit a problem with claws-mail: it freezes during network
changes. This problem is known upstream and a fix exists, as stated in
the following upstream bug report in 2018:

https://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=4129

The proposed fix is to compile claws-mail with NetworkManager support.
It appears that this is not the case in the current Debian package, as
can be seen in the Help > About > Options dialog in claws-mail, or in
the output of `claws-mail --version-full`:

```
Claws Mail version 3.17.8
runtime GTK+ 2.24.33 / GLib 2.66.7
buildtime GTK+ 2.24.32 / GLib 2.66.2
Compiled-in features:
 compface
 Enchant
 GnuTLS
 IPv6
 iconv
 LDAP
 libetpan 1.9
 libSM
 librSVG 2.50.1
```

I would be very grateful if the NetworkManager option was enabled by
default in the debian package.

Regards,


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

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

Versions of packages claws-mail depends on:
ii  libc62.31-9
ii  libcairo21.16.0-5
ii  libcompfaceg11:1.5.2-5+b2
ii  libenchant-2-2   2.2.15-1
ii  libetpan20   1.9.4-3
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.7-1
ii  libgnutls30  3.7.0-7
ii  libgtk2.0-0  2.24.33-1
ii  libice6  2:1.0.10-1
ii  libldap-2.4-22.4.57+dfsg-2
ii  libnettle8   3.7-2.1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  librsvg2-2   2.50.3+dfsg-1
ii  libsm6   2:1.2.3-1
ii  xdg-utils1.1.3-4

Versions of packages claws-mail recommends:
ii  aspell-en [aspell-dictionary]  2018.04.16-0-1
ii  aspell-fr [aspell-dictionary]  0.50-3-8.1
ii  claws-mail-i18n3.17.8-1
ii  xfonts-100dpi  1:1.0.4+nmu1.1
ii  xfonts-75dpi   1:1.0.4+nmu1.1

Versions of packages claws-mail suggests:
ii  chromium [www-browser] 88.0.4324.182-1
pn  claws-mail-doc 
pn  claws-mail-tools   
ii  elinks [www-browser]   0.13.2-1+b1
ii  firefox [www-browser]  86.0-2
pn  gedit | kwrite | mousepad | nedit  
ii  links [www-browser]2.21-1+b1
ii  lynx [www-browser] 2.9.0dev.6-1
ii  netrik [www-browser]   1.16.1-2+b2
ii  w3m [www-browser]  0.5.3+git20210102-3

-- no debconf information

Bug#985026: python3-pulp: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-pulp
Version: 1.6.0+dfsg1-5
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-pulp (1.6.0+dfsg1-5) ...
  /usr/lib/python3/dist-packages/pulp/pulp.py:700: SyntaxWarning: "is" with a 
literal. Did you mean "=="?
if other is 0: return self
  /usr/lib/python3/dist-packages/pulp/pulp.py:720: SyntaxWarning: "is" with a 
literal. Did you mean "=="?
if other is 0: return self


Andreas

Bug#985025: golang-github-pires-go-proxyproto: CVE-2021-23351

2021-03-11 Thread Salvatore Bonaccorso

Source: golang-github-pires-go-proxyproto
Version: 0.4.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/pires/go-proxyproto/issues/69
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for golang-github-pires-go-proxyproto.

CVE-2021-23351[0]:
| The package github.com/pires/go-proxyproto before 0.5.0 are vulnerable
| to Denial of Service (DoS) via the parseVersion1() function. The
| reader in this package is a default bufio.Reader wrapping a net.Conn.
| It will read from the connection until it finds a newline. Since no
| limits are implemented in the code, a deliberately malformed V1 header
| could be used to exhaust memory in a server process using this code -
| and create a DoS. This can be exploited by sending a stream starting
| with PROXY and continuing to send data (which does not contain a
| newline) until the target stops acknowledging. The risk here is small,
| because only trusted sources should be allowed to send proxy protocol
| headers.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-23351
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23351
[1] https://github.com/pires/go-proxyproto/issues/69
[2] 
https://github.com/pires/go-proxyproto/commit/7f48261db810703d173f27f3309a808cc2b49b8b
[3] https://snyk.io/vuln/SNYK-GOLANG-GITHUBCOMPIRESGOPROXYPROTO-1081577

Regards,
Salvatore

Bug#985024: python3-num2words: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-num2words
Version: 0.5.9-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-num2words (0.5.9-1) ...
  /usr/lib/python3/dist-packages/num2words/lang_AR.py:191: SyntaxWarning: "is 
not" with a literal. Did you mean "!="?
if ret_val is not "" and tens < 4:
  /usr/lib/python3/dist-packages/num2words/lang_AR.py:195: SyntaxWarning: "is 
not" with a literal. Did you mean "!="?
if ret_val is not "" and ones != 0:
  /usr/lib/python3/dist-packages/num2words/lang_AR.py:229: SyntaxWarning: "is 
not" with a literal. Did you mean "!="?
if group_description is not '':
  /usr/lib/python3/dist-packages/num2words/lang_AR.py:231: SyntaxWarning: "is 
not" with a literal. Did you mean "!="?
if ret_val is not "":
  /usr/lib/python3/dist-packages/num2words/lang_AR.py:239: SyntaxWarning: "is 
not" with a literal. Did you mean "!="?
if ret_val is not "":
  /usr/lib/python3/dist-packages/num2words/lang_AR.py:253: SyntaxWarning: "is 
not" with a literal. Did you mean "!="?
if self.arabicPrefixText is not "":
  /usr/lib/python3/dist-packages/num2words/lang_AR.py:291: SyntaxWarning: "is 
not" with a literal. Did you mean "!="?
if self.arabicSuffixText is not "":
  /usr/lib/python3/dist-packages/num2words/lang_AR.py:302: SyntaxWarning: "is" 
with a literal. Did you mean "=="?
if currency is 'EGP':
  /usr/lib/python3/dist-packages/num2words/lang_AR.py:305: SyntaxWarning: "is" 
with a literal. Did you mean "=="?
elif currency is 'KWD':


Andreas

Bug#985023: python3-isodatetime: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-isodatetime
Version: 2.0.2-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-isodatetime (2.0.2-2) ...
  /usr/lib/python3/dist-packages/metomi/isodatetime/data.py:2030: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
if year is not None and (year is "leap" or get_is_leap_year(year)):


Andreas

Bug#985022: python3-mbed-ls: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-mbed-ls
Version: 1.6.2+dfsg-6
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-mbed-ls (1.6.2+dfsg-6) ...
  /usr/lib/python3/dist-packages/mbed_lstools/lstools_base.py:364: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
if oper is '+':
  /usr/lib/python3/dist-packages/mbed_lstools/lstools_base.py:366: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
elif oper is '-':
  /usr/lib/python3/dist-packages/mbed_lstools/platform_database.py:504: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
if id is '*' and device_type in self._dbs[self._prim_db]:


Andreas

Bug#985021: python3-azure-cosmos: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-azure-cosmos
Version: 3.1.1-3
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-azure-cosmos (3.1.1-3) ...
  /usr/lib/python3/dist-packages/azure/cosmos/session.py:186: SyntaxWarning: 
"is not" with a literal. Did you mean "!="?
if session_token is not '':


Andreas

Bug#985000: Merge request for nfs-utils to fix bugs #985000 and #985002

2021-03-11 Thread Joachim Falk

Hi All,

Am 07.03.21 um 08:40 schrieb Salvatore Bonaccorso:
> Hi Felix,
>
> On Sat, Mar 06, 2021 at 11:26:36PM -0800, Felix Lechner wrote:
>> Hi Salvatore,
>>
>> On Sat, Mar 6, 2021 at 2:15 AM Joachim Falk  wrote:
>>>
>>> I have a merge request open on nfs-utils.
>>
>> I would like to second this request, please. I filed (or patched) some
>> of these bugs, but someone downgraded them from the RC level. They are
>> on my list of open items for bullseye: I plan to potentially upgrade
>> the severities again, after consulting with the release team. Your
>> input would be much appreciated. Thanks!
>>
>> Thank you, Joachim, for advancing these grave issues in a helpful way!
>
> Can you check which ones the release team accepts as potentially to be
> be fixed at this stage of the release, and then we really can aim to
> take those.

can we get some more bugs fixed? I created bug reports for two more problems
that were fixed in my previous merge request. Moreover, there is now a merge 
request
( https://salsa.debian.org/kernel-team/nfs-utils/-/merge_requests/7 ) 
exclusively to
fix those bugs. The patches are one or two liners and, hence, should be 
uncontroversial.
The merge request should cleanly apply to the current master.

Best,

Joachim

OpenPGP_signature
Description: OpenPGP digital signature

Bug#985020: ITP: xtensor-blas -- an extension to xtensor offering bindings to BLAS and LAPACK

2021-03-11 Thread Drew Parsons

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Science List 


* Package name: xtensor-blas
  Version : 0.6.1
  Upstream Author : QuantStack: Wolf Vollprecht, Johan Mabille and Sylvain 
Corlay
* URL : https://github.com/xtensor-stack/xtensor-blas
* License : BSD
  Programming Lang: C++
  Description : an extension to xtensor offering bindings to BLAS and LAPACK

xtensor-blas is an extension to the header-only xtensor library,
offering bindings to BLAS and LAPACK libraries through cxxblas and
cxxlapack from the FLENS project.

xtensor-blas currently provides non-broadcasting dot, norm (1- and
2-norm for vectors), inverse, solve, eig, cross, det, slogdet,
matrix_rank, inv, cholesky, qr, svd in the xt::linalg namespace (check
the corresponding xlinalg.hpp header for the function signatures). The
functions, and signatures, are trying to be 1-to-1 equivalent to
NumPy. Low-level functions to interface with BLAS or LAPACK with
xtensor containers are also offered in the blas and lapack namespace.

Used by basix and dolfinx in the FEniCS project.

To be maintained alongside xtensor by the Debian Science Team.

Bug#985019: python3-pyresample: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-pyresample
Version: 1.17.0+ds-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-pyresample (1.17.0+ds-1+b1) ...
  /usr/lib/python3/dist-packages/pyresample/ewa/__init__.py:214: SyntaxWarning: 
"is" with a literal. Did you mean "=="?
if "fill" is None:


Andreas

Bug#985018: python3-django-haystack: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-django-haystack
Version: 3.0-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-django-haystack (3.0-1) ...
  /usr/lib/python3/dist-packages/haystack/backends/whoosh_backend.py:734: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
if value is None or len(value) is 0:


Andreas

Bug#985017: python3-whoosh: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-whoosh
Version: 2.7.4+git6-g9134ad92-5
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-whoosh (2.7.4+git6-g9134ad92-5) ...
  /usr/lib/python3/dist-packages/whoosh/codec/whoosh3.py:1116: SyntaxWarning: 
"is" with a literal. Did you mean "=="?
elif fixedsize is 0:


Andreas

Bug#985016: python3-yaql: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-yaql
Version: 1.1.3-5
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-yaql (1.1.3-5) ...
  /usr/lib/python3/dist-packages/yaql/language/parser.py:84: SyntaxWarning: 
"is" with a literal. Did you mean "=="?
(('left',) if oa is 'l' else ('right',)) +


Andreas

Bug#984719: lintian: add check for incomplete XS-Go-Import-Path

2021-03-11 Thread Felix Lechner

Hi Alexandre,

On Sun, Mar 7, 2021 at 8:54 AM Alexandre Viau  wrote:
>
> It would be great if lintian validated that `XS-Go-Import-Path` was correct.

I implemented it on an unreleased branch, but it will not work well
unless the field is propagated into the control files of installed
packages (for your example, golang-github-bmizerany-pat-dev). I see
the field only in the dsc, but not in CONTROL [1]. Is that possible,
please?

Kind regards
Felix Lechner

[1] 
https://binarycontrol.debian.net/cache/unstable/golang-github-bmizerany-pat-dev/control

Bug#985015: python3-imageio: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-imageio
Version: 2.4.1-3
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-imageio (2.4.1-3) ...
  /usr/lib/python3/dist-packages/imageio/plugins/_tifffile.py:2813: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
if key is 0:


Andreas

Bug#984917: feedgnuplot: dynamic plots (--stream) do not work

2021-03-11 Thread Dima Kogan

Hi. Yeah, wayland is almost certainly the cuplrit. If you can talk to
the gnuplot upstream to get it resolved, that'd be awesome.

Bug#985014: python3-gnocchiclient: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-gnocchiclient
Version: 7.0.6-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-gnocchiclient (7.0.6-1) ...
  /usr/lib/python3/dist-packages/gnocchiclient/v1/resource_cli.py:201: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
if value is "":

Andreas

Bug#985012: apache2: Race condition in DEP8 test case t/apache/expr_string.t

2021-03-11 Thread Bryce Harrington

Source: apache2
Version: 2.4.43-1
Severity: normal

Dear Maintainer,

One of the test cases has been seen to fail intermittently in Ubuntu,
so we added a small sleep to it which seems to have solved the problem.
I didn't notice that Debian hits this, but upstream did in the past, and
used the same solution to fix it.

https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1890302

Patch as applied to Ubuntu is attached.

Thanks,
Bryce

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

Kernel: Linux 5.4.0-65-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apache2-bin depends on:
ii  libapr1  1.6.5-1ubuntu1
ii  libaprutil1  1.6.1-4ubuntu2
ii  libaprutil1-dbd-sqlite3  1.6.1-4ubuntu2
ii  libaprutil1-ldap 1.6.1-4ubuntu2
ii  libbrotli1   1.0.7-6ubuntu0.1
ii  libc62.31-0ubuntu9.2
ii  libcrypt11:4.4.10-10ubuntu4
ii  libcurl4 7.68.0-1ubuntu2.4
ii  libjansson4  2.12-1build1
ii  libldap-2.4-22.4.49+dfsg-2ubuntu1.7
ii  liblua5.2-0  5.2.4-1.1build3
ii  libnghttp2-141.40.0-1build1
ii  libpcre3 2:8.39-12build1
ii  libssl1.11.1.1f-1ubuntu2.2
ii  libxml2  2.9.10+dfsg-5
ii  perl 5.30.0-9ubuntu0.2
ii  zlib1g   1:1.2.11.dfsg-2ubuntu1.2

Versions of packages apache2-bin suggests:
pn  apache2-doc 
pn  apache2-suexec-pristine | apache2-suexec-c  
ii  chromium-browser [www-browser]  1:85.0.4183.83-0ubuntu0.20.04.2
ii  firefox [www-browser]   84.0.2+build1-0ubuntu0.20.04.1
ii  google-chrome-stable [www-browser]  88.0.4324.96-1
ii  links2 [www-browser]2.20.2-1
ii  lynx [www-browser]  2.9.0dev.5-1

Versions of packages apache2 is related to:
ii  apache2  2.4.41-4ubuntu3.1
ii  apache2-bin  2.4.41-4ubuntu3.1
>From 6ae8c18ed06dc19123c61616da55e6bb93b396bc Mon Sep 17 00:00:00 2001
From: Andreas Hasenack 
Date: Mon, 24 Aug 2020 18:18:55 -0300
Subject: [PATCH] - d/p/t/apache/expr_string.t: Avoid test suite failure
 due to timing   issue reading error log too quickly after request, by
 adding a sleep.   (LP #1890302)

---
 debian/perl-framework/t/apache/expr_string.t | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/perl-framework/t/apache/expr_string.t b/debian/perl-framework/t/apache/expr_string.t
index a9115eeec..66b09030d 100644
--- a/debian/perl-framework/t/apache/expr_string.t
+++ b/debian/perl-framework/t/apache/expr_string.t
@@ -7,6 +7,8 @@ use Apache::TestUtil qw(t_write_file t_start_error_log_watch t_finish_error_log_
 
 use File::Spec;
 
+use Time::HiRes qw(usleep);
+
 # test ap_expr
 
 Apache::TestRequest::user_agent(keep_alive => 1);
@@ -62,6 +64,8 @@ foreach my $t (@test_cases) {
'SomeHeader' => 'SomeValue',
'User-Agent' => 'SomeAgent',
'Referer'=> 'SomeReferer');
+### Sleep here, attempt to avoid intermittent failures. (LP: #1890302)
+usleep(25);
 my @loglines = t_finish_error_log_watch();
 
 my @evalerrors = grep {/(?:internal evaluation error|flex scanner jammed)/i
-- 
2.30.0

Bug#985013: python3-os-ken: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-os-ken
Version: 1.2.0-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-os-ken (1.2.0-2) ...
  /usr/lib/python3/dist-packages/os_ken/lib/packet/cfm.py:271: SyntaxWarning: 
"is not" with a literal. Did you mean "!="?
assert interval is not 0


Andreas

Bug#985011: golang-github-go-redis-redis: autopkgtest regression

2021-03-11 Thread Paul Gevers

Source: golang-github-go-redis-redis
Version: 6.15.0-1
User: debian...@lists.debian.org
Usertags: timeout regression
X-Debbugs-CC: debian...@lists.debian.org

Dear maintainer,

Your package has an autopkgtest, great! However, mid 2020 it started to
fail [1]. Can you please investigate and fix the situation?

Additionally, on amd64 it times out regularly. It seems to happen when
run on our worker13, which is a worker where we run multiple autopkgtest
instances on the same machine. Please do get in touch if we need to dive
into this together.

To avoid needlessly stress our infrastructure, I'll block this
package on amd64 until this bug is fixed.

Paul

[1]
https://ci.debian.net/packages/g/golang-github-go-redis-redis/testing/amd64/

https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-github-go-redis-redis/10594973/log.gz

[91m[1mSummarizing 30 Failures:[0m

[91m[1m[Fail] [0m[90mRedis Ring [0m[91m[1m[It] distributes keys [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/ring_test.go:45[0m

[91m[1m[Fail] [0m[90mRedis Ring [0m[91m[1m[It] uses single shard
when one of the shards is down [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/ring_test.go:91[0m

[91m[1m[Fail] [0m[90mRedis Ring [0m[91m[1m[It] supports hash
tags [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/ring_test.go:100[0m

[91m[1m[Fail] [0m[90mRedis Ring [0m[0mpipeline [0m[91m[1m[It]
distributes keys [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/ring_test.go:122[0m

[91m[1m[Fail] [0m[90mRedis Ring [0m[0mpipeline [0m[91m[1m[It]
is consistent with ring [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/ring_test.go:145[0m

[91m[1m[Fail] [0m[90mRedis Ring [0m[0mpipeline [0m[91m[1m[It]
supports hash tags [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/ring_test.go:159[0m

[91m[1m[Fail] [0m[90mCommands [0m[0mserver [0m[91m[1m[It]
should Auth [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/commands_test.go:36[0m

[91m[1m[Fail] [0m[90mCommands [0m[0mserver [0m[91m[1m[It]
should Command [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/commands_test.go:247[0m

[91m[1m[Fail] [0m[90mCommands [0m[0mdebugging [0m[91m[1m[It]
should MemoryUsage [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/commands_test.go:293[0m

[91m[1m[Fail] [0m[90mClusterClient [0m[0mClusterClient
[0m[90mpipelining [0m[0mwith Pipeline [0m[91m[1m[It] follows
redirects [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/cluster_test.go:439[0m

[91m[1m[Fail] [0m[90mClusterClient [0m[0mClusterClient
[0m[90mpipelining [0m[0mwith TxPipeline [0m[91m[1m[It] follows
redirects [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/cluster_test.go:439[0m

[91m[1m[Fail] [0m[90mClusterClient [0m[0mClusterClient
failover [0m[90mpipelining [0m[0mwith Pipeline [0m[91m[1m[It]
follows redirects [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/cluster_test.go:439[0m

[91m[1m[Fail] [0m[90mClusterClient [0m[0mClusterClient
failover [0m[90mpipelining [0m[0mwith TxPipeline [0m[91m[1m[It]
follows redirects [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/cluster_test.go:439[0m

[91m[1m[Fail] [0m[90mClusterClient [0m[0mClusterClient with
RouteByLatency [0m[90mpipelining [0m[0mwith Pipeline
[0m[91m[1m[It] follows redirects [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/cluster_test.go:439[0m

[91m[1m[Fail] [0m[90mClusterClient [0m[0mClusterClient with
RouteByLatency [0m[90mpipelining [0m[0mwith TxPipeline
[0m[91m[1m[It] follows redirects [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/cluster_test.go:439[0m

[91m[1m[Fail] [0m[90mClusterClient [0m[0mClusterClient with
ClusterSlots [0m[91m[1m[It] should GET/SET/DEL [0m
[37m/tmp/autopkgtest-lxc.okzciie5/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/go-redis/redis/cluster_test.go:259[0m

[91m[1m[Fail] [0m[90mClusterClient [0m[0mClusterClient with
ClusterSlots [0m[91m[1m[It] SET follows

Bug#984917: feedgnuplot: dynamic plots (--stream) do not work

2021-03-11 Thread Detlev Zundel

Hi,

[...]

> I should have mentioned I only recently switched from GNOME on Xorg to
> GNOME on Wayland.  I hope it does not make a difference but I wanted to
> mention it.

Having written this paragraph I just reran the test once again and
noticed that the graph gets redrawn when I move the mouse on the desktop
so it enters and exits different windows.  At those moments in time, the
graph gets refreshed.  So I can get an updating graph by continuously
moving the mouse between my terminal window that I started the command
in and the gnuplot window.

With this in mind I switched back to GNOME on Xorg and sure enough
everything works as expected...

So the bug only shows in gnuplot under GNOME on Wayland.  It is
therefore likely a gnuplot bug instead of a problem in feedgnuplot.
Does this make sense?  Should I open a bug with gnuplot?

Thanks!
  Detlev

-- 
The 82558 B-step and later generation devices do not maintain a link
in D3 if PME is disabled or if the device does not have power.
-- Intel documentation

Bug#985010: python3-kazoo: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-kazoo
Version: 2.7.0-4
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-kazoo (2.7.0-4) ...
  /usr/lib/python3/dist-packages/kazoo/protocol/serialization.py:114: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
read_only = bool_struct.unpack_from(bytes, offset)[0] is 1
  /usr/lib/python3/dist-packages/kazoo/protocol/serialization.py:449: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
return cls(t, done is 1, err), offset


Andreas

Bug#984917: feedgnuplot: dynamic plots (--stream) do not work

2021-03-11 Thread Detlev Zundel

Hi Dima,

> Hi. Notes inline.

Thanks for your quick reply!

>> I cannot get dynamic plots to work on my system.
>
> OK. I suspect this is something on your end, but let's run some
> experiments.

I am 100% sure it is something on my end.  The question is if it is my
fault or reproducible on other machines as well ;)

>> while true; do sleep 1; cat /proc/net/dev; done |
>>  gawk '/enp6s0/ {if(b) {print $2-b; fflush()} b=$2}' |
>>  feedgnuplot --lines --stream --xlen 10 --ylabel 'Bytes/sec' --xlabel seconds
>>
>> This opens up a gnuplot window but it is not updating every second as
>> it should. The lower left corner seems to be showing a coordinate and
>> this indeed updates every second, but the plot itself does not. From
>> time to time the plot gets redrawn but then again stays fixed.
>
> I can think of several potential causes. First off, let's eliminate X
> issues. Can you please add '--terminal "dumb 80 40"' to the feedgnuplot
> command? If that works properly, you'll see an ascii plot printed onto
> your console every second. Do you see that?

Works like a charm.

>> Doing more diagnosing, I used the --dump switch to see what is being fed into
>> gnuplot and when I manually run gnuplot and paste the fragments into it, it
>> works just fine. It seems to be related with the fact that gnuplot reads the
>> input from the pipe.
>
> Right. The second theory is that it's something related to buffering.
> That command should handle it, but let's see. Try this:
>
> 1. apt install mawk
>
> 2. while true; do sleep 1; cat /proc/net/dev; done |
>  mawk -Winteractive '/enp6s0/ {if(b) {print $2-b} b=$2}' |
>  feedgnuplot --lines --stream --xlen 10 --ylabel 'Bytes/sec' --xlabel seconds 
> --terminal 'dumb 80 40'
>
> So use "mawk -Winteractive" instead of "gawk", and remove the fflush().
> Does that make any difference?

Nope.  Same behaviour.  Position in lower left corner updates, graph
does not.  Only one update after approximately 8 seconds then again
fixed.

>> Maybe this is related to the gnuplot version in Bullseye?
>
> Maybe, but I doubt it. Please run the two experiments above, and we can
> go from there.

I should have mentioned I only recently switched from GNOME on Xorg to
GNOME on Wayland.  I hope it does not make a difference but I wanted to
mention it.

Any other ideas?

Thanks in advance!
  Detlev

-- 
Any fool can write code that a computer can understand. Good
programmers write code that humans can understand.
-- Martin Fowler

Bug#985009: python3-paraview: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-paraview
Version: 5.9.0-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-paraview (5.9.0-2) ...
  /usr/lib/python3/dist-packages/vtkmodules/numpy_interface/algorithms.py:209: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
if max_dims is 1:


Andreas

Bug#985008: python3-sardana: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-sardana
Version: 3.0.3-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-sardana (3.0.3-1) ...
  /usr/lib/python3/dist-packages/sardana/macroserver/macros/lists.py:146: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
if nb is 0:
  /usr/lib/python3/dist-packages/sardana/tango/core/util.py:1209: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
if port is None or port is 0:
  
/usr/lib/python3/dist-packages/sardana/taurus/core/tango/sardana/macroserver.py:668:
 SyntaxWarning: "is" with a literal. Did you mean "=="?
if result['input'] is '' and 'default_value' in input_data:


Andreas

Bug#984882: unblock: debian-science/1.14.1

2021-03-11 Thread Andreas Tille

Control: tags -1 - moreinfo

Hi Graham,

On Thu, Mar 11, 2021 at 05:23:30PM +0200, Graham Inggs wrote:
> On Tue, 9 Mar 2021 at 19:03, Andreas Tille  wrote:
> >   [ ] attach debdiff against the package in testing
> >   (I do not see any reason for a debdiff of the autogenerated package)
> 
> Autogenerated or not, the debdiff is the thing we need to review, in
> order to answer your unblock request.

At your request I'm attaching a debdiff between the version in testing
(1.13) and unstable (1.14.1).  The only purpose of this upload that
should have happened before the freeze is that usually we need to update
the metapackages in deep freeze to reflect the package pool of the final
release.  It happens usually that we will loose packages due to RC bugs.
The main purpose of the 1.14.1 upload is to make *that* debdiff as
readable as possible.  I do not think that reading the attached debdiff
is very helpful but the chances to break anything are close to zero and
your perfectly understandable request for a debdiff can be sensibly
fulfilled with 1.14.2 (to be uploaded after the package pool has
stabilised and will contain those scientific packages that will be part
of the release).  This is the established procedure over several
releases.

Kind regards and thanks for your work for the release team

Andreas. 

-- 
http://fam-tille.de

debian-science_1.13-1.14.1.debdiff.gz
Description: application/gzip

Bug#985007: python3-tango: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-tango
Version: 9.2.5-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-tango (9.3.2-1+b1) ...
  /usr/lib/python3/dist-packages/tango/pytango_pprint.py:54: SyntaxWarning: 
"is" with a literal. Did you mean "=="?
if param_name is 'data_type':


Andreas

Bug#945506: Bug#984862: dkms now exports CC=

2021-03-11 Thread Axel Beckert

Hi Andreas,

Andreas Beckmann wrote:
> I've just added a patch to dkms to export the kernel compiler used for the
> headers as CC and the module build system automatically picks it up and
> therefore uses the "correct" compiler for the module.
> I'll attempt to get this unblocked for bullseye.

Thanks! Much appreciated!

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

Bug#985006: python3-overpass: SyntaxWarning during package installation

2021-03-11 Thread Andreas Beckmann

Package: python3-overpass
Version: 0.7-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package emits a SyntaxWarning
during installation:

  Setting up python3-overpass (0.7-1) ...
  /usr/lib/python3/dist-packages/overpass/api.py:126: SyntaxWarning: "is not" 
with a literal. Did you mean "!="?
if responseformat is not "geojson":


Andreas

Bug#985005: unblock: dkms/2.8.4-3

2021-03-11 Thread Andreas Beckmann

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

Please unblock package dkms

I've just added a patch to dkms that exports the compiler used by the
kernel headers (i.e. some gcc-X) as CC for usage by non-Kbuild module
build systems which would otherwise attempt to use CC=gcc. That usually
fails due to gcc not being available (the kernel headers only depend on
gcc-X) unless build-essential is installed.
This fixes three RC bugs in -dkms packages (which I've now downgraded to
important, assuming the improved dkms reaches bullseye):
#945506, #946497, #984862

I've tested this by rechecking all *-dkms packages in my local piuparts
instance which attempts to build the module for linux-headers-amd64.
There were no regressions, but three more modules building sucessfully.

unblock dkms/2.8.4-3
diff --git a/debian/changelog b/debian/changelog
index 1743dcc..dfa7594 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+dkms (2.8.4-3) unstable; urgency=medium
+
+  [ Gianfranco Costamagna ]
+  * Team upload.
+
+  [ Andreas Beckmann ]
+  * Export the CC variable from .kernelvariables in the kernel source to allow
+module build systems use the kernel's compiler also outside of Kbuild.
+(Closes: #984929)
+
+ -- Andreas Beckmann   Wed, 10 Mar 2021 12:11:42 +0100
+
 dkms (2.8.4-2) unstable; urgency=medium
 
   [ Gianfranco Costamagna ]
diff --git a/debian/patches/export-CC.patch b/debian/patches/export-CC.patch
new file mode 100644
index 000..1ae7e70
--- /dev/null
+++ b/debian/patches/export-CC.patch
@@ -0,0 +1,20 @@
+Description: export CC pointing to the kernel's compiler
+ export the CC variable from .kernelvariables in the kernel source to allow
+ module build systems use the kernel's compiler also outside of Kbuild
+Author: Andreas Beckmann 
+
+--- dkms-2.8.4.orig/dkms
 dkms-2.8.4/dkms
+@@ -1166,6 +1166,12 @@ prepare_kernel()
+ esac
+ }
+ 
++if [ -f "$kernel_source_dir/.kernelvariables" ]; then
++export CC=$(echo -e "show-%:\n\t@echo \$(\$*)\ninclude 
$kernel_source_dir/.kernelvariables" | make -f - show-CC)
++else
++unset CC
++fi
++
+ [[ $no_prepare_kernel ]] && return
+ 
+ if [[ (! ( $(VER $1) < $(VER 2.6.5) ) || -d /etc/SuSEconfig) && \
diff --git a/debian/patches/series b/debian/patches/series
index f3c2a3b..aa7de72 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 do-not-load-modules.patch
+export-CC.patch

Bug#984997: [debian-mysql] Bug#984997: mariadb-server-10.5: database password passed in cleartext both on commandline and in environment

2021-03-11 Thread Otto Kekäläinen

Hello!

Thanks for looking into this and reporting it. Could you be a bit more
specific what the context is, who can view the command? How do you
suggest the password would be passed?

I added a couple Galera developers as this script is not maintained in
Debian, but inherited from upstream Galera project.


On Thu, 11 Mar 2021 at 19:48, Marc Lehmann  wrote:
>
> Package: mariadb-server-10.5
> Version: 1:10.5.9-1
> Severity: normal
>
> Dear Maintainer,
>
> I had a look at /usr/bin/wsrep_sst_mariabackup, after being a bit
> suspicious on how mariadb executes mariabackup for wsrep replication.
>
> I found that the database password is passed in *cleartext* both on the
> command line and via the environment.
>
> Neither of these are suitable places for a secret, as both can usually
> easily be queried by nonprivileged users.
>
>* What outcome did you expect instead?
>
> Secrets should never be passwd on the commandline or in the environment.
>
> -- System Information:
> Debian Release: 10.8
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 
> 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 
> 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, x32
>
> Kernel: Linux 5.8.18-050818-generic (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages mariadb-server-10.5 depends on:
> ii  adduser   3.118
> ii  debconf [debconf-2.0] 1.5.71
> pn  galera-4  
> ii  gawk  1:4.2.1+dfsg-1
> ii  iproute2  5.10.0-4
> ii  libc6 2.30-4
> ii  libdbi-perl   1.642-1+deb10u2
> ii  libpam0g  1.3.1-5
> ii  libssl1.1 1.1.1d-0+deb10u2
> ii  libstdc++610.2.1-6
> ii  lsb-base  11.1.0
> ii  lsof  4.91+dfsg-1
> pn  mariadb-client-10.5   
> ii  mariadb-common1:10.3.27-0+deb10u1
> pn  mariadb-server-core-10.5  
> ii  passwd1:4.5-1.1
> ii  perl  5.28.1-6+deb10u1
> ii  procps2:3.3.15-2
> ii  psmisc23.2-1
> ii  rsync 3.2.3-4
> ii  socat 1.7.3.2-2
> ii  zlib1g1:1.2.11.dfsg-1
>
> Versions of packages mariadb-server-10.5 recommends:
> ii  libhtml-template-perl  2.97-1
>
> Versions of packages mariadb-server-10.5 suggests:
> ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1
> ii  mailutils [mailx]  1:3.5-4
> pn  mariadb-test   
> ii  netcat-openbsd 1.195-2
>
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mysql-maint



-- 
- Otto

Bug#985004: gemma: flaky armhf autopkgtest: regularly times out after 2:47 h

2021-03-11 Thread Paul Gevers

Source: gemma
Version: 0.98.3+dfsg-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, I looked into
the history of your autopkgtest [1,2] and I noticed it fails regularly
on armhf, while sporadically a rerun passes. I copied some of the output
at the bottom of this report.

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

Paul

[1] https://ci.debian.net/packages/g/gemma/testing/armhf/
[2] https://ci.debian.net/packages/g/gemma/unstable/armhf/

https://ci.debian.net/data/autopkgtest/testing/armhf/g/gemma/10238800/log.gz

https://ci.debian.net/data/autopkgtest/testing/armhf/g/gemma/10042898/log.gz

autopkgtest [20:25:33]: test run-sample-analysis: [---
GEMMA 0.98.3 (2020-11-28) by Xiang Zhou and team (C) 2012-2020
Reading Files ...
## number of total individuals = 1940
## number of analyzed individuals = 1410
## number of covariates = 1
## number of phenotypes = 1
## number of total SNPs/var=12226
## number of analyzed SNPs =10768
Calculating Relatedness Matrix ...
   0%
   8%
   16%
   25%
   33%
   41%
   49%
   57%
   65%
   74%
   82%
   90%
=  98%
== 100%
 INFO: Done.
GEMMA 0.98.3 (2020-11-28) by Xiang Zhou and team (C) 2012-2020
Reading Files ...
## number of total individuals = 1940
## number of analyzed individuals = 1410
## number of covariates = 1
## number of phenotypes = 1
## number of total SNPs/var=12226
## number of analyzed SNPs =10768
Start Eigen-Decomposition...
pve estimate =0.608801
se(pve) =0.032774
   0%
   8%
   16%
   25%
   33%
   41%
   49%
   57%
   65%
   74%
   82%
   90%
=  98%
== 100%
== 100%
 INFO: Done.
GEMMA 0.98.3 (2020-11-28) by Xiang Zhou and team (C) 2012-2020
Reading Files ...
## number of total individuals = 1940
## number of analyzed individuals = 1197
## number of covariates = 1
## number of phenotypes = 2
## number of total SNPs/var=12226
## number of analyzed SNPs =10758
Start Eigen-Decomposition...
REMLE estimate for Vg in the null model:
1.3940  
-0.2267 2.0817  
se(Vg):
0.1567  
0.1363  0.2359  
REMLE estimate for Ve in the null model:
0.3489  
0.0491  0.4144  
se(Ve):
0.0206  
0.0166  0.0267  
REMLE likelihood = -2855.1664
MLE estimate for Vg in the null model:
1.3959  
-0.2267 2.0854  
se(Vg):
0.1568  
0.1365  0.2361  
MLE estimate for Ve in the null model:
0.3483  
0.0490  0.4136  
se(Ve):
0.0206  
0.0166  0.0266  
MLE likelihood = -2856.0280
   0%
   8%
   16%
   25%
   33%
   41%
   49%
   57%
   65%
   74%
   82%
   90%
=  98%
== 100%
 INFO: Done.
GEMMA

Bug#945506: dkms now exports CC=

2021-03-11 Thread Andreas Beckmann


Control: severity -1 important

I've just added a patch to dkms to export the kernel compiler used for 
the headers as CC and the module build system automatically picks it up 
and therefore uses the "correct" compiler for the module.

I'll attempt to get this unblocked for bullseye.

Therefore please *do not add Depends: gcc* as I suggested previously.

You might consider bumping the dkms dependency to
  dkms (>= 2.8.4-3~)
but that change alone is not worth an upload/unblock cycle.

Andreas

Bug#985003: shellcheck: –list-optional: openBinaryFile: does not exist (No such file or directory)

2021-03-11 Thread Thorsten Glaser

Package: shellcheck
Version: 0.7.1-1
Severity: important
X-Debbugs-Cc: t...@mirbsd.de

$ shellcheck –list-optional
–list-optional: –list-optional: openBinaryFile: does not exist (No such file or 
directory)

This was copy/paste from the manual page:

   –list-optional
  Output  a  list  of known optional checks.  These can be enabled
  with -o flags or enable directives.

Incidentally, the leading dash is U+2013, not a hyphen-minus.
Typing this myself doesn’t make it work though…

$ shellcheck -list-optional
unrecognized option `-l'

Usage: shellcheck [OPTIONS...] FILES...
  -a  --check-sourcedInclude warnings from sourced 
files
  -C[WHEN]--color[=WHEN] Use color (auto, always, never)
  -i CODE1,CODE2..--include=CODE1,CODE2..Consider only given types of 
warnings
  -e CODE1,CODE2..--exclude=CODE1,CODE2..Exclude types of warnings
  -f FORMAT   --format=FORMATOutput format (checkstyle, 
diff, gcc, json, json1, quiet, tty)
  --list-optionalList checks disabled by default
  --norc Don't look for .shellcheckrc 
files
  -o check1,check2..  --enable=check1,check2..   List of optional checks to 
enable (or 'all')
  -P SOURCEPATHS  --source-path=SOURCEPATHS  Specify path when looking for 
sourced files ("SCRIPTDIR" for script's dir)
  -s SHELLNAME--shell=SHELLNAME  Specify dialect (sh, bash, 
dash, ksh)
  -S SEVERITY --severity=SEVERITYMinimum severity of errors to 
consider (error, warning, info, style)
  -V  --version  Print version information
  -W NUM  --wiki-link-count=NUM  The number of wiki links to 
show, when applicable
  -x  --external-sources Allow 'source' outside of FILES
  --help Show this usage summary and 
exit




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

Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages shellcheck depends on:
ii  libatomic1  10.2.1-6
ii  libc6   2.31-9
ii  libffi7 3.3-6
ii  libgmp102:6.2.1+dfsg-1

shellcheck recommends no packages.

shellcheck suggests no packages.

-- no debconf information

Bug#984996: [debian-mysql] Bug#984996: mariadb-server-core-10.5: modifies globalö environment, causing race conditions

2021-03-11 Thread Otto Kekäläinen

Hello!

Thanks for reviewing the systemd scripts in MariaDB. I added a couple
of MariaDB devs as the systemd service files are not maintained in
Debian but inherited from upstream MariaDB.

On Thu, 11 Mar 2021 at 19:42, Marc Lehmann  wrote:
>
> Package: mariadb-server-core-10.5
> Version: 1:10.5.9-1
> Severity: normal
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> various scripts (e.g. galera_new_cluster) and the systemd.unit modify the
> global/systemwide environment, e.g. with variables _WSREP_START_POSITION.
>
> This has the effect of polluting the environment of other sservices with
> these variables, which is usually pretty harmless.
>
> However, if there are multiple server instances then this creates a race
> condition where starting/stopping one server or bootstrapping one cluster
> will interfere with the other instance,s which could easily lead to
> database corruption.
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> I didn't try to solve the problem, it seems to be too fundamental to
> easily work around. The mechanism (systemd environment block) is wholly
> unsuitable to solve this problem.
>
>* What was the outcome of this action?
>
> Environment polluted, critical environment variables of other services
> erased/modified.
>
>* What outcome did you expect instead?
>
> A systemd service should _never_ _ever_ modify the global environment.
>
>
> -- System Information:
> Debian Release: 10.8
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 
> 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 
> 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, x32
>
> Kernel: Linux 5.8.18-050818-generic (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mysql-maint



-- 
- Otto

Bug#948277: Certbot wiki suggests using main repo instead of backport repo for Stretch

2021-03-11 Thread Bastian Stassen

https://wiki.debian.org/LetsEncrypt 
says:

Stretch (Debian 9.x) / Buster (Debian 10.x) / Testing / Unstable Howto:

You can install certbot from the main repository.



So maybe we should now remove the backport repo from apt-get sources and try to 
upgrade certbot?


Bart

Bug#913531: Recheck

2021-03-11 Thread Joachim Falk

Heads up, this is still present in Debian bullseye with gdm3 version 3.38.2.1-1.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985002: nfs-common: Degraded system state if nfs-common installed and /etc/krb5.keytab present

2021-03-11 Thread Joachim Falk

Package: nfs-common
Version: 1:1.3.4-4
Severity: normal
Tags: patch
X-Debbugs-Cc: felix.lech...@lease-up.com

The nfs-client.target requires the auth-rpcgss-module.service, which in
turn requires rpc-svcgssd.service. However, the rpc.svcgssd daemon is
not needed for an NFS client, even when using Kerberos security.
Moreover, starting this daemon with its default configuration will fail
when no nfs/@REALM principal is in the kerberos keytab. Thus,
resulting in a degraded system state for NFS client configurations
without nfs/@REALM principal in the kerberos keytab. However, this
is a perfectly valid NFS client configuration as the nfs/@REALM
principal is not required for mounting NFS file systems. This is even
the case when Kerberos security is enabled for the mount!

Note that installing the gssproxy packed hides this problem as this
disables the rpc-svcgssd.service.

-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
-- /etc/default/nfs-common --
SMNOTIFYARGS=""
RPCIDMAPDARGS=""
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=
NEED_GSSD=
RPCGSSDOPTS=
-- /etc/idmapd.conf --
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
Domain = jfalk.de
Local-Realms = JFAD.JFALK.DE
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
-- /etc/fstab --
nfs.jfalk.de:/home  /home   nfs4
sec=krb5p,nodev,nosuid,noatime,async0   0
nfs.jfalk.de:/local /local  nfs4
sec=krb5p,nodev,nosuid,noatime,async0   0
nfs.jfalk.de:/opt   /optnfs4
sec=krb5p,nodev,nosuid,noatime,async0   0
# the auto mounter map /etc/auto.nfs handles these
#nfs.jfalk.de:/bulk-data/bulk-data  nfs4
sec=krb5p,nodev,nosuid,noatime,async0   0
-- /proc/mounts --
nfs.jfalk.de:/local /local nfs4 
rw,nosuid,nodev,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5p,clientaddr=192.168.192.128,local_lock=none,addr=192.168.194.37
 0 0
nfs.jfalk.de:/opt /opt nfs4 
rw,nosuid,nodev,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5p,clientaddr=192.168.192.128,local_lock=none,addr=192.168.194.37
 0 0
nfs.jfalk.de:/home /home nfs4 
rw,nosuid,nodev,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5p,clientaddr=192.168.192.128,local_lock=none,addr=192.168.194.37
 0 0
/etc/auto.nfs /var/autofs/nfs autofs 
rw,relatime,fd=6,pgrp=1106,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=12280
 0 0

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

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

Versions of packages nfs-common depends on:
ii  adduser 3.118
ii  keyutils1.6.1-2
ii  libc6   2.31-9
ii  libcap2 1:2.44-1
ii  libcom-err2 1.46.1-1
ii  libdevmapper1.02.1  2:1.02.175-2.1
ii  libevent-2.1-7  2.1.12-stable-1
ii  libgssapi-krb5-21.18.3-4
ii  libkeyutils11.6.1-2
ii  libkrb5-3   1.18.3-4
ii  libmount1   2.36.1-7
ii  libnfsidmap20.25-6
ii  libtirpc3   1.3.1-1
ii  libwrap07.6.q-31
ii  lsb-base11.1.0
ii  rpcbind 1.2.5-9
ii  ucf 3.0043

Versions of packages nfs-common recommends:
pn  python  

Versions of packages nfs-common suggests:
pn  open-iscsi  
pn  watchdog

-- Configuration Files:
/etc/default/nfs-common changed:
SMNOTIFYARGS=""
RPCIDMAPDARGS=""
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=
NEED_GSSD=
RPCGSSDOPTS=


-- no debconf information
Description: The rpc.svcgssd daemon is not needed for an NFS client, even
 when using Kerberos security. Moreover, starting this daemon with its
 default configuration will fail when no nfs/@REALM principal is in
 the krb5.keytab. Furthermore, the nfs/@REALM principal is unneeded
 for an NFS client configuration. Thus, resulting in a degraded system
 state for NFS client configurations without nfs/@REALM principal
 in the krb5.keytab.
Author: Joachim Falk 

Index: pkg-nfs-utils/systemd/auth-rpcgss-module.service
===
--- pkg-nfs-utils.orig/systemd/auth-rpcgss-module.service   2020-09-04 
10:04:07.018816047 +0200
+++ pkg-nfs-utils/systemd/auth-rpcgss-module.service2020-09-04 
10:04:25.586617690 +0200
@@ -8,7 +8,7 @@
 Description=Kernel Module

Bug#984931: git-el,elpa-magit: fails to install: /usr/lib/emacsen-common/packages/install/git emacs failed at /usr/lib/emacsen-common/lib.pl line 19, line 7.

2021-03-11 Thread David Bremner

David Bremner  writes:

>
> As far as I can see, the problem is that the setup for elpa-magit and
> git-el both call "emacs", but that does not exist until the
> update-alternatives is called. So there seems to be a race condition
> here where emacs-gtk (or whatever is providing /usr/bin/emacs) needs to
> run its postinst before any add-on package wanting to do byte
> compilation.
>
> Somewhat to my surprise I could duplicate this failure with
>
>  $ sudo schroot -r -c test apt install git-el elpa-magit
>
> where test is an up to date sid chroot.

Another thing I noticed is that git-el does not depend on emacsen-common

per [1] (5), I think it should. I don't know if this has any practical
impact.

d

Bug#985001: ITP: ipytree -- a tree widget using Jupyter-widget protocol and jsTree

2021-03-11 Thread Emmanuel Arias

Package: wnpp
Severity: wishlist
Owner: Emmanuel Arias 
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name    : ipytree
  Version         : 0.2.1
  Upstream Author : Martin Renou 
* URL             : https://github.com/QuantStack/ipytree
* License         : MIT
  Programming Lang: Python
  Description     : a Tree Widget using Jupyter-widgets protocol and jsTree

Widget that allow create trees for visualization on Jupyter. This
package use Jupyter-widgets protocol and jsTree.
.
This package is need to fix #979625.
.
This package will be maintained as part of the Debian Python modules team.

Cheers,
Emmanuel

Bug#983610: zint: CVE-2021-27799

2021-03-11 Thread Gunnar Wolf

tags -1 + patch,pending
user debian-rele...@lists.debian.org
usertags -1 + bsp-2021-03-latinoamerica
thank you

Hi,

I have prepared this patch and will be performing an upload targetted
at delayed/7-day.

Dmitry, please do take a look at my proposed patch. I backported the
commit I'm quoting in it, which applied quite imperfectly; I am
basically sure the code I applied is correct (but extra eyes will
never hurt!), but I left out the patch for
backend/tests/test_upcean.c, as the version we are shipping is very
much behind (the patched functions don't even exist).

Greetings,
Last-Update: 2021-03-11
Origin: https://sourceforge.net/p/zint/code/ci/7f8c8114f31c09a986597e0ba63a49f96150368a/
Forwarded: not-needed
Author: Gunnar Wolf 
Description: Fix a buffer overflow in ean_laeding_zeroes
 This vulnerability is tracked as CVE-2021-27799. The patch was backported
 from the devel git tree.

Index: zint-2.9.1/backend/composite.c
===
--- zint-2.9.1.orig/backend/composite.c
+++ zint-2.9.1/backend/composite.c
@@ -65,7 +65,7 @@
 
 INTERNAL int eanx(struct zint_symbol *symbol, unsigned char source[], int length);
 INTERNAL int ean_128(struct zint_symbol *symbol, unsigned char source[], const size_t length);
-INTERNAL void ean_leading_zeroes(struct zint_symbol *symbol, unsigned char source[], unsigned char local_source[]);
+INTERNAL int ean_leading_zeroes(struct zint_symbol *symbol, unsigned char source[], unsigned char local_source[]);
 INTERNAL int rss14(struct zint_symbol *symbol, unsigned char source[], int length);
 INTERNAL int rsslimited(struct zint_symbol *symbol, unsigned char source[], int length);
 INTERNAL int rssexpanded(struct zint_symbol *symbol, unsigned char source[], int length);
@@ -1422,7 +1422,10 @@ INTERNAL int composite(struct zint_symbo
 int padded_pri_len;
 char padded_pri[20];
 padded_pri[0] = '\0';
-ean_leading_zeroes(symbol, (unsigned char *) symbol->primary, (unsigned char *) padded_pri);
+if (!ean_leading_zeroes(symbol, (unsigned char *) symbol->primary, (unsigned char *) padded_pri)) {
+		strcpy(symbol->errtxt, "448: Input wrong length in linear component");
+		return ZINT_ERROR_TOO_LONG;
+		}
 padded_pri_len = strlen(padded_pri);
 if (padded_pri_len <= 7) { /* EAN-8 */
 cc_width = 3;
Index: zint-2.9.1/backend/upcean.c
===
--- zint-2.9.1.orig/backend/upcean.c
+++ zint-2.9.1/backend/upcean.c
@@ -125,7 +125,7 @@ static void upca_draw(char source[], cha
 /* Make a UPC A barcode when we haven't been given the check digit */
 static int upca(struct zint_symbol *symbol, unsigned char source[], char dest[]) {
 int length;
-char gtin[15];
+char gtin[13];
 
 strcpy(gtin, (char*) source);
 length = strlen(gtin);
@@ -391,7 +391,7 @@ static char ean_check(char source[]) {
 static int ean13(struct zint_symbol *symbol, unsigned char source[], char dest[]) {
 unsigned int length, i, half_way;
 char parity[6];
-char gtin[15];
+char gtin[14];
 
 strcpy(parity, "");
 strcpy(gtin, (char*) source);
@@ -569,8 +569,9 @@ static int isbn(struct zint_symbol *symb
 }
 
 /* Add leading zeroes to EAN and UPC strings */
-INTERNAL void ean_leading_zeroes(struct zint_symbol *symbol, unsigned char source[], unsigned char local_source[]) {
-unsigned char first_part[20], second_part[20], zfirst_part[20], zsecond_part[20];
+INTERNAL int ean_leading_zeroes(struct zint_symbol *symbol, unsigned char source[],
+	unsigned char local_source[], int *p_with_addon) {
+unsigned char first_part[14], second_part[6], zfirst_part[14], zsecond_part[6];
 int with_addon = 0;
 int first_len = 0, second_len = 0, zfirst_len = 0, zsecond_len = 0, i, h;
 
@@ -592,15 +593,16 @@ INTERNAL void ean_leading_zeroes(struct
 ustrcpy(zfirst_part, (unsigned char *) "");
 ustrcpy(zsecond_part, (unsigned char *) "");
 
+if (first_len > 13 || second_len > 5) {
+return 0;
+}
+
 /* Split input into two strings */
 for (i = 0; i < first_len; i++) {
 first_part[i] = source[i];
 first_part[i + 1] = '\0';
 }
 
-if (second_len >= 6) { /* Allow 6 (actual max 5) so as to trigger too long error */
-second_len = 6;
-}
 for (i = 0; i < second_len; i++) {
 second_part[i] = source[i + first_len + 1];
 second_part[i + 1] = '\0';
@@ -698,12 +700,13 @@ INTERNAL void ean_leading_zeroes(struct
 strcat((char*) local_source, "+");
 strcat((char*) local_source, (char*) zsecond_part);
 }
+
+return 1; /* Success */
 }
 
-/* splits string to parts before and after '+' parts */
 INTERNAL int eanx(struct zint_symbol *symbol, unsigned char source[], int src_len) {
-unsigned char first_part[20] = {0}, second_part[7] = {0}, dest[1000] = {0};
-

Bug#890834: gtk+2.0: Add build profiles to skip flavors and packages

2021-03-11 Thread Javier Serrano Polo

Control: tags -1 - moreinfo

More information was provided.

smime.p7s
Description: S/MIME cryptographic signature

Bug#890556: aptitude: Add build profile to skip documentation packages

2021-03-11 Thread Javier Serrano Polo

Control: tags -1 - moreinfo

More information was provided.

smime.p7s
Description: S/MIME cryptographic signature

Bug#985000: nfs-common: auth-rpcgss-module.service fails inside Linux containers (LXC)

2021-03-11 Thread Joachim Falk

Package: nfs-common
Version: 1:1.3.4-5
Severity: important
Tags: patch
X-Debbugs-Cc: joachim.f...@gmx.de, felix.lech...@lease-up.com

To fix this problem, the auth_rpcgss kernel module must only be loaded
if it is not already loaded. Otherwise, the auth-rpcgss-module service
will fail inside a Linux container as the loading of kernel modules is
forbidden for the container. Thus, the "/sbin/modprobe -q auth_rpcgss"
call will fail even if the auth_rpcgss kernel module was already loaded.
This has been testesd with kmod up to version 28-1 (current in bullseye
as of 2021-03-11). This situation occurs when the container host already
loaded the auth_rpcgss kernel module to enable kerberized NFS service
for its containers.

-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
151   udp  40401  mountd
151   tcp  58455  mountd
152   udp  49124  mountd
152   tcp  60609  mountd
153   udp  47861  mountd
153   tcp  51113  mountd
133   tcp   2049  nfs
134   tcp   2049  nfs
1002273   tcp   2049
133   udp   2049  nfs
1002273   udp   2049
1000211   udp  47640  nlockmgr
1000213   udp  47640  nlockmgr
1000214   udp  47640  nlockmgr
1000211   tcp  33781  nlockmgr
1000213   tcp  33781  nlockmgr
1000214   tcp  33781  nlockmgr
-- /etc/default/nfs-common --
SMNOTIFYARGS=""
RPCIDMAPDARGS=""
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=
NEED_GSSD=
RPCGSSDOPTS=
-- /etc/idmapd.conf --
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
Domain = jfalk.de
Local-Realms = JFAD.JFALK.DE
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
-- /etc/fstab --
nfs.jfalk.de:/home  /home   nfs4
sec=krb5p,nodev,nosuid,noatime,async0   0
nfs.jfalk.de:/local /local  nfs4
sec=krb5p,nodev,nosuid,noatime,async0   0
nfs.jfalk.de:/opt   /optnfs4
sec=krb5p,nodev,nosuid,noatime,async0   0
nfs.jfalk.de:/bulk-data /bulk-data  nfs4
sec=krb5p,nodev,nosuid,noatime,async0   0

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

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

Versions of packages nfs-common depends on:
ii  adduser 3.118
ii  keyutils1.6.1-2
ii  libc6   2.31-9
ii  libcap2 1:2.44-1
ii  libcom-err2 1.46.1-1
ii  libdevmapper1.02.1  2:1.02.175-2.1
ii  libevent-2.1-7  2.1.12-stable-1
ii  libgssapi-krb5-21.18.3-4
ii  libkeyutils11.6.1-2
ii  libkrb5-3   1.18.3-4
ii  libmount1   2.36.1-7
ii  libnfsidmap20.25-6
ii  libtirpc3   1.3.1-1
ii  libwrap07.6.q-31
ii  lsb-base11.1.0
ii  rpcbind 1.2.5-9
ii  ucf 3.0043

Versions of packages nfs-common recommends:
pn  python  

Versions of packages nfs-common suggests:
pn  open-iscsi  
pn  watchdog

Versions of packages nfs-kernel-server depends on:
ii  keyutils  1.6.1-2
ii  libblkid1 2.36.1-7
ii  libc6 2.31-9
ii  libcap2   1:2.44-1
ii  libsqlite3-0  3.34.1-3
ii  libtirpc3 1.3.1-1
ii  libwrap0  7.6.q-31
ii  lsb-base  11.1.0
ii  netbase   6.2
ii  ucf   3.0043

-- no debconf information
Description: Only try to load the auth_rpcgss kernel module if it is not
 already loaded. Otherwise, the auth-rpcgss-module service might fail inside a
 Linux container where the loading of kernel modules is forbidden for the
 container. In this case, the "/sbin/modprobe -q auth_rpcgss" call will fail
 even if the auth_rpcgss kernel module was already loaded. This has been testesd
 with kmod up to version 27+20200310-2. This situation occurs when the container
 host already loaded the auth_rpcgss kernel module to enable kerberized NFS
 service for its containers.
Author: Joachim Falk 

--- a/systemd/auth-rpcgss-module.service.orig   2020-08-26 19:17:27.761451866 
+0200
+++ b/systemd/auth-rpcgss-module.service2020-08-26 19:18:16.988795354 
+0200
@@ -13,4 +13,4 @@

 [Service]
 Type=oneshot
-ExecStart=/sbin/modprobe -q auth_rpcgss
+ExecStart=/bin/sh -c '( /sbin/lsmod | grep -q "^auth_rpcgss\\>" ) || 
/sbin/modprobe -q auth_rpcgss'
Description: Only try to load the auth_rpcgss kernel module if it is not
 already loaded. Otherwise, the auth-rpcgss-module service

Bug#984999: sso.debian.org is deprecated

2021-03-11 Thread Antoine Beaupre

Package: tracker.debian.org
Severity: normal

According to the sso.debian.org wiki page, the service is
"deprecated":

> If you are a service admin please look into using Salsa for this
> purpose. 

It seems to me that tracker.debian.org should follow this deprecation
and stop using sso.debian.org as a single sign on source, especially
now that Firefox in stable (78, buster) does not support the 
tag (dropped from Firefox 69) which makes enrolling client certs
particularly painful.

For those who want the gory history of that removal:

https://bugzilla.mozilla.org/show_bug.cgi?id=1315460

Apparently, you can still generate client-sides certs with "web
crypto", whatever that means... But that's kind of out of scope here. 

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

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

Bug#984998: apt-cacher-ng.service suggestions to appease "systemd-analyze security"

2021-03-11 Thread Trent W. Buck

Package: apt-cacher-ng
Version: 3.6.3-1
Severity: wishlist

The attached /etc/systemd/service/apt-cacher-ng.service.d/override.conf
makes "systemd-analyze security" change from a frowny face to a smiley face.
(I think it's also supposed to improve security hardening, but I can only vouch 
for the smiley face.)

I took my usual strategy of "block everything, then unblock things until stuff 
works again".
My "is it working" tests were:

* systemctl start apt-cacher-ng
* apt update (using acng as proxy)
* mmdebstrap (using acng as proxy)
* browse to http://localhost:3142/acng-report.html?doCount=Count+Data#stats
* all the above with an empty /var/cache/apt-cacher-ng

I ran a similar override on buster for 12 months with no OBVIOUS issues, but
it probably needs more testing before pushing it out to everybody.
(i.e. before copy-pasting override.conf into systemd/apt-cacher-ng.service.in)


As a specific example of "more real-world testing needed",
I found with other daemons it's a real pain to call sendmail(8) or mail(1).
Here are some workarounds I came up with on buster for specific MTAs:


https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/blob/main/systemd/system/0-EXAMPLES/30-allow-mail-msmtp.conf

https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/blob/main/systemd/system/0-EXAMPLES/30-allow-mail-postfix-non-root-addgroup.conf

https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/blob/main/systemd/system/0-EXAMPLES/30-allow-mail-postfix-non-root-dac-override.conf

https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/blob/main/systemd/system/0-EXAMPLES/30-allow-mail-postfix-non-root-setgid.conf

https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/blob/main/systemd/system/0-EXAMPLES/30-allow-mail-postfix-root-dac-override.conf

https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/blob/main/systemd/system/0-EXAMPLES/30-allow-mail-postfix-root-sys-admin.conf

https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/blob/main/systemd/system/0-EXAMPLES/30-allow-mail-postfix-via-msmtp.conf

I *think* acng only sends mail in troublefaq.html, so
it might be sufficient for troublefaq.html to say
"you might need to comment out systemd security options while debugging".


PS: for comparison, a daemon that is sucessfully using this stuff is mariadb,
as an alternative to the mysqld_safe wrapper.

https://mariadb.com/kb/en/systemd/

UNITEXPOSURE PREDICATE HAPPY
mariadb.service  5.6 MEDIUM
apt-cacher-ng.service9.2 UNSAFE  (current state)
apt-cacher-ng.service1.1 OK  (with my 
probably-too-strict override.conf)



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

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
# Appease "systemd-analyze security" as at v247
[Service]
CapabilityBoundingSet=
RestrictNamespaces=yes
# FIXME: blocking AF_NETLINK causes this warning:
#   [warn] Unable to call getifaddrs(): Address family not supported by protocol
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK
DevicePolicy=closed
DeviceAllow=
NoNewPrivileges=yes
PrivateDevices=yes
PrivateMounts=yes
PrivateTmp=yes
PrivateUsers=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectProc=invisible
ProtectSystem=strict
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
SystemCallFilter=~@privileged @resources
RestrictRealtime=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
RemoveIPC=yes
UMask=0077
ProtectHostname=yes
ProcSubset=pid

# apt-cacher-ng has a control socket in /run that /etc/cron.daily/apt-cacher-ng 
talks to.
# Have systemd create the parent directory, so that we can confine the daemon 
from doing so.
RuntimeDirectory=apt-cacher-ng
WorkingDirectory=/run/apt-cacher-ng
# Let apt-cacher-ng maintain its download cache, and create logs.
ReadWritePaths=-/var/cache/apt-cacher-ng /var/log/apt-cacher-ng

Bug#984981: arcanist: non-functional bash-completion script

2021-03-11 Thread Kevin Locke

On Thu, 2021-03-11 at 07:31 -0700, Kevin Locke wrote:
> arcanist installs a bash-completion script at
> /usr/share/bash-completion/completions/arcanist.bash-completion
> which will not be loaded by bash-completion [...]

I just realized that arcanist previously installed a functional
completion script as /etc/bash_completion.d/arcanist.bash-completion.
(Which was loaded because all scripts in /etc/bash_completion.d are
eagerly loaded.)  It looks like that script was replaced with the
non-functional one in
https://github.com/phacility/arcanist/commit/acf060768340ba057e1acd5e8950dea41dc2b19e
Installing the previous version as 
/usr/share/bash-completion/completions/arcanist might work well.

Thanks for considering,
Kevin

Bug#984997: mariadb-server-10.5: database password passed in cleartext both on commandline and in environment

2021-03-11 Thread Marc Lehmann

Package: mariadb-server-10.5
Version: 1:10.5.9-1
Severity: normal

Dear Maintainer,

I had a look at /usr/bin/wsrep_sst_mariabackup, after being a bit
suspicious on how mariadb executes mariabackup for wsrep replication.

I found that the database password is passed in *cleartext* both on the
command line and via the environment.

Neither of these are suitable places for a secret, as both can usually
easily be queried by nonprivileged users.

   * What outcome did you expect instead?

Secrets should never be passwd on the commandline or in the environment.

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

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

Versions of packages mariadb-server-10.5 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
pn  galera-4  
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  5.10.0-4
ii  libc6 2.30-4
ii  libdbi-perl   1.642-1+deb10u2
ii  libpam0g  1.3.1-5
ii  libssl1.1 1.1.1d-0+deb10u2
ii  libstdc++610.2.1-6
ii  lsb-base  11.1.0
ii  lsof  4.91+dfsg-1
pn  mariadb-client-10.5   
ii  mariadb-common1:10.3.27-0+deb10u1
pn  mariadb-server-core-10.5  
ii  passwd1:4.5-1.1
ii  perl  5.28.1-6+deb10u1
ii  procps2:3.3.15-2
ii  psmisc23.2-1
ii  rsync 3.2.3-4
ii  socat 1.7.3.2-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mariadb-server-10.5 recommends:
ii  libhtml-template-perl  2.97-1

Versions of packages mariadb-server-10.5 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1
ii  mailutils [mailx]  1:3.5-4
pn  mariadb-test   
ii  netcat-openbsd 1.195-2

Bug#984996: mariadb-server-core-10.5: modifies globalö environment, causing race conditions

2021-03-11 Thread Marc Lehmann

Package: mariadb-server-core-10.5
Version: 1:10.5.9-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

various scripts (e.g. galera_new_cluster) and the systemd.unit modify the
global/systemwide environment, e.g. with variables _WSREP_START_POSITION.

This has the effect of polluting the environment of other sservices with
these variables, which is usually pretty harmless.

However, if there are multiple server instances then this creates a race
condition where starting/stopping one server or bootstrapping one cluster
will interfere with the other instance,s which could easily lead to
database corruption.

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

I didn't try to solve the problem, it seems to be too fundamental to
easily work around. The mechanism (systemd environment block) is wholly
unsuitable to solve this problem.

   * What was the outcome of this action?

Environment polluted, critical environment variables of other services
erased/modified.

   * What outcome did you expect instead?

A systemd service should _never_ _ever_ modify the global environment.


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

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

Bug#984859: CVE-2021-21381: flatpak: sandbox escape via special tokens in .desktop file (flatpak#4146)

2021-03-11 Thread Simon McVittie

Control: retitle -1 CVE-2021-21381: flatpak: sandbox escape via special tokens 
in .desktop file (flatpak#4146)

On Tue, 09 Mar 2021 at 10:11:09 +, Simon McVittie wrote:
> flatpak since 0.9.4 has a bug in the "file forwarding" feature, which can
> be used by an attacker to gain access to files that would not ordinarily
> be allowed by the app's permissions.
...
> There is no CVE ID available for this yet, so I'm tracking it using the
> upstream issue reference flatpak#4146.

GitHub has issued CVE-2021-21381.

(Full set of identifiers: CVE-2021-21381, flatpak#4146, Debian bug
#984859 and GHSA-xgh4-387p-hqpp are all the same thing.)

smcv

Bug#941199: Upstream has valid debian packaging

2021-03-11 Thread Andreas Metzler

Control: unblock 941199 by 958509

On 2020-04-17 Seunghun Han  wrote:
[...]
> Dear Laurent Bigonville and Christian Ehrhardt,

> I would like to package this one.

> Best regards,

Hello Seunghun,

are you still working on this or should I retitle this to ITP?

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#984995: packaging-tutorial: [INTL:pt_BR] Brazilian Portuguese templates translation

2021-03-11 Thread Tassia Camoes Araujo

Package: packaging-tutorial
Tags: l10n patch
Severity: wishlist

Hi Lucas,

Please merge the pull request for the Brazilian portuguese translation:
https://salsa.debian.org/debian/packaging-tutorial/-/merge_requests/4

I've rebuilt the pdf as per README, to make sure that everything was
properly placed.
I had to do some adjustments in font size so that the text in Portuguese
would fit the page.

Thanks,

Tassia.

Bug#984925: pre-approval: updating python-networkmanager to 2.2 (bugfix release) in bullseye

2021-03-11 Thread Paul Gevers

Control: tags -1 moreinfo

Hi Andreas,

On 10-03-2021 11:41, Andreas Henriksson wrote:
> If you think this (is ok to upload to unstable and) has a chance to get
> unblocked, I'll get right on it (with the first step being filing the
> bug report on python3-networkmanager with RC severity).

The diff you showed looked reasonable (didn't check your filter).

The package does contain tests (that aren't run during build). Does it
make sense to run these as autopkgtest? Would that have caught this
issue? Are these superficial tests, or would they actually "really" test
the package. If the latter is the case, if you would add the tests now,
you wouldn't even need to ask for an unblock.

Paul

OpenPGP_signature
Description: OpenPGP digital signature

Bug#984994: RFS: ibus-kmfl/14.0.258-1 [ITS] -- KMFL engine for IBus

2021-03-11 Thread Eberhard Beilharz


Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ibus-kmfl":

* Package name : ibus-kmfl
Version : 14.0.258-1
Upstream Author : Keyman team 
* URL : https://www.keyman.com
* License : GPL-2+, GPL-2+ or MIT
* Vcs : https://github.com/keymanapp/keyman/tree/master/linux/ibus-kmfl
Section : utils

It builds those binary packages:

ibus-kmfl - KMFL engine for IBus

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


https://mentors.debian.net/package/ibus-kmfl/

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

dget -x 
https://mentors.debian.net/debian/pool/main/i/ibus-kmfl/ibus-kmfl_14.0.258-1.dsc


Changes since the last upload:

ibus-kmfl (14.0.258-1) UNRELEASED; urgency=medium
.
* New upstream release
* Re-release to Debian

Regards,
    Eberhard Beilharz

Bug#984993: RFS: libkmfl/14.0.258-1 [ITS] -- KMFL library - runtime

2021-03-11 Thread Eberhard Beilharz


Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : libkmfl
Version : 14.0.258-1
Upstream Author : Doug Rintoul 
* URL : https://www.keyman.com
* License : MIT
* Vcs : https://github.com/keymanapp/keyman/tree/master/linux/libkmfl
Section : libs

It builds those binary packages:

libkmfl0 - KMFL library - runtime
libkmfl-dev - KMFL library - development

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/libk/libkmfl/libkmfl_14.0.258-1.dsc


Changes since the last upload:

libkmfl (14.0.258-1) UNRELEASED; urgency=medium
.
* New upstream release
* Re-release to Debian

Regards,
    Eberhard Beilharz

Bug#984992: RFS: kmflcomp/14.0.258-1 [ITS] -- KMFL (Keyboard Mapping for Linux) Compiler

2021-03-11 Thread Eberhard Beilharz


Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : kmflcomp
Version : 14.0.258-1
Upstream Author : Doug Rintoul 
* URL : https://www.keyman.com
* License : MIT, GPL-2+ with Bison 2.2 exception
* Vcs : https://github.com/keymanapp/keyman/tree/master/linux/kmflcomp
Section : utils

It builds those binary packages:

libkmflcomp0 - KMFL (Keyboard Mapping for Linux) compiler library
libkmflcomp-dev - Development files for libkmflcomp
kmflcomp - KMFL (Keyboard Mapping for Linux) Compiler

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/k/kmflcomp/kmflcomp_14.0.258-1.dsc


Changes since the last upload:

kmflcomp (14.0.258-1) UNRELEASED; urgency=medium
.
* New upstream release
* Re-release to Debian

Regards,

    Eberhard Beilharz

Bug#984991: RFS: keyman-keyboardprocessor/14.0.258-1 [ITS] -- Keyman keyboard processing library

2021-03-11 Thread Eberhard Beilharz


Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "keyman-keyboardprocessor":

* Package name : keyman-keyboardprocessor
Version : 14.0.258-1
Upstream Author : SIL International 
* URL : https://www.keyman.com
* License : MIT
* Vcs : https://github.com/keymanapp/keyman/tree/master/common/core/desktop
Section : text

It builds those binary packages:

libkmnkbp0-0 - Keyman keyboard processing library
libkmnkbp-dev - Development files for Keyman keyboard processing library

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


https://mentors.debian.net/package/keyman-keyboardprocessor/

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

dget -x 
https://mentors.debian.net/debian/pool/main/k/keyman-keyboardprocessor/keyman-keyboardprocessor_14.0.258-1.dsc


Changes since the last upload:

keyman-keyboardprocessor (14.0.258-1) UNRELEASED; urgency=medium
.
* New upstream release
* Re-release to Debian

Regards,
    Eberhard Beilharz

Bug#984989: RFS: keyman-config/14.0.258-1 [ITS] -- Keyman for Linux configuration

2021-03-11 Thread Eberhard Beilharz


Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "keyman-config":

* Package name : keyman-config
Version : 14.0.258-1
Upstream Author : Keyman team 
* URL : https://www.keyman.com
* License : MIT
* Vcs : https://github.com/keymanapp/keyman/tree/master/linux/keyman-config
Section : utils

It builds those binary packages:

python3-keyman-config - Keyman for Linux configuration
keyman - Type in your language with Keyman for Linux

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


https://mentors.debian.net/package/keyman-config/

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

dget -x 
https://mentors.debian.net/debian/pool/main/k/keyman-config/keyman-config_14.0.258-1.dsc


Changes since the last upload:

keyman-config (14.0.258-1) UNRELEASED; urgency=medium
.
* New upstream release
* Re-release to Debian

Regards,
    Eberhard Beilharz

Bug#984990: RFS: ibus-keyman/14.0.258-1 [ITS] -- Keyman engine for IBus

2021-03-11 Thread Eberhard Beilharz


Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ibus-keyman":

* Package name : ibus-keyman
Version : 14.0.258-1
Upstream Author : Keyman team 
* URL : https://www.keyman.com
* License : GPL-2+, GPL-3+, GPL-2+ or MIT
* Vcs : https://github.com/keymanapp/keyman/tree/master/linux/ibus-keyman
Section : utils

It builds those binary packages:

ibus-keyman - Keyman engine for IBus

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


https://mentors.debian.net/package/ibus-keyman/

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

dget -x 
https://mentors.debian.net/debian/pool/main/i/ibus-keyman/ibus-keyman_14.0.258-1.dsc


Changes since the last upload:

ibus-keyman (14.0.258-1) UNRELEASED; urgency=medium
.
* New upstream release
* Re-release to Debian

Regards,
    Eberhard Beilharz

Bug#979563: gitlab: my instance work great after upgrade to 13.5.6.1!

2021-03-11 Thread Pirate Praveen

On Mon, 11 Jan 2021 18:10:34 +0200 Dragos Jarca 
 wrote:
> Just to know, in previous version I have some trouble with licensee, 
and

> I do the following to solve the problem:
>
> gitaly(13.4.6+dfsg1-2) and gitlab(13.4.7-2) have in Gemfile:
>
> gem 'rugged', '~> 0.28'
> ...
> gem 'licensee', '~> 8.9'
>
> But rugged is 1.1.0+ds-1 in testing and unstable and licensee need
> rugged~>0.24.
>
> Solved putting in Gemfile:
> gem 'rugged', '>= 0.28'
> gem 'licensee', '~> 9.14', '>= 9.14.1'
>
> and manually install licensee 9.14.1 with:
>
> cd /usr/share/gitlab
> gem install licensee
>
> It could help.

gitlab 13.9.3 now works again with rugged 1.1 in the archive, so these 
work arounds are not required. https://wiki.debian.org/gitlab/wip has 
instructions to get the new version. This will be uploaded to 
experimental soon (after ruby-pg-query is accepted).

Bug#947809: upgrade-reports: lost wifi on upgrade from buster to bullseye

2021-03-11 Thread Michael Biebl


Control: tags -1 - a11y


Am 11.03.21 um 15:19 schrieb Paul Gevers:

[Oops, re-sending to the right address]

Control: reassign -1 network-manager
Control: affects -1 upgrade-reports

Hi network-manager maintainers,

It's hopelessly over time, but is there anything in the report below
that is actionable for you?


Not really, unfortunately.
We first would need to know, if NetworkManager is actually in charge of 
the network connection (and not ifupdown e.g.).
Second, a debug log from NetworkManager would potentially provide some 
insight, what is happening:


https://wiki.gnome.org/Projects/NetworkManager/Debugging

Might just as well be a driver/kernel issue or something else.

Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#832150: ITA: xmacro -- Record / Play keystrokes and mouse movements in X displays

2021-03-11 Thread Vincent Carluer

Hello,

Nice :) I dont maintain the package since it wasn't clear some years ago if I 
should to...
Do as you want ;) I don't think I have anything to do on my side.


Regards,

Vincent Carluer

11 mars 2021 10:24:15 Francisco Demartino :

> retitle 832150 ITA: xmacro -- Record / Play keystrokes and mouse movements in 
> X displays
> owner 832150 !
> thanks
> 
> Hello,
> 
> I've recently discovered xmacro and I've added a feature so it can record 
> delays between events, so the recorded macro contains timing data and the 
> replay matches the original inputs.
> 
> I'd like to maintain the package! I'm not sure if I should turn into its new 
> upstream as well...
> 
> Best,
> Francisco

Bug#984980: libaqbanking44: Wrong message after sending an transaction

2021-03-11 Thread Andrei POPESCU

Control: reassign -1 libaqbanking44

On Jo, 11 mar 21, 15:17:15, Mechtilde Stehmann wrote:
> Package: libaqbaning44
> Version: 6.2.9-1
> severity: grave
> 
> I get the message the transaction failed after entering PIN and TAN but
> the transaction was executed.
> 
> Upstream has already fixed it in version 6.2.10
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (400, 'testing'), (300, 'unstable'), (200, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libaqbanking44 depends on:
> ii  libaqbanking-data  6.2.9-1
> ii  libc6  2.31-9
> ii  libgmp10   2:6.2.1+dfsg-1
> ii  libgwenhywfar795.6.0-2
> ii  libxml22.9.10+dfsg-6.3+b1
> ii  libxmlsec1 1.2.31-1
> ii  zlib1g 1:1.2.11.dfsg-2
> 
> libaqbanking44 recommends no packages.
> 
> Versions of packages libaqbanking44 suggests:
> pn  aqbanking-tools  
> 
> -- no debconf information
> 
> 
> -- 
> Mechtilde Stehmann
> ## Debian Developer
> ## PGP encryption welcome
> ## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F

Fixing typo in package name.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#984988: pre-approval: unblock: golang-1.15/1.15.9-1

2021-03-11 Thread Shengjing Zhu

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org, team+go-compi...@tracker.debian.org

Please unblock package golang-1.15

[ Reason ]
Upstream security release, only target fix is introduced.
CVE-2021-27918: encoding/xml: infinite loop when using `xml.NewTokenDecoder`
with a custom `TokenReader`.
https://github.com/golang/go/issues/44913

[ Impact ]
Without this version, the Go compiler is vulnerable.
However with the new undetermined Go security policy, this
bug is classified as LOW (severity issues affect niche configurations,
have very limited impact, or are already widely known).
https://github.com/golang/go/issues/44918

[ Tests ]
+ Upstream tests in source package.
+ Have manually test some Go packages.

[ Risks ]
+ No autopkgtest
+ Diff is small

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
If this package is blocked in unstable, all Go packages will be prevented
from migrating to testing, due to the Built-Using thing..
So I fill this pre-approval request. And if possible, reduce the age too.

unblock golang-1.15/1.15.9-1


diff -Nru golang-1.15-1.15.8/debian/changelog 
golang-1.15-1.15.9/debian/changelog
--- golang-1.15-1.15.8/debian/changelog 2021-02-15 23:19:39.0 +0800
+++ golang-1.15-1.15.9/debian/changelog 2021-03-11 23:43:18.0 +0800
@@ -1,3 +1,12 @@
+golang-1.15 (1.15.9-1) unstable; urgency=medium
+
+  * Team upload.
+  * New upstream version 1.15.9
++ encoding/xml: infinite loop when using `xml.NewTokenDecoder` with a
+  custom `TokenReader`. CVE-2021-27918
+
+ -- Shengjing Zhu   Thu, 11 Mar 2021 23:43:18 +0800
+
 golang-1.15 (1.15.8-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru golang-1.15-1.15.8/src/encoding/xml/xml.go 
golang-1.15-1.15.9/src/encoding/xml/xml.go
--- golang-1.15-1.15.8/src/encoding/xml/xml.go  2021-02-05 20:48:37.0 
+0800
+++ golang-1.15-1.15.9/src/encoding/xml/xml.go  2021-03-10 22:29:35.0 
+0800
@@ -271,7 +271,7 @@
 // it will return an error.
 //
 // Token implements XML name spaces as described by
-// https://www.w3.org/TR/REC-xml-names/.  Each of the
+// https://www.w3.org/TR/REC-xml-names/. Each of the
 // Name structures contained in the Token has the Space
 // set to the URL identifying its name space when known.
 // If Token encounters an unrecognized name space prefix,
@@ -285,16 +285,17 @@
if d.nextToken != nil {
t = d.nextToken
d.nextToken = nil
-   } else if t, err = d.rawToken(); err != nil {
-   switch {
-   case err == io.EOF && d.t != nil:
-   err = nil
-   case err == io.EOF && d.stk != nil && d.stk.kind != stkEOF:
-   err = d.syntaxError("unexpected EOF")
+   } else {
+   if t, err = d.rawToken(); t == nil && err != nil {
+   if err == io.EOF && d.stk != nil && d.stk.kind != 
stkEOF {
+   err = d.syntaxError("unexpected EOF")
+   }
+   return nil, err
}
-   return t, err
+   // We still have a token to process, so clear any
+   // errors (e.g. EOF) and proceed.
+   err = nil
}
-
if !d.Strict {
if t1, ok := d.autoClose(t); ok {
d.nextToken = t
diff -Nru golang-1.15-1.15.8/src/encoding/xml/xml_test.go 
golang-1.15-1.15.9/src/encoding/xml/xml_test.go
--- golang-1.15-1.15.8/src/encoding/xml/xml_test.go 2021-02-05 
20:48:37.0 +0800
+++ golang-1.15-1.15.9/src/encoding/xml/xml_test.go 2021-03-10 
22:29:35.0 +0800
@@ -33,30 +33,90 @@
 
 func TestDecodeEOF(t *testing.T) {
start := StartElement{Name: Name{Local: "test"}}
-   t.Run("EarlyEOF", func(t *testing.T) {
-   d := NewTokenDecoder({earlyEOF: true, t: []Token{
-   start,
-   start.End(),
-   }})
-   err := d.Decode( {
-   XMLName Name `xml:"test"`
-   }{})
-   if err != nil {
-   t.Error(err)
+   tests := []struct {
+   name   string
+   tokens []Token
+   ok bool
+   }{
+   {
+   name: "OK",
+   tokens: []Token{
+   start,
+   start.End(),
+   },
+   ok: true,
+   },
+   {
+   name: "Malformed",
+   tokens: []Token{
+   start,
+   StartElement{Name: Name{Local: "bad"}},
+   start.End(),
+

Bug#984881: libnvidia-ml-dev: missing libnvidia-ml.so in library search path?

2021-03-11 Thread Samuel Thibault

Hello,

Andreas Beckmann, le mer. 10 mars 2021 10:32:42 +0100, a ecrit:
> I'll think about where best to add this ... driver or cuda toolkit.

Thanks for the nvidia-alternative upload, but it seems that it then
doesn't work for ppc64el, which doesn't have the nvidia-alternative
binary package since it doesn't build the nvidia-graphics-drivers source
package?

Samuel

Bug#984946: Bug report libpigpiod-if-dev

2021-03-11 Thread peter green




> The package 'libpigpiod-if-dev' should contain all the header files and object

No, it contains the header files and shared library symlinks for building
against the libpigpio-if and libpigpio-if2 libraries.

The server and direct access GPIO libraries are not packaged in Debian
because they are not compatible with Debian kernels.
In particular, pigpio relies on the userspace mainbox interface
which is only present in downstream raspberry pi foundation
kernels.

Bug#984987: ITP: cl-trivial-macroexpand-all -- macroexpand-all function for which calls implementation-specific equivalent

2021-03-11 Thread Sean Whitton

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-common-l...@lists.debian.org

* Package name: cl-trivial-macroexpand-all
  Version : 0~git20171020.933270a
  Upstream Author : cbaggers
* URL : https://github.com/cbaggers/trivial-macroexpand-all/
* License : Unlicense
  Programming Lang: Common Lisp
  Description : macroexpand-all function which calls 
implementation-specific equivalent

This small library is one way to deal with the fact that the ANSI Common
Lisp standard does not provide quite enough facilities to do completely
reliable code walking, which is needed by Consfigurator, a package of
mine.

For background see Michael Raskin.  2017.  Writing a best-effort
portable code walker in Common Lisp.  In Proceedings of 10th European
Lisp Symposium, Vrije Universiteit Brussel, Belgium, April 2017
(ELS2017).  DOI: 10.5281/zenodo.3254669
https://zenodo.org/record/3254669/files/writing-portable-macroexpand-all.pdf

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#984925: pre-approval: updating python-networkmanager to 2.2 (bugfix release) in bullseye

2021-03-11 Thread Andreas Henriksson

Control: block 984983 by 984925

Hello,

I've done detailed investigations and reported them in a bug report
against python3-networkmanager in https://bugs.debian.org/984925

I've also locally updated the package and verified that 2.2 solves
the problem.

I'm ready to pull the trigger and upload when/if you say so.

(Have not yet pushed to the git repository since it includes reverting
a pending compat bump, which we only want to do if we're uploading this
during freeze. Can push on request if is interested.)

Regards,
Andreas Henriksson

Bug#984971: RFS: wfrench/1.2.7-1 -- French dictionary words for /usr/share/dict

2021-03-11 Thread guillaume pernot

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: wfrench
   Version : 1.2.7-1
   Upstream Author : Paul Leyland 
 * URL : https://salsa.debian.org/gpernot-guest/wfrench
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/gpernot-guest/wfrench
   Section : text

It builds those binary packages:

  wfrench - French dictionary words for /usr/share/dict

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/w/wfrench/wfrench_1.2.7-1.dsc

Changes since the last upload:

 wfrench (1.2.7-1) unstable; urgency=medium
 .
   * new upstream release
   * Christoph Berg fixes :
 - Use Rules-Requires-Root: no; install file using dh_install.
 - Don't call dh_installman from override_dh_auto_install, it's
called
 later anyway.

Regards,

Bug#984522: Acknowledgement (The ruby-gnome autopkgtests are failing with 2.31)

2021-03-11 Thread Sebastien Bacher

I've also reported the issue upstream now with some details

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

Le 04/03/2021 à 17:48, Debian Bug Tracking System a écrit :
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 984522: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984522.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian WebKit Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 984...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>

Bug#984882: unblock: debian-science/1.14.1

2021-03-11 Thread Graham Inggs

Control: tags -1 + moreinfo

Hi Andreas

On Tue, 9 Mar 2021 at 19:03, Andreas Tille  wrote:
>   [ ] attach debdiff against the package in testing
>   (I do not see any reason for a debdiff of the autogenerated package)

Autogenerated or not, the debdiff is the thing we need to review, in
order to answer your unblock request.

Regards
Graham

Bug#829398: xcfa: Buffer overflow with more than 45 tracks

2021-03-11 Thread Gunnar Wolf



tags -1 + patch
user debian-rele...@lists.debian.org
usertags -1 + bsp-2021-03-latinoamerica
kthxbye

So, a trivial workaround for this issue would be to increase the
amount of entries in the allocation table:


diff --git a/src/file_lc.c b/src/file_lc.c
index 4d9ce0c..ef774ee 100644
--- a/src/file_lc.c
+++ b/src/file_lc.c
@@ -57,7 +57,7 @@
 // 
 gchar **filelc_AllocTabArgs( void )
 {
-   gchar   **PtrTab = (gchar **)g_malloc0( sizeof(gchar **) * 50 );
+   gchar   **PtrTab = (gchar **)g_malloc0( sizeof(gchar **) * 110 );
 
PtrTab [ 0 ] = g_strdup( "nice" );
PtrTab [ 1 ] = g_strdup( "-n" );


I chose 110 in order to leave space for the relevant logs mentioned by
the bug submitter. While this is not a definitive answer and does not
make the buffer overflow go away, this would allow all
standards-compliant CDDA disks to be produced -- A CD can contain up
to 99 tracks¹, so this would allow for creating all valid CDs.

Of course, this trivial patch does not take away the overflow
potential (and that should definitively be addressed!), and does not
yet properly communicate to users they requested the creation of
something that would break the standards. But it would be a first,
trivial step to fix this (old!) bug allowing for the creation of valid
images.

¹ https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio#Tracks
  The official standard is not freely available.

Bug#983533: [vinagre] black screen when launching RDP session

2021-03-11 Thread Paul Gevers

Hi all,

On Mon, 8 Mar 2021 13:04:07 + Simon McVittie  wrote:
> On Thu, 25 Feb 2021 at 19:04:49 +, Mike Gabriel wrote:
> > I saw from other open
> > bugs that vinagre upstream is scarcely maintained. Does it make sense to
> > ship vinagre in Debian 11?
> 
> I suspect there are people relying on it, but as you say, it's basically
> unmaintained upstream. The latest version of src:meta-gnome3 drops it from
> Depends down to Suggests, which I think is proportionate.

For reference: vinagre is a key package due to popcon, however, it *can*
easily be removed:

elbrus@coccia:~$ dak rm --no-action -R --suite testing vinagre
Will remove the following packages from testing:

   vinagre |   3.22.0-8 | source, amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x

Maintainer: Debian GNOME Maintainers


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#984985: wordpress: WordPress 5.7 available

2021-03-11 Thread Christer Mjellem Strand

Package: wordpress
Version: 5.6.1+dfsg1-1
Severity: normal

Dear Maintainer,

WordPress 5.7 has been released. Appreciate if you're able to update the 
package at your earliest convenience.



TIA

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

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

Versions of packages wordpress depends on:
ii  apache2 [httpd] 2.4.46-4~bpo10+1
ii  ca-certificates 20210119
ii  default-mysql-client1.0.5
ii  libjs-cropper   1.2.2-1
ii  libjs-underscore1.9.1~dfsg-1
ii  mariadb-client-10.3 [virtual-mysql-client]  1:10.3.27-0+deb10u1
ii  php 2:7.3+69
ii  php-gd  2:7.3+69
ii  php-getid3  1.9.20+dfsg-1
ii  php-mysql   2:7.3+69
ii  php7.3 [php]7.3.27-1~deb10u1
ii  php7.3-gd [php-gd]  7.3.27-1~deb10u1
ii  php7.3-mysql [php-mysqlnd]  7.3.27-1~deb10u1

Versions of packages wordpress recommends:
ii  wordpress-l10n   5.6.1+dfsg1-1
ii  wordpress-theme-twentytwentyone  5.6.1+dfsg1-1

Versions of packages wordpress suggests:
ii  mariadb-server-10.3 [virtual-mysql-server]  1:10.3.27-0+deb10u1
pn  php-ssh2

-- Configuration Files:
/etc/wordpress/htaccess [Errno 2] No such file or directory: 
'/etc/wordpress/htaccess'

-- no debconf information

Bug#984984: hwloc-contrib: FTBFS with latest nvidia-alternative

2021-03-11 Thread Samuel Thibault

Source: hwloc-contrib
Version: 2.4.1+dfsg-1
Severity: serious
Justification: FTBFS

With the new nvidia-alternative package which fixed shipping
libnvidia-ml.so (see #984881), hwloc-contrib now FTBFS:

   dh_missing -a
dh_missing: warning: usr/lib/x86_64-linux-gnu/hwloc/hwloc_nvml.so exists in 
debian/tmp but is not installed to anywhere

That's because hwloc can now build its nvml plugin. It happens that we'd
want to ship indeed, so I'll propose to use the attached patch.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-proposed-updates-debug'), (500, 'testing-proposed-updates'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.11.0 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/libhwloc-contrib-plugins.install 
b/debian/libhwloc-contrib-plugins.install
index 59555c70..80553c88 100644
--- a/debian/libhwloc-contrib-plugins.install
+++ b/debian/libhwloc-contrib-plugins.install
@@ -1 +1,2 @@
 usr/lib/*/hwloc/hwloc_cuda.so
+usr/lib/*/hwloc/hwloc_nvml.so

Bug#984983: python3-networkmanager: crashes on unknown device types (eg. wifi p2p) in >=bullseye

2021-03-11 Thread Andreas Henriksson

Package: python3-networkmanager
Version: 2.1-2
Severity: serious
Justification: Incompatibility with bullseye NM causes crashes enumerating 
devices etc.

Dear Maintainer,

I'm experiencing python3-networkmanager crashing with a simple test
program like this:

$ cat /tmp/test.py
#!/usr/bin/python3

import NetworkManager

for dev in NetworkManager.NetworkManager.Devices:
if dev.DeviceType == NetworkManager.NM_DEVICE_TYPE_WIFI:
print(dev)

print("Program finished")
$ python3 /tmp/test.py
Traceback (most recent call last):
  File "/tmp/test.py", line 6, in 
for dev in NetworkManager.NetworkManager.Devices:
  File "/usr/lib/python3/dist-packages/NetworkManager.py", line 174, in get_func
return fixups.to_python(klass, 'Get', name, data, attrib['type'])
  File "/usr/lib/python3/dist-packages/NetworkManager.py", line 555, in 
to_python
val = fixups.base_to_python(val)
  File "/usr/lib/python3/dist-packages/NetworkManager.py", line 612, in 
base_to_python
return [fixups.base_to_python(x) for x in val]
  File "/usr/lib/python3/dist-packages/NetworkManager.py", line 612, in 

return [fixups.base_to_python(x) for x in val]
  File "/usr/lib/python3/dist-packages/NetworkManager.py", line 625, in 
base_to_python
return globals()[classname](val)
  File "/usr/lib/python3/dist-packages/NetworkManager.py", line 353, in __new__
klass = device_class(obj.Get('org.freedesktop.NetworkManager.Device', 
'DeviceType', dbus_interface='org.freedesktop.DBus.Properties'))
  File "/usr/lib/python3/dist-packages/NetworkManager.py", line 373, in 
device_class
return {
KeyError: dbus.UInt32(30, variant_level=1)


The reason appears to be that NM in bullseye supports and returns a
(disconnected=30) wifi p2p interface on my device.

Here's some info from the affected system:

$ nmcli d
DEVICE TYPE  STATE CONNECTION
wlan0  wifi  connected FOOBAR
p2p-dev-wlan0  wifi-p2p  disconnected  --
lo loopback  unmanaged --


The mere existance of p2p-dev-wlan0 causes the crash and the needed constant
values in python3-networkmanager was added in new upstream release 2.2.

FWIW the problem is also reproducible on a buster system with a partial
update to NM (and deps) from bullseye. The p2p feature is thus not a new
kernel feature or similar, simply new info exposed by NM.

As mentioned, this is fixed in upstream release 2.2.
I've also filed a pre-approval request to update to 2.2 during freeze,
see Bug#984925

Regards,
Andreas Henriksson

Bug#984982: plexus-languages: Build-Depends on no longer available libsisu-maven-plugin-java

2021-03-11 Thread Andreas Beckmann

Source: plexus-languages
Version: 1.0.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
User: debian...@lists.debian.org
Usertags: piuparts

plexus-languages/experimental Build-Depends on libsisu-maven-plugin-java
which has been removed from sid.


Andreas

1 2 >

1 - 100 of 136 matches

Mail list logo