date:20211214

Hi Markus,

On Tue, Dec 14, 2021 at 11:45:20PM +0100, Markus Koschany wrote:
> Control: owner -1 !
> 
> Am Dienstag, dem 14.12.2021 um 21:37 +0100 schrieb Salvatore Bonaccorso:
> > Source: apache-log4j2
> > Version: 2.15.0-1
> > Severity: grave
> > Tags: security upstream
> > Justification: user security hole
> > Forwarded: https://issues.apache.org/jira/browse/LOG4J2-3221
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team
> > 
> > Control: found -1 2.15.0-1~deb11u1
> > Control: found -1 2.15.0-1~deb10u1
> > 
> > Hi,
> > 
> > The following vulnerability was published for apache-log4j2. Strictly
> > speaking it's less severe as CVE-2021-44228 as it is an incomplete fix
> > for the former CVE in certain non-default configurations.
> 
> Hi Salvatore,
> 
> I believe Stretch is not vulnerable to CVE-2021-45046 because I have removed
> the JndiLookup class when I fixed CVE-2021-44228.

Oh, good in this case I would mark it with something along the lines:

[stretch] - apache-log4j2  (Incomplete fix for 
CVE-2021-44228 not applied; JndiLookup class removed as part of fix for 
CVE-2021-44228)

> Shall I release a new DSA for CVE-2021-45046 or a regression update for CVE-
> 2021-44228 because of the incomplete upstream fix?

You are right, it might be a bit borderline towards a "regression
update". But as it is considered both a CVE assigned because of an
incomplete fix, but still can be seen as own issue I would just
allocate a new DSA number for the update and make it a regular
security update. 

My reasoning here is is not, that the CVE-2021-44228 was thought to be
meant to be addressed remains unfixed, but some other edge  cases were
not covered, making the fix incomplete, but still beeing a  own
"issue".

So just allocate a new DSA for it covering the CVE-2021-45046 CVE.

Thanks for working on the update!

Regards,
Salvatore

Bug#1001681: sight: FTBFS in unstable

2021-12-14 Thread Pierre Gruet


Hello,

On Tue, 14 Dec 2021 17:51:06 +0100 Flavien Bridault 
 wrote:

> Understood, I just wanted to avoid any overlap. I'll have a look asap. :)
>
>
> *Dr. Flavien BRIDAULT*
> Director of Software Development
> IRCAD France & IRCAD Africa
>
> flavien.brida...@ircad.fr 
> Tél. : +33 (0)3 88 119 201
> IRCAD France
> http://www.ircad.fr/
> http://www.ircad.africa/ 
>
> Suivez l'IRCAD sur Facebook
> 
>
> *IRCAD France*
> Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg Cedex
> - FRANCE
>
> Le 14/12/2021 à 17:49, Andreas Tille a écrit :
> > Hi Flavien,
> >
> > Am Tue, Dec 14, 2021 at 04:13:26PM +0100 schrieb Flavien Bridault:
> >> Thanks for the notice.
> >>
> >> This comes from DCMTK. Maybe an API change or a move of a header. 
Do you

> >> want me to have a look ?
> > I guess Steve will be very happy if you can have a look. As far as
> > I know he is not a medical imaging expert and has no interest in
> > debugging DCMTK.
> >
> > Thanks a lot for checking
> >
> > Andreas.
> >

I found the issue, which is OFIterator shall now be instantiated as 
OFListIterator(T). With this change, the package builds.


Unless you ask me otherwise, I shall make an upload with this change 
tonight.



Best wishes,

--
Pierre

Bug#1001744: cura: Cura does not start

2021-12-14 Thread Sebastián Lacuesta

Package: cura
Version: 4.8-5
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: sebastianlacue...@gmail.com

Program does not start. Message in console is:

Traceback (most recent call last):
  File "/usr/bin/cura", line 32, in 
from cura.CrashHandler import CrashHandler
  File "/usr/lib/python3/dist-packages/cura/CrashHandler.py", line 27, in

from UM.Application import Application
  File "/usr/lib/python3/dist-packages/UM/Application.py", line 9, in 
from UM.Controller import Controller
  File "/usr/lib/python3/dist-packages/UM/Controller.py", line 3, in 
from UM.Scene.Iterator.DepthFirstIterator import DepthFirstIterator
  File "/usr/lib/python3/dist-
packages/UM/Scene/Iterator/DepthFirstIterator.py", line 3, in 
from UM.Scene.SceneNode import SceneNode
  File "/usr/lib/python3/dist-packages/UM/Scene/SceneNode.py", line 14, in

from UM.Mesh.MeshBuilder import MeshBuilder
  File "/usr/lib/python3/dist-packages/UM/Mesh/MeshBuilder.py", line 4, in

from UM.Mesh.MeshData import MeshData
  File "/usr/lib/python3/dist-packages/UM/Mesh/MeshData.py", line 16, in

import scipy.spatial
  File "/usr/lib/python3/dist-packages/scipy/spatial/__init__.py", line 96, in

from .kdtree import *
  File "/usr/lib/python3/dist-packages/scipy/spatial/kdtree.py", line 5, in

from .ckdtree import cKDTree, cKDTreeNode
  File "ckdtree.pyx", line 1, in init scipy.spatial.ckdtree
