Bug#1001690: wmaker: White horizontal zones

[JKB]

Package: wmaker
Version: 0.95.9-3
Severity: important

Dear Maintainer,

Since last upgrade of Windowmaker, I randomly have white lines on screen.
These lines are not displayed on dock.

Of course, I have tested some other windowmanagers (fvwm for example) and
these white blocks of lines only appear with wmaker.

Best regards,

JKB

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

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

Versions of packages wmaker depends on:
ii  libc6   2.32-5
ii  libexif12   0.6.24-1
ii  libfontconfig1  2.13.1-4.2
ii  libwings3   0.95.9-3
ii  libwraster6 0.95.9-3
ii  libwutil5   0.95.9-3
ii  libx11-62:1.7.2-2+b1
ii  libxext62:1.3.4-1
ii  libxinerama12:1.1.4-2
ii  libxpm4 1:3.5.12-1
ii  wmaker-common   0.95.9-3

wmaker recommends no packages.

Versions of packages wmaker suggests:
ii  desktop-base  11.0.3
ii  gnome-terminal [x-terminal-emulator]  3.42.2-1
ii  wmaker-data   0.9~4-1
pn  wmaker-utils  
ii  x11-apps  7.7+8
ii  xterm [x-terminal-emulator]   370-1

-- no debconf information

Bug#1001666: stress-ng: flaky autopkgtest

[Sebastian Ramacher]

Hi Colin

On 2021-12-13 23:38:56, Colin King (gmail) wrote:
> Hi Sebastian,
> 
> thanks for reporting this. Is is OK to ask a few questions as I've never
> seen this before on a wide range of kit that I test this on.
> 
> 1. Is this failure repeatable? (I'm not sure how it occurs since there is a
> SIGSEGV handler for these cases).

It is repeatable to some extend. For recent failures, see
https://ci.debian.net/packages/s/stress-ng/testing/amd64/ and
https://ci.debian.net/packages/s/stress-ng/testing/i386/.

> 2. Does it fail on specific machines?
> 3. What CPU model is the machine it fails on?

I can't answer these two questions. I suggest to contact the debci
maintainers by, for example, joining #debci on OFTC.

Cheers

> 
> I've tried to understand this failure, but so far I'm quite perplexed by it,
> so maybe it's a CPU specific caching behavior that I have misunderstood.
> 
> Any assistance with the questions above would be most useful,
> 
> Regards,
> 
> Colin
> 
> 
> On 13/12/2021 21:48, Sebastian Ramacher wrote:
> > Source: stress-ng
> > Version: 0.13.08-1
> > Severity: important
> > X-Debbugs-Cc: sramac...@debian.org
> > 
> > The autopkgtests of stress-ng fail from time to time:
> > | stress-ng: 20:49:12.58 info:  [1091] unsuccessful run completed in 0.51s
> > | stress-ng: 20:49:12.58 fail:  [1091] cache instance 3 corrupted bogo-ops 
> > counter, 2 vs 0
> > | stress-ng: 20:49:12.58 fail:  [1091] cache instance 3 hash error in 
> > bogo-ops counter and run flag, 796547380 vs 0
> > | stress-ng: 20:49:12.58 fail:  [1091] metrics-check: stressor metrics 
> > corrupted, data is compromised
> > | cache FAILED
> > ...
> > | zlib PASSED
> > | 42 PASSED
> > | 1 FAILED, cache
> > | 0 SKIPPED
> > 
> > See
> > https://ci.debian.net/data/autopkgtest/testing/amd64/s/stress-ng/17550292/log.gz
> > for a recent failure
> > 
> > Cheers
> > 
> 

-- 
Sebastian Ramacher

Bug#999022: binstats: diff for NMU version 1.08-9.1

[Stephen Kitt]

Control: tags 999022 + patch
Control: tags 999022 + pending

Dear maintainer,

I've prepared an NMU for binstats (versioned as 1.08-9.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer; you can of course also replace this with your
own upload.

Regards,

Stephen
diff -u binstats-1.08/debian/changelog binstats-1.08/debian/changelog
--- binstats-1.08/debian/changelog
+++ binstats-1.08/debian/changelog
@@ -1,3 +1,10 @@
+binstats (1.08-9.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to short dh rules. Closes: #999022.
+
+ -- Stephen Kitt   Tue, 14 Dec 2021 08:56:38 +0100
+
 binstats (1.08-9) unstable; urgency=low
 
   * Acknowledge NMU
diff -u binstats-1.08/debian/rules binstats-1.08/debian/rules
--- binstats-1.08/debian/rules
+++ binstats-1.08/debian/rules
@@ -1,53 +1,10 @@
 #! /usr/bin/make -f
 
-export CFLAGS="-O2 -g -Wall"
-export LDFLAGS=""
+%:
+	dh $@
 
-clean:
-	dh_testdir
-	dh_testroot
-	dh_clean
-	make clean
+# We only ship the shell script, there's nothing to build
+override_dh_auto_build:
 
-build:
-	make 
-
-binary:  binary-indep
-
-binary-indep: 
-	dh_testdir 
-	dh_testroot
-	dh_clean 
-	dh_installdirs  usr/bin 
-	cp -p binstats debian/binstats/usr/bin
-	dh_installdocs README
-	dh_installman binstats.1
-	dh_installchangelogs
-	dh_strip
-	dh_compress
-	dh_fixperms
-	dh_installdeb
-	dh_gencontrol
-	dh_md5sums
-	dh_builddeb
-
-binary-arch: build
-	dh_testdir 
-	dh_testroot
-	dh_clean 
-	dh_installdirs  usr/bin usr/share/man/man1
-	make install DESTBIN=`pwd`/debian/binstats/usr/bin \
-	   	 DESTMAN=`pwd`/debian/binstats/usr/share/man/man1
-	cp -p binstats debian/binstats/usr/bin
-	dh_installdocs README
-	dh_installman binstats.1
-	dh_installchangelogs
-	dh_strip
-	dh_compress
-	dh_fixperms
-	dh_installdeb
-	dh_gencontrol
-	dh_md5sums
-	dh_builddeb
-
-.PHONY: clean build binary binary-arch binary-indep
+# Everything is installed through debhelper
+override_dh_auto_install:
reverted:
--- binstats-1.08/debian/rules.tiny
+++ binstats-1.08.orig/debian/rules.tiny
@@ -1,3 +0,0 @@
-#!/usr/bin/make -f
-%:
-	dh $@
only in patch2:
unchanged:
--- binstats-1.08.orig/debian/docs
+++ binstats-1.08/debian/docs
@@ -0,0 +1 @@
+README
only in patch2:
unchanged:
--- binstats-1.08.orig/debian/install
+++ binstats-1.08/debian/install
@@ -0,0 +1 @@
+binstats /usr/bin
only in patch2:
unchanged:
--- binstats-1.08.orig/debian/manpages
+++ binstats-1.08/debian/manpages
@@ -0,0 +1 @@
+binstats.1


signature.asc
Description: PGP signature

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

[Thomas Arendsen Hein]

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)?

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.

Thank you,

Thomas Arendsen Hein

-- 
Thomas Arendsen Hein 
OpenPGP key: https://intevation.de/~thomas/thomas_pgp.asc (0xD45DE28FF3A2250C)
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Bug#1001684: Davmail should use log4j 2.16 rather than 1.2

[Alain Knaff]

Hi Alexandre,

On 14/12/2021 11:51, Alexandre Rossi wrote:
> tag 1001684 moreinfo
> thanks
> 
> Hi,
> 
>> According to https://github.com/jagornet/dhcp/issues/20 , log4j 1.2 is
>> vulnerable to CVE-2019-17571, so davmail should use log4j 2.15 or 2.16
>> instead.
> 
> According to the debian security tracker[1], this has been fixed in
> log4j so davmail uses a fixed version.
> https://security-tracker.debian.org/tracker/source-package/apache-log4j1.2

