Bug#1023842: rust-criterion - inconsistent dependencies on cast.

[Jonas Smedegaard]

Quoting Peter Green (2022-11-12 01:16:23)
> On 11/11/2022 16:02, Jonas Smedegaard wrote:
> 
> > 
> > My work on other packages (rust-test-case) recently revealed that my
> > approach to embedding crates is broken, so I will do some more poking to
> > get it to not only succeed building on its own but also builds as
> > dependency of other Rust crates.
> 
> Note that criterion-plot is packaged in Debian, so an alternative way
> to fix this would be to stop embedding it and use the packaged version.

Ahhh, *that* is probably why this bug wasn't caught earlier: Other
packages simply pull in the separately packaged version.

Thanks for pointing that out :-)

I do think, however, that the better approach is for rust-criterion to
take over that other binary package, since it is part of same upstream
source project (yes, I am aware that the Rust project has a different
approach...).  I'll think on it and fie a separate bugreport about that
unless I change my mind - i.e. let's not discuss that further here.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature

Bug#1022943: Fix suggestion

[Emmanuel Bouthenot]

Aleksi,

On Fri, Nov 11, 2022 at 02:36:00PM +0200, Aleksi Suhonen wrote:
[...]

> After the upgrade to 6.2.68 the database health check and upgrade wouldn't
> work at all. I added tons of debugging output and tracked down the problem:
> When the health check compares the database types, it is expecting lowercase
> type names, but SQLITE occasionally gives uppercase type names.
> 
> After forcing SQLITE return values to lowercase, everything seems to work.
> Here's a patch:

Thanks for your feedback.

I've submitted your patch upstream:
https://github.com/sympa-community/sympa/pull/1513

Anyway, your fix should be included with the next sympa upload (6.2.70) in
unstable.

Have a nice day.

Regards,

-- 
Emmanuel Bouthenot
  kolter@{openics,debian}.org   kolter@{libera,oftc}
  0x929D42C3/4096R

Bug#989029: info: prev-line and scroll-backward are buggy on gnuplot.info

[Eli Zaretskii]

> Date: Sat, 12 Nov 2022 00:17:34 +0100
> From: Vincent Lefevre 
> Cc: 989...@bugs.debian.org
> 
> [Cc to the Debian bug 989029, which I reported last year:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989029
> 
> I'm now reporting it upstream since it still occurs with "info"
> from Texinfo 7.0.]

AFAIU, this is not a bug with Texinfo, see below.

> * gnuplot::
> * plotting_styles::
> * Commands::
> * Terminal_types::
> * Bugs::
> * Concept_Index::
> * Command_Index::
> * Options_Index::
> * Function_Index::
> * Terminal_Index::
> 
> Go to "Bugs". This gives
> 
> 
> Next: Concept_Index,  Prev: Terminal_types,  Up: Top
> 
> 5 Bugs
> **
> 
> Please e-mail bug reports to the gnuplot-bugs mailing list or upload the
> report to the gnuplot web site on SourceForge.  Please give complete
> information on the version of gnuplot you are using and, if possible, a
> test script that demonstrates the bug.  See 'seeking-assistance'.
> 
> * Menu:
> 
> * known_limitations::
> * External_libraries::
> 
> 
> Then do a scroll-backward (with the Backspace or PageUp key) or a
> prev-line (with the up arrow key). This gives:
> 
> 
> 5.2 External libraries
> ==
> [...]
> 
> 
> instead of going to Terminal_types.
> 
> Going to the previous node gives successively:
> 
> 5 Bugs
> 5.2 External libraries
> 5.1 known limitations
> 5 Bugs

