Bug#1003012: Fixing #1003012 in bullseye (was: Re: Bug#1003012: closed by Salvatore Bonaccorso (Re: Accepted bash 5.1-6 (source) into unstable))

2022-01-07 Thread Salvatore Bonaccorso
Hi Frank,

On Sat, Jan 08, 2022 at 12:27:35AM +0100, Frank Heckenbach wrote:
> Thanks for the quick fix!

Just in avoidance of doubt, thanks goes to Matthias, I just fixed the
BTS metadata as the bug was not closed along with the upload.

> However, it's not clear to me if the fix will go to
> bullseye-security or at least bullseye-updates or only to testing.
> (Is there some way to find this out on the web site or so?)
> 
> I need to know because now I have to either wait for the bullseye
> package or backport it myself, and I'd like to avoid having to do
> both (and thus rebooting my systems twice).

>From a security team perspective, we do not plan to release the fix as
a DSA via the security-archive, but a fix would be welcome to be
included in the next bullseye point release.

Apart the patch "014" for this issue, maybe it makes sense to pick up
as well other of the applied patches (have not looked at the others).

Matthias, would you prepare such an update? TTBOMK the next bullseye
release will be around february 2022, according to the planning of the
release team.

Regards,
Salvatore



Bug#1003319: insighttoolkit5: Use UTC timestamp for build date

2022-01-07 Thread Vagrant Cascadian
Source: insighttoolkit5
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timezone
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build date is embedded in libITKCommon-5.2.so.1:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/insighttoolkit5.html

  
http://www.itk.oThe·URL·of·projeThe·version·at·configuration·tim2021-12-31·08:41The·date·of·conf
 ...
vs.
  
http://www.itk.oThe·URL·of·projeThe·version·at·configuration·tim2022-01-01·10:41The·date·of·conf
 ...


While CMake respects SOURCE_DATE_EPOCH, it still can produce a different
date depending on the timezone of the running system.

Applying the attached patch explicitly sets the timezone to UTC and
should result in a reproducible build for the testing/bookworm suite.

There may be other reproducibility issues caused by changing build path
for sid tests that are not addressed by this patch.


Thanks for maintaining insighttoolkit5!


live well,
  vagrant
From 0b58affa9a5eb82293ce412766b2d0db8077fc23 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 7 Jan 2022 23:39:29 +
Subject: [PATCH 1/3] Modules/Core/Common/src/CMakeLists.txt: Use UTC
 timestamp.

While cmake respects SOURCE_DATE_EPOCH, the timezone may still change
the embedded timestamp used.

https://reproducible-builds.org/docs/source-date-epoch/
---
 Modules/Core/Common/src/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Modules/Core/Common/src/CMakeLists.txt b/Modules/Core/Common/src/CMakeLists.txt
index 774a164d..1486c670 100644
--- a/Modules/Core/Common/src/CMakeLists.txt
+++ b/Modules/Core/Common/src/CMakeLists.txt
@@ -8,7 +8,7 @@ if( GIT_LOCAL_MODIFICATIONS MATCHES ".*files changed.*")
set(GIT_LOCAL_MODIFICATIONS " (with uncommitted code modifications ${GIT_LOCAL_MODIFICATIONS} )")
 endif()
 
-string(TIMESTAMP CONFIGURE_DATE "%Y-%m-%d %H:%M")
+string(TIMESTAMP CONFIGURE_DATE "%Y-%m-%d %H:%M" UTC)
 
 ## MAKE_MAP_ENTRY is a macro to facilitate placing items in the itk::BuildInformation class
 ##/--_---_-/
-- 
2.34.1



signature.asc
Description: PGP signature


Bug#1003318: agda: Please package agda 2.6.2.1

2022-01-07 Thread Samuel Mimram
Package: agda
Version: 2.6.1-1
Severity: wishlist
X-Debbugs-Cc: smim...@gmail.com

It would be nice if you could package the latest upstream version (2.6.2.1 at
the time of writing). The currently packaged version is almost 2 years old and
many useful improvements have ben brought since then.

Thanks!


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

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

Versions of packages agda depends on:
ii  agda-bin 2.6.1-1+b3
ii  agda-stdlib  1.3-2
ii  agda-stdlib-doc  1.3-2
ii  elpa-agda2-mode  2.6.1-1
ii  libghc-agda-dev  2.6.1-1+b3

agda recommends no packages.

agda suggests no packages.

-- no debconf information



Bug#991378: This bug is still alive

2022-01-07 Thread Karl Schmidt

On 1/7/22 9:31 PM, Michael Stone wrote:

agreed, someone should fix xdg-desktop-portal to not cause errors

Ok - now I'm really confused..

My digging had me looking at fuse3?

I don't see such open bug in xdg-desktop-portal  ?


I saw this crop up when I did a sshfs mount..

df hinted at the strange /root/.cache directoy -

I thought it was due to the /root/.cache/doc/by-app directory - which has 
nothing in it - can't be deleted.

I figured it was in use - but lsof can't see it.

lsof: WARNING: can't stat() fuse.portal file system /run/user/1001/doc
  Output information may be incomplete.

$ ll /run/user/1001/

returns

d? ? ??  ?? doc/

Finally the error lsof gave me had me look for a bad mount - but unmounting the 
sshfs mount does not make it go away.

Ahh . It was a second mount at /run/user/1001/doc

I was able to get back to normal with:
$ umount /run/user/1001/doc

- so once gone - I tried to recreate - turns out it is not the sshfs mount - it 
is

$ pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY meld

That creates the mess -- pkexec is part of policykit-1

Don't see any such bugs.. hope these breadcrumbs help someone.




Karl Schmidt  EMail k...@lrak.net



Bug#1003316: python-cooler: reproducible builds: tests tarball includes file mode and timestamps

2022-01-07 Thread Vagrant Cascadian
Source: python-cooler
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The generated tarball /usr/share/doc/python3-cooler/tests.tar.xz
includes the file mode and timestamp of the archived files:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/python-cooler.html

  drwxr-xr-x ... 2023-02-03·11:19:21.00·tests/
vs.
  drwxrwxr-x ... 2022-01-01·05:00:28.00·tests/


The attached patch fixes this by passing the --mode and --mtime
arguments to the tar command used in debian/rules.


Thanks for maintaining python-cooler!


live well,
  vagrant
From 937dcde974e616b7d96592db3d38e66cc364f60f Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 8 Jan 2022 05:12:21 +
Subject: [PATCH] debian/rules: Pass --mtime and --mode arguments to tar for
 example tests tarball.

https://reproducible-builds.org/docs/archives/
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index efbc531..3d40ce9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,4 +9,4 @@ export PYBUILD_NAME=cooler
 
 override_dh_installexamples:
 	dh_installexamples
-	cd debian/python3-$(PYBUILD_NAME)-examples/usr/share/doc/python3-$(PYBUILD_NAME) && tar --create --owner=0 --group=0 --numeric-owner --sort=name --file tests.tar.xz tests && rm -rf tests
+	cd debian/python3-$(PYBUILD_NAME)-examples/usr/share/doc/python3-$(PYBUILD_NAME) && tar --create --owner=0 --group=0 --numeric-owner --sort=name --mtime="@$(SOURCE_DATE_EPOCH)" --mode=u=wrX,og=rX --file tests.tar.xz tests && rm -rf tests
-- 
2.30.2



signature.asc
Description: PGP signature


Bug#991378: This bug is still alive

2022-01-07 Thread Michael Stone

agreed, someone should fix xdg-desktop-portal to not cause errors

On Fri, Jan 07, 2022 at 07:05:09PM -0600, you wrote:

It breaks the df command and rf command - both return unhelpful error messages 
- breaks scrips that use df..

Putting a mount point in /root/.cache  was never a good idea - not where they 
belong (breaks the FHS standard)

Adds confusion to users - something in a cache should be delete-able - 
this creates what looks like an empty directory that one can not 
delete.


Not able to install fuse3 from testing as it wants to remove libc-bin..

Stable needs an update.

I think this should have severity: critical as it breaks unrelated 
software? - or at the very least 'serious' as if violates a few of the 
must and required directives?



--

Karl Schmidt  EMail k...@lrak.net
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049

Google is the camel's nose.
-kps





Bug#1003315: ITP: yosys-plugin-ghdl -- VHDL to RTL synthesis plugin using GHDL

2022-01-07 Thread Daniel Gröber
Package: wnpp
Severity: wishlist
Owner: Daniel Gröber 
X-Debbugs-Cc: debian-de...@lists.debian.org, d...@darkboxed.org

* Package name: yosys-plugin-ghdl
  Version : 0.0~git20211127.09a32cd
  Upstream Author : Tristan Gingold 
* URL : https://github.com/ghdl/ghdl-yosys-plugin/
* License : GPLv3+
  Programming Lang: C++
  Description : VHDL to RTL synthesis plugin using GHDL

This yosys plugin allows running RTL synthesis from VHDL source code
instead of yosys' native Verilog.

This allows a full synthesis flow from VHDL to hardware for FPGAs where
the GHDL compiler is used to analyse the VHDL sources and yosys is used to
perform the convertion to netlist format with only free software tools
already in Debian (together with yosys and nextpnr/arachne-pnr).

--Daniel


Bug#1003233: numpy: Please move the BD needed to build the -doc package to Build-Depends-Indep

2022-01-07 Thread Sandro Tosi
control: tags -1 +moreinfo

> There are a lot of build dependencies that are marked with the !nodoc
> profile
>
> Shouldn't all of these be moved to Build-Depends-Indep instead?

what would be the advantage of complicating build dependencies setup
in d/control? i'd rather optimize for developer time (mine) than for
resource-constrained machines.

> That should reduce the package pulled by the buildd

has that caused any problem? from what i can see numpy builds just
fine on all architectures (where it can build) so none of the buildds
have issues building it and there's no benefit in changing how build
dependencies are installed

> (and also make the
> package easier to bootstrap on new ports)

isnt that the entire purposes of build profiles?

for now my answer is "there's nothing to change" and close this bug,
but i want to hear more

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



Bug#992592: lightdm does not start / work any more after system upgrade

2022-01-07 Thread 肖盛文

If you want use nodm, only run apt-get install nodm in enough.

lightdm and nodm can co-exist in the same machine.

When install nodm after lightdm, It'll display a prompt let user choise 
"Default display manager".


You may choice nodm to use.


在 2022/1/8 01:00, Karsten Malcher 写道:

There seems no solution in sight.

When there is only one user that can be automatically logged in the 
nodm display manager can solve the problem.


Use:
agt-get purge lightdm


I do not agree use this command directly, this will cause dark screen 
and back to tty.


My wireless network connection is also down, (My notebook use Xfce)

so I can't install nodm use apt in the next.



apget install nodm

Best regards
karsten


--
肖盛文 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#912682: e: Bug#912682: usefulness of this package?g

2022-01-07 Thread gregor herrmann
On Thu, 06 Jun 2019 10:56:07 +0100, Dominic Hargreaves wrote:

> Per our new policy[1], we'll remove this after July if no new
> upstream update appears.
> [1] 

Looks like this hasn't happened :)

I came to this bug as ExtUtils::ParseXS 3.44 was released yesterday.

So the current situation is:

We have libextutils-parsexs-perl 3.35-1 in unstable.

For ExtUtils::ParseXS in perl core we have

  v5.32.13.40  
…
  v5.34.03.43  
  v5.35.03.43  
  v5.35.13.43  
  v5.35.23.43  
  v5.35.33.43  
  v5.35.43.44  
  v5.35.53.44  
  v5.35.63.44  
  v5.35.73.44  

This means we could upload 3.44() to unstable, and after the
transition to 5.34 this would still be ok, and after the migration to
5.36 in a couple of months we'd be in the same situation as now.

If I understand it correctly, ExtUtils::ParseXS is one of those
dual-lifed modules which are primarily maintained in perl core, and
then also released to the CPAN (ideally when a new perl is releaesed,
right now a couple of months later), which means that there probably
won't by any release where CPAN precedes perl core.

If this understanding is correct, than keeping libextutils-parsexs-perl
as a separate package doesn't make a lot of sense (it will only be
newer in the window between new upstream perl releases and our
migrations in Debian), and I propose to remove it.


Cheers,
gregor

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


signature.asc
Description: Digital Signature


Bug#1002326: python-schema-salad: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

2022-01-07 Thread Sandro Tosi
> E   AttributeError: module 'mistune' has no attribute 'Renderer'
> _ ERROR collecting 
> .pybuild/cpython3_3.9_schema-salad/build/schema_salad/tests/test_errors.py _
> schema_salad/tests/test_errors.py:4: in 
> import schema_salad.main
> schema_salad/main.py:19: in 
> from .makedoc import makedoc
> schema_salad/makedoc.py:60: in 
> class MyRenderer(mistune.Renderer):
> E   AttributeError: module 'mistune' has no attribute 'Renderer'
> _ ERROR collecting 
> .pybuild/cpython3_3.9_schema-salad/build/schema_salad/tests/test_examples.py _
> schema_salad/tests/test_examples.py:10: in 
> import schema_salad.main
> schema_salad/main.py:19: in 
> from .makedoc import makedoc
> schema_salad/makedoc.py:60: in 
> class MyRenderer(mistune.Renderer):
> E   AttributeError: module 'mistune' has no attribute 'Renderer'

another victim of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001591

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



Bug#991378: This bug is still alive

2022-01-07 Thread Karl Schmidt

It breaks the df command and rf command - both return unhelpful error messages 
- breaks scrips that use df..

Putting a mount point in /root/.cache  was never a good idea - not where they 
belong (breaks the FHS standard)

Adds confusion to users - something in a cache should be delete-able - this creates what looks like an empty directory 
that one can not delete.


Not able to install fuse3 from testing as it wants to remove libc-bin..

Stable needs an update.

I think this should have severity: critical as it breaks unrelated software? - or at the very least 'serious' as if 
violates a few of the must and required directives?



--

Karl Schmidt  EMail k...@lrak.net
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049

 Google is the camel's nose.
 -kps




Bug#1000593: Failing testsuite with PHP 8.1

2022-01-07 Thread Bryce Harrington
These tests fail due to changes in how objects are dumped, like the
ordering of members.  This seems to just be a formatting discrepancy.
Presumably the logical fix is to revise the expected output to match the
new output formatting style, or alternatively just disable the three
test cases until upstream has a chance to update to latest versions of
php, et al.

Bryce



Bug#1000650: Possible patch

2022-01-07 Thread Bryce Harrington
I reproduced these failures in Ubuntu, and found they're fixed by this
recently introduced upstream commit:


https://github.com/sebastianbergmann/phploc/commit/c21b0521f0d87ddc328b62dccafe2f90b62cfbe3.patch

HTH,
Bryce



Bug#1003314: orthanc package: startlimitburst too low

2022-01-07 Thread Gerald Wiese
Package: orthanc

Version: 1.9.2.+really1.9.1+dfsg-1

When installing Orthanc inside my Ansible scripts the following problem occurs: 
Every package orthanc-* triggers a
systemd service restart and if there are a couple of orthanc extensions the 
StartLimitBurst is reached. This can be
fixed by including "StartLimitBurst=10" in orthanc.service.


Reproduce:

$ sudo apt install -y git ansible

$ ansible-galaxy collection install community.general community.crypto

$ git clone https://gitlab.com/geraldwiese/gnuhealth-automatic-deployment.git

$ cd gnuhealth-automatic-deployment/

In orthanc/installation.yml delete lines 1-12 in order to disable my workaround

In orthanc/vault: set 'vault_ssh_user' to OS user and 'use_ssh_pw_for_sudo' to 
false

$ ansible-playbook orthanc.yml -c local -K


Unfortunately I can't copy the error message from the VM but the important part 
is probably "orthanc.service: Start
request repeated too quickly".

Running Debian 11 and Ansible 2.10.8


This problem does not occure on Ubuntu, but there the version of orthanc seems 
to be 1.5.8+dfsg-2ubuntu6

Could you please tell me if I am overlooking something or if I'm right and it's 
possible to increase the StartLimitBurst
in the shipped files?


Kind regards

Gerald



Bug#928300: secure boot via removable media path unavailable

2022-01-07 Thread Timo van Roermund

Dear Chris, Steve,

Was there any further follow-up on this issue?

It seems that I've got pretty much the same situation here on an Intel 
DB75EN motherboard.


Regarding the keys, pretty much the same situation:

- same keys/content in the secure boot signature store (db)
- similar contents in the secure boot blacklist signature store (dbx) -- 
I have the same first entry, only the 2nd and 3rd are missing

- same keys/content in the Key Exchange Key Signature database (KEK)
- but I have no public Platform Key (PK) installed

The (literal) output on the screen is:

        Image Authorization Fail.
        System can not boot to this device due to Security Violation.

    Press Enter key to continue.

Thanks in advance,

Timo



Bug#1003313: libgpg-error FTCBFS for musl: refuses to use generic lock object detection

2022-01-07 Thread Helmut Grohne
Source: libgpg-error
Version: 1.43-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

A while ago, libgpg-error gained a feature that enabled configure to
introspect lock objects without running code (via objdump).
Unfortunately, this code is only used for glibc. When cross building for
e.g. musl, it falls back to the old way where you'd have to collect the
results. And since those aren't collected, it fails. The objdump trick
should work on all Linux systems regardless of the C library in used.
That's also what the VoidLinux people think:
https://github.com/void-linux/void-packages/commit/429ac8a534d4e1fffc0c7f5df47a4f4ac67fa2cd
So please consider applying it here as well. I'm attaching the relevant
hunk.

Helmut
--- a/configure.ac
+++ b/configure.ac
@@ -605,7 +605,7 @@
   AC_MSG_NOTICE([generated src/lock-obj-pub.native.h for $host])
 elif test x$cross_compiling = xyes; then
   case $host in
-*-*-linux-gnu*)
+*-*-linux-*)
 AC_CHECK_TOOL(OBJDUMP, [objdump])
 if test -n "$OBJDUMP"; then
   lock_obj_h_generated=yes


Bug#1003012: closed by Salvatore Bonaccorso (Re: Accepted bash 5.1-6 (source) into unstable)

2022-01-07 Thread Frank Heckenbach
Thanks for the quick fix!

However, it's not clear to me if the fix will go to
bullseye-security or at least bullseye-updates or only to testing.
(Is there some way to find this out on the web site or so?)

I need to know because now I have to either wait for the bullseye
package or backport it myself, and I'd like to avoid having to do
both (and thus rebooting my systems twice).

Frank



Bug#1003312: gqrx-sdr, apparent leftover build-dependency on gr-iio

2022-01-07 Thread peter green

Package: gqrx-sdr
Version: 2.14.6-1

I noticed that gqrx-sdr build-depends on gr-iio (which FTBFS in testing/unstable
and is built against an old version of gnuradio), but there is no corresponding
runtime dependency and the only mentions of iio in the build log are the
installation of build-dependencies and the generation of the buildinfo file.

I did a test build with the build-dependency on gr-iio removed and it built
successfully. So it looks to me like this build-dependency should just be 
removed.



Bug#1003311: ndpi FTCBFS: configures twice. first invocation lacks cross flags