ok that's good news :-)

> 
> Do you have exploit code that works against davmail or any other clue
> that davmail needs fixing?

Unfortunately not.

I only stumbled upon this when examining our servers for instances
vulnerable to CVE-2021-44228. Forums seem to claim that versions log4j
versions 1 are not safe either (different vulnerabilities), but without
giving any specifics. However, log4j team itself says versions 1.x are
"end of life" and should be avoided. So, it's more a case of "better be
safe than sorry" than any concrete exploit.

Also, since a while already, Java now has its own internal logging
framework (java.util.logging.Logger), so there should be less and less
reason to use potentially unsafe third-party logging libraries (but
switching to java's internal logging might be more difficult to do in
the short run than just upgrading to a newer version).


> 
> Thanks,
> 
> Alex
> 

Regards,
-- 
Alain Knaff
Ingénieur Informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat et du Développement durable
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu

Bug#1001683: node-babel-loader: FTBFS with webpack5: BREAKING CHANGE: No more changes should happen to Compilation.assets after sealing the Compilation

[Caleb Adepitan]

Source: node-babel-loader

Version: 8.2.3-1

Severity: important

Justification: ftbfs

Tags: ftbfs

User: pkg-javascript-de...@alioth-lists.debian.net

Usertags: webpack5

Hi,

We are starting to build against webpack5 in experimental and the 
package needed for local build is webpack and node-webpack-source from 
experimental.
During a test rebuild, node-babel-loader was found to fail to build in 
that situation.


Relevant part (hopefully):


# should throw error
(node:207301) [DEP_WEBPACK_COMPILATION_NORMAL_MODULE_LOADER_HOOK] 
DeprecationWarning: Compilation.hooks.normalModuleLoader was moved to 
NormalModule.getCompilationHooks(compilation).loader
(node:207301) [DEP_WEBPACK_COMPILATION_ASSETS] DeprecationWarning: 
Compilation.assets will be frozen in future, all modifications are 
deprecated.
BREAKING CHANGE: No more changes should happen to Compilation.assets 
after sealing the Compilation.

Do changes to assets earlier, e. g. in Compilation.hooks.processAssets.
	Make sure to select an appropriate stage from 
Compilation.PROCESS_ASSETS_STAGE_*.


not ok 75 should be strictly equal
  ---
operator: equal
expected: |-
  'webpack://babel-loader/./test/fixtures/basic.js'
actual: |-
  'webpack://babel-loader/webpack/bootstrap'
at:  (/<>/test/sourcemaps.test.js:123:15)
stack: |-
  Error: should be strictly equal
  at Test.assert [as _assert] 
(/usr/share/nodejs/tape/lib/test.js:311:54)
  at Test.bound [as _assert] 
(/usr/share/nodejs/tape/lib/test.js:96:32)

  at Test.strictEqual (/usr/share/nodejs/tape/lib/test.js:475:10)
  at Test.bound [as is] (/usr/share/nodejs/tape/lib/test.js:96:32)
  at /<>/test/sourcemaps.test.js:123:15
  at FSReqCallback.readFileAfterClose [as oncomplete] 
(internal/fs/read_file_context.js:63:3)

  ...
not ok 90 should be strictly equal
  ---
operator: equal
expected: |-
  'webpack://babel-loader/./test/fixtures/basic.js'
actual: |-
  'webpack://babel-loader/webpack/bootstrap'
at:  (/<>/test/sourcemaps.test.js:240:15)
stack: |-
  Error: should be strictly equal
  at Test.assert [as _assert] 
(/usr/share/nodejs/tape/lib/test.js:311:54)
  at Test.bound [as _assert] 
(/usr/share/nodejs/tape/lib/test.js:96:32)

  at Test.strictEqual (/usr/share/nodejs/tape/lib/test.js:475:10)
  at Test.bound [as is] (/usr/share/nodejs/tape/lib/test.js:96:32)
  at /<>/test/sourcemaps.test.js:240:15
  at FSReqCallback.readFileAfterClose [as oncomplete] 
(internal/fs/read_file_context.js:63:3)

  ...
not ok 91 should be truthy
  ---
operator: ok
expected: true
actual:   false
at:  (/<>/test/sourcemaps.test.js:247:15)
stack: |-
  Error: should be truthy
  at Test.assert [as _assert] 
(/usr/share/nodejs/tape/lib/test.js:311:54)
  at Test.bound [as _assert] 
(/usr/share/nodejs/tape/lib/test.js:96:32)

  at Test.assert (/usr/share/nodejs/tape/lib/test.js:430:10)
  at Test.bound [as ok] (/usr/share/nodejs/tape/lib/test.js:96:32)
  at /<>/test/sourcemaps.test.js:247:15
  at FSReqCallback.readFileAfterClose [as oncomplete] 
(internal/fs/read_file_context.js:63:3)

  ...
not ok 98 should be strictly equal
  ---
operator: equal
expected: |-
  'webpack://babel-loader/./test/fixtures/basic.js'
actual: |-
  'webpack://babel-loader/webpack/bootstrap'
at:  (/<>/test/sourcemaps.test.js:304:15)
stack: |-
  Error: should be strictly equal
  at Test.assert [as _assert] 
(/usr/share/nodejs/tape/lib/test.js:311:54)
  at Test.bound [as _assert] 
(/usr/share/nodejs/tape/lib/test.js:96:32)

  at Test.strictEqual (/usr/share/nodejs/tape/lib/test.js:475:10)
  at Test.bound [as is] (/usr/share/nodejs/tape/lib/test.js:96:32)
  at /<>/test/sourcemaps.test.js:304:15
  at FSReqCallback.readFileAfterClose [as oncomplete] 
(internal/fs/read_file_context.js:63:3)

  ...
not ok 99 should be truthy
  ---
operator: ok
expected: true
actual:   false
at:  (/<>/test/sourcemaps.test.js:311:15)
stack: |-
  Error: should be truthy
  at Test.assert [as _assert] 
(/usr/share/nodejs/tape/lib/test.js:311:54)
  at Test.bound [as _assert] 
(/usr/share/nodejs/tape/lib/test.js:96:32)

  at Test.assert (/usr/share/nodejs/tape/lib/test.js:430:10)
  at Test.bound [as ok] (/usr/share/nodejs/tape/lib/test.js:96:32)
  at /<>/test/sourcemaps.test.js:311:15
  at FSReqCallback.readFileAfterClose [as oncomplete] 
(internal/fs/read_file_context.js:63:3)

  ...


The full log is attached to this mail.
sbuild (Debian sbuild) 0.81.2 (31 January 2021) on debian

+==+
| node-babel-loader 8.2.3-1 (amd64)Mon, 13 Dec 2021 15:06:04 + |

Bug#995212: ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]

[Jeff Blake]

