Bug#1005693: iwlwifi bug fix

[Bernhard]

Hello Holger
Hello Salvatore

This bugfix also closes my installation report #1005693.
Do you think, you can release 5.16.10-2 with this bugfix in the next
days?
Without this bugfix, installation of sid with iwlwifi card present in
the system is not possible.

Best regards and thank you for the great work.
Bernhard



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

Bug#1006131: rus-ispell: please stop build-depending on myspell-tools

[Mikhail Gusarov]

Hello Agustin,

On 21 Feb 2022, at 23:46, Agustin Martin wrote:

>> Could you show me the difference?

> Find attached diff. SInce flags are sorted differently by i2myspell
> and ispellaff2myspell , I made some magic for easier check of result,
> actually diffing sorted affix files. This is what leads to that file

Thanks. Looks fine for me.
Actually, new file has the Cyrillic letters sorted in the right order :)

Best,
Mikhail.

Bug#1004262: [debian-mysql] Bug#1004262: Acknowledgement (mariadb-server: Instead of being upgraded, mariadb-server gets removed after apt update)

[Otto Kekäläinen]

Hello!

As part of our CI we run a Bullseye MariaDB 10.5 to Debian Sid MariaDB
10.6 upgrade on every commit. If passes correctly with:

The following packages will be REMOVED:
  mariadb-client-10.5 mariadb-client-core-10.5 mariadb-server-10.5
  mariadb-server-core-10.5
The following NEW packages will be installed:
  libdaxctl1 libkmod2 libndctl6 libnuma1 libodbc2 libodbccr2 libpcre2-posix3
  libpmem1 liburing2 mariadb-client-10.6 mariadb-client-core-10.6
  mariadb-server-10.6 mariadb-server-core-10.6

To continue with solving this issue I would like to first get it
reproduced in the CI. The root cause why we have an upgrade issue is
that there is a scenario users can hit that is not covered by our CI.
Fixing that would ensure proper testing coverage and forever working
MariaDB upgrades.

Latest CI run:
https://salsa.debian.org/mariadb-team/mariadb-server/-/pipelines/350897

Bullseye to Sid upgrade test:
https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/2492192

Source.
https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/salsa-ci.yml

How to contribute:
https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian

Bug#1006259: RM: unison-2.51+4.11.1 -- ROM; obsolete

[Stéphane Glondu]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Dear FTP Team,

It is time to remove unison-2.51+4.11.1, the version of Unison built
with OCaml 4.11.1, from unstable.


Cheers,

-- 
Stéphane

Bug#1002721: okular: segfaults when trying to open a signed PDF

[Patrick Franz]

Control: 1002721 severity important
thanks

Hi Pablo,

can you point to a PDF document available on the web that causes Okular 
to segfault for you such that I can try to reproduce it ?


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1006258: rstudio crashes

[Luc Castermans]

Package: rstudio
Version: 2022.02.0+443
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: l...@castermans.org

Dear Maintainer,

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

   * What led up to the situation?
upon crash a white screen is shown, need to KILL it; fully reproducible
   * 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: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'experimental'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.17.0-rc3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), LANGUAGE=nl
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rstudio depends on:
ii  libc6   2.34-0experimental3
ii  libclang-dev1:13.0-54
ii  libedit23.1-20210910-1
ii  libpq5  14.2-1
ii  libsqlite3-03.37.2-2
ii  libssl1.1   1.1.1m-1
ii  libxkbcommon-x11-0  1.4.0-1

Versions of packages rstudio recommends:
ii  r-base  4.1.2-2

rstudio suggests no packages.

-- no debconf information

Bug#1005190: gbp dch: add trailing dot when updating changelog

[Otto Kekäläinen]

Hi!

Personally I don't use trailing dots in d/changelog unless there are
actual full sentences that need them. I do however wish gbp-dch had
this feature, as currently when it does not have it, Lintian-brush
adds trailing dot to git commit message titles.

I find that ugly and I believe most git users would agree. if gbp-dch
supported adding dots it would neatly solve this issue.

> Jelmer Vernooij wrote:
>> Guido Günther wrote:
>> Introduce a /usr/share/doc/git-buildpackage/examples/debian_cl.py that
>> has all the wanted options, have janitor recommend using that and later
>> on make it a built in option if it's a style maintainers are happy with?
>
>Yeah, that seems like a reasonable approach. Let me see if I can
>propose a script that does that.

Thanks Guido and Jelmer for considering this!

- Otto

PS. This is practically identical
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959665

Bug#1002291: bpfcc: Fails to build with libbpf/0.6.1-1

[Vasudev Kamath]

Sudip Mukherjee  writes:

> You are trying to build 0.24.0+ds and I am rebuilding 0.22.0+ds-2 to test.  :)
>
> Can you rebuild 0.22.0+ds-2 and verify.

Err yes. It works with 0.22.0. I was preparing 0.23.0 and then 0.24.0.
Both of which fails as of now. Not sure what should be done.

Cheers,
Vasudev

Bug#1006257: python3-apt: Sigwinch window resizes have no effect on debconf prompts

[Blake Lee]

Package: python3-apt
Version: 2.3.0+b1
Severity: important

Dear Maintainer,

After running cache.commit() sigwinch signals don't seem to be respected.

If I resize the terminal after calling comit, and hit a debconf prompt it will 
be formatted weird.

additionally if you can get a prompt that allows executing a shell, such as a 
conf prompt,

the shell will not get sigwinch updates either.



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

Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
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 python3-apt depends on:
ii  distro-info-data   0.52
ii  libapt-pkg6.0  2.3.15
ii  libc6  2.33-5
ii  libgcc-s1  11.2.0-16
ii  libstdc++6 11.2.0-16
ii  python-apt-common  2.3.0
ii  python33.9.8-1

Versions of packages python3-apt recommends:
ii  iso-codes4.9.0-1
ii  lsb-release  11.1.0

Versions of packages python3-apt suggests:
ii  apt  2.3.15
pn  python-apt-doc   
pn  python3-apt-dbg  

-- no debconf information

Bug#1006256: gmerlin: reproducible builds: Timestamps embedded in manpages

[Vagrant Cascadian]

Source: gmerlin
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build timestamp is embedded in manpages:

  ./usr/share/man/man1/mdb-tool.1.gz

  -.TH MDB-TOOL 1 "February 2022" Gmerlin "User Manuals"
  vs.
  +.TH MDB-TOOL 1 "November 2022" Gmerlin "User Manuals"


The attached patch fixes this by respecting the SOURCE_DATE_EPOCH
environment variable in the manpage generation code in lib/cmdline.c.


With this patch applied, gmerlin should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining gmerlin!


live well,
  vagrant
From d532ebe90243f9390b0b1e49f1d4918f173238a6 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 22 Feb 2022 03:25:25 +
Subject: [PATCH] lib/cmdline.c: Use deterministic timestamp when generating
 manpages.

Use the SOURCE_DATE_EPOCH environment variable if available, and use
numeric date to avoid embedding locale-dependent month names.

https://reproducible-builds.org/docs/source-date-epoch/
---
 lib/cmdline.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/lib/cmdline.c b/lib/cmdline.c
index 4b4d2f6..049e905 100644
--- a/lib/cmdline.c
+++ b/lib/cmdline.c
@@ -441,9 +441,13 @@ void bg_cmdline_print_help(char * argv0, bg_help_format_t format)
   char ** args;
   char * string_uc;
   
-  time();
-  localtime_r(, );
-  strftime(date_str, 511, "%B %Y", );
+  char *source_date_epoch;
+  /* This assumes that the SOURCE_DATE_EPOCH environment variable will contain
+ a correct, positive integer in the time_t range */
+  if ((source_date_epoch = getenv("SOURCE_DATE_EPOCH")) == NULL ||
+  (t = (time_t)strtoll(source_date_epoch, NULL, 10)) <= 0)
+time();
+  strftime(date_str, 511, "%F", gmtime());
 
   string_uc = bg_toupper(bg_app_get_name());
   
-- 
2.35.1



signature.asc
Description: PGP signature

Bug#995189: RFH: isc-dhcp

[Martin-Éric Racine]

On Mon, Feb 21, 2022 at 11:44 PM Santiago R.R.  wrote:
>
> El 21/02/22 a las 15:19, Martin-Éric Racine escribió:
> > On Mon, Feb 21, 2022 at 2:18 PM Martin-Éric Racine
> >  wrote:
> > >
> > > On Thu, Jan 6, 2022 at 8:40 PM Santiago R.R.  
> > > wrote:
> > > > On January 6, 2022 4:49:49 AM GMT-05:00, "Martin-Éric Racine" 
> > > >  wrote:
> > > > >Hello again,
> > > > >
> > > > >ke 24. marrask. 2021 klo 16.20 Santiago Ruano Rincón
> > > > >(santiag...@riseup.net) kirjoitti:
> > > > >> El 07/11/21 a las 13:54, Martin-Éric Racine escribió:
> > > > >> > ma 27. syysk. 2021 klo 21.44 Santiago Ruano Rincón
> > > > >> > (santiag...@riseup.net) kirjoitti:
> > > > >> > > El 27/09/21 a las 20:25, Martin-Éric Racine escribió:
> > > > >> > > > Package: wnpp
> > > > >> > > > Severity: normal
> > > > >> > > > X-Debbugs-Cc: debian-de...@lists.debian.org
> > > > >> > > > Control: affects -1 src:isc-dhcp
> > > > >> > > >
> > > > >> > > > -BEGIN PGP SIGNED MESSAGE-
> > > > >> > > > Hash: SHA256
> > > > >> > > >
> > > > >> > > > The ISC DHCP suite has a lenghty list of bug reports that have 
> > > > >> > > > been left unattended. Some bugs date back to DHCP 3 or even 
> > > > >> > > > earlier.
> > > > >> > > >
> > > > >> > > > Additionally, recent upstream releases are still unpackaged. 
> > > > >> > > > One release came out well ahead of the Bullseye freeze, a bug 
> > > > >> > > > report requesting its packaging was filed, but it remains 
> > > > >> > > > unanswered.
> > > > >> > > >
> > > > >> > > > Leaving a package with a priority Important in such utter 
> > > > >> > > > state of neglect is unacceptable.
> > > > >> > > >
> > > > >> > > > At this point, it has become clear that, at the very least, 
> > > > >> > > > its maintainers need help, hence why I filed this WNPP bug.
> > > > >> > >
> > > > >> > > Indeed. I am willing to spend some cycles to help maintaining 
> > > > >> > > it. I
> > > > >> > > requested access to the ISC DHCP packaging team in salsa ~a 
> > > > >> > > couple of
> > > > >> > > weeks ago, but I hasn't been answered yet (mgilbert is its only 
> > > > >> > > member).
> > > > >> > > It was on my ToDo list to ping the maintainers (in CC).
> > > > >> >
> > > > >> > Has any progress taken place on this?
> > > > >>
> > > > >> I've started doing some work at 
> > > > >> https://salsa.debian.org/santiago/isc-dhcp/
> > > > >>
> > > > >> I still didn't get any answer from current maintainers (keeping them 
> > > > >> in
> > > > >> CC), so I plan to retitle this bug as an ITS bug soon. Hopefully no
> > > > >> later than next Friday.
> > > > >
> > > > >Has the ITA taken place?
> > > > >
> > > >
> > > > Not an ITA, but an ITS (CCed). I was unable close according to the ITS 
> > > > schedule, and I will have to resume the work after then end of my VAC 
> > > > (mid-January)
> > >
> > > This was nearly 2 months ago.  At this point, I think that apollock
> > > and mgilbert might as well be considered MIA.
> >
> > Sure enough, upstream already is up to version 4.4.3b1, 26 January
> > 2022, and recent commits include CVE fixes.
>
> OK. I am resuming the work on this, and I'll upload it ASAP.
>
> I have just requested to move the isc-dhcp packaging repo to the debian/
> namespace.

Please note that there are now 2 upstream repos, if you wanna cherry
pick CVE fixes:

https://github.com/isc-projects/dhcp
https://gitlab.isc.org/isc-projects/dhcp

GitHub seems to be abandoned, while GitLab regularly sees commits and
is where I found the 4.4.3 beta.

Tarballs are still here:

https://downloads.isc.org/isc/dhcp/

Martin-Éric

Bug#997811: unbound crashes, remote dos?

[zm5s-trnc]

On Mon, 25 Oct 2021 07:57:22 +0300 Aleksi Suhonen 
 wrote:

> Package: unbound
> Version: 1.13.1-1
> Severity: normal

Hi,
got the same issue with backport on debian10  1.13.1-1~bpo10+1

We made a fleet of cache servers running Unbound behind a L4 load-balancer.
We got crashes on 3 of the machines all with the same diagnosis.

Here is what we got in dmesg

[2000699.556805] unbound[2823]: segfault at 108 ip 5584e0d84c2b sp 
7f80ad7f9c80 error 4 in unbound[5584e0cc5000+d3000]
[2000699.556818] Code: 00 00 00 48 8b 88 78 01 00 00 31 c0 e8 fe 36 f9 
ff eb b0 e8 b7 0f f4 ff 0f 1f 80 00 00 00 00 41 56 41 55 41 54 55 53 48 
89 fb <48> 8b 3f 48 85 ff 74 35 4d 89 c6 41 89 cd 48 89 d5 49 89 f4 e8 cc
[2046588.178787] unbound[14134]: segfault at 108 ip 55f01390bc2b sp 
7fde77ffec80 error 4 in unbound[55f01384c000+d3000]
[2046588.178800] Code: 00 00 00 48 8b 88 78 01 00 00 31 c0 e8 fe 36 f9 
ff eb b0 e8 b7 0f f4 ff 0f 1f 80 00 00 00 00 41 56 41 55 41 54 55 53 48 
89 fb <48> 8b 3f 48 85 ff 74 35 4d 89 c6 41 89 cd 48 89 d5 49 89 f4 e8 cc
[2224158.880592] unbound[2271]: segfault at 108 ip 55e995650c2b sp 
7fb46a7fbc80 error 4 in unbound[55e995591000+d3000]
[2224158.880606] Code: 00 00 00 48 8b 88 78 01 00 00 31 c0 e8 fe 36 f9 
ff eb b0 e8 b7 0f f4 ff 0f 1f 80 00 00 00 00 41 56 41 55 41 54 55 53 48 
89 fb <48> 8b 3f 48 85 ff 74 35 4d 89 c6 41 89 cd 48 89 d5 49 89 f4 e8 cc


"Interestingly" it does not happen all the time, as you can see we had a 
burst during last week-end, but right now all is calm.


We just restart the service when crash happens for the moment.

Bug#1006253: iwd is crashing with a segfault

[Jonas Smedegaard]

Hi Theodore,

Quoting Theodore Y. Ts'o (2022-02-22 03:00:55)
> After upgrading to iwd 1.24-1, it is crashing on my system.  (Dell 
> XPS-13 with an ath10k/QCA6174/hw3.0 wireless card.)  Downgrading to 
> iwd 1.21-3 allows things to work.  Restalling iwd 1.24-1 causes it 
> crash again.

Upstream made a few crash fixes a few weeks ago which I have now 
cherry-picked and released as 1.24-2.  Please try that and tell if it 
helps for your scenario.

If it doesn't, I propose that you pass the debug information upstream 
directly (I can also do it, but have no special skills so will simply 
act as a proxy for you, which might not be as efficient).

Upstream can be reached at this mailinglist: 
https://lists.01.org/postorius/lists/iwd.lists.01.org/


Kind regards,

 - 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#1006255: RFP: blender-doc -- Offline copy of the Blender Manual available at https://docs.blender.org/manual/

[Jonathan Rubenstein]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: jrub...@gmail.com

* Package name: blender-doc
  Version : 3.0
  Upstream Author : Blender Documentation Team 
* URL : https://docs.blender.org/manual/
* License : CC BY-SA 4.0
  Programming Lang: rST / Sphinx
  Description : Offline copy of the Blender Manual available at 
https://docs.blender.org/manual/


This is an entirely sphinx based full manual for the Blender 3D modelling
software. It is linked to from the Help menu of the Blender program, which
opens a web browser to https://docs.blender.org/manual//.

This documentation is not currently distributed with Debian, and I would 
like
to see it so, to give users the opportunity to easily download the 
manual for

offline use through apt, as well as giving the manual added protection
against total loss through the source code and compiled manual being 
mirrored

on Debian's wide and diverse mirror network, in addition to downstream
mirrors.

The source code is currently located at 
https://svn.blender.org/svnroot/bf-manual/trunk/blender_docs,
or 
https://svn.blender.org/svnroot/bf-manual/branches/blender--release/blender_docs/
with translations located at 
https://svn.blender.org/svnroot/bf-manual-translations/trunk/blender_docs.


I do not believe it is strictly necessary to package the translations too,
but they could be useful if the prospective maintainer chooses to 
include them.


Instructions for building are found at 
https://docs.blender.org/manual/en/latest/about/index.html,
however in my experience, python3-sphinx and sphinx-rtd-theme are 
sufficient.



I have not packaged before, and I'm nervous, which is why this is an RFP for
the moment, rather than an ITP.


Best Regards,

Jonathan Rubenstein

Bug#1006254: mdnsd: reproducible-builds: Example Makefiles embed build paths and binary paths

[Vagrant Cascadian]

Source: mdnsd
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath usrmerge shell
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path and several binary paths are embedded in example
Makefiles shipped in the mdsnd package:

│ │ │ ├── ./usr/share/doc/mdnsd/examples/Makefile
...
│ │ │ │ -ACLOCAL = ${SHELL} 
'/tmp/reprotest.277oHq/const_build_path/aux/missing' aclocal-1.16
│ │ │ │ +ACLOCAL = ${SHELL} 
'/tmp/reprotest.277oHq/build-experiment-1/aux/missing' aclocal-1.16


Since these values may differ with the installed system, in order to use
the example Makefile, a person would have to regenerate it from
Makefile.in and/or Makefile.am, which are also provided in the package.

The attached patch fixes this by adjusting debian/mdnsd.examples to
avoid installing the example Makefile.


With this patch applied mdnsd should become reproducible on
tests.reproducible-builds.org!


Thanks for maintaining mdnsd!


live well,
  vagrant
From 73985d4b673fbcbfe21e6cd2ccd915a40551bf52 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 22 Feb 2022 02:00:04 +
Subject: [PATCH] mdnsd.examples: Avoid installing generated Makefile.

The generated Makefile embeds full paths to scripts containing the
build path, so would need to be regenerated anyways. It also contains
other differences (e.g. usrmerge vs. non-usrmerge, /bin/sh
implementation differences, etc.) which may not be consistant with the
user's system.
---
 debian/mdnsd.examples | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/mdnsd.examples b/debian/mdnsd.examples
