Bug#948698: Help needed?

2021-04-18 Thread Carsten Schoenert
Hi Sandro, hi Henning!

Am 19.04.21 um 00:10 schrieb Henning Sprang:

> I thought just about a bit of technical work but if this is helpful, I
> can try. I have to check the documentation
> (https://wiki.debian.org/DebianMaintainer
>  right?) to see if I can
> fulfil the requirements for taking that role.

Step up as a package maintainer requires mostly two things, firstly a
good knowledge about the upstream project and secondly also knowledge
about the mostly technical packaging things within Debian. There are of
course some social things and requirements in Debian and by this in
packaging of upstream software.

The first part I'm sure you know enough to make decisions and judgments
about upstream versions.

But also on the technical packaging side you are not on the starting
line. The Python team in Debian has one of the best documented workflow
rules for the team which did help me in the past as I needed to package
some Python packages.

https://wiki.debian.org/Python/LibraryStyleGuide

> I have been involved with debian since a while but never has maintainer
> responsibilities and wasnt very active in recent years, but finding
> someone for the advocacy should be doable.

I can sponsor packages and preparation from you if the DPMT is o.k. with
this. In case you want to do the next step I'd also guide you through
the required NM process to become DM.

> Do you suggest anything specific i should do as a next step that i might
> not read in the above document?

Reading the mentioned Wiki site is always a good thing.
The main thing is to know and understand why a specific package is build
exact that way it is and by this to see what is potentially needed to
improve the packaging. In case something isn't fully clear the ML should
help to find the correct answers.
But shouldn't be that hard as you don't need to start from scratch and
you can use the existing git tree to see what happen in the past.

> I see also there is a newer version of the package on salsa already, not
> up to date with upstream, but more current:
> https://salsa.debian.org/python-team/packages/flask-sqlalchemy
> 
> That’s probably what has been mentioned in the earlier conversations
> about this bug.
> But it seems not to have made it to the archive... 

Obviously. ;)
As Sandro already has mentioned we are in the hard freeze currently. So
I'd suggest to prepare a new version, this can be the existing version
in the git tree, for uploading into experimental so potentially needed
fixed versions for bullseye can still be uploaded to unstable.

Once bullseye is out of the door the usual upload of recent versions
into unstable can be done and the later migrated version can be go too
into backports if this is possible without complex adaptions on other
needed packages.

In all I can only suggest to try out to become a package maintainer for
this package in question. Shouldn't be a job with a lot of time consumption.

-- 
Regards
Carsten



Bug#987172: acl2: run-acl2 in emacs fails

2021-04-18 Thread florine forine
Package: acl2
Version: 8.3dfsg-2
Severity: normal

Dear Maintainer,

M-x run-acl2 in emacs fails probably because
/usr/share/emacs/site-lisp/acl2/mfm.el
uses an obsolete function string-to-int.
See 
https://stackoverflow.com/questions/52726142/emacs-26-symbol-s-function-definition-is-void-string-to-int.

emacs configuration in ~/.emacs:

(setq *acl2-sources-dir* "/usr/share/acl2-8.3dfsg/")
(setq *acl2-interface-dir* "/usr/share/emacs/site-lisp/acl2/")
(setq inferior-acl2-program "/usr/bin/acl2")

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

Versions of packages acl2 depends on:
ii  libc6 2.31-11
ii  libgmp10  2:6.2.1+dfsg-1
ii  libreadline8  8.1-1
ii  libx11-6  2:1.7.0-2

Versions of packages acl2 recommends:
ii  acl2-books   8.3dfsg-2
ii  acl2-source  8.3dfsg-2

Versions of packages acl2 suggests:
ii  acl2-emacs  8.3dfsg-2

-- no debconf information

-- 


signature.asc
Description: PGP signature


Bug#987176: plasma-desktop: Default application for .deb files is broken on clean install

2021-04-18 Thread Caleb McKay
Package: plasma-desktop
Version: 4:5.20.5-4
Severity: important
X-Debbugs-Cc: ca...@candj.us

Dear Maintainer,



   * What led up to the situation? This was a clean install of Debian 11 on 
multiple computers.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Tried to install a .deb by double clicking on it in Dolphin
   * What was the outcome of this action? Nothing happens
   * What outcome did you expect instead? I would expect the default 
application associated with .deb files out of the box, apper, would launch. 
This can be worked around with simply associating deb files with something 
else, like Discover. But this is a really poor out of the box experience for 
users. Whatever bug that prevents apper from launching should be fixed or the 
default application on a clean install should be changed.





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

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

Versions of packages plasma-desktop depends on:
ii  accountsservice  0.6.55-3
ii  breeze   4:5.20.5-3
ii  kactivitymanagerd5.20.5-1
ii  kde-cli-tools4:5.20.5-2
ii  kded55.78.0-2
ii  kio  5.78.0-4
ii  kpackagetool55.78.0-3
ii  libaccounts-qt5-11.16-2
ii  libc62.31-11
ii  libcrypt11:4.4.18-2
ii  libglib2.0-0 2.66.8-1
ii  libibus-1.0-51.5.23-2
ii  libkaccounts24:20.12.1-1
ii  libkf5activities55.78.0-2
ii  libkf5activitiesstats1   5.78.0-2
ii  libkf5authcore5  5.78.0-2
ii  libkf5baloo5 5.78.0-3
ii  libkf5codecs55.78.0-2
ii  libkf5completion55.78.0-3
ii  libkf5configcore55.78.0-4
ii  libkf5configgui5 5.78.0-4
ii  libkf5configwidgets5 5.78.0-2
ii  libkf5coreaddons55.78.0-4
ii  libkf5crash5 5.78.0-3
ii  libkf5dbusaddons55.78.0-2
ii  libkf5declarative5   5.78.0-2
ii  libkf5globalaccel-bin5.78.0-3
ii  libkf5globalaccel5   5.78.0-3
ii  libkf5guiaddons5 5.78.0-3
ii  libkf5i18n5  5.78.0-2
ii  libkf5iconthemes55.78.0-2
ii  libkf5itemviews5 5.78.0-2
ii  libkf5kcmutils5  5.78.0-3
ii  libkf5kdelibs4support5   5.78.0-2
ii  libkf5kiocore5   5.78.0-4
ii  libkf5kiofilewidgets55.78.0-4
ii  libkf5kiogui55.78.0-4
ii  libkf5kiowidgets55.78.0-4
ii  libkf5notifications5 5.78.0-2
ii  libkf5notifyconfig5  5.78.0-2
ii  libkf5package5   5.78.0-3
ii  libkf5plasma55.78.0-3
ii  libkf5plasmaquick5   5.78.0-3
ii  libkf5quickaddons5   5.78.0-2
ii  libkf5runner55.78.0-3
ii  libkf5service-bin5.78.0-2
ii  libkf5service5   5.78.0-2
ii  libkf5solid5 5.78.0-2
ii  libkf5sonnetcore55.78.0-2
ii  libkf5sonnetui5  5.78.0-2
ii  libkf5wallet-bin 5.78.0-2
ii  libkf5wallet55.78.0-2
ii  libkf5widgetsaddons5 5.78.0-2
ii  libkf5windowsystem5  5.78.0-2
ii  libkf5xmlgui55.78.0-2
ii  libkworkspace5-5 4:5.20.5-5
ii  libnotificationmanager1  4:5.20.5-5
ii  libphonon4qt5-4  4:4.11.1-3
ii  libprocesscore9  4:5.20.5-1
ii  libqt5concurrent55.15.2+dfsg-5
ii  libqt5core5a 5.15.2+dfsg-5
ii  libqt5dbus5  5.15.2+dfsg-5
ii  libqt5gui5   5.15.2+dfsg-5
ii  libqt5network5   5.15.2+dfsg-5
ii  libqt5qml5   5.15.2+dfsg-5
ii  libqt5quick5

Bug#987174: ITS: kyotocabinet

2021-04-18 Thread Boyuan Yang
Source: kyotocabinet
Version:  1.2.76-4.2
Severity: important
X-Debbugs-CC: shawnland...@gmail.com

Dear package kyotocabinet maintainer in Debian,

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

My current plan is to package the latest upstream release (1.2.79),
clean up packaging and orphan this package to allow possible external
contribution.

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


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

-- 
Best Regards,
Boyuan Yang


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


Bug#987153: Typo in anacron log message: "ststus" should be "status"

2021-04-18 Thread Boyuan Yang
Control: tags -1 +pending

在 2021-04-18星期日的 09:53 -0400,Jonathan Kamens写道:
> Package: anacron
> Version: 2.3-30
> Tags: patch
> 
> There is a typo in the log message generated by anacron when it can't
> send email. It says "ststus" when it should say "status".

Patch committed into git packaging repo.

-- 
Thanks,
Boyuan Yang


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


Bug#972230: Bug#976477 marked as pending in jruby

2021-04-18 Thread Louis-Philippe Véronneau
On 2021-04-18 17 h 54, Markus Koschany wrote:
> Hi,
> 
> I'm just investigating the current open RC bugs for the debian-java maintained
> packages. You have marked #976477 and #977979 in jruby as pending. Could you
> clarify why there hasn't been an upload yet? There also seems to be another RC
> bug, #972230. Do you have any suggestions how we can include jruby in Debian
> 11? 
> 
> Regards,
> 
> Markus 
> 
> 

Hi,

I worked on jruby quite a bit but the testsuite still fails in many
places. Trying to use the resulting binary package for
jruby-utils-clojure (the package I was trying to get in the archive in
the first place) yielded failures too.

At the moment, I don't think there is a way to include jruby in Debian
11 and I think it would be unwise to try to do so. It's too late, and
I don't believe anyone is currently committed to supporting jruby for
the whole Bullseye cycle.

I have worked with the release team to remove as much blockers for the
jruby removal from Bullseye as possible and I don't think jruby not
being present currently breaks anything release critical.

If someone wants jruby back in the archive eventually, there is
substantial work to be done. I think the harder thing to fix is jruby
targeting a different version of ruby than what is packaged in Debian.
Last time I checked, upstream jruby was several major releases behind
ruby, and the Ruby Team is already working on moving to ruby 3.0.

FWIW, I also wrote a blog post on the work I did:

https://veronneau.org/puppetserver-6-a-debian-packaging-post-mortem.html

Cheers,

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



OpenPGP_signature
Description: OpenPGP digital signature


Bug#987173: unblock: iptables-netflow/2.5.1-2

2021-04-18 Thread Axel Beckert
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: a...@debian.org, a...@debian.org

Please unblock package iptables-netflow.

[ Reason ]

One if this source package's binary packages is a dkms-built kernel
module and it was one of the packages affected by #984929 in dkms.

This upload changes the dkms dependency to a versioned dependency on ≥
the version which fixed #984929 to make sure the fixed dkms package is
installed before this package is upgraded and tries to use it at
configuration time.

Closes RC bug #984862 (https://bugs.debian.org/984862) against this
package.

[ Impact ]