On Tue, 7 Dec 2021 19:43:10 +0100 Tomas Pospisek  wrote:
> On 06.12.21 20:43, Noah Meyerhans wrote:
> > On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote:
>  So what's happening with chromium in both sid and stable? I saw on 
>  d-release that it was removed from testing (#998676 and #998732), with a 
>   discussion about ending security support for it in stable.
> >>>
> >>> The problem really is lack of maintenance. In my opinion, chromium 
> >>> deserves an active *team* to support it in Debian.  <...>  The security 
> >>> team doesn't have the bandwidth to do it themselves, they need a team to 
> >>> help them.
> >>
> >> Sorry for a silly question, but whatʼs so wrong with the build done by 
> >> linuxmint.com [1], so Debian needs a whole team to duplicate their effort? 
> >>  Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in 
> >> my (limited) experience.
> >>
> > 
> > Well, you can start with the fact that the Mint chromium source packages
> > don't even include the chromium source, let alone the sources for all
> > the other things they build (NodeJS, and more).
> > 
> > The biggest difficulty, as far as I can tell from my look at Chromium
> > from several months ago, is that our patch set [1] needs a lot of
> > attention with every chromium release.  Mint doesn't apply any patches
> > at all to the source, at least none of any real complexity.
> > 
> > One lesson we may take from Mint, though, is that it's not worth trying
> > to patch Chromium as much as we'd like.  Anything that we can do to
> > simplify the Chromium packaging will help us keep the package
> > up-to-date, which in turn will help us keep our users safer.  In my
> > opinion, we should be pretty aggressive about dropping as many of the
> > Chromium patches as possible, even if that means we link against
> > bundled/vendored dependencies.
> > 
> > Legal/licensing considerations are still important and I don't know if
> > we actually *can* ship builds based on the bundled stuff.  But based on
> > the number of patches we have to disable various things [2] or build
> > against system dependencies [3], I can't help but think we'd have an
> > easier time keeping this package fresh if we could drop some of those.
> > 
> > noah
> > 
> > 1. 
> > https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/series
> > 2. 
> > https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/disable
> > 3. 
> > https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/system
> 
> I'd also like to point out, that the ungoogled-chromium project has some 
> overlap in goals with Debian and it'd possibly be interessing to join 
> forces:
> 
> https://github.com/ungoogled-software/ungoogled-chromium-debian
> 
> (I have been running an ungoogled-chromium for a while (ca. a year 
> ago?), however at that time their chrome wasn't extremely stable so I 
> gave up again. Does anybody have experience using it recently?)
> *t
> 
> 
> 


I have recently forked the debian version of ungoogled chromium [1] [2] [3] to 
(amongst other reasons) re-incorporate many of the previous debian patches and 
features [4].

I haven't had any of the major problems which have blocked the main upstream 
version of it 
over the last couple of release, and the latest chromium version builds and 
runs on both 
unstable and stable.

Most of the debian patches aren't too much bother to update, and are mainly 
context changes. 
Many of them seem worth having, but several are problematic, and if anyone 
wants to make 
maintenance easier then the low hanging fruit to delete for enhanced 
maintainability is as 
follows.


## Plainly not a good idea
debianization/optimization.patch
system/use-desktop-gl-as-default.patch

## Too complex or not worth the trouble to maintain
fixes/inspector.patch
fixes/widevine-revision.patch
system/convertutf.patch

## GCC specific
fixes/gnu-as.patch
warnings/int-in-bool-context.patch
warnings/stringop-overflow.patch

# System lib replacements which are too changeable and/or incompatible between 
stable/unstable
bullseye/ffmpeg.patch
bullseye/icu-types.patch
system/clang-format.patch
system/ffmpeg.patch
system/harfbuzz.patch


Upstream is better placed to judge optimisation levels per build target, and 
all you'll 
achieve with a flat '-O2 everywhere' is a slower binary. With upstream bundled 
clang 
(discussed below) dpkg buildflags doesn't appear to be picked up by the build 
system anyway.

The desktop gl patch is questionable since it can be set as a runtime flag in 
the existing 
debian/etc/default-flags file.

Inspector and convertutf are the worst offenders in terms of being unnecessary 
and complex. 
The disable/catapult.patch could also be dropped, since profiling might be 
desirable to some 
users.

Using gcc to build chromium was dropped by debian ages ago and is not supported 
upstream, so 
I don't see the point in patching gcc-related build 

Bug#1001682: doxygen use current build path as id value in html code

[肖盛文]

X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org


Hi,

    The simple describe about #1001682 is:

doxygen use current build path as id value in html code for README.md.



The "tmp_reprotest_ilsJd0_build_experiment_1" string is an embedded build path 
/tmp/reprotest-X/build-experiment-1/

This cause the FTBR[1].

The id value keep the consistent in different build path will fix this bug.


[1] https://tests.reproducible-builds.org/debian/reproducible.html


Thanks!

--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_0x00186602339240CB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001643: Acknowledgement (sdaps: fails to setup a project with texlive-latex-extra/unstable (2021.2021127-1))

[Vincent-Xavier JUMEL]

In the comment https://github.com/sdaps/sdaps/issues/
238#issuecomment-993392198[1], sdaps author and maintener states that the 
package 
should not ship anymore these files

> Yes. The package should add a dependency to the LaTeX class. And then stop 
> setting --
build-tex and --install-tex in debian/rules.
> This was set earlier (in my own packages too), because TeXLive had a bug and 
> was 
missing a file.

-- 
Vincent-Xavier JUMEL Id: 0xBC8C2BAB14ABB3F2 https://blog.thetys-retz.net

Société Libre, Logiciel Libre http://www.april.org/adherer
Parinux, logiciel libre à Paris : http://www.parinux.org



[1] https://github.com/sdaps/sdaps/issues/238#issuecomment-993392198

Bug#703102: Nowy system 2022

[Arkadiusz Stryj]

Dzień dobry, 

kontaktuje się z Państwem, ponieważ jako osoba zajmująca się usprawnieniem 
procesów, chciałbym zaprezentować nowoczesne rozwiązanie dla Państwa firmy. 

System został stworzony z myślą o przedsiębiorstwach z sektora MŚP, aby 
zapewnić bezpieczeństwo danych, niezawodność i optymalizację procesów. Dzięki 
bogatym funkcjonalnościom usprawnia i przyspiesza obsługę zleceń.

Jeśli chcieliby Państwo zwiększyć tempo rozwoju swojej działalności i poszerzyć 
rynek zbytu chętnie opowiem więcej. Kiedy mogę się skontaktować? 


Pozdrawiam,
Arkadiusz Stryj

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

[Martin-Éric Racine]

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:
> >
> > Package: gnome-gmail
> > Version: 2.8-1
> > Severity: important
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > The version of gnome-mail currently in Stable fails to connect to GMail 
> > with an API error.
> >
>
> 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

Bug#742241: tmpreaper: please make it easy to use tmpreaper without running it from cron to clean /tmp

[Paul Slootman]

Sorry for ignoring this for so long...

On Fri 21 Mar 2014, Joost van Baal-Ilić wrote:

> Package: tmpreaper
> Version: 1.6.13+nmu1
> Severity: wishlist
> Tags: patch
> 
> Hi,
> 
> I'd like to use tmpreaper to clean other directories then /tmp.  Currently,
> this would need editing both /etc/cron.daily/tmpreaper and 
> /etc/tmpreaper.conf.
> Applying this patch in the package would mean the user would have to edit only
> one file and, furthermore, would point the user to a way not to suffer from
> tmpreapers security issues.

Surely if you don't want to run tmpreaper from cron, simply delete the
cron.daily script?

If you don't use the cron.daily script (either by deleting it or by
implementing your suggested patch) then /etc/tmpreaper.conf is not used.
So if you want to run tmpreaper manually, just go for it, no need to
modify /tmp/tmpreaper.conf.

Maybe I've misunderstood what you're trying to do?


Regards,
Paul

Bug#1001692: bullseye-pu: package rust-cbindgen/0.17.0-4

[Emilio Pozuelo Monfort]

On 14/12/2021 13:36, Emilio Pozuelo Monfort wrote:

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net

Hi,

This is an update of cbindgen to 0.20.0, as required by firefox and
thunderbird ESR 91 updates. Since cbindgen is only used by those two
packages, the risk of the update is minimal.

For bullseye, we can just backport the version from sid. I'm attaching
a sid -> bullseye-pu debdiff, obviously one from the bullseye version
is significantly larger, but I don't think it's too useful here. However
if you'd like to take a look at it let me know.


Now with the diff.