ValueError: numpy.ndarray size changed, may indicate binary incompatibility.
Expected 88 from C header, got 80 from PyObject


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (700, 'testing'), (699, 'unstable'), (698, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages cura depends on:
ii  cura-engine 1:4.8-1
ii  fdm-materials   4.8-1
ii  fonts-open-sans 1.11-2
ii  python3 3.9.8-1
ii  python3-certifi 2020.6.20-1
ii  python3-charon  4.8-1
ii  python3-cryptography3.4.8-1
ii  python3-pynest2d4.8.0-2+b1
ii  python3-pyqt5   5.15.6+dfsg-1+b1
ii  python3-pyqt5.qtopengl  5.15.6+dfsg-1+b1
ii  python3-requests2.25.1+dfsg-2
ii  python3-savitar 4.8-1+b2
ii  python3-serial  3.5~b0-1
ii  python3-shapely 1.8.0-1+b1
ii  python3-uranium 4.8-1
ii  qml-module-qt-labs-folderlistmodel  5.15.2+dfsg-8
ii  qml-module-qt-labs-settings 5.15.2+dfsg-8
ii  qml-module-qtqml-models25.15.2+dfsg-8
ii  qml-module-qtquick-controls 5.15.2-2
ii  qml-module-qtquick-controls25.15.2+dfsg-4
ii  qml-module-qtquick-dialogs  5.15.2-2
ii  uranium-plugins 4.8-1

Versions of packages cura recommends:
ii  python3-zeroconf  0.37.0-1

cura suggests no packages.

-- no debconf information

Bug#1001743: ITP: libsigmf -- a header-only C++ library for working with Signal Metadata Format

2021-12-14 Thread A. Maitland Bottoms

Package: wnpp
Severity: wishlist
Owner: A. Maitland Bottoms 

* Package name: libsigmf
  Version : 1.0.0
  Upstream Author : DeepSig Inc. and libsigmf contributors.
* URL : https://github.com/deepsig/libsigmf
* License : Apache-2.0 License
  Description : A C++ library for working with SigMF metadata

Signal Metadata Format (SigMF)

Sharing sets of recorded signal data is an important part of science
and engineering. It enables multiple parties to collaborate, is often a
necessary part of reproducing scientific results (a requirement of
scientific rigor), and enables sharing data with those who do not have
direct access to the equipment required to capture it.

Unfortunately, these datasets have historically not been very portable,
and there is not an agreed upon method of sharing metadata descriptions
of the recorded data itself. This is the problem that SigMF solves.

By providing a standard way to describe data recordings, SigMF
facilitates the sharing of data, prevents the "bitrot" of datasets
wherein details of the capture are lost over time, and makes it
possible for different tools to operate on the same dataset, thus
enabling data portability between tools and workflows.

libsigmf is a free & opensource library for working with SigMF
recordings. (https://sigmf.org)

It was designed to enable the use of SigMF through static types in C++,
thus enabling things like compile-time errors and code inspection.

It was created and first authored by DeepSig Inc., and then released to
the community as an Apache 2.0-licensed FOSS project at FOSDEM 2019.

Contributors:

Nathan West
Tim O'Shea
Ben Hilburn

Bug#1001742: RFP: desktop-sound-themes -- made for freedesktop

2021-12-14 Thread Oe Ai


Package: wnpp
Version: N/A; reported 2021-12-15
Severity: wishlist

Package name :desktop-sound-themes
Version :0.6
Upstream Author :Symbiants
URL :https://github.com/SyMbiANtS/usual.art
License :(GPL)

Description :
there's 3 sound themes made in 2015, not so much people uses that
and there's no that much themes actually can be found.
It was designed for freedesktop behaviour, but can be used for any
as it is just sounds, designed for some interaction.

Depending on used DE this can have slightly different workarounds,
that can be easily scripted with symlinks and namings.
just sometimes you want to change something
or make it more like authentic, that's what it tends for.
3 because 1 theme can't fit anyone and it's just to get something people 
like.


just remembered that it was made and it's made for all

Symbiants
OeAi

Bug#1001741: flatbuffers: please update to new >= 2 version

2021-12-14 Thread A. Maitland Bottoms

Source: flatbuffers
Severity: wishlist

Dear Maintainer,

Please update the version of flatbuffers.

There is a 2.0.0 release:
https://github.com/google/flatbuffers/releases

and now a 2.0.5 tag:
https://github.com/google/flatbuffers/tags
https://qa.debian.org/cgi-bin/watch?pkg=flatbuffers
either would be a worthwhile update.

I have been chatting with some sigmf.org and deepsig folk about the
version of flatbuffers in Debian being too old to use.

I myself am about to ITP libsigmf based upon
https://github.com/deepsig/libsigmf
(which just got tags yesterday, maybe soon a release!).

-Maitland

Bug#1001331: [pkg-gnupg-maint] Bug#1001331: gpg: Provide interface to inspect (detached) signatures

2021-12-14 Thread Guillem Jover

Hi!

On Mon, 2021-12-13 at 22:58:22 +0100, Werner Koch wrote:
> > I cannot stop using as I do not know of a publicly supported interface
> > to inspect a (detached) signature to get its issuer fingerprint or
> > keyid.
> 
> You can do this:
> 
>   gpg --verify --status-fd 1 x.asc /dev/null 2>/dev/null \
> | awk '$1=="[GNUPG:]" && $2=="BADSIG" { print $3}'
> 
> which greps for 
> 
> [GNUPG:] BADSIG 19CC1C9E085B107A w...@gnupg.org
> 
> This shows the keyid but not the newer fingerprint.  Adding something
> for the fingerprint would be easy, but it takes some time before it will
> be widely enough deployed.  

Hmm, this feels like a hack though, as I don't really want to verify
it at that point, only fetch metadata from it, it would be nice to have
the equivalent of --show-keys for signatures. But I guess it fulfills
the "officially supported interface" part. For debsig-verify at least
I would not mind at all requiring a recent enough GnuPG, as long as
I'd be able to use a nicer interface. :)

But, thanks, for now I think I could instead switch to do something
like:

  gpg --no-options --no-default-keyring --keyring /dev/null \
  --status-fd 1 --verify x.asc /dev/null 2>/dev/null \
| awk '$1=="[GNUPG:]" && $2=="ERRSIG" \
   { if ($9 == "-") { print $3 } else { print $9 } }'

As that should be guaranteed regardless of keyring contents.

Thanks,
Guillem

Bug#1000715: dpkg -S fails to identify package for coreutils files: says 'no path found matching pattern' instead

2021-12-14 Thread Guillem Jover

Hi!

On Sun, 2021-11-28 at 19:09:37 +, Ray Dillinger wrote:
> I suppose this means I don't actually understand how dpkg works at all. 
> The files are there in /usr/bin, and SOMETHING, presumably an installer
> run by dpkg the most recent time coreutils was updated, installed them. 
> But dpkg does not know which installer was running at the time?  Does it
> rely on some information separate from keeping track of the actual files
> written while an installer is running, to know which installer was
> responsible for writing the files?  That's very unexpected at least to
> me.  It seems like manually maintaining the lists would be a lot more
> work than coding the automatic tracking I had assumed was happening. 
> I'd be interested in understanding the design constraints that make it
> preferable.

This is due to some people in Debian having pushed to have systems be
installed with the broken and unsupported merged-usr-via-aliased-symlinks,
while dpkg has never supported that.

  

> Not that it makes much difference on the ground right now.  The news
> relevant to this is, it's on your radar already as an issue with this
> migration/merge situation, and I'm not bringing up anything that
> wouldn't eventually get fixed otherwise.  So I suppose all there is to
> say is "known issue" and "workaround available" and close this when you
> get to it in the due course of the migration work.  I hope various
> aspects of this don't cause you too many more headaches. 

Well, personally I think the approach is broken, and adding support
for this in dpkg properly would conflict with other features that are
in the pipeline, and even then would not even be feasible for several
Debian release cycles anyway. And then the layout would still be
problematic non the less.

> Honestly I don't have much opinion on the /bin and /usr/bin merger; the
> pros and cons seem balanced on a knife edge to me.  It seems like an
> objectively good impulse to reduce complexity, but it also seems like a
> hell of a lot of work, pain, and confusion to go through right now for
> what will be, in any particular future year, only a very minor benefit. 
> On the third hand there won't come a time in the future when it's easier
> or less painful than right now, so the choice is existential; rather
> than "when", we face "whether at all" because the pro and con arguments
> are unlikely to change.

My recommendation is to either reinstall with a non-broken layout, or
revert the switch by running something like dpkg's dpkg-fsys-usrunmess
from testing, after reading its man page, as mentioned in the FAQ entry.

Thanks,
Guillem

Bug#1001695: dpkg.postinst fails to handle /var/lib/dpkg/lost+found

2021-12-14 Thread Mad Horse


On 2021/12/14 21:28, Guillem Jover wrote:

Hi!

On Tue, 2021-12-14 at 21:00:40 +0800, Mad Horse wrote:

Package: dpkg
Version: 1.21.1
Severity: important
On my system, /var/lib/dpkg is an dedicated file system mounted there, so
there
is an directory /var/lib/dpkg/lost+found, and fixup_misplaced_alternatives()
within dpkg.postinst will try to "fix" it up, causing upgrade from dpkg
1.16.1
failed.

Currently I walk this problem around by adding "lost+found" to the "known
file
list" in fixup_misplaced_alternatives(), but this function should only work
on
files, not directories, so we had better add some check to see whether this
assumed target is a file, in the first place.

Ouch, indeed. Thanks, I've fixed this locally now, and will be
included in the next upcoming release.

Thanks,
Guillem


Since this bug breaks upgradability, could you release a "hotfix" for this?

Bug#1001536: cinnamon-control-center-goa: Online Accounts crashes when trying to add account with web login

2021-12-14 Thread Alejandro Morales Lepe

Hello Fabio!

The only commands needed after "gbp buildpackage" were:

cd ..
sudo debi cinnamon_4.8.6-2+deb11u1~_amd64.changes

after which I can happily confirm that online accounts works as
expected! So, at least oh my side the test passes. Thanks for your
help!

Cheers!
- Alejandro



On Tue, 2021-12-14 at 11:58 +0100, Fabio Fantoni wrote:
> Il 14/12/2021 02:44, Alejandro Morales Lepe ha scritto:
> > Hello! thanks for your reply! I'm very happy to see the commit on
> > the
> > bullseye branch.
> > 
> > I have been trying to test, however I am not familiar with the
> > desktop's code structure, so I couldn't build it. I looked around
> > for
> > building instructions but I couldn't find something helpful. Is
> > there
> > any documenation that could help me with that?
> > 
> > I would appreciate any pointer to that.
> > 
> > Cheers!
> > - Alejandro
> 
> for build packages should be:
> 
> sudo apt install packaging-dev
> 
> sudo apt build-dep cinnamon
> 
> git clone https://salsa.debian.org/cinnamon-team/cinnamon.git
> 
> cd cinnamon
> 
> git checkout pristine-tar
> 
> git checkout upstream
> 
> git checkout bullseye
> 
> gbp buildpackage
> 
> now I don't remember if I wrote you everything you need,
> unfortunately 
> I'm going out and I don't have time to turn on the development pc and
> check, if you have problems let me know
>

Bug#1001740: bullseye-pu: package fcitx5-chinese-addons/5.0.4-1+deb11u1

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bullseye
X-Debbugs-Cc: by...@debian.org
Severity: normal

[ Reason ]
Currently the table input methods provided by fcitx5-table (in src:fcitx5-
chinese-addons) will not work due to missing dependencies on fcitx5-module-
pinyinhelper and fcitx5-module-punctuation. This is reported as
https://bugs.debian.org/1001739 . The bug is present from the very beginning.
While the latest fcitx5-chinese-addons/5.0.9-2 upload has fixed the bug in
Debian Sid, This bullseye-pu will fix this bug in Debian 11 (stable).

[ Impact ]
If this update is not present, users that only have fcitx5-table installed
(i.e. did not explicitly install fcitx5-module-pinyinhelper and fcitx5-module-
punctuation) will not be able to use any table input method in fcitx5
framework.

[ Tests ]
I have tested the fix in a freshly-installed Debian 11 VM.

[ Risks ]
No risk expected. This fix only adds two package dependencies.

[ 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 stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
  * debian/control: Add missing package dependency relationship:
+ fcitx5-table:
  - fcitx5-module-pinyinhelper (Dep)
  - fcitx5-module-punctuation (Dep) (Closes: #1001739)

Full debdiff provided in attachment.

[ Other info ]
Changes in git packaging repo:
https://salsa.debian.org/input-method-team/fcitx5-chinese-addons/-/commit/1d489d123c26e37b63fe24fe6748856a5f72103d

-- 
Regards,
Boyuan Yang

diff -Nru fcitx5-chinese-addons-5.0.4/debian/changelog fcitx5-chinese-addons-5.0.4/debian/changelog
--- fcitx5-chinese-addons-5.0.4/debian/changelog	2021-02-19 02:29:37.0 -0500
+++ fcitx5-chinese-addons-5.0.4/debian/changelog	2021-12-14 20:09:19.0 -0500
@@ -1,3 +1,12 @@
+fcitx5-chinese-addons (5.0.4-1+deb11u1) bullseye; urgency=medium
+
+  * debian/control: Add missing package dependency relationship:
++ fcitx5-table:
+  - fcitx5-module-pinyinhelper (Dep)
+  - fcitx5-module-punctuation (Dep) (Closes: #1001739)
+
+ -- Boyuan Yang   Tue, 14 Dec 2021 20:09:19 -0500
+
 fcitx5-chinese-addons (5.0.4-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru fcitx5-chinese-addons-5.0.4/debian/control fcitx5-chinese-addons-5.0.4/debian/control
--- fcitx5-chinese-addons-5.0.4/debian/control	2021-02-19 02:29:37.0 -0500
+++ fcitx5-chinese-addons-5.0.4/debian/control	2021-12-14 20:09:19.0 -0500
@@ -290,6 +290,8 @@
 Multi-Arch: same
 Depends:
  fcitx5-chinese-addons-data,
+ fcitx5-module-pinyinhelper (= ${binary:Version}),
+ fcitx5-module-punctuation (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends},
 Description: Fcitx Input Method Framework v5 (builtin table support)


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

Bug#999041: libimage-base-bundle-perl: diff for NMU version 1.0.7-3.3

2021-12-14 Thread Don Armstrong

On Mon, 13 Dec 2021, gregor herrmann wrote:
> I've prepared an NMU for libimage-base-bundle-perl (versioned as 1.0.7-3.3) 
> and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

Feel free to upload right away; thanks for fixing it. [I'm also happy if
the perl team takes over that package too.]

-- 
Don Armstrong  https://www.donarmstrong.com

Bug#1001739: fcitx5-table: Missing dependency fcitx5-module-pinyinhelper and fcitx5-module-punctuation

Package: fcitx5-table
Version: 5.0.4-1
Severity: important
Control: close -1 5.0.9-2

Binary package fcitx5-table misses runtime dependency fcitx5-module-
pinyinhelper and fcitx5-module-punctuation, which will crash all table-based
input methods such as chewing.

This bug affects packages in Debian 11 and Testing/Sid. The bug is fixed with
fcitx5-chinese-addons/5.0.9-2.

Thanks,
Boyuan Yang


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

Bug#1001738: 404 on www.debian.org/releases/testing/*/release-notes/

2021-12-14 Thread Andrew Beel

Package: www.debian.org
Version: current

The release notes for all architectural variants of the 'testing' release
are inaccessible.  Attempting to access the corresponding URLs produces 404
(Page not found) errors.

For instance, the URL for the amd64 release notes (
https://www.debian.org/releases/testing/amd64/release-notes/), which can be
accessed by clicking the hyperlinked text "Release Notes for 64-bit PC
(amd64)" at this URL (https://www.debian.org/releases/testing/releasenotes)
produces the following error:
"Page not found
We are sorry, the page you were looking for can't be found on this site.
Please inform the site owner that referred you to this page about the
broken link. You can go to the home page of the Debian project in the
meantime or use the search engine to crawl the website for the information
you are looking for.
Back to the Debian Project homepage."

Best regards.

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

2021-12-14 Thread Richard Z

If hibernation is broken by default it would be wise to disable it
completely because some systems may trash or lockup if they attempt to
hibernate with 1G of RAM.

Bug#998058: intel-compute-runtime: FTBFS due to 2 failing tests

2021-12-14 Thread Andreas Beckmann

Followup-For: Bug #998058

This is actually caused by the (transitive) B-D using different LLVM
versions: intel-graphics-compiler is built against llvm-12, while
intel-opencl-clang and spirv-llvm-translator are built against llvm-13.

This combination "only" causes some tests to fail, while other
combinations (e.g. using a intel-opencl-clang rebuilt with llvm-12) can
cause some compilation step to fail with "Aborted".

I'm working on updating the packaging of the whole stack s.t. the
dependencies only allow for a consistent llvm usage ;-)


Andreas

Bug#960883: FBZX is out of date

2021-12-14 Thread Santiago Vila

Ok, I found the "most" official tarball in the "releases" page:

https://gitlab.com/rastersoft/fbzx/-/releases

Will update the package again.

Thanks.

Bug#960883: FBZX is out of date

2021-12-14 Thread Santiago Vila

On Sun, May 17, 2020 at 09:21:38PM +0100, Steve Clark wrote:
> Package: fbzx
> Version: 3.1.0-1
> 
> FBZX is a bit out of date. The current version in Buster is 3.1.0 which
> has issues with full-screen where it changes a multi-monitor setup to
> mirrored from what-ever you had previously. Also, it doesn't seem to
> append to TZX/TAP files when SAVEing as it should.
> 
> The upstream version 4.0.0 has neither of these issues.

Thanks for the report, and sorry for the late reply. I've uploaded
version 4.3.1 for unstable today, but I'm not closing this bug yet
because that's only the latest version available from the author's
home page, but not the latest version in github (for some reason there
is not a "canonical URL" for the tarball). I'll ask the author about
this and will probably upload again in a few days.

Thanks.

Bug#999082: offering to help with checksecurity

2021-12-14 Thread Richard Lewis

Hi,

I don't know how much attention this package gets, but i still use it

The repository at https://salsa.debian.org/rpil2/checksecurity/

includes a 'modernised' 3-line debian/rules (plus other things) that
would, i think, fix this bug.

That repository includes all the history that git-buildpackage could
import, and makes various other changes - i really wanted to fix
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994707 but . I ended
up doing more, including rewriting the main perl script in bash and
fixing some other inconsistencies and logfile locations - so you might
not want all of what is in there, but perhaps it is helpful.

If there is another/better way to help keep this package in Debian do
let me know -  as ever, i find myself not really sure how to help.

Bug#1001054: /sbin/start-stop-daemon: start-stop-daemon --exec should fall back to other methods if readlink fails

2021-12-14 Thread Guillem Jover

Hi!

On Fri, 2021-12-03 at 09:56:34 +0100, Andrej Shadura wrote:
> Package: dpkg
> Version: 1.20.9
> Severity: normal
> File: /sbin/start-stop-daemon

> I was debugging an init script in a Debian Docker container, and found
> it always fails to stop the daemon. Upon a closer inspection, I found
> that --exec, which init-d-script always passed, never matches the
> executable, even if a PID file is used. I then checked the source and
> tried to do the steps manually:
> 
> root@d351c00abb80:/# ls /proc/1841/exe -l
> ls: cannot read symbolic link '/proc/1841/exe': Permission denied
> lrwxrwxrwx 1 sphinxsearch sphinxsearch 0 Dec  3 08:46 /proc/1841/exe
> 
> In fact, cwd and root are also inaccessible. I’m not sure it’s some
> security setting Docker applies or is it something becaue of the
> containers, but the fact is that --exec is unusable in this setting.

Yes, this seems to be a known regression in docker, see
 and all related bugs
closed w/o any action. It seems you can workaround this by running the
docker image with ptrace Linux capabilities (even though that looks
rather unintuitive).

> I guess falling back to other matching methods might be more useful than
> failing to stop at all.

I don't think that would be safe at all, as the interface is expected
to AND all the match options, to properly select what to act on. And
in any case this looks like a bug in docker anyway.

Given the above I'm going to be closing this, unless there's a very
compelling argument to do otherwise.

Thanks,
Guillem

Bug#929700: [Debichem-devel] [help] pymol: Deprecation warning during startup

2021-12-14 Thread Daniel Leidert

Am Dienstag, dem 14.12.2021 um 21:17 +0100 schrieb Andreas Tille:
> Hi,
> 
> I think I've fixed the issue[1] and it works nicely at command line. 
> Unfortunately
> Salsa-CI[2] shows a new issue
> 
>    AttributeError: module 'importlib' has no attribute 'util'
> 
> which I do not understand at all since at command line there is the attribute
> 'util'.

importlib/util.py is part of libpython3.x-minimal, and while libpython3.10-
minimal gets installed, libpython3.9-minimal is not and it seems, python3.9 is
the default. So technically the error would be correct.

As I said in my other mail, maybe use

import importlib.util; ...

Not sure of that fixes your dependencies. You have to depend on the right
libpython3.x-minimal, it seems.

HTH Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#1001729: apache-log4j2: CVE-2021-45046: Incomplete fix for CVE-2021-44228 in certain non-default configurations

2021-12-14 Thread Markus Koschany

Control: owner -1 !

Am Dienstag, dem 14.12.2021 um 21:37 +0100 schrieb Salvatore Bonaccorso:
> Source: apache-log4j2
> Version: 2.15.0-1
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> Forwarded: https://issues.apache.org/jira/browse/LOG4J2-3221
> X-Debbugs-Cc: car...@debian.org, Debian Security Team
> 
> Control: found -1 2.15.0-1~deb11u1
> Control: found -1 2.15.0-1~deb10u1
> 
> Hi,
> 
> The following vulnerability was published for apache-log4j2. Strictly
> speaking it's less severe as CVE-2021-44228 as it is an incomplete fix
> for the former CVE in certain non-default configurations.

Hi Salvatore,

I believe Stretch is not vulnerable to CVE-2021-45046 because I have removed
the JndiLookup class when I fixed CVE-2021-44228.

Shall I release a new DSA for CVE-2021-45046 or a regression update for CVE-
2021-44228 because of the incomplete upstream fix?

Regards,

Markus



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

Bug#982555: mutt: Messages sent by Gmail SMTP are recorded in sent box with wrong charset/encoding


On Thu, 11 Feb 2021 16:40:53 -0300 Marcelo Luiz de Laia  
wrote:

Package: mutt
Version: 2.0.5-1
Severity: minor

Dear Maintainer,

After upgrade to mutt:amd64 2.0.5-1, messages sent by gmail was recorded in
sent box with wrong charset, like this:

Finalizei a inserï¿½ï¿½o das ATA no Processo.
Sï¿½o seis ATA e um documento resumo.
Encaminhei ao Lourenï¿½o e Angelo para leitura e assinatura.
Fique ï¿½ vontade para revisar.
Abraï¿½os!

These messages have the headers:

Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

This is the same headers present in previous messages sent with mutt 2.0.2-1.


I've reviewed the changes between 2.0.2 and 2.0.5 and there was nothing 
fixed related to character set handling or saving of messages.


Do you have $record set, or have you left it empty?  What is your value 
of $send_charset?  Are you still having this problem?


-Kevin


signature.asc
Description: PGP signature

Bug#965948: mutt: Incorrect handling of whitespace in aliases file


On Tue, 21 Jul 2020 11:38:18 +0100 Matthew Foulkes  
wrote:

Package: mutt
Version: 1.14.5-1
Severity: minor
X-Debbugs-Cc: m.foul...@blueyonder.co.uk

Dear Maintainer,

Before version 1.14.15-1, mutt used to ignore extra whitespace between 
the end of the long name and the beginning of the email address in the 
aliases file. Given an aliases file organised into columns


alias   alice  Alice Aardvark
alias   bobBob Bee   

typing "mutt alice" would have generated an email with

To: Alice Aardvark 

Since the update to 1.14.15-1, all whitespace following the long name is 
preserved exactly and you get


To: Alice Aardvark


I think this was a consequence of +EXACT_ADDRESS being configured. 
Since the Debian package now has that turned off, I think this bug 
should be resolved.


-Kevin


signature.asc
Description: PGP signature

Bug#990828: mutt can not delete mails due to access rights


On Thu, 08 Jul 2021 19:26:06 +0200 "Hans-J. Ullrich"  
wrote:

Package: mutt
Version: 2.0.5-4.1
Severity: important

Dear Maintainer,

it looks like, that mutt is not able to delete mails due to access rights. 
I checked the settings of the files and directories, but these seem to be ok for me. 
This is the output: 

ls -la / | grep var 
drwxr-xr-x  14 root root4096 18. Mai 11:33 var 

ls -la /var | grep mail 
drwxrwsr-x   2 root mail   4096  8. Jul 16:02 mail 

ls -la /var/mail/myusername 
-rw-rw 1 myusername mail 55330396  8. Jul 16:02 /var/mail/myusername 


(The term "myusername" is an alias for my real username)

When I remember correctly, this bug appeared in the past from time to time and 
was fixed. Now it appears again.

It would be nice, if you could take a look at it.

Thank you and best regards


Sorry I also can't duplicate this problem.  This ticket, in addition to 
#969279 seem to hint something is very odd about your system or your 
configuration.


Perhaps more details would help illuminate the problem.  Can you 
duplicate it with a minimal muttrc file?  Does it happen just with your 
spoolfile, or with other mbox files in your home directory?  Is there a 
problem with the mutt_dotlock program installation?  What error messages 
are you getting?


-Kevin



signature.asc
Description: PGP signature

Bug#969279: mutt - could not create tempory files


On Tue, 31 Aug 2021 11:09:30 +0200 "Hans-J. Ullrich"  
wrote:

Package: mutt
Version: 2.0.5-4.1
Followup-For: Bug #969279

Dear Maintainer,

I can confirm this issue now for almost half a year, maybe longer. 
However, this issue appears only on amd64, on i386 it seems to work well.


Sorry, I can't duplicate this problem.  You'll need to provide more 
details, and steps to reliably reproduce.


What is $tmpdir set to?  Does this only happen when you tag-delete *all* 
messages and quit, or are there other circumstances?  Does this happen 
just for your $spoolfile, or does it also happen for mailboxes in your 
home directory?  What about maildir vs mbox files?


-Kevin


signature.asc
Description: PGP signature

Bug#671847: [Mutt] #3879: mutt: encoded-words are not decoded in mailto:


On Sat, 01 Oct 2016 21:01:11 - Mutt  wrote:

#3879: mutt: encoded-words are not decoded in mailto:
+--
  Reporter:  antonio@…  |  Owner:  mutt-dev
  Type:  defect | Status:  closed
  Priority:  major  |  Milestone:
 Component:  charset|Version:  1.7.0
Resolution:  fixed  |   Keywords:
+--
Changes (by Kevin McCarthy ):

 * status:  reopened => closed
 * resolution:   => fixed


Antonio, I believe this ticket can be closed now, since it was fixed in 
1.7.


-Kevin


signature.asc
Description: PGP signature

Bug#997845: Your mail

2021-12-14 Thread nick black

ought i upload a -4 with a changelog entry marking the bug
closed? i didn't mark it closed in the changelog because i
explicitly wanted the bug left open.

sorry for any confusion -- i'm certainly not trying to work
around this issue in the long term by reducing testing =]. i
just know that it's not going to be fixed until growlight 1.2.38
moves to unstable from experimental, which requires notcurses3,
which is in the NEW queue awaiting FTPteam approval.

at that point, i'll be reenabling the test. so i don't consider
1.2.37-3 as having "closed" the bug whatsoever. but it ought be
closed shortly after notcurses3 hits unstable =].

Bug#929612: sispmctl: support EG-PMS2 aka usb-id 04b4:fd15

2021-12-14 Thread Frank Heckenbach

I wrote:

: Still broken in stable and testing.

Still broken in current stable, testing and unstable.

: upstream 4.1 still works out of the box.

Still does.

: Does anyone read these bug reports at all?

Apparently not. :(

Bug#997845: Your mail

2021-12-14 Thread nick black

you are correct in all of your assumptions =].


signature.asc
Description: PGP signature

Bug#999320: libwww-indexparser-perl: missing required debian/rules targets build-arch and/or build-indep

2021-12-14 Thread Christoph Biedl

Control: tags 999320 pending

> Your package does not include build-arch and/or build-indep targets in
> debian/rules. This is required by Debian Policy section 4.9, since 2012.
> https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules

After a brief exchange with James Bromberger: I will take over
maintainership for this package. Upload will take a few days, please be
patient.

Christoph


signature.asc
Description: PGP signature

Bug#997845: Your mail


Control: fixed -1 1.2.37-3

Hi Nick

On Mon, 25 Oct 2021 22:43:44 -0400 nick black  
wrote:

i'm not sure whether the "forwarded" tag applies in this case,
but i've created an upstream bug (i am the upstream author) at
https://github.com/dankamongmen/growlight/issues/153.


I understand you uploaded -3 without the test to have it not removed 
from testing. For the migration to happen, this bug should not cause 
regressions in testing and as such, the version you want to migrate 
should be marked as fixed (doing so now). I'm *not* closing the bug as I 
assume you want to track adding the test back and properly close it with 
the version that fixes the bug.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001724: /usr/bin/firefox is difficult to wrap

2021-12-14 Thread Mike Hommey

reassign 1001724 firefox-esr
thanks

On Tue, Dec 14, 2021 at 04:18:36PM -0400, Joey Hess wrote:
> Package: firefox
> Version: 94.0.2-1
> Severity: normal
> 
> I have a ~/bin/firefox wrapper script ahead of the usual firefox in PATH.
> 
> #!/bin/sh
> MOZ_USE_XINPUT2=1 /usr/bin/firefox "$@"
> 
> This has a very surprising behavior, because /usr/bin/firefox contains:
> 
> FIREFOX="$(command -v firefox)"
> [ -x "$FIREFOX.real" ] && exec "$FIREFOX.real" "$@"
> 
> So FIREFOX gets set to ~/bin/firefox and there is no ~/bin/firefox.real
> to run. So instead it falls through and runs firefox-esr which I also happen
> to have installed. Since firefox-esr doesn't use my usual firefox
> config, my wrapper script effectively breaks the configuration.
> 
> The workaround was to change my wrapper script to this:
> 
> #!/bin/sh
> MOZ_USE_XINPUT2=1 PATH=/usr/bin:$PATH exec firefox "$@"
> 
> Although notice that this can turn into an infinite loop if firefox
> is somehow not in /usr/bin anymore. Also it prevents firefox from running
> any other wrapper scripts I might have in ~/bin when starting a program
> such as a PDF viewer. So this is a suboptimal workaround.
> 
> I don't know if there is a reason you are not using $0 or not simply
> hardcoding the path to firefox.real, either seems like a way to avoid this.

Using $0 causes #818159. I guess hardcoding /usr/bin/firefox would work.

Mike

Bug#1001736: typedload: autopkgtest regression: Library stubs not installed for "attr._make" (or incompatible with Python 3.7)


Source: typedload
Version: 2.14-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of typedload the autopkgtest of typedload fails in 
testing when that autopkgtest is run with the binary packages of 
typedload from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
typedload  from testing2.14-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Are you really 
trying to test with python3.7?


Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=typedload

https://ci.debian.net/data/autopkgtest/testing/amd64/t/typedload/17556987/log.gz

mypy --python-version=3.7 --config-file mypy.conf typedload
typedload/dataloader.py:683: error: Library stubs not installed for 
"attr._make" (or incompatible with Python 3.7)
typedload/dataloader.py:683: note: Hint: "python3 -m pip install 
types-attrs"
typedload/dataloader.py:683: note: (or run "mypy --install-types" to 
install all missing stub packages)
typedload/dataloader.py:683: note: See 
https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports

Found 1 error in 1 file (checked 6 source files)
make: *** [Makefile:12: mypy] Error 1
autopkgtest [07:11:50]: test command1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001735: node-trust-keyto: autopkgtest regression: Cannot find module '@trust/keyto'


Source: node-trust-keyto
Version: 2.0.0~alpha1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of node-trust-keyto the autopkgtest of 
node-trust-keyto fails in testing when that autopkgtest is run with the 
binary packages of node-trust-keyto from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
node-trust-keyto   from testing2.0.0~alpha1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=node-trust-keyto

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-trust-keyto/17556375/log.gz

internal/modules/cjs/loader.js:818
  throw err;
  ^

Error: Cannot find module '@trust/keyto'
Require stack:
- /tmp/autopkgtest-lxc.wqzautxi/downtmp/build.Vrg/src/[eval]
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 [eval]:1:1
at Script.runInThisContext (vm.js:120:18)
at Object.runInThisContext (vm.js:309:38)
at Object. ([eval]-wrapper:10:26)
at Module._compile (internal/modules/cjs/loader.js:999:30)
at evalScript (internal/process/execution.js:94:25) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [ 
'/tmp/autopkgtest-lxc.wqzautxi/downtmp/build.Vrg/src/[eval]' ]

}
autopkgtest [06:13:32]: test command1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001734: golang-github-rogpeppe-go-internal: autopkgtest regression: Reversed (or previously applied) patch detected!


Source: golang-github-rogpeppe-go-internal
Version: 1.8.0-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of golang-github-rogpeppe-go-internal the 
autopkgtest of golang-github-rogpeppe-go-internal fails in testing when 
that autopkgtest is run with the binary packages of 
golang-github-rogpeppe-go-internal from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
golang-github-rogpeppe-go-internal from testing1.8.0-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] 
https://qa.debian.org/excuses.php?package=golang-github-rogpeppe-go-internal


https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-github-rogpeppe-go-internal/17556363/log.gz

   debian/rules override_dh_auto_test
make[1]: Entering directory 
'/tmp/autopkgtest-lxc.k67h7x0n/downtmp/autopkgtest_tmp'

patch -N -p1 -i debian/0001-Allow-TestSimple-cover-to-PASS.patch
patching file 
_build/src/github.com/rogpeppe/go-internal/testscript/testscript.go

Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file 
_build/src/github.com/rogpeppe/go-internal/testscript/testscript.go.rej
make[1]: Leaving directory 
'/tmp/autopkgtest-lxc.k67h7x0n/downtmp/autopkgtest_tmp'

make[1]: *** [debian/rules:9: override_dh_auto_test] Error 1
make: *** [debian/rules:4: build] Error 2
autopkgtest [06:12:32]: test dh-golang-autopkgtest



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001733: dh-sysuser: autopkgtest failure: FAILED: user _runit-log exists after purge or environment is not clean


Source: dh-sysuser
Version: 1.3.6+really1.4.0
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package dh-sysuser, great. 
However, it fails. Currently this failure is blocking the migration to 
testing [1]. Can you please investigate the situation and fix it?


I copied some of the output at the bottom of this report.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=dh-sysuser

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dh-sysuser/17221501/log.gz

OK: user libvirtdbus succesfully created
Reading package lists...
Building dependency tree...
Reading state information...
Package 'libvirt-dbus' is not installed, so not removed
The following packages were automatically installed and are no longer 
required:
  adwaita-icon-theme alsa-topology-conf alsa-ucm-conf at-spi2-core 
bsd-mailx

  dconf-gsettings-backend dconf-service dmeventd dns-root-data dnsmasq-base
  exim4-base exim4-config exim4-daemon-light fontconfig fontconfig-config
  fonts-dejavu-core gettext-base glib-networking glib-networking-common
  glib-networking-services gsettings-desktop-schemas gstreamer1.0-libav
  gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-x
  gtk-update-icon-cache hicolor-icon-theme i965-va-driver ibverbs-providers
  intel-media-va-driver iptables ipxe-qemu iso-codes libaa1 libaacs0 
libaio1

  libaom3 libasound2 libasound2-data libass9 libasyncns0 libatk-bridge2.0-0
  libatk1.0-0 libatk1.0-data libatspi2.0-0 libavahi-client3
  libavahi-common-data libavahi-common3 libavc1394-0 libavcodec58 
libavfilter7

  libavformat58 libavutil56 libbdplus0 libblas3 libbluray2
  libboost-iostreams1.74.0 libboost-thread1.74.0 libbrlapi0.8 libbs2b0
  libcaca0 libcacard0 libcairo-gobject2 libcairo2 libcapstone4 
libcdparanoia0

  libchromaprint1 libcodec2-0.9 libcolord2 libcups2 libdatrie1 libdav1d5
  libdaxctl1 libdconf1 libdecor-0-0 libdecor-0-plugin-1-cairo libdeflate0
  libdevmapper-event1.02.1 libdrm-amdgpu1 libdrm-common libdrm-intel1
  libdrm-nouveau2 libdrm-radeon1 libdrm2 libdv4 libdw1 libepoxy0
  libevent-2.1-7 libexecs0 libfdt1 libflac8 libflite1 libfontconfig1
  libfreetype6 libfribidi0 libfuse2 libfuse3-3 libgbm1 libgdk-pixbuf-2.0-0
  libgdk-pixbuf2.0-bin libgdk-pixbuf2.0-common libgfapi0 libgfortran5
  libgfrpc0 libgfxdr0 libgl1 libgl1-mesa-dri libglapi-mesa libglusterfs0
  libglvnd0 libglx-mesa0 libglx0 libgme0 libgnutls-dane0 libgomp1
  libgraphite2-3 libgsm1 libgstreamer-plugins-base1.0-0 libgstreamer1.0-0
  libgtk-3-0 libgtk-3-bin libgtk-3-common libgudev-1.0-0 libharfbuzz0b
  libibverbs1 libidn12 libiec61883-0 libigdgmm11 libip6tc2 libiscsi7
  libjack-jackd2-0 libjansson4 libjbig0 libjpeg62-turbo liblapack3 
liblcms2-2

  liblilv-0-0 libllvm12 liblockfile-bin liblockfile1 liblvm2cmd2.03 libmfx1
  libmp3lame0 libmpg123-0 libmysofa1 libndctl6 libnetfilter-conntrack3
  libnfnetlink0 libnfs13 libnftables1 libnftnl11 libnl-3-200 
libnl-route-3-200
  libnorm1 libnspr4 libnss3 libnuma1 libogg0 libopenjp2-7 libopenmpt0 
libopus0
  liborc-0.4-0 libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 
libpcap0.8
  libpciaccess0 libpcsclite1 libpgm-5.3-0 libpixman-1-0 libpmem1 
libpng16-16
  libpocketsphinx3 libpopt0 libpostproc55 libproxy1v5 libpulse0 
libquadmath0

  librabbitmq4 librados2 libraw1394-11 librbd1 librdmacm1 librsvg2-2
  librsvg2-common librubberband2 libsamplerate0 libsdl2-2.0-0
  libsensors-config libsensors5 libserd-0-0 libshine3 libshout3 libslang2
  libslirp0 libsnappy1v5 libsndfile1 libsodium23 libsord-0-0 libsoup2.4-1
  libsoxr0 libspeex1 libsphinxbase3 libspice-server1 libsratom-0-0
  libsrt1.4-gnutls libssh-4 libssh-gcrypt-4 libswresample3 libswscale5
  libtag1v5 libtag1v5-vanilla libthai-data libthai0 libtheora0 libtiff5
  libtwolame0 libudfread0 libunbound8 libunwind8 liburing1 libusb-1.0-0
  libusbredirparser1 libv4l-0 libv4lconvert0 libva-drm2 libva-x11-2 libva2
  libvdeplug2 libvdpau-va-gl1 libvdpau1 libvidstab1.1 libvirglrenderer1
  libvirt-clients libvirt-daemon libvirt-daemon-config-network
  libvirt-daemon-config-nwfilter libvirt-daemon-driver-lxc
  libvirt-daemon-driver-qemu libvirt-daemon-driver-vbox
  libvirt-daemon-driver-xen libvirt-daemon-system
  libvirt-daemon-system-systemd libvirt-glib-1.0-0 libvirt-glib-1.0-data
  libvirt0 libvisual-0.4-0 libvorbis0a libvorbisenc2 libvorbisfile3 libvpx7
  libvte-2.91-0 libvte-2.91-common libvulkan1 libwavpack1 
libwayland-client0
  libwayland-cursor0 libwayland-egl1 libwayland-server0 libwebp6 
libwebpmux3

  libx11-6 libx11-data libx11-xcb1 libx264-160 libx265-199 libxau6
  libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-randr0
  libxcb-render0 libxcb-shm0 libxcb-sync1 libxcb-xfixes0 libxcb1
  libxcomposite1 libxcursor1 libxdamage1

Bug#1001107:

2021-12-14 Thread Daniel B

I see that LLVM are now active on GitHub Issues, so I have filed this there
too. Hopefully someone on either side eventually notices it ;-)

https://github.com/llvm/llvm-project/issues/52696

Bug#1001657: Ball fails its autopkgtest - how to properly deal with sip files?

Control: tags -1 pending

I've fixed the dh_installdocs issue in Git[1] but wanted to solve
the autopkgtest issue as well.  At first I provided the proper
module name[2] which brought me back to the old discussion here:

Am Thu, Sep 23, 2021 at 11:59:50PM +0200 schrieb Étienne Mollier:
> Hi Nilesh,
> 
> Nilesh Patra, on 2021-09-23:
> > The problems that I see on a quick look are:
> > 1) the import name is wrong, it should be BALL instead of ball
> > this is trivial to fix
> > 2) This is the bigger problem. python3-ball is broken, it needed to compile
> > the .sip files, to make an so lib
> > and import that. This is not happening. Probably fixing this is also not
> > hard, just passing SIP_LIBRARY with cmake
> > might do the trick, but again no time.
> > 
> > Also, my understanding is that it was always broken, and has got barely
> > anything to do with my bug fix.
> > Since I am very very short on time, @Etienne, could you please fix this and
> > dput?
> 
> Thanks for drawing my attention on this!  I can have a look,
> sure, although I don't guarantee this will be solved this
> evening; it looks like quite the machine cycles hog.  It is the
> first time I hear about sip, it looks kinda similar to swig.
> Will run an overnight build to see if I can manage to do
> something with the SIP_LIBRARY environment variable; thanks for
> the tip!