During dist-upgrade from Buster to Bullseye, this kernel module might
be tried to be compiled with the wrong (not the kernel's) C compiler
or might even fail to upgrade in case only the package
linux-compiler-gcc-10-x86 but not the package gcc is installed since
then no compiler is found as $CC is not set in the environment by the
dkms package in Buster.

[ Tests ]

None. Solely a migration order issue solved via a versioned dependency
requiring the fixed dkms package to be installed first.

The binary packages built by this source package (built in an up to
date pbuilder chroot) have been successfully installed on one of my
sid machines with the current and an older 5.10 kernel image + headers
being installed.

The version constraint added by Andreas Beckmann (X-Debbugs-Cc'ed) has
been cross-checked by myself to make sure there's no typo in it.

[ Risks ]

None. There are no known dependencies (nor Recommends nor Suggests) on
any of the binary packages built by this source package (outside the
source package itself), so circular dependencies — which might cause
issues with such changes if they're versioned, too — are not present.

[ 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 ]

I deliberately did not bump the Standards-Version from 4.5.0 to 4.5.1
with this upload despite I didn't see any necessary changes to be
made. Just to keep the changeset minimal.

So please …

unblock iptables-netflow/2.5.1-2

… and maybe also reduce the migration interval a bit, dependening on
how close we are to the release. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
diff -Nru iptables-netflow-2.5.1/debian/changelog 
iptables-netflow-2.5.1/debian/changelog
--- iptables-netflow-2.5.1/debian/changelog 2020-10-18 11:22:35.0 
+0200
+++ iptables-netflow-2.5.1/debian/changelog 2021-04-18 18:29:53.0 
+0200
@@ -1,3 +1,11 @@
+iptables-netflow (2.5.1-2) unstable; urgency=low
+
+  [ Andreas Beckmann ]
+  * iptables-netflow-dkms: Bump dkms dependency to ensure CC/CXX are set to
+the kernel's compiler.  (Closes: #984862)
+
+ -- Axel Beckert   Sun, 18 Apr 2021 18:29:53 +0200
+
 iptables-netflow (2.5.1-1) unstable; urgency=medium
 
   * New upstream bugfix release 2.5.1.
diff -Nru iptables-netflow-2.5.1/debian/control 
iptables-netflow-2.5.1/debian/control
--- iptables-netflow-2.5.1/debian/control   2020-04-27 08:39:15.0 
+0200
+++ iptables-netflow-2.5.1/debian/control   2021-04-18 18:15:16.0 
+0200
@@ -15,7 +15,7 @@
 
 Package: iptables-netflow-dkms
 Architecture: linux-any
-Depends: dkms,
+Depends: dkms (>= 2.8.4-3~),
  libc6-dev,
  libxtables-dev,
  pkg-config,


Bug#987171: ITP: libdumbtts -- Helper library for dumb speech synthesizers

2021-04-18 Thread Samuel Thibault
Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
debian-accessibil...@lists.debian.org

* Package name: libdumbtts
  Version : 0.3.2
  Upstream Author : Bohdan R. Rau 
* URL : http://www.polip.com/files/
* License : LGPL v2.1+
  Programming Lang: C
  Description : Helper library for dumb speech synthesizers

This library is used between the Ivona synthesizer and
speech-dispatcher. On the other side, it should be as flexible as it can
be to generate output texts for every other synthesizer.



Bug#983688: This should also apply to other languages

2021-04-18 Thread YOSHINO Yoshihito
Hi Holger,

Now several *-gnome-desktop tasks have been added.  Probably each of
them should have a corresponding *-gnome-flash-desktop task
just like this japanese-gnome-flashback-desktop task.

Thanks,
-- 
YOSHINO Yoshihito 



Bug#984614: #984614 - fixed in unstable

2021-04-18 Thread Javier Fernandez-Sanguino
El mar., 13 abr. 2021 19:51, Chris Hofstaedtler  escribió:

> Hello again,
>
> just in case you are not aware - if snort should stay in testing,
> someone will need to file an unblock bug against release.debian.org.
>

This was done already:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986908

The updated version will not transition into testing automatically.
>

Indeed. Let's see if the unblock request goes through.

Best regards

Javier


Bug#948698: [Python-modules-team] Bug#948698: Help needed?

2021-04-18 Thread Henning Sprang
Hi,

On Fri, Apr 16, 2021 at 10:34 PM Sandro Tosi  wrote:
>...
> i just noticed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892679
> which means there's no physical person currently maintaining this
> package: maybe this is a good opportunity for you, Henning, to start
> maintaining it within the DPT?

OK.

I thought just about a bit of technical work but if this is helpful, I can
try. I have to check the documentation (
https://wiki.debian.org/DebianMaintainer right?) to see if I can fulfil the
requirements for taking that role.

I have been involved with debian since a while but never has maintainer
responsibilities and wasnt very active in recent years, but finding someone
for the advocacy should be doable.

Do you suggest anything specific i should do as a next step that i might
not read in the above document?

I see also there is a newer version of the package on salsa already, not up
to date with upstream, but more current:
https://salsa.debian.org/python-team/packages/flask-sqlalchemy
That’s probably what has been mentioned in the earlier conversations about
this bug.
But it seems not to have made it to the archive...

Thanks,
Henning


-- 
Henning Sprang
http://www.sprang.de
-- 
Henning Sprang
http://www.sprang.de


Bug#972230: Bug#976477 marked as pending in jruby

2021-04-18 Thread Markus Koschany
Hi,

I'm just investigating the current open RC bugs for the debian-java maintained
packages. You have marked #976477 and #977979 in jruby as pending. Could you
clarify why there hasn't been an upload yet? There also seems to be another RC
bug, #972230. Do you have any suggestions how we can include jruby in Debian
11? 

Regards,

Markus 




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


Bug#986861: pragha: No way of sorting album by track number

2021-04-18 Thread Pelle

On 17/04/2021 00:43, Gabriel F. T. Gomes wrote:
I just tested it under sway and the column selection pop up showed up 
normally.


I added a new user to the system. When starting Sway and Pragha with the 
default settings, the columns selection pop up does indeed show up. It 
must then be a configuration issue, perhaps some GTK settings rather 
than an issue with Pragha. I'm have no idea which setting, but it's 
strange that it appears to only be affecting Pragha.






OpenPGP_0x3A57CE276008178F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#987170: python3-dolfinx: python module missing wrapper functions

2021-04-18 Thread Matsievskiy S.V.
Package: python3-dolfinx
Version: 2019.2.0~git20210130.c14cb0a-4
Severity: important
X-Debbugs-Cc: seregaxvm.m...@gmail.com

Dear Maintainer,

Python3 module misses some C++ wrapped functions. One of those functions is
`dolfinx.cpp.la.scatter_forward`

In order to reproduce the problem run the following Python3 code:
```python
import dolfinx
from mpi4py import MPI
mesh = dolfinx.UnitSquareMesh(MPI.COMM_WORLD, 8, 8,
dolfinx.cpp.mesh.CellType.quadrilateral)
V = dolfinx.FunctionSpace(mesh, ("CG", 2))
uex = dolfinx.Function(V)
uex.interpolate(lambda x: 1 + x[0]**2 + 2 * x[1]**2)
dolfinx.cpp.la.scatter_forward(uex.x)
```

This code throws error `AttributeError: module 'dolfinx.cpp.la' has no
attribute 'scatter_forward'` on Debian but runs just fine on the dockerized
jupyter notebook provided by https://github.com/jorgensd/dolfinx-tutorial


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

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

Versions of packages python3-dolfinx depends on:
ii  python3 3.9.2-2
ii  python3-dolfinx-real2019.2.0~git20210130.c14cb0a-4
ii  python3-numpy [python3-numpy-abi9]  1:1.19.5-1

python3-dolfinx recommends no packages.

Versions of packages python3-dolfinx suggests:
ii  dolfinx-doc  2019.2.0~git20210130.c14cb0a-4



Bug#987163: mirror submission for mirrors.sth.sze.hu

2021-04-18 Thread SzE - NetClub
Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.sth.sze.hu
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: SzE - NetClub 
Country: HU Hungary
Location: Gyor




Trace Url: http://mirrors.sth.sze.hu/debian/project/trace/
Trace Url: http://mirrors.sth.sze.hu/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.sth.sze.hu/debian/project/trace/mirrors.sth.sze.hu



Bug#987162: mirror submission for mirrors.sth.sze.hu

2021-04-18 Thread SzE - NetClub
Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.sth.sze.hu
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: SzE - NetClub 
Country: HU Hungary
Location: Gyor




Trace Url: http://mirrors.sth.sze.hu/debian/project/trace/
Trace Url: http://mirrors.sth.sze.hu/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.sth.sze.hu/debian/project/trace/mirrors.sth.sze.hu



Bug#987161: mirror submission for mirrors.sth.sze.hu

2021-04-18 Thread SzE - NetClub
Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.sth.sze.hu
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: SzE - NetClub 
Country: HU Hungary
Location: Győr




Trace Url: http://mirrors.sth.sze.hu/debian/project/trace/
Trace Url: http://mirrors.sth.sze.hu/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.sth.sze.hu/debian/project/trace/mirrors.sth.sze.hu



Bug#987159: broadcom-sta-dkms: error(-1) from calls to @wl_dev_intvar_get; @wl_cfg80211_get_tx_power by networkctl

2021-04-18 Thread Philip Stewart
Thanks Roger, unfortunately both errors remain after updating to 
broadcom-sta-dkms/experimental,now 6.30.223.271-16~exp1.


However, on a more positive note, 'iwlist wlan0 txpower' does seems to 
be report correctly following the update.


Cheers, Phil

On Mon, 19 Apr, 2021 at 05:04, Roger Shimizu  
wrote:

On Mon, Apr 19, 2021 at 1:33 AM Philip Stewart
 wrote:


 Package: broadcom-sta-dkms
 Version: 6.30.223.271-15
 Severity: minor

 Dear Maintainer,

 Calls to networkctl, e.g. 'networkctl' or 'networkctl status wlan0',
 result in the following error messages in dmesg:

 [ 6969.831960] ERROR @wl_dev_intvar_get :
 [ 6969.831968] error (-1)
 [ 6969.831979] ERROR @wl_cfg80211_get_tx_power :
 [ 6969.831982] error (-1)

 I haven't yet observed any significant detrimental effect as a 
result
 of the errors, merely incomplete status reporting, e.g. missing 
access

 point MAC address.


Could you kindly try 6.30.223.271-16~exp1 in experimental?
* 
https://tracker.debian.org/news/1180272/accepted-broadcom-sta-630223271-16exp1-source-all-into-experimental/


It includes some patches to improve txpower, mac setting, etc.

Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1




Bug#969264: firmware-iwlwifi:

2021-04-18 Thread Xiaoguang Xue
Hi,

This issue still exist in the most recent Debian 11 (testing) setup
(5.10.0-6-amd64), although there are no huge impacts on my wifi
speed/reliability.

Let me know if you need any more inforation.

Regards,

Sunney


On Wed, 24 Mar 2021 19:36:05 +0100 maximilian attems  wrote:
> tags 969264 moreinfo
> stop
>
> > Version: 20200721-1
>
> > Wi-Fi connection has been behaving erratically, lots of lags - for
> > instance - in LAN-SSH connections.
>
> > $ lspci | grep "Network controller"
> > 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205
> > [Taylor Peak] (rev 34)
>
> Is this reproducible with current Debian testing?
>
> thank you for your report.
>
>


Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

2021-04-18 Thread Julian Andres Klode
On Sun, Apr 18, 2021 at 10:20:19PM +0200, Paul Gevers wrote:
> Hi Julian, David, SRM,
> 
> On Mon, 8 Jul 2019 09:11:48 +0200 Christoph Berg  wrote:
> > Fwiw, I think this needs fixing in buster, not just in unstable.
> 
> We're getting close to the release of bullseye and it has been brought
> to my attention that this bug is still unfixed in buster. Once we
> release bullseye, this bug is going to run havoc for our buster users.

That's not accurate. This is _only_ a problem for users of testing,
where the codename changes from time to time.

For stable users, this is not a problem at all, more the opposite. Those
poor souls who have stable in their sources.list won't suddenly get
upgraded to bullseye.


> 
> Can we somehow come up with a plan on how to handle this? Can we have a
> fix in the next point release? Are there faster options than just
> waiting some time after the next point release before we can release
> bullseye, e.g. could the SRM allow an update to stable for the change of
> an apt default to have the change earlier than the next point release?

I have no intention of issuing a stable update.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature


Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

2021-04-18 Thread Paul Gevers
Hi Julian, David, SRM,

On Mon, 8 Jul 2019 09:11:48 +0200 Christoph Berg  wrote:
> Fwiw, I think this needs fixing in buster, not just in unstable.

We're getting close to the release of bullseye and it has been brought
to my attention that this bug is still unfixed in buster. Once we
release bullseye, this bug is going to run havoc for our buster users.

Can we somehow come up with a plan on how to handle this? Can we have a
fix in the next point release? Are there faster options than just
waiting some time after the next point release before we can release
bullseye, e.g. could the SRM allow an update to stable for the change of
an apt default to have the change earlier than the next point release?

Paul



OpenPGP_signature
Description: OpenPGP digital signature


Bug#984877: cubature FTCBFS: multiple reasons

2021-04-18 Thread Nilesh Patra
Fixed in salsa, will upload post bullseye

https://salsa.debian.org/science-team/cubature/-/commit/3882776a5814800455244f90354e13411a330562

Nilesh


signature.asc
Description: PGP signature


Bug#987159: broadcom-sta-dkms: error(-1) from calls to @wl_dev_intvar_get; @wl_cfg80211_get_tx_power by networkctl

2021-04-18 Thread Roger Shimizu
On Mon, Apr 19, 2021 at 1:33 AM Philip Stewart
 wrote:
>
> Package: broadcom-sta-dkms
> Version: 6.30.223.271-15
> Severity: minor
>
> Dear Maintainer,
>
> Calls to networkctl, e.g. 'networkctl' or 'networkctl status wlan0',
> result in the following error messages in dmesg:
>
> [ 6969.831960] ERROR @wl_dev_intvar_get :
> [ 6969.831968] error (-1)
> [ 6969.831979] ERROR @wl_cfg80211_get_tx_power :
> [ 6969.831982] error (-1)
>
> I haven't yet observed any significant detrimental effect as a result
> of the errors, merely incomplete status reporting, e.g. missing access
> point MAC address.

Could you kindly try 6.30.223.271-16~exp1 in experimental?
* 
https://tracker.debian.org/news/1180272/accepted-broadcom-sta-630223271-16exp1-source-all-into-experimental/

It includes some patches to improve txpower, mac setting, etc.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1



Bug#984414: yosys: ftbfs with GCC-11

2021-04-18 Thread Nilesh Patra
control: tags -1 patch

Fixed in salsa

https://salsa.debian.org/science-team/yosys/-/commit/3d384eef51754edeb802898796953c8fb839facc

Nilesh


signature.asc
Description: PGP signature


Bug#986742: unblock: ruby2.7/2.7.3-1

2021-04-18 Thread Sebastian Ramacher
On 2021-04-17 22:10:19 +0530, Utkarsh Gupta wrote:
> Hi Sebastian,
> 
> On Sat, Apr 17, 2021 at 3:08 PM Sebastian Ramacher  
> wrote:
> > Thanks, please go ahead and remove the moreinfo tag once the version is
> > available in unstable.
> 
> Uploaded to unstable, thanks. And removed the tag as well.

The builds on armel and armhf failed:
https://buildd.debian.org/status/fetch.php?pkg=ruby2.7=armel=2.7.3-1=1618744303=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#986220: fonts-font-awesome: unhandled directory to symlink conversion: /usr/share/fonts-font-awesome/scss -> ../sass/font-awesome

2021-04-18 Thread Thomas Goirand
Hi Andreas,

I tried to do what's below, but it doesn't seem to fix the problem. What
am I doing wrong here?

Cheers,

Thomas Goirand (zigo)

diff --git a/debian/fonts-font-awesome.postinst
b/debian/fonts-font-awesome.postinst
new file mode 100644
index ..51f176a4
--- /dev/null
+++ b/debian/fonts-font-awesome.postinst
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+set -e
+
+dpkg-maintscript-helper dir_to_symlink \
+   /usr/share/fonts-font-awesome/scss ../sass/font-awesome \
+   5.0.10+really4.7.0~dfsg-4.1~ fonts-font-awesome -- "$@"
+
+#DEBHELPER#
diff --git a/debian/fonts-font-awesome.postrm
b/debian/fonts-font-awesome.postrm
new file mode 100644
index ..51f176a4
--- /dev/null
+++ b/debian/fonts-font-awesome.postrm
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+set -e
+
+dpkg-maintscript-helper dir_to_symlink \
+   /usr/share/fonts-font-awesome/scss ../sass/font-awesome \
+   5.0.10+really4.7.0~dfsg-4.1~ fonts-font-awesome -- "$@"
+
+#DEBHELPER#
diff --git a/debian/fonts-font-awesome.preinst
b/debian/fonts-font-awesome.preinst
new file mode 100644
index ..51f176a4
--- /dev/null
+++ b/debian/fonts-font-awesome.preinst
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+set -e
+
+dpkg-maintscript-helper dir_to_symlink \
+   /usr/share/fonts-font-awesome/scss ../sass/font-awesome \
+   5.0.10+really4.7.0~dfsg-4.1~ fonts-font-awesome -- "$@"
+
+#DEBHELPER#



Bug#987169: RFS: newlib/3.3.0-1.1 [NMU] -- C library and math library for embedded systems

2021-04-18 Thread John Scott
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for Newlib:

 * Package name    : newlib
   Version : 3.3.0-1.1
   Upstream Author : Red Hat and others
 * URL : https://sourceware.org/newlib/
 * License : various
 * Vcs : https://salsa.debian.org/debian/newlib
   Section : devel

It builds those binary packages:

  newlib-source - C library and math library for embedded systems (source)
  libnewlib-arm-none-eabi - C library and math library compiled for bare metal 
using Cortex A/R/M
  libnewlib-doc - C library and math library intended for use on embedded 
systems (doc)
  libnewlib-dev - C library and math library intended for use on embedded 
systems

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/n/newlib/newlib_3.3.0-1.1.dsc

Changes since the last upload:

 newlib (3.3.0-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add newlib-source binary package to aid building for new targets.
 (Closes: #912271)

This change wouldn't normally be appropriate for an NMU, but the
maintainer, Agustin Henze, hasn't been responsive to my attempts for
contact, and is also on the LowThresholdNmu list and keeps the package
in the Debian group on Salsa for collaborative maintenance:
https://wiki.debian.org/LowThresholdNmu

I haven't encountered the maintainer previously, but believe in good
faith that these changes would be welcome and that the LowThresholdNmu
criterion are met by addressing a bug with important severity. My
interest in this bug, to introduce a newlib-source binary package, is
to unblock my progress on gcc-sh-elf, which is otherwise almost ready.

That package will bootstrap a toolchain by building GCC and Newlib
simultaneously in a combined build tree, which in my opinion is best
practice for embedded toolchains going forward.

The changelog is set to unstable in anticipation that I won't manage to
clear NEW before Bullseye is released. If anyone would be so kind to
sponsor me sooner, I could change that to experimental.


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


Bug#985563: RFS: binutils-sh-elf/1 [ITP] -- GNU binary utilities for embedded SuperH devices

2021-04-18 Thread John Scott
On Fri, 19 Mar 2021 19:30:45 -0400 John Scott  wrote:
> The package should be built against experimental.

I've come to realize that on the buildd's, packages from experimental
aren't pulled in unless required to satisfy the build dependencies.
Disregard this; it's not a big deal, except that the autopkgtest does
require GCC 11, but I don't think those are run for experimental
anyway.


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


Bug#926539: rootskel: steal-ctty no longer works on s390x

2021-04-18 Thread Philipp Kern
On 18.04.21 17:27, Salvatore Bonaccorso wrote:
> Is this bug still valid to be open?
> 
> The mentioned commit landed in 5.3-rc1, 4.19.54 and as well 4.9.183.

Unfortunately the daily debian-installer build (on Linux 5.10.0-6-s390x)
is still broken on qemu-system-s390x. So the s390x part is still true.

Kind regards
Philipp Kern



Bug#987168: fluidsynth: CVE-2021-28421

2021-04-18 Thread Salvatore Bonaccorso
Source: fluidsynth
Version: 2.1.7-1
Severity: grave
Tags: security upstream
Forwarded: https://github.com/FluidSynth/fluidsynth/issues/808
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for fluidsynth, filling it
as grave to be on safe side because of the use after free aspect. Let
me know if you disagree and we can downgrade. Still ideally it is
fixed for bullseye. It was othrwise marked no-dsa for buster, deemed
enought to be fixed via a point release.

CVE-2021-28421[0]:
| FluidSynth 2.1.7 contains a use after free vulnerability in
| sfloader/fluid_sffile.c that can result in arbitrary code execution or
| a denial of service (DoS) if a malicious soundfont2 file is loaded
| into a fluidsynth library.


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-28421
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28421
[1] https://github.com/FluidSynth/fluidsynth/issues/808
[2] https://github.com/FluidSynth/fluidsynth/pull/810

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#987167: unblock: jamulus/3.6.2+dfsg1-3

2021-04-18 Thread Thorsten Glaser
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@mirbsd.de

Please unblock package jamulus

[ Reason ]
This is threefold:
• I promised to write a manpage and only now was able to do so, as
  well as tackle the lintian duplicate file (in /usr/share/doc/) tag
• Upstream introduced a breaking change in the official server list
  so I updated the server list in the program
• A few targetted bugfixes:
  – correctly escape messages received from clients (HTML injection)
  – cease sending a packet to Cloudflare to determine the (nōn-NAT)
external interface / IP address (privacy fix)
  – add --serverpublicip to support running servers behind IPv4 NAT,
which is a prerequisite to make the privacy fix from above apply
(and very helpful to enable more users to run Jamulus instances)

Upstream also had the “great” idea to move their GitHub project, so
I updated all URLs (Homepage, debian/watch, UMEYAGA, docs, etc.) to
the new address. This is mostly because control passed from the
original developer to a project/group now.

[ Impact ]
• missing manpage
• upstream doesn’t commit to keep the old server DNS entries for
  the entire lifetime of Debian, mostly because they use the domain
  from the initial developer, who’s leaving the project, and the
  new servers use the new jamulus.io (shared) domain; users would
  have to specify the correct central servers on the command line
• possibility of HTML injection in messages
• privacy issue of sending a packet to Cloudflare (AIUI server-only)
• inability to correctly run servers behind IPv4 NAT in some situations
• old URLs that may or may not be kept alive indefinitely

[ Tests ]
I’ve manually tested most of the changes including running a server.

[ Risks ]
The patches are backports/cherry-picks from upstream, and this is a
leaf package, so I’d consider this low-risk. (In fact, the commits
to backport were pointed out to me by upstream.)

[ 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 ]

unblock jamulus/3.6.2+dfsg1-3
diff -Nru jamulus-3.6.2+dfsg1/debian/Jamulus.1 
jamulus-3.6.2+dfsg1/debian/Jamulus.1
--- jamulus-3.6.2+dfsg1/debian/Jamulus.11970-01-01 01:00:00.0 
+0100
+++ jamulus-3.6.2+dfsg1/debian/Jamulus.12021-04-11 16:04:20.0 
+0200
@@ -0,0 +1,272 @@
+.\" Manual page for Jamulus
+.\" Copyright (c) 2021
+.\" mirabilos 
+.\" Published under the same terms as Jamulus itself.
+.\"-
+.Dd April 11, 2021
+.Dt JAMULUS 1
+.Os
+.Sh NAME
+.Nm Jamulus
+.Nd real-time collaborative music session
+.Sh SYNOPSIS
+.Nm
+.Op Fl c | Fl \-connect Ar address
+.Op Fl d | Fl \-discononquit
+.Op Fl e | Fl \-centralserver Ar hostname
+.Op Fl F | Fl \-fastupdate
+.Op Fl f | Fl \-listfilter Ar filter
+.Op Fl h | Fl \&? | Fl \-help
+.Op Fl i | Fl \-inifile Ar file
+.Op Fl j | Fl \-nojackconnect
+.Op Fl L | Fl \-licence
+.Op Fl l | Fl \-log Ar file
+.Op Fl M | Fl \-mutestream
+.Op Fl m | Fl \-htmlstatus Ar file
+.Op Fl n | Fl \-nogui
+.Op Fl o | Fl \-serverinfo Ar info
+.Op Fl p | Fl \-port Ar number
+.Op Fl R | Fl \-recording Ar directory
+.Op Fl s | Fl \-server
+.Op Fl T | Fl \-multithreading
+.Op Fl t | Fl \-notranslation
+.Op Fl u | Fl \-numchannels
+.Op Fl v | Fl \-version
+.Op Fl w | Fl \-welcomemessage Ar message
+.Op Fl z | Fl \-startminimized
+.Op Fl \-clientname Ar name
+.Op Fl \-ctrlmidich Ar MIDISetup
+.Op Fl \-mutemyown
+.Op Fl \-norecord
+.Op Fl \-serverpublicip Ar ip
+.Op Fl \-showallservers
+.Op Fl \-showanalyzerconsole
+.Sh DESCRIPTION
+.Nm Jamulus ,
+a low-latency audio client and server, enables musicians to perform real-time
+.Dq jam
+sessions over the internet.
+It is available across multiple platforms, so participants of any field
+can communicate without specialist setup requirements.
+This is not restricted to music, of course; other use
+.Pq perhaps conferencing?
+is also possible.
+.Pp
+One participant starts
+.Nm
+in server mode, ideally on a dedicated server (virtual) machine;
+all participants start the (graphical) client which transmits audio
+to the server, receiving back a mixed stream.
+Use of a metronome is recommended.
+Clients should be connected using ethernet, not wireless, and use
+proper headphone and microphone connections, not Bluetooth.
+The server should run on a low-latency system, ideally not a VM.
+.Pp
+Running
+.Nm
+without any extra options launches the full graphical client.
+.Pp
+The options are as follows:
+.Bl -tag -width Ds
+.It Fl c | Fl \-connect Ar address
+.Pq client mode only
+connect to the given server
+.Ar address
+.Pq Ar hostname Ns Op Ar :port
+at startup
+.It Fl d | Fl \-discononquit
+.Pq server mode only
+disconnect all clients on quit
+.It Fl e | Fl \-centralserver Ar hostname
+.Pq server mode only
+make the server public and set its genre by setting the address
+of the central 

Bug#987166: Description truncated

2021-04-18 Thread Josh Triplett
Package: libnss-unknown
Version: 0.0.2-2+b1
Severity: minor
X-Debbugs-Cc: j...@joshtriplett.org

The package description appears truncated after "between".



Bug#987165: offlineimap3: flaky autopkgtest: OfflineImapError("Failed to start "

2021-04-18 Thread Paul Gevers
Source: offlineimap3
Version: 0.0~git20210225.1e7ef9e+dfsg-3
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] and I noticed the it fails regularly,
while a rerun passes. I copied some of the output at the bottom
of this report.

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

Paul

[1] ...
https://ci.debian.net/packages/o/offlineimap3/testing/amd64/
https://ci.debian.net/packages/o/offlineimap3/testing/arm64/
https://ci.debian.net/packages/o/offlineimap3/testing/armhf/
https://ci.debian.net/packages/o/offlineimap3/testing/i386/
https://ci.debian.net/packages/o/offlineimap3/testing/ppc64el/


https://ci.debian.net/data/autopkgtest/testing/amd64/o/offlineimap3/11437720/log.gz

autopkgtest [04:27:00]: test testmail: [---
'/tmp/autopkgtest-lxc.7vdzo2pi/downtmp/build.iAb/src/debian/tests' ->
'/tmp/autopkgtest-lxc.7vdzo2pi/downtmp/autopkgtest_tmp/tests'
'/tmp/autopkgtest-lxc.7vdzo2pi/downtmp/build.iAb/src/debian/tests/control'
-> '/tmp/autopkgtest-lxc.7vdzo2pi/downtmp/autopkgtest_tmp/tests/control'
'/tmp/autopkgtest-lxc.7vdzo2pi/downtmp/build.iAb/src/debian/tests/offlinerc'
-> '/tmp/autopkgtest-lxc.7vdzo2pi/downtmp/autopkgtest_tmp/tests/offlinerc'
'/tmp/autopkgtest-lxc.7vdzo2pi/downtmp/build.iAb/src/debian/tests/testmail'
-> '/tmp/autopkgtest-lxc.7vdzo2pi/downtmp/autopkgtest_tmp/tests/testmail'
'/tmp/autopkgtest-lxc.7vdzo2pi/downtmp/build.iAb/src/debian/tests/user.py'
-> '/tmp/autopkgtest-lxc.7vdzo2pi/downtmp/autopkgtest_tmp/tests/user.py'
OfflineIMAP 7.3.0
  Licensed under the GNU GPL v2 or any later version (with an OpenSSL
exception)
imaplib2 v3.05, Python v3.9.2, OpenSSL 1.1.1k  25 Mar 2021
  imaplib2: 3.05
Remote repository 'Remote': type 'IMAP'
Host: localhost Port: None SSL: False
Establishing connection to localhost:143 (Remote)
Server supports ID extension.
Server welcome string: b'* OK [CAPABILITY IMAP4rev1 SASL-IR
LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ STARTTLS AUTH=PLAIN] Dovecot
(Debian) ready.'
Server capabilities: ('IMAP4REV1', 'SASL-IR', 'LOGIN-REFERRALS', 'ID',
'ENABLE', 'IDLE', 'SORT', 'SORT=DISPLAY', 'THREAD=REFERENCES',
'THREAD=REFS', 'THREAD=ORDEREDSUBJECT', 'MULTIAPPEND', 'URL-PARTIAL',
'CATENATE', 'UNSELECT', 'CHILDREN', 'NAMESPACE', 'UIDPLUS',
'LIST-EXTENDED', 'I18NLEVEL=1', 'CONDSTORE', 'QRESYNC', 'ESEARCH',
'ESORT', 'SEARCHRES', 'WITHIN', 'CONTEXT=SEARCH', 'LIST-STATUS',
'BINARY', 'MOVE', 'SNIPPET=FUZZY', 'PREVIEW=FUZZY', 'STATUS=SIZE',
'SAVEDATE', 'LITERAL+', 'NOTIFY', 'SPECIAL-USE')

Folderlist:
 INBOX

Local repository 'Local': type 'Maildir'
Folderlist:


OfflineIMAP 7.3.0
  Licensed under the GNU GPL v2 or any later version (with an OpenSSL
exception)
imaplib2 v3.05, Python v3.9.2, OpenSSL 1.1.1k  25 Mar 2021
Account sync Test:
 *** Processing account Test
 Establishing connection to localhost:143 (Remote)
 ERROR: Failed to start TLS connection: command: CAPABILITY =>
connection terminated
 *** Finished account 'Test' in 3:00
ERROR: Exceptions occurred during the run!
ERROR: Failed to start TLS connection: command: CAPABILITY => connection
terminated

Traceback:
  File "/usr/share/offlineimap3/offlineimap/accounts.py", line 298, in
syncrunner
self.__sync()
  File "/usr/share/offlineimap3/offlineimap/accounts.py", line 374, in
__sync
remoterepos.getfolders()
  File "/usr/share/offlineimap3/offlineimap/repository/IMAP.py", line
667, in getfolders
imapobj = self.imapserver.acquireconnection()
  File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 588, in
acquireconnection
self.__authn_helper(imapobj)
  File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 434, in
__authn_helper
self.__start_tls(imapobj)
  File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 330, in
__start_tls
raise OfflineImapError("Failed to start "

autopkgtest [04:30:08]: test testmail: ---]



OpenPGP_signature
Description: OpenPGP digital signature


Bug#984862: iptables-netflow-dkms: module wants to build with gcc instead of kernel's compiler

2021-04-18 Thread Andreas Beckmann

On 18/04/2021 16.36, Axel Beckert wrote:

Hi Andreas,

Andreas Beckmann wrote:

Please bump the dkms dependency for bullseye, this issue can trigger on
upgrades from buster to bullseye where iptables-netflow-dkms is upgraded
before dkms.


Should that patch really close this bug report? IIRC you didn't close
all these bug reports with the dkms patch. Was this in anticipation of
this version bumping


Yes, as it will avoid broken combinations ;-)


or do you still want us to get upstream to do it
"right" (whatever exactly that would be).


I don't know a generic way to get the kernel compiler from the headers, 
i.e. something that would also work for e.g. vanilla kernels. Thus I 
know of no upstreamable solution.


I find it still curious that it worked for iptables-netflow-dkms out of 
the box in buster with gcc-8 but no gcc installed.


Andreas

PS: I don't do forced module compile tests for upgrades in piuparts due 
to too many failures (extra kernel headers are only installed while 
testing a -dkms package within a distro), but if the package 
dependencies pull in the headers, well, we are building modules ;-)




Bug#987160: gap-core: missing gap in /u/l/gap or gac in /u/l/x/gap

2021-04-18 Thread Bill Allombert
On Sun, Apr 18, 2021 at 06:21:14PM +0200, Jerome Benoit wrote:
> Package: gap-core
> Version: 4r10p0-7

Hello Jerome,
4r10p0-7 is not the version in sid ?

> I have just packaged the last version 4.7.1 of gap-io.
> Its build machinery has changed. It now uses a Gap makefile Makefile.gappkg .
> This makefile implicitly assumes (?=) that the gap and gac are into GAPPATH
> as passed at configuration time. The GAPPATH is /usr/lib/gap or 
> /usr/lib//gap :
> the former contains gac, the latter gap. It would be nice to have both at 
> least
> in one of the GAPPATH.

Why not set GAPPATH to /usr/bin then ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



Bug#987153: Typo in anacron log message: "ststus" should be "status"

2021-04-18 Thread Jonathan Kamens
Package: anacron
Version: 2.3-30
Tags: patch

There is a typo in the log message generated by anacron when it can't
send email. It says "ststus" when it should say "status".

>From 2c1a21af2eb173119187489e55605f1ec292d728 Mon Sep 17 00:00:00 2001
From: Jonathan Kamens 
Date: Sun, 18 Apr 2021 09:51:50 -0400
Subject: [PATCH] Fix typo in log message ("ststus" => "status")

---
 runjob.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/runjob.c b/runjob.c
index b5ed26c..f51b2e6 100644
--- a/runjob.c
+++ b/runjob.c
@@ -195,7 +195,7 @@ tend_mailer(job_rec *jr, int status)
 {
 if (WIFEXITED(status) && WEXITSTATUS(status) != 0)
complain("Tried to mail output of job `%s', "
-"but mailer process (" SENDMAIL ") exited with ststus %d",
+"but mailer process (" SENDMAIL ") exited with status %d",
 jr->ident, WEXITSTATUS(status));
 else if (!WIFEXITED(status) && WIFSIGNALED(status))
complain("Tried to mail output of job `%s', "
-- 
2.30.2



Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

2021-04-18 Thread Jamie Zawinski
As I said, it's already fixed in 6.00. The fix is just to configure without 
setcap and use setuid instead, which works properly with Mesa.

I assume that having 6.00 distributed by Debian prior to 2035 would be asking 
too much, but we dare to dream.



Bug#969747: xfce4-weather-plugin: Weather plugin provides "No data" despite having internet connection and correct location

2021-04-18 Thread Yves-Alexis Perez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2020-09-07 at 13:43 -0400, FX wrote:
>    Weather plugin was functioning fine just days prior. I thought there was
> a
> chance it was off because of my location, so I added a new instance of it to
> the panel and set the location to NYC and it still said no data.
> 
> Thank you for your help

Hi,

I've prepared an update, I'm waiting for an ack from the release team before
uploading it to stable-proposed-updates. Then it should appear in the next
point release.

Sorry for the inconvenience and the delay for fixing that.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmB8bUoACgkQ3rYcyPpX
RFuXGwgA6VNyJtB6q+0NXES0Llf0HhrqDLh3CShsL7XOYYh32QmF2FESgOYrViu0
hO7yfF9ahIrstHFQ8t4Z96Si0xrNePMLYR3YdRhTaTRXcQtIQIkBGb+lZOYCMP/+
tIldWR1MJwFzvgvXfZ2IrKWnAIz1NOjaJr7y1WHDpVmF2/p3SvoxWp2AbE9amIsL
wFEBuizWULTl6t63lr8lc1MLlIdWG6rhg74POIt/d853adPlvNIKBEZPOeN1jXyh
x4lONxcvM+qoC53N+AOMYX5DsDfrAyA8kRwsCVldtRx+SDJKvasvHlLwDKm0FSqh
qONPY7O1S4KsEWC/UAMtX+PJfvahFA==
=2Cxt
-END PGP SIGNATURE-



Bug#987164: buster-pu: package xfce4-weather-plugin/0.8.10-2

2021-04-18 Thread Yves-Alexis Perez
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu


[ Reason ]
Hi,
the Xfce weather plugin in stable is broken (since quite a while
actually) because of an API deprecation at met.no.

There are two open bugs (#970259, #969747) by users. Upstream has
already ported newer version to the new API, but I did a smaller update
just to use the new API.

I've done a few test in stable and the plugin does seem to be fixed with
the update.

The new package also includes a d/gbp.conf addition in order to be able
to build the package in git (since we were previously using svn), I hope
that's not an issue.

The debdiff is attached for review. Since it's broken since quite a
while there's no specific urgency but it'd be nice if it was done for
the next point release.

Regards,
-- 
Yves-Alexis
diff -Nru xfce4-weather-plugin-0.8.10/debian/changelog 
xfce4-weather-plugin-0.8.10/debian/changelog
--- xfce4-weather-plugin-0.8.10/debian/changelog2017-10-15 
20:38:46.0 +0200
+++ xfce4-weather-plugin-0.8.10/debian/changelog2021-04-18 
19:23:36.0 +0200
@@ -1,3 +1,10 @@
+xfce4-weather-plugin (0.8.10-2) buster; urgency=medium
+
+  * d/patches: backport upstream port to 2.0 met.no API
+(Closes: #970259, #969747)
+
+ -- Yves-Alexis Perez   Sun, 18 Apr 2021 19:23:36 +0200
+
 xfce4-weather-plugin (0.8.10-1) unstable; urgency=medium
 
   [ Unit 193 ]
diff -Nru 
xfce4-weather-plugin-0.8.10/debian/patches/0001-port-weather-plugin-to-2.0-met.no-API.patch
 
xfce4-weather-plugin-0.8.10/debian/patches/0001-port-weather-plugin-to-2.0-met.no-API.patch
--- 
xfce4-weather-plugin-0.8.10/debian/patches/0001-port-weather-plugin-to-2.0-met.no-API.patch
 1970-01-01 01:00:00.0 +0100
+++ 
xfce4-weather-plugin-0.8.10/debian/patches/0001-port-weather-plugin-to-2.0-met.no-API.patch
 2021-04-18 19:23:36.0 +0200
@@ -0,0 +1,67 @@
+From: Yves-Alexis Perez 
+Date: Sun, 18 Apr 2021 19:12:09 +0200
+Subject: port weather plugin to 2.0 met.no API
+
+---
+ panel-plugin/weather.c | 29 -
+ 1 file changed, 12 insertions(+), 17 deletions(-)
+
+diff --git a/panel-plugin/weather.c b/panel-plugin/weather.c
+index c096795..55fe151 100644
+--- a/panel-plugin/weather.c
 b/panel-plugin/weather.c
+@@ -578,8 +578,8 @@ update_handler(plugin_data *data)
+ {
+ gchar *url;
+ gboolean night_time;
+-time_t now_t, end_t;
+-struct tm now_tm, end_tm;
++time_t now_t;
++struct tm now_tm;
+ 
+ g_assert(data != NULL);
+ if (G_UNLIKELY(data == NULL))
+@@ -614,22 +614,16 @@ update_handler(plugin_data *data)
+ data->astro_update->next = time_calc_hour(now_tm, 1);
+ data->astro_update->started = TRUE;
+ 
+-/* calculate date range for request */
+-end_t = time_calc_day(now_tm, ASTRODATA_MAX_DAYS);
+-end_tm = *localtime(_t);
+-
+ /* build url */
+-url = g_strdup_printf("https://api.met.no/weatherapi/sunrise/1.1/?;
+-  "lat=%s;lon=%s;"
+-  "from=%04d-%02d-%02d;"
+-  "to=%04d-%02d-%02d",
++url = g_strdup_printf("https://api.met.no/weatherapi;
++  "/sunrise/2.0/?lat=%s=%s&"
++  "date=%04d-%02d-%02d&"
++  "offset=00:00=%u",
+   data->lat, data->lon,
+   now_tm.tm_year + 1900,
+   now_tm.tm_mon + 1,
+   now_tm.tm_mday,
+-  end_tm.tm_year + 1900,
+-  end_tm.tm_mon + 1,
+-  end_tm.tm_mday);
++  data->forecast_days);
+ 
+ /* start receive thread */
+ g_message(_("getting %s"), url);
+@@ -645,10 +639,11 @@ update_handler(plugin_data *data)
+ data->weather_update->started = TRUE;
+ 
+ /* build url */
+-url =
+-g_strdup_printf("https://api.met.no/weatherapi;
+-"/locationforecastlts/1.3/?lat=%s;lon=%s;msl=%d",
+-data->lat, data->lon, data->msl);
++url = g_strdup_printf("https://api.met.no;
++  "/weatherapi/locationforecast/%s/"
++  "classic?lat=%s=%s=%d",
++  "2.0",
++  data->lat, data->lon, data->msl);
+ 
+ /* start receive thread */
+ g_message(_("getting %s"), url);
diff -Nru xfce4-weather-plugin-0.8.10/debian/patches/series 
xfce4-weather-plugin-0.8.10/debian/patches/series
--- xfce4-weather-plugin-0.8.10/debian/patches/series   1970-01-01 
01:00:00.0 +0100
+++ xfce4-weather-plugin-0.8.10/debian/patches/series   2021-04-18 
19:23:36.0 +0200
@@ -0,0 +1 @@
+0001-port-weather-plugin-to-2.0-met.no-API.patch


Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

2021-04-18 Thread Tormod Volden
On Sun, Apr 18, 2021 at 7:04 PM Salvatore Bonaccorso wrote:
> Sure I did as I'm on the team alias as well. Given it looks unlikely
> that mesa will fix it (at the moment?) I though/think we should
> probably do something on xscreensaver's side in Debian as well.
>
> Is the sonar screensaver frequently used? How about dropping it
> instead? Thinking about it in the last hour this raised to be a
> possible option to not expose the bug.

Yes, I think dropping the set_cap is the easy way out of here. sonar
will still be visually pleasing, just not so interesting.

I don't think we should wait for upstream mesa to fix this, but can't
we just patch Debian mesa with getauxval() checks? Since mesa
currently does the geteuid check, it seems logical to fix it there
also for other situations than sonar.

On Sun, Apr 18, 2021 at 7:15 PM Salvatore Bonaccorso wrote:
> Another option would be to extract the needed changes from 6.00
> upstream accordingly if the thread in
> https://www.openwall.com/lists/oss-security/2021/04/17/1 gives us no
> other solutions.

Sure, if that is easily backportable we should do it. I haven't looked
at it though so I cannot tell.

Tormod



Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

2021-04-18 Thread Salvatore Bonaccorso
Hi Tormod,

On Sun, Apr 18, 2021 at 07:04:37PM +0200, Salvatore Bonaccorso wrote:
> Hi Tormod,
> 
> [Adding the team@s.d.o to CC as we do not automatically follow
> security tagged bugs]
> 
> On Sun, Apr 18, 2021 at 06:57:53PM +0200, Tormod Volden wrote:
> > Indeed, as Jamie points out, the problem is in Mesa.
> > 
> > Salvatore, why did you file this against xscreensaver? I thought you
> > had followed the e-mail discussion we had with Tavis?
> 
> Sure I did as I'm on the team alias as well. Given it looks unlikely
> that mesa will fix it (at the moment?) I though/think we should
> probably do something on xscreensaver's side in Debian as well.
> 
> Is the sonar screensaver frequently used? How about dropping it
> instead? Thinking about it in the last hour this raised to be a
> possible option to not expose the bug.

Another option would be to extract the needed changes from 6.00
upstream accordingly if the thread in
https://www.openwall.com/lists/oss-security/2021/04/17/1 gives us no
other solutions.

Regards,
Salvatore



Bug#986806: CVE-2021-28965

2021-04-18 Thread Salvatore Bonaccorso
Hi Pirate,

On Sun, Apr 18, 2021 at 10:26:31PM +0530, Pirate Praveen wrote:
> On Sun, 18 Apr 2021 15:04:56 +0200 Salvatore Bonaccorso 
> wrote:
> > Hi,
> >
> > On Sat, Apr 17, 2021 at 10:34:24PM +0530, Pirate Praveen wrote:
> > >
> > >
> > > On Sat, Apr 17, 2021 at 10:16 pm, Utkarsh Gupta 
> wrote:
> > > > Makes sense. Probably the time to RM ruby-rexml from the archive is
> > > > *now*?
> > >
> > > Requested removal from archive in #987101
> >
> > Thanks for filling the removal!
> >
> > I fear this has though some additional work to be done, trying to
> > simulate the removal the following is shown:
> >
> > Will remove the following packages from sid:
> >
> > ruby-rexml |3.2.4-2 | source, all
> >
> > Maintainer: Debian Ruby Extras Maintainers
> 
> >
> > --- Reason ---
> >
> > --
> >
> > Checking reverse dependencies...
> > # Broken Depends:
> > ruby-kramdown: ruby-kramdown
> >
> > # Broken Build-Depends:
> > ruby-kramdown: ruby-rexml
> >
> > Dependency problem found.
> >
> > Can you change tue Build-Depends of ruby-kramdown?
> 
> I think that is a bug in dak, as libruby2.7 Provides ruby-rexml.

Ack, I see.

Regards,
Salvatore



Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

2021-04-18 Thread Salvatore Bonaccorso
Hi Tormod,

[Adding the team@s.d.o to CC as we do not automatically follow
security tagged bugs]

On Sun, Apr 18, 2021 at 06:57:53PM +0200, Tormod Volden wrote:
> Indeed, as Jamie points out, the problem is in Mesa.
> 
> Salvatore, why did you file this against xscreensaver? I thought you
> had followed the e-mail discussion we had with Tavis?

Sure I did as I'm on the team alias as well. Given it looks unlikely
that mesa will fix it (at the moment?) I though/think we should
probably do something on xscreensaver's side in Debian as well.

Is the sonar screensaver frequently used? How about dropping it
instead? Thinking about it in the last hour this raised to be a
possible option to not expose the bug.

Should we ignore the issue otherwise?

Regards,
Salvatore



Bug#970259: Weather API update

2021-04-18 Thread Yves-Alexis Perez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2021-04-18 at 19:04 +0200, Yves-Alexis Perez wrote:
> Hi Pavel, thanks for the patch. I'm a bit confused though. As far as I
> cantell, it updates only the “sunrise” part of the request, not the
> “weather”
> part.
> 
> It might be that using the wrong sunrise API prevents the whole plugin to
> work, but can you confirm that with the patch both the sunrise *and* the
> weather work fine?

Nevermind, please disregard this mail, I looked at a wrong file missing one
hunk.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmB8ZxgACgkQ3rYcyPpX
RFtCZQf/aXja/BrGS7xA2a/3z+eI1vmwGU7EHJWmAtn11LzwhJbJVn3cfwZ5uMXl
2PNERJzqmbdBvmgT8nkfmlfjul2FYH5A0MCyzGh/kEatq/upH9YFjPhCD9lTWNcK
ZCKY0wf+yKA2QB/IJn7zLnzQ+bnU1EqC/YVPoqiZqP69lIlXjbBnkQ8UmRc/UCWE
Hck3gfRu3GOQVAk2RCGgttgjHkrLovfu39uj12U6sq8HwqjYKGmJ2fjnaAPM4JX3
wAqgnNq8dZ/goHiQpOnqdlaHm6y19b1GOo8Iy7j4BD0GgK89S7OtNrWhiF7jGoEd
YvSlC2mh1t5l+aD4YJJbQZl5WyRVDg==
=n6kR
-END PGP SIGNATURE-



Bug#970259: Weather API update

2021-04-18 Thread Yves-Alexis Perez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2020-09-16 at 08:20 +0300, Pavel R. wrote:
> Hello, I've fixed the plugin by bumping weather API version to 2.0
> 
> Patch is attached
Hi Pavel, thanks for the patch. I'm a bit confused though. As far as I
cantell, it updates only the “sunrise” part of the request, not the “weather”
part.

It might be that using the wrong sunrise API prevents the whole plugin to
work, but can you confirm that with the patch both the sunrise *and* the
weather work fine?

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmB8ZrUACgkQ3rYcyPpX
RFtPvQgAk/EVf7jzpBmJ/yDzwd2C+7WIMyGcxVY4U4XdzKR+aihMuWlHbYDoBmRI
AFDSp61idAquOgM4uB1rrFWqRyQOvI0thhE9u+gDaK8NYrn29Rh8Z+pNJBJ6Udps
FZakxkF780+BPscp7i+zAXspt1CWw6Y1rQM06KjrScVtYRUR3foV2gwM1J+4hPj6
lMfdDhVDiFkNRcDIqX6TPmfd+H53qrOogKxDl6nJ7mJAO1snTT4VZPmA53875BFK
V/0TuY51vqMeUj1Kg2eCYgE61CRYiI8R81yRsZQK7f4XUmUNfkS1lbhV+Ui9kMcc
GFg4IoS9CtEkOSl2xQYpW7Leq48L6Q==
=9YzF
-END PGP SIGNATURE-



Bug#964494: Info received (Bug#964494: File system corruption with ext3 + kernel-4.19.0-9-amd64)

2021-04-18 Thread Salvatore Bonaccorso
Hi,

On Sun, Apr 18, 2021 at 09:04:52AM -0700, Sarah Newman wrote:
> On 4/18/21 8:36 AM, Salvatore Bonaccorso wrote:
> > On Tue, Aug 18, 2020 at 10:02:12PM -0700, Sarah Newman wrote:
> > > We haven't had any further reports of file system corruption. I
> > > would guess that converting to EXT4 is sufficient to avoid the
> > > issue.
> > 
> > Should this bug be closed or is there anything we still can/should do
> > about it?
> > 
> > Regards,
> > Salvatore
> > 
> 
> You can close it.

Okay, let's do that then so.

Regards,
Salvatore



Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

2021-04-18 Thread Tormod Volden
Indeed, as Jamie points out, the problem is in Mesa.

Salvatore, why did you file this against xscreensaver? I thought you
had followed the e-mail discussion we had with Tavis?

Tormod



Bug#986806: CVE-2021-28965

2021-04-18 Thread Pirate Praveen
On Sun, 18 Apr 2021 15:04:56 +0200 Salvatore Bonaccorso 
 wrote:

> Hi,
>
> On Sat, Apr 17, 2021 at 10:34:24PM +0530, Pirate Praveen wrote:
> >
> >
> > On Sat, Apr 17, 2021 at 10:16 pm, Utkarsh Gupta 
 wrote:
> > > Makes sense. Probably the time to RM ruby-rexml from the archive 
is

> > > *now*?
> >
> > Requested removal from archive in #987101
>
> Thanks for filling the removal!
>
> I fear this has though some additional work to be done, trying to
> simulate the removal the following is shown:
>
> Will remove the following packages from sid:
>
> ruby-rexml |3.2.4-2 | source, all
>
> Maintainer: Debian Ruby Extras Maintainers 


>
> --- Reason ---
>
> --
>
> Checking reverse dependencies...
> # Broken Depends:
> ruby-kramdown: ruby-kramdown
>
> # Broken Build-Depends:
> ruby-kramdown: ruby-rexml
>
> Dependency problem found.
>
> Can you change tue Build-Depends of ruby-kramdown?

I think that is a bug in dak, as libruby2.7 Provides ruby-rexml.



Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

2021-04-18 Thread Jamie Zawinski
Already fixed in XScreenSaver 6.00. 

The bug is in Mesa: it has a panoply of env vars that do what LD_PRELOAD does, 
except Mesa only checks geteuid instead of checking getauxval AT_SECURE, as the 
kernel does. So anything that uses both Mesa and setcap is vulnerable.

Ironically, using setuid instead of setcap does not have the vulnerability.



Bug#987160: gap-core: missing gap in /u/l/gap or gac in /u/l/x/gap

2021-04-18 Thread Jerome Benoit
Package: gap-core
Version: 4r10p0-7
Severity: normal

Dear Maintainer,

I have just packaged the last version 4.7.1 of gap-io.
Its build machinery has changed. It now uses a Gap makefile Makefile.gappkg .
This makefile implicitly assumes (?=) that the gap and gac are into GAPPATH
as passed at configuration time. The GAPPATH is /usr/lib/gap or 
/usr/lib//gap :
the former contains gac, the latter gap. It would be nice to have both at least
in one of the GAPPATH.

Cheers,
Jerome


-- System Information:
Debian Release: Sid
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-8-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)



Bug#986267: xfce4-appfinder: Application Finder doesn't show up xfce4's "Add New Items" window

2021-04-18 Thread Yves-Alexis Perez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2021-04-02 at 00:57 -0400, Ron Murray wrote:
> 
>    I noticed "Application Finder" in a Debian Live build I'd made, and
> wondered why I'd never seen it on my normal Debian box. So I tried to
> add it with xfce4's "Add New Items" option, but it doesn't show up
> there.
> 
Hi Ron,

sorry but it's unclear to me what you mean when you say “I noticed …” where
exactly you noticed and what exactly you tried to do next. What is this “Add
new items” menu you're talking about ? If it is the panel plugin menu, then
there is no “application finder plugin”, but you should be able to add a
launcher, and then use the application finder as the application to be
launched.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmB8XzsACgkQ3rYcyPpX
RFtwcQf/c6UR+AQw6+zq1SlJZ0hZdYfmkdZFztjwBeWQHQfhJjRa0oSa+TsZ4cEw
IVeVKWw2AqzEexqGTwxooCFGXbNOKnemHUZvpCTGuvDuZwNWDqIh63hf4DpFntZ/
B9ILasApo2uh3mcPC1cZ7VKgSYuyfPpVOl55IGSqrfivov0pv46CIvPqpDDwtHRp
fqp59bPbvuM4FLKjuxMAammvbS4lBJw8Dn/2YMNLpm9+hWpvcszR5HOkU1evq8SN
eZ6+ZMZH0s9ZbVbzqgPOp8/+HtzlzS6VPmPwTAlY/1h+8HjdKY5MFykxecROD/zA
MP0Eh8qNDkY47DKpoQJUCfHj4nAuIA==
=jcNJ
-END PGP SIGNATURE-



Bug#987159: broadcom-sta-dkms: error(-1) from calls to @wl_dev_intvar_get; @wl_cfg80211_get_tx_power by networkctl

2021-04-18 Thread Philip Stewart

Package: broadcom-sta-dkms
Version: 6.30.223.271-15
Severity: minor

Dear Maintainer,

Calls to networkctl, e.g. 'networkctl' or 'networkctl status wlan0', 
result in the following error messages in dmesg:


[ 6969.831960] ERROR @wl_dev_intvar_get :
[ 6969.831968] error (-1)
[ 6969.831979] ERROR @wl_cfg80211_get_tx_power :
[ 6969.831982] error (-1)

I haven't yet observed any significant detrimental effect as a result 
of the errors, merely incomplete status reporting, e.g. missing access 
point MAC address.


Kind regards,
Phil

# lspci -vv -d 14e4:
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4322 
802.11a/b/g/n Wireless LAN Controller (rev 01)

Subsystem: Apple Inc. AirPort Extreme
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin A routed to IRQ 20
Region 0: Memory at d320 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)

Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=2 PME-
Capabilities: [58] Vendor Specific Information: Len=78 
Capabilities: [e8] MSI: Enable- Count=1/1 Maskable- 64bit+
Address:   Data: 
Capabilities: [d0] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 
unlimited

ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- 
SlotPowerLimit 0.000W
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- 
TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency 
L0s <4us, L1 <64us

ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- 
MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- 
MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ 
MalfTLP+ ECRC- UnsupReq- ACSViol-

CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- 
AdvNonFatalErr-
CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- 
AdvNonFatalErr+
		AERCap:	First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ 
ECRCChkEn-

MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
HeaderLog:    
Capabilities: [13c v1] Virtual Channel
Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
Arb:Fixed- WRR32- WRR64- WRR128-
Ctrl:   ArbSelect=Fixed
Status: InProgress-
VC0:Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number xx-xx-xx-xx-xx-xx-xx-xx
Capabilities: [16c v1] Power Budgeting 
Kernel driver in use: wl
Kernel modules: ssb, wl


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

Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en

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

Versions of packages broadcom-sta-dkms depends on:
ii  dkms  2.8.4-3

Versions of packages broadcom-sta-dkms recommends:
ii  wireless-tools  30~pre9-13.1

broadcom-sta-dkms suggests no packages.

-- no debconf information



Bug#986875: chezscheme: leaves alternatives after upgrade from buster: /usr/bin/scheme -> /etc/alternatives/scheme -> /usr/bin/chezscheme9.5

2021-04-18 Thread Göran Weinholt
tag 986875 + pending
thanks

Andreas Beckmann  writes:

> Package: chezscheme
> Version: 9.5.4+dfsg-3
> Severity: important
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package left unowned files on
> the system after purge, which is a violation of policy 6.8:

Thank you for your report and the patch! I've prepared 9.5.4+dfsg-4 to
fix this. My reading of the freeze policy is that I need to ask the
release team for an unblock, so I've filed a bug against
release.debian.org and will wait for a response before uploading the
fixed version.

-- 
Göran Weinholt   | https://weinholt.se/
Debian Developer | 73 de SA6CJK



Bug#985379: podman: fails to run on freshly installed Bullseye, runtime "crun" not found: invalid argument

2021-04-18 Thread Filippo Giunchedi
Hello,

On Sun, Apr 18, 2021 at 10:38:34AM -0400, Reinhard Tartler wrote:
> Thank you for your report. I have to admit that I'm a bit confused,
> according to attached
> data, it seems you have both 'runc' as well as 'crun' installed. In that
> case, changing
> the order of the dependencies won't make a difference.
> 
> Please confirm what packages of 'crun' and 'runc' you have installed.

You are quite right, the reportbug metadata is confusing in this case! I ran
reportbug on a different host (with both crun and runc installed) than the one
I attached the output from. My apologies!

'host1' had indeed only 'runc' installed.

> It seems that I indeed missed this commit:
> https://salsa.debian.org/go-team/packages/golang-github-containers-common/-/commit/6475ef3063d4a1f50fc84b2e1ceac759f09fbeee
> that changes the default from runc to crun in version
> 0.30.1. Switching the dependency order to read 'crun | runc' instead of
> 'runc | crun' seems appropriate, and I'll
> do that in the next upload.

Thank you so much!

best,
Filippo



Bug#964494: Info received (Bug#964494: File system corruption with ext3 + kernel-4.19.0-9-amd64)

2021-04-18 Thread Sarah Newman

On 4/18/21 8:36 AM, Salvatore Bonaccorso wrote:

On Tue, Aug 18, 2020 at 10:02:12PM -0700, Sarah Newman wrote:

We haven't had any further reports of file system corruption. I
would guess that converting to EXT4 is sufficient to avoid the
issue.


Should this bug be closed or is there anything we still can/should do
about it?

Regards,
Salvatore



You can close it.



Bug#986220: Uploaded to delayed queue

2021-04-18 Thread Thomas Goirand
Dear maintainer,

What Andreas suggested works, I tried.

I have uploaded the suggested debdiff from Andreas to Unstable, in the
delayed/5 queue. If you wish to upload the fix yourself, please let me
know, and I will cancel my upload. Otherwise, in 5 days, it will reach
unstable.

Cheers,

Thomas Goirand (zigo)



Bug#987158: unblock: chezscheme/9.5.4+dfsg-4

2021-04-18 Thread Göran Weinholt
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package chezscheme

[ Reason ]
A new version will fix obsolete alternatives left after upgrading from
buster (#986875).

[ Impact ]
Broken alternatives could be left on the system.

[ Tests ]
The patch was created and tested by anbe@d.o, and I have manually
verified that the broken alternatives were removed when upgrading from
buster to the fixed version.

[ Risks ]
The change itself looks trivial.

[ Other info ]
I've prepared a source upload for unstable and I'm holding off on
uploading it until I receive instructions from you.

unblock chezscheme/9.5.4+dfsg-4




diff --git a/debian/changelog b/debian/changelog
index 1a8e062..b55cdd6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+chezscheme (9.5.4+dfsg-4) unstable; urgency=medium
+
+  * chezscheme.postinst: Clean up obsolete versioned alternatives on
+upgrades from buster. Thanks to Andreas Beckmann for the report and
+the patch! (Closes: #986875)
+
+ -- Göran Weinholt   Sun, 18 Apr 2021 16:54:30 +0200
+
 chezscheme (9.5.4+dfsg-3) unstable; urgency=medium
 
   * debian/rules: Only override dh_link if chezscheme is built.
diff --git a/debian/chezscheme.postinst b/debian/chezscheme.postinst
index 6c578b0..cf85df9 100644
--- a/debian/chezscheme.postinst
+++ b/debian/chezscheme.postinst
@@ -17,6 +17,13 @@ if [ "$1" = "configure" ]; then
 --slave /usr/share/man/man1/scheme-script.1.gz \
 scheme-script.1.gz \
 /usr/share/man/man1/scheme-script-chez.1.gz
+
+if dpkg --compare-versions "$2" lt-nl "9.5.4+dfsg-4~" ; then
+CHEZ_VERSION=9.5
+update-alternatives --remove scheme /usr/bin/chezscheme${CHEZ_VERSION}
+update-alternatives --remove scheme-script 
/usr/bin/chezscheme${CHEZ_VERSION}
+fi
+
 fi
 
 #DEBHELPER#


Bug#987157: unblock: winetricks/0.0+20210206-2

2021-04-18 Thread Jens Reyer
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock



Please unblock package winetricks


[ Reason ]
One of the main purposes of Winetricks is to download Windows software
and install them in the users Wine prefix (basically a Windows
installation in the user's home directory).  Downloaded files are
verified against a hardcoded sha256sum.  Since some software still
receive frequent updates some of these hashsums get outdated quite fast.

#986376 is about updating the hashsum of vcrun2019, which is required by
quite many Windows applications to run.

I updated the hashsum to fix this for now.

I also followed upstream suggestion to cherrypick a change which extends
the existing option "--force" to ignore hashsums, in order to give an
easy general longterm workaround for this issue.


[ Impact if the unblock isn't granted ]
Adjusting only the hashsums via stable-updates is not an option due too
the number of changes and the delay until a user may use Winetricks as
expected again.

Without the "--force"-workaround the usability of our winetricks package
will degrade during Bullseye's lifetime.  (Which will still happen to
some lesser degree with this fix because download URLs will change.)


[ Tests ]
Upstream runs an automatic test suite which downloads and installs each
known software.

I manually tested
- 0.0+20210206-1 does not install vcrun2019
- 0.0+20210206-2 installs vcrun2019
- 0.0+20210206-2 with force accepts invalid hashsums.


[ Risks ]
The hashsum update is trivial.

The extension of the "--force" option is
- quite simple (in posix shell)
- in a specific function (no unexpected things expected)
- authored by upstream
- trivially cherrypicked.

Winetricks is a leaf package in contrib.

The best alternative for users is to install Winetricks (one shell
script) from upstream and use their autoupdate instead.
For this they may opt-in directly from the debian package
(sudo winetricks --self-update).


[ 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 ]
Thanks for your work!

Greets
jre


unblock winetricks/0.0+20210206-2


diff -Nru winetricks-0.0+20210206/debian/changelog 
winetricks-0.0+20210206/debian/changelog
--- winetricks-0.0+20210206/debian/changelog2021-02-07 01:18:11.0 
+0100
+++ winetricks-0.0+20210206/debian/changelog2021-04-13 22:05:56.0 
+0200
@@ -1,3 +1,10 @@
+winetricks (0.0+20210206-2) unstable; urgency=medium
+
+  * Add patch to update vcrun2019 hashes. (Closes: #986376)
+  * Add upstream patch allowing using --force to ignore the sha256sum check.
+
+ -- Jens Reyer   Tue, 13 Apr 2021 22:05:56 +0200
+
 winetricks (0.0+20210206-1) unstable; urgency=medium
 
   * New upstream release 20210206. (Closes: #961205, #981660)
diff -Nru 
winetricks-0.0+20210206/debian/patches/allow-using-force-to-ignore-the-sha256sum-check.patch
 
winetricks-0.0+20210206/debian/patches/allow-using-force-to-ignore-the-sha256sum-check.patch
--- 
winetricks-0.0+20210206/debian/patches/allow-using-force-to-ignore-the-sha256sum-check.patch
1970-01-01 01:00:00.0 +0100
+++ 
winetricks-0.0+20210206/debian/patches/allow-using-force-to-ignore-the-sha256sum-check.patch
2021-04-13 22:03:58.0 +0200
@@ -0,0 +1,27 @@
+From: Austin English 
+Subject: w_verify_sha256sum: allow using --force to ignore the check 
+Origin: upstream, 
https://github.com/Winetricks/winetricks/commit/fb824722d731cd8dfad6610d6449746e763d81ad
+Bug-Debian: https://bugs.debian.org/986376
+
+
+--- a/src/winetricks
 b/src/winetricks
+@@ -1352,13 +1352,17 @@ w_download_to()
+ ;;
+ esac
+ 
+-if test ! "${WINETRICKS_CONTINUE_DOWNLOAD}" ; then
++if test "${WINETRICKS_FORCE}" != 1; then
+ case ${LANG} in
+ pl*) w_warn "Niezgodność sum kontrolnych dla 
${_W_cache}/${_W_file}, pobieram ponownie" ;;
+ ru*) w_warn "Контрольная сумма файла 
${_W_cache}/${_W_file} не совпадает, попытка повторной загрузки" ;;
+ *) w_warn "Checksum for ${_W_cache}/${_W_file} did 
not match, retrying download" ;;
+ esac
+ mv -f "${_W_cache}/${_W_file}" 
"${_W_cache}/${_W_file}".bak
++else
++w_warn "Checksum for ${_W_cache}/${_W_file} did not 
match, but --force was used, so ignoring and trying anyway."
++checksum_ok=1
++break
+ fi
+ else
+ # file exists, no checksum known, declare success and exit 
loop
diff -Nru winetricks-0.0+20210206/debian/patches/series 
winetricks-0.0+20210206/debian/patches/series
--- winetricks-0.0+20210206/debian/patches/series   2021-02-07 
00:33:32.0 +0100
+++ 

Bug#987154: [Pkg-javascript-devel] Bug#987154: rollup: --watch not working because of missing dependency

2021-04-18 Thread Yadd
Le 18/04/2021 à 16:12, Nick Aquina a écrit :
> Package: rollup
> Version: 2.38.4-1
> Severity: normal
> 
> When running `rollup --watch`, an error occurs:
> 
> (node:8675) UnhandledPromiseRejectionWarning: Error: Cannot find module
> 'chokidar'
> [...]
> The error can be fixed by running `sudo apt install node-chokidar`.

Hi,

I think this is not a required dependency. The question for JS-Team is:
add node-chokidar in recommended or suggested dependencies? Of course,
description should explain the need of chokidar.

Cheers,
Yadd



Bug#829532: linux-image-4.6.0-0.bpo.1-amd64: breaks qemu-nbd

2021-04-18 Thread Salvatore Bonaccorso
Control: tags -1 + moreinfo

Hi,

On Mon, Jul 04, 2016 at 05:15:31PM +0200, Ben Hutchings wrote:
> Control: reassign -1 src:linux 4.6.1-1
> Control: severity -1 important
> Control: tag -1 confirmed upstream
> 
> On Mon, 2016-07-04 at 00:47 -0400, westlake wrote:
> > Package: linux-image-4.6.0-0.bpo.1-amd64
> > Version: 4.6.1-1~bpo8+1
> > Severity: normal
> > 
> > kernels 4.5 and 4.6 breaks qemu-nbd from mapping partitions
> > 
> > qemu-nbd can map partitions from VM images and raw disk images to
> > /dev/nbdNpM nodes, but proper module options have to be loaded prior so
> > that qemu-nbd performs these additional mappings (the general consensus
> > around mapping image files has users issuing "kpartx -a /dev/",
> > but kpartx is not needed at all after issuing qemu-nbd)
> > 
> > nothing is specially set up other than a module option file and that's
> > pretty much it -- there's just 2 or 3 commands for the testing --- all
> > which indicates the issue is more towards kernel than it is with qemu-nbd.
> 
> I can confirm this issue.
> 
> > after a modprobe nbd is issued, there is no "/dev/nbd0p1"-like devices,
> 
> That much is correct behaviour since no device is attached yet...
> 
> > so the main problem with kernels 4.5/4.6 is that qemu-nbd is not being
> > allowed to generate any device nodes. ("partition" device nodes that is
> > -- "/dev/nbd0" and "/dev/nbd1" nodes are generated by modprobe nbd)
> [...]
> 
> ...but the kernel should scan the partition table for an nbd as soon as
> it is attached to a server.  Currently that isn't happening.  As a
> workaround, running 'fdisk' and then re-writing the same partition
> table triggers a rescan.
> 
> This is almost certainly caused by:
> 
> commit 37091fdd831f28a6509008542174ed324dd645bc
> Author: Markus Pargmann
> 
> Date:   Mon Jul 27 07:36:49 2015 +0200
> 
> nbd: Create size change events for userspace
> 
> I have a rough idea of how to fix it and will update you later.

This issue has probably been fixed in meanwhile?

Regards,
Salvatore



Bug#964494: Info received (Bug#964494: File system corruption with ext3 + kernel-4.19.0-9-amd64)

2021-04-18 Thread Salvatore Bonaccorso
On Tue, Aug 18, 2020 at 10:02:12PM -0700, Sarah Newman wrote:
> We haven't had any further reports of file system corruption. I
> would guess that converting to EXT4 is sufficient to avoid the
> issue.

Should this bug be closed or is there anything we still can/should do
about it?

Regards,
Salvatore



Bug#900821: workaround confirmed

2021-04-18 Thread Salvatore Bonaccorso
On Mon, Dec 14, 2020 at 08:38:02PM +, Florian Kain wrote:
> Hi all,
> 
> we were experiencing this bug in a debian 10.4 docker container (FROM 
> php:apache)
> it only happens with plain http not with https.
> 
> I can confirm that workaround from  Stefan Fritsch 
> by turning EnableMMAP off is working for us!

is this issue still reproducible with recent kernels?

Regards,
Salvatore



Bug#880503: linux-image-3.16.0-4-amd64: System crash when running docker

2021-04-18 Thread Salvatore Bonaccorso
Closing this bugreport as the affected versions are not supported
anymore within Debian, and the issue appeared to be fixed in recent
4.x kernels.

Please reopen if the issue still persist.

Regards,
Salvatore



Bug#712449: linux-image: Marvell Gigabit Ethernet sky2 driver panics on unplug re-plug, found a fix

2021-04-18 Thread Salvatore Bonaccorso
Hi,

I'm closing this bugreport as it was reported against a now anyway
unsuported version. If the issue still persist please do reopen the
bug and add a found version.

Regards,
Salvatore



Bug#919656: usb - surface dock - ethernet - fix included

2021-04-18 Thread Salvatore Bonaccorso
Source: linux
Source-Version: 4.19.67-1

Hi,

On Fri, Jan 18, 2019 at 11:43:16AM +0100, - wrote:
> Package: linux-image-4.19.0-1-amd64
> Severity: important
> 
> Device: Surface Go
> 
> Debian Version: Buster with latest updates
> 
> Summary:
> 
> The Surface Dock is working fine, hot-plugging and suspend (even with
> S3) are working, just the Ethernet port does not get an IP address. It
> is recognized, but not working.
> 
> There is a quirk available for the powermanagement, see https://github.
> com/jakeday/linux-surface/issues/259 for more information and https://g
> ithub.com/jakeday/linux-
> surface/pull/325/commits/2dd7c642990602cb7f873d4b151098876e80ddb2 for
> the patch.

The quirk patch landed afaics in 4.19.49 "USB: Add LPM quirk for
Surface Dock GigE adapter".

Regards,
Salvatore



Bug#926539: rootskel: steal-ctty no longer works on s390x

2021-04-18 Thread Salvatore Bonaccorso
Is this bug still valid to be open?

The mentioned commit landed in 5.3-rc1, 4.19.54 and as well 4.9.183.

Regards,
Salvatore



Bug#940633: linux-image-5.2.0-2-amd64: UI microfreezes with with i915 driver

2021-04-18 Thread Salvatore Bonaccorso
Source: linux
Source-Version: 5.2.9-1
Control: notfound -1 5.2.9-2

On Wed, Sep 18, 2019 at 08:41:02AM +0200, Gregor Riepl wrote:
> Package: src:linux
> Version: 5.2.9-2
> Severity: important
> Tags: patch upstream
> 
> Dear Maintainer,
> 
> Linux 5.2 kernels contain a bug that causes short graphics freezes when using
> the i915 driver on certain Intel GPUs.
> 
> The issue was originally reported here:
> https://bugzilla.kernel.org/show_bug.cgi?id=204183
> 
> A patch for 5.2 is available here:
> https://patchwork.freedesktop.org/series/63774/#rev4
> 
> This patch will likely be included in kernel 5.3, but 5.2 and possibly older
> kernels are also affected.
> 
> Please consider adding this patch to 5.2 until it arrives in a stable kernel.
> 
> As a temporary workaround, it's possible to disable PSR (Panel Self Refresh) 
> by
> adding i915.enable_psr=0 to the kernel command line. There may be higher power
> consumption or other consequences.

The mentioned patch seems to have been applied to 5.2.8 and 5.3-rc3.

I guess the found version was thus wrong used in the bugreport?

I'm closing the bug now, feel free to reopen if the issue still
persisst.

Regards,
Salvatore



Bug#940825: linux-source-5.2: Backport of wifi driver fixes to enable wifi on whiseylake based system in 5.2.9

2021-04-18 Thread Salvatore Bonaccorso
Source: linux
Source-Version: 5.2.17-1

On Fri, Sep 20, 2019 at 08:29:12AM -0400, Mark Pearson wrote:
> Package: linux-source-5.2
> Version: 5.2.9-2~bpo10+1
> Severity: important
> Tags: patch
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> Wifi on the Lenovo X1 Carbon Gen7 is not functional.
> Intel pointed us at the attached patch comprised of upstream fixes
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Applied the patch and wifi was then operational
>* What was the outcome of this action?
> Wifi works correctly
>* What outcome did you expect instead?
> NA
> 
> Please let me know any questions. I'm still new to the process.
> Thanks in advance for the help - we have a customer who is waiting on these
> fixes in Debian (this and the SOF driver backport).
> Mark

The changes seem to be included in 5.2.12 and so in the 5.2.17-1
upload to unstable.

Regards,
Salvatore



Bug#987156: mod_ssl depends on mod_setenvif while it does not

2021-04-18 Thread MichaIng

Package: apache2
Version: 2.4.46-4

When enabling mod_ssl via "a2enmod ssl" while mod_setenvif is disabled, 
it becomes apparent that mod_ssl depends on mod_setenvif. I checked the 
configuration file /etc/apache2/mods-available/ssl.conf, but it actually 
does not use any mod_setenvif directive. I disabled mod_setenvif 
effectively by emptying setenvif.load and setenvif.conf manually on two 
servers, and none shows any issues for months of 24/7 use.


Hence I believe that this module dependency might come from some 
previous use of setenvif directives in the default mod_ssl config, which 
have been removed meanwhile, rendering this dependency as obsolete.


I'm not sure how those dependencies are defined and whether hence it is 
an upstream issue or a distro package issue. In case I'll report it 
upstream as well.


Best regards,

Micha



Bug#987155: unblock: libpod/3.0.1+dfsg1-2

2021-04-18 Thread Reinhard Tartler
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: siret...@tauware.de, Filippo Giunchedi 

Please unblock package libpod

Note that I have not uploaded the package yet, this is a pre-approval
request.

[ Reason ]
I as maintainer have missed an upstream change that switches the default
container runtime. The remedy is to switch the alternative dependency
in the podman binary pacakage package

[ Impact ]
Not granting the unblock request will leave an unfunctional default
configuration, please see https://bugs.debian.org/985379

[ Tests ]
This needs to be manually tested in a clean, freshly installed system,
such as a VM.

[ Risks ]
This patch does not contain a code-change, and is therefore low-risk.
As an alternative, this could be documented in the bullseye release-notes.


[ Checklist ]
  [ ] 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


The patch would be this:

modified   debian/control
@@ -94,7 +94,7 @@ Depends: ${misc:Depends}, ${shlibs:Depends}
 ,conmon (>= 2.0.18~)
 ,containernetworking-plugins (>= 0.8.7)
 ,golang-github-containers-common
-,runc (>= 1.0.0~rc92~) | crun
+,crun | runc (>= 1.0.0~rc92~)
 Breaks: buildah (<< 1.10.1-6), slirp4netns (<< 0.4.1), fuse-overlayfs (<< 
0.7.1)
 Recommends: ${misc:Recommends}
 ,buildah (>= 1.10.1-6~)


unblock libpod/3.0.1+dfsg1-2



Bug#985379: podman: fails to run on freshly installed Bullseye, runtime "crun" not found: invalid argument

2021-04-18 Thread Reinhard Tartler
Thank you for your report. I have to admit that I'm a bit confused,
according to attached
data, it seems you have both 'runc' as well as 'crun' installed. In that
case, changing
the order of the dependencies won't make a difference.

Please confirm what packages of 'crun' and 'runc' you have installed.

Note that the default container runtime is configured in
/etc/containers/containers.conf, which
is provided by the golang-github-containers-common package. I notice your
comment that your
system doesn't have that file at that location. I assume that you deleted
it. Please refer to
https://manpages.debian.org/experimental/golang-github-containers-common/containers.conf.5.en.html
for fallback locations of that file.

You can verify the default on
https://salsa.debian.org/go-team/packages/golang-github-containers-common/-/blob/ec3c1e1123cb9c682c988905fdf967fe8a88a829/pkg/config/containers.conf#L397-399
.

It seems that I indeed missed this commit:
https://salsa.debian.org/go-team/packages/golang-github-containers-common/-/commit/6475ef3063d4a1f50fc84b2e1ceac759f09fbeee
that changes the default from runc to crun in version
0.30.1. Switching the dependency order to read 'crun | runc' instead of
'runc | crun' seems appropriate, and I'll
do that in the next upload.

Thanks!
-rt


On Tue, Mar 16, 2021 at 5:30 PM Filippo Giunchedi 
wrote:

> Package: podman
> Version: 3.0.1+dfsg1-1
> Severity: important
>
> This is the same as #971253. Specifically, 'runc' is installed as the first
> Depend, however podman defaults to 'crun'. I think podman should depend on
> 'crun' first so it works out of the box (and with cgroups v2).
>
> root@host1:~# podman images
> Error: default OCI runtime "crun" not found: invalid argument
> root@host1:~# ls -la /etc/containers/containers.conf
> ls: cannot access '/etc/containers/containers.conf': No such file or
> directory
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (400, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 podman depends on:
> ii  conmon   2.0.25+ds1-1
> ii  containernetworking-plugins  0.9.0-1+b2
> ii  crun 0.17+dfsg-1
> ii  golang-github-containers-common  0.33.4+ds1-1
> ii  init-system-helpers  1.60
> ii  libc62.31-9
> ii  libdevmapper1.02.1   2:1.02.175-2.1
> ii  libgpgme11   1.14.0-1+b2
> ii  libseccomp2  2.5.1-1
> ii  runc 1.0.0~rc93+ds1-2+b1
>
> Versions of packages podman recommends:
> ii  buildah   1.19.6+dfsg1-1
> ii  catatonit 0.1.5-2
> ii  fuse-overlayfs1.4.0-1
> ii  golang-github-containernetworking-plugin-dnsname  1.1.1+ds1-4+b3
> ii  slirp4netns   1.0.1-1
> ii  tini  0.19.0-1
> ii  uidmap1:4.8.1-1
>
> Versions of packages podman suggests:
> ii  containers-storage  1.24.8+dfsg1-1
> pn  docker-compose  
>
> -- no debconf information
>
>

-- 
regards,
Reinhard


Bug#984862: iptables-netflow-dkms: module wants to build with gcc instead of kernel's compiler

2021-04-18 Thread Axel Beckert
Hi Andreas,

Andreas Beckmann wrote:
> Please bump the dkms dependency for bullseye, this issue can trigger on
> upgrades from buster to bullseye where iptables-netflow-dkms is upgraded
> before dkms.

Should that patch really close this bug report? IIRC you didn't close
all these bug reports with the dkms patch. Was this in anticipation of
this version bumping or do you still want us to get upstream to do it
"right" (whatever exactly that would be).

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#987154: rollup: --watch not working because of missing dependency

2021-04-18 Thread Nick Aquina
Package: rollup
Version: 2.38.4-1
Severity: normal

When running `rollup --watch`, an error occurs:

(node:8675) UnhandledPromiseRejectionWarning: Error: Cannot find module
'chokidar'
Require stack:
- /usr/share/nodejs/rollup/dist/shared/watch-cli.js
- /usr/share/nodejs/rollup/dist/bin/rollup
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:815:15)
at Function.Module._load (internal/modules/cjs/loader.js:667:27)
at Module.require (internal/modules/cjs/loader.js:887:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object. (/usr/share/nodejs/rollup/dist/shared/watch-
cli.js:42:18)
at Module._compile (internal/modules/cjs/loader.js:999:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Module.require (internal/modules/cjs/loader.js:887:19)
(node:8675) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This
error originated either by throwing inside of an async function without a catch
block, or by rejecting a promise which was not handled with .catch(). To
terminate the node process on unhandled promise rejection, use the CLI flag
`--unhandled-rejections=strict` (see
https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id:
1)
(node:8675) [DEP0018] DeprecationWarning: Unhandled promise rejections are
deprecated. In the future, promise rejections that are not handled will
terminate the Node.js process with a non-zero exit code.

The error can be fixed by running `sudo apt install node-chokidar`.

Versions of packages rollup depends on:
ii  node-ansi-escapes  4.3.1-1
ii  node-date-time 3.1.0-1
ii  node-debbundle-acorn   8.0.5+ds+~cs19.19.27-1
ii  node-hash.js   1.1.7-1
ii  node-is-reference  1.2.1-3
ii  node-locate-character  2.0.5+repack-2
ii  node-magic-string  0.25.7-4
ii  node-postcss [node-colorette]  8.2.1+~cs5.3.23-6
ii  node-pretty-bytes  5.5.0-1
ii  node-pretty-ms 7.0.1-1
ii  node-require-relative  0.8.7-3
ii  node-rollup-pluginutils4.1.0+~2.8.2-3
ii  node-signal-exit   3.0.3-1
ii  node-source-map0.7.0++dfsg2+really.0.6.1-7
ii  node-sourcemap-codec   1.4.8-4
ii  node-yargs-parser  18.1.3+~15.0.0-1
ii  nodejs 12.21.0~dfsg-3

rollup recommends no packages.

rollup suggests no packages.



Bug#987152: ITP: python3-absl -- Google's library for building Python applications

2021-04-18 Thread Arturo Borrero Gonzalez




On 4/18/21 3:32 PM, Arturo Borrero Gonzalez wrote:

Package: wnpp
Severity: wishlist
Owner: Arturo Borrero Gonzalez 
X-Debbugs-Cc: debian-de...@lists.debian.org



Initial packaging:

https://salsa.debian.org/debian/pkg-python-absl



Bug#987004: (no subject)

2021-04-18 Thread Arturo Borrero Gonzalez

Initial packaging:

https://salsa.debian.org/debian/pkg-capirca/



Bug#987058: unit tests for the fixes

2021-04-18 Thread Peter Marschall
Hi,

please find attached some updated unit tests for the fixes

-- 
Peter Marschall
pe...@adpm.de
From 866d9b1f8807b43dc7cc9b2b1002d12cb791d146 Mon Sep 17 00:00:00 2001
From: Peter Marschall 
Date: Sun, 18 Apr 2021 14:06:34 +0200
Subject: [PATCH 3/3] t/7_Canvas.t: make tests for rotation work again

Do tests for rotation of bbox's texts before deletion of the bboxes.

Simplify rotation cheks by using 'get_simple_transform()' method that
corresponds to the 'set_simple_transformation()' method used for scaling
and rotating, and call it on the correct object to provide meaningful
results.

Signed-off-by: Peter Marschall 
---
 t/7_Canvas.t | 46 +-
 1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/t/7_Canvas.t b/t/7_Canvas.t
index 9cc6b206..43e9893c 100644
--- a/t/7_Canvas.t
+++ b/t/7_Canvas.t
@@ -1,7 +1,7 @@
 use warnings;
 use strict;
 use IPC::System::Simple qw(system);
-use Test::More tests => 37;
+use Test::More tests => 36;
 use Glib 1.220 qw(TRUE FALSE);# To get TRUE and FALSE
 use Gscan2pdf::Page;
 use Gtk3 -init;
@@ -324,6 +324,30 @@ is( $canvas->hocr, $expected, 'updated hocr with extended hOCR properties' );
 
 #
 
+$group = $canvas->get_root_item;
+# get page 'page_1'
+$group = $group->get_child(0);
+# get column/carea 'block_1'
+$group = $group->get_child(1);
+# get line 'line_1_2'
+$group = $group->get_child(2);
+# get word 'word_1_3'
+$bbox  = $group->get_child(1);
+
+isa_ok($bbox, 'Gscan2pdf::Canvas::Bbox');
+is($bbox->{textangle}, 0, "word_1_3's textangle is 0");
+is($bbox->{transformation}->[0], 90, "word_1_3's (inherited) rotation is 90");
+
+my $textwidget   = $bbox->get_text_widget;
+
+isa_ok($textwidget, 'GooCanvas2::CanvasText');
+
+my @transform = $textwidget->get_simple_transform();
+
+is($transform[-1], 270, "word_1_3's text widget rotation matches the 90° rotation");
+
+#
+
 $bbox = $canvas->get_first_bbox;
 $bbox->delete_box;
 $bbox = $canvas->get_next_bbox;
@@ -336,26 +360,6 @@ is $canvas->get_last_bbox, undef, 'get_last_bbox() returns undef if no boxes';
 
 #
 
-SKIP: {
-skip 'GooCanvas2::Canvas::get_transform() returns undef', 6;
-$group = $canvas->get_root_item;
-$group = $group->get_child(0);
-$group = $group->get_child(1);
-$group = $group->get_child(1);
-$group = $group->get_child(2);
-$bbox  = $group->get_child(1);
-my $matrix = $bbox->get_transform;
-
-is( $matrix->x0, -103.251044000815, 'rotated text x0' );
-is( $matrix->y0, -42.1731768180892, 'rotated text y0' );
-is( $matrix->xx, 2.86820126298635,  'rotated text xx' );
-is( $matrix->xy, 0, 'rotated text xy' );
-is( $matrix->yx, 0, 'rotated text yx' );
-is( $matrix->yy, 2.86820126298635,  'rotated text yy' );
-}
-
-#
-
 $page = Gscan2pdf::Page->new(
 filename   => 'test.pnm',
 format => 'Portable anymap',
-- 
2.30.2



Bug#987057: Unit test(s) for fixes

2021-04-18 Thread Peter Marschall
Hi,

please find attched some patches with unit tetss for the fixes

Best
Peter
-- 
Peter Marschall
pe...@adpm.de
>From 4768853e9f53c71f03fb5be3875dddec5d9ba019 Mon Sep 17 00:00:00 2001
From: Peter Marschall 
Date: Sun, 18 Apr 2021 12:49:54 +0200
Subject: [PATCH 4/5] t/158_save_hocr_structure.t: new

Add a test to test more complex aspects of the hOCR generation:
- support for 'ocr_header', 'ocr_caption', 'ocr_footer' elements
  (and their 'ocrx_...' counterparts)
- preservation of 'textangle' and 'baseline' properties
- correct indentation of closing non-leaf elements when followed by siblings

Signed-off-by: Peter Marschall 
---
 t/158_save_hocr_structure.t | 153 
 1 file changed, 153 insertions(+)
 create mode 100644 t/158_save_hocr_structure.t

diff --git a/t/158_save_hocr_structure.t b/t/158_save_hocr_structure.t
new file mode 100644
index ..d6b7b660
--- /dev/null
+++ b/t/158_save_hocr_structure.t
@@ -0,0 +1,153 @@
+use warnings;
+use strict;
+use IPC::System::Simple qw(system capture);
+use Test::More tests => 1;
+
+BEGIN {
+use Gscan2pdf::Document;
+use Gtk3 -init;# Could just call init separately
+}
+
+#
+
+Gscan2pdf::Translation::set_domain('gscan2pdf');
+use Log::Log4perl qw(:easy);
+Log::Log4perl->easy_init($WARN);
+my $logger = Log::Log4perl::get_logger;
+Gscan2pdf::Document->setup($logger);
+
+# Create test image
+system(qw(convert rose: test.pnm));
+
+my $slist = Gscan2pdf::Document->new;
+
+# dir for temporary files
+my $dir = File::Temp->newdir;
+$slist->set_dir($dir);
+
+my $hocr = <<'EOS';
+http://www.w3.org/TR/html4/loose.dtd;>
+
+
+
+
+
+
+
+
+
+
+
+The
+quick
+brown
+
+
+
+
+
+
+The
+quick
+brown
+
+
+
+
+
+
+The
+quick
+brown
+
+
+fox
+jumps
+over
+
+
+the
+lazy
+dog.
+
+
+
+
+
+
+EOS
+
+$slist->import_files(
+paths => [ 'test.pnm' ],
+finished_callback => sub {
+$slist->{data}[0][2]->import_hocr($hocr);
+$slist->save_hocr(
+path => 'test.txt',
+list_of_pages =>
+  [ $slist->{data}[0][2]{uuid} ],
+finished_callback => sub { Gtk3->main_quit }
+);
+}
+);
+Gtk3->main;
+
+my $expected = <<"EOS";
+
+http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;>
+http://www.w3.org/1999/xhtml; xml:lang="en" lang="en">
+ 
+  
+  
+  
+ 
+ 
+  
+   
+
+ 
+  The
+  quick
+  brown
+ 
+
+   
+   
+
+ 
+  The
+  quick
+  brown
+ 
+
+   
+   
+
+ 
+  The
+  quick
+  brown
+ 
+ 
+  fox
+  jumps
+  over
+ 
+ 
+  the
+  lazy
+  dog.
+ 
+
+   
+  
+ 
+
+EOS
+
+is capture(qw(cat test.txt)), $expected, 'saved multipage hOCR';
+
+#
+
+unlink 'test.pnm', 'test.txt';
+Gscan2pdf::Document->quit();
-- 
2.30.2

From 90f10b940b87699d00560d8b597e19ed5f77b49f Mon Sep 17 00:00:00 2001
From: Peter Marschall 
Date: Sun, 18 Apr 2021 15:30:04 +0200
Subject: [PATCH 5/5] t/156_save_hocr_with_encoding.t: remove 'baseline'
 property

Remove 'baseline property from input to avoid issues with patches preswerving
properties.
This way the test succeeds independently of those changes.

Signed-off-by: Peter Marschall 
---
 t/156_save_hocr_with_encoding.t | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/156_save_hocr_with_encoding.t b/t/156_save_hocr_with_encoding.t
index 41b4f7e5..1bdcb245 100644
--- a/t/156_save_hocr_with_encoding.t
+++ b/t/156_save_hocr_with_encoding.t
@@ -41,7 +41,7 @@ my $hocr = <<'EOS';
   

 
- donc un village à Cuzco ( centre du monde  en 
+ donc un village à Cuzco ( centre du monde  en 
  
 

-- 
2.30.2



Bug#987152: ITP: python3-absl -- Google's library for building Python applications

2021-04-18 Thread Arturo Borrero Gonzalez
Package: wnpp
Severity: wishlist
Owner: Arturo Borrero Gonzalez 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python3-absl
  Version : 0.12.0
  Upstream Author : Google Inc
* URL : https://github.com/abseil/abseil-py
* License : Apache 2.0
  Programming Lang: Python
  Description : Google's library for building Python applications

 A collection of Python library code for building Python applications. The
 code is collected from Google's own Python code base, and has been
 extensively tested and used in production. Some features include:

 * Simple application startup

 * Distributed commandline flags system

 * Custom logging module with additional features

 * Testing utilities

This is a dependency for capirca.



Bug#987151: should declare relationship with libretro cores

2021-04-18 Thread Sébastien Villemot
Package: gnome-games-app
Version: 3.38.0-1
Severity: normal

Dear Maintainer,

gnome-games-app is able to take advantage of several libretro cores, but this
is not reflected in package relationships.

Currently, with no libretro core installed, if a user tries to run a game, they
will get this message: “The system 'foo' isn’t supported yet, but full support
is planned”. This is rather misleading, since the solution is simply to do an
“apt install”.

I therefore think that gnome-games-app should declare a Depends, a Recommends,
or at the very least a Suggests, on all the libretro cores that it is able to
use.

Thanks,

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


Bug#987095: transitive_closure corrupted results, after vertex deleted

2021-04-18 Thread gregor herrmann
On Sat, 17 Apr 2021 15:38:32 +0200, Dominique Dumont wrote:

> I've created a bug upstream:
> https://github.com/graphviz-perl/Graph/issues/20

Thanks.

The issue is fixed upstream, and a new 0.9721 has been made.

As we have 0.9716 in testing and unstable (and 0.9720 in master) and
shouldn't upload all the changes since 0.9716 during the hard freeze,
I've created and pushed a "bullseye" branch with a quilt patch for
this issue, which contains basically the diff between 0.9720 and
0.9721.

The changes also contain a new test based on Ian's reproducer, and
all other tests still pass, so I'm quite confident that this should
be ok to upload. Still, I'd appreciate if Ian and/or Dominique could
take a look at this branch/patch.


Cheers,
gregor

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


signature.asc
Description: Digital Signature


Bug#986806: CVE-2021-28965

2021-04-18 Thread Salvatore Bonaccorso
Hi,

On Sat, Apr 17, 2021 at 10:34:24PM +0530, Pirate Praveen wrote:
> 
> 
> On Sat, Apr 17, 2021 at 10:16 pm, Utkarsh Gupta  wrote:
> > Makes sense. Probably the time to RM ruby-rexml from the archive is
> > *now*?
> 
> Requested removal from archive in #987101

Thanks for filling the removal!

I fear this has though some additional work to be done, trying to
simulate the removal the following is shown:

Will remove the following packages from sid:

ruby-rexml |3.2.4-2 | source, all

Maintainer: Debian Ruby Extras Maintainers 


--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
ruby-kramdown: ruby-kramdown

# Broken Build-Depends:
ruby-kramdown: ruby-rexml

Dependency problem found.

Can you change tue Build-Depends of ruby-kramdown?

Regards,
Salvatore



Bug#987131: dpkg: libreoffice upgrade failure

2021-04-18 Thread Guillem Jover
Hi!

[ I'm assuming this is from Andreas Beckman? :) CCed explicitly. ]

On Wed, 2021-03-17 at 12:04:32 +0100, piupar...@zam127.zam.kfa-juelich.de wrote:
> Package: dpkg
> Version: 1.20.7.1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: block 985297 with -1
> 
>   Preparing to unpack .../0-ure_1%3a7.0.4-3_amd64.deb ...
>   Unpacking ure (1:7.0.4-3) over (6.1.5-3+deb10u7) ...
>   Preparing to unpack .../1-libreoffice-style-colibre_1%3a7.0.4-3_all.deb ...
>   Unpacking libreoffice-style-colibre (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   dpkg: considering deconfiguration of libreoffice-writer, which would be 
> broken by installation of libreoffice-core ...
>   dpkg: yes, will deconfigure libreoffice-writer (broken by libreoffice-core)
>   Preparing to unpack .../2-libreoffice-core_1%3a7.0.4-3_amd64.deb ...
>   De-configuring libreoffice-writer (1:6.1.5-3+deb10u7) ...
>   Unpacking libreoffice-core (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   dpkg: considering removing libreoffice-writer in favour of 
> libreoffice-common ...
> * dpkg: libreoffice-writer is not properly installed; ignoring any 
> dependencies on it ***
> * dpkg: yes, will remove libreoffice-writer in favour of libreoffice-common   
> ***
>   Preparing to unpack .../3-libreoffice-common_1%3a7.0.4-3_all.deb ...
>   dpkg-maintscript-helper: error: file 
> '/usr/lib/libreoffice/share/registry/writer.xcd' not owned by package 
> 'libreoffice-common:all'
>   dpkg-maintscript-helper: error: directory 
> '/usr/lib/libreoffice/share/registry' contains files not owned by package 
> libreoffice-common:all, cannot switch to symlink
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb 
> (--unpack):
>new libreoffice-common package pre-installation script subprocess returned 
> error exit status 1
>   rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or 
> directory
>   rmdir: failed to remove '/var/lib/libreoffice': No such file or directory
>   Selecting previously unselected package libreoffice-writer.
>   dpkg: considering deconfiguration of libreoffice-common, which would be 
> broken by installation of libreoffice-writer ...
>   dpkg: yes, will deconfigure libreoffice-common (broken by 
> libreoffice-writer)
>   Preparing to unpack .../4-libreoffice-writer_1%3a7.0.4-3_amd64.deb ...
>   De-configuring libreoffice-common (1:6.1.5-3+deb10u7) ...
>   Unpacking libreoffice-writer (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   Replacing files in old package libreoffice-common (1:6.1.5-3+deb10u7) ...
>   Preparing to unpack .../5-libxmlsec1_1.2.31-1_amd64.deb ...
>   Unpacking libxmlsec1:amd64 (1.2.31-1) over (1.2.27-2) ...
>   Preparing to unpack .../6-libreoffice-base-core_1%3a7.0.4-3_amd64.deb ...
>   Unpacking libreoffice-base-core (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   Errors were encountered while processing:
>/tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb
> 
> So is dpkg going to remove libreoffice-writer or not? It says both and does
> not remove it, causing dpkg-maintscript-helper to fail since
> /usr/lib/libreoffice/share/registry is not empty before dir_to_symlink
> is run. There should be enough Conflicts to ensure all packages previously
> shipping files there are removed or upgraded.
> 
> Andreas
> 
> (full log in #985297)
> 
> PS: could we please have a dpkg with fixed dpkg-realpath uploaded soon?
> Before people trying to fix the "missing symlink_to_dir" bugs I filed
> recently start to run into that issue?

From the Received headers, can I assume this was a mail that got stuck
in some mail server and delivered just now? Otherwise I'd be a bit
confused, as the dpkg-realpath issue is supposed to have been fixed
already and this report looks like a duplicate of #985401, which was
also analyzed, and deemed a non-bug in dpkg-maintscript-helper?

Otherwise, I'll just be closing this one in a bit.

Thanks,
Guillem



Bug#987150: ITP: sfsexp -- small and fast s-expression parsing library

2021-04-18 Thread David Bremner
Package: wnpp
Severity: wishlist
Owner: David Bremner 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: sfsexp
  Version : 1.3
  Upstream Author : Matthew Sottile 
* URL : https://github.com/mjsottile/sfsexp/
* License : LGPL
  Programming Lang: C
  Description : small and fast s-expression parsing library

This library is intended for developers who wish to manipulate (read,
parse, modify, and create) LISP-style symbolic expressions from C or
C++ programs.

This seems to be one of those things that is re-invented many times.

I'm not 100% committed to packaging this yet, but I have some work in
progress at https://salsa.debian.org/bremner/sfsexp

 One question is whether to follow upstream and name the library /
binary package as libsexp(n) or if that is too generic.


-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmB8IT4ACgkQA0U5G1Wq
FSHvpBAAin7Vu6ranMIhYdLTWy/xW6Hkoi1vvhyahuWsbLC5d58KlWvuUGZpUrFy
KAtjFLWSG5iVUltAtb6b4/ZWkQ5eTLKYhXfyv3iw9O/Pj8NqgTnp8LFxA84Kc5ND
Gs259CXWGtpvE5YTnayfbcxi82ZE/xyhjNDv4YDp2GA3CF3BGlFl7nBAhtFDpyV7
AahWtdkJkrkV0zUCEXiFcgS32y0fsMREeuOfKFowpCIW703v1mBSZuFojJlfFhTE
Ure9XfAs9++9Ra70xDzyprg7SPr6lG6Fd+cNEiUNubn6CFTvCMPI0fYZGW05Hq/z
vVR1Jqk8pqchoB8DyKXE11PLW6dRtFZtl3r7rGZVDLs+dx/T/O4/dlgbQXIfFXVd
ye0SavbTgfwEJm9YZV5G4MLnzm1oY6TVsLFMlRozJIE7GZd+pgCFJFwPc2W9DMn7
5voWYOxP1p2d8nAXVBFle7QbcrxBi8BgxGTjQSUepJb3mDHZd30D4K3LpaHELYpf
Y03MgGt2Pm0ekXRTqddvJBzNI821VAemuXroEkD+loyWe+nO2a7zfJUcC/PNykvg
Y/Dy2DzgadA9JcrlyibNQ64Oadu96qZZifj2ZmUePbETqRIYAEKJGhlXBWrx4ADR
oacsndxa3lkYznFJSYrU+AN9jQbb3cOPx8nLWmdmgA2Vzo+dKes=
=S9oZ
-END PGP SIGNATURE-



Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

2021-04-18 Thread Salvatore Bonaccorso
Source: xscreensaver
Version: 5.45+dfsg1-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi

Filling for tracking in the BTS as well. For full public reference
see:

https://www.openwall.com/lists/oss-security/2021/04/17/1

Regards,
Salvatore



Bug#987148: please consider reading gai.conf into ip addrlabel

2021-04-18 Thread Marc Haber
Package: iproute2
Version: 5.10.0-4
Severity: wishlist

Hi,

that recent Linuxen don't read IP address labels from /etc/gai.conf
comes a bit as surprise. And, additionally, I consider IP address labels
at least kind of permanent configuration.

Wouldn't it be nice if a startup process would read /etc/gai.conf and
establish the apporiate ip addrlabel configuration? Maybe even a systemd
path unit that re-reads the file on change?

Greetings
Marc


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

Kernel: Linux 5.11.11-zgws1 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages iproute2 depends on:
ii  debconf [debconf-2.0]  1.5.76
ii  libbpf01:0.3-2
ii  libbsd00.11.3-1
ii  libc6  2.31-11
ii  libcap21:2.44-1
ii  libcap2-bin1:2.44-1
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libelf10.183-3
ii  libmnl01.0.4-3
ii  libselinux13.1-3
ii  libxtables12   1.8.7-1

Versions of packages iproute2 recommends:
pn  libatm1  

Versions of packages iproute2 suggests:
pn  iproute2-doc  

-- debconf information excluded



Bug#987133: marked as done (exim4: Exim 4.94's new tainting-feature will break many running configs)

2021-04-18 Thread Andreas Metzler
Control: reopen -1
Control: found -1 4.93-1
Control: tags -1 moreinfo
Control: severity -1 normal

On 2021-04-18 Marc Haber  wrote:
> On Sun, Apr 18, 2021 at 09:57:02AM +, Debian Bug Tracking System wrote:
> > From: Andreas Metzler 
> > Subject: Re: Bug#987133: exim4: Exim 4.94's new tainting-feature will break
> >  many running configs
> > To: 987133-d...@bugs.debian.org

> Was the -done really intended?
[...]

No it was not. Sorry for the noise.

cu Andreas



Bug#987133: marked as done (exim4: Exim 4.94's new tainting-feature will break many running configs)

2021-04-18 Thread Marc Haber
On Sun, Apr 18, 2021 at 09:57:02AM +, Debian Bug Tracking System wrote:
> From: Andreas Metzler 
> Subject: Re: Bug#987133: exim4: Exim 4.94's new tainting-feature will break
>  many running configs
> To: 987133-d...@bugs.debian.org

Was the -done really intended? Getting the fix in bullseye this late in
the release process would be vastly easier if it would fix an RC bug.

Curious Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Bug#987147: O: openvpn-systemd-resolved -- integrates OpenVPN with systemd-resolved

2021-04-18 Thread Mattia Rizzolo
Package: wnpp

The current maintainer of openvpn-systemd-resolved, Eugene Zhukov 
,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: openvpn-systemd-resolved
Binary: openvpn-systemd-resolved
Version: 1.3.0-3.1
Maintainer: Eugene Zhukov 
Build-Depends: debhelper (>= 11)
Architecture: any
Standards-Version: 4.4.0
Format: 3.0 (quilt)
Files:
 e940785ffb928018f0a2b55c8ef42ef8 2016 openvpn-systemd-resolved_1.3.0-3.1.dsc
 1867cbab8944c824f2ab8ab9f6b7786f 17601 
openvpn-systemd-resolved_1.3.0.orig.tar.gz
 3fedd7af1112de53cfb82cbe50eac47c 2668 
openvpn-systemd-resolved_1.3.0-3.1.debian.tar.xz
Vcs-Browser: https://salsa.debian.org/debian/openvpn-systemd-resolved
Vcs-Git: https://salsa.debian.org/debian/openvpn-systemd-resolved.git
Checksums-Sha256:
 e5032d0cc0c4c27f8f8dfe51d80c1ec23e7f9c790445714c37d6b52f99ae4cb9 2016 
openvpn-systemd-resolved_1.3.0-3.1.dsc
 ee88c1862cb7d197adfcb0e088530993e092f7035fdd95693827d6526f2817af 17601 
openvpn-systemd-resolved_1.3.0.orig.tar.gz
 1fffc4214926f9fcbb1ecea980a658811646d6dd2a04e55298ae71e276494666 2668 
openvpn-systemd-resolved_1.3.0-3.1.debian.tar.xz
Homepage: https://github.com/jonathanio/update-systemd-resolved
Package-List: 
 openvpn-systemd-resolved deb utils optional arch=any
Directory: pool/main/o/openvpn-systemd-resolved
Priority: optional
Section: misc

Package: openvpn-systemd-resolved
Version: 1.3.0-3.1
Installed-Size: 33
Maintainer: Eugene Zhukov 
Architecture: amd64
Depends: openvpn, libnss-resolve, systemd (>= 229)
Description: integrates OpenVPN with systemd-resolved
Description-md5: c526cf1da064266c33bdd7c104c80419
Homepage: https://github.com/jonathanio/update-systemd-resolved
Section: utils
Priority: optional
Filename: 
pool/main/o/openvpn-systemd-resolved/openvpn-systemd-resolved_1.3.0-3.1_amd64.deb
Size: 15384
MD5sum: e9fb7b3de0d6382312cec11576f82c5c
SHA256: 0d36991f44dde4e03d3dc4492b5cb4e86b7951ea5933595bb88176ec954b26d3


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#987145: Updating the java-comment-preprocessor Uploaders list

2021-04-18 Thread Mattia Rizzolo
Source: java-comment-preprocessor
Version: 6.0.1-1.1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Eugene Zhukov  has retired, so can't work on
the java-comment-preprocessor package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#987146: Updating the epubcheck Uploaders list

2021-04-18 Thread Mattia Rizzolo
Source: epubcheck
Version: 4.2.4-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Eugene Zhukov  has retired, so can't work on
the epubcheck package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#987144: Updating the jing-trang Uploaders list

2021-04-18 Thread Mattia Rizzolo
Source: jing-trang
Version: 20181222+dfsg2-4
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Eugene Zhukov  has retired, so can't work on
the jing-trang package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#987143: Updating the libsaxon-java Uploaders list

2021-04-18 Thread Mattia Rizzolo
Source: libsaxon-java
Version: 1:6.5.5-12
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Eugene Zhukov  has retired, so can't work on
the libsaxon-java package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#987142: Updating the plexus-resources Uploaders list

2021-04-18 Thread Mattia Rizzolo
Source: plexus-resources
Version: 1.1.0-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Eugene Zhukov  has retired, so can't work on
the plexus-resources package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#987141: Updating the javatuples Uploaders list

2021-04-18 Thread Mattia Rizzolo
Source: javatuples
Version: 1.2-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Eugene Zhukov  has retired, so can't work on
the javatuples package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#987140: Updating the saxonhe Uploaders list

2021-04-18 Thread Mattia Rizzolo
Source: saxonhe
Version: 9.9.1.5+dfsg-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Eugene Zhukov  has retired, so can't work on
the saxonhe package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#987139: Updating the saxonb Uploaders list

2021-04-18 Thread Mattia Rizzolo
Source: saxonb
Version: 9.1.0.8+dfsg-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Eugene Zhukov  has retired, so can't work on
the saxonb package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#987138: Updating the xslthl Uploaders list

2021-04-18 Thread Mattia Rizzolo
Source: xslthl
Version: 2.1.3-5.1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Eugene Zhukov  has retired, so can't work on
the xslthl package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#987137: Updating the testng Uploaders list

2021-04-18 Thread Mattia Rizzolo
Source: testng
Version: 6.9.12-4
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Eugene Zhukov  has retired, so can't work on
the testng package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#987136: Updating the xml-maven-plugin Uploaders list

2021-04-18 Thread Mattia Rizzolo
Source: xml-maven-plugin
Version: 1.0.1-4
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Eugene Zhukov  has retired, so can't work on
the xml-maven-plugin package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#987130: libcrypt-dev makes sysvinit FTBFS: ./src/sulogin.c:978: undefined reference to `crypt'

2021-04-18 Thread Marco d'Itri
On Apr 18, Helmut Grohne  wrote:

> One aspect to this certainly is that the .pc files are now located in
> /lib, which is wrong as pkg-config does not search that directory. I've
I am not even sure that there is any point in having a .pc file for 
libcrypt (and I highly doubt that anything uses it), but I will fix this 
later in a simpler way.

-- 
ciao,
Marco


signature.asc
Description: PGP signature


  1   2   >