Cheers,
Emilio
diff -Nru rust-cbindgen-0.20.0/debian/changelog 
rust-cbindgen-0.20.0/debian/changelog
--- rust-cbindgen-0.20.0/debian/changelog   2021-08-22 14:26:42.0 
+0200
+++ rust-cbindgen-0.20.0/debian/changelog   2021-12-02 12:49:31.0 
+0100
@@ -1,3 +1,10 @@
+rust-cbindgen (0.20.0-1~deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport to bullseye.
+
+ -- Emilio Pozuelo Monfort   Thu, 02 Dec 2021 12:49:31 +0100
+
 rust-cbindgen (0.20.0-1) unstable; urgency=medium
 
   * Package cbindgen 0.20.0 from crates.io using debcargo 2.4.4-alpha.0

Bug#988044: linux-image-5.10.0-0.bpo.4-amd64: Kernel panic due nfsd error: refcount_t: addition on 0; use-after-free

[Olivier Monaco]

Hi Salvatore,

I try also to reproduce the issue using multiple ways without success. I hope 
the modification will fix this issue.

Thank you,

Regards,
Olivier

-Message d'origine-
De : Salvatore Bonaccorso  De la part de 
Salvatore Bonaccorso
Envoyé : lundi 13 décembre 2021 21:34
À : Olivier Monaco ; 988...@bugs.debian.org
Objet : Re: Bug#988044: linux-image-5.10.0-0.bpo.4-amd64: Kernel panic due nfsd 
error: refcount_t: addition on 0; use-after-free

Hi Olivier,

On Mon, Nov 22, 2021 at 09:27:26AM +, Olivier Monaco wrote:
> Hi Salvatore,
> 
> Sorry for my very very late answer.
> 
> I tried many actions to reproduce and/or fix this problem. We upgraded 
> our kernel to the lastest backport version for Buster but the issue 
> was still there. We upgraded to Bullseye at the end of October but 
> today this issue occurred again.
> 
> I think it related to 
> https://lore.kernel.org/linux-nfs/yv3vdqopvgxc%2f...@eldamar.lan/
> 
> I just send an email to this thread. 
> 
> Something that may be important: our groups of servers are used to 
> host websites, some with only one website, some with many. For now, 
> this issue only occurred on NFS servers part of a group with many 
> websites. But one of the most loaded NFS server is also used only for 
> one website and has never had this issue. May be this issue occurs 
> only when the NFS server is serving many different files.

I was never able to reliably reproduce the issue myself, but upstream now 
thinks to have isolated the issue and should be fixed with:

https://git.kernel.org/linus/548ec0805c399c65ed66c6641be467f717833ab5

Fixes are as well queued to stable series.

Regards,
Salvatore

Bug#1001555: openconnect: can't connect to server that use SSO SAML with protocol "anyconnect"

[Luca Boccassi]

On Tue, 2021-12-14 at 08:57 +0100, Antonio wrote:
> From GUI interface I can now select the correct group in the
> ComboBox, however when I try to access I get the same result: "No SSO
> handler".
> 
> 
> 
> POST https://myserver/
> Got HTTP response: HTTP/1.1 200 OK
> Content-Type: text/xml; charset=utf-8
> Transfer-Encoding: chunked
> Cache-Control: no-store
> Pragma: no-cache
> Connection: Keep-Alive
> Date: Tue, 14 Dec 2021 07:49:44 GMT
> X-Frame-Options: SAMEORIGIN
> Strict-Transport-Security: max-age=31536000; includeSubDomains
> X-Content-Type-Options: nosniff
> X-XSS-Protection: 1
> Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-
> eval' data: blob:; frame-ancestors 'self'
> X-Aggregate-Auth: 1
> HTTP body chunked (-2)
> POST XML abilitato
> POST https://myserver/
> Got HTTP response: HTTP/1.1 200 OK
> Content-Type: text/xml; charset=utf-8
> Transfer-Encoding: chunked
> Cache-Control: no-store
> Pragma: no-cache
> Connection: Keep-Alive
> Date: Tue, 14 Dec 2021 07:49:46 GMT
> X-Frame-Options: SAMEORIGIN
> Strict-Transport-Security: max-age=31536000; includeSubDomains
> X-Content-Type-Options: nosniff
> X-XSS-Protection: 1
> Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-
> eval' data: blob:; frame-ancestors 'self'
> X-Aggregate-Auth: 1
> HTTP body chunked (-2)
> POST XML abilitato
> No SSO handler

Are you starting the VPN from Gnome's interface? Does the GTK browser
window pop up?

-- 
Kind regards,
Luca Boccassi


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

Bug#1001684: Davmail should use log4j 2.16 rather than 1.2

[Alexandre Rossi]

tag 1001684 moreinfo
thanks

Hi,

> According to https://github.com/jagornet/dhcp/issues/20 , log4j 1.2 is
> vulnerable to CVE-2019-17571, so davmail should use log4j 2.15 or 2.16
> instead.

According to the debian security tracker[1], this has been fixed in
log4j so davmail uses a fixed version.
https://security-tracker.debian.org/tracker/source-package/apache-log4j1.2

Do you have exploit code that works against davmail or any other clue
that davmail needs fixing?

Thanks,

Alex

Bug#1001691: Build without lilv on Ubuntu

[Sebastien Bacher]

Package: pipewire
Version: 0.3.41-1

The recent update added a depends on liblilv, that component is 
currently in Ubuntu universe so it means we need to build without it 
there. Could you consider using the attached patch so we can keep the 
package in sync between the distributions?


Thanks,
diff -Nru pipewire-0.3.41/debian/changelog pipewire-0.3.41/debian/changelog
--- pipewire-0.3.41/debian/changelog	2021-12-13 12:09:33.0 +0100
+++ pipewire-0.3.41/debian/changelog	2021-12-14 13:01:38.0 +0100
@@ -1,3 +1,11 @@
+pipewire (0.3.41-2) UNRELEASED; urgency=medium
+
+  * debian/rules:
+- disable the new lv2 option on Ubuntu, lilv and its depends
+  (serd, sord, sratom) are currently in universe
+
+ -- Sebastien Bacher   Tue, 14 Dec 2021 13:01:38 +0100
+
 pipewire (0.3.41-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru pipewire-0.3.41/debian/rules pipewire-0.3.41/debian/rules
--- pipewire-0.3.41/debian/rules	2021-12-13 12:09:33.0 +0100
+++ pipewire-0.3.41/debian/rules	2021-12-14 13:01:20.0 +0100
@@ -18,6 +18,13 @@
 BLUEZ5_CODEC_LDAC=enabled
 endif
 
+# lilv and some of its dependencies are in universe
+ifeq (yes,$(shell dpkg-vendor --derives-from Ubuntu && echo yes))
+LV2=disabled
+else
+LV2=enabled
+endif
+
 override_dh_auto_configure:
 	dh_auto_configure -- \
 		-Daudiotestsrc=enabled \
@@ -30,6 +37,7 @@
 		-Ddocs=$(DOCS) \
 		-Dffmpeg=disabled \
 		-Dinstalled_tests=enabled \
+		-Dlv2=$(LV2) \
 		-Dman=enabled \
 		-Droc=disabled \
 		-Dsession-managers= \

Bug#1001693: userguide.html missing background

[積丹尼 Dan Jacobson]

Package: i3-wm
Version: 4.20.1-1
Severity: minor
File: /usr/share/doc/i3-wm/userguide.html

Browsing
https://i3wm.org/docs/userguide.html
/usr/share/doc/i3-wm/userguide.html
The former has a black background, missing in the latter.

Bug#1001692: bullseye-pu: package rust-cbindgen/0.17.0-4

[Emilio Pozuelo Monfort]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net

Hi,

This is an update of cbindgen to 0.20.0, as required by firefox and
thunderbird ESR 91 updates. Since cbindgen is only used by those two
packages, the risk of the update is minimal.

For bullseye, we can just backport the version from sid. I'm attaching
a sid -> bullseye-pu debdiff, obviously one from the bullseye version
is significantly larger, but I don't think it's too useful here. However
if you'd like to take a look at it let me know.

Cheers,
Emilio

Bug#1001555: openconnect: can't connect to server that use SSO SAML with protocol "anyconnect"

[Antonio]

>From GUI interface I can now select the correct group in the ComboBox,
however when I try to access I get the same result: "No SSO handler".



POST https://myserver/
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Transfer-Encoding: chunked
Cache-Control: no-store
Pragma: no-cache
Connection: Keep-Alive
Date: Tue, 14 Dec 2021 07:49:44 GMT
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 1
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'
data: blob:; frame-ancestors 'self'
X-Aggregate-Auth: 1
HTTP body chunked (-2)
POST XML abilitato
POST https://myserver/
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Transfer-Encoding: chunked
Cache-Control: no-store
Pragma: no-cache
Connection: Keep-Alive
Date: Tue, 14 Dec 2021 07:49:46 GMT
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 1
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'
data: blob:; frame-ancestors 'self'
X-Aggregate-Auth: 1
HTTP body chunked (-2)
POST XML abilitato
No SSO handler

Bug#1001684: Davmail should use log4j 2.16 rather than 1.2

[Alain Knaff]

Package: davmail
Version: 5.1.0.2891-2

Hi,

According to https://github.com/jagornet/dhcp/issues/20 , log4j 1.2 is
vulnerable to CVE-2019-17571, so davmail should use log4j 2.15 or 2.16
instead.

Thanks,

-- 
Alain Knaff
Ingénieur Informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat et du Développement durable
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu

Bug#1001686: haskell-hourglass: FTBFS on x32 architecture

[Laurent Bigonville]

Source: haskell-hourglass
Version: 0.2.12-3
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hello

haskell-hourglass FTBFS on x32 architectures:

hourglass
  conversion
calendar: FAIL (0.10s)
  *** Failed! (after 61 tests):
  Exception:
expected: 189203562893958s got: -181881611480442s
CallStack (from HasCallStack):
  error, called at tests/Tests.hs:120:25 in main:Main
  189203562893958s
  Use --quickcheck-replay=534039 to reproduce.


-- 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)

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

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

[Fabio Fantoni]

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001687: ITP: pyim-el -- Chinese input method support quanpin, shuangpin, wubi, cangjie and rime

[Lev Lamberov]

Package: wnpp
Owner: Lev Lamberov 
Severity: wishlist

* Package name: pyim-el
  Version : 3.9.5
  Upstream Author : Feng Shu 
* URL or Web page : https://elpa.gnu.org/packages/pyim.html
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : Chinese input method support quanpin, shuangpin, wubi, 
cangjie and rime

pyim is a Chinese input method in the Emacs environment. The code of
pyim is derived from Emacs-eim, which development stopped after 2008.
Although the external input method is powerful, it can't cooperate
with Emacs tacitly, which greatly damages the feeling of Emacs.

Features:
 - pyim supports Quanpin, Shuangpin, Wubi and Cangjie, among which
 Quanpin is the best;
 - pyim optimizes the input method by adding thesaurus;
 - pyim uses the text lexicon format, which is convenient for
 processing;
 - pyim can be used as the front end for rime.

Bug#1001688: ITP: pyim-basedict-el -- default pinyin dict for pyim

[Lev Lamberov]

Package: wnpp
Owner: Lev Lamberov 
Severity: wishlist

* Package name: pyim-basedict-el
  Version : 0.5.0
  Upstream Author : Feng Shu 
* URL or Web page : https://elpa.gnu.org/packages/pyim-basedict.html
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : default pinyin dict for pyim

pyim-basedict is the default lexicon of pyim input method, and the
lexicon data source is the libpinyin project.

Note: The number of entries in this thesaurus is about 10, which
is a *relatively small* thesaurus. It only ensures pyim can work
normally. If users want to make pyim more comfortable, they need to
add other additional thesaurus.

Bug#1001689: /usr/bin/free: misaligned columns in localized output

[mwgamera]

Package: procps
Version: 2:3.3.17-5
Severity: minor
File: /usr/bin/free

In most of the languages available, the columns in output get 
misaligned when non-ASCII characters are used. This makes it 
very ugly and sometimes hard to read.


Compare:

$ for L in en de fr pl pt_BR sv uk vi zh_CN; do echo [$L];LANGUAGE=$L free|sed 
's/^/>/';done
[en]

  totalusedfree  shared  buff/cache   available
Mem: 7630100 1562208 3255836  642724 2812056 5138008
Swap:  0   0   0

[de]

 gesamt   benutzt frei  gemns.  Puffer/Cache verfügbar
Speicher:7630100 1562208 3255836  642724 2812056 5138008
Swap:  0   0   0

[fr]

  total   utilisé  libre partagé tamp/cache   disponible
Mem: 7630100 1562492 322  642724 2812056 5137724
Partition d'échange:  0   0   0

[pl]

  razem   użyte   wolnedzielone   buf/cachedostępne
Pamięć:7630100 1562492 322  642724 2812056 5137724
Wymiana:   0   0   0

[pt_BR]

  totalusedfree  shared  buff/cache   available
Mem.:7630100 1562492 322  642724 2812056 5137724
Swap:  0   0   0

[sv]

 totalt  använt   fritt   delat  buff/cache  tillgängl.
Minne:   7630100 1562776 3255268  642724 2812056 5137440
Växl.:0   0   0

[uk]

  загалом  використ.   вільнаспільна буфери/кеш   дост.
Пам.: 7630100 1562776 3255268  642724 2812056 5137440
Своп.:  0   0   0

[vi]

  totalusedfree  shared  buff/cache   available
BNhớ:  7630100 1563060 3254984  642724 2812056 5137156
Tráo đổi:  0   0   0

[zh_CN]

  totalusedfree  shared  buff/cache   available
内存：7630100 1562888 3255156  642724 2812056 5137328
交换：  0   0   0


Some of these (French) would need a different abbreviated translation 
to fit the limits, but please look at the Ukrainian or at the lines 
starting with Swedish ”Växl.:” (1 cell off), Polish „Pamięć:” or 
Vietnamese “BNhớ:” (2 cells off).


-k

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

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

Versions of packages procps depends on:
ii  init-system-helpers  1.61
ii  libc62.32-5
ii  libncurses6  6.3-1
ii  libncursesw6 6.3-1
ii  libprocps8   2:3.3.17-5
ii  libtinfo66.3-1
ii  lsb-base 11.1.0

Versions of packages procps recommends:
ii  psmisc  23.4-2

procps suggests no packages.

-- Configuration Files:
/etc/sysctl.conf changed [not included]

-- no debconf information

Bug#1000440: pylev: new upstream version

[Julian Gilbey]

Ah, oops, there's a bug in my script

On Tue, Nov 23, 2021 at 09:01:20AM +, Julian Gilbey wrote:
> [...]
> #! /bin/sh
> 
> set -e
> 
> cp tests.py "$AUTOPKGTEST_TMP"
> cd "$AUTOPKGTEST_TMP"
> for py in $(py3versions -r 2>/dev/null) ; do
> echo "Testing with $py:"
> $py -m unittest -v tests.py
> done

The "cd" needs to come after the py3versions call:

#! /bin/sh

set -e

cp tests.py "$AUTOPKGTEST_TMP"
for py in $(py3versions -r 2>/dev/null) ; do
cd "$AUTOPKGTEST_TMP"
echo "Testing with $py:"
$py -m unittest -v tests.py
done

   Julian

Bug#1001700: ansible-mitogen: not working with ansible >= 2.11

[Reiner Herrmann]

Package: ansible-mitogen
Version: 0.3.0-1
Severity: important

Dear maintainer,

ansible-mitogen is not working with newer versions of ansible.

> ERROR! Your Ansible version (2.11.6) is too recent. The most recent version
> supported by Mitogen for Ansible is (2, 10).x. Please check the Mitogen
> release notes to see if a new version is available, otherwise
> subscribe to the corresponding GitHub issue to be notified when
> support becomes available.

ansible-core in unstable is at version 2.12.0.

Kind regards,
  Reiner


signature.asc
Description: PGP signature

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

[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

[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#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.

[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

[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#1001560: 回复：Bug#1001560: Acknowledgement (installation-reports)

[pinokio]

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

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

[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#1001081: additional information

[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#1001684: [Davmail-users] Davmail and the CVE-2021-44228-Log4j?

[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#998961: libdigest-whirlpool-perl: diff for NMU version 1.09-1.2

[gregor herrmann]

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#1001709: amule-daemon: amuled crashes with segmentation fault on startup

[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#1001640: thunderbird does not use language pack installed from debian repo

[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#978911: transmission: diff for NMU version 3.00-1.1

[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#1001711: libtoxcore2: Stack-based buffer overflow vulnerability in UDP packet handling in Toxcore (CVE-2021-44847)

[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#1001316: gnome-gmail: 2.8 to stable-updates

[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

[gregor herrmann]

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#834724: curl: (35) gnutls_handshake() failed: Public key signature verification has failed.

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

[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

[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#1001677: lintian: check for: "cd ... py3versions -r" in autopkgtest scripts

[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

[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#984049: enblend-enfuse: ftbfs with GCC-11

[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#1001712: RFP: rocm-all -- AMD Radeon Open Compute (ROCm) - A collection of utilities for GPGPU (compute) on AMD GPUs.

[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#1001705: ITP: ignition-rendering -- Ignition Rendering is a C++ library designed to provide an abstraction for different rendering engines. It offers unified APIs for creating 3D graphics applicat

[Jose Luis Rivero]

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

* Package name: ignition-rendering
  Version : 6.1.0
  Upstream Author : Open Robotics
* URL : https://github.com/ignitionrobotics/ign-rendering/
* License : Apache2
  Programming Lang: C++
  Description : Ignition Rendering is a C++ library designed to provide an 
abstraction for different rendering engines.

Ignition Rendering is a C++ library designed to provide an abstraction for
different rendering engines. It offers unified APIs for creating 3D graphics
applications.

Ignition Rendering is a component in the ignition framework, a set of libraries
designed to rapidly develop robot applications.

Bug#1001706: ITP: ignition-physics -- Ignition Physics, a component of Ignition Robotics, provides an abstract physics interface designed to support simulation and rapid development of robot applicati

[Jose Luis Rivero]

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

* Package name: ignition-physics
  Version : 5.1.0
  Upstream Author : Open Robotics
* URL : https://github.com/ignitionrobotics/ign-physics/
* License : Apache2
  Programming Lang: C++
  Description : Ignition Physics provides an abstract physics interface 
designed to support simulation and rapid development of robot applications.

Ignition Physics, a component of Ignition Robotics, provides an abstract physics
interface designed to support simulation and rapid development of robot
applications.

Bug#1001681: sight: FTBFS in unstable

[Andreas Tille]

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.

-- 
http://fam-tille.de

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

[Boyuan Yang]

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#993335: libxml-rss-feed-perl: diff for NMU version 2.212-1.3

[gregor herrmann]

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#999078: libemail-foldertype-perl: diff for NMU version 0.813-1.4

[gregor herrmann]

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#1001710: multipath-tools: booting with lvm over multipath it does not setup devices for lvm

[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

[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#997851: The doas package should be called opendoas

[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#934258: Experimentations on packaging jupyterlab

[Julian Gilbey]

On Tue, Dec 14, 2021 at 08:22:16AM +0100, Julien Puydt wrote:
> I'm still struggling with the javascript part.
> [...]
> 
> Once esbuild is clear, I'll see if that solves csso ; if it does, I'll
> see if it solves svgo ; if it does, I'll see if it solves... you get
> the point!

Oh, Julien, I feel for you!  These are so annoying.  I'm in a somewhat
similar situation with Spyder (but not quite as bad, it seems).

Good luck!

   Julian

Bug#1001694: opencascade: Please upgrade to 7.5.3p1

[Christophe Trophime]

Source: opencascade
Version: 7.5.1+dfsg1-2
Severity: wishlist

Dear Maintainer,
could you please upgrade to 7.5.3p1?

NB: please do not consider using latest release 7.6.0 unless we
can install different versions of opencascade side by side.

Thanks


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

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

Bug#908054: pcscd fails to communicate with smartcard after resuming from suspend-to-RAM

[Paride Legovini]

Ludovic Rousseau wrote on 11/12/2021:

Hello Paride,

Do you still have the problem with pcsc-lite 1.9.5?


Hi Ludovic,

It seems to be working fine now. I can't tell if it's a positive side 
effect of fixing #995814, of the new upstream release, or something else 
entirely, but I'm not able to reproduce the issue anymore.


Feel free to mark this bug as Done in version 1.9.5-1.

Cheers,

Paride

Bug#1001696: python-jellyfish: autopkgtest doesn't test anything

[Julian Gilbey]

Source: python-jellyfish
Version: 0.8.9-1
Severity: normal
Tags: patch

I just noticed a bug in my packages which affects python-jellyfish
too: the autopkgtests script debian/tests/py3 doesn't actually test
anything, as py3versions -r only gives an error message and no python
binaries when called from anywhere other than the root of the source
code tree.

The current script changes directory before calling py3versions,
causing this behaviour.  The fix is to call the cd after calling
py3versions, for example changing the body of the script to read:

cp -r testdata "$AUTOPKGTEST_TMP"
for py in $(py3versions -r 2>/dev/null) ; do
cd "$AUTOPKGTEST_TMP"
echo "Testing with $py:"
$py -m pytest --pyargs jellyfish.test
done


or:


python3_versions=$(py3versions -r 2>/dev/null)
cp -r testdata "$AUTOPKGTEST_TMP"
cd "$AUTOPKGTEST_TMP"
for py in $python3_versions ; do
echo "Testing with $py:"
$py -m pytest --pyargs jellyfish.test
done


Best wishes,

   Julian

Bug#1001622: cc by nc nd 4

[Gürkan Myczko]

makes it not go into main. not sure if it could go into non-free,

here's the stuff:
https://mentors.debian.net/package/groops/

and
https://sid.ethz.ch/debian/groops/

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

[Alexandre Rossi]

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
[...]
> > Question: Is davmail vulnerable to log4j?  If so, when could we expect a
> > security fix?
>
> Qouting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001684#22
> Debian maintainer of Davmail,  Alexandre Rossi:
>
>   > Also, since a while already, Java now has its own internal logging
>   > framework (java.util.logging.Logger), so there should be less and
>   > less reason to use potentially unsafe third-party logging libraries
>   > (but switching to java's internal logging might be more difficult
>   > to do in the short run than just upgrading to a newer version).
>
>   I'll try to report this upstream.

To clarify the log4j1 situation, it appears that it is not vulnerable
unless you use JMSAppender which davmail does not.
(there is also CVE-2019-17571 with SocketAppender which is disabled
but usable in davmail).
To clarify the Debian situation, the Debian package does not use the
embedded jar but the system shared jar.

In the case of davmail, I would say that there is a good chance that
the current provided compiled zip in 6.0.1 is not vulnerable to
CVE-2021-44228 because it does not use JMSAppender.

Alex

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

[Mad Horse]

Package: dpkg
Version: 1.21.1
Severity: important

Dear Maintainer,

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.



-- Package-specific info:

-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (900, 'testing'), (500, 'testing-proposed-updates'), (500, 
'unstable'), (500, 'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (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 dpkg depends on:
ii libbz2-1.0 1.0.8-5
ii libc6 2.32-5
ii liblzma5 5.2.5-2
ii libselinux1 3.3-1+b1
ii tar 1.34+dfsg-1
ii zlib1g 1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii apt 2.3.13
ii debsig-verify 0.25

-- debconf-show failed

Bug#998165: debian-policy: document and allow Description in the source paragraph

[Mattia Rizzolo]

On Sun, Dec 12, 2021 at 10:51:43PM +, Holger Levsen wrote:
> > |--- a/policy/ch-controlfields.rst
> > |+++ b/policy/ch-controlfields.rst
> > |@@ -652,9 +654,14 @@ orderings.  [#]_
> > | ~~~
> > | 
> > | In a source or binary control file, the ``Description`` field contains a
> > |-description of the binary package, consisting of two parts, the synopsis
> > |-or the short description, and the long description. It is a multiline
> > |-field with the following format:
> > |+description of the package, consisting of two parts, the synopsis or the 
> > short
> > |+description, and the long description.
> > |+
> > |+When used in a source control file in the general paragraph (i.e., the 
> > first
> 
> I believe the 2nd "in" in this line is too much.

Mh, not really?  However indeed it might be clearer this other way:

When used in the general paragraph of a source control file [...]

> > |+one, for the source package), the text in this field is relevant for all 
> > binary
> > |+packages built by the given source package.
> 
> and then I'd rewrite "the general paragraph (i.e., the first one, for 
> the source package)" into "the first paragraph" and the whole paragraph into
> 
> When used in a source control file the first paragraph is used as the first
> paragraph for all binary packages built by the given source package.

That's not proper: the place this text is placed (§5.6.13 "Description")
talks about the "Description" and it's linked to from the various places
this field is used (a source control file, a binary control file, a
changes control file); it's not describing the source control file (i.e.
d/control).  Furthermore, note that the wording "general paragraph"
comes from §5.2 "Source package control files – debian/control":

The first paragraph of the control file contains information about
the source package in general. [...]

The fields in the general paragraph (the first one, for the source
package) are: [...]


Of course I'm happy to use a different expression (like, "first
paragraph of a source control file") if I'm recommended to.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1001699: gcc/MIPS, gdc defines wrong stat_t for N32 and N64

[YunQiang Su]

On Tue, 14 Dec 2021 23:36:58 +0800 YunQiang Su  wrote:
> Package: src:gcc-10
> Version: 10.3.0-13
> 
> This problem makes fstat get wrong result, and thus makes gcc-12 ftbfs
> on mips64el.

Real patch for gcc-10 instead of in fact for gcc-11.

> 
> -- 
> YunQiang Su

gdc-mips64-stat.patch
Description: Binary data

Bug#998244: lists.debian.org: request for debian-math mailing list

[Tobias Hansen]

Hi Cord,

I am also in favor of the creation of this list. I think we could then close 
down debian-science-sagem...@alioth-lists.debian.net and move these discussions 
to debian-math.

Best,
Tobias

On Sat, 13 Nov 2021 16:45:48 +0530 "Nilesh Patra"  wrote:
> Dear list masters,
> 
> Since a few people already responded on this bug, and other folks
> already showed interest in joining the team[1], would you please consider to
> process this mailing list request now?
> 
> [1]: https://lists.debian.org/debian-science/2021/10/msg00034.html
> 
> Thanks a lot for your work,
> Nilesh
> 
> 

Bug#1001697: libasound2: New upstream release 1.2.6.1 available.

[Christian Marillat]

Package: libasound2
Version: 1.2.5.1-1
Severity: normal

Dear Maintainer,

It is possible to package this new version ?

Christian

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

Kernel: Linux 5.15.8 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libasound2 depends on:
ii  libasound2-data  1.2.5.1-1
ii  libc62.33-1

libasound2 recommends no packages.

Versions of packages libasound2 suggests:
ii  libasound2-plugins  1:1.2.5+gitda157e9-dmo1

-- no debconf information

Bug#1001698: whipper: New upstream release 0.10.0 available

[Tobias Frost]

Source: whipper
Version: 0.9.0-7
Severity: wishlist

Would be great to have the new version in Debian
Thanks for packaging whipper!

-- 
tobi

Bug#1001703: error: Unknown option --interleave-none

[Mathieu Malaterre]

Source: dcmtk
Version: 3.6.6-4

dcmcjpls --interleave-none has been removed. See:

* https://support.dcmtk.org/redmine/issues/892

and

* https://github.com/team-charls/charls/issues/25

Please re-activate this option for advanced users
(ENABLE_DCMJPLS_INTERLEAVE_NONE).

Bug#1001555: openconnect: can't connect to server that use SSO SAML with protocol "anyconnect"

[Antonio]

Are you starting the VPN from Gnome's interface?

No, I use plasma kde from Debian/sid


Does the GTK browser window pop up?

No

if I try with gnone interface i get "No SSO handler" again.

It seems to be a protocol problem.


Il 14/12/21 11:50, Luca Boccassi ha scritto:

No SSO handler
Are you starting the VPN from Gnome's interface? Does the GTK browser
window pop up?

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

[Mattia Rizzolo]

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.

> 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…

> 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 should use `-s` instead of `-r` in those cases, and drop the
2>/dev/null.
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?

-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.

> 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.

> 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.


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).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1001704: RFS: libfilezilla/0.34.2-2 -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: libfilezilla
   Version : 0.34.2-2
   Upstream Author : Tim Kosse 
 * URL : https://lib.filezilla-project.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/libfilezilla
   Section : libs

It builds those binary packages:

  libfilezilla-dev - build high-performing platform-independent programs 
(development)
  libfilezilla-common - build high-performing platform-independent programs 
(translations)
  libfilezilla22 - build high-performing platform-independent programs (runtime 
lib)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.34.2-2.dsc

Changes since the last upload:

 libfilezilla (0.34.2-2) unstable; urgency=medium
 .
   * Moved archicture independent files to new libfilezilla-common package
 making upgrades smoother (Closes: #998450)

Note: Package will be imported into salsa once the package passes and is 
uploaded.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1001684: Davmail should use log4j 2.16 rather than 1.2

[Alexandre Rossi]

tag 1001684 -moreinfo +upstream
severity 1001684 wishlist
thanks

> I only stumbled upon this when examining our servers for instances
> vulnerable to CVE-2021-44228. Forums seem to claim that versions log4j
> versions 1 are not safe either (different vulnerabilities), but without
> giving any specifics. However, log4j team itself says versions 1.x are
> "end of life" and should be avoided. So, it's more a case of "better be
> safe than sorry" than any concrete exploit.
>
> Also, since a while already, Java now has its own internal logging
> framework (java.util.logging.Logger), so there should be less and less
> reason to use potentially unsafe third-party logging libraries (but
> switching to java's internal logging might be more difficult to do in
> the short run than just upgrading to a newer version).

I'll try to report this upstream.

Alex

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

[Geert Stappers]

On Tue, Dec 14, 2021 at 08:52:50AM +0100, Ole Holm Nielsen via Davmail-users 
wrote:
> 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?

Qouting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001684#22
Debian maintainer of Davmail,  Alexandre Rossi:

  > Also, since a while already, Java now has its own internal logging
  > framework (java.util.logging.Logger), so there should be less and
  > less reason to use potentially unsafe third-party logging libraries
  > (but switching to java's internal logging might be more difficult
  > to do in the short run than just upgrading to a newer version).

  I'll try to report this upstream.




And I hope this helps

Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#999040: myspell-fa: missing required debian/rules targets build-arch and/or build-indep

[Salman Mohammadi]

On Tue, 09 Nov 2021 22:28:16 +0100 Lucas Nussbaum  
wrote:> Source: myspell-fa

> Version: 0.20070816-3.1
> Severity: important
> Justification: Debian Policy section 4.9
> Tags: bookworm sid
> User: debian...@lists.debian.org
> Usertags: missing-build-arch-indep
>
> Dear maintainer,
>
> 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

>
> Please note that this is also a sign that the packaging of this software
> could benefit from a refresh. For example, packages using 'dh' cannot be
> affected by this issue.
>
> This mass bug filing was discussed on debian-devel@ in
> https://lists.debian.org/debian-devel/2021/11/msg00052.html .
> The severity of this bug will be changed to 'serious' after a month.
>
> Best,
>
> Lucas
>
>


Hey Lucas,

The package is not in Salsa but is there a way that I can help keeping 
this package?



Cheers, Salman

Bug#1001385: [debian-mysql] Bug#1001385: mariadb-client-10.5: authentification fails while the credentials are ok

[Anthony Bourguignon]

Le lundi 13 décembre 2021 à 21:12 -0800, Otto Kekäläinen a écrit :
> On Mon, Dec 13, 2021 at 2:59 AM Anthony Bourguignon
>  wrote:
> > 
> > Le dimanche 12 décembre 2021 à 20:54 -0800, Otto Kekäläinen a écrit :
> > > Hello!
> > > 
> > > > On Thu, Dec 9, 2021 at 5:00 AM Anthony Bourguignon
> > > >  wrote:
> > > > ...
> > > > > I’m having an issue with the mariadb-client in bullseye. I can’t 
> > > > > connect
> > > > > to a local server using the mariadb client.
> > > > > 
> > > > > To reproduce the bug :
> > > > >   - Install bullseye
> > > > >   - Install mariadb-server and mariadb-client
> > > > >   - connect as root and create a database and a user :
> > > > >     create database testbug;
> > > > >     grant all privileges on testbug.* to 'testbug'@'127.0.0.1'
> > > > >     identified by 's3cr3t';
> > > > >   - exit the client
> > > > >   - try to connect with those credentials :
> > > > >     mariadb -h 127.0.0.1 -u testbug -p testbug
> > > > > 
> > > > > You can’t connect and get an error :
> > > > >   ERROR 1045 (28000): Access denied for user 'testbug'@'localhost' 
> > > > > (using password: YES)
> > > > 
> > > > You granted permissions to 'testbug'@'127.0.0.1' but you are
> > > > connecting from 'testbug'@'localhost'. Grant permissions to the
> > > > hostname (not IP) and try again. Also report back here if that solved
> > > > it for you, so we can close the bug report.
> > > 
> > > Did you try this? I am waiting for your comment on the above, thanks.
> > 
> > Hi. I’ve already replied to this, this is not the issue at all. There is an 
> > upstream bug, which has been confirmed :
> >   https://jira.mariadb.org/browse/MDEV-27215
> > 
> > So I think we should wait for the upstream patch to close this bug.
> 
> Upstream will only fix the error message to tell about truncation.
> There is no point in passwords beyond maybe 20 characters, let alone
> 80. I don't think massively long passwords will ever be supported,
> there is no benefit in doing so.

I don’t think the question is if I should or shouldn’t use long passwords. But 
the behavior of MariaDB should be consistent. If the limit is 80
characters, then it should be documented and we shouldn’t be allowed to put 
longer passwords. But being able to authenticate with a long passphrase on
one side, but can’t on another is really disturbing, and in my opinion is a bug.

I spent a complete morning trying to figure out why I couldn’t connect to my 
database with the client when the application was ok.

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

[Guillem Jover]

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

Bug#1001681: sight: FTBFS in unstable

[Flavien Bridault]

Hello Steve,

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 ?


Cheers,


*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 à 08:37, Steve Langasek a écrit :

Source: sight
Version: 21.0.0-2
Severity: serious
User:ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy

Hi Flavien,

sight is failing to build in unstable right now with the following error:


cd /tmp/sight-21.0.0/obj-x86_64-linux-gnu/libs/io/dimse && /usr/bin/c++ 
-DBOOST_ALL_DYN_LINK -DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK -DBOOST_CHRONO_DYN_LINK 
-DBOOST_DATE_TIME_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_IOSTREAMS_DYN_LINK 
-DBOOST_LOG_DYN_LINK -DBOOST_LOG_SETUP_DYN_LINK -DBOOST_REGEX_DYN_LINK 
-DBOOST_SPIRIT_USE_PHOENIX_V3 -DBOOST_THREAD_DONT_PROVIDE_DEPRECATED_FEATURES_SINCE_V3_0_0 
-DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_PROVIDES_FUTURE -DBOOST_THREAD_VERSION=2 
-DIO_DIMSE_EXPORTS -Dio_dimse_EXPORTS 
-I/tmp/sight-21.0.0/obj-x86_64-linux-gnu/libs/io/dimse/include -I/tmp/sight-21.0.0/libs 
-I/tmp/sight-21.0.0/libs/core 
-I/tmp/sight-21.0.0/obj-x86_64-linux-gnu/libs/core/pch/pchData/include/pchData 
-I/tmp/sight-21.0.0/obj-x86_64-linux-gnu/libs/core/core/include -I/usr/include/libxml2 
-I/tmp/sight-21.0.0/obj-x86_64-linux-gnu/libs/core/data/include -g -O2 
-ffile-prefix-map=/tmp/sight-21.0.0=. -fstack-protector-strong -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -march=sandybridge -mtune=generic -mfpmath=sse -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wconversion -Wno-unused-parameter 
-Wno-ignored-qualifiers -std=gnu++17 -include "pch.hpp"  -Winvalid-pch -MD -MT 
libs/io/dimse/CMakeFiles/io_dimse.dir/SeriesEnquirer.cpp.o -MF 
CMakeFiles/io_dimse.dir/SeriesEnquirer.cpp.o.d -o CMakeFiles/io_dimse.dir/SeriesEnquirer.cpp.o -c 
/tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp
/tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp: In member function 'std::string 
sight::io::dimse::SeriesEnquirer::findSOPInstanceUID(const string&, unsigned 
int)':
/tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp:748:5: error: 'OFIterator' 
was not declared in this scope; did you mean 'OF_error'?
   748 | OFIterator it= responses.begin();
   | ^~
   | OF_error
/tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp:748:26: error: expected 
primary-expression before '*' token
   748 | OFIterator it= responses.begin();
   |  ^
/tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp:748:27: error: expected 
primary-expression before '>' token
   748 | OFIterator it= responses.begin();
   |   ^
/tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp:748:29: error: 'it' was not 
declared in this scope; did you mean 'io'?
   748 | OFIterator it= responses.begin();
   | ^~
   | io


I don't know where OFIterator is supposed to come from, but clearly
something has changed.

Cheers,

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


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001699: gcc/MIPS, gdc defines wrong stat_t for N32 and N64

[YunQiang Su]

Package: src:gcc-10
Version: 10.3.0-13

This problem makes fstat get wrong result, and thus makes gcc-12 ftbfs
on mips64el.

-- 
YunQiang Su


gdc-mips64-stat.patch
Description: Binary data

Bug#1001715: flatpak needs bash-completion as dependency

[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#1001716: src:minimap2: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

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#1001721: pypy3: autopkgtest needs update for new version of setuptools: deprecation warning on stderr

[Paul Gevers]

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#1001724: /usr/bin/firefox is difficult to wrap

[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#1001577: m17n-lib: internal vs external symbols

[Boyuan Yang]

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#1001657: Ball fails its autopkgtest - how to properly deal with sip files?

[Andreas Tille]

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#997845: Your mail

[nick black]

you are correct in all of your assumptions =].


signature.asc
Description: PGP signature

Bug#997845: Your mail

[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#990828: mutt can not delete mails due to access rights

[Kevin J. McCarthy]

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#1001718: astroscrappy breaks ccdproc autopkgtest: detect_cosmics() got an unexpected keyword argument 'pssl'

[Paul Gevers]

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#1001685: mailman: CVE-2021-44227 and updated fix for CVE-2021-42097

[Salvatore Bonaccorso]

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#1001712: [Pkg-opencl-devel] ROCm RFP

[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#1001658: singular: cannot upgrade to 1:4.2.1-p2+ds-3

[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#1001726: node-mqtt-packet breaks node-mqtt-connection autopkgtest: Invalid header flag bits, must be 0x2 for pubrel

[Paul Gevers]

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.

[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#1001728: python-aiohttp breaks dask autopkgtest: 'async_timeout' has no attribute 'Timeout'

[Paul Gevers]

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#1001729: apache-log4j2: CVE-2021-45046: Incomplete fix for CVE-2021-44228 in certain non-default configurations

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

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#1001730: RFH: qdarkstyle

[Boyuan Yang]

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