Instead of "Bugs", go to "Graphical_User_Interfaces" from the
top-level menu.  You will see this:

  4 Graphical User Interfaces
  ***

  Several graphical user interfaces have been written for `gnuplot` and
  one for win32 is included in this distribution.  In addition, there is
  a Python interface at http://py-gnuplot.darwinports.com/
  (http://py-gnuplot.darwinports.com/)

 Also several X11 interfaces exist.  One of them is called xgfe. It
  uses the Qt library and can be found on
  http://www.flash.net/~dmishee/xgfe/xgfe.html
  (http://www.flash.net/~dmishee/xgfe/xgfe.html)

 In addition three Tcl/Tk located at the usual Tcl/Tk repositories
  exist.

 Bruce Ravel (ra...@phys.washington.edu) has written a new version of
  gnuplot-mode for GNU emacs and XEmacs. This version is based on the
  gnuplot.el file by Gershon Elber.  While the gnuplot CVS repository has
  its own copy the most recent version of this package is available from
  http://feff.phys.washington.edu/~ravel/software/gnuplot-mode/
  (http://feff.phys.washington.edu/~ravel/software/gnuplot-mode/)

  * Menu:

  * Bugs::

See that "Bugs" at the end?  This is the problem: since "Bugs" is a
top-level node, its presence in a level-1 node's menu makes the node
tree not really a tree, so Backspace loops.

Thus, the problem is in the way Gnuplot produces the Info manual from
its documentation sources.  This bug should be submitted to the
Gnuplot project.

Bug#1023890: nmu: logol_1.7.9+dfsg-5

[Lev Lamberov]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu logol_1.7.9+dfsg-5 . s390x . unstable . -m "Rebuild against swi-prolog 
8.4.3+dfsg-2"

Hi,

Please, trigger binNUM for logol (in unstable) on s390x. It is needed
to fix #1022253 due to changes in swi-prolog handling of endianness.

Regards,
Lev Lamberov

Bug#1023889: libimage-exiftool-perl: exiftool ignores GPSLongitudeRef option

[Andreas Tille]

Package: libimage-exiftool-perl
Version: 12.49+dfsg-1
Severity: important

Hi,

since some time I'm tagging my scans from analog images with geoinformation
by using scripts calling exiftool.  Here is an example line for one of my
images:

exiftool -overwrite_original -quiet -GPSLatitudeRef='N' -GPSLatitude='64 deg 
8'' 51.464"'  -GPSLongitudeRef='W' -GPSLongitude='21 deg 55'' 59.700"' 
20010712_21_mediafix_img_0254*.jpg*

Since this is in Iceland it has -GPSLongitudeRef='W' set and this worked
at least until
   Date:   Sat Jun 13 22:14:57 2020 +0200
according to my GPS log.  Since I'm using testing this was probably

libimage-exiftool-perl (11.99-1) unstable; urgency=medium

  * Import upstream version 11.99.

 -- gregor herrmann   Fri, 15 May 2020 17:50:20 +0200

At that time the result of the line above was:

 $ exiftool 20010712_21_mediafix_img_0254o_.jpg  | grep GPS
GPS Version ID  : 2.3.0.0
GPS Latitude Ref: North
GPS Longitude Ref   : West
GPS Latitude: 64 deg 8' 51.46" N
GPS Longitude   : 21 deg 55' 59.70" W
GPS Position: 64 deg 8' 51.46" N, 21 deg 55' 59.70" W

If I redo the very same command line above I get:

 $ exiftool 20010712_21_mediafix_img_0254o_.jpg  | grep GPS
GPS Version ID  : 2.3.0.0
GPS Latitude Ref: North
GPS Longitude Ref   : East
GPS Latitude: 64 deg 8' 51.46" N
GPS Longitude   : 21 deg 55' 59.70" E
GPS Position: 64 deg 8' 51.46" N, 21 deg 55' 59.70" E

So the image is not *West* any more but rather *East* no - so all my
images would be moved if I would rerun my scripts (which I'm doing from
time to time when I might add new coordinates).

I did some web search on that matter and found

   https://exiftool.org/forum/index.php?topic=10163.0

but this is talking about versions 19.4x and I'm very sure I was
successfully working with some 11.[89]x version.  So this is IMHO a
regression.

Either there could be some fix for the code to get the old behaviour
back or at least the documentation should be fixed about the
GPSLongitudeRef option.  In the latter case I can search-and-replace
my scripts.

I'm just reporting the issue in the Debian BTW.  I'd volunteer to
contact upstream about this if you are busy with other stuff in
the Perl team.  Just drop me a note if you want me to do so.

Kind regards
   Andreas.


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

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

Versions of packages libimage-exiftool-perl depends on:
ii  perl  5.36.0-4

Versions of packages libimage-exiftool-perl recommends:
ii  libarchive-zip-perl1.68-1
ii  libunicode-linebreak-perl  0.0.20190101-1+b5

Versions of packages libimage-exiftool-perl suggests:
ii  libposix-strptime-perl  0.13-2+b1

-- no debconf information

Bug#1023887: Acknowledgement (systemd:amd64 (252-2 -> 252.1-1) brakes system/resume)

[Alexey Kuznetsov]

System info / logs

* http://linux-hardware.org/?probe=59aa7d31d8

Bug#994857: iwatch: Fails to send sendxmpp

[Braulio Henrique Marques Souto]

Hello Sérgio Abrantes.

Regarding the reported BUG, I have some thoughts to help solve your iwatch 
fails to send sendxmpp problem.

1) When using iwatch in daemon mode (-d), it will use sendxmpp with the root 
user. Then the root user will need a configuration file at '/root/.sendxmpprc'.

2)Analyzing your configuration file for iwatch daemon mode in 
/etc/iwatch/iwatch.xml consider the following change:

- /tmp
+ /tmp

'ps -ef' is not a recommended command to send your output to sendxmpp, because 
of the large amount of data and can cause sending errors. Consider using 
commands with simpler outputs for sendxmpp like the iwatch strings for 
commands: %c, %e, %f, %F, %p and %v and environment variables or programs like 
date.

'sudo' is recommended to force iwatch to call sendxmpp from the root user, and 
this is important because the sendxmpp configuration file for the root user has 
the permissions 600.


Regards
-- 
  Braulio H. M. Souto
  E-mail:brau...@disroot.org / XMPP:brau...@suchat.org
  FB39 DE61 869F 49D5 CCC8 3AE0 D53A 15D9 83A1 0B94

Bug#1023886: boolector: reproducible builds: Embeds running kernel architecture in /usr/bin/boolector

[Vagrant Cascadian]

I have uploaded an NMU fixing this issue:

diff -Nru boolector-1.5.118.6b56be4.121013/debian/changelog 
boolector-1.5.118.6b56be4.121013/debian/changelog
--- boolector-1.5.118.6b56be4.121013/debian/changelog   2022-11-10 
13:35:53.0 -0800
+++ boolector-1.5.118.6b56be4.121013/debian/changelog   2022-11-11 
20:56:12.0 -0800
@@ -1,3 +1,11 @@
+boolector (1.5.118.6b56be4.121013-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * mkconfig: Do not embed architecture of running kernel.
+(Closes: #1023886)
+
+ -- Vagrant Cascadian   Fri, 11 Nov 2022 20:56:12 -0800
+
 boolector (1.5.118.6b56be4.121013-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
boolector-1.5.118.6b56be4.121013/debian/patches/mkconfig-do-not-embed-architecture-of-ru.patch
 
boolector-1.5.118.6b56be4.121013/debian/patches/mkconfig-do-not-embed-architecture-of-ru.patch
--- 
boolector-1.5.118.6b56be4.121013/debian/patches/mkconfig-do-not-embed-architecture-of-ru.patch
  1969-12-31 16:00:00.0 -0800
+++ 
boolector-1.5.118.6b56be4.121013/debian/patches/mkconfig-do-not-embed-architecture-of-ru.patch
  2022-11-11 20:56:12.0 -0800
@@ -0,0 +1,37 @@
+From: Vagrant Cascadian 
+Date: Sat, 12 Nov 2022 04:28:38 +
+X-Dgit-Generated: 1.5.118.6b56be4.121013-1.3 
f1be0e4d3e0bc3d6c0f7f2b741860bd16a67ab4c
+Subject: mkconfig: Do not embed architecture of running kernel.
+
+(Closes: #1023886)
+
+https://tests.reproducible-builds.org/debian/issues/unstable/captures_build_arch_issue.html
+
+---
+
+diff --git a/lingeling/mkconfig b/lingeling/mkconfig
+index 5f99590..61e0618 100755
+--- a/lingeling/mkconfig
 b/lingeling/mkconfig
+@@ -13,7 +13,7 @@ cat<

signature.asc
Description: PGP signature

Bug#1023886: boolector: reproducible builds: Embeds running kernel architecture in /usr/bin/boolector

[Vagrant Cascadian]

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

The kernel architecture is embedded in /usr/bin/boolector:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/diffoscope-results/boolector.html

  Linux·armv7l
  vs.
  Linux·aarch64

The attached patch to fixes this by removing the "-m" argument from a call
to "uname".

According to my local tests, with this patch applied, boolector should build
reproducibly on tests.reproducible-builds.org!

Thanks for maintaining boolector!

As this is on the lowNMU list, and I recently uploaded to fix related
reproducible builds issues, I'll proceed to upload another NMU shortly
to fix reproducible builds on all architectures...


live well,
  vagrant
From: Vagrant Cascadian 
Date: Sat, 12 Nov 2022 04:28:38 +
X-Dgit-Generated: 1.5.118.6b56be4.121013-1.3 4590e8aaecbab65038ef787b9bbeac4dffc6dc99
Subject: mkconfig: Do not embed architecture of running kernel.

https://tests.reproducible-builds.org/debian/issues/unstable/captures_build_arch_issue.html

---

--- boolector-1.5.118.6b56be4.121013.orig/lingeling/mkconfig
+++ boolector-1.5.118.6b56be4.121013/lingeling/mkconfig
@@ -13,7 +13,7 @@ cat<

signature.asc
Description: PGP signature

Bug#1023885: btrbk: split off ssh_filter_btrbk in separate package?

[Christoph Anton Mitterer]

Source: btrbk
Version: 0.32.5-1
Severity: wishlist


Hey Axel.

Actually I'm not even sure myself whether that's worth it ;-) ...
but what would you think about splitting off ssh_filter_btrbk
in a separate package?

I mean it's typically never used on the same host where btrbk runs,
unless perhaps in some where odd scenarios.


In principle, btrbk is quite lightweight, so one could argue it's
not worth it, and people can simply just install the full btrbk packge
on those nodes where they only need ssh_filter_btrbk and just not
set up a btrbk.conf there.

OTOH, the package does install two systemd units... and while they
don't execute (with the PRs I've made just before upstream), they
they're still active and show up in all systemctl listings, logs, etc.
... thereby cluttering these up a bit.
Of course, the user could just disable them though.


So, no super strong wish from my side... unless you don't just like
the idea right away, just close that bug as wontfix.


Thanks,
Chris.

Bug#1023884: vtun: patch for libssl3

[Sylvain Rochet]

Package: vtun
Version: 3.0.4-2+b1
Severity: important

Dear Maintainer,

gdb:
  Program received signal SIGSEGV, Segmentation fault.
  0x77c063a2 in EVP_CIPHER_CTX_set_key_length () from 
/lib/x86_64-linux-gnu/libcrypto.so.3

OpenSSL 3.0 introduced providers, legacy algorithms such as RC4 or Blowfish 
must now be explicitely enabled before using them.

See #1014193.

Here is a patch loading the legacy and default provider.

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

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

Versions of packages vtun depends on:
ii  libc6  2.36-4
ii  liblzo2-2  2.10-2
ii  libssl33.0.7-1
ii  lsb-base   11.5
ii  sysvinit-utils [lsb-base]  3.05-7
ii  udev   252.1-1
ii  zlib1g 1:1.2.13.dfsg-1

vtun recommends no packages.

vtun suggests no packages.

-- Configuration Files:
/etc/vtund.conf [Errno 13] Permission denied: '/etc/vtund.conf'

-- no debconf information
diff -Nru vtun-3.0.4.orig/lfd_encrypt.c vtun-3.0.4/lfd_encrypt.c
--- vtun-3.0.4.orig/lfd_encrypt.c   2022-11-12 01:29:21.0 +0100
+++ vtun-3.0.4/lfd_encrypt.c2022-11-12 01:28:45.525976893 +0100
@@ -154,9 +154,23 @@
const EVP_CIPHER *cipher_type;
char tmpstr[64];
char cipher_name[32];
+   OSSL_PROVIDER *legacy;
+   OSSL_PROVIDER *deflt;
EVP_CIPHER_CTX *pctx_enc;
EVP_CIPHER_CTX *pctx_dec;
 
+   legacy = OSSL_PROVIDER_load(NULL, "legacy");
+   if (legacy == NULL) {
+  vtun_syslog(LOG_ERR, "Failed to load OpenSSL Legacy provider");
+  return -1;
+   }
+
+   deflt = OSSL_PROVIDER_load(NULL, "default");
+   if (deflt == NULL) {
+  vtun_syslog(LOG_ERR, "Failed to load OpenSSL Default provider");
+  return -1;
+   }
+
ctx_enc = EVP_CIPHER_CTX_new();
ctx_dec = EVP_CIPHER_CTX_new();
ctx_enc_ecb = EVP_CIPHER_CTX_new();

Bug#1023883: zeal: Does not download docsets, TLS initialization failure

[Sebastián Lacuesta]

Package: zeal
Version: 1:0.6.1+git20220714+6fee23-2
Severity: important
X-Debbugs-Cc: sebastianlacue...@gmail.com

When trying to download docsets, it fails with following error message:

Download failed!
Error: TLS initialization failed
URL: https://api.zealdocs.org/v1/docsets

If zeal started from terminal, following error occurs:

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use
QT_QPA_PLATFORM=wayland to run on Wayland anyway.
QSocketNotifier: Can only be used with threads started with QThread
zeal.core.applicationsingleton: Singleton ID:
HRjxpHstMPZHc8VorRJjrzSs9hzI_GPunQ8BD1LMNzw
zeal.core.applicationsingleton: Starting as a primary instance. (PID: 21102)
zeal.core.httpserver: Listening on http://127.0.0.1:36691...
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_options
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_get_security_level
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_security_level
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_ciphersuites
qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_use_session_callback
qt.network.ssl: QSslSocket: cannot resolve SSL_SESSION_is_resumable
qt.network.ssl: QSslSocket: cannot resolve SSL_get_client_random
qt.network.ssl: QSslSocket: cannot resolve SSL_SESSION_get_master_key
qt.network.ssl: QSslSocket: cannot resolve SSL_session_reused
qt.network.ssl: QSslSocket: cannot resolve SSL_set_options
qt.network.ssl: QSslSocket: cannot resolve TLS_method
qt.network.ssl: QSslSocket: cannot resolve TLS_client_method
qt.network.ssl: QSslSocket: cannot resolve TLS_server_method
qt.network.ssl: QSslSocket: cannot resolve SSL_SESSION_get_ticket_lifetime_hint
qt.network.ssl: QSslSocket: cannot resolve DTLSv1_listen
qt.network.ssl: QSslSocket: cannot resolve SSL_get1_peer_certificate
qt.network.ssl: QSslSocket: cannot resolve SSL_in_init
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_load_verify_dir
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot call unresolved function OPENSSL_init_ssl
qt.network.ssl: 

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

[Vincent Lefevre]

Hi,

On 2022-11-11 11:32:33 -0700, Sean Whitton wrote:
> On Thu 10 Nov 2022 at 11:23AM +01, Vincent Lefevre wrote:
> > On 2022-11-08 12:44:08 -0700, Sean Whitton wrote:
> >> Are you able to test the patch?  Let me know if you need help getting an
> >> installable .deb.  Thanks.
> >
> > Sorry, I couldn't test it yet, first because of an uninstallable
> > package needed for the build because I couldn't upgrade libc6 yet
> > and I couldn't get the previous version from snapshot.debian.org
> > (bug 1023540). Now that I could upgrade libc6, I'll be able to
> > test when I have some time, but perhaps not before the week-end.
> 
> Okay, do let me know if I can help -- this is blocking Emacs from migrating.

I've rebuilt the packages with the patch and couldn't reproduce
the bug yet. So it may be the correct fix.

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

Bug#1021779: orage: eats events

[Nicolas Mora]

Le 2022-11-11 à 14 h 41, Slavko a écrit :


Yes, with current libical3 (in testing) the problem is solved, can be
closed.


Thanks, closing it then

Bug#1023882: git: Add a way to disable «git clean» per repo

[Guillem Jover]

Package: git
Version: 1:2.38.1-1
Severity: wishlist
Tags: upstream

Hi!

[ Filing this here, because it seems upstream "tracks" bug reports
  from the mailing list!? So to avoid this potentially getting lost…
  And it's not clear whether that also applies to wishlist or just
  regressions and actual bugs. ]

For repositories that are not tracking code, say when storing your ~/
under git, or to store say collections of data files such as photos,
texts or similar, you might end up using .gitignore to unclutter
«git status». The problem is that both ignored and non-ignored
untracked files can be “precious”, as in not version-tracked by losing
them might imply data loss.

Accidentally running «git clean -xdf» or «git clean -Xdf» might be
catastrophic there. But for the ~/ case (or any such tracking in a
parent of git trees, this is even worse, as an accidental «cd» too
much might end up accidentally recursively running those «git clean»
on an unexpected working tree and all of its subdirectories (except
for other git working trees).

I tend to be rather careful with this, but I recently had a scare
where this happened to me, and lost a few (not essential) files before
I noticed and Ctrl-C'd git. I then set out to try to disable git clean
on these situations, but I see no way to do that as aliases do not work
with built-ins, and adding a ~/bin/git wrapper to check for this seems
extremely cumbersome.

It would thus be nice if there was an option that could be set to
completely disable «git clean» on a repo. I guess it might make sense
to disable for any untracked file, or perhaps for ignored and/or
non-ignored. So that these kind of work trees could be protected.

Thanks,
Guillem

Bug#1023881: Buster: oldstable: apache2-bin: mod_cgid: No socket created for cgid at /var/run/apache2

[Sebastian Kraus]

Package: apache2-bin
Version: 2.4.38-3+deb10u8
Arch: amd64
Severity: important
Tags: buster


Dear maintainers,

the bug is about apache2-bin in oldstable. The cgid module of apache2 fails to 
install/open the necessary socket at /var/run/apache2/. On startup, the Apache 
httpd does not care about creating this socket. The error log of Apache httpd 
presents you things like:

[Sat Nov 12 01:55:17.617778 2022] [cgid:error] [pid 10238:tid 139931184354432] 
(1)Operation not permitted: AH01246: Couldn't change owner of unix domain 
socket /var/run/apache2/cgisock.10234
[Sat Nov 12 01:55:17.618520 2022] [mpm_event:notice] [pid 10234:tid 
139931184354432] AH00489: Apache/2.4.38 (Debian) OpenSSL/1.1.1n configured -- 
resuming normal operations
[Sat Nov 12 01:55:17.618539 2022] [core:notice] [pid 10234:tid 139931184354432] 
AH00094: Command line: '/usr/sbin/apache2'
[Sat Nov 12 01:55:17.618575 2022] [cgid:crit] [pid 10234:tid 139931184354432] 
AH01238: cgid daemon failed to initialize
[Sat Nov 12 01:56:19.322600 2022] [cgid:error] [pid 10240:tid 139931164157696] 
(2)No such file or directory: [client 127.0.0.1:35936] AH02833: ScriptSock 
/var/run/apache2/cgisock.10234 does not exist: /var/www/html/test.cgi
[Sat Nov 12 01:56:37.912856 2022] [cgid:error] [pid 10240:tid 139931155764992] 
(2)No such file or directory: [client 127.0.0.1:39024] AH02833: ScriptSock 
/var/run/apache2/cgisock.10234 does not exist: /var/www/html/test.cgi


Please test yourself with:

1) a2enmod cgid

2) A vhost config including:

DocumentRoot /var/www/html

Options +ExecCGI
AddHandler cgi-script .cgi


3) Perl snippet in /var/www/html/test.cgi:

#!/usr/bin/perl

print "Content-type: text/html\n\n";
print "Hello, World.";


With apache2-bin in Debian Bullseye (stable) you do NOT encounter this failure 
and the Apache httpd cares properly about initializing the socket for the cgid 
module. Let me know, if this bug has been published in the right place and/or 
if you need any more details about it.



Regards
Sebastian

___


Sebastian Kraus

IT-Abteilung
Institut für Chemie
Straße des 17. Juni 115

Technische Universität Berlin
Fakultät II
Institut für Chemie
Straße des 17. Juni 135
10623 Berlin

Bug#1023879: Weird supplementary GID passed with getgroups syscall

[Sebastian Kraus]

Severity: important
Tags: buster moreinfo

Bug#1023842: rust-criterion - inconsistent dependencies on cast.

[Peter Green]

On 11/11/2022 16:02, Jonas Smedegaard wrote:



My work on other packages (rust-test-case) recently revealed that my
approach to embedding crates is broken, so I will do some more poking to
get it to not only succeed building on its own but also builds as
dependency of other Rust crates.


Note that criterion-plot is packaged in Debian, so an alternative way
to fix this would be to stop embedding it and use the packaged version.

Bug#1023880: mate-panel: workspace-switcher applet doesn't maintain aspect ratio with panel resize

[Mike Kupfer]

Package: mate-panel
Version: 1.27.0-1
Severity: normal
X-Debbugs-Cc: mkup...@alum.berkeley.edu

Dear Maintainer,

This is a continuation of bug#995601, which went away on its own back
in June but is back now.  I had tried to reopen 995601, but it's
already been archived, so here's a new bug.

In my Bookworm VM (VirtualBox 7), the thumbnails in the workspace
switcher appear to be in portrait layout, with the height greater than
the width.  I expect the aspect ratio of the thumbnails to match (more
or less) the display, which is wider than the height.  (See bug#995601
for some screenshots.)

Here's some additional information:

I created a new user account on the VM and logged in, and I noticed
something interesting.  On the initial login, the applet thumbnails
are a little narrow relative to the display's aspect ratio (see the
"24 pixels" attachment), but not too bad.  If I increase the panel
size to 36 pixels, the applet increases in height, but its width
remains the same, giving it a noticeably odd shape (see the "36
pixels" attachment).  I also took a screenshot with the panel at the
smallest possible height ("19 pixels").  Again, the width of the
applet remained the same; just the aspect ratio changed.  I hope this
is helpful in tracking down the problem.

best regards,
mike

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

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

Versions of packages mate-panel depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  libatk1.0-0  2.46.0-3
ii  libc62.36-4
ii  libcairo21.16.0-6
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libglib2.0-0 2.74.1-2
ii  libgtk-3-0   3.24.34-3
ii  libgtk-layer-shell0  0.8.0-1
ii  libice6  2:1.0.10-1
ii  libmate-desktop-2-17 1.26.0-1
ii  libmate-menu21.26.0-3
ii  libmate-panel-applet-4-1 1.27.0-1
ii  libmateweather1  1.26.0-1.1
ii  libpango-1.0-0   1.50.10+ds-1
ii  librda0  0.0.5-1.1
ii  libsm6   2:1.2.3-1
ii  libwayland-client0   1.21.0-1
ii  libwnck-3-0  43.0-2
ii  libx11-6 2:1.8.1-2
ii  libxrandr2   2:1.5.2-2+b1
ii  mate-desktop 1.26.0-1
ii  mate-menus   1.26.0-3
ii  mate-panel-common1.27.0-1
ii  mate-polkit  1.26.1-1

mate-panel recommends no packages.

mate-panel suggests no packages.

-- no debconf information

Bug#983578: stterm: defaul variable for TERM didn't appear to work by default

[Paride Legovini]

I still can't reproduce the issue. Can you do so on a fresh Debian 
system? I am prone to think that there's something off on the system 
where you're hitting it, otherwise we'd be seeing many more bug reports 
about it.

Bug#212549: info should support the "coding" local variable and output correct characters

[Vincent Lefevre]

On 2022-11-12 00:29:45 +0100, Vincent Lefevre wrote:
> Version: 6.7.0.dfsg.2-6
> 
> On 2022-11-11 23:57:19 +0100, Hilmar Preuße wrote:
> > Could you re-check with more recent version e.g. texinfo 7.0?
> 
> I could check that this is fixed even in Debian 11.5 (current stable),
> e.g. on the old MPFR 2.2.0 info manual.

And this was apparently fixed upstream in Texinfo 6.0 (26 June 2015):

* info:
[...]
  . if reading an Info file that is known to be in a different character
encoding to that of the user's environment, convert its contents 
when displayed and substitute missing characters

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

Bug#1023531: utox: autopkgtest regression on s390x: test_chrono fails

[Aurelien Jarno]

On 2022-11-10 08:37, Paul Gevers wrote:
> Hi,
> 
> On 09-11-2022 23:02, Aurelien Jarno wrote:
> > Unfortunately I am not sure we want to do that, as we don't know if this
> > GCC version incompatibility (that seems specific to s390x, at least in
> > the utox context) will also happen for the next GCC version.
> 
> I noticed yesterday that the previous build of check was done with gcc-10,
> so not the previous gcc. Apparently mixing gcc-10 check and gcc-11 glibc was
> "fine".
> 
> > Now if we consider it will break again, the more elegant solution would
> > be to change check to use dynamic linking instead of static linking.
> > Alternatively we can export the GCC version used to compile GLIBC (for
> > instance providing libc6-gcc11 or libc6-gcc12) and add some code in
> > check to add a depends on that. A simpler way would just be to add a
> > depends on the major glibc version (so libc6 (>> 2.36), libc6 (<< 2.37))
> > as we *tend* to change the GCC version used at the same time than the
> > major version (at least for sid, not true for experimental).
> 
> So maybe we (Release Team and glibc maintainers) should ignore this issue
> for now. At least, not create overly complicated solutions outside of check,
> just to accommodate only that package.
> 

That's indeed the best, it just mean we should carefully look at
autopkgtest on new glibc versions, and look for real issues among the
flaky tests.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#1023879: Buster: oldstable: Weird supplementary GID passed with getgroups syscall

[Sebastian Kraus]

Package: linux-image-amd64
Version: 4.19+105+deb10u17

Appears with: linux-image-4.19.0-{19..22}-amd64
Does not appear with: linux-image-4.19.0-12-amd64
Not checked with: linux-image-4.19.0-{14..17}-amd64


Hi guys,

I observed a very strange error on Debian Buster (oldstable) that appears only 
while using the latest kernel images starting from version 4.19.0-19. However 
employing a rather old kernel image like 4.19.0-12, the problem does not show 
up. The erratic behavior only happens on boxes running in default mode, but not 
while running them in rescue mode. The error is reproducible on different 
machines and can be triggered by using the `groups' command without any 
argument or the C-Library function `getgroups' in C-code directly. The error is 
encountered for any user (root/system accounts/non-privileged users) on the 
system.
Here, you see the example of the `groups' command with and without a strace:


root@box# groups
root groups: cannot find name for group ID 1097573495
1097573495


root@box# strace groups
execve("/usr/bin/groups", ["groups"], 0x7ffd25df6490 /* 30 vars */) = 0
brk(NULL)   = 0x55fe16719000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=180247, ...}) = 0
mmap(NULL, 180247, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fea9bbdb000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260A\2\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1820400, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fea9bbd9000
mmap(NULL, 1832960, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fea9ba19000
mprotect(0x7fea9ba3b000, 1654784, PROT_NONE) = 0
mmap(0x7fea9ba3b000, 1339392, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7fea9ba3b000
mmap(0x7fea9bb82000, 311296, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x169000) = 0x7fea9bb82000
mmap(0x7fea9bbcf000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b5000) = 0x7fea9bbcf000
mmap(0x7fea9bbd5000, 14336, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fea9bbd5000
close(3)= 0
arch_prctl(ARCH_SET_FS, 0x7fea9bbda540) = 0
mprotect(0x7fea9bbcf000, 16384, PROT_READ) = 0
mprotect(0x55fe15e0c000, 4096, PROT_READ) = 0
mprotect(0x7fea9bc2f000, 4096, PROT_READ) = 0
munmap(0x7fea9bbdb000, 180247)  = 0
brk(NULL)   = 0x55fe16719000
brk(0x55fe1673a000) = 0x55fe1673a000
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=4600912, ...}) = 0
mmap(NULL, 4600912, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fea9b5b5000
close(3)= 0
getuid()= 0
getegid()   = 0
getgid()= 0
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 
ENOENT (No such file or directory)
close(3)= 0
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 
ENOENT (No such file or directory)
close(3)= 0
openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=608, ...}) = 0
read(3, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 608
read(3, "", 4096)   = 0
close(3)= 0
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=180247, ...}) = 0
mmap(NULL, 180247, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fea9bbdb000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) 
= 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0003\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=55792, ...}) = 0
mmap(NULL, 83768, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fea9b5a
mprotect(0x7fea9b5a3000, 40960, PROT_NONE) = 0
mmap(0x7fea9b5a3000, 28672, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fea9b5a3000
mmap(0x7fea9b5aa000, 8192, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0xa000) = 0x7fea9b5aa000
mmap(0x7fea9b5ad000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc000) = 0x7fea9b5ad000
mmap(0x7fea9b5af000, 22328, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fea9b5af000
close(3)= 0
mprotect(0x7fea9b5ad000, 4096, PROT_READ) = 0
munmap(0x7fea9bbdb000, 180247)   

Bug#989029: info: scroll-backward is buggy

[Vincent Lefevre]

Control: tags -1 upstream

Hi Hilmar,

On 2022-11-11 23:42:12 +0100, Hilmar Preuße wrote:
> They released texinfo 7.0 and I built packages for that version:
> 
> https://freeshell.de/~hille42/texinfo_7.0/
> 
> IMHO this issue is solved in that version. Would be nice if you could
> confirm so I can write a proper changelog.

I had already built the upstream version a few days ago.

zira:~> which info
/home/vinc17/opt/texinfo-7.0/bin/info
zira:~> info --version
info (GNU texinfo) 7.0
[...]

But I still get the same issue on /usr/share/info/gnuplot.info.gz
from gnuplot 5.4.4+dfsg1-2. I've just reported the bug upstream
with a Cc to this bug.

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

Bug#989029: info: prev-line and scroll-backward are buggy on gnuplot.info

[Vincent Lefevre]

[Cc to the Debian bug 989029, which I reported last year:

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

I'm now reporting it upstream since it still occurs with "info"
from Texinfo 7.0.]

The info manual says:

 ('scroll-backward')

 Shift the text in this window down.  The inverse of
 'scroll-forward'.  If you are at the start of a node,  takes
 you to the "previous" node, so that you can read an entire manual
 from finish to start by repeating .  The default scroll size
 can be changed by invoking the
 ('scroll-backward-page-only-set-window') command with a numeric
 argument.
[...]

But at least with info from Texinfo 6.7 to 7.0, this doesn't behave
like that in the gnuplot manual, e.g. /usr/share/info/gnuplot.info.gz
from the gnuplot-doc 5.4.4+dfsg1-2 Debian package. Its master menu
contains:

* gnuplot::
* plotting_styles::
* Commands::
* Terminal_types::
* Bugs::
* Concept_Index::
* Command_Index::
* Options_Index::
* Function_Index::
* Terminal_Index::

Go to "Bugs". This gives


Next: Concept_Index,  Prev: Terminal_types,  Up: Top

5 Bugs
**

Please e-mail bug reports to the gnuplot-bugs mailing list or upload the
report to the gnuplot web site on SourceForge.  Please give complete
information on the version of gnuplot you are using and, if possible, a
test script that demonstrates the bug.  See 'seeking-assistance'.

* Menu:

* known_limitations::
* External_libraries::


Then do a scroll-backward (with the Backspace or PageUp key) or a
prev-line (with the up arrow key). This gives:


5.2 External libraries
==
[...]


instead of going to Terminal_types.

Going to the previous node gives successively:

5 Bugs
5.2 External libraries
5.1 known limitations
5 Bugs

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

Bug#1023878: ITP: libgrapheme -- Unicode string library with small footprint and high performance

[Paride Legovini]

Package: wnpp
Severity: wishlist
Owner: Paride Legovini 
X-Debbugs-Cc: debian-de...@lists.debian.org, par...@debian.org, d...@frign.de

* Package name: libgrapheme
  Version : 2.0.2
  Upstream Author : Laslo Hunhold 
* URL : https://libs.suckless.org/libgrapheme/
* License : ISC
  Programming Lang: C
  Description : Unicode string library with small footprint and high 
performance

libgrapheme is an extremely simple freestanding C99 library providing
utilities for properly handling strings according to the latest Unicode
standard 15.0.0. It offers fully Unicode compliant

 * grapheme cluster (i.e. user-perceived character) segmentation
 * word segmentation
 * sentence segmentation
 * detection of permissible line break opportunities
 * case detection (lower-, upper- and title-case)
 * case conversion (to lower-, upper- and title-case)

on UTF-8 strings and codepoint arrays, which both can also be null-terminated.

The necessary lookup-tables are automatically generated from the Unicode
standard data (contained in the tarball) and heavily compressed. Over
10,000 automatically generated conformance tests and over 150 unit tests
ensure conformance and correctness.

It is also way smaller and much faster than the other established
Unicode string libraries (ICU, GNU's libunistring, libutf8proc).

I plan to maintain the package in salsa under the debian/ namespace,
unless I get a suggestion for an appropriate team. In that case I'd
be happy to team maintain the package.

I already maintain packages from the same upstream, with whom I have
always had an excellent collaboration.

Paride

Bug#212549: info should support the "coding" local variable and output correct characters

[Hilmar Preuße]

Am 19.07.2008 um 17:50 teilte Vincent Lefevre mit:

On 2003-09-24 11:47:20 +0200, Vincent Lefevre wrote:


Hi Vincent,


I have a .info file with top-bit-set characters and at the end:

Local Variables:
coding: ISO-8859-1
End:

These characters are correctly displayed in an XTerm with the
ISO-8859-1 encoding, but not in a UXTerm (UTF-8 encoding).

info should use the "coding" local variable to know the input encoding
and output correct characters (using the encoding given by the locales).


This bug is still present in the current version.



Could you re-check with more recent version e.g. texinfo 7.0?

Hilmar
--
sigfault

Bug#1022449: python-maxminddb: diff for NMU version 2.0.3-1.1

[Faidon Liambotis]

On Fri, Nov 11, 2022 at 11:56:18PM +0200, Stefano Rivera wrote:
> I've prepared an NMU for python-maxminddb (versioned as 2.0.3-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Thank you so much Stefano! I've been meaning to update to the latest
upstream release for a while (alongside libmaxminddb itself), but life
has gotten busy -- I'm slowly getting there though for the past couple
of weeks :)

This is currently in the top-3 of my list, and I expect to work on this
in the next week at the latest. I don't mind having an NMU, though,
whether targeted or for the new upstream version itself. If you do make
an upload, I have one small request, which would be to push the changes
to the git repo if you can (it's under the "debian" salsa project). If
you're interested in doing further work in this package, you are also
more than welcome to add yourself to Uploaders and make this a
maintainer upload. If not, totally understandable :)

Best,
Faidon

Bug#989029: info: scroll-backward is buggy

[Hilmar Preuße]

Am 24.05.2021 um 01:36 teilte Vincent Lefevre mit:

Hi Vincent,


 ('scroll-backward')

  Shift the text in this window down.  The inverse of
  'scroll-forward'.  If you are at the start of a node,  takes
  you to the "previous" node, so that you can read an entire manual
  from finish to start by repeating .  The default scroll size
  can be changed by invoking the
  ('scroll-backward-page-only-set-window') command with a numeric
  argument.
[...]


They released texinfo 7.0 and I built packages for that version:

https://freeshell.de/~hille42/texinfo_7.0/

IMHO this issue is solved in that version. Would be nice if you could
confirm so I can write a proper changelog.

Thanks,
  Hilmar
--
sigfault

Bug#1023654:

[Daniel Kamil Kozar]

This also affects mpd. Please see bug #1023872 for the details , but
the gist is the same as the samba situation described here.

Bug#1023877: apt-listbugs: [INTL:ru] Russian translation update

[Алексей Шилин]

Package: apt-listbugs
Version: 0.1.37
Severity: wishlist
Tags: l10n patch

Hi,

Updated apt-listbugs translation into Russian is attached.

-- 
Алексей Шилин 


ru.po.xz
Description: application/xz

Bug#965591: iitalian: diff for NMU version 1:2.3-3.1

[Adrian Bunk]

Control: tags 965591 + patch
Control: tags 965591 + pending
Control: tags 996361 + patch
Control: tags 996361 + pending
Control: tags 999201 + patch
Control: tags 999201 + pending

Dear maintainer,

I've prepared an NMU for iitalian (versioned as 1:2.3-3.1) and uploaded 
it to DELAYED/10. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -u iitalian-2.3/debian/rules iitalian-2.3/debian/rules
--- iitalian-2.3/debian/rules
+++ iitalian-2.3/debian/rules
@@ -47 +47,4 @@
-.PHONY: binary binary-arch binary-indep clean checkroot
+build-arch: build
+build-indep: build
+
+.PHONY: binary binary-arch binary-indep build-arch build-indep clean checkroot
diff -u iitalian-2.3/debian/changelog iitalian-2.3/debian/changelog
--- iitalian-2.3/debian/changelog
+++ iitalian-2.3/debian/changelog
@@ -1,3 +1,12 @@
+iitalian (1:2.3-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/compat: 5 -> 7. (Closes: #965591)
+  * debian/rules: Add build-{arch,indep}. (Closes: #999201)
+  * Rebuild with new ispell. (Closes: #996361)
+
+ -- Adrian Bunk   Fri, 11 Nov 2022 23:53:01 +0200
+
 iitalian (1:2.3-3) unstable; urgency=low
 
   [ Robert Luberda ]
diff -u iitalian-2.3/debian/compat iitalian-2.3/debian/compat
--- iitalian-2.3/debian/compat
+++ iitalian-2.3/debian/compat
@@ -1 +1 @@
-5
+7

Bug#398710: bell-style audible makes baby Pollito cry

[Adam Borowski]

Hi!
Big fat +1 to defaulting bell-style to either "none" or "visible".

As just discussed on #pipewire, emulating the bell on machines w/o a
hardware pc speaker is off by default because "most people want to
rip out the beeper".  And that's specifically because of bash & co
beeping whenever you press backspace or tab.

The bell is supposed to alert the user that something is wrong (or that
a long-running task on a remote server is done...), not to make a
racket during normal use.

Thus: for the love of father Dagon and mother Hydra, could you please
silence the bell by default?

/usr/share/readline/inputrc
# do not bell on tab-completion
# set bell-style none
# set bell-style visible
⬑ one of these 


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#817825: marble: enable experimental vector tiling

[matthias . geiger1024]

 Hi Ximin,

I take it this feature isn't implemented yet in 21.08.03?

Matthias

Bug#1022449: python-maxminddb: diff for NMU version 2.0.3-1.1

[Stefano Rivera]

Control: tags 1022449 + patch
Control: tags 1022449 + pending

Dear maintainer,

I've prepared an NMU for python-maxminddb (versioned as 2.0.3-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

SR
diff -Nru python-maxminddb-2.0.3/debian/changelog python-maxminddb-2.0.3/debian/changelog
--- python-maxminddb-2.0.3/debian/changelog	2020-12-11 06:29:45.0 +0200
+++ python-maxminddb-2.0.3/debian/changelog	2022-11-11 23:49:29.0 +0200
@@ -1,3 +1,10 @@
+python-maxminddb (2.0.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch: Avoid distutils, supporting setuptools >= 60. (Closes: #1022449)
+
+ -- Stefano Rivera   Fri, 11 Nov 2022 23:49:29 +0200
+
 python-maxminddb (2.0.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru python-maxminddb-2.0.3/debian/patches/avoid-distutils python-maxminddb-2.0.3/debian/patches/avoid-distutils
--- python-maxminddb-2.0.3/debian/patches/avoid-distutils	1970-01-01 02:00:00.0 +0200
+++ python-maxminddb-2.0.3/debian/patches/avoid-distutils	2022-11-11 23:49:29.0 +0200
@@ -0,0 +1,36 @@
+From: Gregory Oschwald 
+Date: Tue, 7 Dec 2021 14:22:04 -0800
+Subject: Do not use distutils
+
+Origin: upstream, https://github.com/maxmind/MaxMind-DB-Reader-python/commit/4ddd4ca604ab0f78f763664b76d7d0eebfdbe6ae
+Bug-Debian: https://bugs.debian.org/1022449
+---
+ setup.py | 14 +++---
+ 1 file changed, 11 insertions(+), 3 deletions(-)
+
+diff --git a/setup.py b/setup.py
+index 8feb869..2596b41 100644
+--- a/setup.py
 b/setup.py
+@@ -5,10 +5,18 @@ import sys
+ # This import is apparently needed for Nose on Red Hat's Python
+ import multiprocessing
+ 
+-from distutils.command.build_ext import build_ext
+-from distutils.errors import CCompilerError, DistutilsExecError, DistutilsPlatformError
+-
+ from setuptools import setup, Extension
++from setuptools.command.build_ext import build_ext
++
++# These were only added to setuptools in 59.0.1.
++try:
++from setuptools.errors import CCompilerError
++from setuptools.errors import DistutilsExecError
++from setuptools.errors import DistutilsPlatformError
++except ImportError:
++from distutils.errors import CCompilerError
++from distutils.errors import DistutilsExecError
++from distutils.errors import DistutilsPlatformError
+ 
+ cmdclass = {}
+ PYPY = hasattr(sys, "pypy_version_info")
diff -Nru python-maxminddb-2.0.3/debian/patches/series python-maxminddb-2.0.3/debian/patches/series
--- python-maxminddb-2.0.3/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ python-maxminddb-2.0.3/debian/patches/series	2022-11-11 23:49:29.0 +0200
@@ -0,0 +1 @@
+avoid-distutils

Bug#1020640: libglew2.2: Glew built without, wxwidgets with EGL support

[Scott Talbert]

On Sat, 5 Nov 2022, Andreas Metzler wrote:


On 2022-10-03 Alastair McKinstry  wrote:

As maintainer would be open to changing Glew to EGL support, but need to
understand better the consequences.


[...]

Mandriva also enables glew egl but pulls a patchset from glew GIT head
https://github.com/OpenMandrivaAssociation/glew/tree/master and indeed
if I build glew GIT head (egl build, i.e. SYSTEM=linux-egl) and run
hugin against it it just works and does not crash.


Thanks Andreas for your work testing out glew with EGL support.

I'm coming to the realization, though, that wxWidgets EGL-only wxGLCanvas 
may not be ready for prime time, given this challenge and several other 
bugs (slic3r-prusa, pronterface, etc).  Thus, I'm leaning towards 
rebuilding wxWidgets with GLX support (and adding back our force-X11 so 
things don't break on Wayland patch).  The one challenge with this is that 
it will break ABI and thus will require rebuilding all packages that link 
with the libwx-gl library.


Any comments or concerns?

Thanks,
Scott

Bug#1023872: mpd: 0.23.9-1+b3 fails to start with 'io_uring_get_sqe() failed'

[Daniel Kamil Kozar]

Thanks for the quick reply, Max.

I can confirm that installing liburing2=2.3-1 causes mpd=0.23.9-1+b3
to run flawlessly.

Will file a new bug against liburing.

On Fri, 11 Nov 2022 at 20:55, Max Kellermann  wrote:
>
> On 2022/11/11 20:52, Max Kellermann  wrote:
> > This could be a liburing ABI breakage?
>
> This upstream commit looks like an ABI breakage:
>
>  
> https://github.com/axboe/liburing/commit/f5cd4eb2b50840510a4c6bbe5ba34a5a2058a2ae
>
> The bug report should be moved to liburing.

Bug#1023876: linux-image-5.19.0-0.deb11.2-amd64: infinite loop whit RAID1 when shutting down

[Joao Eriberto Mota Filho]

Package: src:linux
Version: 5.19.11-1~bpo11+1
Severity: important

Dear maintainer,

I have a desktop with 3 polls over RAID1 (2 SSD, 2 HDD, plus 2 SSD). The
current kernel on BPO creates an infinite loop when shutting down the system. I
can see several messages like:

systemd-shutdown[1]: Not all MD devices stopped. 1 left.
systemd-shutdown[1]: Stopping MD devices.
systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
md: md2 stopped.
systemd-shutdown[1]: Not all MD devices stopped. 1 left.
systemd-shutdown[1]: Stopping MD devices.
systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
md: md2 stopped.
systemd-shutdown[1]: Not all MD devices stopped. 1 left.
systemd-shutdown[1]: Stopping MD devices.
systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
md: md2 stopped.
systemd-shutdown[1]: Not all MD devices stopped. 1 left.
systemd-shutdown[1]: Stopping MD devices.
systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
[...]
block device autoloading is deprecated and will be removed
block device autoloading is deprecated and will be removed
block device autoloading is deprecated and will be removed
block device autoloading is deprecated and will be removed
block device autoloading is deprecated and will be removed
block device autoloading is deprecated and will be removed
block device autoloading is deprecated and will be removed
block device autoloading is deprecated and will be removed
[...]
md: md2 stopped.
md: md2 stopped.
md: md2 stopped.
md: md2 stopped.
md: md2 stopped.
md: md2 stopped.
md: md2 stopped.
[...]
systemd-shutdown[1]: Not all MD devices stopped. 1 left.
systemd-shutdown[1]: Stopping MD devices.
systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
md: md2 stopped.
systemd-shutdown[1]: Not all MD devices stopped. 1 left.
systemd-shutdown[1]: Stopping MD devices.
systemd-shutdown[1]: Stopping MD /dev/md2 (9:2)
md: md2 stopped.
[...]

There is a solution from Arch Linux[1]:

"Arch disabled BLOCK_LEGACY_AUTOLOAD for 5.18 which broke mdraid".

[1] https://bbs.archlinux.org/viewtopic.php?id=279383

Please, consider disabling the deprecated BLOCK_LEGACY_AUTOLOAD, enabled by
default in current kernel on Debian:

$ cat /boot/config-5.19.0-0.deb11.2-amd64 | grep BLOCK_LEGACY_AUTOLOAD
CONFIG_BLOCK_LEGACY_AUTOLOAD=y

Thanks in advance.

Regards,

Eriberto

-- Package-specific info:
** Version:
Linux version 5.19.0-0.deb11.2-amd64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP PREEMPT_DYNAMIC Debian 5.19.11-1~bpo11+1 (2022-10-03)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.19.0-0.deb11.2-amd64 
root=UUID=daa37e3e-4081-445f-ba72-16c898462277 ro

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: ASUS
product_name: System Product Name
product_version: System Version
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: 1017
board_vendor: ASUSTeK COMPUTER INC.
board_name: PRIME B560-PLUS
board_version: Rev 1.xx

** Loaded modules:
tls
nfnetlink
bridge
stp
llc
binfmt_misc
intel_rapl_msr
intel_rapl_common
mei_hdcp
nls_ascii
nls_cp437
vfat
fat
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
snd_hda_codec_realtek
snd_hda_codec_generic
kvm
ledtrig_audio
snd_hda_codec_hdmi
snd_usb_audio
snd_hda_intel
irqbypass
snd_intel_dspcfg
snd_intel_sdw_acpi
nvidia_drm(POE)
drm_kms_helper
nvidia_modeset(POE)
rapl
intel_cstate
eeepc_wmi
asus_wmi
platform_profile
battery
efi_pstore
sparse_keymap
rfkill
snd_hda_codec
uvcvideo
snd_usbmidi_lib
snd_hda_core
snd_rawmidi
videobuf2_vmalloc
snd_seq_device
snd_hwdep
videobuf2_memops
videobuf2_v4l2
snd_pcm
joydev
evdev
videobuf2_common
intel_uncore
snd_timer
pcspkr
wmi_bmof
iTCO_wdt
snd
intel_pmc_bxt
mei_me
iTCO_vendor_support
soundcore
mei
watchdog
ee1004
sg
intel_pmc_core
acpi_pad
acpi_tad
button
nvidia(POE)
v4l2loopback(OE)
videodev
mc
dummy
parport_pc
ppdev
lp
parport
loop
dm_crypt
dm_mod
drm
fuse
configfs
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
hid_logitech_hidpp
hid_logitech_dj
btrfs
zstd_compress
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
raid0
multipath
linear
hid_generic
usbhid
hid
raid1
md_mod
sd_mod
t10_pi
crc64_rocksoft_generic
crc64_rocksoft
crc_t10dif
crct10dif_generic
crc64
crct10dif_pclmul
crct10dif_common
crc32_pclmul
crc32c_intel
ahci
ghash_clmulni_intel
libahci
xhci_pci
libata
xhci_hcd
e1000e
aesni_intel
usbcore
crypto_simd
scsi_mod
cryptd
ptp
intel_lpss_pci
i2c_i801
pps_core
intel_lpss
i2c_smbus
scsi_common
idma64
usb_common
wmi
fan
video

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:9b43] (rev 05)
DeviceName: Onboard - Other
Subsystem: ASUSTeK Computer Inc. Device [1043:8694]
Control: I/O- Mem+ 

Bug#944264: Alien Arena 7.71.2

[Raoul de Raadt]

Hi,

I have some info if you are going to try to compile Alien Arena to 
include the latest release in Debian/Ubuntu.
There is an issue with newer GCC versions: 10.4 and higher. You might 
get a lot of build errors with duplicate definitions. In that case you 
need to set a compiler flag because they changed the default.

Then run ./configure like this:

CFLAGS="-O2 -g -fcommon" ./configure

After that you can just run

sudo make -j

and

sudo make install


I hope one of you can find the time soon to include the new release 
because the old one that is currently in the Debian and Ubuntu 
repository is outdated, and is an obsolete and basically single-player 
version of this fun game.


If you need me you can contact me on Discord: https://discord.gg/Rd5fwBg

Or on Matrix: https://matrix.to/#/#alienarena:matrix.org

Kind regards,

Jar-El / Raoul de Raadt

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Zitchas Z]

Good day everyone,

To start off, I have a few questions for you in regards to this. Sorry for
the quantity, I haven't been part of the process of getting a game into
Debian before, so I'm not sure on done of the terminology or what it
entails.

1. What do we need to do to facilitate updates to Endless Sky being
packaged and made available here?

2. There had been mention of having someone as co-maintainer,
sponsor/mentor, and the option of having this under the group maintenance
of the Debian Games group. What would be involved in each of these options?
Are these mutually exclusive options, or complimentary?

3. What sort of long term commitment do we need of someone takes on
responsibility for handling this? Is this someone who just needs to do a
build, test, and upload the game each update? Is there likely to be
additional editing and adjustment required?

4. What possibilities are there for automation? For instance, we have our
GitHub repository setup to automatically build releases for MacOS, Windows,
and an appimage. Can the Debian build feasibly be done alongside these?

5. Does whoever does this require any permissions beyond the publicly
available source code and data? (There is no secret data/code, it is all
publicly visible).

Thank you, I am looking forward to helping more people enjoy our game.

Zitchas


On Fri, Nov 11, 2022, 12:23 Olek Wojnar,  wrote:

> Hello everyone,
>
> On Fri, Nov 11, 2022 at 11:27 AM Zitchas Z  wrote:
>
>> Good day Michael, Job, Damyan, and the Debian games team,
>>
>> I think we may have a person or two familiar with Debian. I will bring
>> this up with the community and see if we're can find someone interested in
>> doing this.
>>
>> I know this has come up before, and we weren't sure how to proceed, so I
>> think we should be able to.
>>
>
> I believe that I previously offered to mentor/sponsor since this game has
> been quite popular in my household. (Thanks for all the great work on it!)
> That offer is still open.
>
>
>> I have taken the liberty to upgrade the package (locally) from
 0.9.8-1.2 to 0.9.16.1 and started a salsa project to track the
 changes. The result is at .
 It is not 100% ready yet, but looks quite nice. At this point I wonder
 how to proceed.

>>>
> I haven't tried building, but that packaging looks pretty solid at first
> glance.
>
>
>> Michael, would you like a co-maintainer for the Debian package?
 Perhaps even a group-maintenance under the Debian Games Team (cc-ed)?
 Either should help timely upgrades in Debian.

>>>
> If you opt to go under the Games Team umbrella, I will be happy to help
> mentor/sponsor, as needed.
>
>
>> Thanks for the great additions to the storyline :)

>>>
> Yes!
>
> -Olek
>

Bug#1023875: RM: qevercloud -- ROM; Unused fork

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: by...@debian.org

Please drop src:qevercloud https://tracker.debian.org/pkg/qevercloud from
Debian Sid. It used to be a dependency of src:nixnote2, but now no longer
being used anymore. It has no reverse dependencies and reverse build-
dependencies.

Thanks,
Boyuan Yang


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

Bug#1023468: dgit: the format of --dep14tag tags should be customisable

[Ian Jackson]

Philip Hands writes ("Bug#1023468: dgit: the format of --dep14tag tags should 
be customisable"):
> When one is considering native packages for which one is also
> upstream, DEP-14 includes this recommendation:
> 
> > In that specific situation, the upstream vendor should not use the usual 
> > / prefix for their branches and tags
> 
> so one could perhaps default native packages to not generate the
> 'debian/' bit, but I'd think that it still needs to be configurable.

Hrm.  Some of the things that we envisage in the future will rely on
being able to find the maintainer view tag, as well as the dgit view
one.

So I don't think we want to get rid of the debian/ tag even in this
case.  But I guess we could supplement it.

> BTW I note that dgit(1) mentions this config setting:
> 
>   dgit-distro._distro_.dgit-tag-format
> 
> which encourages the assumption that one ought to be able to set something 
> like:
> 
>   dgit-distro.debian.dgit-tag-format = '%v'
> 
> and get what I'm asking for, but looking at the code makes me think that
> nothing's making use of that setting at present.

That was a compatibility option, for a previous approach.  The code
was dropped a while ago.  I'll get rid of it from the manpage.

Ian.

-- 
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#1022559: firmware-misc-nonfree: With firmware-misc-nonfree instaled, system crashes (complete freeze/lockup) every few minutes

[Diederik de Haas]

Control: tag -1 -moreinfo upstream
Control: found -1 20221012-1

On Friday, 11 November 2022 20:41:56 CET Rui Dinis wrote:
> After further testing with firmware-misc-nonfree 20220913-1 and
> firmware-misc-nonfree 20221012-1, the problem still persists the machine
> crashes after several minutes or hours.
> Without this firmware installed, the machine never crashes, is rock solid!

Thanks for testing and reporting back.

> Would it possible to explain me why would the new version correct the
> problem that I'm having with these crashes?

There were 2 new versions of the firmware then what you reported against and it
could have been that your issue was fixed in the meantime.
Now we know it was not.

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/nvidia
actually only shows 1 commit in which new firmware was added, thus no update to
existing ones, so if I had checked that before, I could've known.

What remains is reporting this 'upstream' (to nvidia), but I don't know where
that should be done. Hopefully someone else does.

One reason I didn't check is that I never saw the additional information
you did supply, so for completeness sake, I'll quote that below:

On Sun, 23 Oct 2022 22:10:51 +0100 "Rui Dinis"  wrote:
> Here is some aditional information.
> 
> I have a Nvidia Zotac 1080TI mini. With firmware-misc-nonfree installed,
> system crashes (complete freeze/lockup, no errors on screen) every few
> minutes/hours, and the only solution is a reset. Without
> firmware-misc-nonfree, never crashes.
> 
> The package version of firmware-misc-nonfree is 20210818-1
> 
> I'm using 4 screens connected to my Nvidia Graphic Card, and I'm with KDE
> Plasma.
> 
> Without the package firmware-misc-nonfree installed, the systems throws this
> errors, but it never crashes:
> 
> # journalctl -b | grep firmware
> 
> Oct 23 20:08:23 Blackbeard kernel: nouveau :01:00.0: firmware: failed to
> load nvidia/gp102/nvdec/scrubber.bin (-2)
> Oct 23 20:08:23 Blackbeard kernel: nouveau :01:00.0: firmware: failed to
> load nvidia/gp102/acr/bl.bin (-2)
> Oct 23 20:08:23 Blackbeard kernel: nouveau :01:00.0: firmware: failed to
> load nvidia/gp102/acr/bl.bin (-2)
> Oct 23 20:08:23 Blackbeard kernel: nouveau :01:00.0: acr: firmware
> unavailable
> Oct 23 20:08:23 Blackbeard kernel: nouveau :01:00.0: pmu: firmware
> unavailable
> Oct 23 20:08:23 Blackbeard kernel: nouveau :01:00.0: gr: firmware
> unavailable
> Oct 23 20:08:23 Blackbeard kernel: nouveau :01:00.0: sec2: firmware
> unavailable
> 
> # inxi -G
> Graphics:
>   Device-1: NVIDIA GP102 [GeForce GTX 1080 Ti] driver: nouveau v: kernel
>   Device-2: Microdia Camera type: USB driver: snd-usb-audio,uvcvideo

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

Bug#1015779: dgit: dgit --dpm push-source failure

[Sean Whitton]

Hello,

On Fri 11 Nov 2022 at 07:46PM GMT, Ian Jackson wrote:

> Ian Jackson writes ("Re: Bug#1015779: dgit: dgit --dpm push-source failure"):
>> But --dry-run still fails for me.  It wants some refs from git-fetch,
>> which it didn't run.
>
> Did this fail for you *without* --dry-run ?  If so then I don't think
> I have a repro.

No, it didn't.

> If it failed only *with* --dry-run then, quoting dgit(1):
>
>> --dry-run | -n
>>   This is not a very good simulation.  It can easily go wrong for
>>   ways that a for-real push wouldn't.

Fair.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1023580: A recent Bookworm upgrade broke video playback in the VLC player

[Alexis Murzeau]

Hi,

On 09/11/2022 14:00, Lisandro Damián Nicanor Pérez Meyer wrote:

tag 1023580 unreproducible moreinfo
thanks

Hi!




First of all thanks for the detailed reproduction steps. I don't seem
able to reproduce the bug on my machine, so something else must be
playing its part here. Are you running on Wayland or X? Which video
card do you have? Are you using the FLOSS drivers for it? If you can
think of any other detail that might be related here, please do not
hesitate in adding it.

Kinds regards, Lisandro.



I'm running on X and reproduced it with:
 - AMD Radeon RX 580 GPU (with xserver-xorg-video-amdgpu driver)
 - Intel HD Graphics 4000 (ivy bridge) (with xserver-xorg-video-intel driver)
 - VirtualBox VM with xserver-xorg-video-vmware and xserver-xorg-video-vesa 
drivers

I'm not running non-free or contrib driver on any of these hardware (except 
firmware-amd-graphics with AMD GPU and microcode firmwares (intel and amd 
physical machines)).
On the virtualbox VM, I'm not running anything outside main.

I'm not on the PC that has the VM right now, but will be next week.
The VM is containing these packages:
 - Debian Unstable without any tasks (nothing selected on Debian Installer)
 - xserver-xorg
 - vlc
 - icewm and fluxbox (or anything you like to have an X environment)
 - xinit (for startx)
 - You might be required to put your user in the `input` group
   (else the mouse and keyboard might not work)
 - Run startx, then run vlc with a video
- Play the video
- Stop the video
- Open the playlist (CTRL + L)
- Play the video again, stop it again
- Resize the VLC window (while the playlist is open)

This reproduce the issue for me with VirtualBox.
I think the emulated GPU controller is "VMSVGA", I will be able to
confirm this next week, but I've not installed guest additions.

I've tried to create a minimal Qt sample application that would reproduce the 
issue, but I can't get it.
Maybe there is something related with a specific feature or configuration.

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

Bug#1015779: dgit: dgit --dpm push-source failure

[Ian Jackson]

Ian Jackson writes ("Re: Bug#1015779: dgit: dgit --dpm push-source failure"):
> But --dry-run still fails for me.  It wants some refs from git-fetch,
> which it didn't run.

Did this fail for you *without* --dry-run ?  If so then I don't think
I have a repro.

If it failed only *with* --dry-run then, quoting dgit(1):

> --dry-run | -n
>   This is not a very good simulation.  It can easily go wrong for
>   ways that a for-real push wouldn't.

(I will fix the grammar...)

Ian.

-- 
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#944855: dgit: History contains tainted commit -- but tags were accepted by the dgit server, making subsequent dgit push fail

[Ian Jackson]

Control: severity -1 wishlist
Control: retitle -1 want early check for server-side tainting

Hi.  I was going through old bugs and found this one:

> If one attempts to push a tainted history (because a package was
> rejected from NEW, for example), one gets the "History contains
> tainted commit" message. If the questionable history is OK,
>  a dgit push with --deliberately flag will fail with 
...
> Version 2.1-3 has already been tagged (pushed?)

To be clear, I think what happened is this:

1. You (or someone) uploaded something that got REJECTed

2. Later, you made subsequent upload attempt, with in its history
   that earlier REJECTed upload.

3. The server regarded that as tainted, since it could see it
   had been REJECTed.

4. You reviewed the situation and decided that the tainted
   history was proper (which is a matter that this system
   intentionally leaves to your judgement).

5. You therefore re-tried the very same dgit push from step 2,
   only with --deliberately-include-questionable-history

6. This failed in the manner you describe.

7. You worked around this by deleting the tag locally
   and retrying the push.

Sadly, I don't see an easy way to avoid this.

Whether you say --deliberately-include-questionable-history is encoded
in the signed git tag that dgit makes, and whose signature
etc. is checked by the server.

So to redo the upload with --deliberately involves making a new tag.

As a matter of principle, it seems poor practice to make multiple
different signed tags with the same tag name.  (This is what you did
in step 7.)  Perhaps you as the user know that this tag hasn't
escaped anywhere, but dgit cannot know that.  (Even if it tries to
delete the tag right after the failure.)

A better answer would be for dgit to have somehow detected that this
was going to happen *before* it made the signed tag.  I don't see a
problem in principle with the server providing dgit with a list of
tainted object names, or something.  But it's not trivial, and it also
involves dgit replicating server-side logic.

I believe dgit will have printed a message saying you should use a new
version number.  I think that is probably the better workaround.

Ian.

-- 
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#1023872: mpd: 0.23.9-1+b3 fails to start with 'io_uring_get_sqe() failed'

[Max Kellermann]

On 2022/11/11 19:59, Daniel Kozar  wrote:
> Package: mpd
> Version: 0.23.9-1+b3
> Severity: important
> X-Debbugs-Cc: dkk...@gmail.com
> 
> MPD stopped being able to run after upgrading to 0.23.9-1+b3. The relevant 
> journal messages are :
> 
> mpd[8301]: terminate called after throwing an instance of 'std::runtime_error'
> mpd[8301]:   what():  io_uring_get_sqe() failed
> 
> Downgrading to 0.23.9-1+b2 or setting "auto_update" to "no" fixes this 
> problem.

b2 was built with liburing 2.2, but b3 was built with liburing 2.3.  See build 
logs:

 
https://buildd.debian.org/status/fetch.php?pkg=mpd=amd64=0.23.9-1%2Bb2=119004=1
 
https://buildd.debian.org/status/fetch.php?pkg=mpd=amd64=0.23.9-1%2Bb3=1668073210=1

This could be a liburing ABI breakage?

Bug#1023872: mpd: 0.23.9-1+b3 fails to start with 'io_uring_get_sqe() failed'

[Max Kellermann]

On 2022/11/11 20:52, Max Kellermann  wrote:
> This could be a liburing ABI breakage?

This upstream commit looks like an ABI breakage:

 
https://github.com/axboe/liburing/commit/f5cd4eb2b50840510a4c6bbe5ba34a5a2058a2ae

The bug report should be moved to liburing.

Bug#1021418: builtin: echo: Treat -n as a string

[Jakub Wilk]

* Alejandro Colomar , 2022-10-08 03:45:

I'd like if dash(1)'s built-in echo(1) would treat -n as a string.


That's not gonna happen. As per Policy §10.4, /bin/sh scripts can rely 
on the current “echo -n” semantics. And of course many of them do rely 
on it.


--
Jakub Wilk

Bug#1023874: node-readable-stream: FTBFS: Cannot use import statement outside a module

[Andreas Beckmann]

Source: node-readable-stream
Version: 4.1.0+~cs9.0.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

node-readable-stream/experimental recently started to FTBFS, probably
because some build-dependency became more strict. The version in sid is
not affected.

...
   dh_auto_build --buildsystem=nodejs
Found debian/nodejs/abort-controller/build
cd ./abort-controller && sh -ex ../debian/nodejs/abort-controller/build
+ rollup -c
(node:4756) Warning: To load an ES module, set "type": "module" in the 
package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
ESC[1mESC[31m[!] ESC[1mRollupError: Node tried to load your configuration file 
as CommonJS even though it is likely an ES module. To resolve this, change the 
extension of your configuration to ".mjs", set "type": "module" in your 
package.json file or pass the "--bundleConfigAsCjs" flag.

Original error: Cannot use import statement outside a 
moduleESC[22mESC[1mESC[39mESC[22m
ESC[36mhttps://rollupjs.org/guide/en/#--bundleconfigascjsESC[39m
ESC[2m/build/node-readable-stream-4.1.0+~cs9.0.2/abort-controller/rollup.config.js:1
import babel from "@rollup/plugin-babel"
^^

SyntaxError: Cannot use import statement outside a module
at Object.compileFunction (node:vm:360:18)
at wrapSafe (node:internal/modules/cjs/loader:1088:15)
at Module._compile (node:internal/modules/cjs/loader:1123:27)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1213:10)
at Module.load (node:internal/modules/cjs/loader:1037:32)
at Function.Module._load (node:internal/modules/cjs/loader:878:12)
at ModuleWrap. (node:internal/modules/esm/translators:169:29)
at ModuleJob.run (node:internal/modules/esm/module_job:193:25)
at async Promise.all (index 0)
at ESMLoader.import (node:internal/modules/esm/loader:530:24)ESC[22m

dh_auto_build: error: cd ./abort-controller && sh -ex 
../debian/nodejs/abort-controller/build returned exit code 1
make: *** [debian/rules:11: binary] Error 25
...

Andreas


node-readable-stream_4.1.0+~cs9.0.2-1.log.gz
Description: application/gzip

Bug#1023515: Re: systemd-pcrphase sysinit hangs blocking boot when tpm2-abrmd installed

[Marek Rusinowski]

> I thought these days in-kernel resource management was preferred? Any
> reason you were using abrmd?

I just still had it installed already for a long time since times where most
places were suggesting using it and never dropped.

Thank you for fixing it!

Bug#1022559: firmware-misc-nonfree: With firmware-misc-nonfree instaled, system crashes (complete freeze/lockup) every few minutes

[Rui Dinis]

Hi.

After further testing with firmware-misc-nonfree 20220913-1 and
firmware-misc-nonfree 20221012-1, the problem still persists the machine
crashes after several minutes or hours.
Without this firmware installed, the machine never crashes, is rock solid!

Would it possible to explain me why would the new version correct the
problem that I'm having with these crashes?

Thanks in advance.

-Original Message-
From: Diederik de Haas  
Sent: Friday, October 28, 2022 23:54
To: the.wingmanx ; 1022...@bugs.debian.org
Subject: Re: Bug#1022559: firmware-misc-nonfree: With firmware-misc-nonfree
instaled, system crashes (complete freeze/lockup) every few minutes

Control: tag -1 moreinfo

On Sunday, 23 October 2022 22:51:09 CEST the.wingmanx wrote:
> Package: firmware-misc-nonfree
> Version: 20210818-1

Can you verify whether the issue is fixed with version 20220913-1 ?

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

[Salvatore Bonaccorso]

Control: forwarded -1 
https://lore.kernel.org/linux-input/Y26BMXn15Kbt6a2u@localhost/
Control: tags -1 - moreinfo

Hi Josh.

On Fri, Nov 11, 2022 at 09:07:41AM -0800, Josh Triplett wrote:
> On Fri, Feb 25, 2022 at 02:43:59PM +0100, Salvatore Bonaccorso wrote:
> > Control: tags -1 + moreinfo
> > 
> > Hi Josh,
> > 
> > On Mon, Feb 21, 2022 at 04:31:39PM -0800, Josh Triplett wrote:
> > > Package: src:linux
> > > Version: 5.16.7-2
> > > Severity: normal
> > > X-Debbugs-Cc: j...@joshtriplett.org
> > > 
> > > I have an external ThinkPad USB keyboard:
> > > 
> > > $ lsusb | grep -i keyboard
> > > Bus 003 Device 022: ID 17ef:6047 Lenovo ThinkPad Compact Keyboard with 
> > > TrackPoint
> > > 
> > > The Linux kernel exposes a fn_lock attribute in sysfs for this keyboard:
> > > 
> > > $ cat 
> > > /sys/devices/pci:00/:00:14.0/usb3/3-5/3-5.4/3-5.4.3/3-5.4.3:1.1/0003:17EF:6047.000F/fn_lock
> > > 1
> > > 
> > > However, this attribute appears inverted for this particular keyboard:
> > > it seems to be 1 when FnLock is *disabled* and 0 when FnLock is
> > > *enabled*.
> > 
> > If you can reproduce this with either 5.16.10-1 (or later today
> > 5.16.11-1) or the current version in experimental (5.17~rc4-1~exp1)
> > would it be possible you report it upstream and keep us updated on the
> > progress?
> 
> Reproduced with 6.0.6-2, and reported upstream (CCed to this bug).

Thank you for re-testing and reporting it upstream.

Regards,
Salvatore

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Olek Wojnar]

Hello everyone,

On Fri, Nov 11, 2022 at 11:27 AM Zitchas Z  wrote:

   Good day Michael, Job, Damyan, and the Debian games team,

   I think we may have a person or two familiar with Debian. I will
   bring this up with the community and see if we're can find someone
   interested in doing this.

   I know this has come up before, and we weren't sure how to proceed,
   so I think we should be able to.


I believe that I previously offered to mentor/sponsor since this game 
has been quite popular in my household. (Thanks for all the great work 
on it!) That offer is still open.


   I have taken the liberty to upgrade the package (locally) from
   0.9.8-1.2 to 0.9.16.1 and started a salsa project to track the
   changes. The result is at
   .
   It is not 100% ready yet, but looks quite nice. At this
   point I wonder
   how to proceed.


I haven't tried building, but that packaging looks pretty solid at first 
glance.


   Michael, would you like a co-maintainer for the Debian package?
   Perhaps even a group-maintenance under the Debian Games Team
   (cc-ed)?
   Either should help timely upgrades in Debian.


If you opt to go under the Games Team umbrella, I will be happy to help 
mentor/sponsor, as needed.


   Thanks for the great additions to the storyline :)


Yes!

-Olek


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020968: Please close this bug

[bobi1024]

I've managed to track the issue and it was due to manually compiled version
of libfreetype in the /usr/local/lib directory

Bug#1019812: wxhexeditor: Please transition to wxwidgets3.2

[Scott Talbert]

On Sat, 5 Nov 2022, Paul Wise wrote:


Control: tags -1 + fixed-upstream patch
Control: forwarded -1 
https://github.com/EUA/wxHexEditor/commit/28151fc64cb6d01a08dc80ef750d4bca96c147e7
 
https://github.com/EUA/wxHexEditor/commit/ebe2449fac22089825d124935a215fd1c0739403

On Wed, 14 Sep 2022 15:42:16 -0400 Scott Talbert wrote:


Please transition wxhexeditor from wxwidgets3.0 to wxwidgets3.2.


This causes a build failure due to WX_CLEAR_ARRAY calls not having a
terminating semicolon in the version in Debian. Fixing those makes the
package build and I have tested that the package works afterwards.
The missing semicolons are fixed in the two upstream commits above.


Yep, I had prepared a pull request independently with these fixes (didn't 
check upstream, oops), but it should be ready to go:


https://salsa.debian.org/debian/wxhexeditor/-/merge_requests/2

Regards,
Scott

Bug#1023873: rygel: can't start rygel, gnome media share stopped working

[Leonardo Canducci]

Package: rygel
Version: 0.42.0-2
Severity: normal

Dear Maintainer,

I've been using gnome media sharing feature for a while and it stopped
working a few days ago. I checked apt logs and found out rygel was
updated. I guess something went wrong with that update.

Anyway when browsing the shared media via VLC from a smartphone or a
laptop I don't get results. Moreover checking systemclt I get that:

leo@asbesto:~$ systemctl --user status rygel.service
× rygel.service - Rygel DLNA/UPnP server
 Loaded: loaded (/usr/lib/systemd/user/rygel.service; disabled; preset: 
enabled)
 Active: failed (Result: exit-code) since Fri 2022-11-11 20:04:38 CET; 5min 
ago
   Duration: 548ms
Process: 7421 ExecStart=/usr/bin/rygel (code=exited, status=255/EXCEPTION)
   Main PID: 7421 (code=exited, status=255/EXCEPTION)
CPU: 11ms

nov 11 20:04:38 asbesto systemd[2104]: rygel.service: Scheduled restart job, 
restart counter >
nov 11 20:04:38 asbesto systemd[2104]: Stopped Rygel DLNA/UPnP server.
nov 11 20:04:38 asbesto systemd[2104]: rygel.service: Start request repeated 
too quickly.
nov 11 20:04:38 asbesto systemd[2104]: rygel.service: Failed with result 
'exit-code'.
nov 11 20:04:38 asbesto systemd[2104]: Failed to start Rygel DLNA/UPnP server.

Any hints for debugging this problem?

Thanks for helping,
Leonardo

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

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

Versions of packages rygel depends on:
ii  init-system-helpers 1.65.2
ii  libc6   2.36-4
ii  libgdk-pixbuf-2.0-0 2.42.9+dfsg-1
ii  libgee-0.8-20.20.6-1
ii  libges-1.0-01.20.3-1
ii  libglib2.0-02.74.1-2
ii  libgssdp-1.6-0  1.6.0-3
ii  libgstreamer-plugins-base1.0-0  1.20.3-2
ii  libgstreamer1.0-0   1.20.4-1
ii  libgupnp-1.6-0  1.6.0-3
ii  libgupnp-av-1.0-3   0.14.1-1
ii  libgupnp-dlna-2.0-4 0.12.0-3
ii  libmediaart-2.0-0   1.9.6-1
ii  librygel-core-2.8-0 0.42.0-2
ii  librygel-db-2.8-0   0.42.0-2
ii  librygel-renderer-2.8-0 0.42.0-2
ii  librygel-server-2.8-0   0.42.0-2
ii  libsoup-3.0-0   3.2.1-2
ii  libsqlite3-03.39.4-1
ii  libx11-62:1.8.1-2
ii  libxml2 2.9.14+dfsg-1.1+b1

Versions of packages rygel recommends:
ii  dbus-user-session  1.14.4-1
ii  gstreamer1.0-libav 1.20.3-1+b1
ii  gstreamer1.0-plugins-base  1.20.3-2
ii  gstreamer1.0-plugins-good  1.20.3-1+b1
ii  gstreamer1.0-plugins-ugly  1.20.3-1

Versions of packages rygel suggests:
ii  rygel-playbin  0.42.0-2
ii  rygel-preferences  0.42.0-2
ii  rygel-ruih 0.42.0-2
ii  rygel-tracker  0.42.0-2
ii  tumbler4.16.1-1

-- no debconf information

Bug#1023872: mpd: 0.23.9-1+b3 fails to start with 'io_uring_get_sqe() failed'

[Daniel Kozar]

Package: mpd
Version: 0.23.9-1+b3
Severity: important
X-Debbugs-Cc: dkk...@gmail.com

MPD stopped being able to run after upgrading to 0.23.9-1+b3. The relevant 
journal messages are :

mpd[8301]: terminate called after throwing an instance of 'std::runtime_error'
mpd[8301]:   what():  io_uring_get_sqe() failed

Downgrading to 0.23.9-1+b2 or setting "auto_update" to "no" fixes this problem.

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

Kernel: Linux 6.0.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mpd depends on:
ii  adduser   3.129
ii  init-system-helpers   1.65.2
ii  libadplug-2.3.3-0 2.3.3+dfsg-2
ii  libao41.2.2+20180113-1.1
ii  libasound21.2.7.2-1
ii  libavahi-client3  0.8-6+b1
ii  libavahi-common3  0.8-6+b1
ii  libavcodec59  7:5.1.2-1
ii  libavformat59 7:5.1.2-1
ii  libavutil57   7:5.1.2-1
ii  libbz2-1.01.0.8-5+b1
ii  libc6 2.36-4
ii  libcdio-cdda2 10.2+2.0.1-1
ii  libcdio-paranoia2 10.2+2.0.1-1
ii  libcdio19 2.1.0-4
ii  libchromaprint1   1.5.1-2+b1
ii  libcurl3-gnutls   7.86.0-1
ii  libdbus-1-3   1.14.4-1
ii  libexpat1 2.5.0-1
ii  libfaad2  2.10.1-1
ii  libflac12 1.4.2+ds-1
ii  libfluidsynth32.3.0-1+b1
ii  libfmt9   9.1.0+ds1-2
ii  libgcc-s1 12.2.0-9
ii  libgme0   0.6.3-3
ii  libicu71  71.1-3
ii  libid3tag00.15.1b-14
ii  libiso9660-11 2.1.0-4
ii  libixml10 1:1.8.4-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-1
ii  libjs-sphinxdoc   4.5.0-4
ii  libmad0   0.15.1b-10.1+b1
ii  libmikmod33.3.11.1-6
ii  libmms0   0.6.4-3
ii  libmodplug1   1:0.8.9.0-3
ii  libmp3lame0   3.100-6
ii  libmpcdec62:0.1~r495-2
ii  libmpdclient2 2.20-1+b1
ii  libmpg123-0   1.31.1-1
ii  libnfs13  4.0.0-1
ii  libogg0   1.3.5-1
ii  libopenal11:1.19.1-2
ii  libopenmpt0   0.6.6-1+b1
ii  libopus0  1.3.1-2
ii  libpcre2-8-0  10.40-2
ii  libpipewire-0.3-0 0.3.59-1+b1
ii  libpulse0 16.1+dfsg1-2+b1
ii  libsamplerate00.2.2-2
ii  libshout3 2.4.6-1+b1
ii  libsidplayfp6 2.3.1-1
ii  libsmbclient  2:4.17.2+dfsg-8
ii  libsndfile1   1.1.0-3+b1
ii  libsndio7.0   1.9.0-0.3+b1
ii  libsoxr0  0.1.3-4
ii  libsqlite3-0  3.39.4-1
ii  libstdc++612.2.0-9
ii  libsystemd0   252.1-1
ii  libupnp13 1:1.8.4-2
ii  liburing2 2.2-2
ii  libvorbis0a   1.3.7-1
ii  libvorbisenc2 1.3.7-1
ii  libwavpack1   5.5.0-1
ii  libwildmidi2  0.4.3-1
ii  libyajl2  2.1.0-3
ii  libzzip-0-13  0.13.72+dfsg.1-1.1
ii  lsb-base  11.5
ii  sysvinit-utils [lsb-base] 3.05-6
ii  zlib1g1:1.2.11.dfsg-4.1

mpd recommends no packages.

Versions of packages mpd suggests:
ii  avahi-daemon0.8-6+b1
pn  icecast2
ii  mpc [mpd-client]0.34-1+b1
ii  ncmpc [mpd-client]  0.47-1
pn  pulseaudio  

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

-- no debconf information

Bug#1004680: upgrade-reports: beep when selecting logout

[slow_speed]

On Thu, 10 Nov 2022 10:25:00 +0500 Akbarkhon Variskhanov 
 wrote:

> Control: forwarded -1 gitlab.xfce.org/xfce/xfce4-session/issues/146
> Control: reassign -1 xfce4-session
> Control: tags -1 - d-i + wontfix
>
> As suggested in the upstream issue, you need to set the
> /general/ShowScreenshots to false like so:
>
> $ xfconf-query --channel xfce4-session --property
> /general/ShowScreenshots --set false
>
> The part of code responsible for emitting the beep has been around for
> a long time. It's done so as to notify of a taken screenshot, which is
> used to represent the current session in the list of saved sessions.
>
> You could argue that it should be disabled by default but I guess it's
> better to provide some feedback and let the user know.
>
>
I don't know anything about that.  However, if the logout notification 
is somehow tied to a screenshot notification, I would think it would be 
tied to many other functions as well.  I do not experience that; not 
even with a screenshot.


So, if there is code for that, are you saying that it is misused in this 
application?

Bug#1022149: ktimetracker total data loss

[Adrian Bunk]

The BTS does not Cc the submitter by default, Cc added.


On Fri, Oct 21, 2022 at 07:39:30AM +0100, David Jarvie wrote:
> This looks of it could be the same issue as bug 1021938, which is due to a 
> regression in libical version 3.0.15.
> --
> David Jarvie
> KAlarm author, KDE developer

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

[Sean Whitton]

Hello,

On Thu 10 Nov 2022 at 11:23AM +01, Vincent Lefevre wrote:

> On 2022-11-08 12:44:08 -0700, Sean Whitton wrote:
>> Are you able to test the patch?  Let me know if you need help getting an
>> installable .deb.  Thanks.
>
> Sorry, I couldn't test it yet, first because of an uninstallable
> package needed for the build because I couldn't upgrade libc6 yet
> and I couldn't get the previous version from snapshot.debian.org
> (bug 1023540). Now that I could upgrade libc6, I'll be able to
> test when I have some time, but perhaps not before the week-end.

Okay, do let me know if I can help -- this is blocking Emacs from migrating.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1023601: libgpgme-dev: removal of gpgme-config breaks the build of software relying on it

[Vincent Lefevre]

Hi Andreas,

On 2022-11-11 18:31:40 +0100, Andreas Metzler wrote:
> We were aware that some breakage was to be expected (a little bit late,
> though), and will provide help/assistance (quoting Daniel 1023601: "this
> might cause knock-on effects for projects that themselves think they
> should be dependent on gpgme-config, but i'll try to sort those through
> as well.")
> 
> I do not think the bug severity is correct. It does not break any binary
> packages, i.e. it fits "a bug which has a major effect on the usability
> of a package, without rendering it completely unusable to everyone."

Well, for anyone that follows the official GPGME documentation, the
libgpgme-dev package (only needed to build GPGME-based software) is
unusable. Something needs to be done before the release. See below.

> One might argue that the combination of this gpgme version with
> unbuildable packages is not releaseable and up with serious.

Remember that libgpgme-dev is not just useful to build Debian
packages, but also to build software that is not part of Debian.

In any case, a decision has to be made: either consider that the
change is too early, and the next Debian release should have this file
(in this case, the RC bug is justified), or consider that it is up to
other software to be updated (or users to find a workaround), in which
case, things should at least properly documented: the GPGME manual
currently says:


2.2 Building the Source
===

If you want to compile a source file including the ‘gpgme.h’ header
file, you must make sure that the compiler can find it in the directory
hierarchy.  This is accomplished by adding the path to the directory in
which the header file is located to the compilers include file search
path (via the ‘-I’ option).

   However, the path to the include file is determined at the time the
source is configured.  To solve this problem, gpgme ships with a small
helper program ‘gpgme-config’ that knows about the path to the include
file and other configuration options.  The options that need to be added
to the compiler invocation at compile time are output by the ‘--cflags’
option to ‘gpgme-config’.  The following example shows how it can be
used at the command line:

 gcc -c foo.c `gpgme-config --cflags`

   Adding the output of ‘gpgme-config --cflags’ to the compiler command
line will ensure that the compiler can find the GPGME header file.

   A similar problem occurs when linking the program with the library.
Again, the compiler has to find the library files.  For this to work,
the path to the library files has to be added to the library search path
(via the ‘-L’ option).  For this, the option ‘--libs’ to ‘gpgme-config’
can be used.  For convenience, this option also outputs all other
options that are required to link the program with GPGME (in particular,
the ‘-lgpgme’ option).  The example shows how to link ‘foo.o’ with the
GPGME library to a program ‘foo’.

 gcc -o foo foo.o `gpgme-config --libs`

   Of course you can also combine both examples to a single command by
specifying both options to ‘gpgme-config’:

 gcc -o foo foo.c `gpgme-config --cflags --libs`

   If you need to detect the installed language bindings you can use
list them using:

 gpgme-config --print-lang

   or test for the availability using

 gpgme-config --have-lang=python && echo 'Bindings for Pythons available'


But in Debian, where gpgme-config is currently missing, this
will *not* work at all.

BTW, after all, the use of gpgrt-config might not be user-friendly
in an interactive shell (as opposed to a configure.ac file). An
alternative solution would be to consider a small gpgme-config script
that will call gpgrt-config with the right arguments. For instance,
on x86_64, I suppose that this could be

  exec gpgrt-config --libdir=/usr/lib/x86_64-linux-gnu gpgme "$@"

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

Bug#1021779: orage: eats events

[Adrian Bunk]

The BTS does not Cc the submitter by default, Cc added.


On Sun, Oct 30, 2022 at 02:21:09PM -0400, Nicolas Mora wrote:
> Hello,
> 
> On Sun, 23 Oct 2022 11:54:52 +0200 Yves-Alexis Perez 
> wrote:
> 
> > 
> > for some reason your reports never reached us so I've just seen this bug and
> > your investigation. My feeling is that this is actually
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021698 so it might be
> > interesting to check if it's fixed with 3.0.16-1.
> > 
> 
> If the bug comes from libical, I can confirm that it has been fixed in the
> last release 3.0.16-1 which is now on testing.
> 
> Can you check with the last packages if the bug is still present?
> 
> /Nicolas

Bug#1023871: automake: Missing amhello-1.0.tar.gz

[Brian Flaherty]

Package: automake
Version: 1:1.16.5-1.3
Severity: minor
X-Debbugs-Cc: b...@yahoo.com

Dear Maintainer,

   * What led up to the situation?
   
I was reading the info for automake. Section 2.2 references amhello-1.0.tar.gz 
in PREFIX/share/doc/automake. It was not there.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 
I found it on a webpage and shall create the files myself.
   https://www.gnu.org/software/automake/manual/html_node/Creating-amhello.html

   * What outcome did you expect instead?

I expected the file to be where the documentation said it should be.

Thank you.


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

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

Versions of packages automake depends on:
ii  autoconf   2.71-2
ii  autotools-dev  20220109.1

automake recommends no packages.

Versions of packages automake suggests:
ii  autoconf-doc   2.71-2
ii  gnu-standards  2022.03.23-0.1

-- no debconf information

Bug#888078: RFA: easyprocess

[Malik]

Hello,

I would also like to help to maintain this package, is it still open to be
maintained?


regards,

-- 
Malik Mlitat

Bug#1023870: dpkg: Problems in buildds due to slow compression

[Manuel A. Fernandez Montecelo]

Package: dpkg
Version: 1.21.9
Severity: normal
X-Debbugs-Cc: m...@debian.org, debian-wb-t...@lists.debian.org

(Setting initial severity as "normal" because it affects packages built in
buildd machines).

Hi,

The origins of this bug report are because there are sometimes problems building
packages in buildds, the compression phase is very slow and sometimes the build
is aborted due to inactivity:

  E: Build killed with signal TERM after 300 minutes of inactivity [1]

After some investigation by aurel32 and myself, this was traced back to the
commit f8d254943051e085040367d689048c00f31514c3 [2], in which the calculation of
the memory that can be used, to determine the number of threads to use, was
changed from half of the physical mem to be based on the memory available.

For example in buildds with not-so-large amount of RAM, using part of it for
tempfs (which is how buildds are set-up), the reported available memory maybe is
not very large.  For example it could be MemAvailable=2GB for 16GB of physical
RAM in the machine.  In the dpkg code, for the purposes of the calculation of
how much memory can be used, the result appears to be to be half of the
MemAvailable [3], so only 1GB.

According to the tables in xz man page, for compression the algorithm can use
674MB.  So as a result, dpkg-deb uses single-threaded compression, even if it
could easily use 2-3 threads and still use only RAM; or use the full number of
threads in the machine (e.g. 4 or 8) even if it means swapping out some of the
content of tempfs -- which is not a problem in most cases for buildds, specially
if using fast disks.

As a result of all this, it is taking upwards of 600 mins of CPU time to
compress recent linux-image-*-dbg packages in the buildds of riscv64
architecture at the moment, so when using 2 threads of less, it's guaranteed to
be aborted.

But this also affects other arches and other packages in other ways, at least by
making the build needlessly slow in many cases.


It's not very clear what could be the solution for this, as the default could be
OK for desktops and many machines in which there's plenty of available RAM, but
this is not the case of all of our buildds.  It might not be possible to detect
which is the best from within dpkg.

Maybe it could be through a new variable DPKG_DEB_THREADS (similar to the
recently added DPKG_DEB_MAX_THREADS) in which the buildds explicitly set the
amount of threads that they want.


PS: Bug #501456 [4] is possibly a duplicate, or at least the intersection is
largish :)


[1] 
https://buildd.debian.org/status/fetch.php?pkg=linux=riscv64=6.1%7Erc3-1%7Eexp1=1667646869=0

[2] 
https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=f8d254943051e085040367d689048c00f31514c3

[3] At least that's what I got in my tests as value for mt_memlimit, half of the
MemAvailable at the time, even if I expected the full amount of MemAvailable
when quickly reading the code.  But I didn't pay much attention because this
detail is not very important in principle: MemAvailable could be very low if
tempfs is using more than the physical RAM, it doesn't matter if it's full
or half in many cases with low memory.

[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501456


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 

Bug#861142: thunar: Problem bulk renaming photos by hour

[Akbarkhon Variskhanov]

Control: tags -1 moreinfo upstream

On Mon, 24 Apr 2017 21:26:58 -0300 Marco  wrote:
> Typically, the hour is wrong, and the pictures end up unsorted.

Wrong how exactly? What was the original filename and what was the result?

> If you open the file properties, you can see that the actual time of the 
> photo is correct, so Thunar Bulk Rename fails to extract the correct hour out 
> of the file.

Again, it'd be nice to have concrete data.

> It doesn't do with every file. Some files are incorrectly renamed.

What types of files?

Do you still have this problem? Perhaps your problem was fixed in the
later versions?

Bug#833035: linux-image-3.16.0-4-amd64: Keyspan USB serial adapter USA-49WLC failed to load firmware

[Jakob Haufe]

On Fri, 11 Nov 2022 16:12:32 +0100
Salvatore Bonaccorso  wrote:

> Jakob, were you able to forward the patch upstream? I'm including
> Johan and linux-usb list in this reply now.

No, I originally wanted to understand the differences of the firmware
loading mechanism as I assumed a patch migrating away from the unified
firmware interface would not be accepted anyway.

Unfortunately, I never found time to do this.

Thanks for bringing this up again.

Given I have two different affected devices, I am more than happy to
test any new versions of this patch.

Cheers,
sur5r

-- 
ceterum censeo microsoftem esse delendam.


pgpcnd3dp3yFx.pgp
Description: OpenPGP digital signature

Bug#1023869: openjdk-17: Versioned java-runtime, java-runtime-headless and java-sdk virtual packages

[Emmanuel Bourg]

Source: openjdk-17
Version: 17.0.5+8-2
Severity: normal

The openjdk package provides several virtual packages with a version number
in the package name:
- java<2, 5..n>-runtime
- java<2, 5..n>-runtime-headless
- java<2, 5..n>-sdk
- java<2, 5..n>-sdk-headless

Since Jessie the provided virtual packages can be versioned. I suggest
adding a version to the java-runtime, java-runtime-headless and java-sdk
virtual packages to avoid appending two new packages per year. This is
in addition to the current java-runtime packages that should remain
in place to preserve the compatibility. But I suggest that we stop this
pattern with the version 21 (so openjdk-22 will not provide java22-runtime).
diff --git a/debian/control b/debian/control
index 4fd33c9410..09f129ccd1 100644
--- a/debian/control
+++ b/debian/control
@@ -30,7 +30,7 @@ Pre-Depends: ${dpkg:Depends}
 Depends: openjdk-17-jre-headless (= ${binary:Version}),
   ${shlibs:Depends}, ${misc:Depends}
 Suggests: openjdk-17-demo, openjdk-17-source
-Provides: java-sdk-headless, java2-sdk-headless,
+Provides: java-sdk-headless (= ${vm:Version}), java2-sdk-headless,
   java5-sdk-headless, java6-sdk-headless,
   java7-sdk-headless, java8-sdk-headless,
   java9-sdk-headless, java10-sdk-headless,
@@ -56,7 +56,7 @@ Recommends: ${dlopenhl:Recommends}
 Suggests: libnss-mdns,
   fonts-dejavu-extra,
   fonts-ipafont-gothic, fonts-ipafont-mincho, fonts-wqy-microhei | 
fonts-wqy-zenhei, fonts-indic,
-Provides: java-runtime-headless, java2-runtime-headless,
+Provides: java-runtime-headless (= ${vm:Version}), java2-runtime-headless,
   java5-runtime-headless, java6-runtime-headless,
   java7-runtime-headless, java8-runtime-headless,
   java9-runtime-headless, java10-runtime-headless,
@@ -80,7 +80,7 @@ Depends: openjdk-17-jre (= ${binary:Version}),
   ${shlibs:Depends}, ${misc:Depends}
 Recommends: libxt-dev
 Suggests: openjdk-17-demo, openjdk-17-source, visualvm
-Provides: java-sdk, java2-sdk, java5-sdk, java6-sdk,
+Provides: java-sdk (= ${vm:Version}), java2-sdk, java5-sdk, java6-sdk,
   java7-sdk, java8-sdk, java9-sdk, java10-sdk, java11-sdk,
   java12-sdk, java13-sdk, java14-sdk, java15-sdk, java16-sdk, java17-sdk,
   java-compiler
@@ -96,7 +96,7 @@ Depends: openjdk-17-jre-headless (= ${binary:Version}),
   ${xandsound:Depends}, ${dlopenjre:Depends},
   ${shlibs:Depends}, ${misc:Depends}
 Recommends: ${dlopenjre:Recommends}, ${bridge:Recommends}, fonts-dejavu-extra
-Provides: java-runtime, java2-runtime,
+Provides: java-runtime (= ${vm:Version}), java2-runtime,
   java5-runtime, java6-runtime,
   java7-runtime, java8-runtime,
   java9-runtime, java10-runtime,
diff --git a/debian/control.in b/debian/control.in
index 1c13028402..a61894632e 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -30,7 +30,7 @@ Pre-Depends: ${dpkg:Depends}
 Depends: @basename@-jre-headless (= ${binary:Version}),
   ${shlibs:Depends}, ${misc:Depends}
 Suggests: @basename@-demo, @basename@-source
-Provides: java-sdk-headless, java2-sdk-headless,
+Provides: java-sdk-headless (= ${vm:Version}), java2-sdk-headless,
   java5-sdk-headless, java6-sdk-headless,
   java7-sdk-headless, java8-sdk-headless,
   java9-sdk-headless, java10-sdk-headless,
@@ -56,7 +56,7 @@ Recommends: ${dlopenhl:Recommends}
 Suggests: libnss-mdns,
   @core_fonts@,
   @cjk_fonts@
-Provides: java-runtime-headless, java2-runtime-headless,
+Provides: java-runtime-headless (= ${vm:Version}), java2-runtime-headless,
   java5-runtime-headless, java6-runtime-headless,
   java7-runtime-headless, java8-runtime-headless,
   java9-runtime-headless, java10-runtime-headless,
@@ -80,7 +80,7 @@ Depends: @basename@-jre (= ${binary:Version}),
   ${shlibs:Depends}, ${misc:Depends}
 Recommends: libxt-dev
 Suggests: @basename@-demo, @basename@-source, visualvm
-Provides: java-sdk, java2-sdk, java5-sdk, java6-sdk,
+Provides: java-sdk (= ${vm:Version}), java2-sdk, java5-sdk, java6-sdk,
   java7-sdk, java8-sdk, java9-sdk, java10-sdk, java11-sdk,
   java12-sdk, java13-sdk, java14-sdk, java15-sdk, java16-sdk, java17-sdk,
   java-compiler
@@ -96,7 +96,7 @@ Depends: @basename@-jre-headless (= ${binary:Version}),
   ${xandsound:Depends}, ${dlopenjre:Depends},
   ${shlibs:Depends}, ${misc:Depends}
 Recommends: ${dlopenjre:Recommends}, ${bridge:Recommends}, @core_fonts@
-Provides: java-runtime, java2-runtime,
+Provides: java-runtime (= ${vm:Version}), java2-runtime,
   java5-runtime, java6-runtime,
   java7-runtime, java8-runtime,
   java9-runtime, java10-runtime,
diff --git a/debian/rules b/debian/rules
index ed53ec1ebe..5add570484 100755
--- a/debian/rules
+++ b/debian/rules
@@ -828,6 +828,7 @@ d_dbg   = debian/$(p_dbg)
 
 control_vars = \
'-Vvm:Name=$(vm_name)' \
+   '-Vvm:Version=shortver' \
'-Vdlopenhl:Depends=$(dlopen_hl_depends)' \
'-Vdlopenhl:Recommends=$(dlopen_hl_recommends)' \
'-Vdlopenjre:Depends=$(dlopen_jre_depends)' \

Bug#1023855: TOTP module not enabled in slapd-contrib

[Ryan Tandy]

Control: severity -1 wishlist

On Fri, Nov 11, 2022 at 03:05:48PM +0100, Kees Meijs wrote:

Could you please enable the plugin to be built?


Will do. Thanks for putting in the request.

Bug#1023868: caja-seahorse: FTBFS against libgpgme-dev >= 1.18.0-2 [checking for gpgme-config... failed]

[Andreas Metzler]

Package: caja-seahorse
Version: 1.18.5-1
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

Hello,

caja-seahorse FTBFS due to removal of gpgme-config. Since caja-seahorse
already requires pkgconfig you can simply use this for gpgme, too.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
diff -Nru caja-seahorse-1.18.5/debian/changelog caja-seahorse-1.18.5/debian/changelog
--- caja-seahorse-1.18.5/debian/changelog	2020-08-24 10:00:41.0 +0200
+++ caja-seahorse-1.18.5/debian/changelog	2022-11-11 18:45:09.0 +0100
@@ -1,3 +1,11 @@
+caja-seahorse (1.18.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * 1010_gpgme_pkgconfig.diff: Use pkgconfig to locate gpgme instead of
+gpgme-config fixing FTBFS with libgpgme-dev >= 1.18.0-2.
+
+ -- Andreas Metzler   Fri, 11 Nov 2022 18:45:09 +0100
+
 caja-seahorse (1.18.5-1) unstable; urgency=medium
 
   [ Simon Quigley ]
diff -Nru caja-seahorse-1.18.5/debian/patches/1010_gpgme_pkgconfig.diff caja-seahorse-1.18.5/debian/patches/1010_gpgme_pkgconfig.diff
--- caja-seahorse-1.18.5/debian/patches/1010_gpgme_pkgconfig.diff	1970-01-01 01:00:00.0 +0100
+++ caja-seahorse-1.18.5/debian/patches/1010_gpgme_pkgconfig.diff	2022-11-11 18:45:09.0 +0100
@@ -0,0 +1,54 @@
+Description: Use pkgconfig to locate gpgme instead of gpgme-config.
+Author: Andreas Metzler 
+Origin: vendor
+Last-Update: 2022-11-11
+
+--- a/configure.ac
 b/configure.ac
+@@ -85,45 +85,11 @@
+ 	else
+ 		AC_MSG_ERROR([Appropriate version of GnuPG not found. Please install one of versions: $accepted_versions])
+ 	fi
+ fi
+ 
+-ok="no"
+-min_gpgme_version=1.0.0
+-AC_PATH_PROG(GPGME_CONFIG, gpgme-config, "failed")
+-if test $GPGME_CONFIG != "failed" ; then
+-	AC_MSG_CHECKING(for GPGME - version >= $min_gpgme_version)
+-	req_major=`echo $min_gpgme_version | \
+-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
+-	req_minor=`echo $min_gpgme_version | \
+-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
+-	req_micro=`echo $min_gpgme_version | \
+-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
+-	gpgme_config_version=`$GPGME_CONFIG --version`
+-	major=`echo $gpgme_config_version | \
+-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\1/'`
+-	minor=`echo $gpgme_config_version | \
+-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\2/'`
+-	micro=`echo $gpgme_config_version | \
+-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\3/'`
+-
+-	if test "$major" -eq "$req_major"; then
+-		if test "$minor" -ge "$req_minor"; then
+-			if test "$micro" -ge "$req_micro"; then
+-ok="yes"
+-			fi
+-		fi
+-	fi
+-fi
+-
+-if test $ok = "yes"; then
+-	GPGME_CFLAGS=`$GPGME_CONFIG --cflags`
+-	GPGME_LIBS=`$GPGME_CONFIG --libs`
+-	AC_MSG_RESULT(yes)
+-else
+-	AC_MSG_ERROR(GPGME $min_gpgme_version or later needed)
+-fi
++PKG_CHECK_MODULES([GPGME], [gpgme >= 1.0.0])
+ 
+ SEAHORSE_CFLAGS="$SEAHORSE_CFLAGS $GPGME_CFLAGS"
+ SEAHORSE_LIBS="$SEAHORSE_LIBS $GPGME_LIBS"
+ 
+ # -
diff -Nru caja-seahorse-1.18.5/debian/patches/series caja-seahorse-1.18.5/debian/patches/series
--- caja-seahorse-1.18.5/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ caja-seahorse-1.18.5/debian/patches/series	2022-11-11 18:43:29.0 +0100
@@ -0,0 +1 @@
+1010_gpgme_pkgconfig.diff

Bug#1023867: labltk: /usr/bin/labltk script won't run; paths in it not sanitized after package build

[Jean]

Package: labltk
Version: 8.06.9-1+b1
Severity: important

Dear Maintainer,

The /usr/bin/labltk script which is the main content of package labltk
fails to run, with the following error message :

/usr/bin/labltk: 2: exec: /build/labltk-
mgG2qY/labltk-8.06.9/debian/tmp//usr/lib/ocaml/labltk/labltktop: not found

Indeed, this one-liner script contains two hardcoded paths that are wrong,
they expose the build path of the package instead of the installation
location /usr/lib/ocaml/labltk. Both the path of the binary labltktop and the
included path after "-I" need fixing.

Thanks a lot for Debian in general and for the OCaml packages in particulier!
Best
Jean


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

Kernel: Linux 5.10.0-19-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 labltk depends on:
ii  liblabltk-ocaml-dev  8.06.9-1+b1

Versions of packages labltk recommends:
ii  ocaml-findlib  1.8.1-2

labltk suggests no packages.

Bug#1023848: kodi-pvr-hts: Packet requires kodi-api-pvr but is not available in sid

[Vasyl Gello]

Hi Leela,

To resolve this I will need to upload src:kodi once more to fix an overlooked 
issue breaking builds on non-x86 platforms and then, after it gets built for 
all arches, upload the addons again. Mattia might help me early next week with 
it, because my status (Debian Contributor) does not allow me uploading packages 
directly.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1023865: docker.io: docker build breaks breaks host network

[Shengjing Zhu]

Control: tags + moreinfo unreproducible

On Sat, Nov 12, 2022 at 1:15 AM ChangZhuo Chen  wrote:
>
> Package: docker.io
> Version: 20.10.19+dfsg1-1
> Severity: normal
>
> Hi,
>
> When using `docker build`, my host network, and container network are
> both down. This problem make `docker build` useless since it cannot
> download necessary artifacts to build image anymore. The problematic
> docker file is 
> https://github.com/apache/flink-docker/blob/master/1.16/scala_2.12-java11-ubuntu/Dockerfile.
> However, other Dockerfile can also reprocedure the issue.
>
> The problem might be caused by additinoal routing table record added by
> docker. The following is normal `route` output:
>

`docker build` uses the default docker network(usually the docker0
bridge). It won't do anything to the routing table during `docker
build`.
You must have some  other configurations for the host network or your
docker setup.

-- 
Shengjing Zhu

Bug#1021488: solved

[Alf]

This bug isn't really a bug, found the resolution today:

The settings which I claimed to be missing/ignored in cups-pdf are now 
available in job specific settings of the printing dialog (xfce4 desktop) and 
are persistent thus surviving reboots. This was absolutely different compared 
to how it was in Bullseye where there was no such possibility neither in the 
printing dialog nor in the settings of the printing object on the desktop.

As this is a complete fresh installation of Bookworm there was no such 
notification during install. Also explanations in cups-pdf.conf do not mention 
that change.

Sorry,
Alf

Bug#1023601: libgpgme-dev: removal of gpgme-config breaks the build of software relying on it

[Andreas Metzler]

On 2022-11-08 Vincent Lefevre  wrote:
> On 2022-11-07 13:36:30 +0100, Vincent Lefevre wrote:
> > The removal of gpgme-config due to
> > 
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022348
> > 
> > breaks the build of software relying on it, such as Mutt:
[...]
> Actually gpgrt-config can be used instead of gpgme-config. But
> this requires changes in existing code, possibly non trivial,
> as now done for Mutt:

>   https://gitlab.com/muttmua/mutt/-/issues/430

> (not yet in Debian).

> So before gpgme-config gets removed (which is a *recent* upstream
> change), you should make sure that existing code based on it has
> been updated.

Hello Vincent,

Disclaimer: I am not in uploaders of gpg packaging but follow the list.

We were aware that some breakage was to be expected (a little bit late,
though), and will provide help/assistance (quoting Daniel 1023601: "this
might cause knock-on effects for projects that themselves think they
should be dependent on gpgme-config, but i'll try to sort those through
as well.")

I do not think the bug severity is correct. It does not break any binary
packages, i.e. it fits "a bug which has a major effect on the usability
of a package, without rendering it completely unusable to everyone." One
might argue that the combination of this gpgme version with unbuildable
packages is not releaseable and up with serious.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1023866: firmware: failed to load brcm/BCM4345C0.raspberrypi,3-model-b-plus.hcd

[Diederik de Haas]

Package: bluez-firmware
Version: 1.2-7
Severity: normal
X-Debbugs-Cc: pkg-raspi-maintain...@lists.alioth.debian.org

With a freshly made RPi 3 Bookworm image (with [1]) I booted up my
RPi 3B+ and noticed the following error in `dmesg`:

[   21.159415] bluetooth hci0: firmware: failed to load 
brcm/BCM4345C0.raspberrypi,3-model-b-plus.hcd (-2)
[   21.169313] bluetooth hci0: firmware: failed to load 
brcm/BCM4345C0.raspberrypi,3-model-b-plus.hcd (-2)

After installing 'bluez' and 'bluez-tools' and running 'bluetoothctl'
and setting it to 'discoverable', I did see the device on my phone.

Still, dmesg reports it as an error, hence severity 'normal'.
If this is a kernel issue, please do reassign.

Cheers,
  Diederik

[1] https://salsa.debian.org/raspi-team/image-specs/

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

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

-- no debconf information

Bug#1023865: docker.io: docker build breaks breaks host network

[陳昌倬]

Package: docker.io
Version: 20.10.19+dfsg1-1
Severity: normal

Hi,

When using `docker build`, my host network, and container network are
both down. This problem make `docker build` useless since it cannot
download necessary artifacts to build image anymore. The problematic
docker file is 
https://github.com/apache/flink-docker/blob/master/1.16/scala_2.12-java11-ubuntu/Dockerfile.
However, other Dockerfile can also reprocedure the issue.

The problem might be caused by additinoal routing table record added by
docker. The following is normal `route` output:

Kernel IP routing table 


Destination Gateway Genmask Flags Metric Ref
Use Iface
default _gateway0.0.0.0 UG60000 
wlp3s0  

10.0.3.00.0.0.0 255.255.255.0   U 0  0  
  0 lxcbr0
link-local  0.0.0.0 255.255.0.0 U 1000   00 
wlp3s0  

172.17.0.0  0.0.0.0 255.255.0.0 U 0  0  
  0 docker0
192.168.0.0 0.0.0.0 255.255.255.0   U 60000 
wlp3s0

And the following is `route` output when `docker build` is running:

Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse 
Iface
0.0.0.0 0.0.0.0 255.255.255.255 UH0  00 
veth7e48846
default 0.0.0.0 0.0.0.0 U 0  00 
veth7e48846
default _gateway0.0.0.0 UG60000 
wlp3s0
10.0.3.00.0.0.0 255.255.255.0   U 0  00 
lxcbr0
link-local  0.0.0.0 255.255.0.0 U 0  00 
veth7e48846
link-local  0.0.0.0 255.255.0.0 U 1000   00 
wlp3s0
172.17.0.0  0.0.0.0 255.255.0.0 U 0  00 
docker0
192.168.0.0 0.0.0.0 255.255.255.0   U 60000 
wlp3s0

The new entry for default destination might cause the problem.


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

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

Versions of packages docker.io depends on:
ii  adduser3.129
ii  containerd 1.6.9~ds1-1
ii  init-system-helpers1.65.2
ii  iptables   1.8.8-1
ii  libc6  2.36-4
ii  libdevmapper1.02.1 2:1.02.185-2
ii  libsystemd0252.1-1
ii  runc   1.1.4+ds1-1
ii  sysvinit-utils [lsb-base]  3.05-7
ii  tini   0.19.0-1

Versions of packages docker.io recommends:
ii  apparmor 3.0.7-1+b1
ii  ca-certificates  20211016
ii  cgroupfs-mount   1.4
ii  git  1:2.38.1-1
ii  needrestart  3.6-2
ii  xz-utils 5.2.7-0.1

Versions of packages docker.io suggests:
pn  aufs-tools 
pn  btrfs-progs
ii  debootstrap1.0.128+nmu2
pn  docker-doc 
ii  e2fsprogs  1.46.6~rc1-1+b1
pn  rinse  
pn  rootlesskit
pn  xfsprogs   
pn  zfs-fuse | zfsutils-linux  

-- no debconf information

--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#853106: lightdm: dm-tool segfaults when XDG_SEAT_PATH doesn't start with '/'

[Akbarkhon Variskhanov]

Control: severity -1 wishlist
Control: tags -1 wontfix
Control: reassign -1 glib2.0

Why wouldn't it? This is like taking out a car's wheel and becoming
surprised it doesn't drive very well.

I can't even think of a scenario why it'd be necessary to omit the
initial slash. This is wrong on so many levels. Please refer to the
documentation of the g_variant_is_object_path() function[1] and the
D-Bus specification[2], which I'm going to quote here:

The path must begin with an ASCII '/' (integer 47) character, and must
consist of elements separated by slash characters.

I'm reassigning it to glib2.0 since it's not a bug in LightDM and
there is nothing to fix unless you're suggesting that LightDM provides
a leading slash and covers up for the user's mistake or even
deliberate choice, which is a really bad practice. The glib folks will
most definitely mark it as wontfix/invalid anyway.

[1] https://docs.gtk.org/glib/type_func.Variant.is_object_path.html#description
[2] https://dbus.freedesktop.org/doc/dbus-specification.html

> Changing XDG_SEAT_PATH=org... to XDG_SEAT_PATH=/org... fixes the problem.

A nonexistent problem born from your curiosity. ;)

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

[Josh Triplett]

I have an external ThinkPad USB keyboard:

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

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

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

However, this attribute appears inverted for this particular keyboard:
it seems to be 1 when FnLock is *disabled* and 0 when FnLock is
*enabled*. In order to enable FnLock, I have to write 0 to this file.

(Also, separately from that, it would be nice if the kernel could handle
fn_lock toggling *internally*, rather than expecting userspace to do it.
As far as I can tell, it does handle similar things for some keyboards,
but not this one.)

Bug#1022308:

[Gard Spreemann]

Hi,

I have verified that adding libglu1-mesa-dev to the build-deps makes the
package again build successfully.


 -- Gard
 


signature.asc
Description: PGP signature

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

[Josh Triplett]

On Fri, Feb 25, 2022 at 02:43:59PM +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
> 
> Hi Josh,
> 
> On Mon, Feb 21, 2022 at 04:31:39PM -0800, Josh Triplett wrote:
> > Package: src:linux
> > Version: 5.16.7-2
> > Severity: normal
> > X-Debbugs-Cc: j...@joshtriplett.org
> > 
> > I have an external ThinkPad USB keyboard:
> > 
> > $ lsusb | grep -i keyboard
> > Bus 003 Device 022: ID 17ef:6047 Lenovo ThinkPad Compact Keyboard with 
> > TrackPoint
> > 
> > The Linux kernel exposes a fn_lock attribute in sysfs for this keyboard:
> > 
> > $ cat 
> > /sys/devices/pci:00/:00:14.0/usb3/3-5/3-5.4/3-5.4.3/3-5.4.3:1.1/0003:17EF:6047.000F/fn_lock
> > 1
> > 
> > However, this attribute appears inverted for this particular keyboard:
> > it seems to be 1 when FnLock is *disabled* and 0 when FnLock is
> > *enabled*.
> 
> If you can reproduce this with either 5.16.10-1 (or later today
> 5.16.11-1) or the current version in experimental (5.17~rc4-1~exp1)
> would it be possible you report it upstream and keep us updated on the
> progress?

Reproduced with 6.0.6-2, and reported upstream (CCed to this bug).

Bug#1006251: Closing this bug (BTS maintenance for src:linux bugs)

[Josh Triplett]

reopen 1006251 6.0.6-2
thanks

I can confirm that this still exists in current kernels.

- Josh Triplett

On Fri, Nov 11, 2022 at 04:46:52PM +0100, car...@debian.org wrote:
> Hi
> 
> This bug was filed for a very old kernel or the bug is old itself
> without resolution.
> 
> If you can reproduce it with
> 
> - the current version in unstable/testing
> - the latest kernel from backports
> 
> please reopen the bug, see https://www.debian.org/Bugs/server-control
> for details.
> 
> Regards,
> Salvatore

Bug#1016014: adduser: Broken symlinks in /usr/*/man8 folders. Affects piuparts

[Jason Franklin]

On Fri, 2022-11-11 at 12:07 +0100, Bastian Germann wrote:
> Control: severity -1 important
> 
> Can you please fix this? This is really annoying for all maintainers who care 
> about the piuparts test results of their 
> packages (all maintainers?). I always have to look more closely because I 
> might have introduced a bug but every time for 
> the past 4 months it was this issue that comes up. This will lead people to 
> ignore piuparts and will introduce bugs.

I find it odd that our Salsa CI pipeline still shows a green check even
though piuparts is emitting an error message about these links. I hope
that doesn't indicate some kind of problem with our CI setup. :/

This is simple enough to fix, however. We can always add the links back
when up-to-date translations are submitted.

I will send up a merge request today and then ping a reviewer about it
to move things along.

Thanks to Peter, Andreas, and Bastian for being persistent. :)

-- 
Jason Franklin

Bug#1023752: visidata: New upstream version: v2.10.2 (Oct 8, 2022)

[Andrew Chadwick]

Hi Anja -

Thanks for the response! Yes, I can confirm that 2.10.2 feels pretty
stable, although I'm very much a beginner with the program.

I wonder if it would be possible to add Suggests: headers for a "nice"
subset of the packages required to open certain kinds of file in the
next upload. Specifically, the ones listed in

  * short: 
https://jsvine.github.io/intro-to-visidata/basics/opening-files/#compatible-filetypes

  * full: https://www.visidata.org/docs/formats/

It wouldn't be right to list them in Recommends:, I feel, but a
Suggests: header feels like a really nice packaging enhancement for
end users who want to explore more.

I'd understand if you can't list them all, because there are a lot,
and they might not all have Debian packages yet. And it's inherently a
choice, a matter of judgment, if you decide against trying to list all
of them.

I'm not 100% sure about what feels like a "nice" subset, or what the
criteria for such a list should be. Entries for common simple local
file formats (Excel, LibreOffice, XML, YAML) and important Open Source
databases (MySQL/MariaDB, Postgres) would seem good as a starting
point, however. Also, the Debian-Edu team might be interested in
seeing visidata's package announce support for big stats package file
formats (Stata, pandas, SAS, Numpy, ...)


cheers,
Andrew

On Wed, 9 Nov 2022 at 17:40, Anja  wrote:
>
> Hi Andrew!
>
> We tend to wait to update the Homebrew and Debian until we are sure of the 
> solidity of a release. Having said that, 2.10.2 does feel pretty solid, so we 
> are likely to prioritise a Debian release for that one. =)

Bug#1023864: reportbug: Doesn't put cursor to correct position in emacs unless config specially edited

[Askar Safin]

Package: reportbug
Version: 11.5.1
Severity: normal
X-Debbugs-Cc: safinas...@gmail.com

When reportbug spawns emacs editor, it doesn't put cursor to correct position. 
The cursor is placed in first line
instead. This happens if I never edited /etc/reportbug.conf . If I uncomment 
line 'editor "emacs -nw"' in the
config, then cursor will be placed correctly.

This is exact steps to reproduce starting from fresh docker container: 
https://paste.debian.net/hidden/66b1f071/

You may say: "Just edit reportbug.conf". Well, when I want to report some bug I 
often create fresh system (for
example, I start fresh docker container), then reproduce the bug in it and then 
report the bug from this system.
I usually don't edit reportbug.conf every time.


-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /root/.reportbugrc:
reportbug_version "11.5.1"
mode advanced
ui text
realname "Askar Safin"
email "safinas...@gmail.com"
no-check-uid
no-cc
list-cc-me
smtphost reportbug.debian.org

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

Kernel: Linux 5.10.0-0.deb9.17-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages reportbug depends on:
ii  apt2.5.4
ii  python33.10.6-1
ii  python3-reportbug  11.5.1
ii  sensible-utils 0.0.17

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
ii  debconf1.5.79
pn  debsums
pn  dlocate
ii  emacs-bin-common   1:27.1+1-3.1+b1
ii  exim4-daemon-light [mail-transport-agent]  4.96-8
ii  file   1:5.41-4
pn  gnupg | pgp
pn  python3-urwid  
pn  reportbug-gtk  
pn  xdg-utils  

Versions of packages python3-reportbug depends on:
ii  apt2.5.4
ii  file   1:5.41-4
ii  python33.10.6-1
ii  python3-apt2.3.0+nmu1
ii  python3-debian 0.1.48
ii  python3-debianbts  3.2.4
ii  python3-requests   2.27.1+dfsg-1
ii  sensible-utils 0.0.17

python3-reportbug suggests no packages.

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

-- no debconf information

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Zitchas Z]

Good day Michael, Job, Damyan, and the Debian games team,

I think we may have a person or two familiar with Debian. I will bring this
up with the community and see if we're can find someone interested in doing
this.

I know this has come up before, and we weren't sure how to proceed, so I
think we should be able to.

Thank you,

Zitchas

On Fri, Nov 11, 2022, 06:39 Michael Zahniser,  wrote:

> I have not been working on Endless Sky in a few years - it would make
> sense to switch the maintainer to someone on the current development team
> . I've CCed Zitchas on this
> email.
>
> -Michael
>
>
> On Fri, Nov 11, 2022 at 1:24 AM Damyan Ivanov  wrote:
>
>> (resent with the correct games team address; sorry for the duplicate)
>>
>> -=| Job Bautista, 01.08.2020 08:13:08 + |=-
>> > Just in case someone wonders if this is being worked on, MZ uploaded a
>> 0.9.12-1 package at mentors.debian.net[1]. He's just waiting for a
>> sponsor to upload it to the main archive. If you want, you can dget the dsc
>> file and build the package yourself.
>> >
>> > Regards,
>> >
>> > Job Bautista
>> >
>> > [1]: https://mentors.debian.net/package/endless-sky/
>>
>> Two years later, this is no longer available and endless-sky is at
>> version 0.9.16.1.
>>
>> I have taken the liberty to upgrade the package (locally) from
>> 0.9.8-1.2 to 0.9.16.1 and started a salsa project to track the
>> changes. The result is at .
>> It is not 100% ready yet, but looks quite nice. At this point I wonder
>> how to proceed.
>>
>> Michael, would you like a co-maintainer for the Debian package?
>> Perhaps even a group-maintenance under the Debian Games Team (cc-ed)?
>> Either should help timely upgrades in Debian.
>>
>> Thanks for the great additions to the storyline :)
>>
>>
>> -- Damyan
>>
>

Bug#1019356: gnome-feeds: Update to 1.0.3

[erusan]

A 1.0 release has just been tagged for syndication-
domination: https://gitlab.com/gabmus/syndication-domination/activity

I assume this can be packaged now that there's a release?


> It switches to the Python3 bindings for
> https://gitlab.com/gabmus/syndication-domination
> which isn't packaged in Debian yet.

Bug#816073: xfce4-notifyd did not show icons when network status changed

[Akbarkhon Variskhanov]

Control: severity -1 wishlist
Control: tags -1 wontfix

Most likely because you clicked on the "Do not show this ever again"
button that accompanies the pop-up. I'd say it's working as intended.
I'm not sure how you can get it back, though.

Bug#1023842: rust-criterion - inconsistent dependencies on cast.

[Jonas Smedegaard]

Quoting Peter Green (2022-11-11 09:04:34)
> The rust-criterion package has inconsistent dependencies on the cast
> crate, the dependency in the main Cargo.toml is on version 0.3, but
> the dependencies in the debian packaging and in the embedded copy of
> the criterion-plot crate are at 0.2
> 
> I have updated the cast crate in Debian to 0.3, and prepared an update
> for the rust-criterion package to use 0.3 consistently. I tested that
> the package built succesfully and the autopkgtests passed with these
> changes.

Thanks!

I am now applying main parts of your proposed patch to the git repo
(only locally for now - will push when I have it in working shape).

I also extended the embedded patch  to the full original upstream
patch (turns out all of it is relevant for us), and adjusted to properly
use DEP-3 patch headers (helpful that you referenced upstream patch, but
for future sake beware especially to properly credit the author: You are
at most co-author when cherry-picking patched done by others, and in
most cases only reviewer).

My work on other packages (rust-test-case) recently revealed that my
approach to embedding crates is broken, so I will do some more poking to
get it to not only succeed building on its own but also builds as
dependency of other Rust crates.


> While working on the fix, I discovered the clean target wasn't
> cleaning up properly, so I fixed it to do so.

I have left that part out for now, as that sounds like a general flaw in
dh-cargo that I will try identify and fix (instead of papering over it).
Thanks for pointing it out!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature

Bug#965786: pppoeconf: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Michael Prokop]

* Niels Thykier [Mon Jul 20, 2020 at 07:35:34PM +]:
> Source: pppoeconf
> Version: 1.21
> Severity: normal
> Usertags: compat-5-6-removal
> 
> The package pppoeconf uses debhelper with a compat level of 5 or 6,
> which is deprecated and scheduled for removal[1].
[...]

This bug is still present and caused the package to be removed from
testing. Gregory, can you please take of this, so pppoeconf has the
chance to be present in the upcoming bookworm release?

regards
-mika-


signature.asc
Description: PGP signature

Bug#992675: resynthesizer missing in bullseye

[Jakub Wilk]

* Ying-Chun Liu (PaulLiu) , 2022-11-08 04:22:

right now in Debian we have to disable all python plugins temporarily.
We will bring those plugins back when gimp-python3 is available.


Please remove resynthesizer from the package description and from 
Provides until this is fixed.


--
Jakub Wilk


signature.asc
Description: PGP signature

Bug#996008: Bug #996008: i225 NIC no longer recognized after 11.1 point release

[Salvatore Bonaccorso]

Hi

On Tue, Jun 07, 2022 at 04:50:09PM +0200, Diederik de Haas wrote:
> Control: reassign -1 src:linux 5.10.70-1
> Control: tag -1 moreinfo
> 
> On Sun, 10 Oct 2021 00:25:44 + (UTC) TarotApprentice 
>  wrote:
> > Package: linux-image-amd64
> > Version: 5.10.0-9 (5.10.70-1)
> > 
> > Two machines (ASUS X570-P/CSM) with built-in NIC (realtek) and 
> > add-in 2.5GbE NIC (intel i225). After installing point release 11.1 the 
> > add-in NIC is no longer recognized on either machine. The built-in NIC still
> > works. Clearly it was working before the point release as it used the 
> > 2.5G NIC to do the apt upgrade.
> > 
> > Both machines were running kernel 5.10.0-8 and Bullseye prior to the 
> > upgrade.
> > Rebooting the machine using the 5.10.0-8 kernel (selecting it from grub) 
> > doesn't help - NIC enumeration fails.
> > 
> > # grep igc /var/log/messages
> > Oct 10 08:50:00 *** kernel: [4.829780] igc :04:00.0 enp4s0: NIC 
> > Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
> > Oct 10 09:03:26 *** kernel: [3.819348] igc: probe of :04:00.0 
> > failed with error -13
> > Oct 10 10:59:51 *** kernel: [3.826878] igc: probe of :04:00.0 
> > failed with error -13
> 
> I'm inclined to think/agree that this is a kernel issue, but what is then
> confusing is that it still doesn't work with the same kernel version with 
> which
> it previously did work. Which suggests that another update caused the failure.
> 
> The latest point release is now 11.3, so verifying whether the problem is 
> still
> present there, with a newer 5.10 kernel, seems like a good first step.
> 
> If that's the case, a more complete output of dmesg or /var/log/messages would
> be useful.
> Also testing with a kernel from Testing/Unstable and/or Bullseye backports
> would also give useful extra information.

Do you still experience the same issues with the most recent kernel in
bullseye (5.10.149-2).

I'm inclined otherwise to close this bugreport, assuming it's not
reproducible. If it is reproducible, does the same issue shows up with
more recent kernels from unstable and/or backports?

Regards,
Salvatore

Bug#1023863: firmware: failed to load brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.bin (-2)

[Diederik de Haas]

Package: firmware-brcm80211
Version: 20221012-1
Severity: normal
X-Debbugs-Cc: pkg-raspi-maintain...@lists.alioth.debian.org

With a freshly made RPi 3 Bookworm image (with [1]) I booted up my
RPi 3B+ and noticed the following error in `dmesg`:

[   19.801109] brcmfmac mmc1:0001:1: firmware: failed to load 
brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.bin (-2)
[   19.815101] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   19.829633] brcmfmac mmc1:0001:1: firmware: failed to load 
brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.bin (-2)

All messages wrt 'brcmfmac' in `dmesg`:
[   19.773206] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio 
for chip BCM4345/6
[   19.786577] usbcore: registered new interface driver brcmfmac
[   19.801109] brcmfmac mmc1:0001:1: firmware: failed to load 
brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.bin (-2)
[   19.829633] brcmfmac mmc1:0001:1: firmware: failed to load 
brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.bin (-2)
[   19.843649] brcmfmac mmc1:0001:1: Direct firmware load for 
brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.bin failed with error -2
[   19.950059] brcmfmac mmc1:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43455-sdio.bin
[   19.985340] brcmfmac mmc1:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt
[   20.206331] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio 
for chip BCM4345/6
[   20.249761] brcmfmac mmc1:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43455-sdio.clm_blob
[   20.266765] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Apr 15 
2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm
does not seem to have a file with that name though, but I've seen in
other places where a symlink was made.
Not sure if that's what missing here though.
If the kernel incorrectly reports this issue, please reassign.

The (cabled) network *does* work though, but as dmesg classified it
as an error, I've set the severity to normal.

Cheers,
  Diederik

[1] https://salsa.debian.org/raspi-team/image-specs/

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

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

firmware-brcm80211 depends on no packages.

firmware-brcm80211 recommends no packages.

Versions of packages firmware-brcm80211 suggests:
ii  initramfs-tools  0.142

-- no debconf information

Bug#927710: ath10k locks to regulatory domain US on ACPI platforms

[Salvatore Bonaccorso]

Control: forwarded -1 
https://lore.kernel.org/ath10k/2ab7cc1d-f756-ba3c-64b7-65f8a739a...@newmedia-net.de/#t

On Sat, May 29, 2021 at 02:23:22PM +0200, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
> 
> Hi,
> 
> On Sun, Apr 21, 2019 at 09:48:17PM +0200, Rene 'Renne' Bartsch, B.Sc. 
> Informatics wrote:
> > Package: linux-image
> > Version: 4.19.28-2
> > 
> > The ath10k 802.11 driver reads the country code for the radio regulatory 
> > domain from the ACPI table.
> > If it can't get a valid value it locks to US regulatory domain which is 
> > wrong for most countries.
> > This makes Atheros devices in master mode unusable on ACPI devices in most 
> > countries.
> > 
> > Sven Gottschall suggested on ath10k mailing-list to return -EOPNOTSUPP in 
> > function
> > ath10k_mac_get_wrdd_regulatory(struct ath10k *ar, u16 *rd) in file 
> > drivers/net/wireless/ath/ath10k/mac.c to solve this.
> > 
> > 
> > static int ath10k_mac_get_wrdd_regulatory(struct ath10k *ar, u16 *rd)
> > {
> > return -EOPNOTSUPP;
> > }
> 
> Was there a conclusion upstream?

As this looks is not going to change in upstream, I'm closing this
downstream bug about it as well.

Regards,
Salvatore

Bug#1023862: paho.mqtt.c: New upstream version is available

[Matthias Klein]

Source: paho.mqtt.c
Severity: wishlist

Dear Maintainer,

please consider packaging the latest available release, 1.3.11. This
version is required by the C++ binding paho.mqtt.cpp which I want to
package.

Thanks for your work on the package!

Best regards,
Matthias

Bug#1014095: azure-cli: az error: no module 'azure.mgmt.containerservice.v2022_04_01'

[Luca Boccassi]

Control: close -1 20221101+git-1

On Thu, 30 Jun 2022 10:04:21 +0200 Dominique Dumont 
wrote:
> Package: azure-cli
> Version: 2.37.0-2
> Severity: important
> 
> Dear Maintainer,
> 
> az cli fails due to a missing dependency:
> 
> $  az aks get-upgrades --resource-group alilo-dev --name alilo-dev 
> The command failed with an unexpected error. Here is the traceback:
> No module named 'azure.mgmt.containerservice.v2022_04_01'
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/knack/cli.py", line 231, in
invoke
> cmd_result = self.invocation.execute(args)
>   File "/usr/lib/python3/dist-
packages/azure/cli/core/commands/__init__.py", line 561, in execute
> self.commands_loader.load_arguments(command)
>   File "/usr/lib/python3/dist-packages/azure/cli/core/__init__.py",
line 515, in load_arguments
> self.command_table[command].load_arguments()  # this loads the
arguments via reflection
>   File "/usr/lib/python3/dist-
packages/azure/cli/core/commands/__init__.py", line 318, in
load_arguments
> super(AzCliCommand, self).load_arguments()
>   File "/usr/lib/python3/dist-packages/knack/commands.py", line 104,
in load_arguments
> cmd_args = self.arguments_loader()
>   File "/usr/lib/python3/dist-
packages/azure/cli/core/commands/command_operation.py", line 125, in
arguments_loader
> op = self.get_op_handler(self.op_path)
>   File "/usr/lib/python3/dist-
packages/azure/cli/core/commands/command_operation.py", line 59, in
get_op_handler
> handler = import_module(mod_to_import)
>   File "/usr/lib/python3.10/importlib/__init__.py", line 126, in
import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 1050, in _gcd_import
>   File "", line 1027, in _find_and_load
>   File "", line 992, in
_find_and_load_unlocked
>   File "", line 241, in
_call_with_frames_removed
>   File "", line 1050, in _gcd_import
>   File "", line 1027, in _find_and_load
>   File "", line 992, in
_find_and_load_unlocked
>   File "", line 241, in
_call_with_frames_removed
>   File "", line 1050, in _gcd_import
>   File "", line 1027, in _find_and_load
>   File "", line 1004, in
_find_and_load_unlocked
> ModuleNotFoundError: No module named
'azure.mgmt.containerservice.v2022_04_01'
> To open an issue, please run: 'az feedback'
> 
> Can you check what goind on ?

Cannot reproduce this anymore with the new python3-azure, closing.

-- 
Kind regards,
Luca Boccassi


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

Bug#833035: linux-image-3.16.0-4-amd64: Keyspan USB serial adapter USA-49WLC failed to load firmware

[Salvatore Bonaccorso]

Hi Jakob,

On Tue, Feb 08, 2022 at 08:03:19AM +0100, Salvatore Bonaccorso wrote:
> Hi Jakob,
> 
> On Mon, Feb 07, 2022 at 03:33:49PM +0100, Jakob Haufe wrote:
> > This still affects 5.15.0-3-amd64:
> > 
> > [624300.704569] usb 5-1: new full-speed USB device number 2 using ohci-pci
> > [624300.901723] usb 5-1: New USB device found, idVendor=06cd, 
> > idProduct=011a, bcdDevice=80.01
> > [624300.901746] usb 5-1: New USB device strings: Mfr=0, Product=0, 
> > SerialNumber=0
> > [624300.903869] keyspan 5-1:1.0: Keyspan - (without firmware) converter 
> > detected
> > [624300.904014] usb 5-1: firmware: direct-loading firmware 
> > keyspan/usa49wlc.fw
> > [624304.121517] usb 5-1: ezusb_ihex_firmware_download - ezusb_writememory 
> > failed writing internal memory (-110 7F92 b8cbdc0a 1)
> > [624304.121545] usb 5-1: failed to load firmware "keyspan/usa49wlc.fw"
> > [624304.121559] keyspan: probe of 5-1:1.0 failed with error -2
> > 
> > The patch applies with some fuzz but still solves the issue.
> > Refreshed patch is attached.
> > 
> > Has anyone already contacted upstream about this? I couldn't find
> > anything related on the linux-usb ML.
> 
> Not that I'm aware of. Given you have a tested patch, would it be
> possible that you contact upstream about it, keeping us in the loop or
> at least notify when it is applied in mainline?

Jakob, were you able to forward the patch upstream? I'm including
Johan and linux-usb list in this reply now.

Johan, fo context, it is about an older bug reported in Debian as
https://bugs.debian.org/833035 with users of the Keyspan USB serial
adapter USA-49WLC faling to load firmware.

There was a patch used, in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833035#68 tough
which hs no commit message or Signed-off-by's . Original patch is from
Ben in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833035#24 .

Regards,
Salvatore

Bug#1021338: azure-cli: az webapp commands failing: API version 2022-03-01 does not have operation group 'web_apps'

[Luca Boccassi]

Control: close -1 20221101+git-1

On Thu, 06 Oct 2022 17:15:33 +1100 "David.K"  wrote:
> Package: azure-cli
> Version: 2.40.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> az webapp commands are failing with the following stack trace:
> 
> $ az webapp list
> The command failed with an unexpected error. Here is the traceback:
> API version 2022-03-01 does not have operation group 'web_apps'
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/knack/cli.py", line 233, in
invoke
> cmd_result = self.invocation.execute(args)
>   File "/usr/lib/python3/dist-
packages/azure/cli/core/commands/__init__.py", line 663, in execute
> raise ex
>   File "/usr/lib/python3/dist-
packages/azure/cli/core/commands/__init__.py", line 726, in
_run_jobs_serially
> results.append(self._run_job(expanded_arg, cmd_copy))
>   File "/usr/lib/python3/dist-
packages/azure/cli/core/commands/__init__.py", line 697, in _run_job
> result = cmd_copy(params)
>   File "/usr/lib/python3/dist-
packages/azure/cli/core/commands/__init__.py", line 333, in __call__
> return self.handler(*args, **kwargs)
>   File "/usr/lib/python3/dist-
packages/azure/cli/core/commands/command_operation.py", line 121, in
handler
> return op(**command_args)
>   File "/usr/lib/python3/dist-
packages/azure/cli/command_modules/appservice/custom.py", line 967, in
list_webapp
> full_list = _list_app(cmd.cli_ctx, resource_group_name)
>   File "/usr/lib/python3/dist-
packages/azure/cli/command_modules/appservice/custom.py", line 1006, in
_list_app
> result = list(client.web_apps.list())
>   File "/usr/lib/python3/dist-
packages/azure/mgmt/web/_web_site_management_client.py", line 804, in
web_apps
> raise ValueError("API version {} does not have operation group
'web_apps'".format(api_version))
> ValueError: API version 2022-03-01 does not have operation group
'web_apps'

Cannot reproduce with the newer python3-azure, closing.

-- 
Kind regards,
Luca Boccassi


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