For whatever reason python3-sip did not ended up in the package
dependencies. Thus I added it explicitly[3].  But the autopkg issue
remains[4]:

autopkgtest [17:09:54]: test autodep8-python3: [---
Testing with python3.9:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/BALL.py", line 5, in 
from BALLCore import *
ModuleNotFoundError: No module named 'BALLCore'
autopkgtest [17:09:55]: test autodep8-python3: ---]

and we have the sip file 

   /usr/lib/python3/dist-packages/BALL/BALLCore.sip

I have no idea why this is not found.

Kind regards

   Andreas.


[1] 
https://salsa.debian.org/med-team/ball/-/commit/451bb880214e04c1042fabd19acef30fbf1ede78
[2] 
https://salsa.debian.org/med-team/ball/-/commit/129417031797d553a3f87a9de5abfd05d6e848c0
[3] 
https://salsa.debian.org/med-team/ball/-/commit/df9bd210dd6c172563583bc14278cf3bbc0f047b
[4] https://salsa.debian.org/med-team/ball/-/jobs/2278393

-- 
http://fam-tille.de

Bug#1001577: m17n-lib: internal vs external symbols

Hi,

在 2021-12-12星期日的 10:04 +0100，Harshula写道：
> Source: m17n-lib
> Version: 1.8.0-3
> Severity: normal
> X-Debbugs-CC: by...@debian.org
> 
> 
> Hi Boyuan,
> 
> re: 
> https://salsa.debian.org/input-method-team/m17n-lib/-/commit/fed1505e84be88c1d21105df87763a0374693c9e
> 
> Can you please review your commit, above? The changelog entry only says 
> "Refreshed". Was it an accidental error?
> 
> My understanding is that libm17n-X.so and libm17n-gd.so are dynamically 
> loaded libraries that are used internally by the m17n library and not 
> part of the external API.
> 
> Hence, libm17n's internal dynamically loaded library symbols were 
> intentionally removed from the symbols file in Commit 
> aa08c48b1a3cafdd56749d821891859df1ca91ba .

I wasn't aware of the issue around internal & external symbols. Sorry for the
issue! Since the change was made back in 2018, I could not recall my exact
thought when I made those changes. Please feel free to correct the symbol
file.

Thanks,
Boyuan


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

Bug#1001732: node-n3: autopkgtest regression: Cannot find module 'readable-stream'


Source: node-n3
Version: 1.12.1+~1.2.3-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of node-n3 the autopkgtest of node-n3 fails in 
testing when that autopkgtest is run with the binary packages of node-n3 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
node-n3from testing1.12.1+~1.2.3-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Are you 
missing a (test) dependency?


Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=node-n3

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-n3/17556374/log.gz

internal/modules/cjs/loader.js:818
  throw err;
  ^

Error: Cannot find module 'readable-stream'
Require stack:
- /usr/share/nodejs/n3/lib/N3Store.js
- /usr/share/nodejs/n3/lib/index.js
- /tmp/autopkgtest-lxc.abtfpkoq/downtmp/build.2gd/src/[eval]
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/n3/lib/N3Store.js:10:23)
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) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
'/usr/share/nodejs/n3/lib/N3Store.js',
'/usr/share/nodejs/n3/lib/index.js',
'/tmp/autopkgtest-lxc.abtfpkoq/downtmp/build.2gd/src/[eval]'
  ]
}
autopkgtest [06:12:50]: test command1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001685: mailman: CVE-2021-44227 and updated fix for CVE-2021-42097

Hi Thomas,