index e39721e..f71db6f 100644
--- a/debian/mdnsd.examples
+++ b/debian/mdnsd.examples
@@ -1 +1,2 @@
-examples/*
+examples/Makefile.*
+examples/*.service
-- 
2.35.1



signature.asc
Description: PGP signature

Bug#1006253: iwd is crashing with a segfault

[Theodore Y. Ts'o]

Package: iwd
Version: 1.24-1
Severity: important

Dear Maintainer,

After upgrading to iwd 1.24-1, it is crashing on my system.  (Dell
XPS-13 with an ath10k/QCA6174/hw3.0 wireless card.)  Downgrading to iwd
1.21-3 allows things to work.  Restalling iwd 1.24-1 causes it crash
again.

If I run /usr/libexec/iwd -debug, it displays the following, and then
immediately dies with a Segmentation fault:

Wireless daemon version 1.24
Loaded configuration from /etc/iwd/main.conf
station: Network configuration is disabled.
Wiphy: 0, Name: phy0
Permanent Address: 9c:b6:d0:88:b6:0d
2.4Ghz Band:
Bitrates (non-HT):
 1.0 Mbps
 2.0 Mbps
 5.5 Mbps
11.0 Mbps
 6.0 Mbps
 9.0 Mbps
12.0 Mbps
18.0 Mbps
24.0 Mbps
36.0 Mbps
48.0 Mbps
54.0 Mbps
HT Capabilities:
HT40
Short GI for 20Mhz
Short GI for 40Mhz
HT RX MCS indexes:
0-15
5Ghz Band:
Bitrates (non-HT):
 6.0 Mbps
 9.0 Mbps
12.0 Mbps
18.0 Mbps
24.0 Mbps
36.0 Mbps
48.0 Mbps
54.0 Mbps
HT Capabilities:
HT40
Short GI for 20Mhz
Short GI for 40Mhz
HT RX MCS indexes:
0-15
VHT Capabilities:
Short GI for 80Mhz
Max RX MCS: 0-9 for NSS: 2
Max TX MCS: 0-9 for NSS: 2
Ciphers: CCMP TKIP BIP
Supported iftypes: ad-hoc station ap p2p-client p2p-go p2p-device
Segmentation fault

I will attach the output of running iwmon while trying to start iwd.

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

Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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 iwd depends on:
ii  init-system-helpers  1.62
ii  libc62.33-6
ii  libell0  0.48-0.1
ii  libreadline8 8.1.2-1

Versions of packages iwd recommends:
ii  dbus [dbus-system-bus]  1.12.20-3
ii  wireless-regdb  2021.08.28-1

iwd suggests no packages.

-- no debconf information


iwmon.log.gz
Description: application/gzip

Bug#1006185: shunit2: newer upstream version 2.1.8

[tony mancill]

On Sun, Feb 20, 2022 at 11:49:40AM -0800, tony mancill wrote:
> Package: shunit2
> Version: 2.1.6-1.2
> Severity: minor
> 
> Dear Maintainer,
> 
> shunit2 upstream is active again and newer upstream release includes
> some new assertions - for example, "assertContains" - that make it
> easier to write unit-tests.  It would be nice to get the latest version
> into Debian during the bookworm release cycle.
> 
>   https://github.com/kward/shunit2/releases
> 
> Thank you for maintaining shunit2.  I am using it in autopkgtests.

I'd like to add that I am willing to help update and/or maintain shunit2
if you are amenable to that.

Thanks,
tony


signature.asc
Description: PGP signature

Bug#923089: pod2html: rev should be rel

[Kacper Gutowski]

On Sun, 24 Feb 2019 09:59:19 +0800 積丹尼 Dan Jacobson wrote:

mailto:root@localhost; /> should be
mailto:root@localhost; />


Surely you mean rel="author"!

-k

Bug#1006139: RM: libdeflate [armhf] -- ROM; does not seem suitable for armhf 'baseline'

[Wookey]

Andreas Tille  wrote:
> it seems this package does not seem suitable for armhf 'baseline'.
> It fails to build with

>   lib/arm/crc32_impl.h:77:1: error: ‘-mfloat-abi=hard’: selected architecture 
> lacks an FPU

That seems an oversimplification. There is usually an FPU (almost
always) and a neon unit (usually). The point is that their presence is
not guaranteed, so such instructions should not be used without checking
the HWCAPS first. So libdeflate should be able to work fine on armhf, but
may need enhancing with some fallback functions for FPUless and
neonless hardware.

I have not yet checked upstream to see if the codebase already
supports this or would need work to do so. I will do so and report back. 

It seems to me that we shouldn't be disabling standard compression libraries on 
architectures lightly.
At the very least some research is in order. It used to work (before version 
1.9):
https://buildd.debian.org/status/logs.php?pkg=libdeflate=armhf

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1006252: cctbx: reproducible builds: Timestamps embedded in boost_python_meta_ext.so.0.0.1

[Vagrant Cascadian]

Source: cctbx
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build timestamp is embedded in the boost_python_meta_ext.so.0.0.1
library and the corresponding debug symbols:

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

  /usr/lib/x86_64-linux-gnu/boost_python_meta_ext.so.0.0.1

  __TIMESTAMP__·=·Thu·Mar·23·02:40:09·2023
vs.
  __TIMESTAMP__·=·Fri·Feb·18·22:37:54·2022

The attached patch fixes this by removing the timestamp.

With this patch applied, cctbx should build reproducibly on
tests.reproducible-builds.org!


An alternate approach would be to replace it with the timestamp
specified in SOURCE_DATE_EPOCH, if for some reason this binary
absolutely needs an embedded timestamp:

  https://reproducible-builds.org/docs/source-date-epoch/


Thanks for maintaining cctbx!

live well,
  vagrant
From e554ea5ffab260208f9ce81433005e612dc85bf5 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 22 Feb 2022 00:47:41 +
Subject: [PATCH] boost_adaptbx/meta_ext.cpp: Remove embedded timestamp.

https://reproducible-builds.org/docs/timestamps/
---
 boost_adaptbx/meta_ext.cpp | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/boost_adaptbx/meta_ext.cpp b/boost_adaptbx/meta_ext.cpp
index 5d2f45b..19f5782 100644
--- a/boost_adaptbx/meta_ext.cpp
+++ b/boost_adaptbx/meta_ext.cpp
@@ -207,9 +207,6 @@ namespace {
 #if defined(__TIME__)
 result += "__TIME__ = " __TIME__ "\n";
 #endif
-#if defined(__TIMESTAMP__)
-result += "__TIMESTAMP__ = " __TIMESTAMP__ "\n";
-#endif
 #if defined(__alpha__)
 result += "__alpha__\n";
 #endif
-- 
2.30.2



signature.asc
Description: PGP signature

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

[Scott Talbert]

On Sat, 19 Feb 2022, Lucas Nussbaum wrote:


=== FAILURES ===
_ test_internal_errors_propagate_to_controller _

pytester = 

def test_internal_errors_propagate_to_controller(pytester: pytest.Pytester) 
-> None:
pytester.makeconftest(
"""
def pytest_collection_modifyitems():
raise RuntimeError("Some runtime error")
"""
)
pytester.makepyfile("def test(): pass")
result = pytester.runpytest("-n1")

  result.stdout.fnmatch_lines(["*RuntimeError: Some runtime error*"])

E   Failed: nomatch: '*RuntimeError: Some runtime error*'
E   and: '= test session starts 
=='
E   and: 'platform linux -- Python 3.10.2, pytest-6.2.5, py-1.10.0, 
pluggy-0.13.0'
E   and: 'rootdir: 
/tmp/pytest-of-user42/pytest-0/test_internal_errors_propagate_to_controller0'
E   and: 'plugins: xdist-2.5.0, forked-1.4.0'
E   and: 'gw0 I'
E   and: 'gw0 [1]'
E   and: ''
E   and: 'INTERNALERROR> Traceback (most recent call last):'
E   and: 'INTERNALERROR>   File 
"/usr/lib/python3/dist-packages/_pytest/main.py", line 269, in wrap_session'
E   and: 'INTERNALERROR> session.exitstatus = doit(config, session) 
or 0'
E   and: 'INTERNALERROR>   File 
"/usr/lib/python3/dist-packages/_pytest/main.py", line 323, in _main'
E   and: 'INTERNALERROR> 
config.hook.pytest_runtestloop(session=session)'
E   and: 'INTERNALERROR>   File 
"/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286, in __call__'
E   and: 'INTERNALERROR> return self._hookexec(self, 
self.get_hookimpls(), kwargs)'
E   and: 'INTERNALERROR>   File 
"/usr/lib/python3/dist-packages/pluggy/manager.py", line 92, in _hookexec'
E   and: 'INTERNALERROR> return self._inner_hookexec(hook, methods, 
kwargs)'
E   and: 'INTERNALERROR>   File 
"/usr/lib/python3/dist-packages/pluggy/manager.py", line 335, in traced_hookexec'
E   and: 'INTERNALERROR> return outcome.get_result()'
E   and: 'INTERNALERROR>   File 
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 80, in get_result'
E   and: 'INTERNALERROR> raise ex[1].with_traceback(ex[2])'
E   and: 'INTERNALERROR>   File 
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 52, in from_call'
E   and: 'INTERNALERROR> result = func()'
E   and: 'INTERNALERROR>   File 
"/usr/lib/python3/dist-packages/pluggy/manager.py", line 333, in '
E   and: 'INTERNALERROR> outcome = _Result.from_call(lambda: 
oldcall(hook, hook_impls, kwargs))'
E   and: 'INTERNALERROR>   File 
"/usr/lib/python3/dist-packages/pluggy/manager.py", line 83, in '
E   and: 'INTERNALERROR> self._inner_hookexec = lambda hook, 
methods, kwargs: hook.multicall('
E   and: 'INTERNALERROR>   File 
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 208, in _multicall'
E   and: 'INTERNALERROR> return outcome.get_result()'
E   and: 'INTERNALERROR>   File 
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 80, in get_result'
E   and: 'INTERNALERROR> raise ex[1].with_traceback(ex[2])'
E   and: 'INTERNALERROR>   File 
"/usr/lib/python3/dist-packages/pluggy/callers.py", line 187, in _multicall'
E   and: 'INTERNALERROR> res = hook_impl.function(*args)'
E   and: 'INTERNALERROR>   File 
"/<>/.pybuild/cpython3_3.10_pytest-xdist/build/xdist/dsession.py", 
line 117, in pytest_runtestloop'
E   and: 'INTERNALERROR> self.loop_once()'
E   and: 'INTERNALERROR>   File 
"/<>/.pybuild/cpython3_3.10_pytest-xdist/build/xdist/dsession.py", 
line 140, in loop_once'
E   and: 'INTERNALERROR> call(**kwargs)'
E   and: 'INTERNALERROR>   File 
"/<>/.pybuild/cpython3_3.10_pytest-xdist/build/xdist/dsession.py", 
line 262, in worker_collectionfinish'
E   and: 'INTERNALERROR> self.sched.schedule()'
E   and: 'INTERNALERROR>   File 
"/<>/.pybuild/cpython3_3.10_pytest-xdist/build/xdist/scheduler/load.py",
 line 257, in schedule'
E   and: 'INTERNALERROR> self._send_tests(next(nodes), 1)'
E   and: 'INTERNALERROR>   File 
"/<>/.pybuild/cpython3_3.10_pytest-xdist/build/xdist/scheduler/load.py",
 line 269, in _send_tests'
E   and: 'INTERNALERROR> node.send_runtest_some(tests_per_node)'
E   and: 'INTERNALERROR>   File 
"/<>/.pybuild/cpython3_3.10_pytest-xdist/build/xdist/workermanage.py",
 line 284, in send_runtest_some'
E   and: 'INTERNALERROR> self.sendcommand("runtests", 
indices=indices)'
E   and: 'INTERNALERROR>   File 
"/<>/.pybuild/cpython3_3.10_pytest-xdist/build/xdist/workermanage.py",
 line 300, in sendcommand'
E   and: 'INTERNALERROR> 

Bug#1006251: USB Lenovo ThinkPad Compact Keyboard has fn_lock inverted

[Josh Triplett]

Package: src:linux
Version: 5.16.7-2
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

I have an external ThinkPad USB keyboard:

$ lsusb | grep -i keyboard
Bus 003 Device 022: ID 17ef:6047 Lenovo ThinkPad Compact Keyboard with 
TrackPoint

The Linux kernel exposes a fn_lock attribute in sysfs for this keyboard:

$ cat 
/sys/devices/pci:00/:00:14.0/usb3/3-5/3-5.4/3-5.4.3/3-5.4.3:1.1/0003:17EF:6047.000F/fn_lock
1

However, this attribute appears inverted for this particular keyboard:
it seems to be 1 when FnLock is *disabled* and 0 when FnLock is
*enabled*.

Bug#1006250: src:collectd: collectd should no longer build the xencpu plugin on i386

[Maximilian Engelhardt]

Package: src:collectd
Version: 5.12.0-8
Severity: normal
Tags: patch

Hi,

Starting with version 4.16, the xen package in Debian stopped building xen on
the i386 architecture. We only realized shortly after uploading to unstable 
that this change also affects the packages that depend on us.

One step to clean this up now is to adjust collectd accordingly and stop
building the xencpu plugin on i386. Please review and apply my attached patch 
which disables the xencpu plugin on i386.

If you have any questions feel free to ask on #debian-xen or on the
pkg-xen-de...@lists.alioth.debian.org list.

Thanks,
Maxidiff -Nru collectd-5.12.0/debian/changelog collectd-5.12.0/debian/changelog
--- collectd-5.12.0/debian/changelog	2022-01-20 15:40:42.0 +0100
+++ collectd-5.12.0/debian/changelog	2022-02-20 23:41:12.0 +0100
@@ -1,3 +1,11 @@
+collectd (5.12.0-8.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't build the xencpu plugin on i386. Starting with xen version 4.16, xen
+is no longer built on the i386 architecture in Debian.
+
+ -- Maximilian Engelhardt   Sun, 20 Feb 2022 23:41:12 +0100
+
 collectd (5.12.0-8) unstable; urgency=medium
 
   [ Kentaro Hayashi ]
diff -Nru collectd-5.12.0/debian/control collectd-5.12.0/debian/control
--- collectd-5.12.0/debian/control	2022-01-20 15:40:42.0 +0100
+++ collectd-5.12.0/debian/control	2022-02-20 23:40:32.0 +0100
@@ -52,7 +52,7 @@
  libupsclient-dev | libupsclient1-dev,
  libvarnishapi-dev,
  libvirt-dev (>= 0.4.0-6) [linux-any],
- libxen-dev [amd64 arm64 armhf i386],
+ libxen-dev [amd64 arm64 armhf],
  libxml2-dev,
  libyajl-dev,
  linux-libc-dev (>= 2.6.25-4) [linux-any] | linux-libc-dev (<< 2.6.25-1) [linux-any],
diff -Nru collectd-5.12.0/debian/rules collectd-5.12.0/debian/rules
--- collectd-5.12.0/debian/rules	2022-01-20 15:40:42.0 +0100
+++ collectd-5.12.0/debian/rules	2022-02-20 23:40:59.0 +0100
@@ -217,7 +217,7 @@
 endif
 
 # This plugin is x86 and arm specific.
-ifeq (,$(filter amd64 arm64 armhf i386, $(DEB_HOST_ARCH)))
+ifeq (,$(filter amd64 arm64 armhf, $(DEB_HOST_ARCH)))
 	confflags += \
 		--disable-xencpu
 endif


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

Bug#1002051: bullseye-pu: package heartbeat/1:3.0.6-11+deb11u1

[Valentin Vidic]

On Sat, Feb 19, 2022 at 06:59:58PM +, Adam D. Barratt wrote:
> Please go ahead.

Thanks, just uploaded.

-- 
Valentin

Bug#1006249: wrong header installation path

[M. Zhou]

Source: mimalloc
Version: 2.0.5+ds-1
Severity: important
Justification: makes reverse dependency harder to package.

Dear maintainer,
This does not look like a correct header installation path
~/D/m/moarvm ❯❯❯ apt-file list libmimalloc-dev
libmimalloc-dev: /usr/include/mimalloc-2.0/mimalloc-new-delete.h
libmimalloc-dev: /usr/include/mimalloc-2.0/mimalloc-override.h
libmimalloc-dev: /usr/include/mimalloc-2.0/mimalloc.h
libmimalloc-dev: /usr/lib/x86_64-linux-gnu/libmimalloc.so
libmimalloc-dev: /usr/share/doc/libmimalloc-dev/changelog.Debian.gz
libmimalloc-dev: /usr/share/doc/libmimalloc-dev/copyright

As a result, the C compiler cannot find
#include
Unless -I/usr/include/mimalloc-2.0/ is specified.

Why not strip mimalloc-2.0/ from the path?

Bug#1006139: libdeflate on armhf

[nick black]

hi, notcurses maintainer here. if you're going to proceed with this, the thing 
to do is mark notcurses as depending on zlib instead of libdeflate on this 
architecture, and build with `-DUSE_LIBDEFLATE=off`. the only differences ought 
be performance-related.

Bug#1006131: rus-ispell: please stop build-depending on myspell-tools

[Agustin Martin]

El lun, 21 feb 2022 a las 23:26, Mikhail Gusarov
() escribió:
>
> Hello Agustin,
>
> On 21 Feb 2022, at 23:12, Agustin Martin wrote:
>
> I am thinking about using ispellaff2myspell --bylocale flag with
> russian koi8-r locale set. This should only require an extra¡
> build-dep on locales-all and change myspell-tools to hunspell-tools. I
> am checking the result and only have noticed some sorting differences
> in characters inside regexp groups, nothing that should be a problem.
>
> Could you show me the difference?

Hi, Mikhail, thanks for your help.

Find attached diff. SInce flags are sorted differently by i2myspell
and ispellaff2myspell , I made some magic for easier check of result,
actually diffing sorted affix files. This is what leads to that file

LC_ALL=ru_RU.KOI8-R sort /usr/lib/aspell/ru_affix.dat > ru_fromaspell.sorted
LC_ALL=ru_RU.KOI8-R ispellaff2myspell --bylocale
/usr/lib/ispell/russian.aff > ru_fromispell
LC_ALL=ru_RU.KOI8-R sort ru_fromispell > ru_fromispell.sorted
diff -uw ru_fromaspell.sorted ru_fromispell.sorted > aspell_vs_ispell.diff

/usr/lib/aspell/ru_affix.dat is original affix file created by
i2myspell (and shipped by aspell-ru).

Regards,

-- 
Agustin
--- ru_fromaspell.sorted	2022-02-21 23:32:23.980184050 +0100
+++ ru_fromispell.sorted	2022-02-21 23:32:24.020184326 +0100
@@ -23,7 +23,6 @@
 
 
 
-SET KOI8-R
 SFX A   0ав
 SFX A   0аин
 SFX A   0ов
@@ -48,20 +47,20 @@
 SFX A   еми   [иы]е
 SFX A   ем[иы]е
 SFX A   ех[иы]е
-SFX A   ий   ая   [гхк]ий
+SFX A   ийая  [гкх]ий
 SFX A   ий   ая   [жшщч]ий
-SFX A   ий   его  [енржшщч]ий
-SFX A   ий   ее   [енжшщч]ий
-SFX A   ий   ей   [енжшщч]ий
-SFX A   ий   ем   [енржшщч]ий
-SFX A   ий   ему  [енржшщч]ий
-SFX A   ий   ею   [енжшщч]ий
-SFX A   ий   ого  [гхк]ий
-SFX A   ий   ое   [гхк]ий
-SFX A   ий   ой   [гхк]ий
-SFX A   ий   ом   [гхк]ий
-SFX A   ий   ому  [гхк]ий
-SFX A   ий   ою   [гхк]ий
+SFX A   ийего [ежнршщч]ий
+SFX A   ийее  [ежншщч]ий
+SFX A   ийей  [ежншщч]ий
+SFX A   ийем  [ежнршщч]ий
+SFX A   ийему [ежнршщч]ий
+SFX A   ийею  [ежншщч]ий
+SFX A   ийого [гкх]ий
+SFX A   ийое  [гкх]ий
+SFX A   ийой  [гкх]ий
+SFX A   ийом  [гкх]ий
+SFX A   ийому [гкх]ий
+SFX A   ийою  [гкх]ий
 SFX A   ийся аяся [шщ]ийся
 SFX A   ийся егося[шщ]ийся
 SFX A   ийся ееся [шщ]ийся
@@ -74,37 +73,37 @@
 SFX A   ийся имся [шщ]ийся
 SFX A   ийся ихся [шщ]ийся
 SFX A   ийся уюся [шщ]ийся
-SFX A   ий   ую   [гхк]ий
+SFX A   ийую  [гкх]ий
 SFX A   ий   ую   [жшщч]ий
 SFX A   ий   юю   [ен]ий
 SFX A   ий   яя   [ен]ий
-SFX A   йе[гхк]ий
-SFX A   йе[енржшщч]ий
+SFX A   й е   [гкх]ий
+SFX A   й е   [ежнршщч]ий
 SFX A   йеый
-SFX A   йм[гхк]ий
-SFX A   йм[енржшщч]ий
-SFX A   йми   [гхк]ий
-SFX A   йми   [енржшщч]ий
+SFX A   й м   [гкх]ий
+SFX A   й м   [ежнршщч]ий
+SFX A   й ми  [гкх]ий
+SFX A   й ми  [ежнршщч]ий
 SFX A   йми   ый
 SFX A   ймый
-SFX A   йх[гхк]ий
-SFX A   йх[енржшщч]ий
+SFX A   й х   [гкх]ий
+SFX A   й х   [ежнршщч]ий
 SFX A   йхый
 SFX A   йюой
 SFX A   ой   ая   ой
-SFX A   ой   ие   [гхкжшщч]ой
-SFX A   ой   им   [гхкжшщч]ой
-SFX A   ой   ими  [гхкжшщч]ой
-SFX A   ой   их   [гхкжшщч]ой
+SFX A   ойие  [гжкхшщч]ой
+SFX A   ойим  [гжкхшщч]ой
+SFX A   ойими [гжкхшщч]ой
+SFX A   ойих  [гжкхшщч]ой
 SFX A   ой   ого  ой
 SFX A   ой   ое   ой
 SFX A   ой   ом   ой
 SFX A   ой   ому  ой
 SFX A   ой   ую   ой
-SFX A   ой   ые   [^гхкжшщч]ой
-SFX A   ой   ым   [^гхкжшщч]ой
-SFX A   ой   ыми  [^гхкжшщч]ой
-SFX A   ой   ых   [^гхкжшщч]ой
+SFX A   ойые  [^гжкхшщч]ой
+SFX A   ойым  [^гжкхшщч]ой
+SFX A   ойыми [^гжкхшщч]ой
+SFX A   ойых  [^гжкхшщч]ой
 SFX A   ый   ая   ый
 SFX A   ый   его  цый
 SFX A   ый   ее   цый
@@ -145,8 +144,8 @@
 SFX B   ыться ойтесь   ыться
 SFX B   ьеить
 SFX D Y 5
-SFX D   иться атся [жшщч]иться
-SFX D   иться ятся [^жшщч]иться
+SFX D   иться атся[жчшщ]иться
+SFX D   иться ятся[^жчшщ]иться
 SFX D   ться ется [ая]ться
 SFX D   ться ются [ая]ться
 SFX D   ься  ся   иться
@@ -192,13 +191,13 @@
 SFX F   

Bug#1006131: rus-ispell: please stop build-depending on myspell-tools

[Mikhail Gusarov]

Hello Agustin,

On 21 Feb 2022, at 23:12, Agustin Martin wrote:

> I am thinking about using ispellaff2myspell --bylocale flag with
> russian koi8-r locale set. This should only require an extra¡
> build-dep on locales-all and change myspell-tools to hunspell-tools. I
> am checking the result and only have noticed some sorting differences
> in characters inside regexp groups, nothing that should be a problem.

Could you show me the difference?

> Other approach would be to borrow i2myspell, which is unmaintained.
>
> I do not speak russian, but I think this is nearly ready for release,
> hope Mikhail does not find problems with this.

---
Best,
Mikhail.

Bug#1006131: rus-ispell: please stop build-depending on myspell-tools

[Agustin Martin]

El sáb, 19 feb 2022 a las 17:39, Mattia Rizzolo () escribió:
>
> Source: rus-ispell
> Version: 0.99g5-27
> Severity: serious
>
> Dear maintainer,
>
> we plan to remove src:myspell really soon, and together with it also
> the package "myspell-tools".
> Your package still depends on it.

Hi, thanks for reminding,

I am thinking about using ispellaff2myspell --bylocale flag with
russian koi8-r locale set. This should only require an extra¡
build-dep on locales-all and change myspell-tools to hunspell-tools. I
am checking the result and only have noticed some sorting differences
in characters inside regexp groups, nothing that should be a problem.
Other approach would be to borrow i2myspell, which is unmaintained.

I do not speak russian, but I think this is nearly ready for release,
hope Mikhail does not find problems with this.

Unless problems appear, expect an upload soon.

Regards,

-- 
Agustin

Bug#1004769: digikam: FTBFS with ffmpeg 5.0

[Steven Robbins]

On Tue, 1 Feb 2022 21:01:39 +0100 Sebastian Ramacher  
wrote:
> Source: digikam
> Version: 4:7.1.0-2

I have just uploaded Digikam 7.5.0 to unstable.  If you have a chance to re-
try the build, would appreciate knowing if it now builds with new ffmpeg.

Thanks,
-Steve



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

Bug#1006248: RM: open3d [armel mips64el] -- ROM; missing B-D

[Timo Röhling]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear FTP team,

please remove the indicated binaries of open3d. The new version depends
on the filament library, which has non-trivial build problems on the
listed architectures (which also happen to be unsupported by upstream).


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmIUCj4ACgkQ+C8H+466
LVnb/gwA9rhqoy6io1VkoMkIFj7MaRpMqHdpi8FW3qGNFQiquJHwRWhJY4cpxkvb
B42aYbjwlJOx+fzZ5HCgf0mri82RCQvWuIlRX4iE7qJRlJpWs15X2ZbW5qYaKH0h
yGWUKDdHbdAWSqZ7dE6JXhwvndBNkZaA7zEpzcvnc481WFU4r1tgA5UoTYOgRV85
c1j+xWgdxz/WO6+6zvCwQzD/LwpdS5bXIpn9rD8s3sNjQL9j9lIdckIR+6LhtjW7
J7av9rfjg7KHknxbuNgORXQJ4yiV9M0OfET1mADSODi3uPLgvGLfI6FPCcs5GMIp
h5wbQ5chY5hn9WhizJmgCXm79qvI5esq2Awg8R+/ll0LbSRDBG5B9bbC+tmx1jTK
vJ+Dp+ma9FneWhSx0E6+XBMtp72nNYpaLL0/j0ji3avdWqPl3bvpbes2ZhIpZuZJ
goFR0+fkvLTTkx3e77/N2ka8xEOIx0XP9UfHhku3B7q/NOcHLtXxq1jW29kCQRp8
gKMJT34V
=KWsi
-END PGP SIGNATURE-

Bug#1000662: Bug#995189: RFH: isc-dhcp

[Santiago R.R.]

El 21/02/22 a las 15:19, Martin-Éric Racine escribió:
> On Mon, Feb 21, 2022 at 2:18 PM Martin-Éric Racine
>  wrote:
> >
> > On Thu, Jan 6, 2022 at 8:40 PM Santiago R.R.  wrote:
> > > On January 6, 2022 4:49:49 AM GMT-05:00, "Martin-Éric Racine" 
> > >  wrote:
> > > >Hello again,
> > > >
> > > >ke 24. marrask. 2021 klo 16.20 Santiago Ruano Rincón
> > > >(santiag...@riseup.net) kirjoitti:
> > > >> El 07/11/21 a las 13:54, Martin-Éric Racine escribió:
> > > >> > ma 27. syysk. 2021 klo 21.44 Santiago Ruano Rincón
> > > >> > (santiag...@riseup.net) kirjoitti:
> > > >> > > El 27/09/21 a las 20:25, Martin-Éric Racine escribió:
> > > >> > > > Package: wnpp
> > > >> > > > Severity: normal
> > > >> > > > X-Debbugs-Cc: debian-de...@lists.debian.org
> > > >> > > > Control: affects -1 src:isc-dhcp
> > > >> > > >
> > > >> > > > -BEGIN PGP SIGNED MESSAGE-
> > > >> > > > Hash: SHA256
> > > >> > > >
> > > >> > > > The ISC DHCP suite has a lenghty list of bug reports that have 
> > > >> > > > been left unattended. Some bugs date back to DHCP 3 or even 
> > > >> > > > earlier.
> > > >> > > >
> > > >> > > > Additionally, recent upstream releases are still unpackaged. One 
> > > >> > > > release came out well ahead of the Bullseye freeze, a bug report 
> > > >> > > > requesting its packaging was filed, but it remains unanswered.
> > > >> > > >
> > > >> > > > Leaving a package with a priority Important in such utter state 
> > > >> > > > of neglect is unacceptable.
> > > >> > > >
> > > >> > > > At this point, it has become clear that, at the very least, its 
> > > >> > > > maintainers need help, hence why I filed this WNPP bug.
> > > >> > >
> > > >> > > Indeed. I am willing to spend some cycles to help maintaining it. I
> > > >> > > requested access to the ISC DHCP packaging team in salsa ~a couple 
> > > >> > > of
> > > >> > > weeks ago, but I hasn't been answered yet (mgilbert is its only 
> > > >> > > member).
> > > >> > > It was on my ToDo list to ping the maintainers (in CC).
> > > >> >
> > > >> > Has any progress taken place on this?
> > > >>
> > > >> I've started doing some work at 
> > > >> https://salsa.debian.org/santiago/isc-dhcp/
> > > >>
> > > >> I still didn't get any answer from current maintainers (keeping them in
> > > >> CC), so I plan to retitle this bug as an ITS bug soon. Hopefully no
> > > >> later than next Friday.
> > > >
> > > >Has the ITA taken place?
> > > >
> > >
> > > Not an ITA, but an ITS (CCed). I was unable close according to the ITS 
> > > schedule, and I will have to resume the work after then end of my VAC 
> > > (mid-January)
> >
> > This was nearly 2 months ago.  At this point, I think that apollock
> > and mgilbert might as well be considered MIA.
> 
> Sure enough, upstream already is up to version 4.4.3b1, 26 January
> 2022, and recent commits include CVE fixes.

OK. I am resuming the work on this, and I'll upload it ASAP.

I have just requested to move the isc-dhcp packaging repo to the debian/
namespace.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1006247: Upgrade drumkit.xml files using hydrogen's new utility functionality

[Nicholas D Steeves]

Subject: Upgrade drumkit.xml files at build-time using Hydrogen's new utility 
functionality
Package: hydrogen-drumkits
X-Debbugs-Cc: s...@debian.org, Alessio Treglia , Free 
Ekanayaka , IOhannes m zmölnig (Debian/GNU) 
, Jaromír Mikeš ,
Version: 2017.09.19~dfsg-1
Severity: normal
Owner: s...@debian.org

I've CCed all Uploaders and am requesting that anyone who is no longer
interested in this package reply with something to the effect of "yes,
please drop me from Uploaders"--or just edit control in the git repo, as
preferred!  Jonas, I remember you asked to be dropped from src:hydrogen,
and am CCing you because I'd appreciate your perspective on this
problem.  As far as I can tell this will be the last issue you will hear
from me about Hydrogen!  Sorry I missed this when adopting the main
package :$ Likewise, I'd appreciate the perspective of anyone else on
the following issue:

I recently learned from upstream that drumkit.xml files are now
usually upgraded in $HOME when a newer version of Hydrogen is
executed.  Of course, that won't work in Debian (drumkit files in
/usr), so I opened an issue upstream requesting that the drumkit
upgrade function is exposed on the command line; it's fixed there
(albeit seemingly without support for relative paths, which may be
needed on buildd), and merging the patch set into Debian is pending.
I've of course already begun locally testing it.

Since bin:hydrogen-drumkits is a somewhat large package, I think that it
might be a good idea to introduce a bin:hydrogen-drumkits-xml package
that has some kind of dependency on the latest version of hydrogen,
because it seems to me that more often than not Hydrogen will emit
warnings whenever the version used to generate drumkits.xml doesn't
match bin:hydrogen's version...usually this will be cosmetic, I
think...except when it's not, and it doesn't make sense to me to
dedicate developer time to tracking genuine schema incompatibilities.
Any objections or alternative solutions would be very much welcome!  In
particular, I wonder if reprobuilds could be leveraged as a kind of
canary, where trivially scanning the debdiff would make it clear whether
an upgrade/upload of hydrogen-drumkits-xml was needed.

Alternatively it might also be a good idea to introduce a drumkit.xml
autopkgtest to src:hydrogen to block migration of bin:hydrogen until the
drumkit.xml package has also been updated in sid.  If someone has a good
regex heuristic that could reduce false positives and unnecessary
blocks, that'd be much appreciated!  I'm learning as I go and if working
along will probably defer this optimisation to a later date.

Oh, the proposed bin:hydrogen-drumkits-xml would be mostly to save user
and mirror bandwidth when tracking sid and testing.  I don't think that
it makes much difference for Debian infra disk space, and were it to
make a big difference, it seems that there's consensus that disk space
is now cheap.  It looks to me like a src:hydrogen-drumkits-xml (or
rebuilding them on the src:hydrogen) side isn't possible due to a
chicken egg problem for the drumkit.xml file when introducing new
drumkits to src:hydrogen-drumkits.


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#961147: libcolor-calc-perl: broken by new libgraphics-colornames-perl

[Damyan Ivanov]

-=| intrigeri, 22.05.2020 08:47:25 +0200 |=-
> Hi,
> 
> Niko Tyni (2020-05-21):
> > So IMO we should either to package Graphics::ColorNames::HTML even though
> > it's deprecated, or drop Color::Calc from Debian.
> 
> > libcolor-calc-perl has just one reverse dependency AFAICS:
> > libcgi-application-plugin-authentication-perl.
> 
> I took a quick look.

Me too, a longer one :)

I just pushed a patch in Git that makes Color::Calc use '::WWW' 
instead of '::HTML', sorting hash keys so that color names are 
enumerated in a deterministic order and adapted almost all of the 
tests (mainly "gray"→"grey" and "aqua"→"cyan").

There is one test still failing, about "safe" colors.

Then I read your comments about removal :)

Uncertain what to do with the "safe" color conversion, looking at the 
aged upstream release, I decided to stop here. Maybe someone some day 
will find the patch useful.

--dam

Bug#982925: libgtk: print dialog lists autodetected printer twice

[dxld]

Hi Simon,

Thanks for working on this, I do appreciate it :)

On Sun, Feb 20, 2022 at 05:19:32PM +, Simon McVittie wrote:
> On Mon, 26 Jul 2021 at 02:24:06 +0200, Daniel Gröber wrote:
> > I was seeing the exact same problem
> 
> That doesn't appear to be the exact same problem: Zack said that printing
> just doesn't happen, but Daniel said that printing produces a wrong
> print job.

That's probably not a symptom of the bug and just differing behavour of the
printers when presented with garbage input they don't understand.

AFAICT from the code, in the code-path where libgtk doesn't print via cups
no print-job filtering/reformatting happens at all but rather the plain pdf
is just piped stright to the print queue so that's not really surprising :)

> When reporting test results, please answer these questions:
> 
> * Which versions of cups-daemon and cups-filters-core-drivers are installed?
> * How many printers are physically present on your network?
> * Have you configured a printer queue in CUPS manually, or are you only
>   using auto-detection?
> * Is cups-browsed installed? If yes, which version?
> * What printer names appear in the GTK print dialog?
>   (If they contain MAC addresses or serial numbers, you can censor them
>   as XX)
> * For each printer name that appears:
>   * Does printing to it work?
>   * If not, what failure mode do you see?
> (Nothing happens / printer prints wrong results / other)

I'll make some time this weekend to test both versions. Should be pretty
quick as long as you don't need test results for a clean system -- do you?

--Daniel



signature.asc
Description: PGP signature

Bug#1006246: nodejs: FTBFS with OpenSSL 3.0

[Sebastian Andrzej Siewior]

Source: nodejs
Version: 12.22.9~dfsg-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Your package is failing to build using OpenSSL 3.0 with the
following error:

| ../src/node_crypto.cc: In function ‘unsigned int 
node::crypto::GetBytesOfRS(const node::crypto::ManagedEVPPKey&)’:
| ../src/node_crypto.cc:4607:37: warning: ‘const dsa_st* 
EVP_PKEY_get0_DSA(const EVP_PKEY*)’ is deprecated: Since OpenSSL 3.0 
[-Wdeprecated-declarations]
|  4607 | DSA* dsa_key = EVP_PKEY_get0_DSA(pkey.get());
|   |~^~~~
| In file included from /usr/include/openssl/x509.h:29,
|  from /usr/include/openssl/ssl.h:31,
|  from ../src/node_crypto.h:38,
|  from ../src/node_crypto.cc:22:
| /usr/include/openssl/evp.h:1355:22: note: declared here
|  1355 | const struct dsa_st *EVP_PKEY_get0_DSA(const EVP_PKEY *pkey);
|   |  ^
| ../src/node_crypto.cc:4607:37: error: invalid conversion from ‘const 
dsa_st*’ to ‘DSA*’ {aka ‘dsa_st*’} [-fpermissive]
|  4607 | DSA* dsa_key = EVP_PKEY_get0_DSA(pkey.get());
|   |~^~~~
|   | |
|   | const dsa_st*
| ../src/node_crypto.cc:4609:34: warning: ‘const BIGNUM* DSA_get0_q(const 
DSA*)’ is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations]
|  4609 | bits = BN_num_bits(DSA_get0_q(dsa_key));
|   |~~^
| In file included from /usr/include/openssl/x509.h:37,
|  from /usr/include/openssl/ssl.h:31,
|  from ../src/node_crypto.h:38,
|  from ../src/node_crypto.cc:22:
| /usr/include/openssl/dsa.h:209:37: note: declared here
|   209 | OSSL_DEPRECATEDIN_3_0 const BIGNUM *DSA_get0_q(const DSA *d);
|   | ^~
| ../src/node_crypto.cc:4611:42: warning: ‘const ec_key_st* 
EVP_PKEY_get0_EC_KEY(const EVP_PKEY*)’ is deprecated: Since OpenSSL 3.0 
[-Wdeprecated-declarations]
|  4611 | EC_KEY* ec_key = EVP_PKEY_get0_EC_KEY(pkey.get());
|   |  ^~~~
| In file included from /usr/include/openssl/x509.h:29,
|  from /usr/include/openssl/ssl.h:31,
|  from ../src/node_crypto.h:38,
|  from ../src/node_crypto.cc:22:
| /usr/include/openssl/evp.h:1372:25: note: declared here
|  1372 | const struct ec_key_st *EVP_PKEY_get0_EC_KEY(const EVP_PKEY *pkey);
|   | ^~~~
| ../src/node_crypto.cc:4611:42: error: invalid conversion from ‘const 
ec_key_st*’ to ‘EC_KEY*’ {aka ‘ec_key_st*’} [-fpermissive]
|  4611 | EC_KEY* ec_key = EVP_PKEY_get0_EC_KEY(pkey.get());
|   |  ^~~~
|   |  |
|   |  const ec_key_st*

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html

Sebastian

Bug#1006245: libwebsockets: FTBFS with OpenSSL 3.0

[Sebastian Andrzej Siewior]

Source: libwebsockets
Version: 4.0.20-2
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Your package is failing to build using OpenSSL 3.0 with the
following error:

| [ 31%] Building C object 
CMakeFiles/websockets.dir/lib/tls/openssl/openssl-server.c.o
| /usr/bin/cc  -I/<>/include -I/<>/plugins 
-I/<>/lib/core -I/<>/lib/core-net 
-I/<>/lib/event-libs -I/<>/include/abstract 
-I/<>/lib/tls -I/<>/lib/roles 
-I/<>/lib/event-libs/libuv -I/<>/lib/event-libs/poll 
-I/<>/lib/event-libs/libevent 
-I/<>/lib/event-libs/glib -I/<>/lib/event-libs/libev 
-I/<>/lib/jose/jwe -I/<>/lib/jose/jws 
-I/<>/lib/jose -I/<>/lib/misc 
-I/<>/lib/roles/http -I/<>/lib/roles/http/compression 
-I/<>/lib/roles/h1 -I/<>/lib/roles/h2 
-I/<>/lib/roles/ws -I/<>/lib/roles/cgi 
-I/<>/lib/roles/dbus -I/<>/lib/roles/raw-proxy 
-I/<>/lib/abstract -I/<>/lib/system/async-dns 
-I/<>/lib/roles/mqtt -I/<>/lib/plat/unix 
-I/<>/obj-x86_64-linux-gnu -I/<>/lib -Wall 
-Wsign-compare -Wstrict-aliasing -Wuninitialized -Werror -fvisibility=hidden 
-Wundef  -Wtype-limits -Wignored-qualifiers -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -fno-strict-aliasing -Wno-error=format-truncation 
-Wno-error=format-overflow -Wdate-time -D_FORTIFY_SOURCE=2  -pthread -MD -MT 
CMakeFiles/websockets.dir/lib/tls/openssl/openssl-server.c.o -MF 
CMakeFiles/websockets.dir/lib/tls/openssl/openssl-server.c.o.d -o 
CMakeFiles/websockets.dir/lib/tls/openssl/openssl-server.c.o -c 
/<>/lib/tls/openssl/openssl-server.c
| /<>/lib/tls/openssl/openssl-server.c: In function 
‘lws_tls_server_certs_load’:
| /<>/lib/tls/openssl/openssl-server.c:403:9: error: 
‘EC_KEY_new_by_curve_name’ is deprecated: Since OpenSSL 3.0 
[-Werror=deprecated-declarations]
|   403 | ecdh = EC_KEY_new_by_curve_name(ecdh_nid);
|   | ^~~~
| In file included from /usr/include/openssl/x509.h:33,
|  from /usr/include/openssl/ssl.h:31,
|  from /<>/include/libwebsockets.h:250,
|  from /<>/lib/core/private-lib-core.h:135,
|  from /<>/lib/tls/openssl/openssl-server.c:25:
| /usr/include/openssl/ec.h:996:31: note: declared here
|   996 | OSSL_DEPRECATEDIN_3_0 EC_KEY *EC_KEY_new_by_curve_name(int nid);
|   |   ^~~~
| /<>/lib/tls/openssl/openssl-server.c:409:9: error: 
‘EC_KEY_free’ is deprecated: Since OpenSSL 3.0 
[-Werror=deprecated-declarations]
|   409 | EC_KEY_free(ecdh);
|   | ^~~
| In file included from /usr/include/openssl/x509.h:33,
|  from /usr/include/openssl/ssl.h:31,
|  from /<>/include/libwebsockets.h:250,
|  from /<>/lib/core/private-lib-core.h:135,
|  from /<>/lib/tls/openssl/openssl-server.c:25:
| /usr/include/openssl/ec.h:1001:28: note: declared here
|  1001 | OSSL_DEPRECATEDIN_3_0 void EC_KEY_free(EC_KEY *key);
|   |^~~
| /<>/lib/tls/openssl/openssl-server.c:451:9: error: 
‘EVP_PKEY_get1_EC_KEY’ is deprecated: Since OpenSSL 3.0 
[-Werror=deprecated-declarations]
|   451 | EC_key = EVP_PKEY_get1_EC_KEY(pkey);
|   | ^~
| In file included from /usr/include/openssl/x509.h:29,
|  from /usr/include/openssl/ssl.h:31,
|  from /<>/include/libwebsockets.h:250,
|  from /<>/lib/core/private-lib-core.h:135,
|  from /<>/lib/tls/openssl/openssl-server.c:25:
| /usr/include/openssl/evp.h:1374:19: note: declared here
|  1374 | struct ec_key_st *EVP_PKEY_get1_EC_KEY(EVP_PKEY *pkey);
|   |   ^~~~
| /<>/lib/tls/openssl/openssl-server.c:459:9: error: 
‘EC_KEY_free’ is deprecated: Since OpenSSL 3.0 
[-Werror=deprecated-declarations]
|   459 | EC_KEY_free(EC_key);
|   | ^~~
| In file included from /usr/include/openssl/x509.h:33,
|  from /usr/include/openssl/ssl.h:31,
|  from /<>/include/libwebsockets.h:250,
|  from /<>/lib/core/private-lib-core.h:135,
|  from /<>/lib/tls/openssl/openssl-server.c:25:
| /usr/include/openssl/ec.h:1001:28: note: declared here
|  1001 | OSSL_DEPRECATEDIN_3_0 void EC_KEY_free(EC_KEY *key);
|   |^~~
| cc1: all warnings being treated as errors
| make[3]: *** [CMakeFiles/websockets.dir/build.make:765: 
CMakeFiles/websockets.dir/lib/tls/openssl/openssl-server.c.o] Error 1

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html

Sebastian

Bug#1006244: librabbitmq: FTBFS with OpenSSL 3.0

[Sebastian Andrzej Siewior]

Source: librabbitmq
Version: 0.10.0-1
Severity: important
Tags: bookworm sid fixed-upstream
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Your package is failing to build using OpenSSL 3.0 with the
following error:

| [ 32%] Linking C executable amqp_sendstring
| cd /<>/obj-x86_64-linux-gnu/examples && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/amqp_sendstring.dir/link.txt --verbose=1
| /usr/bin/cc -Wall -Wextra -Wstrict-prototypes -Wno-unused-function 
-fno-common -fvisibility=hidden -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=gnu90 -Wl,-z,relro -Wl,-z,now -rdynamic 
CMakeFiles/amqp_sendstring.dir/amqp_sendstring.c.o 
CMakeFiles/amqp_sendstring.dir/utils.c.o 
CMakeFiles/amqp_sendstring.dir/unix/platform_utils.c.o -o amqp_sendstring  
-Wl,-rpath,/<>/obj-x86_64-linux-gnu/librabbitmq 
../librabbitmq/librabbitmq.so.4.4.0 -lssl -lcrypto -lrt -pthread 
| /usr/bin/ld: ../librabbitmq/librabbitmq.so.4.4.0: undefined reference to 
`FIPS_mode_set'
| collect2: error: ld returned 1 exit status
| make[3]: *** [examples/CMakeFiles/amqp_sendstring.dir/build.make:135: 
examples/amqp_sendstring] Error 1

According to upstream's release notes, v0.11.0 has OpenSSL 3.0 support.

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html

Sebastian

Bug#1006009: qtimageformats-opensource-src: FTBFS on mipsel: test failure

[Sebastian Ramacher]

On 2022-02-20 18:33:22, Dmitry Shachnev wrote:
> Control: reassign -1 libwebp7 1.2.1-7
> Control: affects -1 src:qtimageformats-opensource-src
> 
> Hi Sebastian and libwebp maintainers!
> 
> On Fri, Feb 18, 2022 at 10:39:23PM +0100, Sebastian Ramacher wrote:
> > Source: qtimageformats-opensource-src
> > Version: 5.15.2-2
> > Severity: serious
> > Tags: ftbfs
> > Justification: fails to build from source (but built successfully in the 
> > past)
> > X-Debbugs-Cc: sramac...@debian.org
> >
> > qtimageformats-opensource-src FTBFS on mipsel:
> >
> > TIFFReadDirectory: Warning, Sum of Photometric type-related color channels 
> > and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels 
> > as ExtraSamples..
> > TIFFReadDirectory: Warning, Sum of Photometric type-related color channels 
> > and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels 
> > as ExtraSamples..
> > PASS   : tst_qtiff::tiffGrayscale()
> > FAIL!  : tst_qwebp::writeImage(kollada_noalpha-100) '!reread.isNull()' 
> > returned FALSE. ()
> >Loc: [tst_qwebp.cpp(174)]
> > PASS   : tst_qwebp::cleanupTestCase()
> > Totals: 10 passed, 1 failed, 0 skipped, 0 blacklisted, 632ms
> > * Finished testing of tst_qwebp *
> >
> > See
> > https://buildd.debian.org/status/fetch.php?pkg=qtimageformats-opensource-src=mipsel=5.15.2-2%2Bb1=1645209225=0
> 
> It looks to me like a bug in new libwebp version: encoder generates broken
> webp files on mipsel.
> 
> I can reproduce it without any Qt code by encoding the attached PNG file and
> then trying to decode it back:
> 
> (sid_mipsel-dchroot)mitya57@eller:~$ cwebp kollada_noalpha.png -lossless -o 
> kollada_noalpha.webp
> Saving file 'kollada_noalpha.webp'
> File:  kollada_noalpha.png
> Dimension: 436 x 160
> Output:37004 bytes (4.24 bpp)
> Lossless-ARGB compressed size: 37004 bytes
>   * Header size: 636 bytes, image data size: 36342
>   * Precision Bits: histogram=3 transform=3 cache=1
> (sid_mipsel-dchroot)mitya57@eller:~$ dwebp kollada_noalpha.webp
> Decoding of kollada_noalpha.webp failed.
> Status: 3(BITSTREAM_ERROR)
> 
> I am also attaching the generated broken WEBP file.

A git bisect run suggests that this issue was introduced upstream in
dea3e89983f299b3325898fa5b9474be258553b2 and is not yet fixed.

Cheers
-- 
Sebastian Ramacher

Bug#1003470: openimageio FTBFS: invalid preprocessing directive #errorDCMTK

[Matteo F. Vescovi]

Hi Jeremy!

Il lun 21 feb 2022, 03:57 Jeremy Bicha  ha
scritto:

> In Ubuntu, we fixed this issue by building with C++17.
>
> You can find a diff of the rules file at
> https://launchpad.net/ubuntu/+source/openimageio/2.2.18.0+dfsg-1ubuntu
> 


Ah, thanks for the heads up!

I'll fix it asap.

Cheers.

mfv

Bug#1006243: i2pd: FTBFS with OpenSSL 3.0

[Sebastian Andrzej Siewior]

Source: i2pd
Version: 2.39.0-1
Severity: important
Tags: bookworm sid patch fixed-upstream
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0
control: forwarded -1 
https://github.com/PurpleI2P/i2pd/commit/921ec9ec12ead861994c98d96087b93a31051ef5

Your package is failing to build using OpenSSL 3.0 with the
following error:

| /<>/libi2pd/Crypto.cpp: In function ‘void 
i2p::crypto::HKDF(const uint8_t*, const uint8_t*, size_t, const string&, 
uint8_t*, size_t)’:
| /<>/libi2pd/Crypto.cpp:1305:71: error: invalid conversion from 
‘const char*’ to ‘const unsigned char*’ [-fpermissive]
|  1305 | EVP_PKEY_CTX_add1_hkdf_info (pctx, info.c_str 
(), info.length ());
|   |
~~~^~
|   |   
|
|   |   
const char*
| 

It appears to be fixed in 2.40.0.

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html

Sebastian

Bug#1006242: geoclue-2.0: Please package 2.6.0

[Jeremy Bicha]

Source: geoclue-2.0
Version: 2.5.7-3
Severity: wishlist

Please package geoclue 2.6.0

https://gitlab.freedesktop.org/geoclue/geoclue/-/blob/master/NEWS

Thank you,
Jeremy Bicha

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Simon McVittie]

Here is hopefully a better solution for GTK 3 in bullseye:

https://people.debian.org/~smcv/bullseye-gtk-printing/mr6.1/

or if the release team will not accept that, then this:

https://people.debian.org/~smcv/bullseye-gtk-printing/mr9.1/

Please try those (in preference to mr6, mr9) and see what happens with
your particular printers.

As before, the _binary.changes and .dsc files are signed with my key in
the Debian keyring, and can be verified with the dscverify tool from the
devscripts package (this requires devscripts and debian-archive-keyring
installed).

Test results below.

smcv

> * Which versions of cups-daemon and cups-filters-core-drivers are installed?

cups-daemon 2.3.3op2-3+deb11u1
cups-filters-core-drivers   1.28.7-1

> * How many printers are physically present on your network?

One HP Color LaserJet MFP M277dw.

> * Is cups-browsed installed? If yes, which version?

I tested both with and without cups-browsed 1.28.7-1.

Test methodology for each of the 8 attempts listed here (I'm using an
expendable test machine, do not do these steps unless you are willing
to lose manual CUPS configuration):

sudo apt purge cups-browsed cups-daemon
sudo rm -fr /etc/cups
sudo apt install cups cups-core-drivers cups-daemon cups-browsed-
(optionally) Configure printer: gnome-control-center, Printers, Unlock,
 Add..., wait, click on the single printer that appears, Add
(optionally) sudo apt install cups-browsed
gedit
Try to print

GTK 3.24.24-4 (status quo in bullseye)
==

Repeating my previous test results for reference:

| cups-browsed installed |
|no  | yes   |
||---|
printer manually configured   no|unavailable | works |
 yes| works  |duplicated |
||---|

GTK based on merge request 6 (full backport from 3.24.29)
=

| cups-browsed installed |
|no  | yes   |
||---|
printer manually configured   no| works  | works |
 yes| works  | works |
||---|

With no configuration and no cups-browsed: One printer appears in the
GTK dialog, labelled HP_Color_LaserJet_MFP_M277dw_xx_. It is not
listed in /etc/cups/printers.conf. Printing is successful.

With cups-browsed only: One printer appears, labelled
HP_Color_LaserJet_MFP_M277dw_xx_.
It is listed in /etc/cups/printers.conf, labelled as having come from
cups-browsed. It prints successfully.

With manual configuration only: One printer, HP-Color-LaserJet-MFP-M277dw.
It appears in /etc/cups/printers.conf. Printing is successful.
(This is actually better than the Qt app featherpad, which displays two
printers in this situation.)

With both: Same as with manual configuration only.

GTK based on merge request 9 (Daniel's minimal backport)


| cups-browsed installed  |
|no  | yes|
|||
printer manually configured   no| works  | works  |
 yes| works  | duplicated |
|||

With no configuration and no cups-browsed: One printer appears in the
GTK dialog, labelled HP_Color_LaserJet_MFP_M277dw_xx_. It is not
listed in /etc/cups/printers.conf. Printing is successful.

With cups-browsed only: One printer, HP_Color_LaserJet_MFP_M277dw_xx_,
where xx is a unique ID taken from its MAC address. It is in
/etc/cups/printers.conf. Printing is successful.

With manual configuration only: One printer, HP-Color-LaserJet-MFP-M277dw.
It appears in /etc/cups/printers.conf. Printing is successful.

With both: both of the printers mentioned above appear in the GTK dialog
and in /etc/cups/printers.conf. Only the first one printed successfully:
the second logged "NO_DEST_FOUND".

Bug#1006241: yubico-piv-tool: FTBFS with OpenSSL 3.0

[Sebastian Andrzej Siewior]

Source: yubico-piv-tool
Version: 2.2.0-1
Severity: important
Tags: bookworm sid patch fixed-upstream
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0
control: forwarded -1 https://github.com/Yubico/yubico-piv-tool/pull/334

Your package is failing to build using OpenSSL 3.0 with the
following error:

| cd /<>/obj-x86_64-linux-gnu/ykcs11 && /usr/bin/cc 
-DCRYPTOKI_EXPORTS -DHAVE_EXPLICIT_BZERO -I/<>/lib 
-I/<>/ykcs11 -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -pthread -Wdate-time 
-D_FORTIFY_SOURCE=2 -w -Wall -Wextra -Werror -Wshadow -Wwrite-strings 
-Wmissing-prototypes -Wbad-function-cast -pedantic -fstack-protector-all 
-std=c99 -Wno-unused-result  -fvisibility=hidden -fPIC -DSTATIC  -std=gnu99 -MD 
-MT ykcs11/CMakeFiles/ykcs11.dir/ykcs11.c.o -MF 
CMakeFiles/ykcs11.dir/ykcs11.c.o.d -o CMakeFiles/ykcs11.dir/ykcs11.c.o -c 
/<>/ykcs11/ykcs11.c
| In file included from /usr/include/openssl/crypto.h:39,
|  from /usr/include/openssl/bn.h:26,
|  from /<>/ykcs11/openssl_types.h:34,
|  from /<>/ykcs11/ykcs11.h:37,
|  from /<>/ykcs11/ykcs11.c:31:
| /usr/include/openssl/core.h:72:11: error: unknown type name 
‘OSSL_DISPATCH’
|72 | const OSSL_DISPATCH *implementation;
|   |   ^
| /usr/include/openssl/core.h:191:43: error: unknown type name 
‘OSSL_DISPATCH’
|   191 | const OSSL_DISPATCH *in,
|   |   ^
| /usr/include/openssl/core.h:192:43: error: unknown type name 
‘OSSL_DISPATCH’
|   192 | const OSSL_DISPATCH **out,
|   |   ^
| /usr/include/openssl/core.h:216:35: error: unknown type name ‘OSSL_PARAM’
|   216 | typedef int (OSSL_CALLBACK)(const OSSL_PARAM params[], void *arg);
|   |   ^~
| /usr/include/openssl/core.h:217:41: error: unknown type name ‘OSSL_PARAM’
|   217 | typedef int (OSSL_INOUT_CALLBACK)(const OSSL_PARAM in_params[],
|   | ^~
| /usr/include/openssl/core.h:218:35: error: unknown type name 
‘OSSL_PARAM’; did you mean ‘OSSL_PARAM_REAL’?
|   218 |   OSSL_PARAM out_params[], void *arg);
|   |   ^~
|   |   OSSL_PARAM_REAL
| /usr/include/openssl/core.h:227:46: error: unknown type name ‘OSSL_PARAM’
|   227 |const OSSL_PARAM params[], 
void *arg);
|   |  ^~
| In file included from /usr/include/openssl/bn.h:26,
|  from /<>/ykcs11/openssl_types.h:34,
|  from /<>/ykcs11/ykcs11.h:37,
|  from /<>/ykcs11/ykcs11.c:31:
…

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html

Sebastian

Bug#1006219: new expat causes regressions in the python autopkg tests

[Matthias Klose]

On 2/21/22 21:31, Salvatore Bonaccorso wrote:
> Control: forwarded -1 https://bugs.python.org/issue46811
> Control: affects -1 + src:expat
> Control: clone -1 -2 -3
> Control: reassign -1 src:python3.10 3.10.2-1
> Control: reassign -2 src:python3.9 3.9.10-1
> Control: reassign -3 src:python2.7 2.7.18-12
> 
> Hi László, hi Matthias,
> 
> On Mon, Feb 21, 2022 at 08:44:26PM +0100, Salvatore Bonaccorso wrote:
>> Hi,
>>
>> On Mon, Feb 21, 2022 at 05:10:02PM +0100, László Böszörményi wrote:
>>> Control: tags -1 +confirmed
>>>
>>> Hi Matthias,
>>>
>>> On Mon, Feb 21, 2022 at 2:57 PM Matthias Klose  wrote:
 The new expat causes regressions in the python autopkg tests. I also see 
 there
 is a new upstream 2.4.6. Didn't check that yet.
>>>  Basically 2.4.5-2 and 2.4.6 should be identical. I can package the
>>> latter for you if you want.
>>> Will contact upstream about this and see what he finds.
>>
>> It looks this is actually an issue in python's testsuite. Upstream
>> report is at https://bugs.python.org/issue46811 and
>> https://github.com/python/cpython/pull/31453 .
> 
> So given the above, I'm trying to reassign it now to the relevant
> python packages accordingly, bear with me that I have not done
> mistkaes with the control commands.

thanks for looking at these. I'll prepare uploads soonish.

Matthias

Bug#1006219: new expat causes regressions in the python autopkg tests

[Salvatore Bonaccorso]

Control: forwarded -1 https://bugs.python.org/issue46811
Control: affects -1 + src:expat
Control: clone -1 -2 -3
Control: reassign -1 src:python3.10 3.10.2-1
Control: reassign -2 src:python3.9 3.9.10-1
Control: reassign -3 src:python2.7 2.7.18-12

Hi László, hi Matthias,

On Mon, Feb 21, 2022 at 08:44:26PM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Mon, Feb 21, 2022 at 05:10:02PM +0100, László Böszörményi wrote:
> > Control: tags -1 +confirmed
> > 
> > Hi Matthias,
> > 
> > On Mon, Feb 21, 2022 at 2:57 PM Matthias Klose  wrote:
> > > The new expat causes regressions in the python autopkg tests. I also see 
> > > there
> > > is a new upstream 2.4.6. Didn't check that yet.
> >  Basically 2.4.5-2 and 2.4.6 should be identical. I can package the
> > latter for you if you want.
> > Will contact upstream about this and see what he finds.
> 
> It looks this is actually an issue in python's testsuite. Upstream
> report is at https://bugs.python.org/issue46811 and
> https://github.com/python/cpython/pull/31453 .

So given the above, I'm trying to reassign it now to the relevant
python packages accordingly, bear with me that I have not done
mistkaes with the control commands.

Regards,
Salvatore

Bug#1006238: 7-Zip: Shows password in clear text while it is being entered

[kyeastmood]

Package: 7zip
Version: 21.07+dfsg-2

When trying to list, extract or test an archive with encrypted data,
7-Zip asks for password but it doesn't hide it while it is being
entered.

Solution:
Nothing should be printed when a user enters password.

Thank you

Bug#892058: debian-keyring: please automatically send reminder emails to people whose keys will expire soon

[Samuel Henrique]

Thanks for the ping!

Last time I didn't notice my key was about to expire and as a result a
few uploads of mine got delayed by the key refresh in the keyring.

Cheers,

-- 
Samuel Henrique 

Bug#1006152: mozjs91: FTBFS on i386: test262/built-ins/Date/UTC/fp-evaluation-order.js

[Simon McVittie]

Control: severity -1 important

On Mon, 21 Feb 2022 at 00:15:41 +, Simon McVittie wrote:
> I'm testing a patch (basically just extending Marco's workaround to
> apply to i386 too). If successful, I'll downgrade the severity of this bug
> but leave it open.

Looks like this worked.

smcv

Bug#665774: Messes up $PATH

[Andras Korn]

FWIW, this is now fixed in the latest upstream master:

https://github.com/dell/dkms/pull/193/commits/775a3389ebbafb4fb5d59747667e604cf4f4d903

András

-- 
 Crime is merely politics without the excuses.

Bug#1006236: dpkg-sig --gpgoptions doesn't work, but its shortcut -g does

[Andy Castille]

Package: dpkg-sig
Version: 0.13.1+nmu4

Passing -g appears to work:

$ dpkg-sig -g '--passphrase-fd 0 --pinentry-mode loopback' --sign
Option sign requires an argument

According to the documentation, passing --gpgoptions should behave the
same, but instead it doesn't appear to be recognized at all:

$ dpkg-sig --gpgoptions '--passphrase-fd 0 --pinentry-mode loopback' --sign
Unknown option: gpgoptions
Unknown option: passphrase-fd 0 --pinentry-mode loopback
Option sign requires an argument

Kernel: Linux BOXYBOI 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr
2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Shared C library: 2.31-0ubuntu9.2

I ran the commands on a WSL Ubuntu system to copy the output here, but
this behaves the same way on a normal system.

Bug#1005887: unixodbc-dev does not contain unixodbc_conf.h

[Jan Wielemaker]

Hi Hugh,

Thanks for your answer.  I'm not convinced.  You are telling that we 
must define macros to make sql.h get the right type for SQLBIGINT.

Getting the right type (some alias for int64_t or a struct) is IMO
something that should be done by unixodb such that the application
gets a working SQLBIGINT that matches the library.  That is how it
used to be as long as we use unixodbc.   sql.h used to do so by 
including the platform dependent type configuration file.  As it

is working now, we actually have to know which of the HAVE_* and
SIZEOF_* macros we must define before including sql.h.

If this is no longer how it works, do you happen to know the
motivation why not?

Thanks --- Jan

Bug#1006235: stgit: please re-enable the interactive tests

[Daniel Shahaf]

Source: stgit
Version: 0.19-1
Severity: normal
Tags: patch

Dear Maintainer,

One of the Debian changes (debian/patches/*) disables part of the test
suite.

Please consider the following patch so the entire test suite runs.  It
deletes debian/patches/disable_interactive_test and extends
debian/patches/use_editor_as_default to also update the test suite as
needed.  The net result is that t3300-edit.sh now runs.

[[[
diff --git a/debian/patches/use_editor_as_default 
b/debian/patches/use_editor_as_default
index f941073..65d96cb 100644
--- a/debian/patches/use_editor_as_default
+++ b/debian/patches/use_editor_as_default
@@ -9,8 +9,6 @@ Last-Update: 2014-03-26
  stgit/utils.py | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
-diff --git a/stgit/utils.py b/stgit/utils.py
-index cdcc4a9..fbd79a2 100644
 --- a/stgit/utils.py
 +++ b/stgit/utils.py
 @@ -176,7 +176,7 @@ def get_editor():
@@ -22,3 +20,38 @@ index cdcc4a9..fbd79a2 100644
  if editor:
  return editor
  
+--- a/t/t3300-edit.sh
 b/t/t3300-edit.sh
+@@ -87,7 +87,7 @@ test_expect_success 'Save template to st
+ #   3. core.editor
+ #   4. VISUAL
+ #   5. EDITOR
+-#   6. vi
++#   6. editor
+ 
+ mkeditor ()
+ {
+@@ -98,11 +98,11 @@ EOF
+ chmod a+x "$1"
+ }
+ 
+-mkeditor vi
+-test_expect_success 'Edit commit message interactively (vi)' '
++mkeditor editor
++test_expect_success 'Edit commit message interactively (editor)' '
+ m=$(msg HEAD) &&
+ PATH=.:$PATH stg edit p2 &&
+-test "$(msg HEAD)" = "$m/vi"
++test "$(msg HEAD)" = "$m/editor"
+ '
+ 
+ mkeditor e1
+@@ -143,7 +143,7 @@ test_expect_success 'Edit commit message
+ test "$(msg HEAD)" = "$m/e5"
+ '
+ 
+-rm -f vi e1 e2 e3 e4 e5
++rm -f editor e1 e2 e3 e4 e5
+ git config --unset core.editor
+ git config --unset stgit.editor
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 7b014e7..fd89c42 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,4 +1,3 @@
 use_editor_as_default
 stg-gitk_bashism
-disable_interactive_test
 Avoid-the-git-error-messages-when-running-stg-outside-of-.patch
diff --git a/debian/patches/disable_interactive_test 
b/debian/patches/disable_interactive_test
deleted file mode 100644
index 12a6a5b..000
--- a/debian/patches/disable_interactive_test
+++ /dev/null
@@ -1,27 +0,0 @@
-From: Maximiliano Curia 
-Date: Sat, 2 Sep 2017 14:06:57 +0200
-Subject: Disable test calling editor
-
-Upstream uses vi as the default editor, while the debian packages default to
-the editor command, thus the different behavior.
-
-Author: Maximiliano Curia 
-Forwarded: not-needed
-Last-Update: 2014-03-26

- t/t3300-edit.sh | 2 ++
- 1 file changed, 2 insertions(+)
-
-diff --git a/t/t3300-edit.sh b/t/t3300-edit.sh
-index 61baab8..392e1f3 100755
 a/t/t3300-edit.sh
-+++ b/t/t3300-edit.sh
-@@ -2,6 +2,8 @@
- test_description='Test "stg edit"'
- 
- . ./test-lib.sh
-+test_done
-+exit
- 
- test_expect_success 'Setup' '
- printf "000\n111\n222\n333\n" >> foo &&
]]]

Cheers,

Daniel

Bug#1006219: new expat causes regressions in the python autopkg tests

[Salvatore Bonaccorso]

Hi,

On Mon, Feb 21, 2022 at 05:10:02PM +0100, László Böszörményi wrote:
> Control: tags -1 +confirmed
> 
> Hi Matthias,
> 
> On Mon, Feb 21, 2022 at 2:57 PM Matthias Klose  wrote:
> > The new expat causes regressions in the python autopkg tests. I also see 
> > there
> > is a new upstream 2.4.6. Didn't check that yet.
>  Basically 2.4.5-2 and 2.4.6 should be identical. I can package the
> latter for you if you want.
> Will contact upstream about this and see what he finds.

It looks this is actually an issue in python's testsuite. Upstream
report is at https://bugs.python.org/issue46811 and
https://github.com/python/cpython/pull/31453 .

Regards,
Salvatore

Bug#990201: CVE-2021-33622 (was: Re: Accepted singularity-container 3.9.5+ds1-1 (source) into experimental)

[Salvatore Bonaccorso]

Hi again as well,

On Tue, Feb 22, 2022 at 12:44:49AM +0530, Nilesh Patra wrote:
> Hi again,
> 
> On Mon, 21 Feb 2022 01:03:13 +0530 Nilesh Patra  wrote:
> > > So where has this issue bin fixed?
> > 
> > But yes, you are right, even at Mitre metadata, I do not find any 
> > information
> > about any patch for the bug; i.e. I do not see the "code" that fixes it, 
> > and hence
> > I too am skeptical whether or not it is really gone.
> > 
> > For the sake of completeness, I have opened a issue upstream[1]
> 
> Upstream confirmed that this issue no longer surfaces new versions, here[2]
> and here[3].
> So I guess, all good.
>  
> > [1]: https://github.com/sylabs/singularity/issues/586
> [2]: https://github.com/sylabs/singularity/issues/586#issuecomment-1046969527
> [3]: https://groups.google.com/g/singularity-ce/c/OSK5BIHSkbE/m/6dc0DEMiAgAJ

Thanks! Upstream IMHO is still not fully transparent on the
CVE-2021-33622 after reading your references. Thanks a lot for
researching, I have just updated the security-tracker information
about it.

Regards,
Salvatore

Bug#551400: [Pkg-pascal-devel] Bug#551400: fpc on kfreebsd-i386

[Paul Gevers]

Hi Abou,

I think it's fair to say that the kfreebsd port in Debian are fairly 
dead. I wouldn't spend time on solving bugs on that architecture unless 
you have personal interest.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#990201: CVE-2021-33622 (was: Re: Accepted singularity-container 3.9.5+ds1-1 (source) into experimental)

[Nilesh Patra]

Hi again,

On Mon, 21 Feb 2022 01:03:13 +0530 Nilesh Patra  wrote:
> > So where has this issue bin fixed?
> 
> But yes, you are right, even at Mitre metadata, I do not find any information
> about any patch for the bug; i.e. I do not see the "code" that fixes it, and 
> hence
> I too am skeptical whether or not it is really gone.
> 
> For the sake of completeness, I have opened a issue upstream[1]

Upstream confirmed that this issue no longer surfaces new versions, here[2]
and here[3].
So I guess, all good.
 
> [1]: https://github.com/sylabs/singularity/issues/586
[2]: https://github.com/sylabs/singularity/issues/586#issuecomment-1046969527
[3]: https://groups.google.com/g/singularity-ce/c/OSK5BIHSkbE/m/6dc0DEMiAgAJ

Regards,
Nilesh


signature.asc
Description: PGP signature

Bug#1006234: RFS: rednotebook/2.24+ds-1 -- Modern desktop diary and personal journaling tool

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: rednotebook
   Version : 2.24+ds-1
   Upstream Author : Jendrik Seipp 
 * URL : https://rednotebook.app
 * License : LGPL-3+, PSF-2, CC0-1.0, GPL-2+, GPL-3+
 * Vcs : https://github.com/jendrikseipp/rednotebook
   Section : text

It builds those binary packages:

  rednotebook - Modern desktop diary and personal journaling tool

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rednotebook/rednotebook_2.24+ds-1.dsc

Changes since the last upload:

 rednotebook (2.24+ds-1) unstable; urgency=medium
 .
   * New upstream release 2.24.

Note: Will be imported into salsa once passed and uploaded into unstable by 
sponsor.

Regards

Phil

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

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1005889: dbus: flaky autopkgtest on ppc64el: dbus/integration/transient-services.sh.test

[Paul Gevers]

Hi Simon,

On 21-02-2022 12:10, Simon McVittie wrote:

Is there anything unusual about the ppc64el CI-runners compared with other
architectures? (For example: lots of CPUs, few CPUs, lots of RAM, less RAM,
lots of I/O bandwidth, running on tmpfs, using qemu, using lxc, running
many tests in parallel, ...)


Our ppc64el runners are quite similar in terms of CPU, RAM etc as most 
of our amd64/i386/arm64 workers. The thing I noticed them to be 
different is that they seem to run in a virtual environment:

debian@ci-worker-ppc64el-01:~$ lspci
00:01.0 Ethernet controller: Red Hat, Inc. Virtio network device
00:02.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI
00:03.0 USB controller: Red Hat, Inc. QEMU XHCI Host Controller (rev 01)
00:04.0 Communication controller: Red Hat, Inc. Virtio console
00:05.0 Unclassified device [00ff]: Red Hat, Inc. Virtio memory balloon
00:06.0 VGA compatible controller: Device 1234: (rev 02)


From https://ci.debian.net/packages/d/dbus/testing/ppc64el/ it looks like

this is failing about 25% of the time, does that match your experience?


I was totally judging form this page, so yes.


Bail out! /run/user/1000/dbus-1/services is not a directory


My best guess at the root cause for this is that when
gnome-desktop-testing-runner schedules lots of unit tests in a
newly-opened user session, if the integration test for transient
services happens to be one of the first ones to be run, then the session
dbus-daemon will not necessarily have been started by systemd socket
activation just yet. If the test runner has a large number of CPU cores,
then that makes it more likely that the test will win the race with the
dbus-daemon, resulting in failure.


I don't experience our ppc64el hosts as extremely fast, but who knows.


I have a possible patch which I'll upload soon. Would you be able to
schedule several consecutive runs on the affected hardware to make
sure it's really fixed? 10 runs should be enough for a reasonable level
of confidence.


Sure, but anybody (with Salsa credentials) can schedule those jobs. Just 
hitting the retry button will do. Results should be fast too as they are 
scheduled with higher prio.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006233: transition: poppler

[Jeremy Bicha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: popp...@packages.debain.org
Severity: normal

I request permission to do the transition for poppler.

Poppler appears to be doing monthly releases now. To minimize
disruption and extra transitions, we have been skipping some of the
releases. Ubuntu 22.04 LTS will be using the 22.02 release so that's a
good one for us to use for a few months.

I completed the transition in Ubuntu earlier this month.

I believe we can do binNMUs for all of the affected packages.

https://release.debian.org/transitions/html/auto-poppler.html

Thank you,
Jeremy Bicha

Bug#1006232: ldap-account-manager.postinst uses a2query without requiring apache2 package

[Michael Davidsaver]

Package: ldap-account-manager
Version: 7.4-1
Severity: normal
X-Debbugs-Cc: mdavidsa...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?

Attempting to install for use with nginx instead of apache.

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

Install ldap-account-manager while preventing apache2 package from installing 
as well.

   * What was the outcome of this action?

Setting up ldap-account-manager (7.4-1) ...
/var/lib/dpkg/info/ldap-account-manager.postinst: line 89: a2query: command not 
found
/var/lib/dpkg/info/ldap-account-manager.postinst: line 89: a2enconf: command 
not found

Trying to remove then results in

Removing ldap-account-manager (7.4-1) ...
/var/lib/dpkg/info/ldap-account-manager.postrm: line 28: a2query: command not 
found

At which point I was happy that I tried this first in a disposable lxc 
container :)

   * What outcome did you expect instead?

Correctly detecting that apache2 isn't in use.

ldap-account-manager.postinst tests for /etc/$server/conf-available which 
mis-triggers
due to the existence of /etc/apache2/conf-available/javascript-common.conf

Maybe better to test for the existence of '/usr/sbin/a2query', 
'/usr/sbin/apachectl',
or another file from the apache2 package installed outside of /etc ?


*** 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)
Foreign Architectures: i386

Kernel: Linux 5.10.0-11-amd64 (SMP w/8 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 ldap-account-manager depends on:
pn  apache2 | httpd  
ii  debconf [debconf-2.0]1.5.77
ii  fonts-dejavu 2.37-2
pn  libapache2-mod-php | libapache2-mod-fcgid | php-fpm  
pn  php  
pn  php-curl 
pn  php-gd | php-imagick 
pn  php-gmp  
pn  php-json 
pn  php-ldap 
pn  php-monolog  
pn  php-phpseclib
pn  php-xml  
pn  php-zip  

Versions of packages ldap-account-manager recommends:
pn  php-opcache  

Versions of packages ldap-account-manager suggests:
pn  ldap-account-manager-lamdaemon  
pn  ldap-server 
ii  perl5.32.1-4+deb11u2
pn  php-mcrypt  

Bug#692765: Weird table rendering in translated page

[Helge Kreutzmann]

Hello Colin,
On Sun, Jan 30, 2022 at 04:14:18PM +, Colin Watson wrote:

> That changes the amount of space inserted after end-of-sentence
> characters, which by default are '!', '?', and '.'.  As it happens,
> those are exactly the characters after which the table rendering has
> gone wrong above.

I applied it to all translations of ascii.7 present in manpages-l10n
as of today. 

Unfortunately we just had a new version yesterday, so it will arrive
in unstable/backports only in ~ 3 months.

> I've reassigned the primary bug here to src:manpages-l10n (covering
> manpages-fr, manpages-de, etc.) since this typically goes wrong in
> translation, but I think it would be a good idea to do the same thing in
> the base ascii(7) page in manpages as a defensive measure against
> translators not being aware of this subtle detail, so I've reassigned a
> clone of this bug to manpages as well.
> 
> --- ascii.7.orig
> +++ ascii.7
> @@ -141,10 +141,10 @@
>  0:   0 @ P \` p 0:(  2  <  F  P  Z  d   n   x
>  1: ! 1 A Q a q 1:)  3  =  G  Q  [  e   o   y
>  2: " 2 B R b r 2:*  4  >  H  R  \e  f   p   z
> -3: # 3 C S c s 3: !  +  5  ?  I  S  ]  g   q   {
> +3: # 3 C S c s 3: !\&  +  5  ?\&  I  S  ]  g   q   {
>  4: $ 4 D T d t 4: "  ,  6  @  J  T  \(ha  h   r   |
>  5: % 5 E U e u 5: #  \-  7  A  K  U  _  i   s   }
> -6: & 6 F V f v 6: $  .  8  B  L  V  \`  j   t   \(ti
> +6: & 6 F V f v 6: $  .\&  8  B  L  V  \`  j   t   \(ti
>  7: \(aq 7 G W g w 7: %  /  9  C  M  W  a  k   u  DEL
>  8: ( 8 H X h x 8: &  0  :  D  N  X  b  l   v
>  9: ) 9 I Y i y 9: \(aq  1  ;  E  O  Y  c  m   w

That is great, because then future languages will get it as well. I
also added a FIXME to report it to upstream. In German we say "double
holds better".

> Let me know if you have any other questions about this, and I'll try to
> reply in slightly less than nine years this time.

I do have one: Why don't you need it for line 1 as well? There is an
! also.

Greeting

   Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1006231: puppet: FTBFS with ruby 3.0: fileutils.rb:865:in `install': wrong number of arguments (given 3, expected 2) (ArgumentError)

[Andreas Beckmann]

Source: puppet
Version: 6.16.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

puppet/experimental recently started to FTBFS. This seems to have been
cuased by a recent change to a build dependency as a previous build
attempt on Jan 12 was still successful.

 fakeroot debian/rules binary
dh /usr/share/openstack-pkg-tools/pkgos.make
dh: error: Unknown sequence /usr/share/openstack-pkg-tools/pkgos.make (choose 
from: binary binary-arch binary-indep build build-arch build-indep clean 
install install-arch install-indep)
dh binary
   dh_testroot
   dh_prep
   dh_installdirs
   debian/rules override_dh_auto_install
make[1]: Entering directory '/build/puppet-6.16.0'
dh /usr/share/openstack-pkg-tools/pkgos.make
dh: error: Unknown sequence /usr/share/openstack-pkg-tools/pkgos.make (choose 
from: binary binary-arch binary-indep build build-arch build-indep clean 
install install-arch install-indep)
./install.rb --destdir=debian/tmp \
--configdir=/etc/puppet \
--codedir=/etc/puppet/code \
--logdir=/var/log/puppet \
--localedir=/usr/share/puppet/locale \
--vardir=/var/cache/puppet \
--sitelibdir=/usr/lib/ruby/vendor_ruby \
--ruby=/usr/bin/ruby
/usr/lib/ruby/3.0.0/fileutils.rb:865:in `install': wrong number of arguments 
(given 3, expected 2) (ArgumentError)
from ./install.rb:63:in `block in do_configs'
from ./install.rb:61:in `each'
from ./install.rb:61:in `do_configs'
from ./install.rb:493:in `block in '
from /usr/lib/ruby/3.0.0/fileutils.rb:139:in `chdir'
from /usr/lib/ruby/3.0.0/fileutils.rb:139:in `cd'
from ./install.rb:475:in `'
make[1]: *** [debian/rules:10: override_dh_auto_install] Error 1
make[1]: Leaving directory '/build/puppet-6.16.0'
make: *** [debian/rules:7: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit 
status 2

Comparing the build logs shows the switch from ruby 2.7 to 3.0 as a possible 
cause.
Please also fix the "Unknown sequence 
/usr/share/openstack-pkg-tools/pkgos.make" noise.


Andreas


puppet_6.16.0-1.log.gz
Description: application/gzip

Bug#804329: Logging out not always sufficient

[Richard Z.]

Hi,

just tried it on Bullseye and two observations:

* the selection dialog "Should non-superuser be able to capture
  packets?" should make it clearer *how* to answer the choice. I assume
  this is by pressing "y"/"n" and "enter" ? Something like that worked
  for me but the makeup of the dialog is more suggestive of a dialog box
  which usually have other methods of selection.

* in my case not even logging out made non-root capture work but it
  worked after reboot. This may be a peculiarity of Xfce or something
  else but should be mentioned in the README. Or indeed.. if there is a
  known workaround to make it work without reboot/logout it would be
  very nice to mention it there.

* how about asking for a list of users to add to the wireshark group
  during configuration?

Regards
Richard

Bug#1003773: aerc: please update Homepage (and probably debian/copyright URIs as well)

[Nilesh Patra]

Hi Jonas,

On Sat, 15 Jan 2022 17:28:59 +0100 Jonas Smedegaard  wrote:
> Homepage is listed as https://aerc-mail.org which points to
> https://git.sr.ht/~sircmpwn/aerc for its source and currently lists
> 0.5.2 as its latest release.

That link points to the correct source code URL link i.e. 
https://git.sr.ht/~rjarry/aerc
Maybe this was updated there after you filed this bug report.

But in any case, this bug report is no longer valid. If you agree,
please close this.

Regards,
Nilesh


signature.asc
Description: PGP signature

Bug#1006190: New upstream release

[MichaIng]

Dear Georges,

many thanks for your quick action. I'll test the new package once it is 
available in unstable.


Best regards,

Micha

Bug#1005653: (no subject)

[ZenWalker]

maybe
https://github.com/Nheko-Reborn/nheko/commit/b439e1fa41b26db5f1d0d16bd1da664338b435e7
fixes the bug, which is included in version 0.9.1

There is plans to package nheko 0.9.1 ?

Bug#1006164: Acknowledgement (tidy: keeps on adding new line before inline CDATA)

[Martin-Éric Racine]

Reported upstream at https://github.com/htacg/tidy-html5/issues/1026

Bug#1006230: qt6-base-dev: Undefined target Qt::CorePrivate.

[Hefee]

Package: qt6-base-dev
Version: 6.2.2+dfsg-5
Severity: important
X-Debbugs-Cc: he...@debian.org

If I just use in CMake "find_package(Qt6 COMPONENTS Core REQUIRED)" I
end up with the bug:
"Targets not yet defined: Qt::CorePrivate"

Also if I add qt6-base-private-dev explicitly to the Build-Depends list,
I still get the same error.
That's why it seems like a bug inside qt6-base.

See the build of qtkeychain:
https://salsa.debian.org/owncloud-team/qtkeychain/-/jobs/2496539#L1939
https://salsa.debian.org/owncloud-team/qtkeychain/-/pipelines/351397

and the correspondig CMakeLists.txt:
https://salsa.debian.org/owncloud-team/qtkeychain/-/blob/master/CMakeLists.txt

and relevant Debian files:
https://salsa.debian.org/owncloud-team/qtkeychain/-/blob/work/hefee/qt6/debian/control
https://salsa.debian.org/owncloud-team/qtkeychain/-/blob/work/hefee/qt6/debian/control

Regards,

hefee


-- 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)
Foreign Architectures: i386

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

Versions of packages qt6-base-dev depends on:
ii  libqt6concurrent6 6.2.2+dfsg-5
ii  libqt6core6   6.2.2+dfsg-5
ii  libqt6dbus6   6.2.2+dfsg-5
ii  libqt6gui66.2.2+dfsg-5
ii  libqt6network66.2.2+dfsg-5
ii  libqt6openglwidgets6  6.2.2+dfsg-5
ii  libqt6printsupport6   6.2.2+dfsg-5
ii  libqt6sql66.2.2+dfsg-5
ii  libqt6test6   6.2.2+dfsg-5
ii  libqt6widgets66.2.2+dfsg-5
ii  libqt6xml66.2.2+dfsg-5
ii  qmake66.2.2+dfsg-5
ii  qt6-base-dev-tools6.2.2+dfsg-5
ii  qt6-qpa-plugins   6.2.2+dfsg-5

Versions of packages qt6-base-dev recommends:
ii  libqt6opengl6-dev  6.2.2+dfsg-5

qt6-base-dev suggests no packages.

-- no debconf information

Bug#1006229: RM: python-oauth -- RoQA; obsolete, replaced by python-oauthlib

[Jeremy Bicha]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: python-oa...@packages.debian.org

Please remove python-oauth. It has been abandoned upstream; the
replacement is python-oauthlib. See the Ubuntu bug for more details:
https://launchpad.net/bugs/1118815

Thank you,
Jeremy Bicha

Bug#1006227: please resolve lepton-eda s390x out of date in testing

[Bdale Garbee]

Package: ftp.debian.org

Hi.  In response to bug 1006172, it appears the best fix for now would
be to arrange for the lepton-eda 1.9.16-3 binaries for s390x to be
removed from the archive.  I'd be fine with either the s390x binaries
only being removed, or the complete removal of 1.9.16-3 from the
archive.

The goal is to allow 1.9.17-2 to promote to testing without waiting for
the s390x porters to figure out what's wrong in the guile port that's
triggering test suite errors in a package that's unlikely to ever be
used on s390x in any case.

Regards,

Bdale


signature.asc
Description: PGP signature

Bug#1006190: New upstream release

[Georges Khaznadar]

Dear MichaIng, thank you for your bug report!

Dear Steven, please can you confirm that the repository
https://gitlab.com/stevenshiau/clonezilla is actually the place where
you are maintaining latest sources of your work? I missed this
information.

I am preparing a Debian package to be uploaded shortly.

Best regards,   Georges.

MichaIng a écrit :
> 
> Package: clonezilla
> Version: 3.35.2-3
> 
> Dear maintainer,
> 
> the last Clonezilla upstream release has been applied to Debian a long time
> ago. In the meantime there have been many releases, latest at time of
> writing bring v5.0.3:
> https://gitlab.com/stevenshiau/clonezilla/-/blob/master/clonezilla.spec
> 
> It provides many new features, including one I personally require: support
> for loop devices.
> 
> Would it be possible to provide a new Debian build via unstable suite?
> 
> Best regards,
> 
> Micha

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1006226: libthrust: Version conflict with libcub

[Thomas Viehmann]

Package: libthrust
Severity: important

Hello.

Thank you for maintaining thrust along with the cuda stack in Debian!
While compiling PyTorch on Debian, I noticed that the version of cub is 
0.1.15 and that of thrust is 0.1.14.
My impression is that libthrust needs the locked version of libcub, i.e. 
libthrust 0.1.14 needs libcub=0.1.14, but the dependency currently is >=.


I upgraded libthrust to 0.1.15 locally using uupdate and it seemed to 
work (but I avoided to get into a mismatch with 0.1.16 which is out now 
and I didn't try updating both to 0.1.16).


Best regards

Thomas

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Petra Rübe-Pugliese]

Hello Salvatore,

Am Mo., 21. Feb. 2022, um 14:56 +0100 schrieb Salvatore Bonaccorso 
:
> Control: tags -1 + moreinfo
[...]
> Are you booting in quite mode?

I do not think so.
I usually get _heaps_ of output scrolling away on the screen,
but in this case absolutely _nothing_ happens after the
first line of output.

> if yes, can you remote if from the kernel command line and see
> if you get more information on the screen?

How would that be done?
 
> Got off-bug a report from someone with similar Hardware with similar
> symptoms.

I'm glad to hear that it's not just me ...
> 
> >From the failed boot, can you extract the kernel logs produced?

I did the following:

 -> Start the notebook with the "bad" kernel at about 16:56 today.
(The notebook had not run before today.)
 -> Press the button at around 16:58 to stop it.
 -> Restart the "good" kernel at 16:59:xx

Here is the corresponding passage from /var/log/kern.log :

Feb 20 10:24:42 localhost kernel: [ 2220.772792] sd 2:0:0:0: [sdb] Attached 
SCSI removable disk
Feb 20 10:24:43 localhost kernel: [ 2221.424423] sd 2:0:0:0: [sdb] 15753215 
512-byte logical blocks: (8.07 GB/7.51 GiB)
Feb 20 10:24:43 localhost kernel: [ 2221.425660] sdb: detected capacity change 
from 0 to 15753215
Feb 20 10:24:43 localhost kernel: [ 2221.426455]  sdb: sdb1
Feb 20 10:24:54 localhost kernel: [ 2232.992583] EXT4-fs (sdb1): mounting ext2 
file system using the ext4 subsystem
Feb 20 10:24:54 localhost kernel: [ 2233.011371] EXT4-fs (sdb1): mounted 
filesystem without journal. Opts: (null). Quota mode: none.
Feb 20 10:29:11 localhost kernel: [ 2489.270389] usb 1-4: USB disconnect, 
device number 8
Feb 21 17:00:53 localhost kernel: [0.00] Linux version 5.15.0-3-686 
(debian-ker...@lists.debian.org) (gcc-11 (Debian 11.2.0-14) 11.2.0, GNU ld (GNU 
Binutils for Debian) 2.37.90.20220123) #1 SMP Debian 5.15.15-2 (2022-01-30)
Feb 21 17:00:53 localhost kernel: [0.00] x86/fpu: x87 FPU will use 
FXSAVE
Feb 21 17:00:53 localhost kernel: [0.00] signal: max sigframe size: 1440
Feb 21 17:00:53 localhost kernel: [0.00] BIOS-provided physical RAM map:
Feb 21 17:00:53 localhost kernel: [0.00] BIOS-e820: [mem 
0x-0x0009efff] usable
Feb 21 17:00:53 localhost kernel: [0.00] BIOS-e820: [mem 
0x0009f000-0x0009] reserved
Feb 21 17:00:53 localhost kernel: [0.00] BIOS-e820: [mem 
0x000d2000-0x000d3fff] reserved
Feb 21 17:00:53 localhost kernel: [0.00] BIOS-e820: [mem 
0x000dc000-0x000f] reserved
Feb 21 17:00:53 localhost kernel: [0.00] BIOS-e820: [mem 
0x0010-0x1ff5] usable
Feb 21 17:00:53 localhost kernel: [0.00] BIOS-e820: [mem 
0x1ff6-0x1ff76fff] ACPI data
Feb 21 17:00:53 localhost kernel: [0.00] BIOS-e820: [mem 
0x1ff77000-0x1ff78fff] ACPI NVS
Feb 21 17:00:53 localhost kernel: [0.00] BIOS-e820: [mem 
0x1ff8-0x1fff] reserved
Feb 21 17:00:53 localhost kernel: [0.00] BIOS-e820: [mem 
0xff80-0x] reserved
Feb 21 17:00:53 localhost kernel: [0.00] Notice: NX (Execute Disable) 
protection missing in CPU!



That is:  Nothing whatever got recorded between
Feb 20 10:29:11 localhost kernel: [ 2489.270389] usb 1-4: USB disconnect, 
device number 8
(last activity yesterday)
and
Feb 21 17:00:53 localhost kernel: [0.00] Linux version 5.15.0-3-686 
(debian-ker...@lists.debian.org) (
(start of the "good" kernel today).

I'm afraid that is not much in the way of "more information" ...  :-\


Best regards,
Petra

Bug#1006219: new expat causes regressions in the python autopkg tests

[GCS]

Control: tags -1 +confirmed

Hi Matthias,

On Mon, Feb 21, 2022 at 2:57 PM Matthias Klose  wrote:
> The new expat causes regressions in the python autopkg tests. I also see there
> is a new upstream 2.4.6. Didn't check that yet.
 Basically 2.4.5-2 and 2.4.6 should be identical. I can package the
latter for you if you want.
Will contact upstream about this and see what he finds.

Regards,
Laszlo/GCS

Bug#1006168: screenruler fails to start

[Georges Khaznadar]

Dear Andreas, thank you for the bug report.

I changed the dependencies of screenruler, which should provide the main
fix.

However, I cannot reproduce the bug which you reported, about missing
graduations. Those graduations are created by iterations of the method
line_to(), in an instance of Cairo context. Please can you tell me which
versions of ruby-cairo and ruby-cairao-gobject are in use on your
computer?

Best regards,   Georges.

Andreas Schmidt a écrit :
> Package: screenruler
> Version: 1.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I noticed that screenruler didn't start when I used the menu shortcut. Trying
> to start it via the shell, I've got this :
> 
> $ screenruler
> Loading libraries...
> :85:in
> `require': cannot load such file -- gtk3 (LoadError)
> from
> :85:in
> `require'
> from ./screenruler.rb:52:in `'
> 
> I've then installed ruby-gtk3 (version 3.4.3-1+b3), which also pulled in ruby-
> gdk3 (3.4.3-1). Then I've started screenruler again:
> 
> $ screenruler
> Loading libraries...
> Creating windows...
> Reading settings...
> Presenting ruler...
> 
> This works kind of: there's no error, there is a ruler, and right-clicking the
> ruler brings up the menu. However, the screenruler itself is just a single
> white bar, displaying no scale or anything else.
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages screenruler depends on:
> ii  libcanberra-gtk3-module  0.30-8
> ii  ruby 1:3.0
> ii  ruby-cairo   1.16.6-1+b2
> ii  ruby-cairo-gobject   3.4.3-1+b3
> ii  ruby-gettext 3.3.3-2
> ii  ruby-gtk23.4.3-1+b3
> 
> screenruler recommends no packages.
> 
> screenruler suggests no packages.
> 
> -- no debconf information

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1006225: shadow: manpages groups and id - replacement of "concurrent group sets"

[Markus Hiereth]

Source: shadow
Version: 4.8.1
Severity: minor

Dear Serge, 

attached the edited xml files for groups.1 and id.1 where "concurrent 
group set" occured. These occurences were replaced with "supplementary 
groups" and a reference to initgroups(3).

No other changes were made

- as real and effective IDs are only mentioned, but the shadow 
implementation of groups and id (which have no option --real) and

- as there are doubts whether these binaries/manpages will reach users 
at all. They are not within the Debian distribution.

Best regards
Markus

(References: email correspondence 2022-02-18 - 2022-02-21)
--- shadow-4.8.1/man/id.1.xml   2019-07-23 17:26:08.0 +0200
+++ shadow-4.8.1_mh/man/id.1.xml2022-02-21 16:32:48.691912849 +0100
@@ -79,8 +79,9 @@
   have a corresponding entry in /etc/passwd or
   /etc/group, the value will be displayed without
   the corresponding name. The optional -a flag will
-  display the group set on systems which support multiple concurrent
-  group membership.
+  display the group set on systems which support supplementary groups
+  (see initgroups
+  3).
 
   
 
@@ -114,6 +115,9 @@
   
getuid2
   
+  
+   initgroups3
+  
 
   
 


http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [

]>

  
  

  Julianne Frances
  Haugh
  Creation, 1991


  Thomas
  Kłoczko
  kloc...@pld.org.pl
  shadow-utils maintainer, 2000 - 2007


  Nicolas
  François
  nicolas.franc...@centraliens.net
  shadow-utils maintainer, 2007 - now

  
  
id
1
User Commands
shadow-utils
_UTILS_VERSION;
  
  
id
display current user and group ID names
  

  

  id-a 

  

  
DESCRIPTION

  The id command displays the current real and
  effective user and group ID names or values. If the value does not
  have a corresponding entry in /etc/passwd or
  /etc/group, the value will be displayed without
  the corresponding name. The optional -a flag will
  display the group set on systems which support supplementary groups
  (see initgroups
  3).

  

  
FILES

  
/etc/group

  Group account information.

  
  
/etc/passwd

  User account information.

  

  

  
SEE ALSO

  
getgid2
  ,
  
getgroups2
  ,
  
getuid2
  
  
initgroups3
  

  

--- shadow-4.8.1/man/groups.1.xml   2019-07-23 17:26:08.0 +0200
+++ shadow-4.8.1_mh/man/groups.1.xml2022-02-21 14:53:33.260598583 +0100
@@ -89,7 +89,9 @@
   
 NOTE
 
-  Systems which do not support concurrent group sets will have the
+  Systems which do not support supplementary groups (see 
+   initgroups3
+  ) will have the
   information from /etc/group reported. The user
   must use newgrp or sg to change
   his current real and effective group ID.


http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [

]>

  
  

  Julianne Frances
  Haugh
  Creation, 1991


  Thomas
  Kłoczko
  kloc...@pld.org.pl
  shadow-utils maintainer, 2000 - 2007


  Nicolas
  François
  nicolas.franc...@centraliens.net
  shadow-utils maintainer, 2007 - now

  
  
groups
1
User Commands
shadow-utils
_UTILS_VERSION;
  
  
groups
display current group names
  

  

  groups
  
user
  

  

  
DESCRIPTION

  The groups command displays the current group names
  or ID values. If the value does not have a corresponding entry in
  /etc/group, the value will be displayed as the
  numerical group value. The optional user parameter will display the groups for the
  named user.

  

  
NOTE

  Systems which do not support supplementary groups (see 
initgroups3
  ) will have the
  information from /etc/group reported. The user
  must use newgrp or sg to change
  his current real and effective group ID.

  

  
FILES

  
/etc/group

  Group account information.

  

  

  
SEE ALSO

  
newgrp1
  ,
  
getgid2
  ,
  
getgroups2
  ,
  
getuid2
  .

  

Bug#1006223: "stack smashing detected" error in ld while linking with Map-file specified

[Max A. Dednev]

Package version (2.26.20160125+Atmel3.6.2-3) patch level was incremented 
by me while building patched version.
So, the original package version with bug reported is 
2.26.20160125+Atmel3.6.2-2


--
Max A. Dednev

Bug#1006224: oping should failover correctly to IPv4

[Antoine Beaupre]

Package: oping
Version: 1.10.0-4+b1
Severity: normal
File: /usr/bin/noping
Tags: ipv6
X-Debbugs-Cc: lavam...@debian.org

On some IPv4-only networks, DNS results sometimes include 
records. Most programs correctly handle this situation and fall back
to the A record. For example, if you curl `www.torproject.org`, it
uses the A or  record depending on whether you are on a IPv6 or
IPv4 network:

anarcat@curie:~(main)$ curl -s -v -I www.torproject.org 2>&1 | head -1
*   Trying 116.202.120.165:80...

anarcat@marcos:~$ curl -s -v -I www.torproject.org 2>&1 | head -1
*   Trying 2604:8800:5000:82:466:38ff:fecb:d46e:80...

marcos is on an IPv6 network, curie isn't.

Web browsers also handle this gracefully.

oping (and, obviously noping) doesn't handle this correctly:

anarcat@curie:~(main)$ oping -c 1 www.torproject.org
PING www.torproject.org (2a01:4f8:fff0:4f:266:37ff:feae:3bbc) 56 bytes of data.
echo reply from www.torproject.org (2a01:4f8:fff0:4f:266:37ff:feae:3bbc): 
icmp_seq=1 timeout

--- www.torproject.org ping statistics ---
1 packets transmitted, 0 received, 100,00% packet loss, time 0,0ms

For what it's worth, iputils-ping doesn't have the same bug, but
that's only because it defaults to IPv4 instead, which isn't ideal:

anarcat@marcos:~$ ping -c 1 www.torproject.org
PING www.torproject.org (38.229.82.25): 56 data bytes
64 bytes from 38.229.82.25: icmp_seq=0 ttl=57 time=29,997 ms
--- www.torproject.org ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 29,997/29,997/29,997/0,000 ms

anarcat@curie:~(main)$ ping -c 1 www.torproject.org
PING www.torproject.org (95.216.163.36) 56(84) bytes of data.
64 bytes from hetzner-hel1-03.torproject.org (95.216.163.36): icmp_seq=1 ttl=44 
time=129 ms

--- www.torproject.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 128.706/128.706/128.706/0.000 ms

... but that's a different question.

the `oping` manpage specifically advertises IPv6 support this way:

In contrast to the fping utility (URL is listed in "SEE ALSO")
oping can use both, IPv4 and IPv6 transparently and side by side.


And, for what *that's* worth, fping actually does the correct thing
here:

anarcat@marcos:~$ fping -A -c 1 www.torproject.org
2604:8800:5000:82:466:38ff:fecb:d46e : [0], 64 bytes, 34.9 ms (34.9 avg, 0% 
loss)

2604:8800:5000:82:466:38ff:fecb:d46e : xmt/rcv/%loss = 1/1/0%, min/avg/max = 
34.9/34.9/34.9

anarcat@curie:~(main)$ fping -A -c 1 www.torproject.org
116.202.120.165 : [0], 64 bytes, 112 ms (112 avg, 0% loss)

116.202.120.165 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 112/112/112

(It should also be noted here that fping *can* use both IPv4 and IPv6
transparently, see the `-m` option, so the above quote is actually
incorrect.)

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

Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 oping depends on:
ii  libc6 2.31-13+deb11u2
ii  libncursesw6  6.2+20201114-2
ii  liboping0 1.10.0-4+b1
ii  libtinfo6 6.2+20201114-2

oping recommends no packages.

oping suggests no packages.

-- no debconf information

Bug#1006223: binutils-avr: "stack smashing detected" error in ld while linking with Map-file specified

[Max A. Dednev]

Package: binutils-avr
Version: 2.26.20160125+Atmel3.6.2-3
Severity: important
Tags: patch
X-Debbugs-Cc: mded...@yandex.ru

Dear Maintainer,

binutils-avr ld crashes with error "*** stack smashing detected ***:
terminated" if map-file generation is enabled with -Map=mapfile.map command
line option.

Example compilation log:

--- LOG start ---
avr-gcc (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiling: main.c
avr-gcc -c -mmcu=atmega64 -I. -gstabs -DF_CPU=SYSTEM_CLOCK  -Os -Wall -Wstrict-
prototypes -Wa,-adhlns=main.lst  -std=gnu99  main.c -o main.o

Linking: atmega64.elf
avr-gcc -mmcu=atmega64 -I. -gstabs -DF_CPU=SYSTEM_CLOCK  -Os -Wall -Wstrict-
prototypes -Wa,-adhlns=main.o  -std=gnu99  main.o  --output atmega64.elf
-Wl,-Map=atmega64.map,--cref-lm
collect2: fatal error: ld terminated with signal 6 [Аварийный останов]
compilation terminated.
*** stack smashing detected ***: terminated
make: *** [makefile:391: atmega64.elf] Ошибка 1
--- LOG end ---

I've found, that stack overflow is in ldmain.c add_archive_element() function
at sprintf() call. Proposed patch is:

Index: binutils-avr-2.26.20160125+Atmel3.6.2/binutils/ld/ldmain.c
===
--- binutils-avr-2.26.20160125+Atmel3.6.2.orig/binutils/ld/ldmain.c
2020-01-12 11:11:48.0 +0300
+++ binutils-avr-2.26.20160125+Atmel3.6.2/binutils/ld/ldmain.c  2022-02-21
17:36:14.889230109 +0300
@@ -846,11 +846,8 @@

   if (! header_printed)
{
- char buf[100];
-
- sprintf (buf, _("Archive member included "
- "to satisfy reference by file (symbol)\n\n"));
- minfo ("%s", buf);
+ minfo (_("Archive member included "
+  "to satisfy reference by file (symbol)\n\n"));
  header_printed = TRUE;
}


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

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

Versions of packages binutils-avr depends on:
ii  libc6   2.31-13+deb11u2
ii  zlib1g  1:1.2.11.dfsg-2

binutils-avr recommends no packages.

Versions of packages binutils-avr suggests:
ii  binutils  2.35.2-2
Index: binutils-avr-2.26.20160125+Atmel3.6.2/binutils/ld/ldmain.c
===
--- binutils-avr-2.26.20160125+Atmel3.6.2.orig/binutils/ld/ldmain.c 
2020-01-12 11:11:48.0 +0300
+++ binutils-avr-2.26.20160125+Atmel3.6.2/binutils/ld/ldmain.c  2022-02-21 
17:36:14.889230109 +0300
@@ -846,11 +846,8 @@
 
   if (! header_printed)
{
- char buf[100];
-
- sprintf (buf, _("Archive member included "
- "to satisfy reference by file (symbol)\n\n"));
- minfo ("%s", buf);
+ minfo (_("Archive member included "
+  "to satisfy reference by file (symbol)\n\n"));
  header_printed = TRUE;
}
 

Bug#1006198: docbook: Packaging license incompatible with the upstream

[Daniel Leidert]

Am Montag, dem 21.02.2022 um 10:57 -0300 schrieb Eriberto Mota:
> 

[..]
> Considering that docbook is orphan plus your reply (or your very
> aggressive reply),

Maybe you should re-consider your approach and reflect on the actions you were
announcing. I cannot even believe that a DD threatens to relicense without
proper permissions by the authors. And you haven't layed out what you consider
to be the problem, which makes it impossible to even come up with a sensible
solution.

Also: How should the Docbook license, which clearly restricts itself to the
"[..] DocBook XML DTD and its accompanying documentation [..]", cover the
packaging files?

JFTR: Most of the original Debian package maintainers cannot be reached
anymore. Your chances to get the required permissions are slim.

> I am closing this bug.

There is IMHO no "hampering" condition. The patches that are part of the
package will not be accepted into upstream for the reasons I have layed out
earlier. The DocBook project is not changing their releases, not even for bug
fixes. Those have always gone into the next release or the RC for the next
release. Thus the existing patches pose no problem at all IMO.

New patches also pose no problem. The patch author has the authority to provide
their contribution to the DocBook project under the DocBook license and also
ship it with the docbook-Debian package if necessary.

And then again: We always had the intention to not deviate from upstream - the
Debian packages should always behave like the upstream releases. Thus we were
always working closely with upstream (Debian even had a chair in the OASIS,
IIRC). And I fail to see good reasons. why we would want to change that, as
well.

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

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


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

Bug#1006221: RM: probabel [arm64 armel armhf mips64el mipsel ppc64el s390x alpha hppa ia64 powerpc ppc64 riscv64 sparc64] -- ROM; Build issues in several architectures

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi ftpmasters,

as discussed with upstream it is better to exclude several archictectures
for probabel which I did now.  Please remove the unsupported architectures
from the Debian repository.

Kind regards
Andreas.

Bug#1006217: Problem indentified

[karsten]

The reason for this bug is an entry found in 
/etc/apparmor.d/tunables/home.d/site.local
Here is an entry @{HOMEDIRS}=/srv/home/ that was not set manually.
After deleting this entry aa-genprof is working again.

This report can be closed.

Bug#1004556: fix doesn't seem to be sufficient

[Julien Bigot]

Dear maintainer,

I've tried the same test with mpich 4.0-2 and still see the same behaviour. 
The issue doesn't seem fixed on my side. Is there anything else I should wait 
for beyond mpich/libmpich-dev?

Best,
Julien

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

Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?

[Alex Deucher]

On Mon, Feb 21, 2022 at 3:29 AM Eric Valette  wrote:
>
> On 20/02/2022 16:48, Dominique Dumont wrote:
> > On Monday, 14 February 2022 22:52:27 CET Alex Deucher wrote:
> >> Does the system actually suspend?
> >
> > Not really. The screens looks like it's going to suspend, but it does come
> > back after 10s or so. The light mounted in the middle of the power button 
> > does
> > not switch off.
>
>
> As I have a very similar problem and also commented on the original
> debian bug report
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005005), I will add
> some information here on another amd only laptop (renoir AMD Ryzen 7
> 4800H with Radeon Graphics + Radeon RX 5500/5500M / Pro 5500M).
>
> For me the suspend works once, but after the first resume (I do know
> know if it is in the suspend path or the resume path I see a RIP in the
> dmesg (see aditional info in debian bug))  and later suspend do not
> work: It only go to the kde login screen.
>
> I was unable due to network connectivity to do a full bisect but tested
> with the patch I had on my laptop:
>
> 5.10.101 works, 5.10 from debian works
> 5.11 works
> 5.12 works
> 5.13 suspend works but when resuming the PC is dead I have to reboot
> 5.14 seems to work but looking at dmesg it is full of RIP messages at
> various places.
> 5.15.24 is a described 5.15 from debian is behaving identically
> 5.16 from debian is behaving identically.
>
> >> Is this system S0i3 or regular S3?
>
> For me it is real S3.
>
> The proposed patch is intended for INTEl + intel gpu + amdgpu but I have
> dual amd GPU.

It doesn't really matter what the platform is, it could still
potentially help on your system, it depends on the bios implementation
for your platform and how it handles suspend. You can try the patch,
but I don't think you are hitting the same issue.  I bisect would be
helpful in your case.

Alex

Bug#1006220: pytest & pyflake broken in unstable

[Matthias Klose]

Package: src:python-flake8
Version: 4.0.1-1
Severity: serious
Tags: sid bookworm

Seen in the last test rebuild, e.g.:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006032

if there are incompatible versions of flake and pytest, it should be expressed
by Dependencies/Breaks in these packages.

Bug#997972: haskell-pandoc-citeproc has been deprecated upstream

[Jonas Smedegaard]

Quoting Sean Whitton (2022-02-15 07:16:04)
> On Wed 27 Oct 2021 at 07:13pm -04, Louis-Philippe Véronneau wrote:
> 
> > Package: src:haskell-pandoc-citeproc
> > Version: 2.9.2.1-1+b2
> > Severity: important
> >
> > Dear maintainers,
> >
> > This project has been deprecated upstream since October 9th 2020 
> > [1]. There is a new project called "citeproc" by the same author 
> > that replaces it [2].
> >
> > Pandoc version 2.11 (not in Debian yet) now supports the new 
> > citeproc invocation ("--citeproc" instead of "--filter 
> > pandoc-citeproc") and I believe requires this new binary.
> >
> > Does anyone plan to package the new "citeproc"?
> 
> I guess that this will happen when pandoc itself gets updated.

Seems reasonable to me to consider packaging future reverse dependencies 
before¹ needed.

Related to this issue, I have gone through the pending releases of 
pandoc and gathered when new reverse dependencies become needed: 
https://salsa.debian.org/haskell-team/pandoc/-/blob/master/debian/TODO


 - Jonas


¹ I am well aware of Haskell team packaging style of doing everything at 
once, but personally I do not share that mindset, and I doubt it is 
helpful for ftpmasters to release a huge pile at once (but with their 
current level of transparency we can unfortunately only speculate about 
their needs).


 - 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#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi

On Sat, Feb 19, 2022 at 10:04:14PM +0100, Petra R.-P. wrote:
> Package: src:linux
> Version: 5.16.7-2
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> This new kernel version does not boot on two fairly similar
> old IBM T41 Thinkpads.
> 
> What reproducibly happens is as follows:
> 
> After the lines
> 
>Loading Linux 5.16.0-1-686 ...
>Loading initial ramdisk ...
> 
> the screen gets flushed, and I see:
>
>[  4.xx] ata1.00: Read log 0x00 page 0x00 failed  Emask 0x1
>
> 
> The "xx" vary for every try.
> 
> Then nothing else happens.
> Ctrl-Alt-Del has no effect.
> I have to reset the computer by pressing the button.
> 
> On an old PC running the same kernel the same message "ata1.00: Read log ..."
> appears, but then the boot process continues normally.
> 
> linux-image-5.15.0-3-686, which I am using to write this
> message, runs fine.

Are you booting in quite mode? if yes, can you remote if from the
kernel command line and see if you get more information on the screen?

Got off-bug a report from someone with similar Hardware with similar
symptoms.

>From the failed boot, can you extract the kernel logs produced?

Regards,
Salvatore

Bug#1006214: [Pkg-javascript-devel] Bug#1006205: node-md5-hex: ships files already provided by node-blueimp-md5

[Jonas Smedegaard]

Quoting Andreas Beckmann (2022-02-21 13:55:20)
> node-blueimp-md5 was only recently uploaded to the archive. Therefore 
> node-md5-hex needs to stop bundling it and use the separately packaged 
> node-blueimp-md5 instead.
> 
> node-blueimp-md5 needs Breaks+Replaces against node-md5-hex versions 
> that bundled node-blueimp-md5 content. (The version (<< 
> 3.0.1+~2.19.0-2~) is only a guess.)

Makes sense.

For the record, despite this bug being release-critical, my plan is to 
do exactly nothing about it, since I expect to be able to close it (with 
zero changes to node-blueimp-md5) about a week from now when I expect 
node-md5-hex to no longer provide blueimp-md5 in any supported branches 
of Debian.

 - 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#1006219: new expat causes regressions in the python autopkg tests

[Matthias Klose]

Package: src:expat
Version: 2.4.5-2
Severity: serious
Tags: sid bookworm

The new expat causes regressions in the python autopkg tests. I also see there
is a new upstream 2.4.6. Didn't check that yet.

See https://tracker.debian.org/pkg/expat

Bug#1006218: csound-plugins: missing Breaks+Replaces: libcsound64-6.0 (<< 1:6.17)

[Andreas Beckmann]

Package: csound-plugins
Version: 1.0.2~dfsg1-1~exp1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
This error may also be triggered by having a predecessor package from
'sid' installed while installing the package from 'experimental'.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../csound-plugins_1.0.2~dfsg1-1~exp1_amd64.deb ...
  Unpacking csound-plugins (1.0.2~dfsg1-1~exp1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/csound-plugins_1.0.2~dfsg1-1~exp1_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/x86_64-linux-gnu/csound/plugins64-6.0/libchua.so', which is also in 
package libcsound64-6.0:amd64 1:6.16.2~dfsg-1+b1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/csound-plugins_1.0.2~dfsg1-1~exp1_amd64.deb


cheers,

Andreas

Bug#1006217: aa-genprof does not find or record any event

[karsten]

Package: apparmor-utils
X-Debbugs-Cc: deb...@decotrain.de
Version: 2.13.6-10
Severity: important

Hello,

today i tried to create a profile for the opera browser.
So i started as root (german version):

 snip
# aa-genprof /usr/bin/opera
Aktualisiertes Profil für /usr/lib/x86_64-linux-gnu/opera/opera wird 
geschrieben.
/usr/lib/x86_64-linux-gnu/opera/opera wird in den Complain-Modus versetzt.

Bevor Sie beginnen, möchten Sie vielleicht prüfen,
ob bereits ein Profil für das Programm besteht,
das Sie einschränken möchten. Weitere Informationen
können Sie auf der folgenden Wiki-Seite erhalten:
https://gitlab.com/apparmor/apparmor/wikis/Profiles

Profilerstellung: /usr/lib/x86_64-linux-gnu/opera/opera

Starten Sie die Anwendung, für die ein Profil erstellt werden soll, in
einem anderen Fenster, und führen Sie die Funktionalität jetzt aus.

Nach Abschluss dieses Vorgangs bitte unten »Durchsuchen« wählen,
um in den Systemprotokollen nach AppArmor-Ereignissen zu suchen.

Für jedes AppArmor-Ereignis haben Sie die Gelegenheit anzugeben,
ob der Zugriff zugelassen oder verweigert werden soll.

[(S)can system log for AppArmor events] / En(d)e
 snap

I opened, used and closed Opera.
Afterwards i pressed s to scan the system log but nothing happens!
It's the same when i try this with another application.

A file /etc/apparmor.d/tunables/usr.lib.x86_64-linux-gnu.opera.opera was 
created.
/usr/bin/opera is a symbolic link to ../lib/x86_64-linux-gnu/opera/opera.

Please help to solve the problem.

Best regards
karsten


-- 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-11-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 apparmor-utils depends on:
ii  apparmor  2.13.6-10
ii  python3   3.9.2-3
ii  python3-apparmor  2.13.6-10

apparmor-utils recommends no packages.

Versions of packages apparmor-utils suggests:
pn  vim-addon-manager  

-- no debconf information

Bug#1006216: shadow: suggestions for man 8 groupadd

[Markus Hiereth]

Source: shadow
Version: 4.8.1
Severity: minor

Hi Serge,

I withdrew the changes you did not appreciate, kept the ones you did no 
comment on and used the suggustions you made.

Attached the respective xml and diff files.

Best regards
Markus



"Serge E. Hallyn"  schrieb am 20. Februar 2022 um 10:33
> On Thu, Feb 17, 2022 at 09:43:59PM +0100, Markus Hiereth wrote:
> > Hi Serge,
> > 
> > today I worked on the message catalogue for groupadd.8
> > 
> > I have no problems with understanding or translating this manual
> > page. Nevertheless there are paragraphs for which I would suggest
> > alternatives explanations. They are alreay in an attached xml-file.
> > 
> > Below, there is a diff with commments that allows you to jugde the
> > suggestions.
> > 
> > Feel free to tell me what changes are welcome.
> > 
> > Best regards
> > Markus
> > 
> > 
> > --- shadow-4.8.1/man/groupadd.8.xml 2019-07-23 17:26:08.0 +0200
> > +++ shadow-4.8.1_mh/man/groupadd.8.xml  2022-02-17 16:30:14.284465573 
> > +0100
> > 

> > Elsewhere, capital letters are used for such arguments 
> > 
> > @@ -72,10 +72,10 @@
> >  
> >groupadd
> >
> > -   options
> > +   OPTIONS
> >
> >
> > -   group
> > +   NEWGROUP
> >
> >  
> >
> > 

> > These two paragraphs come from section CAVEATS, but I think the are
> > necessary parts of the section DESCRIPTION
> > @@ -87,6 +87,15 @@
> >values from the system. The new group will be entered into the system
> >files as needed.
> >  
> > + 
> > +   Groupnames must start with a lower case letter or an underscore,
> > +   followed by lower case letters, digits, underscores, or dashes.
> > +   They can end with a dollar sign.
> > +   In regular expression terms: [a-z_][a-z0-9_-]*[$]?
> > + 
> > + 
> > +   Groupnames may only be up to _NAME_MAX_LENGTH; characters 
> > long.
> > + 
> >
> > 
> > 

> > Changed due to my different view on the attribute "unique". For me, an
> > ID that appears only once is an unique but in our context, it always
> > deals with the relation between names and IDs.
> > @@ -103,10 +112,11 @@
> > 
> >   
> > This option causes the command to simply exit with success
> > -   status if the specified group already exists. When used with
> > -   -g, and the specified GID already exists,
> > -   another (unique) GID is chosen (i.e. -g is
> > -   turned off).
> > +   status if the specified group already exists. When used
> > +   with -g and the specified GID already
> > +   exists, another one is chosen. As result, option
> > +   -g is turned off and the GID points in a
> > +   unique way to NEWGROUP.
> 
> Sorry, the new language is confusing to me.
> 
> Would simply doing 's/another (unique)/a different, unused, /' be
> clearer to you?

Yes it would.

 
> > I just replaced "this value" with "GID" which is used in the line above
> > 
> > @@ -115,8 +125,8 @@
> >   -g, 
> > --gidGID
> > 
> > 
> > - The numerical value of the group's ID. This value must be
> > -   unique, unless the -o option is used. The value
> > + The numerical value of the group's ID. 
> > GID 
> > +   must be unique, unless the -o option is used. The 
> > value
> > must be non-negative. The default is to use the smallest ID
> > value greater than or equal to GID_MIN and
> > greater than every other group.
> 
> Ok.

> > Again, "unique-and-non-unique" stuff 
> > 
> > @@ -159,7 +169,10 @@
> > 
> > 
> >   
> > -   This option permits to add a group with a non-unique GID.
> > +   permits the creation of a group with an already used
> > +   numerical ID. In turn, for this
> > +   GID, the mapping towards group
> > +   NEWGROUP will not be unique.
> 
> The more I see the substitutions, the more I think we should stick to
> using the term "unique" everywhere.

OK

> > Explanation similar to the one in useradd.8 and usermod.8. Provides more 
> > information about the implications.
> > 
> > @@ -169,11 +182,17 @@
> > 
> > 
> >   
> > -   The encrypted password, as returned by 
> > -   crypt3
> > -   . The default is to disable the password.
> > +   defines an initial password for the group account. PASSWORD is 
> > expected to
> > +be encrypted, as returned by crypt
> > +3. 
> 
> Good.

> 
> >   
> >   
> > +Without this option, the group account will be locked and
> > +with no password defined, i.e. a single exclamation mark
> > +in the respective field of ths system account file 
> > +/etc/group or 
> > /etc/gshadow.
> > +  
> > + 
> > Note: This option is not
> > recommended because the password (or encrypted password) will
> > be visible by users listing the 

Bug#995189: RFH: isc-dhcp

[Martin-Éric Racine]

On Mon, Feb 21, 2022 at 2:18 PM Martin-Éric Racine
 wrote:
>
> On Thu, Jan 6, 2022 at 8:40 PM Santiago R.R.  wrote:
> > On January 6, 2022 4:49:49 AM GMT-05:00, "Martin-Éric Racine" 
> >  wrote:
> > >Hello again,
> > >
> > >ke 24. marrask. 2021 klo 16.20 Santiago Ruano Rincón
> > >(santiag...@riseup.net) kirjoitti:
> > >> El 07/11/21 a las 13:54, Martin-Éric Racine escribió:
> > >> > ma 27. syysk. 2021 klo 21.44 Santiago Ruano Rincón
> > >> > (santiag...@riseup.net) kirjoitti:
> > >> > > El 27/09/21 a las 20:25, Martin-Éric Racine escribió:
> > >> > > > Package: wnpp
> > >> > > > Severity: normal
> > >> > > > X-Debbugs-Cc: debian-de...@lists.debian.org
> > >> > > > Control: affects -1 src:isc-dhcp
> > >> > > >
> > >> > > > -BEGIN PGP SIGNED MESSAGE-
> > >> > > > Hash: SHA256
> > >> > > >
> > >> > > > The ISC DHCP suite has a lenghty list of bug reports that have 
> > >> > > > been left unattended. Some bugs date back to DHCP 3 or even 
> > >> > > > earlier.
> > >> > > >
> > >> > > > Additionally, recent upstream releases are still unpackaged. One 
> > >> > > > release came out well ahead of the Bullseye freeze, a bug report 
> > >> > > > requesting its packaging was filed, but it remains unanswered.
> > >> > > >
> > >> > > > Leaving a package with a priority Important in such utter state of 
> > >> > > > neglect is unacceptable.
> > >> > > >
> > >> > > > At this point, it has become clear that, at the very least, its 
> > >> > > > maintainers need help, hence why I filed this WNPP bug.
> > >> > >
> > >> > > Indeed. I am willing to spend some cycles to help maintaining it. I
> > >> > > requested access to the ISC DHCP packaging team in salsa ~a couple of
> > >> > > weeks ago, but I hasn't been answered yet (mgilbert is its only 
> > >> > > member).
> > >> > > It was on my ToDo list to ping the maintainers (in CC).
> > >> >
> > >> > Has any progress taken place on this?
> > >>
> > >> I've started doing some work at 
> > >> https://salsa.debian.org/santiago/isc-dhcp/
> > >>
> > >> I still didn't get any answer from current maintainers (keeping them in
> > >> CC), so I plan to retitle this bug as an ITS bug soon. Hopefully no
> > >> later than next Friday.
> > >
> > >Has the ITA taken place?
> > >
> >
> > Not an ITA, but an ITS (CCed). I was unable close according to the ITS 
> > schedule, and I will have to resume the work after then end of my VAC 
> > (mid-January)
>
> This was nearly 2 months ago.  At this point, I think that apollock
> and mgilbert might as well be considered MIA.

Sure enough, upstream already is up to version 4.4.3b1, 26 January
2022, and recent commits include CVE fixes.

Martin-Éric

Bug#1006205: [Pkg-javascript-devel] Processed: reassign 1006205 to node-blueimp-md5

[Yadd]

On 21/02/2022 14:00, Jonas Smedegaard wrote:

Control: reassign 1006205 node-md5-hex

Quoting Debian Bug Tracking System (2022-02-21 13:27:11)

reassign 1006205 node-blueimp-md5


No, it is not a bug for node-blueimp-md5 to provide blueimp-md5!


Oups sorry, I inverted debian/watch files

Bug#1006205: [Pkg-javascript-devel] Processed: reassign 1006205 to node-blueimp-md5

[Jonas Smedegaard]

Control: reassign 1006205 node-md5-hex

Quoting Debian Bug Tracking System (2022-02-21 13:27:11)
> reassign 1006205 node-blueimp-md5

No, it is not a bug for node-blueimp-md5 to provide blueimp-md5!

It is a bug in node-md5-hex to embed blueimp-md5 without coordination at 
bug#867290, causing wasted duplicate packaging efforts.

It is arguably a bug in node-md5-hex to embed blueimp-md5 at all: It's 
*not* tightly related and seems *not* a tiny package to me, and 
evidently ftpmasters agree since they approved packaging it separately.

Regardless of the above two bugs in node-blueimp-md5, it is a bug in 
node-md5-hex to continue to ship blueimp-md5 after that has emerged as 
separate package!


Do *NOT* reassign again without prior discussion!


 - 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#1006215: bullseye-pu: package node-prismjs/1.23.0+dfsg-1+deb11u1

[Yadd]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
node-prismjs has 2 vulnerabilities:
 * Regex DoS (CVE-2021-40438)
 * cross-site scripting attack (CVE-2022-23647)

[ Impact ]
Medium vulnerabilities

[ Tests ]
No change in test, passed

[ Risks ]
Low risk, patch is trivial

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
 * Regexp change
 * Encode commandline arguments

[ Other info ]
I patched source files and regenerated minified files using uglifyjs

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index f70003b..956abf2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+node-prismjs (1.23.0+dfsg-1+deb11u1) bullseye; urgency=medium
+
+  * Team upload
+  * Fix ReDoS (Closes: CVE-2021-3801)
+  * Command Line: Escape markup in command line output
+(Closes: CVE-2022-23647)
+
+ -- Yadd   Mon, 21 Feb 2022 11:57:44 +0100
+
 node-prismjs (1.23.0+dfsg-1) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/control b/debian/control
index 27bb7f6..7021e6c 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,7 @@ Build-Depends: chai 
  , mocha 
  , node-yargs 
  , dh-sequence-nodejs
+ , uglifyjs
 Standards-Version: 4.5.1
 Vcs-Browser: https://salsa.debian.org/js-team/node-prismjs
 Vcs-Git: https://salsa.debian.org/js-team/node-prismjs.git
diff --git a/debian/patches/CVE-2021-40438.patch 
b/debian/patches/CVE-2021-40438.patch
new file mode 100644
index 000..a0830ac
--- /dev/null
+++ b/debian/patches/CVE-2021-40438.patch
@@ -0,0 +1,17 @@
+Description: Markup: fixed ReDoS
+Author: ready-research
+Origin: upstream, https://github.com/prismjs/prism/commit/0ff371bb
+Bug: https://security-tracker.debian.org/tracker/CVE-2021-40438
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2021-09-21
+
+--- a/components/prism-markup.js
 b/components/prism-markup.js
+@@ -1,5 +1,5 @@
+ Prism.languages.markup = {
+-  'comment': //,
++  'comment': //,
+   'prolog': /<\?[\s\S]+?\?>/,
+   'doctype': {
+   // https://www.w3.org/TR/xml/#NT-doctypedecl
diff --git a/debian/patches/CVE-2022-23647.patch 
b/debian/patches/CVE-2022-23647.patch
new file mode 100644
index 000..4008ab5
--- /dev/null
+++ b/debian/patches/CVE-2022-23647.patch
@@ -0,0 +1,19 @@
+Description: Escape markup in command line output
+Author: at055612 <22818309+at055...@users.noreply.github.com>
+Origin: upstream, https://github.com/PrismJS/prism/commit/e002e78c
+Bug: https://github.com/PrismJS/prism/security/advisories/GHSA-3949-f494-cm99
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2022-02-21
+
+--- a/plugins/command-line/prism-command-line.js
 b/plugins/command-line/prism-command-line.js
+@@ -122,7 +122,7 @@
+   var outputLines = commandLine.outputLines || [];
+   for (var i = 0, l = outputLines.length; i < l; i++) {
+   if (outputLines.hasOwnProperty(i)) {
+-  codeLines[i] = outputLines[i];
++  codeLines[i] = 
Prism.util.encode(outputLines[i]);
+   }
+   }
+   env.highlightedCode = codeLines.join('\n');
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..88f88a9
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1,2 @@
+CVE-2021-40438.patch
+CVE-2022-23647.patch
diff --git a/debian/rules b/debian/rules
index 8240d18..411edb7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,6 +7,13 @@
 %:
dh $@
 
+override_dh_auto_build:
+   dh_auto_build
+   uglifyjs -o components/prism-markup.min.js \
+   components/prism-markup.js
+   uglifyjs -o plugins/command-line/prism-command-line.min.js \
+   plugins/command-line/prism-command-line.js
+
 override_dh_fixperms:
dh_fixperms
chmod -x debian/node-prismjs/usr/share/nodejs/prismjs/package.json
diff --git a/debian/salsa-ci.yml b/debian/salsa-ci.yml
index 33c3a64..6fd902a 100644
--- a/debian/salsa-ci.yml
+++ b/debian/salsa-ci.yml
@@ -1,4 +1,7 @@
 ---
+variables:
+  RELEASE: 'bullseye'
+
 include:
   - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
   - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml

Bug#1006205: node-md5-hex: ships files already provided by node-blueimp-md5

[Andreas Beckmann]

Followup-For: Bug #1006205
Control: clone -1 -2
Control: found -2 2.19.0~ds-2
Control: retitle -2 node-blueimp-md5: missing Breaks+Replaces: node-md5-hex (<< 
3.0.1+~2.19.0-2~)
Control: reassign -1 node-md5-hex 3.0.1+~2.19.0-1

node-blueimp-md5 was only recently uploaded to the archive.
Therefore node-md5-hex needs to stop bundling it and use the separately
packaged node-blueimp-md5 instead.

node-blueimp-md5 needs Breaks+Replaces against node-md5-hex versions that
bundled node-blueimp-md5 content. (The version (<< 3.0.1+~2.19.0-2~) is
only a guess.)


Andrea

Bug#1006203: [Pkg-utopia-maintainers] Bug#1006203: polkitd: mishandled configuration ownership change from policykit-1 to polkitd

[Simon McVittie]

On Mon, 21 Feb 2022 at 12:42:06 +0100, Michael Biebl wrote:
> There is indeed no support for this.
> Taking over a conffile from another package is a tricky business and ideally
> would have native support by dpkg.
> 
> In systemd we used
> https://salsa.debian.org/systemd-team/systemd/-/commit/d6483013d5779d4d465a1e174e44a754b941d0e6
> for systemd-timesyncd.

In policykit-1, at least we don't have to handle the case where the
conffile is intentionally removed, because policykit-1 Depends on polkitd,
so things are a little simpler than what happens in systemd where upgrades
will not always install systemd-timesyncd.

smcv

Bug#892058: Thanks!

[Lisandro Damián Nicanor Pérez Meyer]

Now this is a useful service! Thanks a lot for the ping!

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/