Bug#1012619: want /etc/updatedb/updatedb.conf.d/

[Steinar H. Gunderson]

On Sat, Jun 11, 2022 at 02:12:50AM +0100, Ian Jackson wrote:
> How do you suggest I fix #1012617 ?

I don't know how your system works (and there's no documentation that I can
find), so I'm not in a position to say much about it. (If you use
filesystem-level snapshots, PRUNE_BIND_MOUNTS would take a fair amount of
such structures, but I really don't know what you're doing.) But there's
nothing preventing you from simply documenting that if you are bothered by
this, you should exclude the relevant directories in updatedb.conf (manually,
or through something like Puppet).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1012655: upstream bug and fix

[Stephan Verbücheln]

When I filed the bug, I could not find any other reports. Now I found
an upstream report which has matching symptoms.

https://bugzilla.kernel.org/show_bug.cgi?id=215890

However, there is confusion about the resolution. One reply states that
it was resolved in 5.18.0, but other replies talk about accidental
fixes.

A fix was submitted more recently than 5.18.0 release:
https://lore.kernel.org/all/20220606113636.588955-1-mathias.ny...@linux.intel.com/

Regards

Bug#1012641: schroot.service: Failed at step EXEC spawning /usr/share/schroot/bin/schroot-init: Is a directory

[rleigh]

FYI: https://gitlab.com/codelibre/schroot/-/blob/eol/README.md

-Original Message-
From: Christoph Biedl  
Sent: 11 June 2022 07:31
To: Konomi Kitten ; 1012...@bugs.debian.org
Subject: Bug#1012641: schroot.service: Failed at step EXEC spawning
/usr/share/schroot/bin/schroot-init: Is a directory

Control: tags 1012641 confirmed pending

Konomi Kitten wrote...

> After upgrading schroot the the schroot.service file fails to start:

Ouch. How did *that* slip through my testing procedure?

Thanks for reporting, will upload a fixed version ASAP.

Christoph

Bug#1012656: htmldoc: 1.9.16-1 CreationDate not reproducible

[Roland Rosenfeld]

Package: htmldoc
Version: 1.9.16-1
Severity: wishlist

Dear Maintainer,

I use htmldoc to build the documentation of xfig during package build.
This night the build pipeline of xfig reported a failed reproducible
build test: https://salsa.debian.org/debian/xfig/-/jobs/2866236
because the "CreationDate" of the PDF output is now depending on the
configured timezone:

-/CreationDate(D:2022050103560901400)/
+/CreationDate(D:20220430015609-1200)/

So the xfig package can no longer be build reproducible.

This was triggered by some upstream changes in htmldoc between 1.9.15
and 1.9.16 in htmldoc/ps-pdf.cxx:

@@ -537,7 +537,7 @@ pspdf_export(tree_t *document,  /* I - Document to export */
-  gmtime_r(&doc_time, &doc_date);
+  localtime_r(&doc_time, &doc_date);

Using localtime instead of gmtime makes the resulting file depend on
the given timezone and in the following code this time zone dependent
time is written to the CreationDate output:

@@ -11538,9 +11647,14 @@ write_prolog(FILE  *out,   /* I - Output file */
   fprintf(out, "BoundingBox: 0 0 %d %d\n", PageWidth, PageLength);
 fprintf(out,"LanguageLevel: %d\n", PSLevel);
 fputs("%%Creator: " HTMLDOC_PRODUCER "\n", out);
-fprintf(out, "CreationDate: D:%04d%02d%02d%02d%02d%02d+\n",
+fprintf(out, "CreationDate: D:%04d%02d%02d%02d%02d%02d%03d00\n",
 doc_date.tm_year + 1900, doc_date.tm_mon + 1, doc_date.tm_mday,
-doc_date.tm_hour, doc_date.tm_min, doc_date.tm_sec);
+doc_date.tm_hour, doc_date.tm_min, doc_date.tm_sec,
+#ifdef WIN32
+(int)(_timezone / 3600));
+#else
+   (int)(doc_date.tm_gmtoff / 3600));
+#endif // WIN32
 if (doc_title != NULL)
   fprintf(out, "Title: %s\n", doc_title);
 if (author != NULL)
@@ -11922,9 +12036,14 @@ write_prolog(FILE  *out,   /* I - Output file */
 fputs("/CreationDate", out);
-snprintf(temp, sizeof(temp), "D:%04d%02d%02d%02d%02d%02dZ",
+snprintf(temp, sizeof(temp), "D:%04d%02d%02d%02d%02d%02d%03d00",
 doc_date.tm_year + 1900, doc_date.tm_mon + 1, doc_date.tm_mday,
-doc_date.tm_hour, doc_date.tm_min, doc_date.tm_sec);
+doc_date.tm_hour, doc_date.tm_min, doc_date.tm_sec,
+#ifdef WIN32
+(int)(_timezone / 3600));
+#else
+   (int)(doc_date.tm_gmtoff / 3600));
+#endif // WIN32

For building xfig reproducible, I added a workaround by setting a
sticky timezone before calling htmldoc now, but I think that it isn't
a really good idea to use the timezone in the CreationDate at least if
SOURCE_DATE_EPOCH is defined.

Greetings
Roland

Bug#941131: Files uploaded to Upload.ee

[Upload.ee]

Hello


Your uploaded file 16DDB348-0915-4E76-8B7F-DFDF97CCE58B.jpg can be downloaded 
from: 
https://www.upload.ee/files/14219725/16DDB348-0915-4E76-8B7F-DFDF97CCE58B.jpg.html

Delete link: 
https://www.upload.ee/files/14219725/16DDB348-0915-4E76-8B7F-DFDF97CCE58B.jpg.html?killcode=78814846684836948298

NB! If you are registered user, you can also see your uploaded files under "My 
Files" section.
Upload.ee

Bug#1012196: ITP: exaile/4.1.2-beta1-1 -- Exaile is a music player with a simple interface

[Mezgani Ali]

Hello André,

Why we need that in Debian. You may take a look at 'amarok audio player’.
A complete and powerful Audio Player.

Amarok supports the KDE interface and there are many Music player in Gnome.




Kind regards, 
--
https://wiki.debian.org/mezgani


> On 31/05/2022, at 22:04, André  wrote:
> 
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "exaile":
> 
> * Package name : exaile
> Version : 4.1.2-beta1-1
> Upstream Author : Andre Flechs 
> * URL : https://exaile.org
> * License : GPL-2.0+
> * Vcs : https://github.com/exaile/exaile
> Section : sound
> 
> The source builds the following binary packages:
> 
> exaile - Exaile is a music player with a simple interface
> 
> To access further information about this package, please visit the following 
> URL:
> 
> https://mentors.debian.net/package/exaile/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/e/exaile/exaile_4.1.2-beta1-1.dsc
> 
> Changes since the last upload:
> 
> exaile (4.1.2-beta1-1) unstable; urgency=low
> 

Bug#1012536: guix: Debian's guix tries using Guix' glibc locales installed in /var/guix/profiles/... instead of Debian's glibc locales

[Maxime Devos]

Hi,

Will there also be an update to the 1.2.0 package as well
(bullseye/stable)?  Apparently an UTF-8 locale for 'guix substitute'
and 'guix offload' to work:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43039
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=aba8def46d392b3ef2278d16a2c9708fab05c6fd

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32942
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=7e4bc215098f334bc2a11737f2665dd4992fc2da

Greetings,
Maxime.


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

Bug#1012566: spdlog: Please package new version v1.10.0

[Andreas Tille]

Hi Boyuan,

Am Fri, Jun 10, 2022 at 08:35:23PM -0400 schrieb Boyuan Yang:
> 
> Just manually checked symbol changes with c++filt and it looks okay. I will
> make an upload to experimental to provide a base version for future work. Do
> expect some FTBFS due to unmatched symbols on some architectures, but
> pkgkde_symbolhelpers will kick in and solve the issue with next rebuild.

That's perfectly fine.  BTW, feel free to add yourself to Uploaders
of the package if you intend to contribute in future.

Thanks a lot for working on this package

Andreas. 


-- 
http://fam-tille.de

Bug#1010937: transition: gdal

[Sebastiaan Couwenberg]

On 6/11/22 01:32, Sebastian Ramacher wrote:

Please go ahead


Thanks. gdal (3.5.0+dfsg-1) has been uploaded to unstable and is built 
and installed on all release architectures.


libgdal-grass (1:1.0.0-1) has also been uploaded to unstable.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1012657: list-unreleased: use find's own '-regex' tests instead of grep

[Akbarkhon Variskhanov]

Package: devscripts
Version: 2.22.1ubuntu2
Master branch has identical code.

The 'find' utility provides the '-regex' primary test. Instead of cloning
and creating a subshell for grep, use that. It supports multiple regex
syntaxes but the default one should be okay.

Patch provided.

Tag: patch
--- list-unreleased.sh	2022-06-11 14:28:18.476849697 +0500
+++ list-unreleased_fix	2022-06-11 14:30:19.684504068 +0500
@@ -40,15 +40,15 @@
 
 [ "$PATHS" ] || PATHS=.
 
-vcs_dirs='(\.(svn|hg|git|bzr)|_darcs|_MTN|CVS)'
+vcs_dirs='\(\.\(svn\|hg\|git\|bzr\)\|_darcs\|_MTN\|CVS\)'
 get_list() {
 	local path="$1"
 
 	for dir in $(
 		if [ "$RECURSE" ]; then
-			find "$path" -type d | grep -vE "$vcs_dirs"
+			find "$path" -type d ! -regex "$vcs_dirs"
 		else
-			find "$path" -maxdepth 1 -type d | grep -vE "$vcs_dirs"
+			find "$path" -maxdepth 1 -type d ! -regex "$vcs_dirs"
 		fi
 	); do
 		changelog="$dir/debian/changelog"

Bug#1012655: upstream bug and fix

[Diederik de Haas]

Control: tag -1 fixed-upstream

On Saturday, 11 June 2022 09:33:09 CEST Stephan Verbücheln wrote:
> I found an upstream report which has matching symptoms.
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=215890
> 
> However, there is confusion about the resolution. One reply states that
> it was resolved in 5.18.0, but other replies talk about accidental fixes.
> 
> A fix was submitted more recently than 5.18.0 release:
> https://lore.kernel.org/all/20220606113636.588955-1-mathias.ny...@linux.inte
> l.com/

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c42e65664390be7c1ef3838cd84956d3a2739d60
is where it is fixed. But there is indeed some confusion as noted by Linus:
https://lore.kernel.org/all/CAHk-=wjcc15lsps1nj-e5nc-hr3ogvy+bqumyld9vz4hzad...@mail.gmail.com/

I normally use https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
and if you search for the primary commit message, it doesn't find it.
If you add "commit/?id=c42e65664390be7c1ef3838cd84956d3a2739d60" to that base
URL, you'll see "Notice: this object is not reachable from any branch."

So it is fixed upstream and according to Linus it is also part of 5.19-rc1
Apparently it's considered an important fix, so I guess it should be backported
to 5.18 'shortly'.

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

Bug#1012631: tcp-wrappers: d/copyright is incomplete

[Bastian Germann]

Control: tags -1 patch

Here is the patch.From: Bastian Germann 
Date: Sat, 11 Jun 2022 12:55:25 +0200
Subject: d/copyright: Add missing licenses in machine-readable format

Closes: #1012631
---
 debian/copyright| 110 
 debian/patches/05_wildcard_matching |   4 +-
 debian/patches/11_tcpd_blacklist|   1 +
 3 files changed, 84 insertions(+), 31 deletions(-)

diff --git a/debian/copyright b/debian/copyright
index e889bea..0cfd84d 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,33 +1,83 @@
-This package was debianized by Anthony Towns  on
-Tue, 10 Aug 1999 12:06:33 +1000.
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: TCP Wrapper
+Source: ftp://ftp.porcupine.org/pub/security/index.html
+Comment:
+ This package was debianized by Anthony Towns .
+ Thanks to Wietse Venema for his permission to include the TCP Wrapper
+ package in the Debian Distribution.
 
-It was downloaded from ftp://ftp.porcupine.org/pub/security/index.html
+Files: *
+Copyright: 1995 by Wietse Venema.  All rights reserved.
+Comment: Some individual files may be covered by other copyrights.
+License: TCP-wrappers
+ This material was originally written and compiled by Wietse Venema at
+ Eindhoven University of Technology, The Netherlands, in 1990, 1991,
+ 1992, 1993, 1994 and 1995.
+ .
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that this entire copyright notice
+ is duplicated in all such copies.
+ .
+ This software is provided "as is" and without any expressed or implied
+ warranties, including, without limitation, the implied warranties of
+ merchantibility and fitness for any particular purpose.
 
-and includes ftp://ftp.porcupine.org/pub/security/tcpd-blacklist-patch
+Files: strcasecmp.c
+Copyright: (c) 1987 Regents of the University of California.
+ All rights reserved.
+License: BSD-3-clause
+ Redistribution and use in source and binary forms are permitted
+ provided that the above copyright notice and this paragraph are
+ duplicated in all such forms and that any documentation,
+ advertising materials, and other materials related to such
+ distribution and use acknowledge that the software was developed
+ by the University of California, Berkeley.  The name of the
+ University may not be used to endorse or promote products derived
+ from this software without specific prior written permission.
+ THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 
-Copyright updated on 2001/06/08 from 
-ftp://ftp.porcupine.org/pub/security/tcp_wrappers_license
-
-Upstream Author: Wietse Venema
-
-Copyright:
-
-/
-* Copyright 1995 by Wietse Venema.  All rights reserved.  Some individual
-* files may be covered by other copyrights.
-*
-* This material was originally written and compiled by Wietse Venema at
-* Eindhoven University of Technology, The Netherlands, in 1990, 1991,
-* 1992, 1993, 1994 and 1995.
-*
-* Redistribution and use in source and binary forms, with or without
-* modification, are permitted provided that this entire copyright notice
-* is duplicated in all such copies.
-*
-* This software is provided "as is" and without any expressed or implied
-* warranties, including, without limitation, the implied warranties of
-* merchantibility and fitness for any particular purpose.
-/
-
-Thanks to Wietse Venema for his permission to include the tcp_wrapper
-package in the Debian Distribution.
+Files: debian/patches/05_wildcard_matching
+Copyright: (c) 1995 Tatu Ylonen , Espoo, Finland
+All rights reserved
+Comment: Applies to the function match_pattern_ylo.
+License: SSH
+   As far as I am concerned, the code I have written for this software
+   can be used freely for any purpose.  Any derived versions of this
+   software must be clearly marked as such, and if the derived work is
+   incompatible with the protocol description in the RFC file, it must be
+   called by a name other than "ssh" or "Secure Shell".
+ .
+   Note that any information and cryptographic algorithms used in this
+   software are publicly available on the Internet and at any major
+   bookstore, scientific library, and patent office worldwide.  More
+   information can be found e.g. at "http://www.cs.hut.fi/crypto";.
+ .
+   The legal status of this program is some combination of all these
+   permissions and restrictions.  Use only at your own responsibility.
+   You will be responsible for any legal consequences yourself; I am not
+   making any claims whether possessing or using this is legal or not in
+   your country, and I am not taking any responsibility on your behalf.
+ .
+

Bug#1012659: python3-paramiko: attempts to use RSA keys as DSA

[David Bremner]

Package: python3-paramiko
Version: 2.10.4-1
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This is arguably RC, since it prevents python3-paramiko in bookworm
from working with RSA keys generated in bookworm.

It seems to be upstream issue 1839 [1], which has been open for more
than a year.

To duplicate,

0) Generate an RSA ssh key

$   ssh-keygen -f test_key -t rsa -P ''
   
1) Run the following python code. It doesn't really matter whether the
key is in the key is present in authorized_keys, but the test host
should resolve.

import paramiko

username = 'git'
hostname = 'salsa.debian.org'

#  ssh-keygen -f test_key -t rsa -P ''
p_key = 'test_key'

client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
client.connect(hostname, username=username, key_filename=p_key)

2) Observe the traceback, with lots of talk about dsa

Unknown exception: q must be exactly 160, 224, or 256 bits long
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/paramiko/transport.py", line 2171, 
in run
handler(self.auth_handler, m)
  File "/usr/lib/python3/dist-packages/paramiko/auth_handler.py", line 377, 
in _parse_service_accept
sig = self.private_key.sign_ssh_data(blob, algorithm)
  File "/usr/lib/python3/dist-packages/paramiko/dsskey.py", line 109, in 