On Tue, Dec 14, 2021 at 09:13:02PM +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + upstream security
> 
> Hi Thomas,
> 
> On Tue, Dec 14, 2021 at 11:23:53AM +0100, Thomas Arendsen Hein wrote:
> > Package: mailman
> > Version: 1:2.1.29-1+deb10u2
> > Severity: important
> > 
> > Hi!
> > 
> > Mailman 2.1.38 has been released to fix CVE-2021-44227 (a list
> > member or moderator can get a CSRF token and craft an admin request),
> > and 2.1.39 has been released to fix a regression in above fix and
> > to update the fix for CVE-2021-42097.
> > 
> > https://mail.python.org/archives/list/mailman-annou...@python.org/thread/D54X2LXETPMVP5KZNM2WP6Z6UOPJXSVD/
> > Can you update the packages for Debian buster (and ideally for
> > stretch LTS, too)?
> 
> See: https://bugs.debian.org/1001556 so it's pending for the next
> buster point release.
> 
> > In bug report #1000367 an updated package 1:2.1.29-1+deb10u3 has
> > been created, but it is not yet available via buster-security.
> > That's why I have marked this ticket with "1:2.1.29-1+deb10u2"
> > above.
> 
> Samewise: https://bugs.debian.org/1000386 
> 
> So in summary, all the CVE fixes are already pending for the next
> point release for buster.

Btw, that said, I would appreciate if the proposed packages get some
additional testing exposure.

I will try to provide in the next days as well a followup to the
additional regression fix and improvement bugfix mentioned from the
2.1.39 release.

Regards,
Salvatore

Bug#1001731: linux: Please consider enabling CONFIG_TLS_DEVICE

2021-12-14 Thread Andrea Pappacoda

Source: linux
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

I saw that you recently enabled the tls module. Great! It would also be nice to
enable CONFIG_TLS_DEVICE, so that the kernel can offload TLS handling to the
hardware, when supported (like with some network cards).

It seems that Ubuntu enabled it as well:
https://git.launchpad.net/~ubuntu-
kernel/ubuntu/+source/linux/+git/unstable/tree/debian.master/config/config.common.ubuntu?id=08e3a17135e7c81c89b6f8c78bd81090a2bfdf74#n11176

Thanks :)


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYbkAERQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSfg9AP9sVwJymbEa/nNGovOPKN9oC1V2/Vn5
b3X1Qqi8acNgGwD/U/trAdvj3a6L8YFyxOB4WXFtbtB7ucXz61mwuhHKPAU=
=v7EH

Bug#1001730: RFH: qdarkstyle

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-pyt...@lists.debian.org debian-scie...@lists.debian.org