2022-01-07 Thread Helmut Grohne
Source: ndpi
Version: 4.0-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ndpi fails to cross build from source, because it configures for the
build architecture. It actually attempts to configure twice. Once via
autogen.sh and another time via dh_auto_configure. The latter one would
work in theory if the first one didn't fail already. The obvious
solution is skipping the first invocation. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru ndpi-4.0/debian/changelog ndpi-4.0/debian/changelog
--- ndpi-4.0/debian/changelog   2021-09-25 22:04:56.0 +0200
+++ ndpi-4.0/debian/changelog   2022-01-06 16:43:22.0 +0100
@@ -1,3 +1,10 @@
+ndpi (4.0-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCFBS: Don't configure during autogen.sh. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 06 Jan 2022 16:43:22 +0100
+
 ndpi (4.0-4) unstable; urgency=medium
 
   * Team upload
diff --minimal -Nru ndpi-4.0/debian/patches/cross.patch 
ndpi-4.0/debian/patches/cross.patch
--- ndpi-4.0/debian/patches/cross.patch 1970-01-01 01:00:00.0 +0100
+++ ndpi-4.0/debian/patches/cross.patch 2022-01-06 16:43:22.0 +0100
@@ -0,0 +1,14 @@
+--- ndpi-4.0.orig/autogen.sh
 ndpi-4.0/autogen.sh
+@@ -56,8 +56,10 @@
+ autoreconf -ivf
+ cat configure | sed "s/#define PACKAGE/#define NDPI_PACKAGE/g" | sed 
"s/#define VERSION/#define NDPI_VERSION/g"  > configure.tmp
+ cat configure.tmp > configure
++chmod +x configure
++
++test "x${NO_CONFIGURE:-}" = x || exit 0
+ 
+ echo "./configure $@"
+-chmod +x configure
+ ./configure $@
+ 
diff --minimal -Nru ndpi-4.0/debian/patches/series 
ndpi-4.0/debian/patches/series
--- ndpi-4.0/debian/patches/series  2021-09-25 21:57:57.0 +0200
+++ ndpi-4.0/debian/patches/series  2022-01-06 16:41:59.0 +0100
@@ -5,3 +5,4 @@
 system-uthash.patch
 fix-unaligned-memory-accesses-with-get_u_int64_t-at-armhf.patch
 use-get_u_int64_t-to-avoid-unaligned-memory-access-at-armhf.patch
+cross.patch
diff --minimal -Nru ndpi-4.0/debian/rules ndpi-4.0/debian/rules
--- ndpi-4.0/debian/rules   2021-09-25 22:03:13.0 +0200
+++ ndpi-4.0/debian/rules   2022-01-06 16:43:22.0 +0100
@@ -19,7 +19,7 @@
dh $@
 
 override_dh_auto_configure:
-   ./autogen.sh
+   NO_CONFIGURE=1 ./autogen.sh
dh_auto_configure -- --prefix=/usr
 
 override_dh_auto_test:


Bug#1003310: soundmodem FTCBFS for architectures other than i686-pc-cygwin

2022-01-07 Thread Helmut Grohne
Source: soundmodem
Version: 0.20-6
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

soundmodem fails to cross build from source, because its configure
script thinks that cross building means building for i686-pc-cygwin, but
there are many other architectures. It also thinks that during cross
building, pkg-config doesn't work, which happens to be the think that
just works on Debian. I'm attaching a patch to extend the cross build
support upstream. Please consider applying it.

Helmut
--- soundmodem-0.20.orig/configure.ac
+++ soundmodem-0.20/configure.ac
@@ -32,7 +32,7 @@
 AC_OBJEXT
 
 dnl check for cross compiler path
-if test x$cross_compiling = xyes; then
+if test x$cross_compiling = xyes && test "x$host_alias" = i686-pc-cygwin; then
   AC_MSG_CHECKING(for cross compiler path)
   if test -d /usr/local/cross/i686-pc-cygwin; then
 CROSSCOMPPATH=/usr/local/cross/i686-pc-cygwin
@@ -137,25 +137,28 @@
   LIBS="$LIBS -ldsound -lgdi32"
 fi
 
-if test x$cross_compiling = xyes; then
-  gtk=no
-  xlibs="$LIBS"
-  LIBS="$LIBS -L$CROSSCOMPPATH/gtk/lib"
-  AC_CHECK_LIB(gtk,gtk_main,gtk=yes)
-  LIBS="$xlibs"
-  if test x$gtk = xyes; then
-GTK_CFLAGS="-I$CROSSCOMPPATH/gtk/include -I$CROSSCOMPPATH/gtk/include/glib -I$CROSSCOMPPATH/gtk/include/gdk"
-GTK_LIBS="-L$CROSSCOMPPATH/gtk/lib -lgtk -lgdk -lglib"
-PTHREAD_CFLAGS="-I$CROSSCOMPPATH/gtk/include"
-PTHREAD_LIBS="-L$CROSSCOMPPATH/gtk/lib"
+PKG_CHECK_MODULES([GTK],[gtk+-2.0 >= 2.6.0],,[
+  if test x$cross_compiling = xyes; then
+gtk=no
+xlibs="$LIBS"
+LIBS="$LIBS -L$CROSSCOMPPATH/gtk/lib"
+AC_CHECK_LIB(gtk,gtk_main,gtk=yes)
+LIBS="$xlibs"
+if test x$gtk = xyes; then
+  GTK_CFLAGS="-I$CROSSCOMPPATH/gtk/include -I$CROSSCOMPPATH/gtk/include/glib -I$CROSSCOMPPATH/gtk/include/gdk"
+  GTK_LIBS="-L$CROSSCOMPPATH/gtk/lib -lgtk -lgdk -lglib"
+  PTHREAD_CFLAGS="-I$CROSSCOMPPATH/gtk/include"
+  PTHREAD_LIBS="-L$CROSSCOMPPATH/gtk/lib"
+fi
+  fi
+])
+PKG_CHECK_MODULES([XML],[libxml-2.0])
+PKG_CHECK_MODULES([AUDIOFILE],[audiofile],,[
+  if test x$cross_compiling = xyes && test "x$GTK_LIBS" != x; then
 AUDIOFILE_CFLAGS="-I$CROSSCOMPPATH/audiofile/include"
 AUDIOFILE_LIBS="-L$CROSSCOMPPATH/audiofile/lib -laudiofile"
   fi
-else
-  PKG_CHECK_MODULES(XML,libxml-2.0)
-  PKG_CHECK_MODULES(GTK,gtk+-2.0 >= 2.6.0)
-  PKG_CHECK_MODULES(AUDIOFILE,audiofile)
-fi
+])
 
 dnl Check for recently introduced GTK symbols
 xlibs="$LIBS"


Bug#1003309: vdr-plugin-streamdev FTBFS: error: invalid conversion from ‘cChannel*’ to ‘int’

2022-01-07 Thread Helmut Grohne
Source: vdr-plugin-streamdev
Version: 0.6.1+git20180514-4
Severity: serious
Tags: ftbfs

vdr-plugin-streamdev fails to build from source in unstable on amd64. A
non-parallel build now ends as follows:

| g++ -g -O2 -ffile-prefix-map=/build/vdr-dx7twj/vdr-2.6.0=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -D_GNU_SOURCE 
-DPLUGIN_NAME_I18N='"streamdev-server"' -I/include -I.. -o connectionVTP.o 
connectionVTP.c
| connectionVTP.c: In member function ‘bool cConnectionVTP::CmdMOVC(const 
char*)’:
| connectionVTP.c:1885:108: error: invalid conversion from ‘cChannel*’ to ‘int’ 
[-fpermissive]
|  1885 |   
  cDevice::SetCurrentChannel(CurrentChannel);
|   |   
 ^~
|   |   
 |
|   |   
 cChannel*
| In file included from /usr/include/vdr/dvbdevice.h:15,
|  from /usr/include/vdr/menuitems.h:14,
|  from /usr/include/vdr/plugin.h:14,
|  from ../common.h:15,
|  from ../server/connection.h:9,
|  from ../server/connectionVTP.h:4,
|  from connectionVTP.c:5:
| /usr/include/vdr/device.h:366:37: note:   initializing argument 1 of ‘static 
void cDevice::SetCurrentChannel(int)’
|   366 |   static void SetCurrentChannel(int ChannelNumber) { currentChannel = 
ChannelNumber; }
|   | ^
| connectionVTP.c: In member function ‘bool cConnectionVTP::CmdDELC(const 
char*)’:
| connectionVTP.c:1986:84: error: invalid conversion from ‘cChannel*’ to ‘int’ 
[-fpermissive]
|  1986 | 
cDevice::SetCurrentChannel(CurrentChannel);
|   |   
 ^~
|   |   
 |
|   |   
 cChannel*
| In file included from /usr/include/vdr/dvbdevice.h:15,
|  from /usr/include/vdr/menuitems.h:14,
|  from /usr/include/vdr/plugin.h:14,
|  from ../common.h:15,
|  from ../server/connection.h:9,
|  from ../server/connectionVTP.h:4,
|  from connectionVTP.c:5:
| /usr/include/vdr/device.h:366:37: note:   initializing argument 1 of ‘static 
void cDevice::SetCurrentChannel(int)’
|   366 |   static void SetCurrentChannel(int ChannelNumber) { currentChannel = 
ChannelNumber; }
|   | ^
| make[2]: *** [Makefile:39: connectionVTP.o] Error 1
| make[2]: Leaving directory '/<>/server'
| make[1]: *** [Makefile:80: server] Error 2
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j1 "INSTALL=install --strip-program=true" 
returned exit code 2
| make: *** [debian/rules:9: build] Error 25
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut



Bug#1003308: /usr/bin/cvsconvert: cvsconvert handling of absolute paths

2022-01-07 Thread Ian Jackson
Package: cvs-fast-export
Version: 1.59-1
Severity: normal
File: /usr/bin/cvsconvert
Tags: newcomer

Steps to reproduce:

  $ cd
  $ rm -rf d
  $ mkdir d
  $ cd d
  $ mkdir repo
  $ cvs -d $PWD/repo init
  $ mkdir repo/module
  $ export CVSROOT=$PWD/repo
  $ mkdir working
  $ cd working
  $ cvs co module
  cvs checkout: Updating module
  $ cd module
  $ echo hi >file
  $ cvs add file
  cvs add: scheduling file `file' for addition
  cvs add: use `cvs commit' to add this file permanently
  $ cvs ci -m 'add file'
  cvs commit: Examining .
  /home/ian/d/repo/module/file,v  <--  file
  initial revision: 1.1
  $ cd ~/d
  $ find /home/ian/d/repo/module
  /home/ian/d/repo/module
  /home/ian/d/repo/module/file,v
  $ cvsconvert /home/ian/d/repo/module 

Observed behaviour:

  cvsconvert: repo  does not exist.

Expected behaviour:

  Either an error message saying only relative paths are supported,
  or correct functioning.

Additional notes:

  Providing the relative path didn't work for me either with a
  different error.  I'm not sure if this ought to be another bug:

  $ cvsconvert repo/module
  fatal: You are on a branch yet to be born
  cvsconvert: cat repo-module.git.fi | (cd repo-module-git >/dev/null; git 
fast-import --quiet --done && git checkout) returned 128.

I first experienced this with the version in buster, 1.44-1, which was
able to handle the repo I needed to convert.  I have repro'd this in a
sid schroot.

In practice, I think probably *fixing* this will be rather hard but it
is probably easy to improve the error message.  For now I am reporting
this bug, if for no other reason than to help the next user.

Thanks,
Ian.

-- System Information:
Debian Release: 10.11
  APT prefers oldstable-debug
  APT policy: (500, 'oldstable-debug'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 5.10.0-0.bpo.9-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages cvs-fast-export depends on:
ii  libc6   2.28-10
ii  python  2.7.16-1

Versions of packages cvs-fast-export recommends:
ii  cvs  2:1.12.13+real-27
ii  git  1:2.20.1-2+deb10u3
ii  reposurgeon  3.45-1
ii  rsync3.1.3-6

Versions of packages cvs-fast-export suggests:
pn  bzr-fastimport  
pn  rcs 

-- no debconf information



Bug#894081: Libvirt debug symbols not available for latest version

2022-01-07 Thread Mike Hommey
On Thu, Mar 05, 2020 at 04:12:48PM +0100, Andreas Oberritter wrote:
> On Tue, 15 May 2018 11:17:24 +0800 Paul Wise  wrote:
> > Control: retitle -1 security.debian.org: please publish dbgsym packages
> > 
> > On Tue, 27 Mar 2018 14:11:28 +0300 Mathieu Tarral wrote:
> > 
> > > But the reason i couldn't find them is that proposed-upates-debug is not 
> > > listed
> > > on the Wiki:
> > > https://wiki.debian.org/AutomaticDebugPackages#Status
> > 
> > Fixed:
> > 
> > https://wiki.debian.org/AutomaticDebugPackages?action=diff=29=30
> > 
> > I heard that the security archive saves dbgsym packages but does not
> > publish them anywhere. Retitling the bug to reflect that.
> 
> This bug has been idle for almost two years. Is anybody still working on it?
> 
> Just wanted to point out that not every package can be found in 
> proposed-updates-debug.
> There don't seem to be dbgsym packages for php 7.3.14-1~deb10u1, for example, 
> which keeps me from debugging a segfault.

Almost two more years have passed, and I have the same problem with
firefox-esr 91.4.1esr-1~deb11u1.

Mike



Bug#1003307: restfuldb: FTBFS against sqlite3 3.37 or newer

2022-01-07 Thread Dan Bungert
Package: restfuldb
Version: 0.15.2+dfsg-2
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy

Dear Maintainer,

This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/1956798

When built against sqlite 3.37 or newer, the build will fail in test.
Example:
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/r/restfuldb/20220107_080256_a18a5@/log.gz
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/restfuldb/17950775/log.gz

tests/cases/Database.pm_001.sh:FAILED:
2c2
<   'image' => 'blob'
---
>   'image' => 'BLOB'

+many more of a similar nature.

As of sqlite 3.37.0, with FossilOrigin-Name:
d2da62a9df63036b02dadca3798de9e623c2680b3ef0c37d2b18bb88693afd7f,
type names for 5 common types BLOB, INT, INTEGER, REAL, and TEXT will be
treated as if they were created in all uppercase.

My proposed workaround is the following.  Due to the nature of the tests, any
sort of fixes to the test would in my opinion be best done upstream.

--- restfuldb-0.15.2+dfsg.orig/Makefile
+++ restfuldb-0.15.2+dfsg/Makefile
@@ -103,7 +103,7 @@ define can_run_test
 endef

 define diff_outputs
-diff -I 'Expires:\|Date:' ${OUTP_DIR}/$*.out -
+diff -i -I 'Expires:\|Date:' ${OUTP_DIR}/$*.out -
 endef

 define report_differences

-Dan



Bug#1003305: ruby-sqlite3: FTBFS against sqlite3 3.37 or newer

2022-01-07 Thread Dan Bungert
Package: ruby-sqlite3
Version: 1.4.2-3build1
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy

Dear Maintainer,

This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/1956796
The description, from Dan Bungert, follows:

When built against sqlite 3.37 or newer, the build will fail in test. 
Examples:
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/r/ruby-sqlite3/20220107_075823_1a1f3@/log.gz
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/ruby-sqlite3/17951708/log.gz

TC_ResultSet#test_types 
[/tmp/autopkgtest.J0NEKT/build.hEV/src/test/test_integration_resultset.rb:121]:
Expected: ["integer", "text"]
  Actual: ["INTEGER", "TEXT"]

+2 more failures of a similar nature.

As of sqlite 3.37.0, with FossilOrigin-Name:
d2da62a9df63036b02dadca3798de9e623c2680b3ef0c37d2b18bb88693afd7f,
type names for 5 common types BLOB, INT, INTEGER, REAL, and TEXT will be
treated as if they were created in all uppercase.

See attached for my proposed change for Ubuntu to address the test failures.

-Dan
diff -Nru ruby-sqlite3-1.4.2/debian/changelog 
ruby-sqlite3-1.4.2/debian/changelog
--- ruby-sqlite3-1.4.2/debian/changelog 2021-12-03 15:07:08.0 -0700
+++ ruby-sqlite3-1.4.2/debian/changelog 2022-01-07 14:15:57.0 -0700
@@ -1,3 +1,9 @@
+ruby-sqlite3 (1.4.2-3ubuntu1) jammy; urgency=medium
+
+  * Adjust tests for compatibility with sqlite 3.37.0 or newer (LP: #1956796)
+
+ -- Dan Bungert   Fri, 07 Jan 2022 14:15:57 -0700
+
 ruby-sqlite3 (1.4.2-3build2) jammy; urgency=medium
 
   * No-change upload due to ruby3.0 transition, remove ruby2.7 support.
diff -Nru ruby-sqlite3-1.4.2/debian/control ruby-sqlite3-1.4.2/debian/control
--- ruby-sqlite3-1.4.2/debian/control   2021-02-09 15:26:09.0 -0700
+++ ruby-sqlite3-1.4.2/debian/control   2022-01-07 14:15:57.0 -0700
@@ -1,7 +1,8 @@
 Source: ruby-sqlite3
 Section: ruby
 Priority: optional
-Maintainer: Debian Ruby Team 

+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Debian Ruby Team 

 Uploaders: Dmitry Borodaenko 
 Build-Depends: debhelper-compat (= 13),
gem2deb (>= 1),
diff -Nru ruby-sqlite3-1.4.2/debian/patches/series 
ruby-sqlite3-1.4.2/debian/patches/series
--- ruby-sqlite3-1.4.2/debian/patches/series2021-02-09 14:22:28.0 
-0700
+++ ruby-sqlite3-1.4.2/debian/patches/series2022-01-06 17:05:49.0 
-0700
@@ -1,2 +1,3 @@
 use-slugs-in-faq.diff
 drop-vendorizing-tasks.patch
+type-case.patch
diff -Nru ruby-sqlite3-1.4.2/debian/patches/type-case.patch 
ruby-sqlite3-1.4.2/debian/patches/type-case.patch
--- ruby-sqlite3-1.4.2/debian/patches/type-case.patch   1969-12-31 
17:00:00.0 -0700
+++ ruby-sqlite3-1.4.2/debian/patches/type-case.patch   2022-01-07 
14:15:56.0 -0700
@@ -0,0 +1,77 @@
+Description: Use uppercase types for test
+ As of sqlite 3.37.0, with FossilOrigin-Name:
+ d2da62a9df63036b02dadca3798de9e623c2680b3ef0c37d2b18bb88693afd7f,
+ type names for 5 common types BLOB, INT, INTEGER, REAL, and TEXT will be
+ treated as if they were created in all uppercase.  This patch does two things
+ about this:
+ 1) Adjust expected types to upper case, as that will always be what newer
+ sqlite actually does for these 5 types
+ 2) adjust created tables to use upper case type names, so that pre-3.37 sqlite
+ uses the type name strings expected by the tests
+Author: Dan Bungert 
+Bug-Ubuntu: https://launchpad.net/bugs/1956796
+Forwarded: https://github.com/sparklemotion/sqlite3-ruby/pull/304 ; PR comment
+Last-Update: 2022-01-07
+--- a/test/test_database.rb
 b/test/test_database.rb
+@@ -268,12 +268,12 @@
+ 
+ def test_table_info
+   db = SQLite3::Database.new(':memory:', :results_as_hash => true)
+-  db.execute("create table foo ( a integer primary key, b text )")
++  db.execute("create table foo ( a INTEGER primary key, b TEXT )")
+   info = [{
+ "name"   => "a",
+ "pk" => 1,
+ "notnull"=> 0,
+-"type"   => "integer",
++"type"   => "INTEGER",
+ "dflt_value" => nil,
+ "cid"=> 0
+   },
+@@ -281,7 +281,7 @@
+ "name"   => "b",
+ "pk" => 0,
+ "notnull"=> 0,
+-"type"   => "text",
++"type"   => "TEXT",
+ "dflt_value" => nil,
+ "cid"=> 1
+   }]
+--- a/test/test_integration.rb
 b/test/test_integration.rb