sign_ssh_data
key = dsa.DSAPrivateNumbers(
  File 
"/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/asymmetric/dsa.py",
 line 244, in private_key
return backend.load_dsa_private_numbers(self)
  File 
"/usr/lib/python3/dist-packages/cryptography/hazmat/backends/openssl/backend.py",
 line 827, in load_dsa_private_numbers
dsa._check_dsa_private_numbers(numbers)
  File 
"/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/asymmetric/dsa.py",
 line 282, in _check_dsa_private_numbers
_check_dsa_parameters(parameters)
  File 
"/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/asymmetric/dsa.py",
 line 274, in _check_dsa_parameters
raise ValueError("q must be exactly 160, 224, or 256 bits long")
ValueError: q must be exactly 160, 224, or 256 bits long

[1]: https://github.com/paramiko/paramiko/issues/1839

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

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

Versions of packages python3-paramiko depends on:
ii  python3   3.10.4-1+b1
ii  python3-bcrypt3.2.0-1+b1
ii  python3-cryptography  3.4.8-1
ii  python3-nacl  1.5.0-2
ii  python3-six   1.16.0-3

Versions of packages python3-paramiko recommends:
ii  python3-invoke  1.7.0+ds-1

Versions of packages python3-paramiko suggests:
ii  python3-gssapi  1.6.12-2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmKkf/wACgkQA0U5G1Wq
FSFSdRAAhOXmO38RNJ3hhIGijH1uTlUbkuFN0eQto7Ddw/YfQT0ManJnwWJzvyeS
XFJdNuF/xJqMjpmyPFPS2BeL4tlTg4yF/sNQD6h/VqiO5eXV4m1OmOOqjk772mgu
U2hgZyJ31W6ZBvMFeYIKhJ/f6ondEzml/lKAaDumKi13hG3C1IyX3ojyCSlnuvPF
sE5a0olLUaHQxBAkkcjqXCMROv0E9ANFZRDu4+N2LhXeGmG2yO+ejMLgPCBomDSR
tZpAWNfeWBEkDRNNg/HlnVqldCopCy/ozxAsZsJ8yyarPAMJvXmfbcV7qK9De9W5
6uw6ZtvkysTGLdikpjCi2S6uZXFxEczejjZf1M/XE45ZGlb8AqSoHCgwYh7DRO1P
0yKxdAMxqHmGAwmj1FYlaYu99L1IyvJD9KH8WC4l4XvoOFtCfGy9BT5vM27G2wot
lSSYl59mHOvA2rHwTwvrWzXJdIQLPS0b00/3vId8gqK3DJJoIiZl84Jig1FTIuz2
cCBwcJzdBM1foxzoPNIp2vPUel1evRayBptWUSXZZjQuxO0ezLCQnh2Wu/BjDCma
OzhBemytqm0L9km3AyfZ26zLTUjAx7kfIPA/X46BLA6F9ftqapXZXuolTxjkjPEq
UdLjxoYW26HX5vuU6HDeXEy/ONPN4lyJZu2rUxRMliFSdoSPqkU=
=YoNc
-END PGP SIGNATURE-

Bug#1012619: want /etc/updatedb/updatedb.conf.d/

[Ian Jackson]

Steinar H. Gunderson writes ("Re: Bug#1012619: want 
/etc/updatedb/updatedb.conf.d/"):
> On Sat, Jun 11, 2022 at 02:12:50AM +0100, Ian Jackson wrote:
> > How do you suggest I fix #1012617 ?

Sorry for being tetchy.

I still think I need to do better here.

> I don't know how your system works (and there's no documentation that I can
> find), so I'm not in a position to say much about it. (If you use
> filesystem-level snapshots, PRUNE_BIND_MOUNTS would take a fair amount of
> such structures, but I really don't know what you're doing.)

LVM level snapshots.  That's not unusual for backup systems.

> But there's
> nothing preventing you from simply documenting that if you are bothered by
> this, you should exclude the relevant directories in updatedb.conf (manually,
> or through something like Puppet).

I don't think "if you are bothered by this" is really right.  It's
clearly a bug, and it can cause the backups to actually fail.


How about the following proposal[1]:

 * Change updatedb so that it tolerates multiple
 PRUNEFS=
 PRUNEPATHS=
 PRUNENAMES=
   and simply concatenates the lists.

 * Have it additionally read files in /etc/updatedb/updatedb.conf.d
   (or some other similar name), as if their contents had been
   included in the main file.

This does not require a big change to the semantics: just allowing
a single list to be specified over multiple lines.

I think this would be enough to meet nearly everyone's needs,
including those of chiark-backup, rsbackup, and, well, whatever else
people might have.

Failing that, I could a send patch to the default file to include
chiark-backup's path, and maintainers/users of other systems with
similar needs could do the same.  But that isn't very scaleable, which
is why we usually use the .d convention in Debian.

Thanks,
Ian.

[1] My previous suggestion was under the assumption that the file was
a shell script.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#774068: ExtUtils-MakeMaker and NO_PERLLOCAL

[Damyan Ivanov]

-=| Niko Tyni, 30.12.2014 11:47:23 +0200 |=-
> (cc'ing the debian-perl list)
> 
> On Tue, Dec 30, 2014 at 08:38:56AM +, Damyan Ivanov wrote:
> > -=| Andrew Beverley, 29.12.2014 00:16:14 + |=-
> > > Is there any harm in having the option in there, especially as the
> > > upstream version of EU-MM defaults to creating perllocal.pod files, and
> > > provides this option to prevent it happening?
> > 
> > As I see it, adding and maintaining a line to 2000+ debian/rules files 
> > is a bit of a burden. Not an unbearable one, but we embraced the tiny 
> > dh rules exactly because they made things really simple.
> > 
> > > Presumably Debian's version uses a patched version of EU-MM, which was
> > > required before this option was available.
> > 
> > I wonder if debhelper would be the right place to add this. This would 
> > solve the problem this patch solves, and maybe also simplify the patch 
> > in the perl package package [1]
> > 
> > [1] 
> > https://anonscm.debian.org/cgit/perl/perl.git/tree/debian/patches/debian/no_packlist_perllocal.diff
> 
> Right, that seems like the right long term approach to me. Ideally,
> debhelper could pass both NO_PACKLIST and NO_PERLLOCAL to EU::MM, and
> the above patch wouldn't be needed at all.
> 
> This would be a similar transition to the (still unfinished) PREFIX one,
> see #579461 and 
>  
> https://lintian.debian.org/tags/debian-rules-makemaker-prefix-is-deprecated.html
> 
> Packages not using the short form dh rules would need to be modified
> before the patch could be removed. The required steps would be something
> like
>  1) change the Perl policy to recommend NO_PACKLIST + NO_PERLLOCAL
>  2) change debhelper v9 to use them
>  3) add a lintian check and/or do a mass bug filing for the other packages
>  4) wait for (most of) the packages to be fixed
>  5) change the Perl policy to require NO_PACKLIST + NO_PERLLOCAL
>  6) remove the patch from the perl package

I've been thinking about this. Even made the changes in debhelper¹ and 
considered a possible wording for the Perl policy.

 ¹ 
https://salsa.debian.org/dmn/debhelper/-/commits/b9cdc9696464f67f0c75479383a002ff666ffd6b

Then it occured to me that this is a titanic work that would take 
months if not years - rebuilding the archive, analyzing the results, 
providing patches to the packages that need them and track their 
progress.

All this so that a patch is dropped from Debian's EU:MM and packages 
created with dh-make-perl could be built in a rather non-standard 
environment.

And perhaps the other patches to Debian's EU:MM also have some purpose 
that would still be missing, so another round of the same would be 
needed.

Somehow, to me it seems that the gain is not worth the effort. By 
a huge margin.

So how about this instead:

Add a special option to dh-make-perl like '--pristine-upstream-eumm' 
that causes it to make whatever changes are necessary to the resulting 
package for it to build with the non-standard envronment. Including 
a warning to the docs that such a package is not intented for the 
official Debian archive.

Andrew, are you still interested in this and willing to provide 
a merge request/patch that provides such an option?

If you have solved the issue by other means (e.g. --data-dir), then 
perhaps we should just close this bugreport.


-- Damyan

Bug#1012619: want /etc/updatedb/updatedb.conf.d/

[Steinar H. Gunderson]

tags 1012619 + wontfix
thanks

On Sat, Jun 11, 2022 at 12:49:09PM +0100, Ian Jackson wrote:
> I don't think "if you are bothered by this" is really right.  It's
> clearly a bug, and it can cause the backups to actually fail.

If so, that's a bug on chiark-backup.

I do not intend do to put resources into this at the moment.
I would consider patches, assuming they do not cause significant extra
review or long-term maintenance.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1011985: claws-mail: [backport request] for compatibility with gmail

[Michel Briand]

Package: claws-mail
Version: 3.17.8-1+b1
Followup-For: Bug #1011985

Dear Maintainer,

please package version 3.19.0 into backports, it contains the necessary support 
for OAuth2 authentication (required by GMail and MS Exchange).

Best regards,


-- System Information:
Debian Release: 11.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'proposed-updates'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages claws-mail depends on:
ii  libc62.31-13+deb11u3
ii  libcairo21.16.0-5
ii  libcompfaceg11:1.5.2-5+b2
ii  libenchant-2-2   2.2.15-1
ii  libetpan20   1.9.4-3
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.8-1
ii  libgnutls30  3.7.1-5
ii  libgtk2.0-0  2.24.33-2
ii  libice6  2:1.0.10-1
ii  libldap-2.4-22.4.59+dfsg-1~bpo11+1
ii  libnettle8   3.7.3-1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  librsvg2-2   2.50.3+dfsg-1
ii  libsm6   2:1.2.3-1
ii  xdg-utils1.1.3-4.1

Versions of packages claws-mail recommends:
ii  aspell-en [aspell-dictionary]  2018.04.16-0-1
ii  aspell-fr [aspell-dictionary]  0.50-3-8.1
ii  aspell-it [aspell-dictionary]  2.4-20070901-0-3.1
ii  claws-mail-i18n3.17.8-1
ii  xfonts-100dpi  1:1.0.4+nmu1.1
ii  xfonts-75dpi   1:1.0.4+nmu1.1

Versions of packages claws-mail suggests:
ii  chromium [www-browser]99.0.4844.74-1~deb11u1
ii  claws-mail-doc3.17.8-1
ii  claws-mail-tools  3.17.8-1
ii  dillo [www-browser]   3.0.5-7
ii  firefox-esr [www-browser] 78.15.0esr-1~deb11u1
ii  gedit 3.38.1-1
ii  google-chrome-unstable [www-browser]  104.0.5110.0-1
ii  konqueror [www-browser]   4:20.12.0-4
ii  lynx [www-browser]2.9.0dev.6-3~deb11u1
ii  mousepad  0.5.2-1
ii  sugar-browse-activity [www-browser]   207-1
ii  w3m [www-browser] 0.5.3+git20210102-6

-- debconf-show failed

Bug#1012660: ITP: golang-github-pion-dtls -- DTLS 1.2 Server/Client implementation for Go

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-dtls
  Version : 2.1.5-1
  Upstream Author : Pion