Package qdarkstyle is currently team-maintained under Debian Python Team. It
is a (build-)dependency for the versatile Python-based scientific IDE spyder (
https://tracker.debian.org/pkg/spyder ).

The current version of qdarkstyle in Debian archive is 2.8.1. Newer releases
of spyder IDE requires qdarkstyle 3.x, which seems to need a lot more
packaging efforts in handling upstream buildsystem and dependencies. Any help
around new version packaging would be welcome.

-- 
Regards,
Boyuan Yang


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

Bug#1001729: apache-log4j2: CVE-2021-45046: Incomplete fix for CVE-2021-44228 in certain non-default configurations

Source: apache-log4j2
Version: 2.15.0-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://issues.apache.org/jira/browse/LOG4J2-3221
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2.15.0-1~deb11u1
Control: found -1 2.15.0-1~deb10u1

Hi,

The following vulnerability was published for apache-log4j2. Strictly
speaking it's less severe as CVE-2021-44228 as it is an incomplete fix
for the former CVE in certain non-default configurations.

CVE-2021-45046[0]:
| It was found that the fix to address CVE-2021-44228 in Apache Log4j
| 2.15.0 was incomplete in certain non-default configurations. This
| could allows attackers with control over Thread Context Map (MDC)
| input data when the logging configuration uses a non-default Pattern
| Layout with either a Context Lookup (for example, $${ctx:loginId}) or
| a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious
| input data using a JNDI Lookup pattern resulting in a denial of
| service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to
| localhost by default. Note that previous mitigations involving
| configuration such as to set the system property
| `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this specific
| vulnerability. Log4j 2.16.0 fixes this issue by removing support for
| message lookup patterns and disabling JNDI functionality by default.
| This issue can be mitigated in prior releases (2.16.0) by removing
| the JndiLookup class from the classpath (example: zip -q -d
| log4j-core-*.jar
| org/apache/logging/log4j/core/lookup/JndiLookup.class).


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-45046
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046
[1] https://issues.apache.org/jira/browse/LOG4J2-3221
[2] https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046
[3] https://www.openwall.com/lists/oss-security/2021/12/14/4

Regards,
Salvatore

Bug#1001728: python-aiohttp breaks dask autopkgtest: 'async_timeout' has no attribute 'Timeout'


Source: python-aiohttp
Control: found -1 python-aiohttp/3.8.1-3
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks

Dear maintainer(s),

With a recent upload of python-aiohttp the autopkgtest of dask fails in 
testing when that autopkgtest is run with the binary packages of 
python-aiohttp from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
python-aiohttp from testing3.8.1-3
dask   from testing2021.09.1+dfsg-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. To me it looks 
like this is all python-aiohttp code path, so I *suspect* the issue is 
with python-aiohttp itself.


Currently this regression is blocking the migration of python-aiohttp to 
testing [1].


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-aiohttp

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dask/17553992/log.gz

Testing with python3.9:
= test session starts 
==
platform linux -- Python 3.9.9, pytest-6.2.5, py-1.10.0, pluggy-0.13.0 
-- /usr/bin/python3.9

cachedir: .pytest_cache
rootdir: /tmp/autopkgtest-lxc.eom7aakg/downtmp/autopkgtest_tmp
collecting ... collected 9095 items / 1 error / 3 deselected / 21 
skipped / 9070 selected


 ERRORS 

__ ERROR collecting bytes/tests/test_http.py 
___

/usr/lib/python3/dist-packages/dask/bytes/tests/test_http.py:18: in 
aiohttp = pytest.importorskip("aiohttp")
/usr/lib/python3/dist-packages/aiohttp/__init__.py:6: in 
from .client import (
/usr/lib/python3/dist-packages/aiohttp/client.py:36: in 
from . import hdrs, http, payload
/usr/lib/python3/dist-packages/aiohttp/http.py:7: in 
from .http_parser import (
/usr/lib/python3/dist-packages/aiohttp/http_parser.py:29: in 
from .helpers import NO_EXTENSIONS, BaseTimerContext
/usr/lib/python3/dist-packages/aiohttp/helpers.py:732: in 
def ceil_timeout(delay: Optional[float]) -> async_timeout.Timeout:
E   AttributeError: module 'async_timeout' has no attribute 'Timeout'


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001727: python-aiohttp breaks postfix-mta-sts-resolver autopkgtest: Job for postfix-mta-sts-resolver.service failed

Source: python-aiohttp, postfix-mta-sts-resolver
Control: found -1 python-aiohttp/3.8.1-3
Control: found -1 postfix-mta-sts-resolver/1.0.0-4
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of python-aiohttp the autopkgtest of
postfix-mta-sts-resolver fails in testing when that autopkgtest is run
with the binary packages of python-aiohttp from unstable. It passes when
run with only packages from testing. In tabular form:

passfail
python-aiohttp from testing3.8.1-3
postfix-mta-sts-resolver from testing1.0.0-4
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python-aiohttp to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-aiohttp

https://ci.debian.net/data/autopkgtest/testing/amd64/p/postfix-mta-sts-resolver/17553994/log.gz

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Job for postfix-mta-sts-resolver.service failed because the control
process exited with error code.
See "systemctl status postfix-mta-sts-resolver.service" and "journalctl
-xeu postfix-mta-sts-resolver.service" for details.

Traceback (most recent call last):
File
"/tmp/autopkgtest-lxc.e660v08n/downtmp/build.EcE/src/debian/tests/run",
line 75, in

main()
File
"/tmp/autopkgtest-lxc.e660v08n/downtmp/build.EcE/src/debian/tests/run",
line 62, in main

set_up()
File
"/tmp/autopkgtest-lxc.e660v08n/downtmp/build.EcE/src/debian/tests/run",
line 11, in set_up

proc.check_returncode()
File "/usr/lib/python3.9/subprocess.py", line 460, in check_returncode
raise CalledProcessError(self.returncode, self.args, self.stdout,
subprocess.CalledProcessError: Command '['tests/install.debian.sh']'
returned non-zero exit status 1.

autopkgtest [04:02:53]: test run

OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001614: odil: FTBFS on armhf: 91 - MoveSCU_Move (Failed)

Hi Julien,

Am Tue, Dec 14, 2021 at 07:02:40PM +0100 schrieb Julien Lamy:
> Hi list,
> I tried to solve #1001614 but I can't reproduce the error: on an armhf box,
> sbuild environment targeting sid, no error occurs. Since the build error is
> supposed to happen during network-related unit tests in which I'm starting a
> server listening on a fixed port of the loopback interface, I'm suspecting
> that something specific to the build environment interferes.
> 
> I can think of three possible ways to go:
> 1. Skip all network-related tests. The networking tests are run during CI
> upstream, but on x86 only.

This is definitely a valid way to go.

> 2. Have the server listen on a random port. The error may however pop back
> randomly.
> 3. Restrict the architectures to avoid armhf.

I personally think that this software is not used on armhf.  Well,
sometimes those rarely used architectures are some means to detect
some hidden issues.  But if you can be sure that's not the case
the solution is also valid in my eyes.
 
> Which one would you advise? Is there a fourth one, since none of those seem
> good?

May be I did not understood 2. correctly but 1. and 3. are fine for
me.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#1001726: node-mqtt-packet breaks node-mqtt-connection autopkgtest: Invalid header flag bits, must be 0x2 for pubrel


Source: node-mqtt-packet, node-mqtt-connection
Control: found -1 node-mqtt-packet/7.1.1-1
Control: found -1 node-mqtt-connection/4.1.0-3
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of node-mqtt-packet the autopkgtest of 
node-mqtt-connection fails in testing when that autopkgtest is run with 
the binary packages of node-mqtt-packet from unstable. It passes when 
run with only packages from testing. In tabular form:


   passfail
node-mqtt-packet   from testing7.1.1-1
node-mqtt-connection   from testing4.1.0-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of node-mqtt-packet 
to testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=node-mqtt-packet

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-mqtt-connection/17553966/log.gz

# Using package.json
# Node module name is mqtt-connection
# Build files found: # Test files found: test
# Files/dir to be installed from source: test # Copy test files
# Copy debian/tests/pkg-js content
'debian/tests/pkg-js' -> 
'/tmp/autopkgtest-lxc.is20x5x_/downtmp/autopkgtest_tmp/smokegz7eSX/debian/tests/pkg-js'
'debian/tests/pkg-js/test' -> 
'/tmp/autopkgtest-lxc.is20x5x_/downtmp/autopkgtest_tmp/smokegz7eSX/debian/tests/pkg-js/test'

# Searching module in /usr/lib/nodejs/mqtt-connection
# Searching module in /usr/lib/*/nodejs/mqtt-connection
# Searching module in /usr/share/nodejs/mqtt-connection
# Found /usr/share/nodejs/mqtt-connection
# Searching files to link in /usr/share/nodejs/mqtt-connection
'./connection.js' -> '/usr/share/nodejs/mqtt-connection/connection.js'
'./lib' -> '/usr/share/nodejs/mqtt-connection/lib'
'./package.json' -> '/usr/share/nodejs/mqtt-connection/package.json'
# Launch debian/tests/pkg-js/test with sh -ex
+ mocha test/


  Connection-v5
undefined should start piping in the next tick
transmission-v5
  #subscribe-5.0
undefined should send a 5.0 subscribe packet (single) (50ms)

  Connection
undefined should start piping in the next tick
parsing
  connect
undefined should fire a connect event (minimal)
undefined should fire a connect event (maximal)
parse errors
  undefined should say protocol not parseable
  connack
undefined should fire a connack event (rc = 0)
undefined should fire a connack event (rc = 5)
  publish
undefined should fire a publish event (minimal)
undefined should fire a publish event with 2KB payload
undefined should fire a publish event with 2MB payload
undefined should fire a publish event (maximal)
undefined should fire an empty publish
undefined should parse a splitted publish
  puback
undefined should fire a puback event
  pubrec
undefined should fire a pubrec event
  pubrel
1) should fire a pubrel event
  pubcomp
undefined should fire a pubcomp event
  subscribe
undefined should fire a subscribe event (1 topic)
undefined should fire a subscribe event (3 topic)
  suback
2) should fire a suback event
  unsubscribe
undefined should fire an unsubscribe event
  unsuback
undefined should fire a unsuback event
  pingreq
undefined should fire a pingreq event
  pingresp
undefined should fire a pingresp event
  disconnect
undefined should fire a disconnect event
  reserverd (15)
undefined should emit an error
  reserverd (0)
undefined should emit an error
transmission
  #connect
undefined should send a connect packet (minimal)
undefined should send a connect packet (maximal)
undefined should send a connect packet with binary 
username/password

undefined should send a connect packet with binary will payload
undefined should send a connect packet with unicode will payload
invalid options
  protocol id
undefined should reject non-string
  protocol version
undefined should reject non-number
undefined should reject >255
undefined should reject <0
  client id
undefined should reject non-present
undefined should reject empty
undefined should reject non-string
  keepalive
undefined should reject non-number
undefined should

Bug#1001725: audiotools: dvda2track binary not found anywhere.

2021-12-14 Thread Alex Relis

Package: audiotools
Version: 3.1.1-1.1+b8
Severity: normal
Tags: upstream

Dear Maintainer,

So I am trying to rip a DVD-Audio album to flac but I'm having a bit of 
trouble. Bear in mind that by DVD-Audio I don't mean rip a DVD movie's audio. I 
mean DVD Audio, the more obscure audiophile format: 
https://en.wikipedia.org/wiki/DVD-Audio
On paper, audiotools should do the job nicely since it has dvda2track which 
does exactly what I need. It's even demonstrated on the website of the program: 
http://audiotools.sourceforge.net/screenshots.html#dvda2track

However, when installing the package on Debian, the binary for dvda2track isn't 
found anywhere. I assumed that this was for legal reasons, so I decided to 
manually compile the program myself. Turns out, the upstream version of the 
program doesn't have dvda2track either.

Do you know why this is the case? And do you know of any other way to rip DVD-A 
on Debian? Python Audio Tools was last updated 5 years ago, and I am unable to 
get ahold of the upstream developer.

Thanks,
Alex :)

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

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

Versions of packages audiotools depends on:
ii  libasound2 1.2.4-1.1
ii  libc6  2.31-13+deb11u2
ii  libcdio-cdda2  10.2+2.0.0-1+b2
ii  libcdio-paranoia2  10.2+2.0.0-1+b2
ii  libcdio19  2.1.0-2
ii  libmp3lame03.100-3
ii  libmpg123-01.26.4-1
ii  libopus0   1.3.1-0.1
ii  libopusfile0   0.9+20170913-1.1
ii  libpulse0  14.2-2
ii  libtwolame00.4.0-2
ii  libvorbisenc2  1.3.7-1
ii  libvorbisfile3 1.3.7-1
ii  libwavpack15.4.0-1
ii  python33.9.2-3

Versions of packages audiotools recommends:
ii  faad   2.10.0-1
ii  python3-urwid  2.1.2-1

Versions of packages audiotools suggests:
pn  faac  

-- no debconf information

Bug#1001724: /usr/bin/firefox is difficult to wrap

2021-12-14 Thread Joey Hess

Package: firefox
Version: 94.0.2-1
Severity: normal

I have a ~/bin/firefox wrapper script ahead of the usual firefox in PATH.

#!/bin/sh
MOZ_USE_XINPUT2=1 /usr/bin/firefox "$@"

This has a very surprising behavior, because /usr/bin/firefox contains:

FIREFOX="$(command -v firefox)"
[ -x "$FIREFOX.real" ] && exec "$FIREFOX.real" "$@"

So FIREFOX gets set to ~/bin/firefox and there is no ~/bin/firefox.real
to run. So instead it falls through and runs firefox-esr which I also happen
to have installed. Since firefox-esr doesn't use my usual firefox
config, my wrapper script effectively breaks the configuration.

The workaround was to change my wrapper script to this:

#!/bin/sh
MOZ_USE_XINPUT2=1 PATH=/usr/bin:$PATH exec firefox "$@"

Although notice that this can turn into an infinite loop if firefox
is somehow not in /usr/bin anymore. Also it prevents firefox from running
any other wrapper scripts I might have in ~/bin when starting a program
such as a PDF viewer. So this is a suboptimal workaround.

I don't know if there is a reason you are not using $0 or not simply
hardcoding the path to firefox.real, either seems like a way to avoid this.

-- Package-specific info:

-- Extensions information
Name: Abstract — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Abstract — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Abstract — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Add-ons Search Detection
Location: 
/home/joey/.mozilla/firefox/darkstar.default/features/{24d1e21e-7f68-43e8-b88d-0ac0a57147bf}/addons-search-detect...@mozilla.com.xpi
Status: enabled

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

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

Name: Cheers — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Cheers — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Cheers — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

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

Name: DoH Roll-Out
Location: /usr/lib/firefox/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox
Status: enabled

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

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

Name: Elemental — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Elemental — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Elemental — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

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

Name: Firefox Multi-Account Containers
Location: ${PROFILE_EXTENSIONS}/@testpilot-containers.xpi
Status: enabled

Name: Firefox Screenshots
Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Foto — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Foto — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Foto — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

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

Name: Graffiti — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Graffiti — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Graffiti — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

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

Name: Lush — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Lush — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Lush — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Picture-In-Picture
Location: /usr/lib/firefox/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Proxy Failover
Location: /usr/lib/firefox/browser/features/proxy-failo...@mozilla.com.xpi
Package: firefox
Status: enabled

Name: Reset Search Defaults
Location:

Bug#1001723: RM: fortunes-fr -- ROM; RC buggy, offensive, unmaintained, low popcon

2021-12-14 Thread Aurelien Jarno

Package: ftp.debian.org
Severity: normal

Dear ftp-master,

fortunes-fr is a package I used to maintain many years ago, both
upstream and in Debian. I haven't touched it for years. It is offensive,
unmaintained, RC buggy and used by very few people. For that reason, it
is better to just remove it from the archive instead of finding a new
maintainer.

Regards,
Aurelien

Bug#1001722: python3.10: autopkgtest needs update for new version of setuptools: deprecation warning on stderr


Source: python3.10
Version: 3.10.1-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, setupto...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:setuptools

Dear maintainer(s),

With a recent upload of setuptools the autopkgtest of python3.10 fails 
in testing when that autopkgtest is run with the binary packages of 
setuptools from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
setuptools from testing59.4.0-1
python3.10 from testing3.10.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. The test fails 
because there is a deprecation warning on stderr and the allow-stderr 
restriction is not set on the autopkgtest.


Currently this regression is blocking the migration of setuptools to 
testing [1]. Of course, setuptools shouldn't just break your autopkgtest 
(or even worse, your package), but it seems to me that the change in 
setuptools was intended and your package needs to update to the new 
situation.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=setuptools

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python3.10/17559467/log.gz

testFibPy
running install
/usr/lib/python3/dist-packages/setuptools/command/install.py:34: 
SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build 
and pip and other standards-based tools.

  warnings.warn(
/usr/lib/python3/dist-packages/setuptools/command/easy_install.py:158: 
EasyInstallDeprecationWarning: easy_install command is deprecated. Use 
build and pip and other standards-based tools.

  warnings.warn(
running bdist_egg
running egg_info
creating fibpy.egg-info
writing fibpy.egg-info/PKG-INFO
writing dependency_links to fibpy.egg-info/dependency_links.txt
writing top-level names to fibpy.egg-info/top_level.txt
writing manifest file 'fibpy.egg-info/SOURCES.txt'
reading manifest file 'fibpy.egg-info/SOURCES.txt'
writing manifest file 'fibpy.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
running build_py
creating build
creating build/lib
copying fibpy.py -> build/lib
creating build/bdist.linux-x86_64
creating build/bdist.linux-x86_64/egg
copying build/lib/fibpy.py -> build/bdist.linux-x86_64/egg
byte-compiling build/bdist.linux-x86_64/egg/fibpy.py to 
fibpy.cpython-310.pyc

creating build/bdist.linux-x86_64/egg/EGG-INFO
copying fibpy.egg-info/PKG-INFO -> build/bdist.linux-x86_64/egg/EGG-INFO
copying fibpy.egg-info/SOURCES.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying fibpy.egg-info/dependency_links.txt -> 
build/bdist.linux-x86_64/egg/EGG-INFO
copying fibpy.egg-info/top_level.txt -> 
build/bdist.linux-x86_64/egg/EGG-INFO

copying fibpy.egg-info/zip-safe -> build/bdist.linux-x86_64/egg/EGG-INFO
creating dist
creating 'dist/fibpy-42.0.0-py3.10.egg' and adding 
'build/bdist.linux-x86_64/egg' to it

removing 'build/bdist.linux-x86_64/egg' (and everything under it)
Processing fibpy-42.0.0-py3.10.egg
Copying fibpy-42.0.0-py3.10.egg to /usr/lib/python3.10/dist-packages
Adding fibpy 42.0.0 to easy-install.pth file



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001721: pypy3: autopkgtest needs update for new version of setuptools: deprecation warning on stderr


Source: pypy3
Version: 7.3.7+dfsg-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, setupto...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:setuptools

Dear maintainer(s),

With a recent upload of setuptools the autopkgtest of pypy3 fails in 
testing when that autopkgtest is run with the binary packages of 
setuptools from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
setuptools from testing59.4.0-1
pypy3  from testing7.3.7+dfsg-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. The test fails 
because there is a deprecation warning on stderr and the allow-stderr 
restriction is not set on the autopkgtest.


Currently this regression is blocking the migration of setuptools to 
testing [1]. Of course, setuptools shouldn't just break your autopkgtest 
(or even worse, your package), but it seems to me that the change in 
setuptools was intended and your package needs to update to the new 
situation.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=setuptools

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pypy3/17554112/log.gz

Installed /usr/local/lib/pypy3.7/dist-packages/fibpy-42.0.0-py3.7.egg
Processing dependencies for fibpy==42.0.0
Finished processing dependencies for fibpy==42.0.0
/usr/lib/python3/dist-packages/setuptools/command/install.py:37: 
SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build 
and pip and other standards-based tools.

  setuptools.SetuptoolsDeprecationWarning,
/usr/lib/python3/dist-packages/setuptools/command/easy_install.py:161: 
EasyInstallDeprecationWarning: easy_install command is deprecated. Use 
build and pip and other standards-based tools.

  EasyInstallDeprecationWarning,
testFibC
running install
running bdist_egg
running egg_info
creating fibc.egg-info
writing fibc.egg-info/PKG-INFO
writing dependency_links to fibc.egg-info/dependency_links.txt
writing top-level names to fibc.egg-info/top_level.txt
writing manifest file 'fibc.egg-info/SOURCES.txt'
reading manifest file 'fibc.egg-info/SOURCES.txt'
writing manifest file 'fibc.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
running build_ext
building 'fibc' extension
creating build
creating build/temp.linux-x86_64-3.7
gcc -pthread -DNDEBUG -O2 -fPIC -I/usr/lib/pypy3/include -c fibc.c -o 
build/temp.linux-x86_64-3.7/fibc.o

creating build/lib.linux-x86_64-3.7
gcc -pthread -shared build/temp.linux-x86_64-3.7/fibc.o -o 
build/lib.linux-x86_64-3.7/fibc.pypy37-pp73-x86_64-linux-gnu.so

creating build/bdist.linux-x86_64
creating build/bdist.linux-x86_64/egg
copying build/lib.linux-x86_64-3.7/fibc.pypy37-pp73-x86_64-linux-gnu.so 
-> build/bdist.linux-x86_64/egg

creating stub loader for fibc.pypy37-pp73-x86_64-linux-gnu.so
byte-compiling build/bdist.linux-x86_64/egg/fibc.py to fibc.pypy37.pyc
creating build/bdist.linux-x86_64/egg/EGG-INFO
copying fibc.egg-info/PKG-INFO -> build/bdist.linux-x86_64/egg/EGG-INFO
copying fibc.egg-info/SOURCES.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying fibc.egg-info/dependency_links.txt -> 
build/bdist.linux-x86_64/egg/EGG-INFO

copying fibc.egg-info/not-zip-safe -> build/bdist.linux-x86_64/egg/EGG-INFO
copying fibc.egg-info/top_level.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
writing build/bdist.linux-x86_64/egg/EGG-INFO/native_libs.txt
creating dist
creating 'dist/fibc-42.0.0-py3.7-linux-x86_64.egg' and adding 
'build/bdist.linux-x86_64/egg' to it

removing 'build/bdist.linux-x86_64/egg' (and everything under it)
Processing fibc-42.0.0-py3.7-linux-x86_64.egg
creating 
/usr/local/lib/pypy3.7/dist-packages/fibc-42.0.0-py3.7-linux-x86_64.egg
Extracting fibc-42.0.0-py3.7-linux-x86_64.egg to 
/usr/local/lib/pypy3.7/dist-packages

Adding fibc 42.0.0 to easy-install.pth file



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001720: Cache directory not populated, directory omissions

2021-12-14 Thread Dominique Brazziel

Package: libapache2-mod-musicindexVersion: 1.4.1-3.1Severity: 
importantX-Debbugs-Cc: dbrazz...@snet.net
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
   * What led up to the situation?Run apache2 with mod-musicindex configured   
* What exactly did you do (or not do) that was effective (or     
ineffective)?Deleted and redefined cache directory   * What was the outcome of 
this action?Cache directory is empty after browsing and playing audio 
files.Some of the subdirectories are missing from the genre displays(i.e. the 
'Yes' subdirectory does not show up though it existsunder the 'Rock' genre.   * 
What outcome did you expect instead?Display of all music directories and 
populated cache directory.
*** End of the template - remove these template lines ***

-- System Information:Debian Release: bookworm/sid  APT prefers testing  APT 
policy: (990, 'testing'), (500, 'stable-security'), (500, 
'unstable')Architecture: amd64 (x86_64)
Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)Kernel taint flags: 
TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULELocale: 
LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE not setShell: /bin/sh linked to /usr/bin/dashInit: 
systemd (via /run/systemd/system)LSM: AppArmor: enabled
Versions of packages libapache2-mod-musicindex depends on:ii  apache2-bin 
[apache2-api-20120211]  2.4.51-2ii  libapr1                             
1.7.0-8ii  libarchive13                        3.4.3-2+b1ii  libc6              
                 2.32-5ii  libflac8                            1.3.3-2ii  
libid3tag0                          0.15.1b-14ii  libmad0                       
      0.15.1b-10ii  libmariadb3                         1:10.5.12-1ii  
libvorbis0a                         1.3.7-1ii  libvorbisfile3                   
   1.3.7-1ii  mod-musicindex-common               
1.4.1-3.1libapache2-mod-musicindex recommends no packages.
libapache2-mod-musicindex suggests no packages.
-- no debconf information

Bug#929700: [help] pymol: Deprecation warning during startup

Hi,

I think I've fixed the issue[1] and it works nicely at command line.  
Unfortunately
Salsa-CI[2] shows a new issue

   AttributeError: module 'importlib' has no attribute 'util'

which I do not understand at all since at command line there is the attribute 
'util'.

Any hint would be welcome
Andreas.


[1] 
https://salsa.debian.org/debichem-team/pymol/-/commit/66b5875cbc000870f3661c66a4578d4c58968446
[2] https://salsa.debian.org/debichem-team/pymol/-/jobs/2273661

-- 
http://fam-tille.de

Bug#1001719: jenkins-job-builder: autopkgtest needs update for new version of setuptools: deprecation warning on stderr

Source: jenkins-job-builder
Version: 3.11.0-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, setupto...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:setuptools

Dear maintainer(s),

With a recent upload of setuptools the autopkgtest of
jenkins-job-builder fails in testing when that autopkgtest is run with
the binary packages of setuptools from unstable. It passes when run with
only packages from testing. In tabular form:

passfail
setuptools from testing59.4.0-1
jenkins-job-builderfrom testing3.11.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. The test fails
because there is a deprecation warning on stderr and the allow-stderr
restriction is not set on the autopkgtest.

Currently this regression is blocking the migration of setuptools to
testing [1]. Of course, setuptools shouldn't just break your autopkgtest
(or even worse, your package), but it seems to me that the change in
setuptools was intended and your package needs to update to the new
situation.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=setuptools

https://ci.debian.net/data/autopkgtest/testing/amd64/j/jenkins-job-builder/17554110/log.gz

Testing with python3.9:
{3}
tests.cachestorage.test_cachestorage.TestCaseJobCache.test_save_on_exit
[0.004601s] ... ok
{3}
tests.jenkins_manager.test_manager.TestCaseTestJenkinsManager.test_get_plugins_info_handles_connectionrefused_errors
[0.004442s] ... ok
{6}
tests.parallel.test_parallel.TestCaseParallel.test_parallel_single_thread [0.001632s]
... ok
{6}
tests.xml_config.test_xml_config.TestXmlJobGeneratorExceptions.test_incorrect_template_params
[0.026831s] ... ok
{4}
tests.cmd.subcommands.test_update.UpdateTests.test_update_timeout_set
... SKIPPED: TODO: Develop actual update timeout test approach.
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116:
PkgResourcesDeprecationWarning: 1.0a.preview is an invalid version and
will not be supported in a future release

warnings.warn(

OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001658: singular: cannot upgrade to 1:4.2.1-p2+ds-3

2021-12-14 Thread Jerome BENOIT


Dear Patrice, thanks for your report.
I am on my way to try to fix it.
Jerome

On Mon, 13 Dec 2021 20:38:06 +0100 Patrice Duroux  
wrote:

Package: singular
Version: 1:4.1.1-p2+ds-4+b3
Severity: wishlist

Dear Maintainer,

Here is what I am getting:

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

The following packages have unmet dependencies:
 libsingular4m1 : Breaks: libsingular
E: Broken packages

I do not know also why apt transaction is aborted while there are some
other package to upgrade. Is this also a trouble in apt?

Thanks,
Patrice

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

Kernel: Linux 5.14.0-1-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 singular depends on:
ii  singular-data 1:4.1.1-p2+ds-4
pn  singular-modules  
pn  singular-ui   

singular recommends no packages.

singular suggests no packages.

-- no debconf information




--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001712: [Pkg-opencl-devel] ROCm RFP

2021-12-14 Thread Andreas Beckmann


On 14/12/2021 20.10, maxzor wrote:
For your information, I just opened this RFP : 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001712 .


If anybody is already on the job that's great,


Not that I'd know.


if not I might gather the  > energy to withstand the maintainer trial :)


I might spend some time reviewing and sponsoring ...

Would it be useful to place these packages under the umbrella of
  Maintainer: Debian OpenCL Maintainers 

There is more in ROCm than just OpenCL, but I don't know a better 
fitting team ...


Given that there are third-party Debian packages out in the wild, we 
should ensure that upgrades from third-party packages to official Debian 
packages (and maybe vice versa) work smoothly. Which means packaging 
updates probably need to be propagated back to the third-party 
packaging. (An *no* use of epochs to be newer than the third-party 
packages!)


(I had used the third-party ROCm packages on a Debian system in the 
past, and IIRC it worked surprisingly well after I figured out that we 
already had a recent enough kernel to not need the out-of-tree kernel 
module bits.)



Andreas

Bug#1001685: mailman: CVE-2021-44227 and updated fix for CVE-2021-42097

Control: tags -1 + upstream security

Hi Thomas,

On Tue, Dec 14, 2021 at 11:23:53AM +0100, Thomas Arendsen Hein wrote:
> Package: mailman
> Version: 1:2.1.29-1+deb10u2
> Severity: important
> 
> Hi!
> 
> Mailman 2.1.38 has been released to fix CVE-2021-44227 (a list
> member or moderator can get a CSRF token and craft an admin request),
> and 2.1.39 has been released to fix a regression in above fix and
> to update the fix for CVE-2021-42097.
> 
> https://mail.python.org/archives/list/mailman-annou...@python.org/thread/D54X2LXETPMVP5KZNM2WP6Z6UOPJXSVD/
> Can you update the packages for Debian buster (and ideally for
> stretch LTS, too)?

See: https://bugs.debian.org/1001556 so it's pending for the next
buster point release.

> In bug report #1000367 an updated package 1:2.1.29-1+deb10u3 has
> been created, but it is not yet available via buster-security.
> That's why I have marked this ticket with "1:2.1.29-1+deb10u2"
> above.

Samewise: https://bugs.debian.org/1000386 

So in summary, all the CVE fixes are already pending for the next
point release for buster.

Hope this helps,

Regards,
Salvatore

Bug#1001718: astroscrappy breaks ccdproc autopkgtest: detect_cosmics() got an unexpected keyword argument 'pssl'


Source: astroscrappy, ccdproc
Control: found -1 astroscrappy/1.1.0-1
Control: found -1 ccdproc/2.2.0-1
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of astroscrappy the autopkgtest of ccdproc fails in 
testing when that autopkgtest is run with the binary packages of 
astroscrappy from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
astroscrappy   from testing1.1.0-1
ccdprocfrom testing2.2.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of astroscrappy to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=astroscrappy

https://ci.debian.net/data/autopkgtest/testing/amd64/c/ccdproc/17555299/log.gz


=== FAILURES 
===
 test_cosmicray_lacosmic_does_not_change_input 
_


def test_cosmicray_lacosmic_does_not_change_input():
ccd_data = ccd_data_func()
original = ccd_data.copy()
error = np.zeros_like(ccd_data)

  ccd = cosmicray_lacosmic(ccd_data)


/usr/lib/python3/dist-packages/ccdproc/tests/test_ccdproc.py:794: _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ /usr/lib/python3/dist-packages/ccdproc/core.py:1525: in cosmicray_lacosmic

crmask, cleanarr = detect_cosmics(
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _

  ???

E   TypeError: detect_cosmics() got an unexpected keyword argument 'pssl'

astroscrappy/astroscrappy.pyx:26: TypeError
___ test_cosmicray_lacosmic 



def test_cosmicray_lacosmic():
ccd_data = ccd_data_func(data_scale=DATA_SCALE)
threshold = 5
add_cosmicrays(ccd_data, DATA_SCALE, threshold, ncrays=NCRAYS)
noise = DATA_SCALE * np.ones_like(ccd_data.data)

  data, crarr = cosmicray_lacosmic(ccd_data.data, sigclip=5)


/usr/lib/python3/dist-packages/ccdproc/tests/test_cosmicray.py:38: _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ /usr/lib/python3/dist-packages/ccdproc/core.py:1491: in cosmicray_lacosmic

crmask, cleanarr = detect_cosmics(
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _

  ???

E   TypeError: detect_cosmics() got an unexpected keyword argument 'pssl'

astroscrappy/astroscrappy.pyx:26: TypeError
___ test_cosmicray_lacosmic_ccddata 



def test_cosmicray_lacosmic_ccddata():
ccd_data = ccd_data_func(data_scale=DATA_SCALE)
threshold = 5
add_cosmicrays(ccd_data, DATA_SCALE, threshold, ncrays=NCRAYS)
noise = DATA_SCALE * np.ones_like(ccd_data.data)
ccd_data.uncertainty = noise

  nccd_data = cosmicray_lacosmic(ccd_data, sigclip=5)


/usr/lib/python3/dist-packages/ccdproc/tests/test_cosmicray.py:52: _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ /usr/lib/python3/dist-packages/ccdproc/core.py:1525: in cosmicray_lacosmic

crmask, cleanarr = detect_cosmics(
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _

  ???

E   TypeError: detect_cosmics() got an unexpected keyword argument 'pssl'

astroscrappy/astroscrappy.pyx:26: TypeError
- Captured stdout call 
-
INFO: array provided for uncertainty; assuming it is a 
StdDevUncertainty. [astropy.nddata.ccddata]
-- Captured log call 
---
INFO astropy:ccddata.py:263 array provided for uncertainty; assuming 
it is a StdDevUncertainty.
 test_cosmicray_gain_correct[True-True] 



array_input = True, gain_correct_data = True

@pytest.mark.parametrize('array_input', [True, False])
@pytest.mark.parametrize('gain_correct_data', [True, False])
def test_cosmicray_gain_correct(array_input, gain_correct_data):
# Add regression check for #705 and for the new gain_correct
# argument.
# The issue is that cosmicray_lacosmic gain-corrects the
# data and returns that gain corrected data. That is not the
# intent...
ccd_data = ccd_data_func(data_scale=DATA_SCALE)
threshold = 5
add_cosmicrays(ccd_data, DATA_SCALE, threshold,

Bug#1001717: fcitx5-chewing: Unmatched license for debian/* (GPL-2+ -> LGPL-2.1+)

Source: fcitx5-chewing
Version: 5.0.7-1
Tags: sid bookworm
Severity: normal
X-Debbugs-CC: m...@debian.org

Hi Yao Wei,

As seen in
https://salsa.debian.org/input-method-team/fcitx5-chewing/-/commit/a723daa5f225cd5b4574a8a350aa2c34fe674db0
, the new release of fcitx5-chewing 5.0.8 has switched its license from GPL-2+
to LGPL-2.1+. However, you documented that files written by you in debian/*
dir
https://salsa.debian.org/input-method-team/fcitx5-chewing/-/blob/a723daa5f225cd5b4574a8a350aa2c34fe674db0/debian/copyright#L22
is released under GPL-2+.

Could you please re-license you contribution under a LGPL-2.1+ or a more
permissive license to match this upstream switch?

Thanks,
Boyuan Yang

Bug#1001716: src:minimap2: fails to migrate to testing for too long: autopkgtest regression


Source: minimap2
Version: 2.17+dfsg-12
Severity: serious
Control: close -1 2.22+dfsg-3
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:minimap2 has been trying to migrate for 61 
days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=minimap2



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001715: flatpak needs bash-completion as dependency

2021-12-14 Thread Asif Ali Rizvan

Package: flatpak
Version: 1.10.5-0+deb11u1

flatpak does not do bash completion on pressing tab. After installing
bash-completion package with `sudo apt install bash-completion`; flatpak
works with bash completion.

As flatpak apps have long names it is necessary to have bash completion
functionality.

I'm using:
Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux

Regards,
Rizvan.

Bug#997851: The doas package should be called opendoas

2021-12-14 Thread Andrea Pappacoda

I agree that having this package renamed to "opendoas" could result in 
fewer bug reports filled against the wrong upstream repo, but I also 
think that OpenDoas currently offers a better experience for Linux 
users. The persist feature is certainly nice, but (maybe more 
importantly) slicer69/doas had some serious security flaws that have 
been treated superficially by slicer69 [1], and Linux support is not 
its main focus.


In my opinion, users installing the "doas" package should get the 
"better" version by default, and by moving this package to "opendoas" 
and packaging slicer69/doas under "doas" this wouldn't be possible. A 
possible solution would be making "doas" a virtual package and 
packaging the two variants under "opendoas" and "slicer69-doas", both 
providing the virtual package. Just renaming this package to "opendoas" 
(without doing anything else) wouldn't be satisfactory because we 
wouldn't have any package providing doas.


I propose "slicer69-doas" since names like "universal doas" are not 
really descriptive and wouldn't help with identifying the actual 
version of doas that you're installing. But it isn't perfect, so maybe 
you have a better name :)


1. https://xn--1xa.duncano.de/slicer69-doas.html

Bug#834724: curl: (35) gnutls_handshake() failed: Public key signature verification has failed.

2021-12-14 Thread Mehdi khanpor

On Wed, 28 Sep 2016 12:57:49 +0100 Tim Small  wrote:
> Package: curl
> Followup-For: Bug #834724
>
> I fixed this on a sid install by removing libgnutls-deb0-28 which was
> being kept around by an old librtmp1 package version, left over from
> Jessie debian-multimedia.  Possibly libcurl should conflict with this
> package?
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.7.0-1-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages curl depends on:
> ii  libc62.24-3
> ii  libcurl3-gnutls  7.50.1-1
> ii  zlib1g   1:1.2.8.dfsg-2+b1
>
> curl recommends no packages.
>
> curl suggests no packages.
>
> -- debconf-show failed
>
>


Mehdi khanpor

Bug#1001708: segfault when attempting SEPA transfer (works in debian 11, but broken in unstable)

2021-12-14 Thread Harald Welte

misc correction: It's probably only about 10 years that I'm using
aqbanking in this setup.  In any case, it has been extremely stable for
me during that time.

As for the actual bug: I built aqbanking 6.3.2 (from upstream git) on
Debian unstable and the same problem can be observed there.  I verified
that the libaqbanking.so from the custom build is used in the process,
so it's clearly not using the Debian-packaged library.

Same also is the case with upstream 6.1.0.  Building 5.8.2 unfortuantely
fails as it expects gwenhywfar-config to be present, while the new
version switched to pkg-config.  Even after patching the autoconf, it's
appears to be impossibel to build an old aqbanking5 against modern
gwenhywfar, so I'm a bit lost.

Is there an easy way to install previous aqbanking packages in unstable
before upgrading to 6.4.x?

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1001713: lxc-copy --ephemeral fail: Failed to create monitor cgroup 12

2021-12-14 Thread Shengjing Zhu

Package: lxc
Version: 1:4.0.10-1
Severity: normal
X-Debbugs-Cc: z...@debian.org

Dear Maintainer,

$ sudo lxc-copy -F -l debug --name autopkgtest-sid --ephemeral --newname a
Created a as clone of autopkgtest-sid
lxc-copy: autopkgtest-sid: cgroups/cgfsng.c: __cgroup_tree_create: 771 File 
exists - Creating the final cgroup 12(lxc.monitor.a) failed
lxc-copy: autopkgtest-sid: cgroups/cgfsng.c: cgroup_tree_create: 831 File 
exists - Failed to create monitor cgroup 12(lxc.monitor.a)
lxc-copy: autopkgtest-sid: cgroups/cgfsng.c: __cgroup_tree_create: 771 File 
exists - Creating the final cgroup 12(lxc.monitor.a-1) failed
lxc-copy: autopkgtest-sid: cgroups/cgfsng.c: cgroup_tree_create: 831 File 
exists - Failed to create monitor cgroup 12(lxc.monitor.a-1)
lxc-copy: autopkgtest-sid: cgroups/cgfsng.c: __cgroup_tree_create: 771 File 
exists - Creating the final cgroup 12(lxc.monitor.a-2) failed
lxc-copy: autopkgtest-sid: cgroups/cgfsng.c: cgroup_tree_create: 831 File 
exists - Failed to create monitor cgroup 12(lxc.monitor.a-2)
lxc-copy: autopkgtest-sid: cgroups/cgfsng.c: __cgroup_tree_create: 771 File 
exists - Creating the final cgroup 12(lxc.monitor.a-3) failed
lxc-copy: autopkgtest-sid: cgroups/cgfsng.c: cgroup_tree_create: 831 File 
exists - Failed to create monitor cgroup 12(lxc.monitor.a-3)
lxc-copy: autopkgtest-sid: conf.c: lxc_rootfs_init: 570 Bad file descriptor - 
Failed to open 
"overlay:/var/lib/lxc/autopkgtest-sid/rootfs:/var/lib/lxc/a/overlay/delta"
lxc-copy: autopkgtest-sid: start.c: __lxc_start: 2025 Failed to handle rootfs 
pinning for container "a"

As the log shows, lxc-copy fails when using --ephemeral option.

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

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

Versions of packages lxc depends on:
ii  bridge-utils 1.7-1
ii  debconf [debconf-2.0]1.5.79
ii  dnsmasq-base [dnsmasq-base]  2.86-1.1
ii  iproute2 5.15.0-1
ii  iptables 1.8.7-1
ii  libc62.32-5
ii  libcap2  1:2.44-1
ii  libgcc-s111.2.0-12
ii  liblxc1  1:4.0.10-1
ii  libseccomp2  2.5.3-2
ii  libselinux1  3.3-1+b1
ii  lsb-base 11.1.0

Versions of packages lxc recommends:
ii  apparmor   3.0.3-6
ii  debootstrap1.0.126+nmu1
ii  dirmngr2.2.27-2
ii  gnupg  2.2.27-2
pn  libpam-cgfs
ii  lxc-templates  3.0.4-5
pn  lxcfs  
ii  openssl1.1.1l-1
ii  rsync  3.2.3-8
ii  uidmap 1:4.8.1-2
ii  wget   1.21.2-2+b1

Versions of packages lxc suggests:
pn  btrfs-progs  
pn  lvm2 
pn  python3-lxc  

-- debconf information:
  lxc/auto_update_config:

Bug#1001712: RFP: rocm-all -- AMD Radeon Open Compute (ROCm) - A collection of utilities for GPGPU (compute) on AMD GPUs.

2021-12-14 Thread Maxime Chambonnet

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: max...@maxzor.eu

* Package name: rocm-all
  Version : 4.5.2
  Upstream Author : amd.com
* URL : https://rocmdocs.amd.com/
* License : UIUC
  Programming Lang: C, C++, DLSs
  Description : AMD Radeon Open Compute (ROCm) - A collection of utilities
for GPGPU (hybrid computing).

AMD ROCm is the current tentative at a unified platform for hybrid CPU/GPU
computing. It supersedes the PAL compute stack. It is as essential as any
package in a distribution if not more, given how the other GPU manufacturer
behaves with regards to FLOSS.

This RFP is a porte-manteau request for a package for each free module of the
stack. (See ROCm doc, Arch github repo below, for detail.)

Currently AMD packages ROCm themselves here : https://repo.radeon.com/rocm .
They are mostly left unchecked, Arch packagers do the job :
https://github.com/rocm-arch/rocm-arch . The privileged way of installing ROCm
for Debian-based-distro users today is to use the AMD installer, often
referred-to as AMDGPU-PRO. This latter is a bundle which includes proprietary
bits.

In a few months, Blender will release 3.1 with support for rendering in Cycles
on Linux, and will be dependent on HIP, one of ROCm sub-packages.

BR, Maxime Chambonnet

Bug#1001709: amule-daemon: amuled crashes with segmentation fault on startup

2021-12-14 Thread Sven Geuer

Further observations:

Setting ConnectToKad=0 in ~/.aMule/amule.conf lets amuled start up as
expected, but of course without connecting to the Kademlia network.

Activating Kademlia later on via amulegui > Preferences > Connection >
Networks and bootstraping from known clients makes amuled crash again.

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#1001316: gnome-gmail: 2.8 to stable-updates

2021-12-14 Thread David Steele

On Tue, Dec 14, 2021 at 7:03 AM Martin-Éric Racine
 wrote:
>
> ma 13. jouluk. 2021 klo 19.18 David Steele (ste...@debian.org) kirjoitti:
> >
> > Control: severity -1 normal
> > Control: tags -1 moreinfo unreproducible
> > thanks
> >
> > On Wed, Dec 8, 2021 at 4:48 AM Martin-Éric Racine
> >  wrote:
> > >
...
> >
> > I spun up a new and created a new draft with gnome-gmail with no API
> > errors. Can you provide more information on how you came across this
> > issue?
> >
> > Note that the API requires a fully-qualified email address
> > ("gnome-gmail j...@example.com" vs. "gnome-gmail joe").
>
> I click on a mailto link. I get the dialog box asking which e-mail
> should be used. Web browser opens asking for authorization to access
> the account using Viagee. I agree. I select the account to use. I get
> an error 403 notification in gnome-shell.
>
> Martin-Éric

I am unable to reproduce the issue.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#999282: spell: diff for NMU version 1.0-24.1

Control: tags 999282 + patch
Control: tags 999282 + pending


Dear maintainer,

I've prepared an NMU for spell (versioned as 1.0-24.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  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: Michèle Sammarcelli: n/a
diff -u spell-1.0/debian/rules spell-1.0/debian/rules
--- spell-1.0/debian/rules
+++ spell-1.0/debian/rules
@@ -25,7 +25,8 @@
 
 	CFLAGS="$(CFLAGS)" ./configure $(CROSS) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
 
-build: build-stamp
+build: build-arch
+build-arch: build-stamp
 build-stamp: config.status
 	dh_testdir
 
@@ -33,6 +34,8 @@
 
 	touch build-stamp
 
+build-indep:
+
 install: build
 	dh_testdir
 	dh_testroot
@@ -63,4 +66,4 @@
 
 binary-indep:
 
-.PHONY: clean build install binary binary-arch binary-indep
+.PHONY: clean build build-arch build-indep install binary binary-arch binary-indep
diff -u spell-1.0/debian/changelog spell-1.0/debian/changelog
--- spell-1.0/debian/changelog
+++ spell-1.0/debian/changelog
@@ -1,3 +1,12 @@
+spell (1.0-24.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "missing required debian/rules targets build-arch and/or build-
+indep": add targets to debian/rules.
+(Closes: #999282)
+
+ -- gregor herrmann   Tue, 14 Dec 2021 19:11:57 +0100
+
 spell (1.0-24) unstable; urgency=low
 
   * Support also aspell (Closes: #381511)


signature.asc
Description: Digital Signature

Bug#1001711: libtoxcore2: Stack-based buffer overflow vulnerability in UDP packet handling in Toxcore (CVE-2021-44847)

2021-12-14 Thread Vincas Dargis

Package: libtoxcore2
Version: 0.2.12-1+b1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

Dear Maintainer,

libtoxcore has CVE-2021-44847:

https://blog.tox.chat/2021/12/stack-based-buffer-overflow-vulnerability-in-udp-packet-handling-in-toxcore-cve-2021-44847/

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44847

Workaround is to disable UDP support in settings.

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

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

Versions of packages libtoxcore2 depends on:
ii  libc62.33-1
ii  libopus0 1.3.1-0.1
ii  libsodium23  1.0.18-1
ii  libvpx7  1.11.0-2

libtoxcore2 recommends no packages.

libtoxcore2 suggests no packages.

-- no debconf information

Bug#1001710: multipath-tools: booting with lvm over multipath it does not setup devices for lvm

2021-12-14 Thread Carlos Barros

Package: multipath-tools
Version: 0.8.5-2
Severity: important
X-Debbugs-Cc: carlos.bar...@econocom.com

Dear Maintainer,

A server was setup with some disks configured in multipath.
The root filesystem is on LVM on internal disk, not configured for multipath.

Then build another lvm configuration on those devices (/dev/mapper/...)

Now, every time it starts, lvm takes the /dev/sd.. before multipath sets 
/dev/mapper/...  up.
Also, the booting proccess delays for 2+  minutes, mostly because of 
systemd-udev-settle.service:
root@panblando:~# systemd-analyze blame
 2min 22ms systemd-udev-settle.service
1min 105ms NetworkManager-wait-online.service
9.983s smartmontools.service
4.415s dev-mapper-dl380g8\x2d\x2dvg\x2droot.device

But this service is called from multipath:
[Unit]
Description=Device-Mapper Multipath Device Controller
Wants=systemd-udev-trigger.service systemd-udev-settle.service
Before=iscsi.service iscsid.service lvm2-activation-early.service
Before=local-fs-pre.target blk-availability.service
After=multipathd.socket systemd-udev-trigger.service 
systemd-udev-settle.service
DefaultDependencies=no
Conflicts=shutdown.target
ConditionKernelCommandLine=!nompath
ConditionKernelCommandLine=!multipath=off

According to systemd-udev-settle.service(8) it is not recommended, as that 
service can fail (in fact, 
in the server it fails as systemd says) 

I think that the problem is related to multipath, because it did not setup the 
devices before lvm, 
and maybe the problem is inside the initrd.

Then I did install multipath-tools-boot but the problem is the same.
The only way is to avoid mounting the filesystems in the LVM (or umounting 
them) vgchange -an VG 
and do the multipath and mount it, all by hand

The disk list in multipath is short (8 disks with only 1 path each by now)

Best regards,
Carlos Barros.

-- Package-specific info:
Contents of /etc/multipath.conf:
defaults {
polling_interval 10
user_friendly_names yes
}
blacklist {
device {
vendor "HP"
product "LOGICAL VOLUME"#HPSA raid internal
}
}



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

Kernel: Linux 5.10.0-9-amd64 (SMP w/32 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 multipath-tools depends on:
ii  kpartx  0.8.5-2
ii  libaio1 0.3.112-9
ii  libc6   2.31-13+deb11u2
ii  libdevmapper1.02.1  2:1.02.175-2.1
ii  libjson-c5  0.15-2
ii  libreadline88.1-1
ii  libsystemd0 247.3-6
ii  libudev1247.3-6
ii  liburcu60.12.2-1
ii  lsb-base11.1.0
ii  sg3-utils-udev  1.45-1
ii  udev247.3-6

multipath-tools recommends no packages.

Versions of packages multipath-tools suggests:
ii  multipath-tools-boot  0.8.5-2

-- no debconf information

Bug#1001709: amule-daemon: amuled crashes with segmentation fault on startup

2021-12-14 Thread Sven Geuer

Package: amule-daemon
Version: 1:2.3.3-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: debma...@g-e-u-e-r.de

Dear Maintainer,

amuled crashes on startup since my recent system upgrade.

Here's what gdb reveals.

(gdb) run   
Starting program: /usr/bin/amuled 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after vfork from child process 3950]
 2021-12-14 18:42:31: Initialising aMuleD 2.3.3 compiled with wxBase(GTK2) 
v3.0.5 and Boost 1.74
 2021-12-14 18:42:31: Checking if there is an instance already running...
 2021-12-14 18:42:31: No other instances are running.
[Detaching after vfork from child process 3952]
[Detaching after vfork from child process 3954]
[Detaching after vfork from child process 3956]
[Detaching after vfork from child process 3958]
[Detaching after vfork from child process 3960]
[Detaching after vfork from child process 3965]
[Detaching after vfork from child process 3970]
[Detaching after vfork from child process 3975]
 2021-12-14 18:42:33: ListenSocket: Ok.
[New Thread 0x7721e640 (LWP 3980)]
[New Thread 0x76a1d640 (LWP 3981)]
[New Thread 0x7621c640 (LWP 3982)]
[New Thread 0x75a1b640 (LWP 3983)]
[New Thread 0x7521a640 (LWP 3984)]
[New Thread 0x74a19640 (LWP 3985)]
 2021-12-14 18:42:33: Loading temp files from /home/sg/.aMule/Temp.
 2021-12-14 18:42:33: All PartFiles Loaded.
 2021-12-14 18:42:33: amuled: OnInit - starting timer
[New Thread 0x7fffd640 (LWP 3986)]
 2021-12-14 18:42:33: Asio thread 1 started
 2021-12-14 18:42:33: Asio thread 2 started
 2021-12-14 18:42:33: Asio thread 3 started
 2021-12-14 18:42:33: Asio thread 4 started
[Thread 0x74a19640 (LWP 3985) exited]
[Detaching after fork from child process 3987]

Thread 1 "amuled" received signal SIGSEGV, Segmentation fault.
0x55679781 in Kademlia::CKademlia::ProcessPacket (
data=0x7fff8d10 
"\344!\004\016\376TN\346\377\003\355j\261\245\006e:\003\331\"\241\311NU\001x\207\031\323\061\037\374\367@\217",
 
lenData=lenData@entry=35, ip=ip@entry=1564980350, port=port@entry=51663, 
validReceiverKey=true, senderKey=...)
at ../../src/kademlia/kademlia/Kademlia.cpp:303
303 ../../src/kademlia/kademlia/Kademlia.cpp: No such file or directory.


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

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

Versions of packages amule-daemon depends on:
ii  amule-common  1:2.3.3-2
ii  libc6 2.32-5
ii  libcrypto++8  8.6.0-2
ii  libgcc-s1 11.2.0-12
ii  libixml10 1:1.8.4-2
ii  libpng16-16   1.6.37-3
ii  libreadline8  8.1-2
ii  libstdc++611.2.0-12
ii  libupnp13 1:1.8.4-2
ii  libwxbase3.0-0v5  3.0.5.1+dfsg-2+b1
ii  lsb-base  11.1.0
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages amule-daemon recommends:
ii  amule-utils  1:2.3.3-2
ii  unzip6.0-26

amule-daemon suggests no packages.

-- Configuration Files:
/etc/default/amule-daemon changed [not included]

-- no debconf information

Bug#998961: libdigest-whirlpool-perl: diff for NMU version 1.09-1.2

Control: tags 998961 + patch
Control: tags 998961 + pending


Dear maintainer,

I've prepared an NMU for libdigest-whirlpool-perl (versioned as 1.09-1.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  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: Michèle Sammarcelli: n/a
diff -u libdigest-whirlpool-perl-1.09/debian/changelog libdigest-whirlpool-perl-1.09/debian/changelog
--- libdigest-whirlpool-perl-1.09/debian/changelog
+++ libdigest-whirlpool-perl-1.09/debian/changelog
@@ -1,3 +1,12 @@
+libdigest-whirlpool-perl (1.09-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "missing required debian/rules targets build-arch and/or build-
+indep": add targets to debian/rules.
+(Closes: #998961)
+
+ -- gregor herrmann   Tue, 14 Dec 2021 18:59:32 +0100
+
 libdigest-whirlpool-perl (1.09-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u libdigest-whirlpool-perl-1.09/debian/rules libdigest-whirlpool-perl-1.09/debian/rules
--- libdigest-whirlpool-perl-1.09/debian/rules
+++ libdigest-whirlpool-perl-1.09/debian/rules
@@ -24,7 +24,9 @@
 CFLAGS += -O2
 endif
 
-build: build-stamp
+build: build-arch build-indep
+build-arch: build-stamp
+build-indep: build-stamp
 build-stamp:
 	dh_testdir
 	# Add commands to compile the package here
@@ -73,4 +75,4 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build-indep build-arch build clean binary-indep binary-arch binary install


signature.asc
Description: Digital Signature

Bug#1001684: [Davmail-users] Davmail and the CVE-2021-44228-Log4j?

2021-12-14 Thread Geert Stappers

On Tue, Dec 14, 2021 at 06:23:29PM +0100, Mickaël Guessant wrote:
To: davmail-us...@lists.sourceforge.net
> Le 14/12/2021 à 08:52, Ole Holm Nielsen via Davmail-users a écrit :
> > Hi,
> > 
> > We have installed davmail 6.0.1 dated Dec. 3, 2021 as an RPM on CentOS
> > 7.9.  However, it's only a few days ago that the Vulnerability in Apache
> > Log4j (CVE-2021-44228-Log4j) was announced.  We note that Davmail
> > includes a log4j component:
> > 
> > $ rpm -ql davmail | grep log4j
> > /usr/share/davmail/lib/log4j-1.2.16.jar
> > /usr/share/davmail/lib/slf4j-log4j12-1.7.25.jar
> > 
> > Question: Is davmail vulnerable to log4j?  If so, when could we expect a
> > security fix?
> > 
> > Thanks,
> > Ole
> > 
> The good news is that DavMail is *not* vulnerable to latest Log4J 2 CVE as
> it depends on log4J version 1.

FWIW: That matches https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001684#38
 
> Regards,
> Mickaël Guessant


@Alexandre: FYI, your message didn't yet reach Davmail mailinglist subscribers.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1001081: additional information

2021-12-14 Thread David Loyall

Hello.

Here are the checksums for the `quicklisp.lisp` file which I see
causes the error.

MD5 (quicklisp.lisp) = a5b2e9dc96af62cb61fb791cabcce1cb
SHA256 (quicklisp.lisp) =
4a7a5c2aebe0716417047854267397e24a44d0cce096127411e9ce9ccfeb2c17

This appears to be the same as the live file on xach's website..
https://beta.quicklisp.org/quicklisp.lisp

I've also attached the file, per flip214's suggestion.

Cheers,
--sebboh


quicklisp.lisp
Description: Binary data

Bug#1001708: setgfault when attempting SEPA transfer (works in debian 11, but broken in unstable)

2021-12-14 Thread Harald Welte

Package: libaqbanking44
Version: 6.4.0-1
Severity: normal

I'm using aqbanking / aqhbci with HBIC chip card for 20 years now, and it has 
always worked
rather fine in Debian, as far as I can remember.

However, recently, it stopped to work on Debian unstable, while the same 
configuration,
account, data files and HBCI chip card continue to work smoothly on Debian 11 
stable.

So this is a clear regression compared to Debian 11.

The error happens before there is any communication with either the bank or the 
HBCI chip card, merely
while reading the CSV input file with SEPA transfers and building up some 
internal data structures prior
to talking to the bank.   /proc/fd  for the proces shows only 
stdin/stdout/stderr.

$ gdb --args aqbanking-cli sepatransfers -a 663951200 -f 
/tmp/aqbanking_transfers_20211210.csv --profile=sepatransfer
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from aqbanking-cli...
Reading symbols from 
/usr/lib/debug/.build-id/65/920ab0c9608f4b8430b25f041ba00d1734afb9.debug...
(gdb) run
Starting program: /usr/bin/aqbanking-cli sepatransfers -a 663951200 -f 
/tmp/aqbanking_transfers_20211210.csv --profile=sepatransfer
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__gmpn_copyi () at tmp-copyi.s:81
81  tmp-copyi.s: No such file or directory.
(gdb) bt
#0  __gmpn_copyi () at tmp-copyi.s:81
#1  0x77db93f4 in AB_Value_dup (ov=0x55605380) at 
./src/libs/aqbanking/types/value.c:69
#2  0x77da8b24 in AB_Transaction_dup (p_src=p_src@entry=0x556053f0)
at ./src/libs/aqbanking/types/transaction.c:771
#3  0x77e2fc33 in AH_Job_TransferBase_HandleCommand_SepaUndated 
(j=0x555c72e0, t=0x556053f0)
at ./src/libs/plugins/backends/aqhbci/ajobs/jobtransferbase.c:524
#4  0x77e931c3 in _addCommandToOutbox (outbox=0x555c4810, 
t=0x556053f0, a=0x55b61780, u=0x555abf10,
pro=0x555f1ec0) at 
./src/libs/plugins/backends/aqhbci/banking/provider_sendcmd.c:178
#5  _addCommandsToOutbox (ctx=0x555edba0, outbox=0x555c4810, 
uql=0x55610920, pro=0x555f1ec0)
at ./src/libs/plugins/backends/aqhbci/banking/provider_sendcmd.c:245
#6  AH_Provider_SendCommands (pro=0x555f1ec0, pq=, 
ctx=0x555edba0)
at ./src/libs/plugins/backends/aqhbci/banking/provider_sendcmd.c:63
#7  0x77d7a612 in _sendProviderQueues (pid=3, ctx=0x55604990, 
pql=0x555b2370, ab=0x555abcb0)
at ./src/libs/aqbanking/banking_online.c:729
#8  _sendCommandsInsideProgress (pid=3, ctx=0x55604990, 
commandList=, ab=0x555abcb0)
at ./src/libs/aqbanking/banking_online.c:578
#9  AB_Banking_SendCommands (ab=0x555abcb0, commandList=, 
ctx=0x55604990)
at ./src/libs/aqbanking/banking_online.c:535
#10 0x55567e91 in execBankingJobs (ab=0x555abcb0, 
tList=0x55598940, ctxFile=0x0)
at ./src/tools/aqbanking-cli/util.c:872
#11 0x5556a048 in sepaMultiJobs (ab=ab@entry=0x555abcb0, 
dbArgs=dbArgs@entry=0x555ab590, argc=argc@entry=6,
argv=argv@entry=0x7fffe5f0, multisepa_type=) at 
./src/tools/aqbanking-cli/sepamultijobs.c:140
#12 0x55560ad6 in main (argc=6, argv=0x7fffe5f0) at 
./src/tools/aqbanking-cli/main.c:395
(gdb) frame 1
#1  0x77db93f4 in AB_Value_dup (ov=0x55605380) at 
./src/libs/aqbanking/types/value.c:69
69mpq_set(v->value, ov->value);
(gdb) p *v
$1 = {_list1_element = 0x55610e10, value = {{_mp_num = {_mp_alloc = 21845, 
_mp_size = 21845, _mp_d = 0x55835ed0},
  _mp_den = {_mp_alloc = 21845, _mp_size = 21845, _mp_d = 
0x55612e40}}}, currency = 0x0}
(gdb) p *ov
$2 = {_list1_element = 0x555f0ef0, value = {{_mp_num = {_mp_alloc = 
1432425056, _mp_size = 21845,
_mp_d = 0x555f0ff0}, _mp_den = {_mp_alloc = 1432430912, _mp_size = 
21845, _mp_d = 0x3}}}, currency = 0x0}
(gdb) frame 2
#2  0x77da8b24 in AB_Transaction_dup (p_src=p_src@entry=0x556053f0)
at ./src/libs/aqbanking/types/transaction.c:771
771 p_struct->taxes=AB_Value_dup(p_src->taxes);
(gdb) p p_src->taxes
$3 = (AB_VALUE *) 0x55605380
(gdb) p *p_src->taxes
$4 = {_list1_element = 0x555f0ef0, value = {{_mp_num

Bug#999078: libemail-foldertype-perl: diff for NMU version 0.813-1.4

Control: tags 999078 + patch
Control: tags 999078 + pending


Dear maintainer,

I've prepared an NMU for libemail-foldertype-perl (versioned as 0.813-1.4) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  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: Michèle Sammarcelli: n/a
diff -u libemail-foldertype-perl-0.813/debian/changelog libemail-foldertype-perl-0.813/debian/changelog
--- libemail-foldertype-perl-0.813/debian/changelog
+++ libemail-foldertype-perl-0.813/debian/changelog
@@ -1,3 +1,14 @@
+libemail-foldertype-perl (0.813-1.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "missing required debian/rules targets build-arch and/or build-
+indep": use dh(1) in debian/rules.
+(Closes: #999078)
+  * Additionally add libmodule-pluggable-perl to Build-Depends-Indep,
+as the tests are not skipped anymore.
+
+ -- gregor herrmann   Tue, 14 Dec 2021 18:49:33 +0100
+
 libemail-foldertype-perl (0.813-1.3) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u libemail-foldertype-perl-0.813/debian/control libemail-foldertype-perl-0.813/debian/control
--- libemail-foldertype-perl-0.813/debian/control
+++ libemail-foldertype-perl-0.813/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Michael Ablassmeier  
 Build-Depends: debhelper (>= 9)
-Build-Depends-Indep: perl (>= 5.6.0-16)
+Build-Depends-Indep: perl (>= 5.6.0-16), libmodule-pluggable-perl
 Standards-Version: 3.7.2 
 
 Package: libemail-foldertype-perl
diff -u libemail-foldertype-perl-0.813/debian/rules libemail-foldertype-perl-0.813/debian/rules
--- libemail-foldertype-perl-0.813/debian/rules
+++ libemail-foldertype-perl-0.813/debian/rules
@@ -5,54 +5,5 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-ifndef PERL
-	PERL = /usr/bin/perl
-endif
-
-package = libemail-foldertype-perl
-
-build: build-stamp
-build-stamp:
-	dh_testdir
-
-	perl Makefile.PL INSTALLDIRS=vendor
-	$(MAKE) OPTIMIZE="-O2 -g -Wall"
-
-	touch build-stamp
-
-clean:
-	dh_testdir
-	dh_testroot
-	rm -f build-stamp configure-stamp
-
-	-$(MAKE) realclean
-
-	dh_clean
-
-install: build
-	dh_testdir
-	dh_testroot
-	dh_clean -k
-	dh_installdirs
-
-	$(MAKE) install DESTDIR=$(CURDIR)/debian/$(package)
-	-rmdir --ignore-fail-on-non-empty -p $(CURDIR)/debian/$(package)/usr/lib/perl5
-
-
-binary-arch: build install
-
-binary-indep: build install
-	dh_testdir
-	dh_testroot
-	dh_installdocs
-	dh_installchangelogs Changes
-	dh_compress
-	dh_fixperms
-	dh_installdeb
-	dh_perl
-	dh_gencontrol
-	dh_md5sums
-	dh_builddeb
-
-binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+%:
+	dh $@


signature.asc
Description: Digital Signature

Bug#978911: transmission: diff for NMU version 3.00-1.1

2021-12-14 Thread Sandro Tosi

> It's been another 2 weeks and this RC bug is still open. In total this RC bug
> has lasted for almost a year. This doesn't look well.

false. the bug has been open since a year, it has become RC since Aug 2021 only.

> I know that the proposed patch is not elegant at all (really hacky in terms of
> macro processing), and I understand that upstream will be moving away from
> autotools in future releases thus applying this patch might not be the ideal
> choice. However, having this package FTBFS in the archive forever is
> definitely not a good choice either. For example, such FTBFS might block any
> future transition in the near future (e.g., openssl-3.0 as in
> https://release.debian.org/transitions/html/auto-openssl.html ). I don't see
> any benefit with procrastination on it.

so, what's exactly broken that you're pestering so much to get it
addressed this urgently?

transmission works fine, it's not at risk of being removed from
testing, i'll deal with it in due corse.

thanks for your concern, but take it easy

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

Bug#1001640: thunderbird does not use language pack installed from debian repo

2021-12-14 Thread Carsten Schoenert


Hello Chris,

Am 13.12.21 um 17:05 schrieb Chris Nospam:

Package: thunderbird
Version: 91.4.0-1
Severity: normal

Today the new thunderbird version migrated to testing und I did a
upgrade. However, the translation package (at least for german) does
not work although installed. Thunderbird uses englisch language after
starting it (menus items and so on).

chris@sauron:~$ dpkg -l | grep thunderbird
ii  thunderbird   1:91.4.0-1  amd64mail/news client with RSS, 
chat and integrated spam filter support
ii  thunderbird-l10n-de   1:91.4.0-1  all  German language package for 
Thunderbird

Removing ~/.thunderbird for starting completely clean does not help.
The integrated Add-ons Manager shows the Deutsch (De) Language Pack
as enabled without any problems.

upstream seems to have broken again the detection of the system locale.

This issue was reported in the past for two times already, please check 
for existing bug reports before starting a new one (even you have closed 
them).


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997841
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997863

The issue is also reported upstream but so far there isn't much activity 
on this. Other Linux distribution are affected too.


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

--
Regards
Carsten

Bug#993335: libxml-rss-feed-perl: diff for NMU version 2.212-1.3

Control: tags 993335 + patch
Control: tags 993335 + pending
Control: tags 999215 + patch
Control: tags 999215 + pending


Dear maintainer,

I've prepared an NMU for libxml-rss-feed-perl (versioned as 2.212-1.3) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  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: Michèle Sammarcelli: n/a
diff -u libxml-rss-feed-perl-2.212/debian/changelog libxml-rss-feed-perl-2.212/debian/changelog
--- libxml-rss-feed-perl-2.212/debian/changelog
+++ libxml-rss-feed-perl-2.212/debian/changelog
@@ -1,3 +1,15 @@
+libxml-rss-feed-perl (2.212-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "missing required debian/rules targets build-arch and/or build-
+indep": add missing targets to debian/rules.
+(Closes: #999215)
+  * Fix "FTBFS with Perl 5.34: t/010_deprecated_methods.t failure":
+take fixed test from upstream 2.4 release.
+(Closes: #993335)
+
+ -- gregor herrmann   Tue, 14 Dec 2021 18:41:00 +0100
+
 libxml-rss-feed-perl (2.212-1.2) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u libxml-rss-feed-perl-2.212/debian/rules libxml-rss-feed-perl-2.212/debian/rules
--- libxml-rss-feed-perl-2.212/debian/rules
+++ libxml-rss-feed-perl-2.212/debian/rules
@@ -11,6 +11,8 @@
 PACKAGE=`pwd | sed -e "s/.*\/\\(.*\\)-.*/\\1/"`
 
 
+build-arch: build
+build-indep: build
 build:
 	dh_testdir
 	# Add here commands to compile the package.
@@ -54,4 +56,4 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+.PHONY: build-indep build-arch build clean binary-indep binary-arch binary install configure
only in patch2:
unchanged:
--- libxml-rss-feed-perl-2.212.orig/t/010_deprecated_methods.t
+++ libxml-rss-feed-perl-2.212/t/010_deprecated_methods.t
@@ -1,6 +1,7 @@
 #!/usr/bin/perl
-
-use Test::More tests => 8;
+use strict;
+use warnings;
+use Test::More tests => 4;
 
 BEGIN { use_ok('XML::RSS::Feed') }
 
@@ -10,14 +11,9 @@
 );
 isa_ok( $feed, 'XML::RSS::Feed' );
 
-$SIG{__WARN__} = build_warn("deprecated");
-cmp_ok( $feed->failed_to_fetch, 'eq', "",
-"Verify that failed_to_fetch returns ''" );
-cmp_ok( $feed->failed_to_parse, 'eq', "",
-"Verify that failed_to_parse returns ''" );
-
-sub build_warn {
-my @args = @_;
-return sub { my ($warn) = @_; like( $warn, qr/$_/i, $_ ) for @args };
+{
+local $SIG{'__WARN__'} = sub {};
+cmp_ok( $feed->failed_to_fetch, 'eq', "", "Verify that failed_to_fetch returns ''" );
+cmp_ok( $feed->failed_to_parse, 'eq', "", "Verify that failed_to_parse returns ''" );
 }
 


signature.asc
Description: Digital Signature

Bug#978911: transmission: diff for NMU version 3.00-1.1

X-Debbugs-CC: mo...@debian.org cost...@debian.org

Hi,

On Wed, 01 Dec 2021 00:12:42 -0500 Boyuan Yang  wrote:
> Control: tags -1 -pending
> 
> Hi,
> 
> 在 2021-11-30星期二的 18:09 -0500，Sandro Tosi写道：
> > > I've prepared an NMU for transmission (versioned as 3.00-1.1) and
> > > uploaded it to DELAYED/5. Please feel free to tell me if I
> > > should delay it longer.
> > 
> > please remove it from the delayed queue, there's no need for a nmu here
> 
> I have cancelled the upload and removed it from the delayed queue. Since
this
> will leave this RC bug open, may I ask how will it be fixed then?

It's been another 2 weeks and this RC bug is still open. In total this RC bug
has lasted for almost a year. This doesn't look well.

I know that the proposed patch is not elegant at all (really hacky in terms of
macro processing), and I understand that upstream will be moving away from
autotools in future releases thus applying this patch might not be the ideal
choice. However, having this package FTBFS in the archive forever is
definitely not a good choice either. For example, such FTBFS might block any
future transition in the near future (e.g., openssl-3.0 as in
https://release.debian.org/transitions/html/auto-openssl.html ). I don't see
any benefit with procrastination on it.

Thanks,
Boyuan Yang

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

Bug#984049: enblend-enfuse: ftbfs with GCC-11

2021-12-14 Thread Heinz Repp


/usr/include/vigra/separableconvolution.hxx:1413:13: error: ISO C++17 does not 
allow dynamic exception specifications
/usr/include/vigra/stdconvolution.hxx:796:13: error: ISO C++17 does not allow 
dynamic exception specifications


For those two errors I propose the first patch (c++17conf, in 
include/vigra): The original code had conditional compilation in place: 
all non Microsoft compilers got a pre-C++11 and C++17-forbidden 
construct, and Microsoft Visual C++ 2014 and up got a C++11-introduced 
and C++17-conformant construct. I removed the condition and left only 
the latter - this means you need at least GCC 4.8.1 to compile this (or 
MSC 2014/201).



Then I found another syntax error in Python code - Python 3.10 requires 
parentheses around multiple except-clauses (pythonexcept, in vigranumpy).


With those two patches it compiles, but then 22 tests fail, all with the 
same error in C++ template syntax I am not familiar with. They all fail 
because of a single discrepancy between Python and C++ representation of 
the constructArrayFromAxistags function:



Boost.Python.ArgumentError: Python argument types in
vigra.vigranumpycore.constructArrayFromAxistags(type, tuple, 
numpy.dtype[float32], AxisTags, bool)
did not match C++ signature:
constructArrayFromAxistags(boost::python::api::object, vigra::ArrayVector >, NPY_TYPES, vigra::AxisTags, bool)



Maybe someone can figure out what's wrong there.

Greetings

Heinz Reppdiff -Naur a/separableconvolution.hxx b/separableconvolution.hxx
--- a/separableconvolution.hxx	2021-12-14 12:47:58.561112628 +0100
+++ b/separableconvolution.hxx	2021-12-14 12:41:47.490153379 +0100
@@ -1409,11 +1409,7 @@
 {}
 
 ~InitProxy()
-#ifndef _MSC_VER
-throw(PreconditionViolation)
-#elif _MSC_VER >= 1900
 noexcept(false)
-#endif
 {
 vigra_precondition(count_ == 1 || count_ == sum_,
   "Kernel1D::initExplicitly(): "
diff -Naur a/stdconvolution.hxx b/stdconvolution.hxx
--- a/stdconvolution.hxx	2021-12-14 12:47:58.561112628 +0100
+++ b/stdconvolution.hxx	2021-12-14 12:43:12.728503532 +0100
@@ -792,11 +792,7 @@
 {}
 
 ~InitProxy()
-#ifndef _MSC_VER
-throw(PreconditionViolation)
-#elif _MSC_VER >= 1900
 noexcept(false)
-#endif
 {
 vigra_precondition(count_ == 1 || count_ == sum_,
"Kernel2D::initExplicitly(): "
diff -Naur a/conf.py.cmake2.in b/conf.py.cmake2.in
--- a/conf.py.cmake2.in	2021-12-14 12:38:10.0 +0100
+++ b/conf.py.cmake2.in	2021-12-14 14:13:42.030342506 +0100
@@ -23,7 +23,7 @@
 def _getargspec_workaround(*args, **kw):
 try:
 return _original_getargspec(*args, **kw)
-except TypeError, e:
+except (TypeError, e):
 if str(e).startswith('arg is not a Python function'):
 return inspect.ArgSpec([], None, None, None)
 else:
diff -Naur a/conf.py.in b/conf.py.in
--- a/conf.py.in	2021-12-14 12:38:10.0 +0100
+++ b/conf.py.in	2021-12-14 14:14:07.576442837 +0100
@@ -22,7 +22,7 @@
 def _getargspec_workaround(*args, **kw):
 try:
 return _original_getargspec(*args, **kw)
-except TypeError, e:
+except (TypeError, e):
 if str(e).startswith('arg is not a Python function'):
 return inspect.ArgSpec([], None, None, None)
 else:

Bug#1001560: 回复：Bug#1001560: Acknowledgement (installation-reports)

2021-12-14 Thread pinokio

It seems the dts forget to set the EMAC power enable pin (pin19). Could anyone 
helps to fix it?

Bug#1001677: lintian: check for: "cd ... py3versions -r" in autopkgtest scripts

2021-12-14 Thread Julian Gilbey

Hi Mattia,

On Tue, Dec 14, 2021 at 03:39:54PM +0100, Mattia Rizzolo wrote:
> Hi Julian,
> 
> On Tue, Dec 14, 2021 at 06:49:12AM +, Julian Gilbey wrote:
> > I discovered that in several of my autopkgtest scripts, and in various
> > other packages in the archive, the following pattern appears:
> 
> I think (although I'm not an authoritative voice of any kind here) that
> you you are using the wrong option altogether actually.

That may or may not be true.  What I am observing, though, is that
there are a number of packages that have this bug.  Not many, but a
moderate number nonetheless.

> > cd somewhere
> > ...
> > for py in $(py3versions -r 2>/dev/null)
> > ...
> > 
> > Unfortunately, this silently fails,
> 
> Of course it's silent.  you are asking something and then ignoring the
> output…

Well, yes and no.  In a package that doesn't have X-Python3-Version
set, py3versions -r prints a warning message to stderr, and we want to
suppress this so that autopkgtest doesn't fail for no reason (adding
Restrictions: allow-stderr for a single expected warning is not a good
thing to do).  However, this doesn't separate from the case where
py3versions -r prints an error message and exits with an error status.

> > is given.  The "2>/dev/null" is nevertheless usually required even
> > when run from the correct directory to silence the warning:
> > 
> > py3versions: no X-Python3-Version in control file, using supported versions
> 
> that's because you are using the wrong option.

You may well be correct.  That doesn't change the reality that this is
what is happening in a number of packages.

> You should use `-s` instead of `-r` in those cases, and drop the
> 2>/dev/null.

I'm not convinced; if a X-Python3-Version is added later to a package
using -s, then things might go wrong, whereas -r will always do the
right thing as it falls back to -s.  Or if copying boilerplate testing
code, -r always works but -s doesn't.  A better possibility might be
for py3versions to introduce an additional option -q/--quiet to
suppress the warning message when -r falls back to -s; this is vastly
superior to 2>/dev/null as it will let the true failure remain
visible (and possibly cause autopkgtest to correctly fail).

> Besides, even if you keep the -r it wouldn't be much of a problem: $()
> only captures stdout, stderr just gets printed and doesn't interfere
> with the for loop or such, so why are you doing this?

Because any output to stderr causes autopkgtest to fail unless it is
specifically instructed to allow-stderr.

> -r is used by dh_python and other build scripts because they have to
> support all packages, but IMHO you really should be using -s if you know
> you don't have X-Python3-Version in your package and you *really* want
> to just suppose whatever are the current supported python3 versions.

You may indeed be right.

> > The corrected script should read something like:
> > 
> > ...
> > for py in $(py3versions -r 2>/dev/null); do
> > cd somewhere
> > ...
> 
> 
> And then, `py3versions -s` will "just work" wherever you are, no need to
> do this fairly complicated check.

True.

> > A regex such as /\bcd\b.*py3versions\s+-r/s applied to the entire
> > content of debian/tests/control and every other file in debian/tests
> > should catch this issue.
> 
> Yeah sure, and then what about pushd ?  Doing this kind of check in
> lintian is fraught with false positives, so I recommend the lintian
> maintainers don't try to do this.

I don't think I've yet found a case where pushd has been incorrectly
used (and I've so far checked all source packages beginning with a-f
and all source packages with "python" in their name).

> However, instead, I'd suggest that, after checking with the
> debian-python@ lists, we could tell people to use -s if and only if
> X-Python3-Version is not defined (conversely, we should warn if packages
> use -s if X-Python3-Version *is* defined, probably).

That sounds very sensible.  If people hear the advice.  And how does
one check that the advice is being followed?  Hence my suggestion to
have a lintian check for this.

But it may be a moot point: if it turns out that only a handful of
packages have this issue (and I'm currently filing bug reports on
them), then once they are fixed, maintainers who copy such scripts are
unlikely to reintroduce the issue.

Best wishes,

   Julian

Bug#940328: O: keepassx -- Cross Platform Password Manager

2021-12-14 Thread Fabio Fantoni

Hi, is not maintained anymore upstream: 
https://www.keepassx.org/index.html%3Fp=636.html (the announcement is 
recent but the latest version is 5 years ago)


his fork keepassxc is already present in debian and maintained 
(https://tracker.debian.org/pkg/keepassxc), I suppose that instead 
search maintainer for keepassx can be good check if possible a 
"transition" to keepassxc (and after remove keepassx)




OpenPGP_signature
Description: OpenPGP digital signature

Bug#998174: libical3 segfaults on my birthdays.ics ;)

2021-12-14 Thread Nicolas Mora


Hello,

I've been investigating with your calendar file using libical3 on 
korganizer and I've found out that libical3.10 and libical3.12 are 
correctly importing your file, when libical3.11 doesn't, so I'm guessing 
your problem is fixed with the last package.


Can you test with package libical3 3.0.12-1 ? it's currently in unstable 
but I've successfully installed it on a ubuntu latest.


/Nicolas

Bug#965379: Sometimes draws hyphens after each word

2021-12-14 Thread Dave

 I have version 0.12.10dfsg2-5 installed, and suffered the same issue.

 Found a fix for it.  Go to Options, and select the Styles tab.  Under
"Options for", choose "Regular Paragraph".  Click on the "Allow Hyphenations"
checkbox until it looks grey or solid.  Restart fbreader.

 Text in ebook is now no longer filled with hyphens.

 Cheers,
 dave

Bug#1001681: sight: FTBFS in unstable

2021-12-14 Thread Flavien Bridault


Understood, I just wanted to avoid any overlap. I'll have a look asap. :)


*Dr. Flavien BRIDAULT*
Director of Software Development
IRCAD France & IRCAD Africa

flavien.brida...@ircad.fr 
Tél. : +33 (0)3 88 119 201
IRCAD France
http://www.ircad.fr/
http://www.ircad.africa/ 

Suivez l'IRCAD sur Facebook 



*IRCAD France*
Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg Cedex 
- FRANCE


Le 14/12/2021 à 17:49, Andreas Tille a écrit :

Hi Flavien,

Am Tue, Dec 14, 2021 at 04:13:26PM +0100 schrieb Flavien Bridault:

Thanks for the notice.

This comes from DCMTK. Maybe an API change or a move of a header. Do you
want me to have a look ?

I guess Steve will be very happy if you can have a look.  As far as
I know he is not a medical imaging expert and has no interest in
debugging DCMTK.

Thanks a lot for checking

   Andreas.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001707: ITP: ignition-gui -- Ignition GUI ships with several widgets ready to use and offers a plugin interface which can be used to add custom widgets.

2021-12-14 Thread Jose Luis Rivero

Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ignition-gui
  Version : 6.2.0
  Upstream Author : Open Robotics
* URL : https://github.com/ignitionrobotics/ign-gui
* License : Apache2
  Programming Lang: C++,
  Description : Ignition GUI ships with several widgets ready to use and 
offers a plugin interface which can be used to add custom widgets.

Ignition GUI builds on top of Qt to provide widgets which are useful when
developing robotics applications, such as a 3D view, plots, dashboard, etc, and
can be used together in a convenient unified interface.

Ignition GUI ships with several widgets ready to use and offers a plugin
interface which can be used to add custom widgets.

Bug#1001681: sight: FTBFS in unstable