+@@ -34,11 +34,11 @@
+ 
+   def test_table_info_without_defaults_for_version_3_3_8_and_higher
+ @db.transaction do
+-  @db.execute "create table no_defaults_test ( a integer default 1, b 
integer )"
++  @db.execute "create table no_defaults_test ( a INTEGER default 1, b 
INTEGER )"
+   data = @db.table_info( "no_defaults_test" )
+-  assert_equal({"name" => "a", "type" => "integer", "dflt_value" => "1", 
"notnull" => 0, "cid" => 0, "pk" => 0},
++  assert_equal({"name" => "a", "type" => 

Bug#1000966: amdgpu: output to VR headset fails with "*ERROR* dc_stream_state is NULL for crtc '1'!"

2022-01-07 Thread Claire
I have reproduced the issue on upstream source, identified the commit causing
the regression, and submitted the bug upstream: 
https://gitlab.freedesktop.org/drm/amd/-/issues/1856



Bug#997736: Chiming in..

2022-01-07 Thread Martina Ferrari

Hi,

Sorry for being late to the party here..
(Thanks to Myon for pinging me about this today)

So, it seems that my solution to this issue was not understood. It is 
*expected* (and wanted!) that tests would start failing as soon as a new 
tzdata release is uploaded. The solution is just to create a new source 
package version with no changes, just including the version of the olson 
DB in the moment-timezone debian revision:


Debian package revision (D): 1
Olson database version (TZVER): 2021a
Moment-timezone upstream version (U): 0.5.32
Mangled version after repackaging (U+dfsg): 0.5.32+dfsg
moment-timezone.js full version (U+dfsg1-D+TZVER): 0.5.32+dfsg-1+2021a

I am now uploading a new revision that fixes this.

--
Martina Ferrari (Tina)



Bug#1003304: debsigs uses a predictable /tmp directory name

2022-01-07 Thread Todd C. Miller
Package: debsigs
Version: 0.1.25
Severity: normal
Tags: patch

Dear Maintainer,

When debsigs creates its temporary directory, it just uses
"/tmp/debsigndeb.$$" where "$$" is the process ID.  Using a predictable
temporary file name can be a security issue if an attacker is able to
create the path first.  However, Since debsig uses a temporary directory,
not a file, only a denial of service attack is possible.

It would be safer to use the built-in mkdtemp() function when creating
the temporary directory, which creates a random name and will retry
as needed if the chose name already exists.

The attached fix is also in gitlab as:
https://gitlab.com/debsigs/debsigs/-/merge_requests/2

 - todd

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 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 debsigs depends on:
ii  binutils  2.35.2-2
ii  gnupg 2.2.27-2
ii  perl  5.32.1-4+deb11u2

Versions of packages debsigs recommends:
ii  debsig-verify  0.23+b2

debsigs suggests no packages.

-- no debconf information
commit 9cd7c457001ec6b10fc77ae370046583511c6d24
Author: Todd C. Miller 
Date:   Sun Sep 26 19:31:20 2021 -0600

Use mkdtemp() to create the temp dir instead of using a predictable name.

diff --git a/debsigs b/debsigs
index ee77ff8..903ee14 100644
--- a/debsigs
+++ b/debsigs
@@ -25,6 +25,7 @@ use Debian::debsigs::forktools ':all';
 use Debian::debsigs::gpg;
 use Getopt::Long;
 use List::Util qw(first);
+use File::Temp qw(:mktemp);
 use IO::File;
 use POSIX ":sys_wait_h";
 
@@ -185,8 +186,8 @@ sub cmd_delete($) {
 
 
 sub mktempdir() {
-  mkdir("/tmp/debsigndeb.$$", 0700) or die "couldn't mkdir: $!";
-  return "/tmp/debsigndeb.$$";
+  my $dir = mkdtemp("/tmp/debsigs.XX") or die "couldn't mkdtemp: $!";
+  return $dir;
 }
 
 sub syntax($) {


Bug#1003302: debsigs: Do not hard-code the path to gpg.

2022-01-07 Thread Todd C. Miller
Package: debsigs
Version: 0.1.25
Severity: normal
Tags: patch

Dear Maintainer,

The debsigs utility uses a mix of fully-qualified and unqualified paths
when invoking gpg.  There's no need to explicitly run /usr/bin/gpg as
perl will use execvp() to invoke the command (which searches PATH).
Using the PATH to find gpg makes it easier to run debsigs on other,
non-Debian platforms.

The attached fix is also in gitlab as:
https://gitlab.com/debsigs/debsigs/-/merge_requests/3

 - todd

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 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 debsigs depends on:
ii  binutils  2.35.2-2
ii  gnupg 2.2.27-2
ii  perl  5.32.1-4+deb11u2

Versions of packages debsigs recommends:
ii  debsig-verify  0.23+b2

debsigs suggests no packages.

-- no debconf information
commit b2dbd703b1b40d6e616b2246a84ef3b53e578497
Author: Todd C. Miller 
Date:   Sun Sep 26 19:51:18 2021 -0600

Do not hard-code the path to gpg.
There's no need to do this as perl will use execvp() which searches PATH.

diff --git a/debsigs b/debsigs
index 25b5d44..dc12b02 100644
--- a/debsigs
+++ b/debsigs
@@ -100,7 +100,7 @@ sub cmd_sign($) {
 
   # Why doesn't this work?
 
-  #  my $gpgout = forktools::forkboth($arfd, $sigfile, "/usr/bin/gpg",
+  #  my $gpgout = forktools::forkboth($arfd, $sigfile, "gpg",
   #"--detach-sign");
 
   my @cmdline = ("gpg", "--openpgp", "--detach-sign");
diff --git a/gpg.pm b/gpg.pm
index c624b4e..d939f2c 100644
--- a/gpg.pm
+++ b/gpg.pm
@@ -28,9 +28,7 @@ our $VERSION = '1.06';
 sub getkeyfromfd {
   my $forkfd = shift @_;
 
-  my ($gpgfd, $gpgpid) = forkreader($forkfd,
-  "/usr/bin/gpg",
-  "--list-packets");
+  my ($gpgfd, $gpgpid) = forkreader($forkfd, "gpg", "--list-packets");
   
   my ($keyid, $date);
 
@@ -57,8 +55,7 @@ sub getkeyfromfd {
 sub getkeynamefromid {
   my $keyid = shift @_;
 
-  my ($gpgfd, $gpgpid) = forkreader(undef, "/usr/bin/gpg",
-  "--list-keys", $keyid);
+  my ($gpgfd, $gpgpid) = forkreader(undef, "gpg", "--list-keys", $keyid);
   
   my $line = <$gpgfd>;
   chomp $line;


Bug#1003303: debsigs: Implement the -g/--gpgopts option

2022-01-07 Thread Todd C. Miller
Package: debsigs
Version: 0.1.25
Severity: normal
Tags: patch

Dear Maintainer,

The debsigs utility has scaffolding to support a -g/--gpgopts option but
it is not actually used.  Attached is a patch to pass options specified
via -g/--gpgopts to gpg when signing.  Multiple options may be specified,
separated by commas.

 - todd

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 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 debsigs depends on:
ii  binutils  2.35.2-2
ii  gnupg 2.2.27-2
ii  perl  5.32.1-4+deb11u2

Versions of packages debsigs recommends:
ii  debsig-verify  0.23+b2

debsigs suggests no packages.

-- no debconf information
commit 5311625df0d485e16fd674b452c5ecf2b0df160f
Author: Todd C. Miller 
Date:   Mon Sep 27 08:37:28 2021 -0600

Pass options from -g/--gpgops to gpg when signing.
Multiple options may be specified, separated by commas.

diff --git a/debsigs b/debsigs
index 25b5d44..c789681 100644
--- a/debsigs
+++ b/debsigs
@@ -105,6 +105,10 @@ sub cmd_sign($) {
 
   my @cmdline = ("gpg", "--openpgp", "--detach-sign");
 
+  if ($gpgopts) {
+push (@cmdline, split(/,/, $gpgopts));
+  }
+
   if ($key) {
 push (@cmdline, "--default-key", $key);
   }


Bug#1003277: RFS: memtest86+/5.31b-1 [QA] -- thorough real-mode memory tester

2022-01-07 Thread Bastian Germann

Control: tags -1 - moreinfo



Bug#1003277: RFS: memtest86+/5.31b-1 [QA] -- thorough real-mode memory tester

2022-01-07 Thread Fabio Fantoni

Il 07/01/2022 21:24, Bastian Germann ha scritto:

On 07.01.22 21:10, Fabio Fantoni wrote:

I did wrong to do a QA upload?


No, a QA upload is fine. But the maintainer should be kept "Debian QA 
Group" to be formally correct.


Ah... sry, I saw only now the mistake of not merging debian/control 
change, fixed and did another upload to mentors




OpenPGP_signature
Description: OpenPGP digital signature


Bug#1003240: mlton: mlton_20210117+dfsg-3 cannot rebuild itself on hppa

2022-01-07 Thread Ryan Kavanagh
Control: tags -1 + confirmed
Control: retitle -1 mlton cannot rebuild itself on hppa or i386

On Thu, Jan 06, 2022 at 07:55:00PM +, John David Anglin wrote:
> It fails with a reproducible segmentation fault.

I can reproduce this even with the latest upstream HEAD on the hppa
porterbox, using

make BOOTSTRAP_STYLE=3

which makes it this far:

-8<-
make compiler SELF_COMPILE=true  CHECK_FIXPOINT=true   # tools2 + mlton2 -> 
mlton3; mlton3 == mlton2
[...]
chmod -w front-end/mlb.grm.*
sed \
-e "s/MLTON_NAME/MLton/" \
-e "s/MLTON_VERSION//" \
< control/version_sml.src \
> control/version.sml
(cat control/version_sml.src; echo 'MLton' ''; cat control/version.sml) 
| sha1sum | sed 's/.*\([a-z0-9]\{40\}\).*/\1/' > control/version_sml.chk
Compiling mlton
"/home/rak/mlton/build/bin/mlton" \
@MLton ram-slop 0.7  gc-summary -- \
-default-ann 'sequenceNonUnit warn' -default-ann 'warnUnused true' 
-verbose 2   \
-target self -output mlton-compile  \
mlton.mlb
MLton  starting
   Compile SML starting
  frontend starting
 parseAndElaborate starting
Segmentation fault
make[2]: *** [Makefile:72: mlton-compile] Error 139
make[2]: Leaving directory '/home/rak/mlton/mlton'
make[1]: *** [Makefile:75: compiler] Error 2
make[1]: Leaving directory '/home/rak/mlton'
make: *** [Makefile:29: all] Error 2
-8<-

On Thu, Jan 06, 2022 at 06:04:18PM -0600, Henry Cejtin wrote:
> ssume that it isn't reproducible on AMD, right?
> Or better, x86 (32 bit)?

Not reproducible on amd64, but it is reproducible on i386, even with
codegen c:

make BOOTSTRAP_STYLE=3 MLTON_COMPILE_ARGS='-codegen c'

segfaults at

-8<-
make compiler CHECK_FIXPOINT=false # tools0 + mlton0 -> 
mlton1
make[1]: Entering directory '/home/rak/i386/mlton-20210117+dfsg'
make -C "/home/rak/i386/mlton-20210117+dfsg/mlton"
make[2]: Entering directory '/home/rak/i386/mlton-20210117+dfsg/mlton'
Compiling mlton
"mlton" \
@MLton ram-slop 0.7  gc-summary -- \
 -verbose 2 \
-target self -output mlton-compile  \
mlton-stubs.mlb
MLton 20210117+dfsg-3 starting
   Compile SML starting
  frontend starting
 parseAndElaborate starting
Segmentation fault
-8<-

Is there any chance that the issue is due to a (potential) mismatch
between flags involving pic/pie we pass in via -cc-opt $(CFLAGS), and
the default target-determined default? mlton has the flags -pi-style and
-native-pic thanks to https://github.com/MLton/mlton/pull/365 that may
need setting. (I haven't yet investigated this.) Debian used to carry a
patch that forced PIC to fix a FTBFS on amd64, and I dropped it this
most recent release because I thought it was no longer required (mlton
built fine without it).

Alternatively, it might be easiest to bisect the upstream repository and
see when things broke.

Ryan

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature


Bug#1002023: wine: Regression after upgrade to bullseye: crash with X_ConfigureWindow / BadWindow error

2022-01-07 Thread CJP
Antoine Le Gonidec schreef op vr 07-01-2022 om 17:04 [+0100]:
> I think this is related to this upstream issue: 
> https://bugs.winehq.org/show_bug.cgi?id=49649 — Multiple games cause
> X11 to crash on resolution change (Age of Empires 1 & 2, Star Wars:
> Galactic Battlegrounds)
> 
> It is fixed on current 7.0 release candidate, and you can work around
> it with older WINE builds by changing the Direct3D renderer as
> described in this post:
> https://bugs.winehq.org/show_bug.cgi?id=49649#c6 (a .reg file
> applying the suggested change is provided for convenience)

Thank you so much for this information: it certainly looks exactly like
my problem!

I tried changing the Direct3D renderer with "wine regedit". Initially,
that registry value was not set on my system - I tested with absent
value, with "gdi" and with "gl". These are the results:

===results TLDR===
The workaround works for Age of Empires II but not for Flight Simulator
2004, where it results in a different error. I think Flight Simulator
uses Direct3D and Age of Empires doesn't, and the workaround disables
Direct3D.

===results details===
With "gdi", the terminal window shows a line
"0009:err:winediag:wined3d_dll_init Disabling 3D support.". Unlike
before, Flight Simulator now shows its menu(*). However, when I press
the button to start flying, it shows an error window with the text
"Error creating required Direct3D buffers - Flight Simulator will now
exit.", and the game exits.

With "gdi", Age of Empires II shows the same line on the terminal, but
it works fine. I guess it helps that AoE isn't really a 3D game.

With "gl", the terminal window shows a line
"0009:err:winediag:wined3d_dll_init Using the OpenGL renderer.". While
this line was not present with absent registry key, the behavior is the
same: AoE and Flight Simulator crash, as in my original bug report.
===results end===

I suppose the good news is that we know how Wine 7 is patched to fix
the issue - maybe Wine 5 can be patched in a similar way. I'd have to
look into how to compile Debian's Wine package from source though, and
I hope it won't take too long compiling.

(*) For people trying to reproduce this: in my case, it starts with a
menu page that does not show any 3D elements (the "select flight"
menu). I can imagine it still crashes if on your system it starts with
the "create flight" menu, which does contain 3D elements.



Bug#1003277: RFS: memtest86+/5.31b-1 [QA] -- thorough real-mode memory tester

2022-01-07 Thread Bastian Germann

On 07.01.22 21:10, Fabio Fantoni wrote:
I did 
wrong to do a QA upload?


No, a QA upload is fine. But the maintainer should be kept "Debian QA Group" to 
be formally correct.



Bug#1003277: RFS: memtest86+/5.31b-1 [QA] -- thorough real-mode memory tester

2022-01-07 Thread Fabio Fantoni

Il 07/01/2022 20:53, Bastian Germann ha scritto:

Control: tags -1 moreinfo

Please remove this tag when you have provided a fixed version (keeping 
-1 revision no).


On 07.01.22 20:13, Bastian Germann wrote:

I suppose you should ITA the package. Want to take this responsibility?


Changes since the last upload:

  memtest86+ (5.31b-1) experimental; urgency=medium
  .
    [ Fabio Fantoni ]
    * QA upload.


As you have left out the changes from 
c1cf11ee824384a63f961a59299a9666d8ed6a45 to the release of -4,
this is not really a QA upload. Please include the changes including 
the Maintainer change.


Hi, thanks for reply, I don't have long time to be sure to keep it long 
term even though I have invested several hours in it in the last few 
weeks. Moreover it would be better that the maintainer also have 
experience in assembly and part of the boot (on which I have near 
nothing experience, except grub part) to be able to maintain it at its 
best. I did wrong to do a QA upload?




OpenPGP_signature
Description: OpenPGP digital signature


Bug#996973: Upload or ... Was: WIP

2022-01-07 Thread Geert Stappers
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996973#30
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996973#35

I did recieve that as "Yeah, an upload is fine". So I did.
`msc-generator` is in the NEW queue[1].


Regards
Geert Stappers
DD

[1]: https://ftp-master.debian.org/new.html


signature.asc
Description: PGP signature


Bug#1003277: RFS: memtest86+/5.31b-1 [QA] -- thorough real-mode memory tester

2022-01-07 Thread Bastian Germann

Control: tags -1 moreinfo

Please remove this tag when you have provided a fixed version (keeping -1 
revision no).

On 07.01.22 20:13, Bastian Germann wrote:

I suppose you should ITA the package. Want to take this responsibility?


Changes since the last upload:

  memtest86+ (5.31b-1) experimental; urgency=medium
  .
    [ Fabio Fantoni ]
    * QA upload.


As you have left out the changes from c1cf11ee824384a63f961a59299a9666d8ed6a45 
to the release of -4,
this is not really a QA upload. Please include the changes including the 
Maintainer change.




Bug#1003301: kxl: Uses self-referential Homepage field

2022-01-07 Thread Guillem Jover
Source: kxl
Source-Version: 1.1.7-17
Severity: normal

Hi!

This package contains a Homepage field pointing to the Debian tracker
(at https://tracker.debian.org/pkg/kxl), which is not very useful
really.

So either make it point to http://triring.net/ps2linux/games/kxl/kxlgames.html
or to https://github.com/Quipyowert2/libKXL depending on the outcome
of the other report asking for a possible new upstream release.

Thanks,
Guillem



Bug#1003300: kxl: New upstream project and versions

2022-01-07 Thread Guillem Jover
Source: kxl
Source-Version: 1.1.7-17
Severity: normal

Hi!

It seems the upstream for this package has somewhat disappeared, although
its mirror is still available at
, but that one
does not contain 1.1.7, only up to 1.1.5.

A new project with recent releases (1.2.4 2021-10-01) can be found
at , but then I'm not sure
the standing of that project, whether its some kind of fork, or an
official continuation, accepted by other projects etc.

Thanks,
Guillem



Bug#1003277: RFS: memtest86+/5.31b-1 [QA] -- thorough real-mode memory tester

2022-01-07 Thread Bastian Germann

On Fri, 7 Jan 2022 14:11:21 +0100 Fabio Fantoni  wrote:
New upstream beta version (with relevant additions and fixes), also got 
fixes from coreboot, fedora, suse, gentoo, ubuntu, made further 
additions and improvements to packaging, readme and grub2 configuration, 
I also did some tests on PCs in these weeks and is generally better than 
the current version on stable/testing/unstable. The experimental 
multiboot is still bugged (on my tests) after the patch from coreboot 
(for different problem) but it was also before (on 
stable/testing/unstable packages), and as being disabled by default I 
don't think I should delay a possible upload on experimental yet given 
the numerous fixes that this build includes.


I suppose you should ITA the package. Want to take this responsibility?


Changes since the last upload:

  memtest86+ (5.31b-1) experimental; urgency=medium
  .
    [ Fabio Fantoni ]
    * QA upload.


As you have left out the changes from c1cf11ee824384a63f961a59299a9666d8ed6a45 
to the release of -4,
this is not really a QA upload. Please include the changes including the 
Maintainer change.


    * New upstream version 5.31b (Closes: #989030, #977217)
    * Merge from ubuntu:
  - Use elf version by default that should works on major of system.
  - Drop the multiboot image from the GRUB menu for now, since it's
    experimental and has known problems detecting all memory on some
    systems at the moment.
  - Support localization of GRUB menu entries.
  - Don't present in GRUB menu on EFI systems, since it won't work.
    (Closes: #695246)
  - Close FD 3 when invoking update-grub.
    * Warn that don't support EFI instead of exit silently (LP: 1863940)


Please improve the English here. (Warn that EFI is not supported ...)?


    * Don't add grub2 entries if GRUB_DISABLE_MEMTEST=true is present
  in /etc/default/grub (LP: #420967)




Bug#842335: RFP: mint-y-theme -- Mint-Y themes

2022-01-07 Thread Fabio Fantoni

Control: retitle -1 RFP: mint-themes -- A collection of Mint themes

Hi, mint-y-theme was superseeded by mint-themes 
https://github.com/linuxmint/mint-themes


it depends on mint-x-icons mint-y-icons that also are not present in 
debian repository


upstream debian/ is not "ready" for uploading to debian but from a fast 
look it shouldn't take long to improve it


I'll ask to other people of debian-cinnamon team if it's worth add and 
keeping it




OpenPGP_signature
Description: OpenPGP digital signature


Bug#1003297: libclang-common-13-dev: LD does not find libclang_rt.builtins

2022-01-07 Thread Maxime Chambonnet

I am dealing with complexities that go over my head,
and that I will have a hard time reducing to a minimum test case. :/

I was trying to compile performance tests there
https://github.com/ROCm-Developer-Tools/HIP/tree/develop/tests
with the llvm that you packaged and not the llvm packaged by AMD.
https://github.com/RadeonOpenCompute/llvm-project
This ROCm is a can of worms beware.

On 1/7/22 19:51, Sylvestre Ledru wrote:
Please provide a test case and I will be able to answer to your 
question ;)


Sylvestre





Bug#1003297: libclang-common-13-dev: LD does not find libclang_rt.builtins

2022-01-07 Thread Maxime Chambonnet

(by standard dir I was meaning, in a directory listed in ld.so.conf)

On 1/7/22 19:47, Maxime Chambonnet wrote:

Bonsoir,

I am still discovering the toolchain so some bugs might be false 
positives...


Here it was ROCm having some cmake bugged, that was not correctly finding
the llvm directories and I got it solved.
But shouldn't this library be accessible to the public in a standard 
directory?


BR, Maxime

On 1/7/22 19:43, Sylvestre Ledru wrote:

Bonjour,

Could you please provide a test case to reproduce this easily ?

Thanks
S

Le 07/01/2022 à 19:26, Maxime Chambonnet a écrit :

Package: libclang-common-13-dev
Version: libclang-common-13-dev
Severity: normal
X-Debbugs-Cc: max...@maxzor.eu

Hello,
The linker does not find the static lib,
which is installed by this package in
/usr/lib/llvm-13/lib/clang/13.0.0/lib/linux/libclang_rt.builtins-x86_64.a 



Is there something missing?

BR, Maxime


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 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 libclang-common-13-dev depends on:
pn  lib32gcc-s1   
pn  lib32stdc++6  
ii  libc6 2.33-1
pn  libc6-i386    
ii  libgcc-s1 11.2.0-13
pn  libllvm13 
ii  libstdc++6    11.2.0-13

libclang-common-13-dev recommends no packages.

libclang-common-13-dev suggests no packages.







Bug#1003297: libclang-common-13-dev: LD does not find libclang_rt.builtins

2022-01-07 Thread Sylvestre Ledru

Please provide a test case and I will be able to answer to your question ;)

Sylvestre



Le 07/01/2022 à 19:47, Maxime Chambonnet a écrit :

Bonsoir,

I am still discovering the toolchain so some bugs might be false positives...

Here it was ROCm having some cmake bugged, that was not correctly finding
the llvm directories and I got it solved.
But shouldn't this library be accessible to the public in a standard directory?

BR, Maxime

On 1/7/22 19:43, Sylvestre Ledru wrote:

Bonjour,

Could you please provide a test case to reproduce this easily ?

Thanks
S

Le 07/01/2022 à 19:26, Maxime Chambonnet a écrit :

Package: libclang-common-13-dev
Version: libclang-common-13-dev
Severity: normal
X-Debbugs-Cc: max...@maxzor.eu

Hello,
The linker does not find the static lib,
which is installed by this package in
/usr/lib/llvm-13/lib/clang/13.0.0/lib/linux/libclang_rt.builtins-x86_64.a

Is there something missing?

BR, Maxime


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 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 libclang-common-13-dev depends on:
pn  lib32gcc-s1   
pn  lib32stdc++6  
ii  libc6 2.33-1
pn  libc6-i386    
ii  libgcc-s1 11.2.0-13
pn  libllvm13 
ii  libstdc++6    11.2.0-13

libclang-common-13-dev recommends no packages.

libclang-common-13-dev suggests no packages.







Bug#1003297: libclang-common-13-dev: LD does not find libclang_rt.builtins

2022-01-07 Thread Maxime Chambonnet

Bonsoir,

I am still discovering the toolchain so some bugs might be false 
positives...


Here it was ROCm having some cmake bugged, that was not correctly finding
the llvm directories and I got it solved.
But shouldn't this library be accessible to the public in a standard 
directory?


BR, Maxime

On 1/7/22 19:43, Sylvestre Ledru wrote:

Bonjour,

Could you please provide a test case to reproduce this easily ?

Thanks
S

Le 07/01/2022 à 19:26, Maxime Chambonnet a écrit :

Package: libclang-common-13-dev
Version: libclang-common-13-dev
Severity: normal
X-Debbugs-Cc: max...@maxzor.eu

Hello,
The linker does not find the static lib,
which is installed by this package in
/usr/lib/llvm-13/lib/clang/13.0.0/lib/linux/libclang_rt.builtins-x86_64.a 



Is there something missing?

BR, Maxime


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 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 libclang-common-13-dev depends on:
pn  lib32gcc-s1   
pn  lib32stdc++6  
ii  libc6 2.33-1
pn  libc6-i386    
ii  libgcc-s1 11.2.0-13
pn  libllvm13 
ii  libstdc++6    11.2.0-13

libclang-common-13-dev recommends no packages.

libclang-common-13-dev suggests no packages.







Bug#1003297: libclang-common-13-dev: LD does not find libclang_rt.builtins

2022-01-07 Thread Sylvestre Ledru

Bonjour,

Could you please provide a test case to reproduce this easily ?

Thanks
S

Le 07/01/2022 à 19:26, Maxime Chambonnet a écrit :

Package: libclang-common-13-dev
Version: libclang-common-13-dev
Severity: normal
X-Debbugs-Cc: max...@maxzor.eu

Hello,
The linker does not find the static lib,
which is installed by this package in
/usr/lib/llvm-13/lib/clang/13.0.0/lib/linux/libclang_rt.builtins-x86_64.a

Is there something missing?

BR, Maxime


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 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 libclang-common-13-dev depends on:
pn  lib32gcc-s1   
pn  lib32stdc++6  
ii  libc6 2.33-1
pn  libc6-i386
ii  libgcc-s1 11.2.0-13
pn  libllvm13 
ii  libstdc++611.2.0-13

libclang-common-13-dev recommends no packages.

libclang-common-13-dev suggests no packages.





Bug#677470: xserver-xorg: X server eats CPU when there is animated icons in [plasma]tray

2022-01-07 Thread Johann Klammer
Similar things can be observed in thunderbird or palemoon or anything with 
spinners and throbbers and crap.
I suspect it might(also) be a lousy porter/duff implementation somewhere in 
libpixman or thereabout. 
slowness reading from gfx memory and all that...



Bug#1003297: libclang-common-13-dev: LD does not find libclang_rt.builtins

2022-01-07 Thread Maxime Chambonnet
Package: libclang-common-13-dev
Version: libclang-common-13-dev
Severity: normal
X-Debbugs-Cc: max...@maxzor.eu

Hello,
The linker does not find the static lib,
which is installed by this package in
/usr/lib/llvm-13/lib/clang/13.0.0/lib/linux/libclang_rt.builtins-x86_64.a

Is there something missing?

BR, Maxime


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 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 libclang-common-13-dev depends on:
pn  lib32gcc-s1   
pn  lib32stdc++6  
ii  libc6 2.33-1
pn  libc6-i386
ii  libgcc-s1 11.2.0-13
pn  libllvm13 
ii  libstdc++611.2.0-13

libclang-common-13-dev recommends no packages.

libclang-common-13-dev suggests no packages.



Bug#1003272: lintian: chokes on overrides with "(" but no ")"

2022-01-07 Thread Felix Lechner
Hi,

On Fri, Jan 7, 2022 at 10:18 AM Tobias Frost  wrote:
>
> FWIIW, escaping with a backslash, e.g "\(" *did* work for me earlier today...

Okay, thanks!

I just knew backslashes do not work for square brackets, which are
perhaps more common right now. There, the awkward notation [[] is
required until I implement the new override format.

Kind regards
Felix Lechner



Bug#1003272: lintian: chokes on overrides with "(" but no ")"

2022-01-07 Thread Tobias Frost
On Fri, Jan 07, 2022 at 04:50:37AM -0800, Felix Lechner wrote:
> (backslashes do not work) but more changes are coming to override files.
 
FWIIW, escaping with a backslash, e.g "\(" *did* work for me earlier today...

-- 
tobi



Bug#1003296: [INTL:es] Spanish translation of the debconf template

2022-01-07 Thread Camaleón
Package: open-infrastructure-compute-tools
Severity: wishlist
Tags: patch l10

Hello,
You can find enclosed the Spanish translation template to be uploaded with the 
latest package build.
Cheers,

-- 
Camaleón# Spanish debconf translation of open-infrastructure-container-tools
# Copyright (C) 2021 Camaleón 
# This file is distributed under the same license as the 
open-infrastructure-container-tools package.
#
msgid ""
msgstr ""
"Project-Id-Version: open-infrastructure-compute-tools\n"
"Report-Msgid-Bugs-To: open-infrastructure-compute-to...@packages.debian.org\n"
"POT-Creation-Date: 2021-07-25 10:09+0200\n"
"PO-Revision-Date: 2022-01-07 18:47+0100\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: title
#. Description
#: ../open-infrastructure-container-tools.templates:1001
msgid "container-tools: Setup"
msgstr "container-tools: Configuración"

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:2001
msgid "machines directory:"
msgstr "directorio de máquinas virtuales:"

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:2001
msgid "Please specify the directory that will be used to store the containers."
msgstr ""
"Por favor, indique el directorio que se usará para almacenar los "
"contenedores."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:2001
msgid ""
"If unsure, use /var/lib/machines (default) or /srv/container/system when "
"using shared storage."
msgstr ""
"Si no está seguro, utilice «/var/lib/machines» (predeterminado) o «/srv/"
"container/system» si usa un almacenamiento compartido."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:3001
msgid "config directory:"
msgstr "directorio de configuración:"

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:3001
msgid ""
"Please specify the directory that will be used to store the container "
"configuration files."
msgstr ""
"Por favor, indique el directorio que se usará para almacenar los archivos de "
"configuración del contenedor."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:3001
msgid ""
"If unsure, use /etc/compute-tools/config (default) or /srv/container/config "
"when using shared storage."
msgstr ""
"Si no está seguro, utilice «/etc/compute-tools/config/config» (predeterminado) 
o «/srv/container/config» si usa un almacenamiento "
"compartido."

#. Type: string
#. Description
#. Type: string
#. Description
#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:4001
#: ../open-infrastructure-container-tools.templates:5001
#: ../open-infrastructure-container-tools.templates:6001
msgid "debconf directory:"
msgstr "directorio debconf:"

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:4001
msgid ""
"Please specify the directory that will be used to store the container "
"preseed files."
msgstr ""
"Por favor, indique el directorio que se usará para almacenar los archivos de "
"preconfiguración (preseed) del contenedor."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:4001
msgid ""
"If unsure, use /etc/compute-tools/debconf (default) or /srv/container/"
"debconf when using shared storage."
msgstr ""
"Si no está seguro, utilice «/etc/compute-tools/debconf» (predeterminado) o 
«/srv/container/debconf» si usa un "
"almacenamiento compartido."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:5001
msgid ""
"Please specify the directory that will be used to store the container hooks."
msgstr ""
"Por favor, indique el directorio que se usará para almacenar los archivos de "
"órdenes (hooks) del contenedor."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:5001
msgid ""
"If unsure, use /etc/compute-tools/hooks (default) or /srv/container/hooks "
"when using shared storage."
msgstr ""
"Si no está seguro, utilice «/etc/compute-tools/hooks» (predeterminado) o 
«/srv/container/hooks» si usa un almacenamiento "
"compartido."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:6001
msgid ""
"Please specify the directory that will be used to store the container keys "
"for verifying container image downloads."
msgstr ""
"Por favor, indique el directorio que se usará para almacenar las claves del "
"contenedor para verificar las descargas de imágenes del contenedor."

#. Type: string
#. Description
#: ../open-infrastructure-container-tools.templates:6001
msgid ""
"If unsure, use /etc/compute-tools/keys (default) or /srv/container/keys when "
"using shared storage."
msgstr ""
"Si no está seguro, utilice «/etc/compute-tools/keys» (predeterminado) o 
«/srv/container/keys» si usa un almacenamiento "
"compartido."

#. Type: 

Bug#1003295: [INTL:es] Spanish translation of the debconf template

2022-01-07 Thread Camaleón
Package: kexec-tools
Severity: wishlist
Tags: patch l10

Hello,
You can find enclosed the Spanish translation template to be uploaded with the 
latest package build.
Cheers,

-- 
Camaleón# kexec-tools po-debconf translation to Spanish
# Copyright (C) 2010 Software in the Public Interest
# This file is distributed under the same license as the kexec-tools package.
#
# Changes:
# - Initial translation
# Camaleón , 2011
#
# - Updates
#
#
# Traductores, si no conocen el formato PO, merece la pena leer la
# documentación de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
# Equipo de traducción al español, por favor lean antes de traducir
# los siguientes documentos:
#
# - El proyecto de traducción de Debian al español
# http://www.debian.org/intl/spanish/
# especialmente las notas y normas de traducción en
# http://www.debian.org/intl/spanish/notas
#
# - La guía de traducción de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
#
msgid ""
msgstr ""
"Project-Id-Version: kexec-tools 2.0.2-3\n"
"Report-Msgid-Bugs-To: kexec-to...@packages.debian.org\n"
"POT-Creation-Date: 2021-07-13 16:56-0600\n"
"PO-Revision-Date: 2022-01-07 18:51+0100\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../kexec-tools.templates:2001
#| msgid "Should kexec-tools handle reboots (sysvinit only)?"
msgid "Should kexec-tools handle reboots?"
msgstr ""
"¿Debe kexec-tools gestionar los reinicios del sistema ?"

#. Type: boolean
#. Description
#: ../kexec-tools.templates:2001
msgid ""
"If you choose this option, a system reboot will trigger a restart into a "
"kernel loaded by kexec instead of going through the full system boot loader "
"process."
msgstr ""
"Si selecciona esta opción, al reiniciar el sistema se realizará un reinicio "
"en un núcleo cargado por kexec en lugar de iniciar el proceso completo del "
"cargador de arranque del sistema."

#. Type: boolean
#. Description
#: ../kexec-tools.templates:3001
msgid "Read GRUB configuration file to load the kernel?"
msgstr "¿Leer el archivo de configuración de GRUB al cargar el kernel?"

#. Type: boolean
#. Description
#: ../kexec-tools.templates:3001
msgid ""
"If you choose this option, kexec will read the GRUB configuration file to "
"determine which kernel and options to load for kexec reboot, as opposed to "
"what is in /etc/default/kexec."
msgstr ""
"Si selecciona esta opción, kexec leerá el archivo de configuración de GRUB "
"para determinar el kernel y las opciones que se van a cargar al reiniciar "
"kexec, en lugar de obtener los valores desde el archivo «/etc/default/kexec»."


Bug#1003294: [INTL:es] Spanish translation of the debconf template

2022-01-07 Thread Camaleón
Package: glewlwyd
Severity: wishlist
Tags: patch l10

Hello,
You can find enclosed the Spanish translation template to be uploaded with the 
latest package build.
Cheers,

-- 
Camaleón# glewlwyd po-debconf translation to Spanish.
# Copyright (C) 2021
# This file is distributed under the same license as the glewlwyd package.
# Camaleón , 2021, 2022.
#
msgid ""
msgstr ""
"Project-Id-Version: glewlwyd\n"
"Report-Msgid-Bugs-To: glewl...@packages.debian.org\n"
"POT-Creation-Date: 2021-09-07 12:04-0400\n"
"PO-Revision-Date: 2022-01-07 18:48+0100\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Choices
#. Type: select
#. Default
#. Translators: Default config type, but not translated (or is it?)
#: ../templates:1001 ../templates:1002
msgid "Personalized"
msgstr "Personalizado"

#. Type: select
#. Choices
#: ../templates:1001
msgid "No configuration"
msgstr "Sin configuración"

#. Type: select
#. Description
#: ../templates:1003
msgid "Glewlwyd setup"
msgstr "Ajustes de Glewlwyd"

#. Type: select
#. Description
#: ../templates:1003
msgid "You can configure it later if needed"
msgstr "Puede configurarlo más adelante si lo necesita"

#. Type: string
#. Description
#: ../templates:2001
msgid "External address to access Glewlwyd:"
msgstr "Dirección externa para acceder a Glewlwyd:"

#. Type: note
#. Description
#: ../templates:3001
msgid "PostgreSQL requires pgcrypto"
msgstr "PostgreSQL requiere pgcrypto"


Bug#1003293: buster-pu: package postfix/3.4.14-0+deb10u1

2022-01-07 Thread Scott Kitterman
Debdiff attached.

Scott Kdiff -Nru postfix-3.4.14/debian/changelog postfix-3.4.23/debian/changelog
--- postfix-3.4.14/debian/changelog	2020-06-29 21:33:31.0 -0400
+++ postfix-3.4.23/debian/changelog	2022-01-07 11:04:17.0 -0500
@@ -1,3 +1,247 @@
+postfix (3.4.23-0+deb10u1) buster; urgency=medium
+
+  [Scott Kitterman]
+
+  * Refresh patches
+  * Update d/p/70_postfix-check.diff to exclude makedefs.out from synlink
+check.  Closes: #926331
+  * Do not override user set default_transport in postinst.  Closes: #988538
+  * Remove left-over ca-certificates.crt file from postfix chroot. 
+Closes: #991609
+  * Add information about keeping resolv.conf up to date in the chroot with
+the resolvconf package.  Closes: #964762
+
+  [Sergio Gelato]
+
+  * Correct if-up.d to not error out if postfix can't send mail yet. 
+Closes: #959864
+
+  [Paride Legovini]
+
+  * d/postfix.postinst: tolerate search domain with a leading dot. 
+Closes: #991950
+
+  [Wietse Venema]
+
+  * 3.4.15
+- Bugfix (introduced: Postfix 3.0): minor memory leaks in the
+  Postfix TLS library, found during tests. File: tls/tls_misc.c.
+
+- Bugfix (introduced: Postfix 3.0): 4kbyte per session memory
+  leak in the Postfix TLS library, found during tests. File:
+  tls/tls_misc.c.
+
+- Workaround for distros that override Postfix protocol
+  settings in a system-wide OpenSSL configuration file, causing
+  interoperability problems after an OS update. File:
+  tls/tls_client.c, tls/tls_server.c.
+
+  * 3.4.16
+- Bugfix (introduced: Postfix 3.4.15): part of a memory leak
+  fix was backported to the wrong place. File: tls/tls_misc.c.
+
+- The Postfix 3.4.15 workaround did not explictly override
+  the system-wide OpenSSL configuration of allowed TLS protocol
+  versions, for sessions where the remote SMTP client sends
+  SNI. It's better to be safe than sorry. File: tls/tls_server.c.
+
+  * 3.4.17
+- Bugfix (introduced: Postfix 3.4, already fixed in Postfix
+  3.6): tlsproxy(8) was using the wrong DANE macro for
+  connections with DANE trust anchors or with non-DANE trust
+  anchors (WTF: Thorsten Habich found this bug in the use
+  case that has nothing to do with DANE). This resulted in a
+  global certificate verify function pointer race, between
+  TLS handshakes that use TLS trust achors and handshakes
+  that use PKI. No memory was corrupted in the course of all
+  this.  Viktor Dukhovni. File: tlsproxy/tlsproxy.c.
+
+- Cleanup: the posttls-finger '-X' option reported a false
+  conflict with '-r'.  File: posttls-finger/posttls-finger.c.
+
+  * 3.4.18
+- Bugfix (introduced: Postfix 2.0): smtp_sasl_mechanism_filter
+  ignored table lookup errors, treating them as 'not found'.
+  Found during Postfix 3.6 development. File: smtp/smtp_sasl_proto.c.
+
+- Bugfix (introduced: Postfix 2.3): when deleting a recipient
+  with a milter, delete the recipient from the duplicate
+  filter, so that the recipient can be added back. Backported
+  from Postfix 3.6. Files: global/been_here.[hc],
+  cleanup/cleanup_milter.c.
+
+- Bugfix (introduced: before Postfix alpha): the code that
+  looks for Delivered-To: headers ignored headers longer than
+  $line_length_limit. Backported from Postfix 3.6. File:
+  global/delivered_hdr.c.
+
+- Bugfix (introduced: Postfix 2.8): save a copy of the
+  postscreen_dnsbl_reply_map lookup result. This has no effect
+  when the recommended texthash: look table is used, but it
+  may avoid stale data with other lookup tables. File:
+  postscreen/postscreen_dnsbl.c.
+
+- Bugfix (introduced: Postfix 2.2): after processing an
+  XCCLIENT command, the smtps service was waiting for a TLS
+  handshake. Found by Aki Tuomi. File: smtpd/smtpd.c.
+
+- Bugfix (introduced: Postfix 2.3): static maps did not free
+  their casefolding buffer. File: util/dict_static.c.
+
+  * 3.4.19
+- Feature: when a Postfix program makes a DNS query that
+  requests DNSSEC validation (usually for Postfix DANE support)
+  but the DNS response is not DNSSEC validated, Postfix will
+  send a DNS query configured with the "dnssec_probe" parameter
+  to determine if DNSSEC support is available, and logs a
+  warning if it is not. By default, the probe has type "ns"
+  and domain name ".". The probe is sent once per process
+  lifetime. Files: dns/dns.h, dns/dns_lookup.c, dns/dns_sec.c,
+  test_dns_lookup.c, global/mail_params.[hc], mantools/postlink.
+
+- The default "smtp_tls_dane_insecure_mx_policy = dane" was
+  causing unnecessary dnssec_probe activity. The default is now
+  "dane" when smtp_tls_security_level is "dane", otherwise it is
+  "may". File: global/mail_params.h.
+
+  * 3.4.20
+- Missing null pointer checks (introduced: Postfix 3.4) after
+  an internal I/O error 

Bug#1003293: buster-pu: package postfix/3.4.14-0+deb10u1

2022-01-07 Thread Scott Kitterman
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

This is similar to #1003261 for bullseye, although there are fewer
Debian specific changes because most weren't applicable to or would have
been more invasive for buster.

I've put together my usual postfix post-release update.  Because I'm
behind, it's rather larger than usual.  Also, a number of packaging bugs
that apply to buster have been recently fixed in Bookworm, so the low
risk changes there have been backported too.

The diff is rather large, so I don't include it in the original bug
report to increase the chances this makes it to the mailing list.

Also, as usual, I have this update ready to upload and running in
production locally.

Here is the debian/changelog entry for this update:

postfix (3.4.23-0+deb10u1) buster; urgency=medium

  [Scott Kitterman]

  * Refresh patches
  * Update d/p/70_postfix-check.diff to exclude makedefs.out from synlink
check.  Closes: #926331
  * Do not override user set default_transport in postinst.  Closes: #988538
  * Remove left-over ca-certificates.crt file from postfix chroot.
Closes: #991609
  * Add information about keeping resolv.conf up to date in the chroot with
the resolvconf package.  Closes: #964762

  [Sergio Gelato]

  * Correct if-up.d to not error out if postfix can't send mail yet.
Closes: #959864

  [Paride Legovini]

  * d/postfix.postinst: tolerate search domain with a leading dot.
Closes: #991950

  [Wietse Venema]

  * 3.4.15
- Bugfix (introduced: Postfix 3.0): minor memory leaks in the
  Postfix TLS library, found during tests. File: tls/tls_misc.c.

- Bugfix (introduced: Postfix 3.0): 4kbyte per session memory
  leak in the Postfix TLS library, found during tests. File:
  tls/tls_misc.c.

- Workaround for distros that override Postfix protocol
  settings in a system-wide OpenSSL configuration file, causing
  interoperability problems after an OS update. File:
  tls/tls_client.c, tls/tls_server.c.

  * 3.4.16
- Bugfix (introduced: Postfix 3.4.15): part of a memory leak
  fix was backported to the wrong place. File: tls/tls_misc.c.

- The Postfix 3.4.15 workaround did not explictly override
  the system-wide OpenSSL configuration of allowed TLS protocol
  versions, for sessions where the remote SMTP client sends
  SNI. It's better to be safe than sorry. File: tls/tls_server.c.

  * 3.4.17
- Bugfix (introduced: Postfix 3.4, already fixed in Postfix
  3.6): tlsproxy(8) was using the wrong DANE macro for
  connections with DANE trust anchors or with non-DANE trust
  anchors (WTF: Thorsten Habich found this bug in the use
  case that has nothing to do with DANE). This resulted in a
  global certificate verify function pointer race, between
  TLS handshakes that use TLS trust achors and handshakes
  that use PKI. No memory was corrupted in the course of all
  this.  Viktor Dukhovni. File: tlsproxy/tlsproxy.c.

- Cleanup: the posttls-finger '-X' option reported a false
  conflict with '-r'.  File: posttls-finger/posttls-finger.c.

  * 3.4.18
- Bugfix (introduced: Postfix 2.0): smtp_sasl_mechanism_filter
  ignored table lookup errors, treating them as 'not found'.
  Found during Postfix 3.6 development. File: smtp/smtp_sasl_proto.c.

- Bugfix (introduced: Postfix 2.3): when deleting a recipient
  with a milter, delete the recipient from the duplicate
  filter, so that the recipient can be added back. Backported
  from Postfix 3.6. Files: global/been_here.[hc],
  cleanup/cleanup_milter.c.

- Bugfix (introduced: before Postfix alpha): the code that
  looks for Delivered-To: headers ignored headers longer than
  $line_length_limit. Backported from Postfix 3.6. File:
  global/delivered_hdr.c.

- Bugfix (introduced: Postfix 2.8): save a copy of the
  postscreen_dnsbl_reply_map lookup result. This has no effect
  when the recommended texthash: look table is used, but it
  may avoid stale data with other lookup tables. File:
  postscreen/postscreen_dnsbl.c.

- Bugfix (introduced: Postfix 2.2): after processing an
  XCCLIENT command, the smtps service was waiting for a TLS
  handshake. Found by Aki Tuomi. File: smtpd/smtpd.c.

- Bugfix (introduced: Postfix 2.3): static maps did not free
  their casefolding buffer. File: util/dict_static.c.

  * 3.4.19
- Feature: when a Postfix program makes a DNS query that
  requests DNSSEC validation (usually for Postfix DANE support)
  but the DNS response is not DNSSEC validated, Postfix will
  send a DNS query configured with the "dnssec_probe" parameter
  to determine if DNSSEC support is available, and logs a
  warning if it is not. By default, the probe has type "ns"
  and domain name ".". The probe is sent once per process
  lifetime. Files: dns/dns.h, 

Bug#1003292: Unpassworded superuser account now causes errors in log

2022-01-07 Thread Ben Harris

Package: patroni
Version: 2.1.2-2

I actually encountered this problem in the PGDG package of Patroni for 
Ubuntu (version 2.1.2-2.pgdg18.04+1), but it claims to be an unchanged 
rebuild of Debian release 2.1.2-2, so I expect this is the best place to 
report problems.


In /etc/patroni/config.yml.in, which is added by the Debian packaging, 
there's this section:


# A superuser role is required in order for Patroni to manage the local
# Postgres instance.  If the option `use_unix_socket' is set to `true', then
# specifying an empty password results in no md5 password for the superuser
# being set and sockets being used for authentication. The `password:' line is
# nevertheless required.  Note that pg_rewind will not work if no md5 password
# is set.
superuser:
  username: "postgres"
  password:

That to me implies that not setting a superuser password should work as 
long as I have use_unix_socket set to true and use_pg_rewind set to false, 
both of which I do.  And up to Patroni 2.1.1 it did.  With the upgrade to 
2.1.2, Patroni still seems to work correctly but it produces log messages 
like this every ten seconds:


Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]: 2022-01-07 
17:51:09,869 ERROR: Exception when working with leader
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]: Traceback (most recent 
call last):
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]:   File 
"/usr/lib/python3/dist-packages/patroni/postgresql/rewind.py", line 60, in 
check_leader_is_not_in_recovery
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]: with 
get_connection_cursor(connect_timeout=3, options='-c statement_timeout=2000', 
**conn_kwargs) as cur:
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]:   File 
"/usr/lib/python3.8/contextlib.py", line 113, in __enter__
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]: return 
next(self.gen)
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]:   File 
"/usr/lib/python3/dist-packages/patroni/postgresql/connection.py", line 44, in 
get_connection_cursor
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]: conn = 
psycopg.connect(**kwargs)
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]:   File 
"/usr/lib/python3/dist-packages/psycopg2/__init__.py", line 127, in connect
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]: conn = 
_connect(dsn, connection_factory=connection_factory, **kwasync)
Jan  7 17:51:09 moa-dev-patroni1 patroni@13-main[10646]: psycopg2.OperationalError: 
connection to server at "172.28.208.196", port 5432 failed: fe_sendauth: no 
password supplied

It looks like Patroni now wants to connect to other nodes as a superuser 
even when use_pg_rewind is false.


I haven't managed to find anywhere in the upstream Patroni documentation 
that says that running with no password on the superuser account should 
work, so I think this is probably an error in the comment in config.yml.in 
rather than a bug in Patroni itself.


--
Ben Harris, University of Cambridge Information Services.



Bug#1003291: ModuleNotFoundError: No module named 'pkg_resources'

2022-01-07 Thread Ryan Tandy
Package: goobook
Version: 3.5.1-1
Severity: serious
Justification: Policy 7.2

Dear Maintainer,

goobook seems to need a dependency on python3-pkg-resources:

(sid-amd64)# goobook
Traceback (most recent call last):
  File "/usr/bin/goobook", line 33, in 
sys.exit(load_entry_point('goobook==3.5.1', 'console_scripts', 'goobook')())
  File "/usr/bin/goobook", line 25, in importlib_load_entry_point
return next(matches).load()
  File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
module = import_module(match.group('module'))
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 850, in exec_module
  File "", line 228, in _call_with_frames_removed
  File "/usr/share/goobook/goobook/application.py", line 18, in 
import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

After I installed python3-pkg-resources manually, it works fine.

This upstream MR might be relevant: 
https://gitlab.com/goobook/goobook/-/merge_requests/14

Thanks for maintaining goobook.

Ryan


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

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

Versions of packages goobook depends on:
ii  python3   3.9.2-3
ii  python3-googleapi 1.7.11-4
ii  python3-oauth2client  4.1.2-7
ii  python3-simplejson3.17.2-1
ii  python3-xdg   0.27-2

goobook recommends no packages.

goobook suggests no packages.

-- no debconf information



Bug#1000642: roundcube: Failing test with PHP 8.1

2022-01-07 Thread Guilhem Moulin
On Thu, 02 Dec 2021 at 17:22:09 +, debian-bts-link wrote
> # remote status report for #1000642 (http://bugs.debian.org/1000642)
> # Bug title: roundcube: Failing test with PHP 8.1
> #  * https://github.com/roundcube/roundcubemail/issues/8151
> #  * remote status changed: (?) -> closed
> #  * closed upstream
> tags 1000642 + fixed-upstream
> usertags 1000642 + status-closed

Just a quick follow-up on this: while the upstream issue is closed and
1.5.[12] were recently released, upstream's 1.5 branch is officially not
compatible with PHP 8.1.  I think it's best to refrain from further 1.5
uploads and instead wait for 1.6.0.  Even if that means the roundcube
package will be removed from testing.  (Hopefully only briefly as
upstream is currently planning to release 1.6 in January or February.)

-- 
Guilhem.


signature.asc
Description: PGP signature


Bug#1003290: ITP: mricrogl -- magnetic resonance image conversion, viewing and analysis

2022-01-07 Thread Yaroslav Halchenko
Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Med Packaging Team 


* Package name: mricrogl
  Version : 1.2.20211006
  Upstream Author : Chris Rorden
* URL : https://github.com/rordenlab/MRIcroGL
* License : BSD-2-clause
  Programming Lang: Pascal
  Description : magnetic resonance image conversion, viewing and analysis

 This is a GUI-based visualization and analysis tool for medical imaging.
 .
 This package provides the MRIcroGL executable.

Packaging will be largely based on mricron packaging originally done by
NeuroDebian team, and now maintained by the glorious Debian Med.



Bug#992592: lightdm does not start / work any more after system upgrade

2022-01-07 Thread Karsten Malcher

There seems no solution in sight.

When there is only one user that can be automatically logged in the nodm 
display manager can solve the problem.

Use:
agt-get purge lightdm
apget install nodm

Best regards
karsten



Bug#1002604: RFS: tapecalc/20211222-2 [ITA] [RC] -- full-screen tape editor that lets the user edit a calculation

2022-01-07 Thread Bastian Germann

On 07.01.22 17:33, Victor Westerhuis wrote:
If you don't think this is appropriate for an official Debian package, I can take the extra lines out and revert it to 
the default pipeline.


I have removed the file in favour of a reference to the CI team's version at 
https://salsa.debian.org/debian/tapecalc.
Please use that repo going forward. You should have received an invitation.



Bug#1003240: mlton: mlton_20210117+dfsg-3 cannot rebuild itself on hppa

2022-01-07 Thread John David Anglin

Don't know about amd64 or x86.

I tried adding "-codegen c" to MLTON_FLAGS but it didn't make any difference.

Gdb generates full backtrace with core file.  Thus, in theory, it should be 
possible to
debug.  But without symbols, it's hard to tell what's going on.

The fault outside the chroot is slightly different in that the compiler faults 
on address 0.

On 2022-01-06 7:04 p.m., Henry Cejtin wrote:

ssume that it isn't reproducible on AMD, right?
Or better, x86 (32 bit)?
One thing to try, under either of these, would be compiling stuff with
 -codegen c
or, compiling the compiler with that.

The idea is that the HPPA stuff must use the C compiler back end.

On Thu, Jan 6, 2022 at 3:24 PM John David Anglin  wrote:

Same issue with Linux overcommit turned off.  The machine is not running out of 
memory and
there is lots of swap (40G).

Don't really know what's causing segfault.

On 2022-01-06 3:27 p.m., Henry Cejtin wrote:

MLton understands about running out of memory, so it shouldn't just segfault.
If it isn't too hard, could you try it with Linux overcommit turned off?

On Thu, Jan 6, 2022 at 1:57 PM John David Anglin  wrote:

Source: mlton
Version: 20130715-3
Severity: normal

Dear Maintainer,

Because of dependency problems mlton_20210117+dfsg-3 had to built
manually on hppa.  However, it seems mlton_20210117+dfsg-3 cannot
rebuild itself on hppa.

See log:
https://buildd.debian.org/status/fetch.php?pkg=mlton=hppa=20210117%2Bdfsg-3=1641492022=0

It fails with a reproducible segmentation fault.  I noticed the compiler
had allocated more than 2G at this point, so there was probably a memory
allocation issue.  hppa is a 32-bit architecture.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
APT prefers buildd-unstable
APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.16.0-rc8+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



--
John David Anglin  dave.ang...@bell.net




--
John David Anglin  dave.ang...@bell.net



Bug#1003289: gnunet: [INTL:it] Italian translation of debconf messages

2022-01-07 Thread Beatrice Torracca
Package: gnunet
Severity: wishlist
Tags: l10n patch

Hi.

Please find attached the Italian translation of gnunet debconf messages
proofread by the Italian localization team.

Please include it in your next upload.

Thanks,
Beatrice
# Italian translation of gnunet debconf templates.
# Copyright (C) 2021, 2022 gnunet package copyright holder
# This file is distributed under the same license as the gnunet package.
# Beatrice Torracca , 2012, 2022.
#
msgid ""
msgstr ""
"Project-Id-Version: gnunet 0.8.1b-5\n"
"Report-Msgid-Bugs-To: gnu...@packages.debian.org\n"
"POT-Creation-Date: 2021-02-27 11:07+0100\n"
"PO-Revision-Date: 2022-01-07 17:46+0100\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 3.0\n"

#. Type: title
#. Description
#: ../gnunet.templates:1001
msgid "GNUnet: Setup"
msgstr "GNUnet: configurazione"

#. Type: string
#. Description
#: ../gnunet.templates:2001
msgid "GNUnet user:"
msgstr "Utente GNUnet:"

#. Type: string
#. Description
#: ../gnunet.templates:2001
msgid "Please choose the user that the GNUnet server process will run as."
msgstr ""
"Scegliere l'utente con cui verrà eseguito il processo del server GNUnet."

#. Type: string
#. Description
#: ../gnunet.templates:2001
msgid ""
"This should be a dedicated account. If the specified account does not "
"already exist, it will automatically be created, with no login shell."
msgstr ""
"Dovrebbe essere un account dedicato. Se l'account specificato non esiste "
"già, verrà creato automaticamente senza una shell di login."

#. Type: string
#. Description
#: ../gnunet.templates:3001
msgid "GNUnet group:"
msgstr "Gruppo GNUnet:"

#. Type: string
#. Description
#: ../gnunet.templates:3001
msgid "Please choose the group that the GNUnet server process will run as."
msgstr ""
"Scegliere il gruppo con cui verrà eseguito il processo del server GNUnet."

#. Type: string
#. Description
#: ../gnunet.templates:3001
msgid ""
"This should be a dedicated group, not one that already owns data. Only the "
"members of this group will have access to GNUnet data, and be allowed to "
"start and stop the GNUnet server."
msgstr ""
"Dovrebbe essere un gruppo dedicato, non uno a cui appartengono già dei dati. "
"Solo i membri di questo gruppo avranno accesso ai dati GNUnet e avranno il "
"permesso di avviare e fermare il server GNUnet."

#. Type: boolean
#. Description
#: ../gnunet.templates:4001
msgid "Should the GNUnet server be launched on boot?"
msgstr "Far partire il server GNUnet all'avvio?"

#. Type: boolean
#. Description
#: ../gnunet.templates:4001
msgid ""
"If you choose this option, a GNUnet server will be launched each time the "
"system is started. Otherwise, you will need to launch GNUnet each time you "
"want to use it."
msgstr ""
"Se si sceglie questa opzione, un server GNUnet sarà fatto partire ogni volta "
"che il sistema viene avviato. Altrimenti sarà necessario far partire GNUnet "
"ogni volta che si desidera usarlo."


Bug#1003288: ircd-hybrid: [INTL:it] Italian translation of debconf messages

2022-01-07 Thread Beatrice Torracca
Package: ircd-hybrid
Severity: wishlist
Tags: l10n patch

Hi.

Please find attached the Italian translation of ircd-hybrid debconf
messages proofread by the Italian localization team.

Please include it in your next upload.

Thanks,
Beatrice
# Italian translation of ircd-hybrid po-debconf file.
# COPYRIGHT (C) 2010-2013, 2022 ircd-hybrid package copyright holder
# This file is distributed under the same license as the ircd-hybrid package.
# Vincenzo Campanella , 2010.
# Beatrice Torracca , 2013, 2014, 2022.
msgid ""
msgstr ""
"Project-Id-Version: ircd-hybrid\n"
"Report-Msgid-Bugs-To: ircd-hyb...@packages.debian.org\n"
"POT-Creation-Date: 2021-02-07 15:23+\n"
"PO-Revision-Date: 2022-01-07 17:40+0100\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 3.0\n"

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid "Restart ircd-hybrid on each upgrade?"
msgstr "Riavviare ircd-hybrid a ogni aggiornamento?"

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid ""
"Please choose whether the ircd-hybrid daemon should be restarted every time "
"a new version of this package is installed."
msgstr ""
"Scegliere se riavviare o meno il demone ircd-hybrid ogni volta che viene "
"installata una nuova versione di questo pacchetto."

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid ""
"Automatic restarts may be problematic if, for instance, the server is "
"running with manually loaded modules, which will need to be reloaded after "
"the restart."
msgstr ""
"I riavvii automatici possono essere problematici se, per esempio, il server "
"è in esecuzione con moduli caricati manualmente, che dovranno essere "
"ricaricati dopo il riavvio."

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid ""
"If you reject this option, you will have to restart ircd-hybrid via "
"\"service ircd-hybrid restart\" when needed."
msgstr ""
"Se non si sceglie questa opzione, sarà necessario riavviare ircd-hybrid "
"usando «service ircd-hybrid restart» al momento opportuno."

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:3001
msgid "Automatically fix references to obsolete config options?"
msgstr ""
"Correggere automaticamente i riferimenti a opzioni di configurazione "
"obsolete?"

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:3001
msgid ""
"Several ssl configuration variables have been renamed to tls-like ones in "
"version 8.2.30, with some further changes to rename network_desc and "
"max_watch in 8.2.36, and dots_in_ident in 8.2.38. If enabled, the post-"
"installation script will attempt to automatically fix them before the server "
"is restarted. If not, and you have these options specified, the "
"configuration will become invalid, and server restart will fail."
msgstr ""
"Nella versione 8.2.30 diverse variabili di configurazione di ssl sono state "
"rinominate in altre in stile tls, con alcuni ulteriori cambiamenti per "
"rinominare network_desc e max_watch in 8.2.36, e dots_in_ident in 8.2.38. Se "
"questa opzione viene abilitata, lo script di post-installazione cercherà di "
"correggerle automaticamente prima del riavvio del server. Altrimenti la "
"configurazione, se sono specificate tali opzioni, risulterà non valida e il "
"riavvio del server fallirà."


Bug#1003287: sympa: [INTL:it] Italian translation of debconf messages

2022-01-07 Thread Beatrice Torracca
Package: sympa
Severity: wishlist
Tags: l10n patch

Hi.

Please find attached the Italian translation of sympa debconf messages
proofread by the Italian localization team.

Please include it in your next upload.

Thanks,
Beatrice
# Italian translation of sympa debconf messages.
# Copyright (C) 2011, 2022 sympa package copyright holder
# This file is distributed under the same license as the sympa package.
# Beatrice Torracca , 2012, 2022
msgid ""
msgstr ""
"Project-Id-Version: sympa\n"
"Report-Msgid-Bugs-To: sy...@packages.debian.org\n"
"POT-Creation-Date: 2020-11-28 15:04+0100\n"
"PO-Revision-Date: 2022-01-07 17:39+0100\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 3.0\n"

#. Type: select
#. Description
#: ../templates:1001
msgid "Default language for Sympa:"
msgstr "Lingua predefinita per Sympa:"

#. Type: string
#. Description
#: ../templates:2001
msgid "Sympa hostname:"
msgstr "Nome host di Sympa:"

#. Type: string
#. Description
#: ../templates:2001
msgid ""
"This is the name of the machine or the alias you will use to reach sympa."
msgstr ""
"Questo è il nome della macchina o l'alias che verrà usato per raggiungere "
"sympa."

#. Type: string
#. Description
#. Type: string
#. Description
#: ../templates:2001 ../templates:3001
msgid "Example:"
msgstr "Esempio:"

#. Type: string
#. Description
#: ../templates:2001
msgid "  listhost.cru.fr"
msgstr "  listhost.cru.fr"

#. Type: string
#. Description
#: ../templates:2001
msgid "  Then, you will send your sympa commands to:"
msgstr "  Poi, i comandi di sympa verranno inviati a:"

#. Type: string
#. Description
#: ../templates:2001
msgid "  sy...@listhost.cru.fr"
msgstr "  sy...@listhost.cru.fr"

#. Type: string
#. Description
#: ../templates:3001
msgid "Listmaster email address(es):"
msgstr "Indirizzo o indirizzi di posta elettronica del listmaster:"

#. Type: string
#. Description
#: ../templates:3001
msgid ""
"Listmasters are privileged people who administrate mailing lists (mailing "
"list superusers)."
msgstr ""
"I listmaster sono utenti privilegiati che amministrano le mailing list "
"(superutenti delle mailing list)."

#. Type: string
#. Description
#: ../templates:3001
msgid "Please give listmasters email addresses separated by commas."
msgstr ""
"Inserire gli indirizzi di posta elettronica dei listmaster separati da "
"virgole."

#. Type: string
#. Description
#: ../templates:3001
msgid "  postmas...@cru.fr, r...@home.cru.fr"
msgstr "  postmas...@cru.fr, r...@home.cru.fr"

#. Type: boolean
#. Description
#: ../templates:4001
msgid "Should lists home and spool directories be removed?"
msgstr "Eliminare le directory home e di spool delle liste?"

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"The lists home directory (/var/lib/sympa) contains the mailing lists "
"configurations, mailing list archives and S/MIME user certificates (when "
"sympa is configured for using S/MIME encryption and authentication). The "
"spool directory (/var/spool/sympa) contains various queue directories."
msgstr ""
"La directory home delle liste (/var/lib/sympa) contiene le configurazioni "
"delle mailing list, gli archivi delle mailing list e i certificati utente S/"
"MIME (quando sympa è stato configurato per usare la cifratura e "
"l'autenticazione S/MIME). La directory di spool (/var/spool/sympa) contiene "
"varie directory con code."

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"Note that if those directories are empty, they will be automatically removed."
msgstr ""
"Notare che se tali directory sono vuote, verranno rimosse automaticamente."

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"Please choose whether you want to remove lists home and spool directories."
msgstr ""
"Scegliere se si desidera rimuovere le directory home e di spool delle liste."

#. Type: string
#. Description
#: ../templates:5001
msgid "URL to access WWSympa:"
msgstr "URL per accedere a WWSympa:"

#. Type: select
#. Choices
#: ../templates:6001
msgid "Apache 2"
msgstr "Apache 2"

#. Type: select
#. Choices
#: ../templates:6001
msgid "Other"
msgstr "Altro"

#. Type: select
#. Description
#: ../templates:6002
msgid "Which Web Server(s) are you running?"
msgstr "Quale o quali server web sono in esecuzione?"

#. Type: boolean
#. Description
#: ../templates:7001
msgid "Do you want the sympa SOAP server to be used?"
msgstr "Usare il server SOAP Sympa?"

#. Type: boolean
#. Description
#: ../templates:7001
msgid ""
"Sympa SOAP server allows to access a Sympa service from within another "
"program, written in any programming language and on any computer. The SOAP "
"server provides a limited set of high level functions including login, "
"which, lists, subscribe, signoff."
msgstr ""
"Il server SOAP Sympa permette di accedere a un servizio Sympa 

Bug#1002604: RFS: tapecalc/20211222-2 [ITA] [RC] -- full-screen tape editor that lets the user edit a calculation

2022-01-07 Thread Victor Westerhuis

On 07/01/2022 00:50, Bastian Germann wrote:

Can you please explain what you try to do with the Salsa CI?
Why don't you just use the default pipelines?


I use all of the default pipeline, I've just added an extra stage to 
publish the built apt repository on 
https://viccie30.pages.debian.net/tapecalc/ so that I have a fixed 
address to point to.


I use this mainly for a few other Python packages with dependencies on 
each other to be able to build them on Salsa. See for example 
https://salsa.debian.org/viccie30/python-statmake/-/blob/debian/latest/debian/salsa-ci.yml 
which uses this to download the newest version of python-cattr from my 
Salsa repository.


If you don't think this is appropriate for an official Debian package, I 
can take the extra lines out and revert it to the default pipeline.


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1003130: ITP: luit in 2013.

2022-01-07 Thread Thomas Dickey
On Wed, Jan 05, 2022 at 03:23:13PM -0500, Thomas Dickey wrote:
> On Wed, Jan 05, 2022 at 03:26:13PM +0200, Timo Aaltonen wrote:
...
> > If not, I don't see a point in creating a separate package for it. And I

actually as I understand Debian policy, it would have to be a separate
package because the upstream source differs.

You might find this helpful:

https://invisible-island.net/luit/luit.html#metrics

(Xorg copying ~2000 lines of code from an older version of luit
doesn't exactly improve the situation).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature


Bug#996973: Upload or ... Was: WIP

2022-01-07 Thread NG
Hi Geert,

> * Do another (and final?) upload to 
> https://mentors.debian.net/package/msc-generator/

Done, it is #3 as of now (I removed some old ones -- should I remove all
but the last one?). I skipped adding anything for now: the "examples"
thing is not yet released in upstream, that was an error on my packaging
side.

> * Notify me

+1

and thanks
/g



Bug#1003286: rlm_counter: Failed to open file /etc/freeradius/3.0/db.daily: Read-only file system

2022-01-07 Thread Sven Reissmann
Package: freeradius
Version: 3.0.21+dfsg-2.2+deb11u1
Severity: normal

Dear Maintainer,

when enabling the freeradius module "counter" (rlm_counter) in freeradius 
3.0.21+dfsg-2.2+deb11u1, the systemd service refuses to start with the
following error message, while at the same time, "freeradius -X" successfully 
starts freeradius in debug mode.

> rlm_counter: Failed to open file /etc/freeradius/3.0/db.daily: Read-only file 
> system

I assume the reason is the following directive in the systemd service:

> # We shouldn't be writing to the configuration directory
> ReadOnlyDirectories=/etc/freeradius/

However, in the module itself (/etc/freeradius/3.0/mods-available/counter),
the default filename for the database is:

> filename = ${db_dir}/db.daily

And in /etc/freeradius/3.0/radius.conf, ${db_dir} is set as:

> raddbdir = /etc/freeradius/3.0
> db_dir = ${raddbdir}


Steps to reproduce:

  * Install freeradius 
apt install freeradius

  * Enable rlm_counter 
cd /etc/freeradius/3.0/mods-enabled
ln -s ../mods-available/counter .

  * Restart freeradius
systemctl restart freeradius


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

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

Versions of packages freeradius depends on:
ii  freeradius-common  3.0.21+dfsg-2.2+deb11u1
ii  freeradius-config  3.0.21+dfsg-2.2+deb11u1
ii  libc6  2.31-13+deb11u2
ii  libcrypt1  1:4.4.18-4
ii  libct4 1.2.3-1
ii  libfreeradius3 3.0.21+dfsg-2.2+deb11u1
ii  libgdbm6   1.19-2
ii  libpam0g   1.4.0-9+deb11u1
ii  libperl5.325.32.1-4+deb11u2
ii  libreadline8   8.1-1
ii  libsqlite3-0   3.34.1-3
ii  libssl1.1  1.1.1k-1+deb11u1
ii  libsystemd0247.3-6
ii  libtalloc2 2.3.1-2+b1
ii  libwbclient0   2:4.13.13+dfsg-1~deb11u2
ii  lsb-base   11.1.0

Versions of packages freeradius recommends:
ii  freeradius-utils  3.0.21+dfsg-2.2+deb11u1

Versions of packages freeradius suggests:
pn  freeradius-krb5
pn  freeradius-ldap
pn  freeradius-mysql   
pn  freeradius-postgresql  
pn  freeradius-python3 
pn  snmp   

-- no debconf information

Best regards,
Sven.



Bug#1001668: downgrading severity

2022-01-07 Thread Gordon Ball
Reducing severity to `normal`, since this does not appear to happen
consistently. Looking through the CI logs, there are occasional failures
on ppc64el, but since it does not appear to happen consistently, I don't
_think_ this justifies RC severity, unless anyone can reproduce it in
actual usage.



Bug#1003284: RM: python-cement -- ROM; FTBFS, low-popcon

2022-01-07 Thread Michael Fladischer
Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please remove python-cement. It FTBFS and I'm no longer an active user.


-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmHYYycRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WoPOwgAvstmXmZsRC64kX+FxS3iaxEpPFgJ6MVL
ASDjH7oXCmQS3sAwOMefSnUicEsGBLX1+yT+VGz8fyVUnI7mronvt51yEoxpZYTs
D/5XZ25WSnD1xQz5dUZq88eGJAUB8IvUYT7yLivveI1dFOBspucZwbWnmGHPqwLR
KvTKTnUnKX2wyCBkF55twtjLP9u7YUV1ZSsH7Xj6dan/5DeitlygK2L1iRYpu2AD
BQ2iL92EiNTFC50sjTzkxKSx0XNDn25Dc7UA/B82Pkx1td2QDuq25HxBBm/v2M7q
6WvRrIBZdfTXH5OVQCO45UzPEQQGG20br0/q/QsNg0Tt6mOyRMR2Zw==
=//LX
-END PGP SIGNATURE-



Bug#1003285: RM: django-websocket-redis -- ROM; superseded by ASGI

2022-01-07 Thread Michael Fladischer
Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please remove django-websocket-redis, it has been technologically superseded by
ASGI and I'm no longer using it.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmHYY6MRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wp67QgAu1YHm37wVl9quaCkmRp7XhMqnFpVrgJp
oGPcxC8dGy4zViPqN5dwNwG7vmjgqLhJdVaTJmc45Bk2G3ir4yGiksWb7H34Mhuy
HTnKjPMkxHrYrSjj7BPCxAtsmuCiYB673EAx1QXMdswuzGVPZWOly3Wzw2EGeM5r
qmzfCdeDpE/3LvNrtkLnofeQBLIaPAJ/1sVYdZEJrKPYfoCargnxWsQygY41Z3UP
CmR/zIw+0l50FucY6eAfEXDOHKC0/1StD2r7JRBBekqnDaKLrR8AtqLl0hkglf3Y
h2bf7Hh/9fWsvVuvEjszs9e00JVSzo/oyeELA0CX5Q82RQesji/+Sg==
=g/+1
-END PGP SIGNATURE-



Bug#1003283: RM: python-django-x509 -- ROM; missing dependencies

2022-01-07 Thread Michael Fladischer
Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This package has benn in the archive but was mostly unusable because it depends
on a different implementation of JSONField than the one package in Debian. It
also misses openwisp_utils which is not packaged.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmHYYp0RHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WowQggAktiSYUeLTyjjGskJK7l6fZhzbNhCnITx
S49IvpwDTsV0nJ46CyRdOb0Fw4wPxk5F2PqqY5JfMgrffqg6EGcGwg76Z7BCs7u3
lizaV1HouLjTLskz+85JSi0FcD4LxRvBamevM+yXjbY3Z5SHJ7/DAigTuSzr8Xq5
Umvlt3FkfRx7ujvEJdNhfB59DCaOAUu0Ne4ioYU5ZRger5zkVXgAB/cZ2JaLFN9M
iahjUhWM9WjOU9P9y4yJ3Hrk/D9i1NQXl1NeyDP1RklcRr1+SwFO8L6H7EXOLABx
2w1necRQEqqZ8rW0/UVYQa7uRmr5jMP4aZqrmm1NG6ddQq4RE4MxyQ==
=Iqw9
-END PGP SIGNATURE-



Bug#1002023: Further test results

2022-01-07 Thread C.J. Plooy
I have some further test results:

Red Alert, Splinter Cell and GTA III work without issues (at least
without this particular issue).

Age of Empires II results in the same error, but only once you switch
from the game menus to the game itself. In my set-up, the screen
resolution of the game itself is different from the menus. Since I
tested Age of Empires II in desktop mode, the resolution change should
have resulted in a desktop window resize - as it did before the Debian
dist upgrade. However, it now results in the same crash as Flight
Simulator.



Bug#1003281: ITP: bakunbak -- Easily .bak a file or folder, then restore it.

2022-01-07 Thread Michael Webster
Package: wnpp
Severity: wishlist
Owner: Michael Webster 
X-Debbugs-Cc: debian-de...@lists.debian.org, miketwebs...@gmail.com

* Package name: bakunbak
  Version : 1.0.0
  Upstream Author : Michael Webster 
* URL : https://github.com/mtwebster/bakunbak
* License : GPL
  Programming Lang: Python
  Description : Easily .bak a file or folder, then restore it.

This is a simple convenience tool for making temporary 'backup'
copies of files or folders, by adding and removing .bak to their
filenames. A limited number of options allow copying instead of
moving, and forcing overwrite of existing files.

 - why is this package useful/relevant? For people who do frequent
   tests on packages that utilize configuration files or folders,
   backing up and restoring previous configurations can become
   tedious after a time. This reduces effort.
 - is it a dependency for another package? It is standalone..
 - Do you use it? Yes frequently for testing browser package
   updates.
 - If there are other packages providing similar functionality,
   how does it compare? I've found no other packages (though
   it's possible something exists in utility/bin package
   bundles that doesn't get mentioned in package descriptions.
 - How do you plan to maintain it? It is a simple package, I
   will maintain it myself.
 - Are you looking for co-maintainers? No.
 - Do you need a sponsor? I imagine so, as I've not previously
   been involved in packaging for Debian.



Bug#1003280: thunderbird: TB 91 won't read/apply configuration files in /etc/thunderbird/pref/

2022-01-07 Thread Nika Marisa Mies
Package: thunderbird
Version: 1:91.4.1-1~deb9u1
Severity: normal

Dear Maintainer,

Since the upgrade to Thunderbird 91, custom configuration in 
"/etc/thunderbird/pref/" such as the attached file won't be read/applied.

Earlier versions did apply this configration.

I believe  the patch 
"Add-another-preferences-directory-for-applications-p.patch" to be faulty: the 
addtional directory is added inside an if-clause as well as inside an ifedf.
In my believe it should be added unconditionally (i.e. after the "#endif" 
instead of inside).

Thank you very much.

-- System Information:
Debian Release: 9.13
  APT prefers oldoldstable-debug
  APT policy: (500, 'oldoldstable-debug'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.221.wap (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages thunderbird depends on:
ii  debianutils 4.8.1.1
ii  fontconfig  2.11.0-6.7+b1
ii  libatk1.0-0 2.22.0-1
ii  libbz2-1.0  1.0.6-8.1
ii  libc6   2.24-11+deb9u4-mi
ii  libcairo-gobject2   1.14.8-1+deb9u1
ii  libcairo2   1.14.8-1+deb9u1
ii  libdbus-1-3 1.10.32-0+deb9u1
ii  libdbus-glib-1-20.108-2
ii  libevent-2.0-5  2.0.21-stable-3
ii  libffi6 3.2.1-6
ii  libfontconfig1  2.11.0-6.7+b1
ii  libfreetype62.6.3-3.2+deb9u2
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0  2.36.5-2+deb9u2
ii  libglib2.0-02.50.3-2+deb9u2
ii  libgtk-3-0  3.22.11-1
ii  libjson-c3  0.12.1-1.1+deb9u1
ii  libpango-1.0-0  1.40.5-1
ii  libx11-62:1.6.4-3+deb9u4
ii  libx11-xcb1 2:1.6.4-3+deb9u4
ii  libxcb-shm0 1.12-1
ii  libxcb1 1.12-1
ii  libxext62:1.3.3-1+b2
ii  libxrender1 1:0.9.10-1
ii  psmisc  22.21-2.1+b2
ii  x11-utils   7.7+3+b1
ii  zenity  3.22.0-1+b1
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages thunderbird recommends:
ii  hunspell-de-de [hunspell-dictionary] 20161207-1
ii  hunspell-en-gb [hunspell-dictionary] 1:5.2.5-1
ii  hunspell-en-us [hunspell-dictionary] 20070829-7
ii  hunspell-fr-classical [hunspell-dictionary]  1:5.7-1

Versions of packages thunderbird suggests:
pn  apparmor  
ii  fonts-lyx 2.2.2-1
ii  libgssapi-krb5-2  1.15-1+deb9u3

-- Configuration Files:
/etc/thunderbird/pref/thunderbird.js changed:
// This is the Debian specific preferences file for Mozilla Thunderbird
// You can make any change in here, it is the purpose of this file.
// You can, with this file and all files present in the directory
//
//  /etc/thunderbird/pref directory
//
// override any preference that is present in the directory
//
//  /usr/lib/thunderbird/defaults/pref
//
// While your changes will be kept on upgrade if you modify files in
// /etc/thunderbird/pref, please note that they won't be kept if you
// do them in /usr/lib/thunderbird/defaults/pref.
/*
   use this if you have no access to gnome configuration
   as described on http://www.jwsdot.com/debian/faq.html#q9
   and don't care about debian default settings.
*/
// pref("network.protocol-handler.app.http","mozilla-firefox");
// pref("network.protocol-handler.app.https","mozilla-firefox");
// Use LANG environment variable to choose locale from system
// The old environment setting 'pref("intl.locale.matchOS", true);' is
// currently not working anymore. The new introduced setting
// 'intl.locale.requested' is now used for this. Setting an empty string is
// pulling the system locale into Thunderbird.
pref("intl.locale.requested", "");
/*
   uncomment this if you want your browser configured as
   your default by means of the debian alternatives mechanism
*/
// pref("network.protocol-handler.app.http","x-www-browser");
// pref("network.protocol-handler.app.https","x-www-browser");
// This setting is a workaround for some crashes inside the JS engine.
// By this Thunderbird will use more memory and acting slower as the sharing
// memory between interacting JS files is disabled.
pref ("javascript.options.baselinejit", false);
// Uncomment the follwing setting if you want to have a extra mail header field
// for X-Debbugs-Cc, only needed in case you have to work with the Debian
// Bug Tracking System more deeply
//pref("mail.compose.other.header", "X-Debbugs-Cc");
/*
   use this to tune your gtk2 mouse feeling
*/
// pref("widget.gtk2.dnd.threshold",25);
// pref("widget.gtk2.double_click_timeout", 300);
pref("intl.locale.requested", "");
//Auswahl, welche Addons zu aktivieren sind beim Start nicht zeigen
pref("extensions.shownSelectionUI", true);
//Mailprovider Auswahl abstellen
pref("mail.provider.enabled", false);
//Spamfilter-Deaktivieren
pref("mail.spam.logging.enabled", false);
// Disable default mail client check

Bug#1003279: ITP: onevpl -- oneAPI Video Processing Library

2022-01-07 Thread Timo Aaltonen
Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: onevpl
  Version : 2022.0.2
  Upstream Author : Intel
* URL : https://github.com/oneapi-src/oneVPL
* License : MIT
  Programming Lang: C++
  Description : oneAPI Video Processing Library

 The oneAPI Video Processing Library (oneVPL) provides a single video processing
 API for encode, decode, and video processing that works across a wide range of
 accelerators.
 .
 This repository contains the following components of oneVPL:
 .
 - Copies of the oneVPL Specification API header files
 - oneVPL dispatcher
 - Examples demonstrating API usage
 - oneVPL command line tools
 .
 This project is part of the larger oneAPI project.



Bug#1003204: set the sticky bit on some InRelease files

2022-01-07 Thread Marc Haber
On Thu, Jan 06, 2022 at 02:18:47PM +0100, Eduard Bloch wrote:
> Please check your setting of "FilePerms" in the configuration. That
> picture can only be explained if some files were created earlier and
> some files were created later, and there was a change of FilePerms value
> inbetween.

The machine was recently upgraded from buster to bullseye. No
configuration, neithre old nor new, contains a "FilePerms" setting, the
only matches when grepping are the commented example.

Greetings
Marc

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



Bug#1003278: libreoffice-texmaths: Does not work

2022-01-07 Thread Joachim Zobel
Package: libreoffice-texmaths
Version: 0.43-2.1
Severity: important

Hi.

The subject is actually a quite reasonable description :-)

How to reproduce:
I open a document (I tested writer and impress)
I press the pi button
Expected:
A editor for entering a latex formula opens
Actual:
I get an error message (see attachment) and the macro editor opens

This looks like a missing dependency to me, but providing a full list of
installed packages seems a bit too much for now.

Sincerely,
Joachim

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

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

Versions of packages libreoffice-texmaths depends on:
ii  libreoffice-draw  1:7.0.4-4+deb11u1
ii  texlive   2020.20210202-3

libreoffice-texmaths recommends no packages.

libreoffice-texmaths suggests no packages.


Bug#764901: linux-image-3.16-2-amd64: Suspend results in shutdown

2022-01-07 Thread Dominique Dumont
On Friday, 7 January 2022 12:29:21 CET Diederik de Haas wrote:
> You went to all that trouble to find a 7+ year old bug, with a title that
> doesn't convey a link with dkms compilation issue, unarchive the bug and
> respond to that, but you missed the (1st) response of a kernel maintainer?

Not exactly. I'm stumbled upon this bug while upgrading an old system in 
production. I did not dare reboot the system without fixing initramfs creation.

This bug report actually gave me a hint that dkms could help, so I've added 
the work-around I've found to this bug report.

I hope this will save some time to the next ops that will have to upgrade a 
Debian 7 production system in vmware.

All the best



Bug#270751: HI

2022-01-07 Thread Rosemary Allan
Hello my dear I am Rosemary Allan, I have  good news for you, please can
you kindly get back to me


Bug#1003277: RFS: memtest86+/5.31b-1 [QA] -- thorough real-mode memory tester

2022-01-07 Thread Fabio Fantoni

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "memtest86+":

 * Package name    : memtest86+
   Version : 5.31b-1
   Upstream Author : Samuel Demeulemeester 
 * URL : http://www.memtest.org/
 * License : GPL-2
 * Vcs : https://salsa.debian.org/debian/memtest86plus
   Section : misc

It builds those binary packages:

  memtest86+ - thorough real-mode memory tester

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


  https://mentors.debian.net/package/memtest86+/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/memtest86+/memtest86+_5.31b-1.dsc


New upstream beta version (with relevant additions and fixes), also got 
fixes from coreboot, fedora, suse, gentoo, ubuntu, made further 
additions and improvements to packaging, readme and grub2 configuration, 
I also did some tests on PCs in these weeks and is generally better than 
the current version on stable/testing/unstable. The experimental 
multiboot is still bugged (on my tests) after the patch from coreboot 
(for different problem) but it was also before (on 
stable/testing/unstable packages), and as being disabled by default I 
don't think I should delay a possible upload on experimental yet given 
the numerous fixes that this build includes.



Changes since the last upload:

 memtest86+ (5.31b-1) experimental; urgency=medium
 .
   [ Fabio Fantoni ]
   * QA upload.
   * New upstream version 5.31b (Closes: #989030, #977217)
   * Merge from ubuntu:
 - Use elf version by default that should works on major of system.
 - Drop the multiboot image from the GRUB menu for now, since it's
   experimental and has known problems detecting all memory on some
   systems at the moment.
 - Support localization of GRUB menu entries.
 - Don't present in GRUB menu on EFI systems, since it won't work.
   (Closes: #695246)
 - Close FD 3 when invoking update-grub.
   * Warn that don't support EFI instead of exit silently (LP: 1863940)
   * Don't add grub2 entries if GRUB_DISABLE_MEMTEST=true is present
 in /etc/default/grub (LP: #420967)
   * Make possible disable serial with GRUB_MEMTEST_DISABLE_SERIAL,
 enable multiboot with GRUB_MEMTEST_ENABLE_MULTIBOOT and add
 custom serial parameters with GRUB_MEMTEST_SERIAL_PARAMS
 (Closes: #898636, #612371)
   * Specify on grub2 menu entries when elf and bin are used
   * d/control: Remove hwtools and kernel-patch-badram from suggests.
   * d/copyright: add Upstream-Name, Upstream-Contact and Source fields
   * Bumped Standards-Version to 4.6.0
   * d/patches:
 - update multiboot patch from coreboot patch based on the one of
   Vladimir Serbinenko and refreshed for 5.31b (Closes: #568176)
 - refresh memtest86+-5.01-O0.patch
 - disable memtest86+-5.01-array-size.patch and gcc-5 as seems not
   needed with newer upstream version
 - refresh serial-console-fix.patch
 - add test-random-cflags.patch: use CFLAGS with random.o for
   maintain flags like -fno-stack-protector
 - add fix-gcc8-freeze-crash.patch: runtime fix for gcc>=8
   freeze/crash
 - add discard-note_gnu_property.patch: discards the
   ".note.gnu.property" section that causes crash in some cases
 .
   [ Jérémy Bobbio ]
   * Make the package build reproducibly:
 - Add a patch to make ISO image reproducible.
 - Set the build date to the latest debian/changelog entry in
   debian/rules. (Closes: #783515)

Regards,
--
  Fabio Fantoni



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1003272: lintian: chokes on overrides with "(" but no ")"

2022-01-07 Thread Felix Lechner
Hi,

On Fri, Jan 7, 2022 at 2:57 AM Tobias Frost  wrote:
>
> Unmatched ( in regex; marked by <-- HERE in m/( <-- HERE

That is a consequence of switching to Text::Glob for overrides. I
would suggest '[(]' and '[)]' as probable fixes (backslashes do not
work) but more changes are coming to override files.

We recently introduced 'pointed hints' which allow live links on our
website to sources.d.o and soon others. In terminal output, they are
shown as

tag annotation [file pointer]

but that format is not great for overrides.

We will likely allow globbing on the file pointer, regular expressions
on the annotation and require literal matches for the tag name. To
keep those fields separate, we may switch to a Deb822 format for
override files, but hope to provide automated tools for migration and
management similar to those we already use internally to interactively
recalibrate Lintian's test suite.

Kind regards
Felix Lechner



Bug#1003255: (no subject)

2022-01-07 Thread Peter Mueller
Thanks, Hilmar!
I sent the report by e-mail to PSTricks maintainers and already got an answer 
from them. It seems to me they see it as a warning rather than a bug. Hoewever, 
in my view, compiling a LaTeX document without transparency and getting a 
warning about transparency down the toolchain with default settings is strange. 
You could have been (perhaps, legitimately) warned if there is real 
transparency in your LaTeX document, but if you don't have transparency or 
don't know whether you have transparency (e.g., because your document is huge 
or written by someone else), an excessful warning is, well, more bothering than 
helpful. I'd prefer that the transparency code doesn't even get into the 
Postscript file if transparency isn't used in the source LaTeX document.
Cheers,
Peter
07.01.2022, 12:13, Hilmar Preuße < mailto:hill...@web.de hill...@web.de >
Control: severity -1 minor Am 07.01.2022 um 02:40 teilte Peter Mueller mit: HI 
Peter, > Package: texlive-pstricks > Version: 2021.20211217-1 > Bug report: 
https://tex.stackexchange.com/questions/629314 
https://tex.stackexchange.com/questions/629314 > 
https://tex.stackexchange.com/questions/629314 
https://tex.stackexchange.com/questions/629314. The PStricks > maintainers have 
been informed, too, just in case they don't have an > update for this issue 
yet. > If you forwarded the issue to pstricks, could you leave a link here? 
Hilnar -- sigfault


Bug#1003271: lintian: skip-systemd-native-flag-missing-pre-depends still relevant?

2022-01-07 Thread Felix Lechner
Hi,

On Fri, Jan 7, 2022 at 2:51 AM Tobias Frost  wrote:
>
> the description of the tag has a bug:

I just made these changes:

https://salsa.debian.org/lintian/lintian/-/commit/f5107b60f4c7bbb9762dd375e3513cf54b3bac0d

>From the commit message:

The tag combines two checks in one. First, it requires that a Pre-Depends on
was declared and, second, that the version is sufficient. The reporting party
pointed out that the version requirement is satisfied in oldstable, so the
version requirement was dropped from both the code and from the description.

The overall check that a Pre-Depends was declared, however, may still be
sensible to keep.

On the website 73 sources currently provoke the tag, but we cannot if the
declaration is missing or just does not satisfy the minimum version requirement.
Let's see how the tag performs after this change.

Thanks to Tobias Frost for bringing the matter to our attention!

Kind regards
Felix Lechner



Bug#1003195: enlightenment: E crashes after coming back from a different VTY

2022-01-07 Thread Robert Waldner

On Thu, 06 Jan 2022 22:26:53 -0800, Ross Vandegrift writes:
>On Thu, Jan 06, 2022 at 12:32:44AM +0100, Robert Waldner wrote:
>> F'rex, switching to VTY1 (text console) works as expected, but after
>> switching back to Enlightenment on VTY7 E crashes.
>> Same after switching back to VTY7 from VTY8 (where a different user runs
>> XFCE4).

>Switching to a different vty and back works fine for me, but I don't have
>another desktop session running anywhere.  Does the issue still happen if you
>only have one session running?

Good point: yes, it does.

>> Backtrace log / ~/.e-crashdump.txt from when I get the back screen/red
>> writing situation:

>It looks like you're missing the debug symbols.  Please follow the instructions
>at https://wiki.debian.org/HowToGetABacktrace and try again.

I've installed enlightenment-dbgsym, but can't get Enlightenment 
started via gdb:
--
$ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex 'threa
d apply all bt full' --args /usr/bin/startx /usr/bin/enlightenment_start

"0x7ffc0cb4c140s": not in executable format: file format not recognized
No executable file specified.
Use the "file" or "exec-file" command.
No stack.
No stack.
--

~/.e-crashdump.txt (attached) looks filled with a bit more info, though.

I've then started E normally via lightdm, and attached to the (or
 rather "a", there's a couple) running 
 /usr/bin/enlightenment process with gdb as per
 https://wiki.debian.org/XStrikeForce/XserverDebugging  and did a
 backtrace there, gdb.txt is also attached.

Hope that helps.

Thanks for taking an interest!

Kind regards,
Robert

Continuing.

Thread 1 "enlightenment" received signal SIGINT, Interrupt.
0x7ffaf92af872 in __libc_pause () at ../sysdeps/unix/sysv/linux/pause.c:29
29  in ../sysdeps/unix/sysv/linux/pause.c
#0  0x7ffaf92af872 in __libc_pause () at 
../sysdeps/unix/sysv/linux/pause.c:29
resultvar = 18446744073709551102
sc_cancel_oldtype = 0
#1  0x7ffaf92b0140 in  () at 
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x55a77f727280 in  ()
#3  0x7ffaeddff3b6 in  () at 
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#4  0x7ffaeddf1d1d in  () at 
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#5  0x7ffaeddf2399 in  () at 
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#6  0x7ffaeddc9098 in  () at 
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#7  0x7ffaeddcb4a0 in  () at 
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#8  0x7ffaedd30bc5 in  () at 
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#9  0x7ffaef55b688 in  () at /lib/x86_64-linux-gnu/libEGL_nvidia.so.0
#10 0x7ffaef4ff59f in  () at /lib/x86_64-linux-gnu/libEGL_nvidia.so.0
#11 0x7ffaf4324bbb in eglReleaseThread () at 
/lib/x86_64-linux-gnu/libEGL.so.1
#12 0x7ffaf4375cb3 in  () at 
/usr/lib/x86_64-linux-gnu/evas/modules/engines/gl_x11/v-1.25/module.so
#13 0x7ffaf437320f in  () at 
/usr/lib/x86_64-linux-gnu/evas/modules/engines/gl_x11/v-1.25/module.so
#14 0x7ffaf9c928c8 in efl_canvas_output_del () at 
/lib/x86_64-linux-gnu/libevas.so.1
#15 0x7ffaf9bfb305 in  () at /lib/x86_64-linux-gnu/libevas.so.1
#16 0x7ffaf9f75d6a in efl_destructor () at /lib/x86_64-linux-gnu/libeo.so.1
#17 0x7ffaf9f7f054 in efl_del () at /lib/x86_64-linux-gnu/libeo.so.1
#18 0x7ffaf95231f2 in _ecore_evas_free () at 
/lib/x86_64-linux-gnu/libecore_evas.so.1
#19 0x55a77d250146 in _e_comp_free (c=0x55a77f254d70) at 
../src/bin/e_comp.c:847
#20 0x55a77d2f3e58 in e_object_unref (obj=0x55a77f254d70) at 
../src/bin/e_object.c:153
ref = 0
__func__ = "e_object_unref"
#21 0x55a77d2f3f4d in e_object_del (obj=) at 
../src/bin/e_object.c:60
__func__ = "e_object_del"
#22 0x55a77d2538f4 in e_comp_shutdown () at ../src/bin/e_comp.c:1434
l = 
ll = 
ec = 
#23 0x55a77d2e66c8 in _e_main_screens_shutdown () at 
../src/bin/e_main.c:1585
#24 0x55a77d2e6ccb in _e_main_shutdown (errcode=errcode@entry=0) at 
../src/bin/e_main.c:1157
i = 
#25 0x55a77d226921 in main (argc=, argv=) at 
../src/bin/e_main.c:1119
waslocked = 0 '\000'
strshare = 
s = 
action = 
  {__sigaction_handler = {sa_handler = 0x55a77d30cda0 , 
sa_sigaction = 0x55a77d30cda0 }, sa_mask = {__val = {0 }}, sa_flags = -1073741820, sa_restorer = 0x0}
__func__ = "main"

Thread 4 (Thread 0x7f2f49165700 (LWP 2598539) "Eanimator-timer"):
#0  0x7f2f4df9e116 in epoll_wait (epfd=48, events=0x7f2f49164760, 
maxevents=2, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
#1  0x7f2f4eca071b in  () at /lib/x86_64-linux-gnu/libecore.so.1
#2  0x7f2f4ece4cc1 in  () at /lib/x86_64-linux-gnu/libecore.so.1
#3  0x7f2f4ede1e0a in  () at /lib/x86_64-linux-gnu/libeina.so.1
#4  0x7f2f4e06dea7 in start_thread (arg=) at 
pthread_create.c:477
ret = 
pd = 
unwind_buf = 

Bug#1003276: bluetoothd: assertion failure, killed with status 6/ABRT

2022-01-07 Thread Vincent Lefevre
Package: bluez
Version: 5.62-2
Severity: important

bluetoothd suddenly stopped working. The journalctl logs:

Jan 07 13:06:56 zira bluetoothd[1004]: src/profile.c:record_cb() Unable to get 
Hands-Free Voice gateway SDP record: Host is down
Jan 07 13:07:49 zira bluetoothd[1004]: Disconnected from D-Bus. Exiting.
Jan 07 13:07:49 zira bluetoothd[1004]: Endpoint unregistered: sender=:1.48 
path=/MediaEndpoint/A2DPSink/sbc
Jan 07 13:07:49 zira bluetoothd[1004]: Endpoint unregistered: sender=:1.48 
path=/MediaEndpoint/A2DPSink/sbc_xq_453
Jan 07 13:07:49 zira bluetoothd[1004]: Endpoint unregistered: sender=:1.48 
path=/MediaEndpoint/A2DPSource/sbc_xq_453
Jan 07 13:07:49 zira bluetoothd[1004]: Endpoint unregistered: sender=:1.48 
path=/MediaEndpoint/A2DPSink/sbc_xq_512
Jan 07 13:07:49 zira bluetoothd[1004]: Endpoint unregistered: sender=:1.48 
path=/MediaEndpoint/A2DPSource/sbc_xq_512
Jan 07 13:07:49 zira bluetoothd[1004]: Endpoint unregistered: sender=:1.48 
path=/MediaEndpoint/A2DPSink/sbc_xq_552
Jan 07 13:07:49 zira bluetoothd[1004]: Endpoint unregistered: sender=:1.48 
path=/MediaEndpoint/A2DPSource/sbc_xq_552
Jan 07 13:07:49 zira bluetoothd[1004]: Endpoint unregistered: sender=:1.48 
path=/MediaEndpoint/A2DPSource/sbc
Jan 07 13:07:49 zira acpid[740]: input device has been disconnected, fd 23
Jan 07 13:07:50 zira bluetoothd[1004]: dbus[1004]: arguments to 
dbus_message_new_method_call() were incorrect, assertion "destination == NULL 
|| _dbus_check_is_valid_bus_name (destination)" failed in file 
../../../dbus/dbus-message.c line 1364.
Jan 07 13:07:50 zira bluetoothd[1004]: This is normally a bug in some 
application using the D-Bus library.
Jan 07 13:07:50 zira bluetoothd[1004]:   D-Bus not built with -rdynamic so 
unable to print a backtrace
Jan 07 13:07:50 zira systemd[1]: bluetooth.service: Main process exited, 
code=killed, status=6/ABRT
Jan 07 13:07:50 zira systemd[1]: bluetooth.service: Failed with result 'signal'.

I have 2 bluetooth devices: speakers that are permanently connected,
and headphones, which normally get connected when I switch them on.
During a test, I noticed that the headphones were not connected to
my laptop, but only to my phone. I eventually disabled the bluetooth
on my phone, and it seems that this was at this time that bluetoothd
crashed, but I'm not sure (I don't see what else could trigger the
crash). I suppose that at this time, the headphones tried to connect
to the laptop.

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 bluez depends on:
ii  dbus 1.12.20-3
ii  init-system-helpers  1.61
ii  kmod 29-1
ii  libasound2   1.2.5.1-1
ii  libc62.33-1
ii  libdbus-1-3  1.12.20-3
ii  libdw1   0.186-1
ii  libglib2.0-0 2.70.2-1
ii  libreadline8 8.1-2
ii  libudev1 249.7-1
ii  lsb-base 11.1.0
ii  udev 249.7-1

bluez recommends no packages.

Versions of packages bluez suggests:
ii  pulseaudio-module-bluetooth  15.0+dfsg1-3

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Bug#1003275: mir: FTBFS: /<>/src/client/lttng/input_receiver_report.cpp:80:1: internal compiler error: maximum number of generated reload insns per insn achieved (90)

2022-01-07 Thread Sebastian Ramacher
Source: mir
Version: 1.8.0+dfsg1-19
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

mir FTBFS on amd64:
| [ 48%] Building CXX object 
src/client/lttng/CMakeFiles/mirclientlttng-static.dir/shared_library_prober_report.cpp.o
| cd /<>/build-amd64/src/client/lttng && /usr/bin/c++ 
-DCLIENT_PLATFORM_VERSION=\"MIR_CLIENT_PLATFORM_5\" -DEGL_NO_X11 -DLOG_NDEBUG=1 
-DLTTNG_UST_HAVE_SDT_INTEGRATION -DMESA_EGL_NO_X11_HEADERS 
-DMIR_CLIENT_PLATFORM_PATH=\"/usr/lib/x86_64-linux-gnu/mir/client-platform/\" 
-DMIR_DRMMODEADDFB_HAS_CONST_SIGNATURE 
-DMIR_LOG_COMPONENT_FALLBACK=\"mirclient\" 
-DMIR_SERVER_EGL_OPENGL_API=EGL_OPENGL_ES_API 
-DMIR_SERVER_EGL_OPENGL_BIT=EGL_OPENGL_ES2_BIT 
-DMIR_SERVER_GLEXT_H="" -DMIR_SERVER_GL_H="" 
-DMIR_VERSION_MAJOR=1 -DMIR_VERSION_MICRO=2 -DMIR_VERSION_MINOR=7 
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -I/<>/include/core 
-I/<>/include/common -I/<>/include/cookie 
-I/<>/src/include/common 
-I/<>/build-amd64/src/capnproto 
-I/<>/build-amd64/src/protobuf 
-I/<>/build-amd64/src/client -I/<>/include/platform 
-I/<>/include/client -I/<>/src/include/client 
-I/<>/src/include/cookie -I/usr/include/libdrm 
-I/<>/src/client/lttng -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -pthread -g -std=c++14 -Wall -fno-strict-aliasing  
-Wnon-virtual-dtor -Wextra -fPIC -Wno-mismatched-tags -Wno-psabi -flto 
-ffat-lto-objects -Wno-error=missing-field-initializers 
-Wno-error=unused-function -std=c++14 -MD -MT 
src/client/lttng/CMakeFiles/mirclientlttng-static.dir/shared_library_prober_report.cpp.o
 -MF CMakeFiles/mirclientlttng-static.dir/shared_library_prober_report.cpp.o.d 
-o CMakeFiles/mirclientlttng-static.dir/shared_library_prober_report.cpp.o -c 
/<>/src/client/lttng/shared_library_prober_report.cpp
| during RTL pass: reload
| /<>/src/client/lttng/input_receiver_report.cpp: In member 
function ‘mir::client::lttng::InputReceiverReport::report_touch(MirInputEvent 
const*) const’:
| /<>/src/client/lttng/input_receiver_report.cpp:80:1: internal 
compiler error: maximum number of generated reload insns per insn achieved (90)
|80 | }
|   | ^
| 0x7f68588597ec __libc_start_main
|   ../csu/libc-start.c:332
| Please submit a full bug report,
| with preprocessed source if appropriate.
| Please include the complete backtrace with any bug report.
| See  for instructions.

See
https://buildd.debian.org/status/fetch.php?pkg=mir=amd64=1.8.0%2Bdfsg1-19%2Bb2=1641511010=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#996973: Upload or ... Was: WIP

2022-01-07 Thread Geert Stappers
Hi Gabor,

You wrote:
> Working on build differences
> between upstream Git repo and tarball contents.

Those difference have resolved good enough for now.
I can now cleanly build from git.

The only lintian message I get is:
  W: msc-generator-dbgsym: elf-error In program
  headers: Unable to find program interpreter name
  [usr/lib/debug/.build-id/a0/a796cd48e923166adf698f10e5a484d7ea93a0.debug]

I agree with you that is bugreport #1000449
( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000449 )

Also is -doc package generated. Again good work.

You mentioned (outside of this bugreport) something about "examples".
Should that be included in the first upload?  I tend to "non blocking,
let's upload".  Also because "perfect is the enemy of good".
Express your thoughts about.

Idea/Proposal/Brainfart:
* Add what you want to add.
* Do another (and final?) upload to 
https://mentors.debian.net/package/msc-generator/
* Notify me


Groeten
Geert Stappers
DD
-- 
Silence is hard to parse



Bug#1001067: synaptic: Crushing when searching. Error: Segmentation Fault

2022-01-07 Thread Fabio Fantoni
Hi, I saw this package marked for autoremoval (from testing) on 16 
January for this RC bug, it is widely used (looking popcon), including 
by me.


Is there any news on this?

Thanks for any reply.



OpenPGP_signature
Description: OpenPGP digital signature


Bug#986564: evolution: crash in camel_imapx_folder_set_mailbox

2022-01-07 Thread Peter van Dijk
I have taken `apt-get source evolution-data-server` on an up to date Bullseye 
system, and imported the patch Chris mentioned above. The package I built from 
that has been stable for several days now.

Please find my diff attached. I hope the maintainer can import it into Bullseye.

commit 77914836bb483673261377a737cfb8f72efff81c
Author: Peter van Dijk 
Date:   Wed Jan 5 13:51:23 2022 +0100

import upstream patch to fix Evolution crashes

diff --git a/debian/changelog b/debian/changelog
index 0a21d5f..e60e774 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+evolution-data-server (3.38.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Import https://gitlab.gnome.org/GNOME/evolution-data-server/-/commit/1f1017492
+to fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986564
+
+ -- Peter van Dijk   Wed, 05 Jan 2022 13:49:49 +0100
+
 evolution-data-server (3.38.3-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/libcamel-1.2-62.symbols b/debian/libcamel-1.2-62.symbols
index 467511e..0cf7260 100644
--- a/debian/libcamel-1.2-62.symbols
+++ b/debian/libcamel-1.2-62.symbols
@@ -1359,6 +1359,8 @@ libcamel-1.2.so.62 libcamel-1.2-62 #MINVER#
  camel_util_bdata_get_string@Base 3.24.1
  camel_util_bdata_put_number@Base 3.24.1
  camel_util_bdata_put_string@Base 3.24.1
+ camel_utils_weak_ref_free@Base 3.38.3-1.1
+ camel_utils_weak_ref_new@Base 3.38.3-1.1
  camel_uudecode_step@Base 3.19.92
  camel_uuencode_close@Base 3.19.92
  camel_uuencode_step@Base 3.19.92
diff --git a/debian/patches/evolution-crash.patch b/debian/patches/evolution-crash.patch
new file mode 100644
index 000..0270049
--- /dev/null
+++ b/debian/patches/evolution-crash.patch
@@ -0,0 +1,253 @@
+import https://gitlab.gnome.org/GNOME/evolution-data-server/-/commit/1f1017492
+
+this fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986564
+--- a/src/camel/camel-folder.c
 b/src/camel/camel-folder.c
+@@ -152,50 +152,61 @@
+ 	camel_folder_synchronize_sync (folder, FALSE, cancellable, error);
+ }
+ 
++static void
++folder_schedule_store_changes_job (CamelFolder *folder)
++{
++	CamelSession *session;
++	CamelStore *parent_store;
++
++	g_return_if_fail (CAMEL_IS_FOLDER (folder));
++
++	parent_store = camel_folder_get_parent_store (folder);
++	session = parent_store ? camel_service_ref_session (CAMEL_SERVICE (parent_store)) : NULL;
++	if (session) {
++		gchar *description;
++
++		/* Translators: The first “%s” is replaced with an account name and the second “%s”
++		   is replaced with a full path name. The spaces around “:” are intentional, as
++		   the whole “%s : %s” is meant as an absolute identification of the folder. */
++		description = g_strdup_printf (_("Storing changes in folder “%s : %s”"),
++			camel_service_get_display_name (CAMEL_SERVICE (parent_store)),
++			camel_folder_get_full_name (folder));
++
++		camel_session_submit_job (session, description,
++			folder_store_changes_job_cb,
++			g_object_ref (folder), g_object_unref);
++
++		g_free (description);
++	}
++
++	g_clear_object ();
++}
++
+ static gboolean
+-folder_schedule_store_changes_job (gpointer user_data)
++folder_schedule_store_changes_job_cb (gpointer user_data)
+ {
+-	CamelFolder *folder = user_data;
++	GWeakRef *weak_ref = user_data;
+ 	GSource *source;
++	CamelFolder *folder;
+ 
+ 	source = g_main_current_source ();
+ 
+ 	if (g_source_is_destroyed (source))
+ 		return FALSE;
+ 
+-	g_return_val_if_fail (CAMEL_IS_FOLDER (folder), FALSE);
+-
+-	g_mutex_lock (>priv->store_changes_lock);
+-
+-	if (folder->priv->store_changes_id == g_source_get_id (source)) {
+-		CamelSession *session;
+-		CamelStore *parent_store;
+-
+-		folder->priv->store_changes_id = 0;
+-
+-		parent_store = camel_folder_get_parent_store (folder);
+-		session = parent_store ? camel_service_ref_session (CAMEL_SERVICE (parent_store)) : NULL;
+-		if (session) {
+-			gchar *description;
++	folder = g_weak_ref_get (weak_ref);
++	if (folder) {
++		g_mutex_lock (>priv->store_changes_lock);
+ 
+-			/* Translators: The first “%s” is replaced with an account name and the second “%s”
+-			   is replaced with a full path name. The spaces around “:” are intentional, as
+-			   the whole “%s : %s” is meant as an absolute identification of the folder. */
+-			description = g_strdup_printf (_("Storing changes in folder “%s : %s”"),
+-camel_service_get_display_name (CAMEL_SERVICE (parent_store)),
+-camel_folder_get_full_name (folder));
+-
+-			camel_session_submit_job (session, description,
+-folder_store_changes_job_cb,
+-g_object_ref (folder), g_object_unref);
+-
+-			g_free (description);
++		if (folder->priv->store_changes_id == g_source_get_id (source)) {
++			folder->priv->store_changes_id = 0;
++			folder_schedule_store_changes_job (folder);
+ 		}
+ 
+-		g_clear_object ();
+-	}
++		g_mutex_unlock (>priv->store_changes_lock);
+ 
+-	g_mutex_unlock (>priv->store_changes_lock);
++		

Bug#1003274: ITP: sentrypeer -- SIP peer to peer honeypot for VoIP

2022-01-07 Thread Gavin Henry
Package: wnpp
Severity: wishlist
Owner: Gavin Henry 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: sentrypeer
  Version : N/A; reported 2022-01-07
  Upstream Author : Gavin Henry 
* URL : https://sentrypeer.org
* License : GPLv2 or GPLv3
  Programming Lang: C
  Description : SIP peer to peer honeypot for VoIP
   SentryPeer is a distributed list of bad IP addresses and phone numbers
   collected via a SIP Honeypot.
   This is basically a fraud detection tool. It lets bad actors try to make
   phone calls and saves the IP address they came from and number they
   tried to call. Those details are then used to block them at the service
   providers network and the next time a user/customer tries to call a
   collected number, it's blocked.
   .
   Traditionally this data is shipped to a central place, so you don't own
   the data you've collected. This project is all about Peer to Peer sharing
   of that data. The user owning the data and various Service Provider /
   Network Provider related feeds of the data is the key bit for me. I'm
   sick of all the services out there that keep it and sell it. If you've
   collected it, you should have the choice to keep it and/or opt in to
   share it with other SentryPeer community members via p2p methods.

   I intend to package this and libosip2 under the Debian VoIP Team.
   libosip2 needs updating.

   I am looking for a sponsor too.

   Thanks,
   Gavin.



Bug#989705: Suspend to RAM hangs computer with nouveau driver and kernel 5.10.0-7-amd64 / 5.10.0-8-amd64

2022-01-07 Thread Jens Kaupp
Hello,

I have the same suspend issue with newer Kernels.
System:
Thinkpad T410
Intel i5 M

So I'm reluctant to upgrade my system to Debian 11.

<<... I configured grub to start the kernel with the parameter
init_on_alloc=0 >>

This method worked on my system (tryed with EndevourOS).

Thanks AchilleL.

Now I have to investigate what the purpose of init_on_alloc=0 is ;-)

Cheers!
Jens

On Tue, 31 Aug 2021 23:13:33 +0200 Achille L <
computer.enthusias...@gmail.com> wrote:
> Hello,
>
> I suppose I have identified that the issue was related to the
> activation of the config parameter CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y
> in Debian Kernel 5.10.0-8-amd64 from Debian Bullseye 11.0 (it was
> disabled in the Debian kernel 4.19.0 from Debian Buster 10.11). This
> parameter was activated in Debian wit
h linux (5.8.3-1~exp1)
> experimental on Mon, 24 Aug 2020 01:23:22 +0100 (see
>
https://metadata.ftp-master.debian.org/changelogs//main/l/linux/linux_5.10.46-4_changelog
)
>
> I discovered it bisecting (by hand) the diff of a working kernel
> config file for Debian Kernel 5.10.0-8-amd64 (generated by me from
> Debian kernel source code with make makeoldconfig using as template
> the Debian kernel config-4.19.0-11-amd64) and the default kernel
> config file from stock Debian Kernel 5.10.0-8-amd64 (see attachment);
> the "hunk" of the diff that I detected was the number 151:
>
> --- linux-source-5.10/.config   2021-08-13 17:24:22.386243765 +0200
> +++ /boot/config-5.10.462021-08-01 10:27:12.0 +0200
> @@ -9063,7 +9063,7 @@
>  # Memory initialization
>  #
>  CONFIG_INIT_STACK_NONE=y
> -CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y
> +# CONFIG_INIT_ON_ALLOC_DEFAULT_ON is not set
>  # CONFIG_INIT_ON_FREE_DEFAULT_ON is not set
>  # end of Memory initialization
>  # end of Kernel hardening options
>
> To verify this finding, I configured grub to start the kernel with the
> parameter init_on_alloc=0:
>
> # If you change this file, run 'update-grub' afterwards to update
> # /boot/grub/grub.cfg.
> # For full documentation of the options in this file, see:
> #   info -f grub -n 'Simple configuration'
>
> GRUB_DEFAULT=0
> GRUB_TIMEOUT=5
> GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
> GRUB_CMDLINE_LINUX_DEFAULT="no_console_suspend nouveau.debug=warn
> init_on_alloc=0"
> [...missing...]
>
> After that, of course, I update the grub with kernel boot
> configuration with the command:
>
> update-grub2
>
> The test with the stock Debian Bullseye (11.0) Kernel 5.10.0-8-amd64
> was successful: I'm repeatedly able to suspend to ram and suspend to
> disk with parameter init_on_alloc set to 0 with the same kernel that
> freeze with init_on_alloc set to 1. I haven't deepened yet in kernel
> source code, but in theory the kernel feature activated by this
> parameter [1] (erase area of newly allocated memory) could have side
> effects with the buffer handling/eviction of memory from video memory
> to system memory during suspend to ram or suspend to disk.
>
> You could give it a try, even if your GPU is two year younger then
> mine (but they use the same nv50 kernel drm module).


Bug#1003273: pipewire: headset mic not working

2022-01-07 Thread Marc Glisse
Package: pipewire
Version: 0.3.42-1
Severity: important

Dear Maintainer,

I have a headset that I connect with a USB dongle. It used to work in
December. Today, sound output still works, but not input. I can select
the headset as input source in gnome settings, I see it in pavucontrol,
etc, but they don't actually get any sound (unlike the internal mic of
the laptop, for which I see a bar that moves when I talk). In the log, I
first see

Jan  7 12:17:57 hippo /usr/libexec/gdm-x-session[1449]: (II) event10 - EPOS 
EPOS BTD 800 Consumer Control: is tagged by udev as: Keyboard

Hmm, no, that's a headset... But whatever, this also happens on a
debian stable system where the headset still works. Then

Jan  7 11:06:18 hippo pipewire[1542]: spa.alsa: 0x55da812704c8: card already 
opened at rate:48000
Jan  7 11:06:18 hippo pipewire[1542]: pw.node: 
(alsa_input.usb-EPOS_EPOS_BTD_800_A000871203310101-00.mono-fallback-93) 
suspended -> error (Start error: Invalid argument)
Jan  7 11:06:18 hippo pipewire[1542]: spa.audioadapter: params 
Spa:Enum:ParamId:EnumFormat: 0:0 (convert format) Success
Jan  7 11:06:18 hippo pipewire[1542]:   Object: size 160, type 
Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:EnumFormat (3)
Jan  7 11:06:18 hippo pipewire[1542]: Prop: key 
Spa:Pod:Object:Param:Format:mediaType (1), flags 
Jan  7 11:06:18 hippo pipewire[1542]:   Id 1
(Spa:Enum:MediaType:audio)
Jan  7 11:06:18 hippo pipewire[1542]: Prop: key 
Spa:Pod:Object:Param:Format:mediaSubtype (2), flags 
Jan  7 11:06:18 hippo pipewire[1542]:   Id 1
(Spa:Enum:MediaSubtype:raw)
Jan  7 11:06:18 hippo pipewire[1542]: Prop: key 
Spa:Pod:Object:Param:Format:Audio:format (65537), flags 
Jan  7 11:06:18 hippo pipewire[1542]:   Id 259  
(Spa:Enum:AudioFormat:S16LE)
Jan  7 11:06:18 hippo pipewire[1542]: Prop: key 
Spa:Pod:Object:Param:Format:Audio:rate (65539), flags 
Jan  7 11:06:18 hippo pipewire[1542]:   Int 16000
Jan  7 11:06:18 hippo pipewire[1542]: Prop: key 
Spa:Pod:Object:Param:Format:Audio:channels (65540), flags 
Jan  7 11:06:18 hippo pipewire[1542]:   Int 1
Jan  7 11:06:18 hippo pipewire[1542]: Prop: key 
Spa:Pod:Object:Param:Format:Audio:position (65541), flags 
Jan  7 11:06:18 hippo pipewire[1542]:   Array: child.size 4, child.type 
Spa:Id
Jan  7 11:06:18 hippo pipewire[1542]: Id 2
(Spa:Enum:AudioChannel:MONO)
Jan  7 11:06:18 hippo pipewire[1542]:   Object: size 216, type 
Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:EnumFormat (3)
Jan  7 11:06:18 hippo pipewire[1542]: Prop: key 
Spa:Pod:Object:Param:Format:mediaType (1), flags 
Jan  7 11:06:18 hippo pipewire[1542]:   Id 1
(Spa:Enum:MediaType:audio)
Jan  7 11:06:18 hippo pipewire[1542]: Prop: key 
Spa:Pod:Object:Param:Format:mediaSubtype (2), flags 
Jan  7 11:06:18 hippo pipewire[1542]:   Id 1
(Spa:Enum:MediaSubtype:raw)
Jan  7 11:06:18 hippo pipewire[1542]: Prop: key 
Spa:Pod:Object:Param:Format:Audio:format (65537), flags 
Jan  7 11:06:18 hippo pipewire[1542]:   Choice: type Spa:Enum:Choice:None, 
flags  24 4
Jan  7 11:06:18 hippo pipewire[1542]: Id 259  
(Spa:Enum:AudioFormat:S16LE)
Jan  7 11:06:18 hippo pipewire[1542]: Id 259  
(Spa:Enum:AudioFormat:S16LE)
Jan  7 11:06:18 hippo pipewire[1542]: Prop: key 
Spa:Pod:Object:Param:Format:Audio:rate (65539), flags 
Jan  7 11:06:18 hippo pipewire[1542]:   Choice: type Spa:Enum:Choice:Range, 
flags  28 4
Jan  7 11:06:18 hippo pipewire[1542]: Int 16000
Jan  7 11:06:18 hippo pipewire[1542]: Int 48000
Jan  7 11:06:18 hippo pipewire[1542]: Int 16000
Jan  7 11:06:18 hippo pipewire[1542]: Prop: key 
Spa:Pod:Object:Param:Format:Audio:channels (65540), flags 
Jan  7 11:06:18 hippo pipewire[1542]:   Choice: type Spa:Enum:Choice:None, 
flags  20 4
Jan  7 11:06:18 hippo pipewire[1542]: Int 1
Jan  7 11:06:18 hippo pipewire[1542]: Prop: key 
Spa:Pod:Object:Param:Format:Audio:position (65541), flags 
Jan  7 11:06:18 hippo pipewire[1542]:   Array: child.size 4, child.type 
Spa:Id
Jan  7 11:06:18 hippo pipewire[1542]: Id 2
(Spa:Enum:AudioChannel:MONO)
Jan  7 11:06:18 hippo pipewire[1542]: spa.audioadapter: failed filter:
Jan  7 11:06:30 hippo pipewire[1542]: spa.audioadapter: params 
Spa:Enum:ParamId:EnumFormat: 0:0 (convert format) Success
Jan  7 11:06:30 hippo pipewire[1542]:   Object: size 160, type 
Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:EnumFormat (3)
etc

I have packages

(with "wire")
gstreamer1.0-pipewire:amd64/testing 0.3.42-1 uptodate
libpipewire-0.3-0:amd64/testing 0.3.42-1 uptodate
libpipewire-0.3-common:all/testing 0.3.42-1 uptodate
libpipewire-0.3-modules:amd64/testing 0.3.42-1 uptodate
libwireplumber-0.4-0:amd64/testing 0.4.5-1 uptodate
pipewire:amd64/testing 

Bug#1003260: [Pkg-javascript-devel] Bug#1003260: leaflet-image: FTBFS with webpack5: Invalid configuration object

2022-01-07 Thread Jonas Smedegaard
Control: tag +help

Quoting Caleb Adepitan (2022-01-07 05:47:38)
> 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, leaflet-image was found to fail to build [with 
> webpack5].

> [webpack-cli] Invalid configuration object. Webpack has been initialized 
> using a configuration object that does not match the API schema.
>   - configuration.devtool should match pattern 
> "^(inline-|hidden-|eval-)?(nosources-)?(cheap-(module-)?)?source-map$".
> BREAKING CHANGE since webpack 5: The devtool option is more strict.
> Please strictly follow the order of the keywords in the pattern.

I fail to understand what causes this failure more specifically.

File debian/webpack.config.js defines the devtool value like this:

> devtool: 'source-map',

That syntax seems perfectly valid to me, consulting 
https://webpack.js.org/configuration/devtool/#devtool


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature


Bug#1002850: journalctl -f for SD card in USB adapter and in PC Card.

2022-01-07 Thread Michael Biebl

On 07.01.22 04:41, pe...@easthope.ca wrote:

peter@joule:/home/peter$ cat USB/udevLog1
-- Journal begins at Fri 2021-12-24 18:36:08 PST. --
Jan 06 19:09:29 mebius systemd[362]: Queued start job for default target Main Us
er Target.
Jan 06 19:09:29 mebius systemd[362]: Created slice User Application Slice.
Jan 06 19:09:29 mebius systemd[362]: Reached target Paths.
Jan 06 19:09:29 mebius systemd[362]: Reached target Timers.
Jan 06 19:09:29 mebius systemd[362]: Starting D-Bus User Message Bus Socket.
Jan 06 19:09:29 mebius systemd[362]: Listening on D-Bus User Message Bus Socket.
Jan 06 19:09:29 mebius systemd[362]: Reached target Sockets.
Jan 06 19:09:29 mebius systemd[362]: Reached target Basic System.
Jan 06 19:09:29 mebius systemd[362]: Reached target Main User Target.
Jan 06 19:09:29 mebius systemd[362]: Startup finished in 1.619s.
peter@joule:/home/peter$

Also observed this on the screen when the SD was inserted in
the USB adapter.

[  223.073688] usb usb1-port2: disabled by hub (EMI?), re-enabling...
[  223.741529] usb 1-2: device descriptor read/64, error -71
[  223.985548] usb 1-2: device descriptor read/64, error -71
[  224.357535] usb 1-2: device descriptor read/64, error -71
[  224.601534] usb 1-2: device descriptor read/64, error -71
[  225.277540] usb 1-2: device not accepting address 6, error -71
[  225.821547] usb 1-2: device not accepting address 7, error -71
[  225.821818] usb usb1-port2: unable to enumerate USB device





That's not helpful unfortunately, as it doesn't contain any udev debug 
messages. Obviously you need to run those commands as root.


OpenPGP_signature
Description: OpenPGP digital signature


Bug#974914: ITA: cdrkit

2022-01-07 Thread Fabio Fantoni

Il 07/01/2022 12:09, John Paul Adrian Glaubitz ha scritto:

Hi Fabio!

On 1/7/22 12:06, Fabio Fantoni wrote:

Hi, I saw cdrkit orphan with RC bug but someone that want adopting it
from a message of over one years ago without uploads

@John Paul Adrian Glaubitz: you still want adopt it?

Yes, I'm trying to get that done within the next weeks. Got unfortunately too
distracted with too many other things.

Were you interested in adopting it as well?

Adrian

Thanks for reply, unfortunately I don't have much time, anyway recently 
seeing some packages orphaned with RC or others even if not orphaned 
that no longer seem maintained and with autoremoval on some I did some 
NMU or QA. This I've seen that is build-dep of a package I've invested 
hours on recently 
(https://salsa.debian.org/debian/memtest86plus/-/commits/debian/experimental) 
and have a lot users seeing popcon so I wanted to make sure it will not 
removed (even if it doesn't have autoremoval at the moment), if no one 
else they would fix before a possible autoremoval from testing if I'll 
have time I would do a QA myself (this will not be necessary if you do, 
in which case thank you)


I suggest to create also repository for it in salsa to make 
easier/faster contribute if necessary in future.




OpenPGP_signature
Description: OpenPGP digital signature


Bug#764901: linux-image-3.16-2-amd64: Suspend results in shutdown

2022-01-07 Thread Diederik de Haas
On Friday, 7 January 2022 09:38:46 CET Dominique Dumont wrote:
> Error! Bad return status for module build on kernel: 3.16.0-6-amd64 (x86_64)
> Consult /var/lib/dkms/open-vm-tools/2012.05.21/build/make.log for more
> information.
> ...
> Turns out that the compilation failure happens because dkms is trying to
> compile the Debian 7 version of open-vm-tools (2012.05.21) with Debian 8
> kernel (3.16.0-6).

It's not uncommon that old dkms packages are not compatible with newer 
kernels. I only have experience with non-packaged dkms modules, but the 
problem is the same. 

Out of Tree modules always have to play catch-up because they can't know how 
the kernel will change in the future and thus they can't know in advance how 
their code should be adapted.
The newer version works with Debian 8, but will highly likely fail with Debian 
9 ... until you update open-vm-tools to a later version which does support 
kernel 4.9. 

> I don't know if there's a bug with dkms or open-vm-tools which trigger a
> compilation of old open-vm-tools with newer kernel

As Ben mentioned in msg #10:
"That is a bug in open-vm-tools, not the kernel."

You went to all that trouble to find a 7+ year old bug, with a title that 
doesn't convey a link with dkms compilation issue, unarchive the bug and 
respond to that, but you missed the (1st) response of a kernel maintainer?


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


  1   2   >