* URL : https://github.com/pion/dtls
* License : Expat
  Programming Lang: Go
  Description : DTLS 1.2 Server/Client implementation for Go
 Native DTLS 1.2vimplementation in the Go programming language.
 .
 This is currently targeting DTLS 1.2, and the most modern/common cipher
 suites. Current features are:
 .
  * DTLS 1.2 Client/Server
  * Key Exchange via ECDHE(curve25519, nistp256, nistp384) and PSK
  * Packet loss and re-ordering is handled during handshaking
  * Key export (RFC 5705 (https://tools.ietf.org/html/rfc5705))
  * Serialization and Resumption of sessions
  * Extended Master Secret extension (RFC 7627)
  * ALPN extension (RFC 7301)

Bug#1012661: ITP: golang-github-pion-datachannel -- A Go implementation of WebRTC Data Channels

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-datachannel
  Version : 1.5.2-1
  Upstream Author : Pion
* URL : https://github.com/pion/datachannel
* License : Expat
  Programming Lang: Go
  Description: A Go implementation of WebRTC Data Channels
 Golang library implementing WebRTC Data Channels. WebRTC data channel
 lets you send text or binary data over an active connection to a peer

Bug#1012662: O: cmd2

[Federico Ceratto]

Package: wnpp
Severity: normal
Control: affects -1 src:cmd2

Orphaning this package.

Bug#1012663: paraview: FTBFS in unstable (error: expected identifier or ‘(’ before numeric constant)

[Bas Couwenberg]

Source: paraview
Version: 5.10.1-1
Severity: serious
Tags: ftbfs
Control: block 1010937 by -1

Dear Maintainer,

Your package FTBFS during the gdal transition:

 [  1%] Building C object 
VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_utils.c.o
 cd /<>/build.python3.9/VTK/ThirdParty/exodusII/vtkexodusII && 
/usr/bin/cc -DH5_BUILT_AS_DYNAMIC_LIB -DMPICH_SKIP_MPICXX -DMPI_NO_CPPBIND 
-DOMPI_SKIP_MPICXX -DVTK_MODULE_ENABLE_VTK_mpi=1 -D_MPICC_H -DexoIIc_EXPORTS 
-DexodusII_EXPORTS 
-I/<>/build.python3.9/VTK/ThirdParty/exodusII/vtkexodusII 
-I/<>/VTK/ThirdParty/exodusII/vtkexodusII 
-I/<>/VTK/ThirdParty/exodusII/vtkexodusII/include 
-I/<>/build.python3.9/VTK/ThirdParty/exodusII/vtkexodusII/include 
-isystem /<>/build.python3.9/VTK/ThirdParty/exodusII -isystem 
/<>/VTK/ThirdParty/exodusII -isystem 
/<>/build.python3.9/VTK/ThirdParty/hdf5 -isystem 
/<>/VTK/ThirdParty/hdf5 -isystem /usr/include/hdf5/serial -isystem 
/<>/build.python3.9/VTK/Utilities/MPI -isystem 
/<>/VTK/Utilities/MPI -isystem 
/usr/lib/x86_64-linux-gnu/openmpi/include -isystem 
/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -isystem 
/<>/build.python3.9/VTK/ThirdParty/netcdf -isystem 
/<>/VTK/ThirdParty/netcdf -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -pedantic 
-Wdate-time -D_FORTIFY_SOURCE=2  -O3 -DNDEBUG -fPIC -pthread -std=gnu99 -MD -MT 
VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_utils.c.o 
-MF CMakeFiles/exodusII.dir/src/ex_utils.c.o.d -o 
CMakeFiles/exodusII.dir/src/ex_utils.c.o -c 
/<>/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_utils.c
 In file included from 
/<>/build.python3.9/VTK/ThirdParty/netcdf/vtk_netcdf.h:22,
  from 
/<>/VTK/ThirdParty/exodusII/vtkexodusII/include/exodusII.h:22,
  from 
/<>/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_utils.c:20:
 /<>/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_utils.c: In 
function ‘vtkexodusII_ex__compress_variable’:
 /<>/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_utils.c:1773:19: 
error: expected identifier or ‘(’ before numeric constant
  1773 | const int NC_SZIP_NN = 32;  /* Selects nearest neighbor 
coding method for szip. */
   |   ^~

https://buildd.debian.org/status/fetch.php?pkg=paraview&arch=amd64&ver=5.10.1-1%2Bb1&stamp=1654951949&raw=0

Kind Regards,

Bas

Bug#1012664: network-manager-openvpn: --cipher option deprecated in OpenVPN 2.6, no option to set suggested --data-ciphers flag instead

[Simon Greaves]

Package: network-manager-openvpn
Version: 1.8.18-3
Severity: important
X-Debbugs-Cc: sjgrea...@gmail.com

Dear Maintainer,

   * What led up to the situation?

I have a subscription to an OpenVPN service which uses the AES-256-CBC
cipher. This was configured using the nm-openvpn-gnome UI and up until
the most recent OpenVPN version worked well albeit with a warning in
the daemon.log file that the --cipher flag was to be deprecated. Now,
having updated OpenVPN, the connection now fail because the flag is
now ignored. OpenVPN logs the suggestion that the cipher I need should
be added to the --data-ciphers list.

from daemon.log:
nm-openvpn[3234]: DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but
missing in --data-ciphers
(AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher
for cipher negotiations.
...
nm-openvpn[3234]: OPTIONS ERROR: failed to negotiate cipher with
server.  Add the server's cipher ('AES-256-CBC') to --data-ciphers
(currently 'AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305') if you want to
connect to this server.

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

Just trying to enable the VPN fails due to the required cipher not
being in the --data-ciphers list. There is no obvious way to do this
with the nm-openvpn tool, a quick glance at the source implies that
the --cipher flag is hardcoded there.

I tried adding the --data-cipher list including the AES-256-CBC cipher
to the /etc/default/openvpn file but that didn't seem to help.

   * What was the outcome of this action?

I have been trying to recompile the network-manager-openvpn package
from source having modified it but so far have been unsuccessful due
to unfamiliarity with packaging.

   * What outcome did you expect instead?

If nm-openvpn passes the correct flags then I expect the connection to
come up and work - it was fully operational with the previous OpenVPN
release. I will try configuring an OpenVPN client config file by hand
but obviously the nm-openvpn tool will need to be updated to reflect
the changes to OpenVPN itself. 



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

Kernel: Linux 5.17.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager-openvpn depends on:
ii  adduser  3.121
ii  libc62.33-7
ii  libglib2.0-0 2.72.1-1
ii  libnm0   1.38.0-2
ii  network-manager  1.38.0-2
ii  openvpn  2.6.0~git20220518+dco-2

network-manager-openvpn recommends no packages.

network-manager-openvpn suggests no packages.

-- no debconf information

Bug#1012665: coreutils: wrong GFDL version

[Bastian Germann]

Source: coreutils
Version: 8.32-4.1
Severity: serious
Justification: Policy violation
Tags: patch

The GFDL version of the published package version is 1.3, not 1.2 as claimed by 
coreutils.copyright.

I have attached a patch that places a machine-readable copyright file in 
debian/copyright
instead of referencing the *.copyright files of (some non-existing) binary 
packages.
The GFDL-NIV-1.3 license boilerplate is replaced by one in 
coreutils_8.32.orig.tar.xz.diff -Nru coreutils-8.32/debian/copyright coreutils-8.32/debian/copyright
--- coreutils-8.32/debian/copyright 2016-01-25 16:42:26.0 +0100
+++ coreutils-8.32/debian/copyright 2022-06-11 14:09:27.0 +0200
@@ -1,4 +1,124 @@
-Coreutils itself is generally copyrighted under the terms of the GNU General
-Public License. Specific copyrights can be found in the coreutils.copyright
-file and the *.copyright files for other packages included within the coreutils
-source package. (Generally, these are trivial transitional packages.)
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment: This is the Debian GNU/Linux packaged version of the GNU core
+ utilities.
+ This package is maintained by Michael Stone .
+ See the file AUTHORS for a list of each program's main authors.
+Source: ftp://ftp.gnu.org/gnu/coreutils
+
+Files: *
+Copyright: (C) 1984-2008 Free Software Foundation, Inc.
+License: GPL-3+
+
+Files: lib/fts.c
+   lib/fts_.h
+Copyright: (C) 2004-2020, 2008 Free Software Foundation, Inc.
+   (c) 1989, 1990, 1993, 1994  The Regents of the University of 
California.  All rights reserved.
+License: GPL-3+ and BSD-4-clause-UC
+
+License: GPL-3+
+   This program is free software: you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+ .
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+ .
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see .
+ .
+ On Debian systems, the complete text of the GNU General
+ Public License can be found in `/usr/share/common-licenses/GPL-3'.
+
+License: BSD-4-clause-UC
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 4. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+
+Files: lib/rand-isaac.[ch]
+Copyright: (C) 1999-2006 Free Software Foundation, Inc.
+   (C) 1997, 1998, 1999 Colin Plumb.
+License: GPL-3+
+
+Files: lib/inet_ntop.c
+Copyright: (C) 2005, 2006  Free Software Foundation, Inc.
+License: GPL-3+ and ISC
+
+License: ISC
+ * Copyright (c) 1996-1999 by Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS
+ * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE
+ * CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+ * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+ * PROFITS, WHETHER IN AN ACTION OF CO

Bug#1012663: paraview: FTBFS in unstable (error: expected identifier or ‘(’ before numeric constant)

[Sebastiaan Couwenberg]

On 6/11/22 15:03, Bas Couwenberg wrote:

  /<>/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_utils.c:1773:19: 
error: expected identifier or ‘(’ before numeric constant
   1773 | const int NC_SZIP_NN = 32;  /* Selects nearest neighbor 
coding method for szip. */
|   ^~


netcdf (4.9.0-1) contains this change in include/netcdf.h since 4.8.1-1:

+#define NC_SZIP_NN 32 /**< SZIP NN option mask. */

ParaView will need to be updated to build successfully with NetCDF 4.9.0.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1012666: ITS: wget2

[Boyuan Yang]

Source: wget2
Version: 1.99.1-2.2
Severity: important
X-Debbugs-CC: n...@debian.org
Tags: sid  bookworm

Dear wget2 package maintainer in Debian,

After looking into the package you maintain (wget2, 
https://tracker.debian.org/pkg/wget2), I found that this package
received no maintainer updates in the past 4 years and missed several upstream
releases. The request of making new uploads at https://bugs.debian.org/951354
was not solved as well. As a result, I am filing an ITS (Intent to Salvage)
request against your package according to section 5.12 in Debian's Developers'
Reference [1].

My current plan is to package the latest upstream release (2.0.1) and
clean up existing bugs.

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


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

-- 
Best Regards,
Boyuan Yang


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

Bug#1012667: dh-coq: invalid maintainer address

[Ansgar]

Source: dh-coq
Version: 0.1
Severity: serious
X-Debbugs-Cc: Julien Puydt 

dh-coq uses an invalid maintainer address:

   Maintainer: Debian OCaml Maintainers 

Most likely it only misses a "t" in the localpart.

Ansgar

Bug#1012668: ITP: golang-github-pion-ice.v2 -- Go implementation of ICE

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-ice.v2
  Version : 2.2.6-1
  Upstream Author : Pion
* URL : https://github.com/pion/ice
* License : Expat
  Programming Lang: Go
  Description: Go implementation of ICE
 Golang library implementing ICE for WebRTC
 Interactive Connectivity Establishment (ICE) is a framework to
 allow user's web browser to connect with peers.
 ICE uses STUN and/or TURN servers to accomplish this.


signature.asc
Description: PGP signature

Bug#1012604: RFS: libcap-ng/0.7.9-3 [ITS] -- alternate POSIX capabilities library

[Geert Stappers]

On Sat, Jun 11, 2022 at 05:57:26AM +, Håvard F. Aasen wrote:
> On 2022-06-10 15:52, Bastian Germann wrote:
> > Am 10.06.22 um 17:35 schrieb Håvard F. Aasen:
> > > > I have forked the salsa repo to debian namespace and invited you.
> > > I know the package is already uploaded, but is this a hard
> > > requirement for you? I would prefer to have it under my own
> > > namespace.
> > 
> > Kind of. If (when) you become unresponsive and someone else is taking
> > over the package, we can keep that.
> Not sure if I agree with you on this one, you proved yourself how easy
> it is to move the repository, this will be just as easy if I become
> unresponsive at a later time.
> Most of my worries is because of [1]. By placing it in the Debian
> namespace it is now in the "Debian Team" where every DD can do
> whatever they want.
 
That "whatever" indeed include
smart, good, needed, desired and even stupid things.



> > I would really like to keep it that way. Please tag the uploaded
> > version when it has arrived in the archive.
> Will do.
> 
> I will keep the repo in the Debian namespace for now and not push
> this further, but personally I feel that demanding packages to be
> part of a team isn't the best approach.

Aiming for perfect is good, reaching good is much better.


Groeten
Geert Stappers
DD


P.S.

In an ideal world will happen a stupid thing only once.

[1] 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#1012669: ITP: golang-github-pion-mdns -- Pure Go implementation of Multicast DNS

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-mdns
  Version : 0.0.5-1
  Upstream Author : Pion
* URL : https://github.com/pion/mdns
* License : Expat
  Programming Lang: Go
  Description : Pure Go implementation of Multicast DNS
 Golang mDNS implementation.
 The original user is Pion WebRTC, but is extendable for
 other uses.

Bug#1012670: nodejs: ftbfs on riscv64 arch due to some test cases

[Bo YU]

Package: nodejs
Version: 16.15.0+dfsg-1
Severity: minor
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org


Hi Jérémy,

The nodejs(16.15.0+dfsg-1) has ftbfs on riscv64 again. It seems
to FLAKY some test cases on riscv64 arch.

I build it ok on my locally machines with the patch attached, so 
feel free to apply it if you want :)

Bo

Subject: test does not pass on riscv64
Last-Update: 2022-05-03
Author: Jérémy Lal 
Forwarded: not-yet

--- a/test/sequential/sequential.status
+++ b/test/sequential/sequential.status
@@ -53,3 +53,13 @@
 [$arch==s390x]
 # https://github.com/nodejs/node/issues/41286
 test-performance-eventloopdelay: PASS, FLAKY
+
+[$arch==riscv64]
+test-diagnostic-dir-cpu-prof: FLAKY
+test-cpu-prof-worker-argv: FLAKY
+test-cpu-prof-exit: FLAKY
+test-cpu-prof-kill: FLAKY
+test-diagnostic-dir-cpu-prof: FLAKY
+test-debugger-preserve-breaks: FLAKY
+test-cpu-prof-dir-relative: FLAKY
+


signature.asc
Description: PGP signature

Bug#1011339: [Pkg-javascript-devel] Bug#1011339: [Pkg-openssl-devel] Bug#1011339: openssl: missing errors strings on mipsel

[Sebastian Andrzej Siewior]

On 2022-06-08 20:07:48 [+0200], Jérémy Lal wrote:
> Hi Sebastian,
Hi,

> Any hint or idea about this ? Even wild ideas that I could try,
> before I have to remove the files from mips.

I added RAND_status() as the first instruction in Start() (src/node.cc)
before InitializeOncePerProcess(). With this change the testsuite
passes on eller. So having the same init chain as on amd64 works.
Now let me figure out why the other init chain does not work…

> Jérémy

Sebastian

Bug#1012671: ITP: golang-github-pion-turn.v2 -- Pion TURN, an API for building TURN clients and servers (library)

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-turn.v2
  Version : 2.0.8-1
  Upstream Author : Pion
* URL : https://github.com/pion/turn
* License : Expat
  Programming Lang: Go
  Description: Pion TURN, an API for building TURN clients and servers (library)
 Pion TURN is a Go toolkit for building TURN servers and clients.
 pion/turn is an API for building STUN/TURN clients and servers, not a
 binary to deploy and then configure. It may require copying package examples
 and making minor modifications to fit the need, no knowledge of Go is
 required however. 


signature.asc
Description: PGP signature

Bug#1012672: ITP: golang-github-pion-srtp.v2 -- A Go implementation of SRTP

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-srtp.v2
  Version : 2.0.9-1
  Upstream Author : Pion
* URL : https://github.com/pion/srtp
* License : Expat
  Programming Lang: Go
  Description : Go implementation of SRTP (library)
 Library implementing Secure Real-time Transport Protocol (SRTP) in Golang.
 SRTP is used by WebRTC for encrypting media streams being a lighter
 weight option than DTLS.

Bug#1012673: ITP: golang-github-pion-webrtc.v3 -- Pure Go implementation of the WebRTC API

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-pion-webrtc.v3
  Version : 3.1.41-1
  Upstream Author : Pion
* URL : https://github.com/pion/webrtc
* License : Expat
  Programming Lang: Go
  Description : Pure Go implementation of the WebRTC API (library)
 This package implements WebRTC API in Golang. WebRTC is a free and open-
 source project providing web browsers and mobile applications with real-
 time communication via application programming interfaces.

Bug#999768: lintian: false report: adopted-extended-field

[Axel Beckert]

Hi Francesco,

Francesco Poli wrote:
> More than 6 months later, it seems that this bug is still unfixed in
> lintian: running lintian/2.114.0 produces the same complaints.

Correct.

See https://bugs.debian.org/1012289 formerly known as "O: lintian".

> Is there any hope this bug can get fixed soon, along with the other RC
> bugs currently open against lintian, so that lintian can work better in
> sid (and also migrate to testing, see bug [#1003643] ...)?

I'm now working on a new lintian release and I will work on the
currently open RC bugs.


> By the way: a new version (4.6.1) of Debian Policy has been released

No wonder if noone was working on Lintian proper. There's a pull
request for this
(https://salsa.debian.org/lintian/lintian/-/merge_requests/393),
though and I'll likely merge it once I fixed the more severe and more
pressing issues, namely failing the failing autopkgtests in current
git HEAD (first) and the RC bug reports (second).

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1012674: zlib: contrib/testzlib included (lintian: source-ships-excluded-file)

[Bastian Germann]

Source: zlib
Version: 1:1.2.11.dfsg-4
Severity: serious
Justification: non-free source in main
X-Debbugs-Cc: i...@winimage.com

Hi!

The contrib/testzlib files by Gilles Vollant  are rightfully 
marked
to be excluded from Debian by d/copyright because they are unlicensed and thus 
non-free.

While 1:1.2.8.dfsg-5 still excluded the files, they have since reappeared.
Please fix this with a new orig tarball. There is even a new upstream version 
1.2.12
available which you could import and fix this without even changing the dfsg 
suffix!

I have copied the original author who might shine a light on the supposed 
license.
The zlib FAQ says that the contrib/ files have their own license but there is 
none for
testzlib.

Thanks,
Bastian

Bug#1012675: saga loses gdal support when compiled with gdal 3.5.0

[Adrian Bunk]

Source: saga
Version: 8.2.1+dfsg-2
Severity: important

https://buildd.debian.org/status/logs.php?pkg=saga&ver=8.2.1%2Bdfsg-2%2Bb1

...
GDAL_INCLUDE_DIR=/usr/include/gdal
GDAL_LIBRARY=GDAL_LIBRARY-NOTFOUND
-- Could not find GDAL
...

Bug#1012676: libgtk-3-dev: Error loading png with gtk_image_set_from_file or gdk_pixbuf_new_from_file

[Heinrich]

Package: libgtk-3-dev
Version: 3.24.24-4+deb11u2
Severity: important
X-Debbugs-Cc: heinrich.a...@oltigen-manor.com

Dear Maintainer,

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

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

*** End of the template - remove these template lines ***
I use Debian (11.1), installed : Xfce (4.16), libgtk-3-dev (3.24) 
build-essential (10.2.1-6)

If i call :

Image_AchtungGefahrLinks = gtk_image_new ();
gtk_image_set_from_file (GTK_IMAGE (Image_AchtungGefahrLinks), 
"./__png's/achtunggefahrleer.png");
gtk_fixed_put (GTK_FIXED(AlteVersionWindowFixedLayout), 
Image_AchtungGefahrLinks, 15, 530-7+25);

I receive :

Gtk-WARNING **: 14:21:42.596: Could not load a pixbuf from 
/org/gtk/libgtk/icons/16x16/status/image-missing.png.
This may indicate that pixbuf loaders or the mime database could not be found.

**

Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: 
assertion failed (error == NULL): Failed to load 
/org/gtk/libgtk/icons/16x16/status/image-missing.png: Format der Bilddatei 
unbekannt (gdk-pixbuf-error-quark, 3)
Bail out! 
Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: 
assertion failed (error == NULL): Failed to load 
/org/gtk/libgtk/icons/16x16/status/image-missing.png: Format der Bilddatei 
unbekannt (gdk-pixbuf-error-quark, 3)
Aborted

if i call :

GError *error = NULL;
GdkPixbuf *pix = gdk_pixbuf_new_from_file ("./__png's/achtunggefahrleer.png", 
&error);
if (pix == NULL) {
g_printerr ("Error loading file: #%d %s\n", error->code, error->message);
g_error_free (error);
exit (1);
}
GtkWidget *widget = gtk_image_new_from_pixbuf (pix);

I receive :

Error loading file: #3 Das Format der Bilddatei 
»./__png's/achtunggefahrleer.png« konnte nicht erkannt werden

the loaders are in
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders

the loaders.cache is in 
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/

the png info in loaders.cache is
"/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so"
"png" 5 "gdk-pixbuf" "PNG" "LGPL"
"image/png" ""
"png" ""
"\211PNG\r\n\032\n" "" 100

it seems that the pixbuf loaders can not be found

the image-missing.png is in

/usr/share/icons/Adwaita/16x16/status/ or /usr/share/icons/Tango/16x16/status/ 
or /usr/share/icons/gnome/16x16/status/ or 
/usr/share/man/man1/gtk+3.0-3.24.24/gtk/icons/16x16/status

but it searchs it in 
/org/gtk/libgtk/icons/16x16/status


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

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

Versions of packages libgtk-3-dev depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-gtk-3.0   3.24.24-4+deb11u2
ii  libatk-bridge2.0-dev 2.38.0-1
ii  libatk1.0-dev2.36.0-2
ii  libcairo2-dev1.16.0-5
ii  libegl1-mesa-dev 20.3.5-1
ii  libepoxy-dev 1.5.5-1
ii  libfontconfig-dev [libfontconfig1-dev]   2.13.1-4.2
ii  libfontconfig1-dev   2.13.1-4.2
ii  libfribidi-dev   1.0.8-2
ii  libgdk-pixbuf-2.0-dev2.42.2+dfsg-1
ii  libglib2.0-dev   2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libgtk-3-common  3.24.24-4+deb11u2
ii  libpango1.0-dev  1.46.2-3
ii  libwayland-dev   1.18.0-2~exp1.1
ii  libx11-dev   2:1.7.2-1
ii  libxcomposite-dev1:0.4.5-1
ii  libxcursor-dev   1:1.2.0-2
ii  libxdamage-dev   1:1.1.5-2
ii  libxext-dev  2:1.3.3-1.1
ii  libxfixes-dev1:5.0.3-2
ii  libxi-dev2:1.7.10-1
ii  libxinerama-dev  2:1.1.4-2
ii  libxkbcommon-dev 1.0.3-2
ii  libxrandr-dev2:1.5.1-1
ii  pkg-config   0.29.2-1
ii  wayland-protocols1.20-1

libgtk-3-dev recommends no packages.

Versions of packages libgtk-3-dev suggests:
pn  libgtk-3-doc  

-- no debconf information

Bug#1009316: firmware-linux-nonfree: new upstream release (20220610)

[Diederik de Haas]

Control: retitle -1 firmware-linux-nonfree: new upstream release (20220610)
Control: severity 1011410 wishlist
Control: merge -1 1011410

On 11 Apr 2022 19:02:36 +0200 Diederik de Haas  wrote:
> Package: firmware-linux-nonfree
> Version: 20210818-1
> Severity: wishlist
> 
> Earlier today a new tag ``20220411`` was created in 
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

And yesterday tag ``20220610`` was created:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tag/?h=20220610

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

Bug#1012677: libgtk-3-dev: Error loading png with gtk_image_set_from_file or gdk_pixbuf_new_from_file

[Heinrich]

Package: libgtk-3-dev
Version: 3.24.24-4+deb11u2
Severity: important
X-Debbugs-Cc: heinrich.a...@oltigen-manor.com

Dear Maintainer,

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

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

*** End of the template - remove these template lines ***
I use Debian (11.1), installed : Xfce (4.16), libgtk-3-dev (3.24) 
build-essential (10.2.1-6)

If i call :

Image_AchtungGefahrLinks = gtk_image_new ();
gtk_image_set_from_file (GTK_IMAGE (Image_AchtungGefahrLinks), 
"./__png's/achtunggefahrleer.png");
gtk_fixed_put (GTK_FIXED(AlteVersionWindowFixedLayout), 
Image_AchtungGefahrLinks, 15, 530-7+25);

I receive :

Gtk-WARNING **: 14:21:42.596: Could not load a pixbuf from 
/org/gtk/libgtk/icons/16x16/status/image-missing.png.
This may indicate that pixbuf loaders or the mime database could not be found.

**

Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: 
assertion failed (error == NULL): Failed to load 
/org/gtk/libgtk/icons/16x16/status/image-missing.png: Format der Bilddatei 
unbekannt (gdk-pixbuf-error-quark, 3)
Bail out! 
Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: 
assertion failed (error == NULL): Failed to load 
/org/gtk/libgtk/icons/16x16/status/image-missing.png: Format der Bilddatei 
unbekannt (gdk-pixbuf-error-quark, 3)
Aborted

if i call :

GError *error = NULL;
GdkPixbuf *pix = gdk_pixbuf_new_from_file ("./__png's/achtunggefahrleer.png", 
&error);
if (pix == NULL) {
g_printerr ("Error loading file: #%d %s\n", error->code, error->message);
g_error_free (error);
exit (1);
}
GtkWidget *widget = gtk_image_new_from_pixbuf (pix);

I receive :

Error loading file: #3 Das Format der Bilddatei 
»./__png's/achtunggefahrleer.png« konnte nicht erkannt werden

the loaders are in
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders

the loaders.cache is in 
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/

the png info in loaders.cache is
"/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so"
"png" 5 "gdk-pixbuf" "PNG" "LGPL"
"image/png" ""
"png" ""
"\211PNG\r\n\032\n" "" 100

it seems that the pixbuf loaders can not be found

the image-missing.png is in

/usr/share/icons/Adwaita/16x16/status/ or /usr/share/icons/Tango/16x16/status/ 
or /usr/share/icons/gnome/16x16/status/ or 
/usr/share/man/man1/gtk+3.0-3.24.24/gtk/icons/16x16/status

but it searchs it in 
/org/gtk/libgtk/icons/16x16/status


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

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

Versions of packages libgtk-3-dev depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-gtk-3.0   3.24.24-4+deb11u2
ii  libatk-bridge2.0-dev 2.38.0-1
ii  libatk1.0-dev2.36.0-2
ii  libcairo2-dev1.16.0-5
ii  libegl1-mesa-dev 20.3.5-1
ii  libepoxy-dev 1.5.5-1
ii  libfontconfig-dev [libfontconfig1-dev]   2.13.1-4.2
ii  libfontconfig1-dev   2.13.1-4.2
ii  libfribidi-dev   1.0.8-2
ii  libgdk-pixbuf-2.0-dev2.42.2+dfsg-1
ii  libglib2.0-dev   2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libgtk-3-common  3.24.24-4+deb11u2
ii  libpango1.0-dev  1.46.2-3
ii  libwayland-dev   1.18.0-2~exp1.1
ii  libx11-dev   2:1.7.2-1
ii  libxcomposite-dev1:0.4.5-1
ii  libxcursor-dev   1:1.2.0-2
ii  libxdamage-dev   1:1.1.5-2
ii  libxext-dev  2:1.3.3-1.1
ii  libxfixes-dev1:5.0.3-2
ii  libxi-dev2:1.7.10-1
ii  libxinerama-dev  2:1.1.4-2
ii  libxkbcommon-dev 1.0.3-2
ii  libxrandr-dev2:1.5.1-1
ii  pkg-config   0.29.2-1
ii  wayland-protocols1.20-1

libgtk-3-dev recommends no packages.

Versions of packages libgtk-3-dev suggests:
pn  libgtk-3-doc  

-- no debconf information

Bug#1012675: saga loses gdal support when compiled with gdal 3.5.0

[Sebastiaan Couwenberg]

This is easily fixed with the same change to FindGDAL.cmake as for qgis:


https://salsa.debian.org/debian-gis-team/qgis/-/blob/master/debian/patches/gdal-multiarch.patch

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1000541: firmware-iwlwifi: are some firmwares missing or is the boot looking upstream unavailable ones?

[Diederik de Haas]

On Wednesday, 24 November 2021 19:46:54 CEST Patrice Duroux wrote:
> The iwlwifi-cc-a0-[66,65,64].ucode firmwares do not exist neither in the
> package neither here:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-> 
> firmware.git/tree/
> But it exists there iwlwifi-cc-a0-67.ucode that is not in the package.
> 
> Could this be the reason of those messages?

AFAIK the kernel tries to load firmware and if it doesn't find it, then it 
tries 
the next (appropriate) one. It looks like it did find an appropriate one (-63).

FTR: it does NOT look upstream, only on your local filesystem.

When the package gets updated, then those messages will likely change (or even 
disappear?). Could you update this bug when that happens by either closing it 
by sending a message to 1000541-d...@bugs.debian.org (or just send it to the 
bug report and someone else will close it) or if you think it's not fixed, 
update the bug with your new/updated finding?

TIA,
  Diederik

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

Bug#1012678: zlib: Add watch file

[Bastian Germann]

Source: zlib
Version: 1:1.2.11.dfsg-4
Severity: wishlist

Hi!

A new upstream version is available. Please add a debian/watch file to enable 
scanning for new versions:

opts="repacksuffix=.dfsg,dversionmangle=s/\.dfsg//" \
https://zlib.net/fossils/ @PACKAGE@-@ANY_VERSION@@ARCHIVE_EXT@

Thanks,
Bastian

Bug#969264: Warning message still present in Bullseye 11.2

[Diederik de Haas]

On Sun, 9 Jan 2022 23:20:49 +0100 Frode Severin Hatlevik 
 wrote:
> I just updated my Debian amd64 system from Buster to Bullseye as per
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html
> I have to admit I cut some corners and enabled backports and Fast Track and
> did the update in one go.
> 
> All went well, short of the error discussed in this bug appearing at the
> boot console
> [   20.208399] iwlwifi :02:00.0: firmware: failed to load
> iwl-debug-yoyo.bin (-2)

With what kernel version did you see that message?

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

Bug#1012679: pcre2: d/copyright has incorrect source URL

[Bastian Germann]

Source: pcre2
Version: 10.40-1

d/copyright claims that pcre2's sources are downloaded from 
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/
which had the pcre3 sources. This was probably copied from pcre3 on package 
creation.
The d/watch file has the correct pcre2 location.

Bug#1010937: transition: gdal

[Sebastiaan Couwenberg]

On 6/11/22 11:06, Sebastiaan Couwenberg wrote:

On 6/11/22 01:32, Sebastian Ramacher wrote:

Please go ahead


Thanks. gdal (3.5.0+dfsg-1) has been uploaded to unstable and is built 
and installed on all release architectures.


libgdal-grass (1:1.0.0-1) has also been uploaded to unstable.


Thanks for the binNMUs.

qgis can bin rebuilt now that grass is built and installed on all 
release architectures.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

debian-bugs-dist@lists.debian.org

[Trent W. Buck]

Package: devscripts
Version: 2.22.1~bpo11+1
Severity: wishlist
File: /usr/bin/rmadison

Please extend the rmadison parser so it can add &f=json to the URL it fetches.
This avoids people post-processing text to get json out.

01:08  TIL (from twb's comment earlier) "rmadison -u ubuntu" to 
find out package versions from ubuntu
01:09  It's super slow. :-/
01:11  And the output format differs
01:11  REDACTED2: indeed
01:12  so better not shell-parse that
01:13  the output here only seems to differ by a leading space 
in front of the package name
01:14  yes
01:19  rmadison $pkg | sed 's/  \+/ /g' | jc --csv   goes a long 
way to parsing the output though :)
01:19  TIL: jc
01:20  TIL there's no python-is-python2 in Ubuntu 22.04.
01:27  For me, "jc --csv" produces garbage on rmadison output.
01:30  Like... it assumes that the first line is a header, and 
uses "6" (?!) as the column separator.
01:30  oh hmm here (sid) it recognized the | as the separating 
character.  but I saw after posting that command that one would need to add a 
columns title line with echo for the json objects to make sense
01:31  anyway .. like you were saying, it's not super trivial to 
parse.
02:18  REDACTED1: I think this is probably easier: 
https://api.ftp-master.debian.org/madison?package=mg&f=json
02:19  The args rmadison passes are all single-letter codes, 
file:///usr/bin/rmadison#lines=197-209

Example output:

$ curl -s 
'https://api.ftp-master.debian.org/madison?package=mg&f=json&a=source&s=testing'
 | jq .
[
  {
"mg": {
  "testing": {
"20210609-1": {
  "component": "main",
  "architectures": [
"source"
  ],
  "source": "mg",
  "source_version": "20210609-1"
}
  }
}
  }
]

Note that this does NOT work for Ubuntu.

$ curl 
https://people.canonical.com/~ubuntu-archive/madison.cgi?package=mg\&f=json
dak ls aka madison
⋮
dak ls mg
 mg | 20110905-1.1 | trusty/universe  | source, amd64, arm64, armhf, i386, 
powerpc, ppc64el
 mg | 20160118-2   | xenial/universe  | source, amd64, arm64, armhf, i386, 
powerpc, ppc64el, s390x
 mg | 20171014-1   | bionic/universe  | source, amd64, arm64, armhf, i386, 
ppc64el, s390x
 mg | 20180927-1   | focal/universe   | source, amd64, arm64, armhf, 
ppc64el, riscv64, s390x
 mg | 20200723-1   | impish/universe  | source, amd64, arm64, armhf, 
ppc64el, riscv64, s390x
 mg | 20200723-1   | jammy/universe   | source, amd64, arm64, armhf, 
ppc64el, riscv64, s390x
 mg | 20210609-1   | kinetic/universe | source, amd64, arm64, armhf, 
ppc64el, riscv64, s390x
⋮
Usage: dak ls [OPTION] PACKAGE[...]
Display information about PACKAGE(s).

  -a, --architecture=ARCHonly show info for ARCH(s)
  -c, --component=COMPONENT  only show info for COMPONENT(s)
  -h, --help show this help and exit
  -r, --regextreat PACKAGE as a regex [not supported in 
madison.cgi]
  -s, --suite=SUITE  only show info for this suite
  -S, --source-and-binaryshow info for the binary children of source 
pkgs

ARCH, COMPONENT and SUITE can be comma (or space) separated lists, e.g.
--architecture=m68k,i386
⋮

-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
BTS_CACHE=no
DEBCHANGE_RELEASE_HEURISTIC=changelog
DEB_BUILD_HARDENING=1
DEB_BUILD_OPTIONS=parallel=$(getconf _NPROCESSORS_ONLN || echo 1)

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

Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 devscripts depends on:
ii  dpkg-dev  1.20.10
ii  fakeroot  1.25.3-1.1
ii  file  1:5.39-3
ii  gnupg 2.2.27-2+deb11u1
ii  gpgv  2.2.27-2+deb11u1
ii  libc6 2.31-13+deb11u3
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.11-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.004004-1
ii  libwww-perl   6.52-1
ii  patchutils0.4.2-1
ii  perl  5.32.1-4+deb11u2
ii  python3   3.9.2-3
ii  sensible-utils0.0.14
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.2.4
ii  curl7.74.0-1.3+deb11u1
ii  dctr

Bug#1012681: python3-jupyter-client: unfulfilled requirements?

[Jörg-Volker Peetz]

Package: python3-jupyter-client
Version: 7.3.4-1
Severity: normal


Dear Debian Python Team,

the command

$ python3 -m pip check

gives:

jupyter-client 7.3.4 has requirement python-dateutil>=2.8.2, but you have
python-dateutil 2.8.1.
jupyter-client 7.3.4 has requirement pyzmq>=23.0, but you have pyzmq 22.3.0.

Is this serious?

Regards,
Jörg.


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

Kernel: Linux 5.18.3 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages python3-jupyter-client depends on:
ii  python3   3.9.8-1
ii  python3-dateutil  2.8.1-6
ii  python3-entrypoints   0.4-1
ii  python3-jupyter-core  4.10.0-1
ii  python3-nest-asyncio  1.5.4-1
ii  python3-tornado   6.1.0-3
ii  python3-traitlets 5.2.2-1
ii  python3-zmq   22.3.0-1

python3-jupyter-client recommends no packages.

python3-jupyter-client suggests no packages.

-- no debconf information

Bug#1005202: [Debichem-devel] Bug#1005202: openmolcas: Is the -fno-expensive-optimizations flag still needed?

[Michael Banck]

Hi João,

On Tue, Feb 08, 2022 at 11:31:20PM +, João wrote:
> Source: openmolcas
> Version: 21.10-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Is the compiler flag -fno-expensive-optimizations in debian/rules still 
> needed?
> This flag was introduced to fix a problem with the arm64 build as reported in 
> the bug
> https://bugs.debian.org/961704
> and associated upstream issue
> https://gitlab.com/Molcas/OpenMolcas/-/issues/218
> 
> However the following merge request applied upstream
> https://gitlab.com/Molcas/OpenMolcas/-/merge_requests/420
> suggests that the issue might have been fixed with the flag -ffp-contract=off

I've replaced -fno-expensive-optimizations with -ffp-contract=off now,
but from reading the MR description it sounds like that new flag is only
needed for one test that we don't run during autopkgtest currently.
Still, I guess it won't hurt.

Let's see whether arm64 still works...


Michael

Bug#1012651: transition: log4cxx

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-06-11 07:44:54 +0200, Tobias Frost wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> I'm preparing the transistion for log4cxx from SONAME 12 to SONAME 13.
> I have built the r-deps locally with the result indicated below:
> 
>  solarpowerlog-- builds fine
>  ros-rosconsole   -- builds fine
>  zookeeper-- FTBFS, unrelated to log4cxx (#984406)
> 
> TL:DR: Should be a small, smooth transition.
> 
> Ben file: (The "auto" transistion seems to be right already)
> 
> title = "log4cxx";
> is_affected = .depends ~ "liblog4cxx12" | .depends ~ "liblog4cxx13";
> is_good = .depends ~ "liblog4cxx13";
> is_bad = .depends ~ "liblog4cxx12";
> 
> --
> Waiting for your green light,

Please go ahead

Cheers

> tobi 
> 

-- 
Sebastian Ramacher

Bug#1011339: [Pkg-javascript-devel] Bug#1011339: [Pkg-openssl-devel] Bug#1011339: openssl: missing errors strings on mipsel

[Sebastian Andrzej Siewior]

control: forwarded -1 https://github.com/openssl/openssl/issues/18535

On 2022-06-08 20:07:48 [+0200], Jérémy Lal wrote:
> Hi Sebastian,
Hi,

> Any hint or idea about this ? Even wild ideas that I could try,
> before I have to remove the files from mips.

Okay. So if you do
OPENSSL_init_crypto(OPENSSL_INIT_LOAD_CONFIG
OPENSSL_INIT_LOAD_CRYPTO_STRINGS |
OPENSSL_INIT_ADD_ALL_CIPHERS |
OPENSSL_INIT_ADD_ALL_DIGESTS, settings);

in src/node.cc instead just OPENSSL_INIT_LOAD_CONFIG as it is currently
done, then it will pass.

The difference on mipsel is the call chain. Due to openssl internal
locking it can't load strings. As of now I think that this is a bug in
openssl and I forwarded it to upstream.
So you have a workaround you may try if you want something asap and I
let you know what upstream thinks about this ;)

> Jérémy

Sebastian

Bug#1012533: ftp.debian.org: Please consider a firmware component for bookworm

[Ansgar]

Hi,

On Wed, 2022-06-08 at 21:48 +0200, Jonathan Carter wrote:
> Recently, Steve McIntyre initiated a discussion[1] on debian-devel on
> the future of firmware in Debian, and how we want to address it
> as a project.

[ Request to add non-free-firmware ]

Okay, I'm fine with adding non-free-firmware. I assume the other
members of the ftp team are also still fine with this.

Should we add it to testing/unstable/experimental in one go? Or does
the release team prefer to wait with adding it to testing?

We can always revert the addition temporarily if we find bugs that take
a while to fix.

Ansgar

Bug#1012682: argon2: New upstream version available

[Bastian Germann]

Source: argon2
Version: 0~20171227-0.3

Please import the new upstream version 20190702 that installs the pkg-config 
file,
which enables dropping d/rules' workaround for it.

Bug#1012683: ITP: wl-mirror -- output-mirroring tool for wlroots-based Wayland desktops

[Ferdinand Bachmann]

Package: wnpp

Severity: wishlist

Owner: Ferdinand Bachmann 

X-Debbugs-Cc: debian-de...@lists.debian.org



* Package name: wl-mirror

  Version : 0.11.3

  Upstream Author : Ferdinand Bachmann 

* URL : https://github.com/Ferdi265/wl-mirror

* License : GPL-3+

  Programming Lang: C

  Description : output-mirroring tool for wlroots-based Wayland 
desktops




wl-mirror is a tool to add output mirroring to sway and other

wlroots-based Wayland compositors. wl-mirror requires the export-dmabuf

or screencopy protocols to work.



## Extended Description



wl-mirror basically fills a usability hole in sway and other

wlroots-based compositors, since you without wl-mirror or a similar

tool, you cannot easily hold presentations with a projector since there

is absolutely no support for mirroring your screeheadersn instead of 
extending


it.



## Packaging



This is my first Debian package, so I might have some questions about

packaging, but the "How to Package" guides from the Debian wiki should

be enough.



I already have a proof-of-concept Debian package, but that might need a

little bit more work to meet Debian guidelines.



## Maintenance



I intend to maintain this package myself, updating it whenever I find

bugs in wl-mirror, when I release a new version (for next Debian

release...), or when changes become necessary for Debian releases.



## Other Packages



wl-mirror has already been packaged for



- Arch Linux (AUR): https://aur.archlinux.org/packages/wl-mirror

- Alpine Linux 3.16:

  https://pkgs.alpinelinux.org/packages?name=wl-mirror&branch=v3.16

- NixOS 22.05:


https://github.com/NixOS/nixpkgs/tree/release-22.05/pkgs/tools/wayland/wl-mirror

- FreeBSD Ports: https://www.freshports.org/x11/wl-mirror

- DragonFlyBSD Ports:

  https://github.com/DragonFlyBSD/DPorts/tree/master/x11/wl-mirror

Bug#1012684: ITP: wl-mirror -- output-mirroring tool for wlroots-based Wayland desktops

[Ferdinand Bachmann]

Package: wnpp
Severity: wishlist
Owner: Ferdinand Bachmann 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: wl-mirror
  Version : 0.11.3
  Upstream Author : Ferdinand Bachmann 
* URL : https://github.com/Ferdi265/wl-mirror
* License : GPL-3+
  Programming Lang: C
  Description : output-mirroring tool for wlroots-based Wayland 
desktops


wl-mirror is a tool to add output mirroring to sway and other
wlroots-based Wayland compositors. wl-mirror requires the export-dmabuf
or screencopy protocols to work.

## Extended Description

wl-mirror basically fills a usability hole in sway and other
wlroots-based compositors, since you without wl-mirror or a similar
tool, you cannot easily hold presentations with a projector since there
is absolutely no support for mirroring your screen instead of extending
it.

## Packaging

This is my first Debian package, so I might have some questions about
packaging, but the "How to Package" guides from the Debian wiki should
be enough.

I already have a proof-of-concept Debian package, but that might need a
little bit more work to meet Debian guidelines.

## Maintenance

I intend to maintain this package myself, updating it whenever I find
bugs in wl-mirror, when I release a new version (for next Debian
release...), or when changes become necessary for Debian releases.

## Other Packages

wl-mirror has already been packaged for

- Arch Linux (AUR): https://aur.archlinux.org/packages/wl-mirror
- Alpine Linux 3.16:
  https://pkgs.alpinelinux.org/packages?name=wl-mirror&branch=v3.16
- NixOS 22.05:

https://github.com/NixOS/nixpkgs/tree/release-22.05/pkgs/tools/wayland/wl-mirror
- FreeBSD Ports: https://www.freshports.org/x11/wl-mirror
- DragonFlyBSD Ports:
  https://github.com/DragonFlyBSD/DPorts/tree/master/x11/wl-mirror

Bug#1012685: tilix: Broken binary dependency due to ldc 1.29

[Boyuan Yang]

Package: tilix
Severity: serious
Version: 1.9.5-1
X-Debbugs-CC: jbi...@debian.org m...@debian.org

Dear Debian tilix package maintainer,

According to https://tracker.debian.org/pkg/tilix , package tilix was removed
from Testing and has impossible dependency on disappeared shared library
provided by src:ldc. Please consider solving this issue.

Thanks,
Boyuan Yang


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

Bug#1003824: Difference in current filename packaging conventions leads to downloads being ignored by apt

[Luke Ross]

I also experience this problem; after running debdelta-upgrade I use
this snippet (all on one line; not elegant) to fix up the files so that
apt can find them:

for i in /var/cache/apt/archives/*%*; do sudo mv -n "$i" `perl -e
'$ARGV[0] =~ s/%(2b|7e)/chr(hex($1))/ge; print $ARGV[0]' "$i"`; done

The affected characters, for me, are %2b (+) and %7e (~).

Bug#1012683: ITP: wl-mirror

[Ferdinand Bachmann]

please close this bug in favor of #1012684, I made a mistake when 
sending this mail so all of the line breaks are doubled up.

Bug#1003454: py-lmdb: Non-functional d/watch and new versions available

[Bastian Germann]

Control: retitle -1 py-lmdb: new versions available

I have fixed the watch file in git; this leaves us with a new upstream version.

Bug#996029: firmware-iwlwifi: Filter bogus warning with "firmware: failed to load iwl-debug-yoyo.bin"

[Diederik de Haas]

Control: reassign src:linux
Control: severity important
Control: merge -1 966218

On 10 Oct 2021 23:50:43 +0900 Hideki Yamane  wrote:
>  During looking logs, I've found that iwlwifi puts warning as below.
> 
> > 7月 09 21:04:01 elitebook830 kernel: iwlwifi :01:00.0: firmware: failed
> > to load iwl-debug-yoyo.bin (-2)

This is the same issue as 966218. It should be fixed in the Debian kernel and 
not suppress it via a config file.

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

Bug#1012686: libsemanage.semanage_pipe_data: Child process /usr/libexec/selinux/hll/pp failed

[Mohsen Pahlevanzadeh]

Package: selinux-policy-default
Version: 2:2.20220520-1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***
When I install selinux-policy-default, I get the following messages:
Setting up selinux-policy-default (2:2.20220520-1) ...
Updating selinux default policy (this step might take a 
moment)...libsemanage.semanage_pipe_data: Child process 
/usr/libexec/selinux/hll/pp failed wi
th code: 255. (No such file or directory).
xserver: libsepol.validate_user_datum: Invalid user datum
xserver: libsepol.validate_datum_array_entries: Invalid datum array entries
xserver: libsepol.validate_policydb: Invalid policydb
xserver: libsepol.sepol_module_package_read: invalid module in module package 
(at section 0)
xserver: Failed to read policy package
libsemanage.semanage_direct_commit: Failed to compile hll files into cil files.
 (No such file or directory).
semodule:  Failed!
 failed.
dpkg: error processing package selinux-policy-default (--configure):
 installed selinux-policy-default package post-installation script subprocess 
returned error exit status 1
Errors were encountered while processing:
 selinux-policy-default
E: Sub-process /usr/bin/dpkg returned an error code (1)


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


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

Kernel: Linux 5.18.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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages selinux-policy-default depends on:
ii  libselinux1  3.4-1
ii  libsemanage2 3.4-1
ii  libsepol23.4-1
ii  policycoreutils  3.4-1
ii  selinux-utils3.4-1

Versions of packages selinux-policy-default recommends:
ii  checkpolicy  3.4-1
ii  setools  4.4.0-1+b1

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

-- no debconf information

Bug#1012227: webkitgtk: CPU usage

[tmcconnell168]

This might seem like a stupid question, however; I noticed that when
the CPU was at 100% usage WebKitWebProcess had two PIDs. If I can get
it to do it again so I need to run the command for each PID or can I
run sudo perf top -pPID1 -pPID2 --sort dso,symbol? 
Thanks! 
Tim
-- 
 


On Fri, 2022-06-10 at 16:34 +, Alberto Garcia wrote:
> On Fri, Jun 10, 2022 at 11:27:39AM -0500,
> tmcconnell...@gmail.com wrote:
> >  5533 tmick 20   0   84.3g 620608  60480 R  98.3   8.7  
> > 4:36.70 WebKitWebProces
> 
> > Running sudo perf top -pPID --sort dso,symbol told me gave me
> 
> Here -pPID would have the number of the process that is using the
> CPU,
> in your case
> 
> sudo perf top -p5533 --sort dso,symbol
> 
> Berto

Bug#1012688: libpam0-dev: Provide pkgconfig files (new upstream available)

[Bastian Germann]

Package: libpam0-dev
Version: 1.4.0-13

Upstream has a new version 1.5.2 that has this change:
* Added pkgconfig files for provided libraries.

Please import that new version and make the pkgconfig files available.

Bug#1012687: ITP: python-cloup -- Click with option groups

[Timo Röhling]

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-cloup
  Version : 0.14.0
  Upstream Author : Gianluca Gippetto
* URL : https://github.com/janluke/cloup
* License : BSD-3-clause
  Programming Lang: Python
  Description : Click with option groups

Cloup enriches Click with several features that make it more expressive and
configurable:
 * option groups and an (optional) help section for positional arguments
 * constraints, like mutually_exclusive, that can be applied to option groups
   or to any group of parameters, even conditionally subcommand aliases
 * subcommands sections, i.e. the possibility to organize the subcommands of
   a Group in multiple help sections
 * a themeable HelpFormatter that:
   - has more parameters for adjusting widths and spacing, which can be
 provided at the context and command level use a different layout when the
 terminal width is below a certain threshold in order to improve
 readability
   - suggestions like "did you mean ?" when you mistype a
 subcommand
Moreover, Cloup improves on IDE support providing decorators with detailed
type hints and adding the static methods Context.settings() and
HelpFormatter.settings() for creating dictionaries of settings.

Cloup is a dependency of manim-ce [1]

The package will be team-maintained under the umbrella of
Debian Python Team 
at https://salsa.debian.org/python-team/packages/python-cloup

[1] https://bugs.debian.org/1012608


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmKk4PoACgkQ+C8H+466
LVnuawv/ebpNfq/yyKo+ukQbtqRjLwtuOTR2WxAPlmIg82IhlNMRpIHJyUKemx2o
LyzUAAHLzQf2eyEQrqpLHFM0hSYOcm4g56OE0RVCrII1HenBfIcwzQR70BOw3tLj
w+7W3QP9sZl8MM/F3cA9DoFkmutd+o2nNZvccvAC9OhJinbb4a9U+ttXT8N+eJXZ
E3ZlCN9a0ELZmzQCuvOFCt5I5fi4u6GBEIWAhygii3gJATxkVxJmcDUJj5z2rS8g
qIgA99RzzaW2iO7UxP16SiN+mQj/dJsp2Hon01AH0qIY6EvBFezoQOg8SDhK4LnZ
fnnj9Zq6uvCOGHTPARyOHKNI86RJMhYJZdmxJBvbGJan7zZvMNprA58MNzCvxuIh
wooPUM7MSxKFPDWrfGXBjOc+iT8aK7oH8tfJJaAHbxggp162EUnpMJR5xYnV0sMP
YT/8ZrG1XsV6pH9Qx+eU2muxibGMHGhu/5QdJuI+ef+HWRZiL6RRfeulklgycvoS
lbfIoseM
=+omT
-END PGP SIGNATURE-

Bug#1012689: mia: Migration from vtk7 to vtk9

[Francois Mazen]

Source: mia
Severity: wishlist
Tags: patch
X-Debbugs-Cc: franc...@mzf.fr

Dear Maintainer,

Mia package depends on vtk7 which is quite old and not maintained upstream.

I've succeeded to build mia with vtk9 by changing Build-Depends from
libvtk7-dev to libvtk9-dev and fixing CMake and build errors.
The patch is attached to this message.

Could you please update to vtk9?

Thanks,

François
--- a/addons/vtk/CMakeLists.txt
+++ b/addons/vtk/CMakeLists.txt
@@ -20,9 +20,9 @@
 
 IF(WITH_VTKIO)
   if (STRICT_DEPENDECIES)
-FIND_PACKAGE(VTK REQUIRED COMPONENTS  vtkIOImage  vtkIOXML vtkIOLegacy)
+FIND_PACKAGE(VTK REQUIRED COMPONENTS  IOImage IOXML IOLegacy)
   else (STRICT_DEPENDECIES)
-FIND_PACKAGE(VTK COMPONENTS vtkIOImage vtkIOXML vtkIOLegacy)
+FIND_PACKAGE(VTK COMPONENTS IOImage IOXML IOLegacy)
   endif (STRICT_DEPENDECIES)
   IF(VTK_FOUND)
 DEFINE_PROPERTY(GLOBAL PROPERTY HAVE_VTK_PROP BRIEF_DOCS "yeah" FULL_DOCS 
"yeah")
@@ -41,8 +41,17 @@
 SET(VTK_LINK_LIBS_3D ${SELECTED_VTK_LIBS} mia3d)
 
 PLUGIN_WITH_TEST_AND_PREFIX2("mesh" "io" vtkmesh "${VTK_LINK_LIBS_MESH}")
+target_link_libraries(mesh-io-vtkmesh ${VTK_LIBRARIES})
+target_link_libraries(mesh-io-vtkmesh-common ${VTK_LIBRARIES})
+target_link_libraries(test-mesh-io-vtkmesh ${VTK_LIBRARIES})
 PLUGIN_WITH_TEST_AND_PREFIX2("3dvf" "io" vtkvf "${VTK_LINK_LIBS_3D}")
+target_link_libraries(3dvf-io-vtkvf ${VTK_LIBRARIES})
+target_link_libraries(3dvf-io-vtkvf-common ${VTK_LIBRARIES})
+target_link_libraries(test-3dvf-io-vtkvf ${VTK_LIBRARIES})
 PLUGIN_WITH_TEST_AND_PREFIX2("3dimage" "io" vtkimage "${VTK_LINK_LIBS_3D}")
+target_link_libraries(3dimage-io-vtkimage ${VTK_LIBRARIES})
+target_link_libraries(3dimage-io-vtkimage-common ${VTK_LIBRARIES})
+target_link_libraries(test-3dimage-io-vtkimage ${VTK_LIBRARIES})
 
   ELSEIF(VTK_FOUND)
 MESSAGE(MESSAGE "VTK not found, disabled")
--- a/addons/vtk/vtkmesh.cc
+++ b/addons/vtk/vtkmesh.cc
@@ -78,7 +78,8 @@
// read all cells, if a cell is formed of more than 3 corners, then 
triangulate,
// if it hes less then 3 corners, ignore it (no wireframes supported 
here
auto triangles = CVtkMeshIO::PTrianglefield(new 
CVtkMeshIO::CTrianglefield ());
-   vtkIdType npts, *pts;
+   vtkIdType npts;
+   vtkIdType const *pts;
auto strips = mesh.GetStrips();
 
while (strips->GetNextCell(npts, pts)) {
@@ -183,7 +184,7 @@
auto is = mesh.normals_begin();
 
for (auto i = 0; i < n_normals; ++i, ++is) {
-  normals->GetTupleValue(i, &is->x);
+  normals->GetTypedTuple(i, &is->x);
   cvdebug() << i << ": read normal " << *is << "\n";
}
 }
@@ -217,7 +218,7 @@
auto is = mesh.color_begin();
 
for (auto i = 0; i < n_colors; ++i, ++is)
-  colors->GetTupleValue(i, &is->x);
+  colors->GetTypedTuple(i, &is->x);
 }
 
 PTriangleMesh CVtkMeshIO::do_load(string const&   filename) const

Bug#1012690: pagetools: FTBFS with netpbm11

[Steve Langasek]

Source: pagetools
Version: 2.0-9.1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Hi Victor,

pagetools build-depends on libnetpbm10-dev, which has been obsoleted in
favor of libnetpbm11-dev (related: https://bugs.debian.org/1007984).  After
updating the build-dependency, the package still fails to build from source:

[...]
c++ -g -O2 -ffile-prefix-map=/tmp/pagetools-0.1=. -flto=auto -ffat-lto-objects 
-flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 formats/pbmfact.cpp -I 
. -fno-implicit-templates -c -o formats/pbmfact.o
formats/pbmfact.cpp:22:10: fatal error: pbm.h: No such file or directory
   22 | #include 
  |  ^~~
compilation terminated.
make[2]: *** [Makefile:25: formats/pbmfact.o] Error 1
[...]

Please update your package to work with the current netpbm-free.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1010804: Segfault when applying this patch

[Martin Quinson]

package frogatto
tag 1010804 - patch
tag 1010804 + helpneeded
thanks

Hello,

I confirm that the package is not building without this patch, and that the
build proceeds with this patch. But the problem is that the code is segfaulting
systematically when I build the package with this patch. The failure occures
everytime I get out of the house, at the very beginning of the game (all
settings default).

At first I thought it was unrelated, but the valgrind trace is the following:

==549940== Jump to the invalid address stated on the next line
==549940==at 0x0: ???
==549940==by 0x5B62C4: water::draw_area(water::area const&, int, int, int, 
int) const (water.cpp:169)
==549940==by 0x5B6705: water::draw(int, int, int, int) const (water.cpp:125)
==549940==by 0x451763: level::draw(int, int, int, int) const 
(level.cpp:1930)
==549940==by 0x2FC8C9: render_scene(level const&, screen_position&, entity 
const*, bool) (draw_scene.cpp:358)
==549940==by 0x48753B: level_runner::play_cycle() (level_runner.cpp:1410)
==549940==by 0x488B33: level_runner::play_level() (level_runner.cpp:713)
==549940==by 0x1E341E: main (main.cpp:830)
==549940==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==549940== 
==549940== 
==549940== Process terminating with default action of signal 11 (SIGSEGV)
==549940==at 0x4DED07F: raise (raise.c:45)
==549940==by 0x4DED1FF: ??? (in 
/usr/lib/x86_64-linux-gnu/libpthread-2.33.so)

And the line pointed is the following:

#if defined(TARGET_OS_HARMATTAN) || defined(TARGET_PANDORA) || 
defined(TARGET_TEGRA) || defined(TARGET_BLACKBERRY)
if (glBlendEquationOES) {
glBlendEquationOES(GL_FUNC_REVERSE_SUBTRACT_OES);
}
#elif defined(GL_OES_blend_subtract)
glBlendEquationOES(GL_FUNC_REVERSE_SUBTRACT_OES);<-- HERE! 
THIS IS LINE 169
#elif defined(USE_GLES2)
glBlendEquation(GL_FUNC_REVERSE_SUBTRACT);
#else
if(GLEW_EXT_blend_equation_separate && (GLEW_ARB_imaging || 
GLEW_VERSION_1_4)) {
glBlendEquation(GL_FUNC_REVERSE_SUBTRACT);
} else {
const int max_color = std::max(water_color[0], 
std::max(water_color[1], water_color[2]));
water_color[0] = (max_color - water_color[0])/8;
water_color[1] = (max_color - water_color[1])/8;
water_color[2] = (max_color - water_color[2])/8;
}
#endif

So I feel bad about applying the patch and uploading the package to the archive.

Any help is welcomed. The package is uptodate on salsa.
Mt



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

Bug#1012691: nifti2dicom: Migration from vtk7 to vtk9

[Francois Mazen]

Package: nifti2dicom
Severity: wishlist
Tags: patch
X-Debbugs-Cc: franc...@mzf.fr

Dear Maintainer,

nifti2dicom package depends on vtk7 which is quite old and not maintained
upstream.

I've succeeded to build nifti2dicom with vtk9 by changing Build-Depends from
libvtk7-qt-dev to libvtk9-qt-dev and changing the QVTKWidget to
QVTKOpenGLNativeWidget class in src/gui/init.
A simple patch is attached to this message.

Could you please look at the patch and update to vtk9?

Thanks,

François
--- a/src/gui/init.h
+++ b/src/gui/init.h
@@ -31,7 +31,7 @@
 #include 
 #endif
 
-#include "QVTKWidget.h"
+#include "QVTKOpenGLNativeWidget.h"
 
 
 #include 
@@ -73,7 +73,7 @@
 QSlider*m_horizontalSlider;
 QLineEdit*  m_openedFileName;
 QLineEdit*  m_openedFileSizes;
-QVTKWidget* m_renderPreview;
+QVTKOpenGLNativeWidget* m_renderPreview;
 vtkImageViewer2*m_imageviewer;
 vtkKWImageIO*   m_reader;
 vtkKWImage* m_localVTKImage;
--- a/src/gui/init.cpp
+++ b/src/gui/init.cpp
@@ -65,7 +65,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "vtkKWImageIO.h"
 #include "vtkKWImage.h"
@@ -101,7 +101,7 @@
 m_horizontalSlider(new QSlider(Qt::Horizontal)),
 m_openedFileName(new QLineEdit()),
 m_openedFileSizes(new QLineEdit()),
-m_renderPreview(new QVTKWidget()),
+m_renderPreview(new QVTKOpenGLNativeWidget()),
 m_imageviewer(vtkImageViewer2::New()),
 m_reader(vtkKWImageIO::New()),
 m_localVTKImage(vtkKWImage::New()),
@@ -167,7 +167,8 @@
 #endif
 emptyImage->Delete();
 
-m_renderPreview->SetRenderWindow(m_imageviewer->GetRenderWindow());
+//m_renderPreview->setRenderWindow(m_imageviewer->GetRenderWindow());
+m_imageviewer->SetRenderWindow(m_renderPreview->renderWindow());
 
 m_imageviewer->SetSliceOrientationToXY();
 m_imageviewer->SetSlice(0);

Bug#1011646: libthrust: autopkgtest: please be more gentle on ci.d.n infrastructure

[Andreas Beckmann]

Hi Paul,

with the latest tuned autopkgtest versions of src:libthrust and src:cub
having migrated to testing, could you check whether these packages now
only put an "acceptable" load on the CI infrastructure?

(the src:nvidia-cuda-toolkit autopkgtest will be dropped with the next
upload, src:pycuda should have equivalent tests now while requiring no
extraordinary space to unpack :-)

Andreas

Bug#1011609: bogl-bterm: [PATCH] Several improvements

[Samuel Thibault]

Zhang Boyang, le ven. 10 juin 2022 17:00:16 +0900, a ecrit:
> Here is a patch for another bug. Please refer to the commit message for
> details.

Applied, thanks for your patches!

Samuel

Bug#1012692: missing dotlockfile warning not included in e-mail

[Marc Haber]

Package: cron-apt
Version: 0.13.0+nmu1
Severity: normal

Hi,

cron-apt correctly detects if the dotlockfile package is missing and
generates an error message. This causes the e-mail message to be
subjected as "CRON-APT error", but the actual error message does not
seem to end up in the message.

Greetings
Marc


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

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

Versions of packages cron-apt depends on:
ii  apt  2.2.4

Versions of packages cron-apt recommends:
ii  cron [cron-daemon] 3.0pl1-137
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
pn  liblockfile1   

cron-apt suggests no packages.

-- Configuration Files:
/etc/cron-apt/config changed [not included]
/etc/cron.d/cron-apt changed [not included]
/etc/logrotate.d/cron-apt changed [not included]

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/cron-apt/functions (from cron-apt package)

Bug#1012693: snmpd fails to install due to trying to chown an inexistent file

[Sergio Durigan Junior]

Source: net-snmp
Version: 5.9.1+dfsg-3
Severity: critical

Hi there,

snmpd is currently failing to install due to a problem with its postint
file:

--8<---cut here---start->8---
Setting up snmpd (5.9.1+dfsg-3) ...
adduser: Warning: The home directory `/var/lib/snmp' does not belong to the 
user you are currently creating.
chown: cannot access '/var/lib/snmp/snmpd.conf': No such file or directory
dpkg: error processing package snmpd (--configure):
 installed snmpd package post-installation script subprocess returned error 
exit status 1
Setting up libsnmp-perl (5.9.1+dfsg-3) ...
dpkg: dependency problems prevent configuration of autopkgtest-satdep:
 autopkgtest-satdep depends on snmpd; however:
  Package snmpd is not configured yet.
--8<---cut here---end--->8---

This has been introduced by the following commit:

  
https://salsa.debian.org/debian/net-snmp/-/commit/7f3bc627f40f99b232193efa0fb600c4be734c2b

As can be seen, the postinst script is trying to perform a chown on
"$SNMP_DIR/snmpd.conf", which doesn't exist when the package has just
been installed.

The fix is simple and I will file a Merge Request on salsa soon.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1012049: photofilmstrip: unable to add pictures

[Philipp Huebner]

Hi,

I can confirm this bug on current Debian Sid, Python 3.10 and
python3-wxgtk4.0 4.0.7.

Am 04.06.22 um 10:24 schrieb PhotoFilmStrip:

> As a quick fix you might edit the file
> "/home/gravis/pfs/photofilmstrip/gui/ImageSectionEditor.py" on line 675.
> Change the line:
> img = self._wxImg.Scale(width, height)
> to
> img = self._wxImg.Scale(int(round(width)), int(round(height)))

I tried that fix, it solves that issue but then another one pops up:

Traceback (most recent call last):
  File
"/usr/lib/python3/dist-packages/photofilmstrip/gui/PnlPfsProject.py",
line 501, in OnLvPicsSelectionChanged
self._OnPicsSelectionChanged(selItems, selPics)
  File
"/usr/lib/python3/dist-packages/photofilmstrip/gui/PnlSlideshow.py",
line 127, in _OnPicsSelectionChanged
self.bitmapLeft.SetSection(wx.Rect(*selPics[0].GetStartRect()))
TypeError: Rect(): arguments did not match any overloaded call:
  overload 1: too many arguments
  overload 2: argument 2 has unexpected type 'float'
  overload 3: argument 1 has unexpected type 'int'
  overload 4: argument 1 has unexpected type 'int'
  overload 5: argument 1 has unexpected type 'int'
  overload 6: argument 1 has unexpected type 'int'
Traceback (most recent call last):
  File
"/usr/lib/python3/dist-packages/photofilmstrip/gui/ImageSectionEditor.py",
line 221, in OnPaint
self.__DrawSection(dc)
  File
"/usr/lib/python3/dist-packages/photofilmstrip/gui/ImageSectionEditor.py",
line 150, in __DrawSection
sectRect = self.__SectRectToClientRect()
  File
"/usr/lib/python3/dist-packages/photofilmstrip/gui/ImageSectionEditor.py",
line 140, in __SectRectToClientRect
sectRect = wx.Rect(left + (self._sectRect.GetLeft() * self._zoom),
TypeError: Rect(): arguments did not match any overloaded call:
  overload 1: too many arguments
  overload 2: argument 1 has unexpected type 'float'
  overload 3: argument 1 has unexpected type 'float'
  overload 4: argument 1 has unexpected type 'float'
  overload 5: argument 1 has unexpected type 'float'
  overload 6: argument 1 has unexpected type 'float'


> I have a look at the issue myself and try to publish a fix.
Please ping me when that's done.


Best wishes
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012693: snmpd fails to install due to trying to chown an inexistent file

[Sergio Durigan Junior]

On Saturday, June 11 2022, I wrote:

> snmpd is currently failing to install due to a problem with its postint
> file:
>
> Setting up snmpd (5.9.1+dfsg-3) ...
> adduser: Warning: The home directory `/var/lib/snmp' does not belong to the 
> user you are currently creating.
> chown: cannot access '/var/lib/snmp/snmpd.conf': No such file or directory
> dpkg: error processing package snmpd (--configure):
>  installed snmpd package post-installation script subprocess returned error 
> exit status 1
> Setting up libsnmp-perl (5.9.1+dfsg-3) ...
> dpkg: dependency problems prevent configuration of autopkgtest-satdep:
>  autopkgtest-satdep depends on snmpd; however:
>   Package snmpd is not configured yet.
>
> This has been introduced by the following commit:
>
>   
> https://salsa.debian.org/debian/net-snmp/-/commit/7f3bc627f40f99b232193efa0fb600c4be734c2b
>
> As can be seen, the postinst script is trying to perform a chown on
> "$SNMP_DIR/snmpd.conf", which doesn't exist when the package has just
> been installed.
>
> The fix is simple and I will file a Merge Request on salsa soon.

MR: https://salsa.debian.org/debian/net-snmp/-/merge_requests/13

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1012694: ITP: data-generators-clojure

[Jérôme Charaoui]

Package: wnpp
Severity: wishlist
Owner: Jerome Charaoui 

   Package name : data-generators-clojure
   Version  : 1.0.0
   Upstream author  : Stuart Halloway 
   URL  : https://github.com/clojure/data.generators
   License  : EPL-1.0
   Programming Lang : Clojure
   Description  : Clojure library for generating random data

data.generators serves to generate random clojure data, and is often 
used as part of clojure code test suites.



Thanks,

-- Jerome

Bug#1012695: ITP: test-generative-clojure

[Jérôme Charaoui]

Package: wnpp
Severity: wishlist
Owner: Jerome Charaoui 

   Package name : test-generative-clojure
   Version  : 1.0.0
   Upstream author  : Stuart Halloway 
   URL  : https://github.com/clojure/test.generative
   License  : EPL-1.0
   Programming Lang : Clojure
   Description  : Generative test framework for Clojure

test.generative is a test framework for Clojure that serves to 
automatically generate test cases and validate the properties of the 
output instead of values.



Thanks,

-- Jerome

Bug#1012696: ITP: blaeu -- Tools to create (and analyze) RIPE Atlas network measurements

[Sebastien Badia]

Package: wnpp
Severity: wishlist
Owner: Sebastien Badia 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: blaeu
  Version : 1.1.8
  Upstream Author : Stéphane Bortzmeyer 
* URL : https://framagit.org/bortzmeyer/blaeu
* License : BSD
  Programming Lang: Python
  Description : Tools to create (and analyze) RIPE Atlas network
measurements

Blaeu is a set of Python programs to start distributed Internet measurements
on the network of RIPE Atlas probes , and to analyze
their results.

Packaging is almost ready here https://salsa.debian.org/debian/blaeu

Bug#1012695: Processed: ITP: test-generative-clojure

[Jérôme Charaoui]

Le 2022-06-11 à 18 h 57, Debian Bug Tracking System a écrit :

Processing commands for cont...@bugs.debian.org:


close 1012695

Bug #1012695 [wnpp] ITP: test-generative-clojure
Marked Bug as done

stop

Stopping processing here.


This ITP was closed, but no reason was given. To the best of my 
knowledge, the test.generative library is not in Debian, and is 
DFSG-compatible licensed.


Was this closed by accident, or is there some other explanation?

Thanks.

Bug#1012695: Processed: ITP: test-generative-clojure

[Jérôme Charaoui]

Le 2022-06-11 à 19 h 15, Jérôme Charaoui a écrit :


Le 2022-06-11 à 18 h 57, Debian Bug Tracking System a écrit :

Processing commands for cont...@bugs.debian.org:


close 1012695

Bug #1012695 [wnpp] ITP: test-generative-clojure
Marked Bug as done

stop

Stopping processing here.


This ITP was closed, but no reason was given. To the best of my 
knowledge, the test.generative library is not in Debian, and is 
DFSG-compatible licensed.


Was this closed by accident, or is there some other explanation?


OK now I see this was already filed as RFP #1010995.

Sorry for the duplicate.

Bug#1011305: closing 1011305

[Sebastien Badia]

On Thu, Jun 09, 2022 at 12:34:28PM (+0200), Paul Gevers wrote:
> Control: severity -1 normal
> 
> Hi,
> 
> On Mon, 06 Jun 2022 23:32:55 +0200 Sebastien Badia 
> wrote:> Just fixed this in the latest upload, but I used the wrong keyword
> in my changelog entry.
> 
> Thanks for fixing this bug. However, in the mean time the maintainer of
> luajit found an alternative solution (by introducing an alternative luajit
> source package called luajit2). See transition bug #1012362).
> 
> So, if you want to you can add support for luajit on ppc64el (and now on
> s390x too) back to your package. Sorry for the extra work this bug caused,
> but when I filed it it wasn't clear on what timescale this would happen and
> if it would work out.
> 
> Paul

Hi Paul,

No worries, thanks you for the feedback !
I take a look on luajit2 and #1012362

Have a good day,

Sebastien


signature.asc
Description: PGP signature

Bug#1012697: libffi: Source URL change not documented

[Bastian Germann]

Source: libffi
Version: 3.4.2-4

The documented source URL ftp://sourceware.org/pub/libffi/ is not valid for the 
current version 3.4.2.
Sourceware does not have any 3.4.x version. Please change the d/watch and 
d/copyright file to present
the right source URL, which is most probably 
https://github.com/libffi/libffi/releases

Bug#925473: Tomcat 9 requires Systemd

[Thorsten Glaser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384

Instructions back to the list, in case this is of more general interest.

Dixi quod…

>>What is your opinion about staying current with security updates for
>>this specifically crafted package?
>
>If I know I have users I can stay on top of other updates with this
>package. For simplicity I’d probably follow uploads to unstable and
>rebuild these, with the sysvinit patchset added, within bullseye; I

I’ve done that and I’ll keep up with Markus’ uploads to sid as much
as possible. (I even had to add a patch to make it buildable on
bullseye already, but then the bullseye-security upload is going to
need that exact patch, too.)

>have successfully used the binary packages coming from that as well
>on a buster system, so this should cover three releases.

I have indeed tested the latest version on buster, and it works.
Though, my testing is (currently) really minimal as I’m not in a
Java project at the moment. Nevertheless, my employer, ⮡ tarent,
has sponsored some of my time working on this project again.

>One thing I have already done is to “split” the packages in my APT
>repo so that those I consider “LTS” are available without pulling

The repository is available at http://www.mirbsd.org/~tg/Debs/
though the https on that server is TLSv1 only, which your browser
may not like without reconfiguration so I’ve set up a mirror at
https://caas.mirbsd.org:444/Debs/ (actually the latter is just a
view of the main repo storage on the box, so it’ll be inconsistent
during package updates for a longer time, say an half hour or so,
instead of just for a few seconds as the first URL, but it’s good
to obtain the PGP key, for example, using https as extra trust-y
anchor; the repo/packages themselves use Secure APT via PGP anyway).

Let’s discuss enabling the repository first.

If you use the “extrepo” package, it’s as easy as enabling the
“wtf-lts” repo, if you’re on buster or bullseye. If you’re on
bookworm/testing or sid, you’ll currently need to set up the
full “wtf” repository with sid as release; since you wrote you’ll
use pinning anyway, this should not be a problem.

If you don’t use the “extrepo” package, you’ll need to first let
apt know the PGP key. The “modern” but pre-bookworm way is to get
https://caas.mirbsd.org:444/Debs/wtf-debian-keyring.gpg and
https://caas.mirbsd.org:444/Debs/wtf-debian-keyring.gpg.asc then
use the latter with my Debian Developer key to verify the former.
My DD key is shipped in the package debian-keyring, and I’m using
it to sign this message, too. You can for example do:
$ gpg --keyring /usr/share/keyrings/debian-keyring.gpg \
wtf-debian-keyring.gpg.asc
Once verified, place wtf-debian-keyring.gpg into /etc/apt/trusted.gpg.d/
(however, see below regarding the keyring packagre) and as next step, add
an appropriate sources.list(.d) line, such as:
 deb http://www.mirbsd.org/~tg/Debs/ bullseye lts

The bookworm way is to load https://caas.mirbsd.org:444/Debs/wtf.sources
(and .asc again) instead and place that into /etc/apt/sources.list.d/
and it will replace *both* the trusted key *and* the sources.list entry
by placing the key with the entry in the new “long” format, so it’s only
used for this repository. This doesn’t yet work in bullseye, AFAIK :/

Neither will get you auto-updates for the key. See below for that.

>in other “alternative” versions of packages, so it can safely be
>added to most systems. The current set of packages for bullseye is:

You wrote you need only tomcat and prefer pinning. You can do pinning;
basically, you need to pin down all packages from the repository except
the binary packages from the tomcat9 source package, which are:
 libtomcat9-embed-java deb java optional arch=all
 libtomcat9-java deb java optional arch=all
 tomcat9 deb java optional arch=all
 tomcat9-admin deb java optional arch=all
 tomcat9-common deb java optional arch=all
 tomcat9-docs deb doc optional arch=all
 tomcat9-examples deb java optional arch=all
 tomcat9-user deb java optional arch=all

I’ve not had much success with pinning myself, other than to tell apt
to never install systemd at all, and to force specific versions for
packages. But maybe you figure it out and will share it for everyone?

The repository (independent of whether you use the lts or wtf component)
uses the following identification:

Origin: The MirOS Project
Label: wtf
Suite: bullseye or sid etc…
Codename: bullseye or sid etc…

So I think you should be able to pin with o= (space might be tricky)
and l= according to apt_preferences(5)… anyway, do tell us if it works
(otherwise, we’ll need to prod at it together, until it’s going to).

>• wtf-debian-keyring (the keyring package for this repo)

You wrote:
|Keyring behavior has been changed (to be more cumbersome for an user, I
|think) on Bullseye. Does this still work?

It does. This package still uses the “oldold” way, in that apt-key(8)
is called from postinst. It warns loudly about that. (It might no longer
work on book

Bug#1012698: librhash0 should no longer recommend libssl1.1 due to the OpenSSL 3 transition

[Vincent Lefevre]

Package: librhash0
Version: 1.4.2-1
Severity: serious

librhash0 should no longer recommend libssl1.1 due to the OpenSSL 3
transition.

BTW, librhash0 just provides /usr/lib/x86_64-linux-gnu/librhash.so.0,
which doesn't appear to use any libssl. Moreover,

  strings -a /usr/lib/x86_64-linux-gnu/librhash.so.0 | grep -i ssl

outputs nothing.

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

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

Versions of packages librhash0 depends on:
ii  libc6  2.33-7

Versions of packages librhash0 recommends:
ii  libssl1.1  1.1.1o-1

librhash0 suggests no packages.

-- no debconf information

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

Bug#1012698: librhash0 should no longer recommend libssl1.1 due to the OpenSSL 3 transition

[Vincent Lefevre]

On 2022-06-12 03:20:59 +0200, Vincent Lefevre wrote:
> librhash0 should no longer recommend libssl1.1 due to the OpenSSL 3
> transition.
> 
> BTW, librhash0 just provides /usr/lib/x86_64-linux-gnu/librhash.so.0,
> which doesn't appear to use any libssl. Moreover,
> 
>   strings -a /usr/lib/x86_64-linux-gnu/librhash.so.0 | grep -i ssl
> 
> outputs nothing.

Well, this actually seems to be due to libcrypto:

zira:~> strings -a /usr/lib/x86_64-linux-gnu/librhash.so.0 | grep -i libcrypto
libcrypto.so
libcrypto.so.1.1
libcrypto.so.1.0.2
libcrypto.so.1.0.0
libcrypto.so.0.9.8

Anyway, with the transition, this is now wrong.

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

Bug#1012699: ntpsec: ntpleapfetch broken, which one notices as leap-seconds.list is expiring soon

[maney]

Package: ntpsec
Version: 1.2.0+dfsg1-4
Severity: important
Tags: patch

Bug also in ntp package.

There's a stupid bug in ntpleapfetch that mangles the hash extracted
from the leapsecond files and therefore calls them all invalid.  To
see the failure, just run ntpleapfetch, notice that you get something
like this:

ERROR: EXPECTED:  599d45bf accd4b4f 08b60e46 0049b6237d13b825  
  
ERROR: COMPUTED: 599d45bfaccd4b4f08b60e460049b6237d13b825

Notice that EXPECTED is the wrong size and contains the actual checksum
padded with spurious zeroes.  The fix is simple, and involves adding the
handling for the space/tab(s) preceeding the checksum in the leap-seconds
file.  The comment which *says* it does that has been a lie for a while...

https://u25039542.ct.sendgrid.net/ls/click?upn=0O5yqPC0YgKzANBXFSRMGSiEz6GGG23ysiD-2FussQkApJD0NH1WOf2uFjHAXNEY0fjcYg7q4yWb-2Bb50shbm07WSofjbTDMcpXBr633DkGTJLAD4HxwxtnyY-2F0SlXWO3rZRlMN_kfytytOqXJMoRhb2oyNeM0XjBzsVuOf-2Bk81owLo9uR-2B2kXug4z3VJ6xmun8YzmRwJEABwoZMEaODHYdDXZpq7gckxhKBLMDAQ9Kh-2BYTFPI6d0BB-2BySc9uYbJ8TLDM5zu6G8qN-2Bm3PA2a8nOEoa9gezVr10eR-2FhvOD2r9QUAACcDNc2jeA2p2USKt4ePfV1KzbDbtJ23lErkEm6l9LqiipFAqwuzd3cqM-2BssHjUaZ1Ec-3D

And that's that, aside from the obscurity of the ntpleapfetch command,
which I have never before had reason to "discover" in a few decades of
running ntp[sec] on various machines.

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

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

Versions of packages ntpsec depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libbsd0  0.11.3-1
ii  libc62.31-13+deb11u3
ii  libcap2  1:2.44-1
ii  libssl1.11.1.1n-0+deb11u2
ii  lsb-base 11.1.0
ii  netbase  6.3
ii  python3  3.9.2-3
ii  python3-ntp  1.2.0+dfsg1-4
ii  tzdata   2021a-1+deb11u2

Versions of packages ntpsec recommends:
ii  cron [cron-daemon]  3.0pl1-137
ii  systemd 247.3-7

Versions of packages ntpsec suggests:
ii  apparmor   2.13.6-10
pn  certbot
ii  ntpsec-doc 1.2.0+dfsg1-4
ii  ntpsec-ntpviz  1.2.0+dfsg1-4

-- Configuration Files:
/etc/default/ntpsec changed [not included]
/etc/letsencrypt/renewal-hooks/deploy/ntpsec [Errno 2] No such file or 
directory: '/etc/letsencrypt/renewal-hooks/deploy/ntpsec'
/etc/ntpsec/ntp.conf changed [not included]

-- no debconf information

Bug#1012565: libecap3: ftbfs on riscv64 (error: some symbols or patterns disappeared in the symbols file)

[肖盛文]

control: tags -1 + patch

Hi,

    I do the update for the libecap3.symbols to fix the issue,

please see the attachments file libecap3.symbols.

I referred: https://www.eyrie.org/~eagle/journal/2012-01/008.html

Run the following commands to get the newest libecap3.symbols:

pkgkde-getbuildlogs

pkgkde-symbolshelper batchpatch -v 1.0.1 libecap_unstable_logs/*


I'd test it on my amd64, arm64 and risv64 machine, all build passed.

Welcome to review it and test build in your machine.

Is need to do the NMU on  experimental to test other arches?


在 2022/6/9 22:02, Bo YU 写道:

[...]

maybe it needs update the libecap3.symbols to fix the issue. refer to[0]
and [1]. Thank you.


Thanks!

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

# SymbolsHelper-Confirmed: 1.0.1 amd64 arm64 armel armhf i386 mips64el mipsel 
powerpc ppc64el riscv64 s390x
libecap.so.3 libecap3 #MINVER#
 _ZN7libecap10methodHeadE@Base 1.0.1
 _ZN7libecap10methodPostE@Base 1.0.1
 _ZN7libecap11metaVirusIdE@Base 1.0.1
 _ZN7libecap11methodTraceE@Base 1.0.1
 _ZN7libecap11protocolFtpE@Base 1.0.1
 _ZN7libecap11protocolUrnE@Base 1.0.1
 _ZN7libecap12RegisterHostERKNSt3tr110shared_ptrINS_4host4HostEEE@Base 1.0.1
 _ZN7libecap12metaClientIpE@Base 1.0.1
 _ZN7libecap12metaServerIpE@Base 1.0.1
 _ZN7libecap12metaUserNameE@Base 1.0.1
 _ZN7libecap12methodDeleteE@Base 1.0.1
 _ZN7libecap12protocolHttpE@Base 1.0.1
 _ZN7libecap12protocolWaisE@Base 1.0.1
 
_ZN7libecap13TextExceptionC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPKci@Base
 1.0.1
 
_ZN7libecap13TextExceptionC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPKci@Base
 1.0.1
 _ZN7libecap13TextExceptionD0Ev@Base 1.0.1
 _ZN7libecap13TextExceptionD1Ev@Base 1.0.1
 _ZN7libecap13TextExceptionD2Ev@Base 1.0.1
 _ZN7libecap13VersionStringEv@Base 1.0.1
 _ZN7libecap13headerRefererE@Base 1.0.1
 _ZN7libecap13methodConnectE@Base 1.0.1
 _ZN7libecap13methodOptionsE@Base 1.0.1
 _ZN7libecap13protocolHttpsE@Base 1.0.1
 _ZN7libecap13protocolWhoisE@Base 1.0.1
 _ZN7libecap14protocolGopherE@Base 1.0.1
 _ZN7libecap15RegisterServiceEPNS_7adapter7ServiceE@Base 1.0.1
 _ZN7libecap15headerXClientIpE@Base 1.0.1
 _ZN7libecap15headerXServerIpE@Base 1.0.1
 _ZN7libecap16metaNextServicesE@Base 1.0.1
 _ZN7libecap16metaResponseDescE@Base 1.0.1
 _ZN7libecap16metaResponseInfoE@Base 1.0.1
 _ZN7libecap16metaSubscriberIdE@Base 1.0.1
 _ZN7libecap19headerContentLengthE@Base 1.0.1
 _ZN7libecap20StdStringAreaDetailsD0Ev@Base 1.0.1
 _ZN7libecap20StdStringAreaDetailsD1Ev@Base 1.0.1
 _ZN7libecap20StdStringAreaDetailsD2Ev@Base 1.0.1
 _ZN7libecap21metaAuthenticatedUserE@Base 1.0.1
 _ZN7libecap22headerTransferEncodingE@Base 1.0.1
 _ZN7libecap23metaAuthenticatedGroupsE@Base 1.0.1
 _ZN7libecap24RegisterVersionedServiceEPNS_7adapter7ServiceEPKc@Base 1.0.1
 (arch-bits=32)_ZN7libecap4Area14FromTempBufferEPKcj@Base 1.0.1
 (arch-bits=64)_ZN7libecap4Area14FromTempBufferEPKcm@Base 1.0.1
 
_ZN7libecap4Area14FromTempStringERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 1.0.1
 _ZN7libecap4Name6NextIdEv@Base 1.0.1
 _ZN7libecap4Name9TheLastIdE@Base 1.0.1
 _ZN7libecap4NameC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 
1.0.1
 
_ZN7libecap4NameC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi@Base 
1.0.1
 _ZN7libecap4NameC1Ev@Base 1.0.1
 _ZN7libecap4NameC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 
1.0.1
 
_ZN7libecap4NameC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi@Base 
1.0.1
 _ZN7libecap4NameC2Ev@Base 1.0.1
 _ZN7libecap4NameD1Ev@Base 1.0.1
 _ZN7libecap4NameD2Ev@Base 1.0.1
 _ZN7libecap5ThrowEPKcS1_i@Base 1.0.1
 _ZN7libecap5nsizeE@Base 1.0.1
 _ZN7libecap6MyHostEv@Base 1.0.1
 _ZN7libecap7Message10addTrailerEv@Base 1.0.1
 _ZN7libecap7Message7trailerEv@Base 1.0.1
 _ZN7libecap7adapter7Service4stopEv@Base 1.0.1
 _ZN7libecap7adapter7Service5startEv@Base 1.0.1
 _ZN7libecap7adapter7Service6resumeEv@Base 1.0.1
 _ZN7libecap7adapter7Service6retireEv@Base 1.0.1
 _ZN7libecap7adapter7Service7suspendER7timeval@Base 1.0.1
 _ZN7libecap7adapter7Xaction6resumeEv@Base 1.0.1
 _ZN7libecap7adapter7Xaction7abPauseEv@Base 1.0.1
 _ZN7libecap7adapter7Xaction8abResumeEv@Base 1.0.1
 _ZN7libecap9headerViaE@Base 1.0.1
 _ZN7libecap9methodGetE@Base 1.0.1
 _ZN7libecap9methodPutE@Base 1.0.1
 _ZN7libecaplsERSoRKNS_4AreaE@Base 1.0.1
 _ZNK7libecap13TextException4whatEv@Base 1.0.1
 _ZNK7libecap13TextException5printERSo@Base 1.0.1
 _ZNK7libecap4Area8toStringB5cxx11Ev@Base 1.0.1
 _ZNK7libecap4Name12assignHostIdEi@Base 1.0.1
 _ZNK7libecap4Name14assignedHostIdEv@Base 1.0.1
 _ZNK7libecap7Message7trailerEv@Base 1.0.1
 _ZNK7libecap7adapter7Service18makesAsyncXactionsEv@Base 1.0.1
 _ZNK7libecap8BodySize7badSizeEv@Base 1.0.1
 (optional=templinst)_ZNSt3tr110shared_ptrIN7libecap4host4HostEED1Ev@Base 1.0.1
 (optional=templinst)_ZNSt3tr110shared_ptrIN7

Bug#1011697: wxpython4.0: FTBFS with SIP 6.6

[Scott Talbert]

On Sat, 11 Jun 2022, Sebastiaan Couwenberg wrote:


Upstream has changes to fix building with SIP 6.6:

https://github.com/wxWidgets/Phoenix/pull/2179

But this is blocked because there is no SIP 6.6.2 release yet with many fixes 
for the new ply based parser.


Yes, Phil (sip upstream maintainer) said that he plans a new sip release 
next week when the new version of Qt comes out.


Scott

Bug#1012701: ITP golang-github-cretz-bine -- Go library for accessing and embedding Tor clients and servers

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-cretz-bine
  Version : 0.2.0+ds-1
  Upstream Author : Chad Retz
* URL : https://github.com/cretz/bine
* License : Expat
  Programming Lang: Go
  Description : Go library for accessing and embedding Tor clients and 
servers
 Bine is a Go API for using and controlling Tor. It is similar to Stem
 and has the following features:
 .
  * Full support for the Tor controller API
  * Support for net.Conn and net.Listen style APIs
  * Supports statically compiled Tor to embed Tor into the binary
  * Supports both v2 and v3 onion services
  * Support for embedded control socket in Tor >= 0.3.5 (non-Windows)


signature.asc
Description: PGP signature

Bug#1012699: ntpleapfetch broken

[Martin Maney]

Correction: does not apply to ntp package.  I seem to have looked for
it on the wrong machine (one that was in fact using ntpsec).

And apologies for the link munging - I've been forced to route through
sendgrid ever since the connection here was upgraded to fiber, and
despite repeated claims to the contrary, it does block outbound SMTP.
The fix is in commit a0e5e050dfbdb672459f74bf52562bc8fc50c3b9 in
ntpsec's github repo.

-- 
The only non-renewable resource you truly have
is your time.  -- Clay Johnson

Bug#1012565: libecap3: ftbfs on riscv64 (error: some symbols or patterns disappeared in the symbols file)

[Bo YU]

Hi,
On Sun, Jun 12, 2022 at 10:31:02AM +0800, xiao sheng wen(肖盛文) wrote:

control: tags -1 + patch

Hi,

    I do the update for the libecap3.symbols to fix the issue,

please see the attachments file libecap3.symbols.

I referred: https://www.eyrie.org/~eagle/journal/2012-01/008.html

Run the following commands to get the newest libecap3.symbols:

pkgkde-getbuildlogs

pkgkde-symbolshelper batchpatch -v 1.0.1 libecap_unstable_logs/*


thank you. I got it from here.



I'd test it on my amd64, arm64 and risv64 machine, all build passed.

Welcome to review it and test build in your machine.

Is need to do the NMU on  experimental to test other arches?


Yeah, This package has not been maintained for a long time.

Bo


signature.asc
Description: PGP signature

Bug#1012699: ntpleapfetch broken

[Richard Laager]

[Responding on mobile.] I’ll take a look at it, as obviously it should be made 
to work. But on Debian, there shouldn’t be a need for ntpleapfetch, as the 
tzdata package ships the leap second file.

-- 
Richard

> On Jun 11, 2022, at 22:33, Martin Maney  wrote:
> 
> 
> Correction: does not apply to ntp package.  I seem to have looked for
> it on the wrong machine (one that was in fact using ntpsec).
> 
> And apologies for the link munging - I've been forced to route through
> sendgrid ever since the connection here was upgraded to fiber, and
> despite repeated claims to the contrary, it does block outbound SMTP.
> The fix is in commit a0e5e050dfbdb672459f74bf52562bc8fc50c3b9 in
> ntpsec's github repo.
> 
> -- 
> The only non-renewable resource you truly have
> is your time.  -- Clay Johnson

Bug#768073: "ping!"

[Matt Barry]

Hi,

I imagine I arrived at this bug the same way a lot of folks did, trying
to sleuth out the reason why (e.g.) autopkgtest-build-lxd is broken in
Debian.. but perhaps I might be the first that read all the way to the
end to find a repo that builds somewhat working packages!  Kudos and
thanks!

What is the state of the packages at the moment?  Are there any areas
that need help or testing?  (I'm not a go expert, but happy to help out
if I can.)

Cheers,
Matt


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

Bug#1012702: rust-libsystemd: FTBFS in unstable

[Steve Langasek]

Source: rust-libsystemd
Version: 0.2.1-3
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Dear maintainers,

rust-libsystemd fails to build in unstable.  It's not clear to me from a
build log which of its build-dependencies has triggered this failure.

[...]
 Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=libsystemd 
CARGO_MANIFEST_DIR=/tmp/rust-libsystemd-0.2.1 CARGO_PKG_AUTHORS='Luca Bruno 
' CARGO_PKG_DESCRIPTION='A pure-Rust client library to 
interact with systemd' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE=MIT/Apache-2.0 
CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=libsystemd 
CARGO_PKG_REPOSITORY='https://github.com/lucab/libsystemd-rs' 
CARGO_PKG_VERSION=0.2.1 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=2 
CARGO_PKG_VERSION_PATCH=1 CARGO_PKG_VERSION_PRE='' CARGO_PRIMARY_PACKAGE=1 
LD_LIBRARY_PATH='/tmp/rust-libsystemd-0.2.1/target/debug/deps:/usr/lib' rustc 
--crate-name libsystemd --edition=2018 src/lib.rs --error-format=json 
--json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link 
-C embed-bitcode=no -C debuginfo=2 -C metadata=391c7be326d65e00 -C 
extra-filename=-391c7be326d65e00 --out-dir 
/tmp/rust-libsystemd-0.2.1/target/x86_64-unknown-linux-gnu/debug/deps --target 
x86_64-unknown-linux-gnu -C 
incremental=/tmp/rust-libsystemd-0.2.1/target/x86_64-unknown-linux-gnu/debug/incremental
 -L 
dependency=/tmp/rust-libsystemd-0.2.1/target/x86_64-unknown-linux-gnu/debug/deps
 -L dependency=/tmp/rust-libsystemd-0.2.1/target/debug/deps --extern 
error_chain=/tmp/rust-libsystemd-0.2.1/target/x86_64-unknown-linux-gnu/debug/deps/liberror_chain-15dd2f8bde382f75.rmeta
 --extern 
hmac=/tmp/rust-libsystemd-0.2.1/target/x86_64-unknown-linux-gnu/debug/deps/libhmac-0d9d3a82e1ccf65d.rmeta
 --extern 
libc=/tmp/rust-libsystemd-0.2.1/target/x86_64-unknown-linux-gnu/debug/deps/liblibc-2459bf3735a2a015.rmeta
 --extern 
nix=/tmp/rust-libsystemd-0.2.1/target/x86_64-unknown-linux-gnu/debug/deps/libnix-9a5d1ba2327a249a.rmeta
 --extern 
serde=/tmp/rust-libsystemd-0.2.1/target/x86_64-unknown-linux-gnu/debug/deps/libserde-d5817db1ffae001f.rmeta
 --extern 
sha2=/tmp/rust-libsystemd-0.2.1/target/x86_64-unknown-linux-gnu/debug/deps/libsha2-6cae8de9ca2e7dd5.rmeta
 --extern 
uuid=/tmp/rust-libsystemd-0.2.1/target/x86_64-unknown-linux-gnu/debug/deps/libuuid-ebba74dd0d63f470.rmeta
 -C debuginfo=2 --cap-lints warn -C linker=x86_64-linux-gnu-gcc -C 
link-arg=-Wl,-z,relro --remap-path-prefix 
/tmp/rust-libsystemd-0.2.1=/usr/share/cargo/registry/libsystemd-0.2.1`
warning: use of deprecated enum `nix::sys::socket::SockAddr`: use SockaddrLike 
or SockaddrStorage instead
 --> src/activation.rs:3:23
  |
3 | use nix::sys::socket::SockAddr;
  |   
  |
  = note: `#[warn(deprecated)]` on by default

warning: use of deprecated variant `nix::sys::socket::SockAddr::Inet`: use 
SockaddrLike or SockaddrStorage instead
   --> src/activation.rs:177:34
|
177 | if let SockAddr::Inet(_) = addr {
|  

warning: use of deprecated variant `nix::sys::socket::SockAddr::Unix`: use 
SockaddrLike or SockaddrStorage instead
   --> src/activation.rs:190:34
|
190 | if let SockAddr::Unix(_) = addr {
|  

warning: use of deprecated enum `nix::sys::socket::SockAddr`: use SockaddrLike 
or SockaddrStorage instead
 --> src/logging.rs:4:59
  |
4 | use nix::sys::socket::{sendmsg, ControlMessage, MsgFlags, SockAddr};
  |   

warning: use of deprecated enum `nix::sys::socket::SockAddr`: use SockaddrLike 
or SockaddrStorage instead
   --> src/logging.rs:152:16
|
152 | let path = SockAddr::new_unix(SD_JOURNAL_SOCK_PATH)?;
|

warning: use of deprecated field `nix::sys::socket::SockAddr::Inet::0`: use 
SockaddrLike or SockaddrStorage instead
   --> src/activation.rs:177:39
|
177 | if let SockAddr::Inet(_) = addr {
|   ^

warning: use of deprecated field `nix::sys::socket::SockAddr::Unix::0`: use 
SockaddrLike or SockaddrStorage instead
   --> src/activation.rs:190:39
|
190 | if let SockAddr::Unix(_) = addr {
|   ^

error[E0308]: mismatched types
   --> src/activation.rs:201:20
|
201 | mq_getattr(*self).is_ok()
|^ expected `&MqdT`, found `i32`

For more information about this error, try `rustc --explain E0308`.
warning: `libsystemd` (lib) generated 7 warnings
error: could not compile `libsystemd` due to previous error; 7 warnings emitted
[...]

  (https://launchpad.net/ubuntu/+source/rust-libsystemd/0.2.1-3/+build/23812417)

The above link is to an Ubuntu build log, but I've confirmed the build
failure is also reproducible in sid.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian 

Bug#1002553: firmware-amd-graphics: Memory clock always at 100% (thinkpads w/ryzen 3XXXu)

[ng]

Hi,  I went on and installed the respective image from 
https://snapshot.debian.org/package/linux/5.10.46-5/#linux-image-5.10.0-8-amd64-unsigned_5.10.46-5 
and had no luck,  no change whatsoever.


Later next week I'll try running Fedora or Arch on a different drive to 
see if it has been corrected on the firmware/kernel side, like the git said.


El 10/06/22 a las 10:57, Diederik de Haas escribió:

Could you try *downgrading* your kernel to 5.10.46-5, to be found here:
https://snapshot.debian.org/package/linux/5.10.46-5/#linux-image-5.10.0-8-amd64-unsigned_5.10.46-5

The reason for this is https://bugs.debian.org/990312 with a possible 
similar

cause and therefor solution, which was part of 5.10.46-3.

The fix was reverting 2 commits wrt 'CP_MEC_DOORBELL_RANGE' and in
kernel 5.10.61 there was another commit related to that, and I'd like 
to know

if that caused a regression. I don't expect it, but it's better to verify.

The symptom of bug 990312 were easy to detect with:
cat /sys/class/drm/card0/device/gpu_busy_percent

Bug#1012703: vtk9: FTBFS with NetCDF 4.9.0 (error: expected identifier or '(' before numeric constant)

[Bas Couwenberg]

Source: vtk9
Version: 9.1.0+really9.1.0+dfsg2-3
Severity: serious
Tags: ftbfs

Dear Maintainer,

Your package FTBFS with NetCDF 4.9.0:

[  2%] Building C object 
ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_utils.c.o
cd 
/build/vtk9-9.1.0+really9.1.0+dfsg2/debian/build/ThirdParty/exodusII/vtkexodusII
 && /usr/bin/mpicc -DH5_BUILT_AS_DYNAMIC_LIB -DMPICH_SKIP_MPICXX 
-DMPI_NO_CPPBIND -DOMPI_SKIP_MPICXX -DVTK_IN_VTK -DVTK_MODULE_ENABLE_VTK_mpi=1 
-D_MPICC_
H -DexoIIc_EXPORTS -DexodusII_EXPORTS 
-I/build/vtk9-9.1.0+really9.1.0+dfsg2/debian/build/ThirdParty/exodusII/vtkexodusII
 -I/build/vtk9-9.1.0+really9.1.0+dfsg2/ThirdParty/exodusII/vtkexodusII 
-I/build/vtk9-9.1.0+really9.1.0+dfsg2/ThirdPa
rty/exodusII/vtkexodusII/include 
-I/build/vtk9-9.1.0+really9.1.0+dfsg2/debian/build/ThirdParty/exodusII/vtkexodusII/include
 -isystem /build/vtk9-9.1.0+really9.1.0+dfsg2/debian/build/ThirdParty/exodusII 
-isystem /build/vtk9-9.1.0+really9
.1.0+dfsg2/ThirdParty/exodusII -isystem 
/build/vtk9-9.1.0+really9.1.0+dfsg2/debian/build/ThirdParty/hdf5 -isystem 
/build/vtk9-9.1.0+really9.1.0+dfsg2/ThirdParty/hdf5 -isystem 
/usr/include/hdf5/serial -isystem /build/vtk9-9.1.0+really9.1
.0+dfsg2/debian/build/ThirdParty/netcdf -isystem 
/build/vtk9-9.1.0+really9.1.0+dfsg2/ThirdParty/netcdf -isystem 
/build/vtk9-9.1.0+really9.1.0+dfsg2/debian/build/Utilities/MPI -isystem 
/build/vtk9-9.1.0+really9.1.0+dfsg2/Utilities/MPI -g
 -O2 -ffile-prefix-map=/build/vtk9-9.1.0+really9.1.0+dfsg2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -O2 -g -DNDEBUG -fPIC -std=gnu99 -MD -MT 
ThirdParty/exodusII/vtkexodusII/CMakeFiles/
exodusII.dir/src/ex_utils.c.o -MF CMakeFiles/exodusII.dir/src/ex_utils.c.o.d -o 
CMakeFiles/exodusII.dir/src/ex_utils.c.o -c 
/build/vtk9-9.1.0+really9.1.0+dfsg2/ThirdParty/exodusII/vtkexodusII/src/ex_utils.c
In file included from 
/build/vtk9-9.1.0+really9.1.0+dfsg2/debian/build/ThirdParty/netcdf/vtk_netcdf.h:22,
 from 
/build/vtk9-9.1.0+really9.1.0+dfsg2/ThirdParty/exodusII/vtkexodusII/include/exodusII.h:22,
 from 
/build/vtk9-9.1.0+really9.1.0+dfsg2/ThirdParty/exodusII/vtkexodusII/src/ex_utils.c:20:
/build/vtk9-9.1.0+really9.1.0+dfsg2/ThirdParty/exodusII/vtkexodusII/src/ex_utils.c:
 In function 'vtkexodusII_ex__compress_variable':
/build/vtk9-9.1.0+really9.1.0+dfsg2/ThirdParty/exodusII/vtkexodusII/src/ex_utils.c:1773:19:
 error: expected identifier or '(' before numeric constant
 1773 | const int NC_SZIP_NN = 32;  /* Selects nearest neighbor 
coding method for szip. */
  |   ^~

In NetCDF 4.9.0 NC_SZIP_NN and other are defined in netcdf.h:

 #define NC_SZIP_NN 32 /**< SZIP NN option mask. */

paraview has the same issue: #1012663.

Kind Regards,

Bas

Bug#1012655: upstream bug and fix

[Stephan Verbücheln]

They merged it (on June 7) into kernel 5.19, but kernel 5.18.3
(released June 9) does not seem to have it yet.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/?id=v5.18.3&id2=v5.18&dt=2

I will just use 5.17 or external mouse until the fix lands in Sid.

Thank you and regards