Bug#1018749: claws-mail: Size of Dropdown and Clear-Button to large.

[Christopher Bock]

Package: claws-mail
Version: 4.1.0-2
Severity: minor

Dear Maintainer,

   * What led up to the situation?

I guess some Update from the gtk-libraries.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
  Nothing of the following was effective.

  - Starting Claws-Mail with different Themes via
- GTK_THEME=Adwaita claws-mail
- GTK_THEME=Breeze claws-mail

  - I tried running it with a newly created User

  - I Created a systemd-nspawn container like the example from
https://wiki.debian.org/nspawn#Firefox_example and ran it via
root@asterix ~ # systemd-nspawn \
  --setenv=DISPLAY--bind-ro=/tmp/.X11-unix/ \
  --private-users=pick \
  --private-users-chown \
  -D /var/lib/machines/deb-claws-mail --as-pid2 claws-mail

   * What was the outcome of this action?

The Size of the Drop-Down-Field and Clear-Button for Searching
Mails is about 3 times thicker than it should be.
And now that i loaded the report in Claws-Mail to send it over i
can see that the Size of TO/CC/BCC/.. is also broken.

   * What outcome did you expect instead?
 
   A clean look like in the past.


with many regards,
Christopher Bock

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

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

Versions of packages claws-mail depends on:
ii  libc62.34-4
ii  libcairo21.16.0-6
ii  libcompfaceg11:1.5.2-5.1
ii  libdbus-glib-1-2 0.112-2
ii  libenchant-2-2   2.3.3-1
ii  libetpan20   1.9.4-3
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libglib2.0-0 2.72.3-1+b1
ii  libgnutls30  3.7.7-2
ii  libgtk-3-0   3.24.34-3
ii  libice6  2:1.0.10-1
ii  libldap-2.5-02.5.12+dfsg-2+b1
ii  libnettle8   3.8.1-2
ii  libpango-1.0-0   1.50.9+ds-1
ii  libpangocairo-1.0-0  1.50.9+ds-1
ii  librsvg2-2   2.54.4+dfsg-1
ii  libsm6   2:1.2.3-1
ii  xdg-utils1.1.3-4.1

Versions of packages claws-mail recommends:
ii  aspell-de-1901 [aspell-dictionary]   1:2-37
ii  aspell-en [aspell-dictionary]
2018.04.16-0-1 pn  claws-mail-i18n
 pn  xfonts-100dpi | xfonts-75dpi |
xfonts-100dpi-transcoded | x  

Versions of packages claws-mail suggests:
ii  chromium [www-browser] 104.0.5112.101-1
pn  claws-mail-doc 
ii  claws-mail-tools   4.1.0-2
ii  dillo [www-browser]3.0.5-7+b1
ii  elinks [www-browser]   0.13.2-1+b3
ii  firefox-esr [www-browser]  102.2.0esr-1
pn  gedit | kwrite | mousepad | nedit  
ii  links2 [www-browser]   2.27-1+b1
ii  vivaldi-stable [www-browser]   5.4.2753.40-1

-- no debconf information

Bug#1018748: reportbug: override requests offer deprecated 'extra' priority option

[Daniel Lewart]

Package: reportbug
Version: 11.5.1
Severity: minor
Tags: patch

Reportbug Maintainers,

reportbug ftp.debian.org with request type 'override' asks the user
to choose the (new) priority from the following options:
  * required
  * important
  * standard
  * optional
  * extra

However, Debian Policy 4.0.1 (Aug 2017) deprecated the 'extra' priority.

Therefore the 'extra' priority option should be removed.

Untested patch below.

Thank you!
Daniel Lewart
Urbana, Illinois
---
diff -ru a/reportbug/debbugs.py b/reportbug/debbugs.py
--- a/reportbug/debbugs.py  2022-08-17 14:00:40.0 -0500
+++ b/reportbug/debbugs.py  2022-08-30 00:00:00.0 -0500
@@ -374,15 +374,19 @@
 if not new_section:
 new_section = section
 
+if priority == 'extra':
+default_priority = 'optional'
+else:
+default_priority = priority
+
 new_priority = ui.menu('Select the new priority', {
 'required': "",
 'important': "",
 'standard': "",
 'optional': "",
-'extra': "",
-}, 'Choose the priority: ', default=priority, empty_ok=True)
+}, 'Choose the priority: ', default=default_priority, empty_ok=True)
 if not new_priority:
-new_priority = priority
+new_priority = default_priority
 
 if new_section == section and new_priority == priority:
 cont = ui.select_options(

Bug#1018747: gimp-gap recommends mplayer that will likely not be in bookworm

[Adrian Bunk]

Package: gimp-gap
Version: 2.6.0+dfsg-5
Severity: serious
Tags: bookworm sid

See #1005899 for background.

Bug#1017976: Info received (Confirmation)

[Markus Huber]

Had the same issue.
Installing "emacs-el" (emacs-common recommends but not depends on it) solved it 
on my system.

Bug#1004471: Fwd: [Pkg-javascript-devel] node-terser_5.15.0-1_source.changes ACCEPTED into unstable

[Yadd]

On 29/08/2022 18:24, Jonas Smedegaard wrote:

Quoting Yadd (2022-08-29 17:16:58)

On 29/08/2022 16:46, Jonas Smedegaard wrote:

a) Why is patch 2001 still needed?  You kept parts of if despite terser
now being v5.  Yes, testsuite fails without that patch but I don't
understand why (suspect the cause being newer-than-expected jest).


yes this patch should be renamed. The part I kept wasn't related to
terser 5 but something else. This seems not be related to jest (existed
before jest update). I'll search from where comes this error


Thanks.

Do you mean within hours, or better that I file a bugreport to track
this?

Don't mean to rush you (and fixing this is not urgent), just don't want
to bother with a bugreport if you are as swift as commonly :-)


Sadly it's an upstream issue, snapshot changed (maybe with Node.js 
update): even with a `npm install && ./node_modules/.bin/jest 
test/test.js`, the same snapshot change is needed.


Test based on snapshots are often annoying since they generate 
false-positive regressions. You can replace this patch by a call to 
`jest -u`


Cheers,
Yadd

Bug#1018691: reportbug: nheko fails to start. Undefined symbol

[Shengjing Zhu]

On Mon, Aug 29, 2022 at 10:10:30AM -0400, Hubert Chathi wrote:
> On Mon, 29 Aug 2022 06:35:57 +0200, Enrique Garcia  said:
> 
> > It is not possible to launch nheko in Debian testing:
> 
> > $ nheko
> > nheko: symbol lookup error: nheko: undefined symbol:
> > _ZN6spdlog5sinks18rotating_file_sinkISt5mutexEC1ENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEmmb
> 
> This is a bug with spdlog:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015742
> 
> I believe it will be fixed the next time nheko gets built (either as a
> binNMU or as a new upload -- which I should be doing soon to fix
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881965).
> 

It has already been binNMU in unstable. Version 0.10.0-1+b1 is good.

But nheko failed to migrate to testing due to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017752

Bug#1018746: RFS: golang-github-mazznoer-colorgrad/0.9.0-1 -- Color scales library for maps, charts, data-visualization and creative coding

[Gabriel M Dutra]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package 
"golang-github-mazznoer-colorgrad":


* Package name : golang-github-mazznoer-colorgrad
Version : 0.9.0-1
* URL : https://github.com/mazznoer/colorgrad
* License : MIT
* Vcs : 
https://salsa.debian.org/go-team/packages/golang-github-mazznoer-colorgrad

Section : golang

The source builds the following binary packages:

golang-github-mazznoer-colorgrad-dev - Color scales library for maps, 
charts, data-visualization and creative coding


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


https://mentors.debian.net/package/golang-github-mazznoer-colorgrad/

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

dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-mazznoer-colorgrad/golang-github-mazznoer-colorgrad_0.9.0-1.dsc


Changes for the initial release:

golang-github-mazznoer-colorgrad (0.9.0-1) unstable; urgency=low
.
* Initial release (Closes: TODO)

Regards,

Bug#1018697: deb-scrub-obsolete: please document the RELEASE names

[Martin Quinson]

tags 1018697 +pending
thanks

Le lundi 29 août 2022 à 12:52 +0100, Jelmer Vernooij a écrit :
> tags 1018697 +confirmed
> thanks
> 
> Hi Martin,
> 
> Thanks for the bug report.
> 
> On Mon, Aug 29, 2022 at 09:40:58AM +0200, Martin Quinson wrote:
> > I am always reluctant to apply the merge requests of deb-scrub-obsolete,
> > because I'm not sure of which release I cut off while applying these
> > changes.
> > It would be really helpful if the script could augment the changelog to add
> > the
> > release name since which the removed versionning is useless, please.
> 
> There is a release name in the changelog entry at the moment. Do you
> have a proposed format/wording for the changelog?

My bad. I should have re-tested it before filling this bug report. Older MR
opened by the Debian Janitor did not mention it, so I have many such MR rotting
on salsa, but they were fixed in between. Ahem, I'm ashamed.

Taging the bug as pending as only the following was valid, and you fixed it.
Thanks!

> > Along the same line, it could be helpful to document in the deb-scrub-
> > obsolete
> > manpage the list of accepted releases. In particular, I'm wondering whether
> > I
> > have to use a codename such as bookworm, or whether an alias such as old-
> > old-
> > stable is acceptable.
> Both should work, but I've just added a note in the manpage. Thanks!
> 
> I'll leave the bug report open for the first issue.
> 
> Cheers,
> 
> Jelmer



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

Bug#1016003: yt-dlp: little script

[Unit 193]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384


Howdy,

This concept sounds like a great idea to share in #994151 as they try to 
decide what to do with the youtube-dl package.  Given some[0] responses[1] 
on youtube-dl's bug tracker, I don't imagine picking up new versions will 
be an option any time soon.



Regards,
~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

[0]: https://github.com/ytdl-org/youtube-dl/issues/31190
[1]: https://github.com/ytdl-org/youtube-dl/issues/28859#issuecomment-1158188788


On Mon, 01 Aug 2022 20:10:42 +0200 michel  wrote:

I fleshed out the proposal a bit more. The simplest possibillity is to make 
symlinks, of both
the executable and module, to pretend they are youtube-dl and the module 
youyube_dl. This way,
also python programs that load the module could work.

A little bit better is this little wraper. you link the exec and module to it.

--
#!/usr/bin/python3

import sys
from yt_dlp import *

if __name__ == "__main__":

args=sys.argv.copy()
args.pop(0)
args=['--compat-options','youtube-dl']+args

main(args)



The compat options should improve the compatibility. Also, by using the cli 
options, it would
risk less of breaking over time and keeping a fix stupid proof. Maybe a final 
improvement,
would be to initialise the appropriate variable for the compatibility options, 
so that they
are active in the module also. This would have a higher risk of breaking.

I tested this with pafy(has an unrelated bug) and mpv on stable.

This should stay relevent, for a whille.

-BEGIN PGP SIGNATURE-

iQJIBAEBCQAyFiEEjbPlhoZdK0orGFpcUAHhsJqjdEsFAmMNRzkUHHVuaXQxOTNA
dW5pdDE5My5uZXQACgkQUAHhsJqjdEsf/g//aAwJxAOk0ag1UATT2Qui85kUA2x0
BA+WQ6F4EijSjkmze1qhakR8Qlxc2BDJf5T7r/RMnagcqzRqrM+2j2smoNbTcxHd
fJfV9I2yPYgtAW+ieydqacWOSFHg+P1atG+MAgHJdV7klWAeyCFDnX4Bh2GvQeZF
PsXHPFHyK6WdsGXUiZyUz9workcW4w/wFVljp2mQi63aLDj835E9AZDMJgtJdfZV
x71H5hRoAGxvmjgp69C7D9bhVzJeFVw1I8KDII1Uga84hW5gPVrv8+tWElDVankm
fgOoc6pJ/nWDOaUulk/+DFztZ2CF+HoTn0i9yZt3Sz7XDJPV+ldY9O7Hz2iK77FL
5g+XzEJcK1cLsFDjjcLbLbf0HHU4inwl+ZzYkLuWR04TnzVMXSivFkDZF/JO+LtC
b3ASX37jKT8sV311hUxGzociyYFBVhrfj5N1hj2pUY5AUU2GkW/dOo5SVW4tyyKr
gPlJ9HgjwknPlKtTfJXgJvqqUuzdCvzdbsbDcrB77kLQfZI3Meb6XCQeT6yedavM
p4JRSdpM/3Q5GeyjNBQPM1B9QByNu2vyUwN3wsZmFjHSmUGDTtHf2IexGRxHhGzI
5tL1jDP2IEkv3sTDOCRJPWkXDYehPzwM6uzvuRY5wA80mJAS8cWI/NwzPSK7iZVn
rxInIT6l005IxwQ=
=pMQh
-END PGP SIGNATURE-

Bug#1018744: bullseye-pu: package inetutils/2:2.0-1+deb11u1

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@security.debian.org

Hi!

[ Reason ]

A recent vulnerability (DoS) was reported upstream, for which I
uploaded a fixed package to sid (will migrate tomorrow). There was a
(minor) pending security update missing from bullseye. The security
team (CCed) would prefer to see these handled as normal stable updates.

[ Impact ]

These are both security issues. One against malicious ftp servers
which can end up controlling the client to connect to other hosts,
the other a DoS on the telnetd server which makes it crash with
specific two-byte payloads.

[ Tests ]

For the ftp client, there's a test recipe at
.

For the telnetd server there's a test recipe at

which amounts to «printf "\xff\xf7" | nc -n -v localhost 23».

Both test recipes could be reproduced before, and do not work after
the patched version.

[ Risks ]

The fix for the ftp client has been in sid since 2021-09 with no
reported regressions.

The fix for telnetd has not yet migrated to testing, but is few lines
long fixing a couple of NULL pointer dereferences.

[ Checklist ]

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

[ Changes ]

  * Fix inetutils-ftp security bug trusting FTP PASV responses.
Fixes CVE-2021-40491. Closes: #993476
  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
adapted by Erik Auerswald .

[ Other info ]

None.

Thanks.
Guillem
diff -Nru inetutils-2.0/debian/changelog inetutils-2.0/debian/changelog
--- inetutils-2.0/debian/changelog  2021-02-05 23:14:20.0 +0100
+++ inetutils-2.0/debian/changelog  2022-08-28 16:01:41.0 +0200
@@ -1,3 +1,14 @@
+inetutils (2:2.0-1+deb11u1) bullseye; urgency=medium
+
+  * Fix inetutils-ftp security bug trusting FTP PASV responses.
+Fixes CVE-2021-40491. Closes: #993476
+  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
+a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
+or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
+adapted by Erik Auerswald .
+
+ -- Guillem Jover   Sun, 28 Aug 2022 16:01:41 +0200
+
 inetutils (2:2.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
--- 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
1970-01-01 01:00:00.0 +0100
+++ 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
2022-08-28 16:01:41.0 +0200
@@ -0,0 +1,59 @@
+From 58cb043b190fd04effdaea7c9403416b436e50dd Mon Sep 17 00:00:00 2001
+From: Simon Josefsson 
+Date: Wed, 1 Sep 2021 09:09:50 +0200
+Subject: [PATCH] ftp: check that PASV/LSPV addresses match.
+
+* ftp/ftp.c (initconn): Validate returned addresses.
+---
+ ftp/ftp.c | 21 +
+ 2 files changed, 30 insertions(+)
+
+diff --git a/ftp/ftp.c b/ftp/ftp.c
+index d21dbdd8..7513539d 100644
+--- a/ftp/ftp.c
 b/ftp/ftp.c
+@@ -1365,6 +1365,13 @@ initconn (void)
+ uint32_t *pu32 = (uint32_t *) _addr_sa4->sin_addr.s_addr;
+ pu32[0] = htonl ( (h[0] << 24) | (h[1] << 16) | (h[2] << 8) | 
h[3]);
+   }
++  if (data_addr_sa4->sin_addr.s_addr
++  != ((struct sockaddr_in *) )->sin_addr.s_addr)
++{
++  printf ("Passive mode address mismatch.\n");
++  (void) command ("ABOR");/* Cancel any open connection.  
*/
++  goto bad;
++}
+   } /* LPSV IPv4 */
+ else /* IPv6 */
+   {
+@@ -1395,6 +1402,13 @@ initconn (void)
+ pu32[2] = htonl ( (h[8] << 24) | (h[9] << 16) | (h[10] << 8) 
| h[11]);
+ pu32[3] = htonl ( (h[12] << 24) | (h[13] << 16) | (h[14] << 
8) | h[15]);
+   }
++  if (data_addr_sa6->sin6_addr.s6_addr
++  != ((struct sockaddr_in6 *) )->sin6_addr.s6_addr)
++{
++  printf ("Passive mode address mismatch.\n");
++  (void) command ("ABOR");/* Cancel any open connection.  
*/
++  goto bad;
++}
+   } /* LPSV IPv6 */
+   }
+   else /* !EPSV && !LPSV */
+@@ -1415,6 +1429,13 @@ initconn (void)
+| ((a2 & 0xff) << 8) | (a3 & 

Bug#1016706: transition: GNOME 43 mega libsoup3 transition

[Jeremy Bicha]

Control: tags -1 -moreinfo

The entangled libraries have been reduced to only:
- evolution-data-server
- geocode-glib
- gnome-online-accounts (no soname bump)
- libgweather4 (nosoname bump)
- librest

These are the auto-trackers:
https://release.debian.org/transitions/html/auto-evolution-data-server.html
https://release.debian.org/transitions/html/auto-geocode-glib.html
https://release.debian.org/transitions/html/auto-librest.html

Removals
===
These packages need to be removed from Testing:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org=evolution-3.46
cawbird is already in Sid only.
chatty also has a reverse dependency of meta-phosh. If chatty isn't fixed
in time, we'll
update meta-phosh to lower the Depends to Recommends.

Sourceful Uploads
===
To attempt to reduce breakage if apps try to use libsoup2 and libsoup3
simultaneously, I am adding breaks against apps that use more than one
library. And I will do sourceful uploads of these packages to bump their
dependencies:
- evolution-data-server
- geocode-glib
- gnome-online-accounts
- libgweather4
- librest
- bijiben
- evolution
- evolution-ews
- geary
- gnome-calendar
- gnome-clocks
- gnome-control-center
- gnome-initial-setup
- gnome-maps
- gnome-panel
- gnome-settings-daemon
- gnome-shell
- gnome-software
This means that most of the transition will need to migrate together.

The rest of the packages on the auto trackers will need to be binNMU'd.

We successfully completed this transition in Ubuntu today.

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#1015981: Should grokmirror be removed?

[Moritz Mühlenhoff]

severity 1015981 normal
reassign 1015981 ftp.debian.org
retitle 1015981 RM: grokmirror -- RoM; Depends on Python 2, unmaintained
thanks

Am Sun, Jul 24, 2022 at 08:20:21PM +0200 schrieb Moritz Muehlenhoff:
> Source: grokmirror
> Version: 1.0.0-1.1
> Severity: serious
> 
> Your package came up as a candidate for removal from Debian:
> - Still depends on Python 2
> - Last maintainer upload in 2016
> 
> If you disagree and want to continue to maintain this package,
> please just close this bug (and fix the open issues).
> 
> If you agree with the removal, please reassign to ftp.debian.org
> by sending the following commands to cont...@bugs.debian.org:
> 
> Otherwise I'll move forward and request it's removal in a month.

Reassigning for removal.

Cheers,
 Moritz

Bug#1015980: Should pd-aubio be removed?

[Moritz Mühlenhoff]

severity 1015980 normal
reassign 1015980 ftp.debian.org
retitle 1015980 RM: pd-aubio -- RoM; Depends on Python 2, unmaintained
thanks

Am Sun, Jul 24, 2022 at 08:17:27PM +0200 schrieb Moritz Muehlenhoff:
> Source: pd-aubio
> Version: 0.4-1
> Severity: serious
> 
> Your package came up as a candidate for removal from Debian:
> - Still depends on Python 2
> - Last upload in 2014
> 
> If you disagree and want to continue to maintain this package,
> please just close this bug (and fix the open issues).
> 
> If you agree with the removal, please reassign to ftp.debian.org
> by sending the following commands to cont...@bugs.debian.org:
> 
> Otherwise I'll move forward and request it's removal in a month.

Reassigning for removal.

Cheers,
Moritz

Bug#1018743: squid: build failures because of -Wall -Werror

[Jeremy Bicha]

Source: squid
Version: 5.6-1
Severity: serious
Tags: bookworm sid ftbfs
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update regression

squid's autopkgtests are failing because it fails to build because it
sets -Wall -Werror which means the build will fail for *any* build
warning. Please override that.

Thank you,
Jeremy Bicha

Bug#1017094: false positive source-is-missing for gtk-doc generated html documentation

[Bastian Germann]

In general, it is not a good idea to have line length it as the only heuristic for checking source-is-missing on HTML 
files. I have seen this on many packages that I have dealt with in the last few months and all of them were false positives.

Bug#1018731: ghex wants to install document-modified-symbolic.svg which is already installed by gnome-text-editor

[Jeremy Bicha]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/ghex/-/issues/52

Thanks, I have reported this issue upstream.

Jeremy Bicha

Bug#1018742: /usr/bin/mate-display-properties: Cannot set different scaling on 2 monitors

[Geert Vantienen]

Package: mate-control-center
Version: 1.26.0-2
Severity: wishlist
File: /usr/bin/mate-display-properties
X-Debbugs-Cc: geert.vantie...@gmail.com

Dear Maintainer,


About: mate-display-properties
I have one 4K screen connected using DP and one HD screen connected using HDMI,
When setting scaling to automatic and then Apply, it looks fine, but it forgets 
after a reboot.
(and I have no sound, which seems to be a known issue)
So, I changed resolution to max for 4K + scaling 200%. That is fine on my first 
monitor,
but not good for my second (HD) monitor. After reboot, the setting is there, 
although it
shows (wrongly) 100% at the preference window.




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

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

Versions of packages mate-control-center depends on:
ii  caja-common 1.26.1-1
ii  desktop-file-utils  0.26-1
ii  gsettings-desktop-schemas   43~alpha-1
ii  libaccountsservice0 22.08.8-1
ii  libc6   2.34-4
ii  libcairo-gobject2   1.16.0-6
ii  libcairo2   1.16.0-6
ii  libcanberra-gtk3-0  0.30-10
ii  libcanberra00.30-10
ii  libdconf1   0.40.0-3
ii  libfontconfig1  2.13.1-4.4
ii  libfreetype62.12.1+dfsg-3
ii  libgdk-pixbuf-2.0-0 2.42.9+dfsg-1
ii  libglib2.0-02.72.3-1+b1
ii  libglib2.0-bin  2.72.3-1+b1
ii  libgtk-3-0  3.24.34-3
ii  libmarco-private2   1.26.0-2
ii  libmate-desktop-2-171.26.0-1
ii  libmate-slab0   1.26.0-2
ii  libmate-window-settings11.26.0-2
ii  libmatekbd4 1.26.0-1
ii  libpango-1.0-0  1.50.9+ds-1
ii  libpangocairo-1.0-0 1.50.9+ds-1
ii  libpolkit-gobject-1-0   0.105-33
ii  libx11-62:1.8.1-2
ii  libxcursor1 1:1.2.1-1
ii  libxi6  2:1.8-1
ii  libxklavier16   5.4-4
ii  libxml2 2.9.14+dfsg-1+b1
ii  libxss1 1:1.2.3-1
ii  marco-common1.26.0-2
ii  mate-control-center-common  1.26.0-2
ii  mate-desktop1.26.0-1
ii  mate-icon-theme 1.26.0-1
ii  mate-menus  1.26.0-3
ii  mate-settings-daemon1.26.0-1

mate-control-center recommends no packages.

Versions of packages mate-control-center suggests:
pn  gconf2  

-- no debconf information

Bug#1017960: libdrumstick 2.7.1-1 causes vmpk to stop making sound

[Pedro Lopez-Cabanillas]

On lunes, 29 de agosto de 2022 1:35:22 (CEST) Pedro Lopez-Cabanillas wrote:
> On domingo, 28 de agosto de 2022 23:52:09 (CEST) Ash Joubert wrote:
> > I can confirm that, after upgrading libdrumstick packages to 2.7.1-1,
> > configuring a FluidSynth MIDI connection restores functionality. The
> > missing step was to configure a sound font: the default "default.sf2"
> > does not exist. You might consider enhancing VMPK by changing the
> > default or autodetecting or even recommending a well-known sound font
> > package.
> 
> The name "default.sf2" is the default value of a setting from the
> fluidsynth synthesizer:
> https://www.fluidsynth.org/api/settings_synth.html#settings_synth_default
> -soundfont
> 
> This setting can be changed at fluidsynth build time, and Debian sets it
> to "/usr/share/sounds/sf3/default-GM.sf3". Upon installing the
> libfluidsynth3 library there is a dependency on the package
> "timgm6mb-soundfont" which installs
> "/usr/share/sounds/sf2/TimGM6mb.sf2", so maybe you shouldn't need to
> look for more soundfonts after all. But all this smells like another
> different issue

It is a bug in drumstick-rt-fluidsynth. Upstream ticket:
https://sourceforge.net/p/drumstick/bugs/46/

Regards,
Pedro

Bug#1018740: debootstrap: better initialisisation of /etc/machine-id

[Holger Levsen]

Package: debootstrap
Version: 1.0.123+deb11u1
Severity: normal

Dear Maintainer,

after debootstrapping, /etc/machine-id has a regular machine-id as contents
which seems suboptimal as its unreproducible and also, and foremost, this
can have nasty side-effects...

So probably it would be better to either remove the file or write 
"uninitialized"
into it... or support both via commandline flags :)

from #debian-devel today:

< bluca> for an image builder program, you can do two things with machine-id
< bluca> if you want the first boot logic to apply, you can initialize it to 
"uninitialized"
< bluca> if you don't want the first boot logic, have it as an empty file
< kibi> I think the behaviour changed between buster and bullseye; not sure 
what happened since
< kibi> (based on my recollection of 

https://salsa.debian.org/raspi-team/image-specs/-/commit/26a7de63b0bb3de1b5d0c4d0529240721c322dbb
 for pi images)
< Md> | h01ger: when creating an image it is better to have an empty 
/etc/machine-id than just deleting it, because 
  this way something can bind-mount a writeable file over it in 
early boot
<  josch> | h01ger: in case it helps, mmdebstrap writes "uninitialized" to 
/etc/machine-id
< bluca> empty -> no first boot semantics, uninitialized -> first boot semantics
< bluca> doc ref for the bug: 
https://www.freedesktop.org/software/systemd/man/machine-id.html#First%20Boot%20Semantics


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

I'll believe in climate change when Texas freezes over. (Ted Cruz)


signature.asc
Description: PGP signature

Bug#1009329: New upstream version 2.7.1 - Please package

[Amr Ibrahim]

Please update keepassxc to the latest version 2.7.1 in Debian unstable.

Bug#1018335: datalad-container: build-depends on python3-nose or uses it for autopkgtest

[Yaroslav Halchenko]

FWIW -- I was wrong (got lost in datalad extensions).  -container is not
yet migrated to pytest but will be shortly!

On Mon, 29 Aug 2022, Yaroslav Halchenko wrote:


> Next upload will have it using pytest -- we have migrated to pytest
> recently upstream

> Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: PGP signature

Bug#1018335: datalad-container: build-depends on python3-nose or uses it for autopkgtest

[Yaroslav Halchenko]

Next upload will have it using pytest -- we have migrated to pytest
recently upstream

Cheers,

On Sun, 28 Aug 2022, Dmitry Shachnev wrote:

> Source: datalad-container
> Version: 1.1.6-0.1
> User: python-modules-t...@lists.alioth.debian.org
> Usertags: nose-rm

> Dear Maintainer,

> Your package still uses nose [1], which is an obsolete testing framework for
> Python, dead and unmaintained since 2015 [2][3].

> If you received this bug report, it means that your package either has a
> build-dependency on python3-nose or uses that package in debian/tests/control.
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: PGP signature

Bug#1016598: binoculars: vtk[6,7] removal

[Adrian Bunk]

On Wed, Aug 03, 2022 at 10:35:42PM +0200, Sebastian Ramacher wrote:
> Source: binoculars
> Version: 0.0.11-1
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
> Tags: sid bookworm
> Control: block 1016597 by -1
> User: gl...@debian.org
> Usertags: vtk6_vtk7_removal
> 
> Based on #1013156 and similar bugs:
> 
> Dear maintainer,
> 
> Debian archive has now three major versions of the VTK (The
> Visualization Toolkit) package: vtk6, vtk7 and vtk9. Old vesions
> (vtk6 and vtk7) are not supported by upstream and the package itself
> is not easy for the mainance.
> 
> We aim to drop old and deprecated version vtk6 and vtk7 packages before
> the freeze of the Debian 12 Bookworm. Your package depends on vtk6 or
> vtk7. Thus we ask you to migrate it to the latest vtk9 package.

The only usage seems to be in one place:
/usr/lib/python3/dist-packages/binoculars/space.py:from vtk import 
vtkImageData, vtkXMLImageDataWriter
/usr/lib/python3/dist-packages/binoculars/space.py:from vtk.util import 
numpy_support
/usr/lib/python3/dist-packages/binoculars/space.py:image_data = 
vtkImageData()
/usr/lib/python3/dist-packages/binoculars/space.py:temp_array = 
numpy_support.numpy_to_vtk(temp_array, deep=1)
/usr/lib/python3/dist-packages/binoculars/space.py:writer = 
vtkXMLImageDataWriter()

And this does not even seem to be used right now:
https://github.com/picca/binoculars/commit/ec68d5c0ac656f8421dc27d852b064c1ce75800e

> Cheers

cu
Adrian

Bug#1018684: vmpk: program incompletely applied after restart

[Pedro Lopez-Cabanillas]

Hi,

> if I select a "Program" such as "Rhodes Piano", this selection is
> displayed after restart but "Acoustic Grand Piano" is played. Program
> "Rhodes Piano" must be selected again after restart for this option to
> take effect.

Yes, this behavior is deliberated. It does not only apply to the MIDI 
program, but also to all MIDI channel settings.

VMPK saves the state of the screen widgets and, upon startup, the saved 
values are retrieved and presented to the user again. Most software 
synthesizers, on the other hand, do not remember the last MIDI channel 
states when started, and initialize their MIDI engines with default values 
instead. This is not the case for most professional hardware MIDI 
synthesizers, which typically also remember their latest state. The problem 
is that when using VMPK with synths that don't save its MIDI state there is 
the inconsistency that you have observed.

There is a setting in VMPK for you: Edit->Preferences->Behavior tab, 
checkbox "MIDI channel state consistency". When this setting is enabled 
provides consistency between the screen widgets and the synthesizer's 
state. This means lots of data sent to the MIDI OUT port of VMPK at 
startup, so it should be used only when really needed.

By the way, this was already reported here, 10 years ago:
https://sourceforge.net/p/vmpk/bugs/18/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663513

Don't hesitate to ask for support in the upstream project sites:
https://sourceforge.net/p/vmpk/support-requests/
https://github.com/pedrolcl/VMPK/discussions

Regards,
Pedro

Bug#1018739: src:libowfat: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: libowfat
Version: 0.30-4
Severity: serious
Control: close -1 0.32-3
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1014120

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:libowfat has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package fails to build from 
source, as reported in bug #1014120.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=libowfat



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018738: appdirs: please drop pypy-appdirs to enable removal of pypy

[Paul Gevers]

Source: appdirs
Version: 1.4.4-2
Severity: serious
Control: block 1011926 by -1

Hi all,

We're trying to remove pypy from testing. Please stop building
pypy-appdirs.

This is part of the python2 removal.

Paul

Bug#1016508: rapiddisk,rapiddisk-dkms: both ship /usr/src/rapiddisk-8.2.0-2/*

[Andreas Beckmann]

Followup-For: Bug #1016508
Control: found -1 8.2.0-3

The following files are still shipped by both packages:

usr/src/rapiddisk-8.2.0/Makefile
usr/src/rapiddisk-8.2.0/dkms.conf
usr/src/rapiddisk-8.2.0/rapiddisk-cache.c
usr/src/rapiddisk-8.2.0/rapiddisk.c
usr/src/rapiddisk-8.2.0/rapiddisk.txt


Andreas

Bug#1018279: python3-testpath: Empty binary package

[Emanuele Rocca]

On 28/08 10:04, Gordon Ball wrote:
> Package: python3-testpath
> Version: 0.6.0+dfsg-2

> The package is empty except for the changelog.

Proposed fix here:
https://salsa.debian.org/python-team/packages/testpath/-/merge_requests/1

Bug#967353: freeciv: depends on deprecated GTK 2

[Marko Lindqvist]

 For the future perspective: gtk2-client is dropped completely from
freeciv-3.1 development version. With our attempt to sync our feature
releases with various distributions' two-year release cycle, we are
expecting freeciv-3.1 to be in bookworm+1.


 - ML

Bug#1018737: /usr/bin/rst2man: rst2man: .TH 5th field shouldn't be empty

[Alejandro Colomar]

On 8/29/22 21:14, Alejandro Colomar wrote:

Package: python3-docutils
Version: 0.17.1+dfsg-2
Severity: normal
File: /usr/bin/rst2man
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com, gr...@gnu.org, Quentin Monnet 



Hi,

When rst2man has no information to generate the 5th field to the
.TH macro (the one that sets the title line, i.e., the header and
footer of the manual page), it generates it as an empty argument,
that is "".  groff(1) and mandoc(1) have good defaults for the 5th
field of .TH when it is not specified, so that most manual pages
should need to specify it, but to use that default, the field has


s/should/shouldn't/


to be missing, and an empty argument is an existing argument.
I'll show an example, which may be more explicative:


--
Alejandro Colomar



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018224: src:exempi: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Hi Michael

On 29-08-2022 14:23, Michael Biebl wrote:

As you are probably aware, this issue is known and tracked in [1].


Which I added as a blocker and mentioned in my message, so yes.

The 
package FTBFS after enabling the test suite. I raised this issue 
upstream but there is no real interest/motivation [2] on their part to 
address these (most likely endianess related) issues.

So I informed the s390x porters as well but got not feedback so far.


Ack, I saw the latter part.

To me it seems it's better to not continue ship a known broken package 
on s390x and think a partial architecture removal is probably the better 
alternative.


If you think the package indeed is severely broken, then removal sounds 
best. If its broken in some less common use cases, it may be OK to leave 
it for now (skipping those tests on 390x) and let the porters have a 
look when they have time.



Let me know what you think


It all depends on how broken it is. If you would consider the bugs found 
by the tests RC, then removal is the better choice unless a porter steps 
up to fix it. If the bugs would be important at most, than skipping 
broken tests on s390x sounds like the better option. Removal bugs are 
hard to time predict.


Paul

PS: I would not disable building on s390x if you have the test suite 
finding out severe problems (as the d/control file doesn't have negated 
architecture fields yet). Just getting the binary removed and FTBFS will 
prevent the architecture from building again.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018737: /usr/bin/rst2man: rst2man: .TH 5th field shouldn't be empty

[Alejandro Colomar]

Package: python3-docutils
Version: 0.17.1+dfsg-2
Severity: normal
File: /usr/bin/rst2man
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com, gr...@gnu.org, Quentin Monnet 



Hi,

When rst2man has no information to generate the 5th field to the
.TH macro (the one that sets the title line, i.e., the header and
footer of the manual page), it generates it as an empty argument,
that is "".  groff(1) and mandoc(1) have good defaults for the 5th
field of .TH when it is not specified, so that most manual pages
should need to specify it, but to use that default, the field has
to be missing, and an empty argument is an existing argument.
I'll show an example, which may be more explicative:

$ cat th1.man 
.TH title 7 1234-04-05 foo-1.0 fifth
$ man -P cat ./th1.man 
title(7)  fifth title(7)

foo‐1.01234‐04‐05   title(7)


$ cat th2.man 
.TH title 7 1234-04-05 foo-1.0 ""
$ man -P cat ./th2.man 
title(7)title(7)

foo‐1.01234‐04‐05   title(7)


$ cat th3.man 
.TH title 7 1234-04-05 foo-1.0
$ man -P cat ./th3.man 
title(7)Miscellaneous Information Manualtitle(7)

foo‐1.01234‐04‐05   title(7)


So, please remove that "" and just use 4 fields if there's no
information for filling it.

Cheers,

Alex


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

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

Versions of packages python3-docutils depends on:
ii  docutils-common  0.17.1+dfsg-2
ii  python3  3.10.6-1
ii  python3-roman3.3-1

Versions of packages python3-docutils recommends:
ii  libpaper-utils1.1.28+b1
ii  python3-pil   9.2.0-1+b1
ii  python3-pygments  2.12.0+dfsg-2

Versions of packages python3-docutils suggests:
pn  docutils-doc
pn  fonts-linuxlibertine | ttf-linux-libertine  
pn  texlive-lang-french 
ii  texlive-latex-base  2022.20220722-1
ii  texlive-latex-recommended   2022.20220722-1

-- no debconf information

Bug#1018736: postfix: Please add a dpkg-reconfigure option to masquerade From when smarthosting

[Karl O. Pinc]

Package: postfix
Version: 3.5.13-0+deb11u1
Severity: wishlist

Hello,

Many consumer ISPs won't relay outbound email unless it comes from the
email address associated with the account.

It would be nice if the Postfix pacakge had a configuration option so
that when a smarthost is used there is the option to masquerade
(envelope and regular header) the From address.  This gives the
"ordinary user" the ability to send outbound emails, which lets cron
and other system daemons email notifications that might otherwise be
lost in the local mail spool.  `reportbug` also works better when
outbound email is available, etc.


A sample debian/templates snippet:
-
Template: postfix/masquerade_from_address
Type: string
Default:
_Description: From address for all outbound mail:
 Many consumer ISPs will not deliver outbound email unless it comes
 from the email address(es) the ISP has assigned to the account.  You may
 designate one email address to be used as the From address in all
 email sent from this system.
 .
 Leave this value blank to prevent masquerading of outbound From addresses.
 .
 This entry affects both the envelope and header From addresses.
-


You may also want to add the following paragraph to the bottom of
Template: postfix/relayhost
-
.
Many consumer ISPs require all email to go through a relay host under
their control.  In these cases setting the relay host to your ISP's
server lets email reach the Internet.
-


Other options come to mind that would be useful when there's a
smarthost:

Using LMTP instead of SMTP.  Although perhaps this is
already taken care of because the relayhost syntax allows the choice
of port.  Maybe it wouldn't hurt to have the relayhost part of
debian/templates mention the SUBMISSION port, perhaps by example.

Configuring SASL authentication.  But SASL seems like it could be a
nest-of-worms, unless ISPs have more-or-less standardized.  (Is it
PLAIN over TLS or )  The utility of going down this road is not
clear to me, although it can be "nice" to have something that holds
your hand when configuring.  A simple initialization/use of a single
SASL username/password (as here:
https://www.linkedin.com/pulse/how-setup-postfix-relay-host-federico-panini)
could be nice.  But only if it would mostly-work.

Regards,
Karl

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

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

Versions of packages postfix depends on:
ii  adduser3.118
ii  cpio   2.13+dfsg-4
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.11
ii  e2fsprogs  1.46.2-2
ii  libc6  2.31-13+deb11u3
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libicu67   67.1-7
ii  libnsl21.3.0-2
ii  libsasl2-2 2.1.27+dfsg-2.1+deb11u1
ii  libssl1.1  1.1.1n-0+deb11u3
ii  lsb-base   11.1.0
ii  netbase6.3
ii  ssl-cert   1.1.0+nmu1

Versions of packages postfix recommends:
ii  ca-certificates  20210119
ii  python3  3.9.2-3

Versions of packages postfix suggests:
ii  bsd-mailx [mail-reader]   8.1.2-0.20180807cvs-2
ii  claws-mail [mail-reader]  3.17.8-1+b1
ii  emacs-nox [mail-reader]   1:27.1+1-3.1
ii  libsasl2-modules  2.1.27+dfsg-2.1+deb11u1
ii  mailutils [mail-reader]   1:3.10-3+b1
pn  postfix-cdb   
pn  postfix-doc   
pn  postfix-ldap  
pn  postfix-lmdb  
pn  postfix-mysql 
pn  postfix-pcre  
pn  postfix-pgsql 
ii  postfix-sqlite3.5.13-0+deb11u1
ii  procmail  3.22-26+deb11u1
pn  resolvconf
ii  sylpheed [mail-reader]3.7.0-8
pn  ufw   

-- debconf information excluded

Bug#967353: freeciv: depends on deprecated GTK 2

[Marko Lindqvist]

On Mon, 29 Aug 2022 at 21:45, Tobias Frost  wrote:
>
> On Mon, Aug 29, 2022 at 08:33:12PM +0200, Stephen Kitt wrote:
> > Hi,
> >
> > On Mon, 29 Aug 2022 20:06:12 +0200, Tobias Frost  wrote:
> > > On Tue, 04 Aug 2020 11:38:27 +0100 s...@debian.org wrote:
> > > > Source: freeciv
> > > > Severity: normal
> > > > User: pkg-gnome-maintain...@lists.alioth.debian.org
> > > > Usertags: gtk2 oldlibs
> > > > Control: block 947713 by -1
> > > >
> > > > This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
> > > > binary packages with a Depends on GTK 2.
> > >
> > > (...)
> > >
> > > Upstream says in 3.0.3 (doc/README.packaging):
> > > > * Gtk2-client is no longer considered maintained client

 Read that as: "We don't promise anything."

 In practice it's better than ever (some bug fixes still trivially
ported from other gtk-clients). Just if there's, e.g., going to be a
build breakage with newer compilers or other tools, upstream is not
going to waste time on fixing those. That said, it does compile with
both current gcc-snapshot and clang-15 of Debian Sid.


 - ML

Bug#1018735: rtpengine: FTBFS with libwebsockets/4.3+

[GCS]

Source: rtpengine
Version: 1:10.0.0+r36-5
Severity: important
Usertags: libwebsockets4.3
Tags: ftbfs upstream bookworm sid

Hi,

Soon I would like to ask for libwebsockets 4.3.2 transition. Your
package fails to build with it in its self-testing. But it seems your
upstream has a newer release [1] with a change noted as:
websockets test: update for Python 3.10

Please package it as your time permits to let me do the libwebsockets
transition.

Thanks,
Laszlo/GCS
[1] 
https://github.com/sipwise/rtpengine/commit/b1242befd2e7a2550e89c2b050aa6661c4e1f6ee

Bug#1018734: driftnet: FTBFS with libwebsockets/4.3+

[GCS]

Source: driftnet
Version: 1.3.0+dfsg-2
Severity: important
Usertags: libwebsockets4.3
Tags: ftbfs upstream bookworm sid

Hi,

Soon I would like to ask for libwebsockets 4.3.2 transition. Your
package fails to build with it. Your upstream released 1.4.0 a while
ago and its changelog states:
Add libwebsockets >= 4.3.0 support

Please package it as your time permits to let me do the libwebsockets
transition.

Thanks,
Laszlo/GCS
[1] https://github.com/deiv/driftnet/releases

Bug#967353: freeciv: depends on deprecated GTK 2

[Tobias Frost]

On Mon, Aug 29, 2022 at 08:33:12PM +0200, Stephen Kitt wrote:
> Hi,
> 
> On Mon, 29 Aug 2022 20:06:12 +0200, Tobias Frost  wrote:
> > On Tue, 04 Aug 2020 11:38:27 +0100 s...@debian.org wrote:
> > > Source: freeciv
> > > Severity: normal
> > > User: pkg-gnome-maintain...@lists.alioth.debian.org
> > > Usertags: gtk2 oldlibs
> > > Control: block 947713 by -1
> > > 
> > > This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
> > > binary packages with a Depends on GTK 2.  
> > 
> > (...)
> > 
> > Upstream says in 3.0.3 (doc/README.packaging):
> > > * Gtk2-client is no longer considered maintained client  
> > 
> > So I guess the gtk2 client should not be released with bookworm…
> > 
> > Any thoughts (question directed to the games team)?
> 
> It’s gone entirely in 3.0.3, isn’t it? So if you’re upgrading to that
> release, it seems the freeciv-gtk package should be dropped (or rather,
> turned into a transitional package pulling freeciv-gtk3).

The client is still there in 3.0.3 (but needs to be enabled manually,
at least it builds; not yet there to see if it works…)

-- 
tobi

Bug#1018732: mir-core: FTBFS: ERROR: Unable to detect linker for compiler `ldc2 -L=--version /tmp/tmpq8z68wht.d -Wl,-z,relro -O -g -release -wi`

[Matthias Klumpp]

Control: reassign -1 meson 0.63.1-1
Control: forcemerge -1 1017087
Control: affects 1017087 + mir-core

This is due to a regression in Meson itself reported as bug #1017087
Hopefully we will get a fix into Debian soon, merging this with the
original bug.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1018733: RFP: htmlq -- uses CSS selectors to extract bits of content from HTML file

[Francois Marier]

Package: wnpp
Severity: wishlist

* Package name: htmlq
  Version : 0.4.0
  Upstream Author : Michael Maclean 
* URL : https://github.com/mgdm/htmlq
* License : MIT
  Programming Lang: Rust
  Description : uses CSS selectors to extract bits of content from HTML file

Like jq, but for HTML. Uses CSS selectors to extract bits of content from HTML 
files.

Bug#967353: freeciv: depends on deprecated GTK 2

[Stephen Kitt]

Hi,

On Mon, 29 Aug 2022 20:06:12 +0200, Tobias Frost  wrote:
> On Tue, 04 Aug 2020 11:38:27 +0100 s...@debian.org wrote:
> > Source: freeciv
> > Severity: normal
> > User: pkg-gnome-maintain...@lists.alioth.debian.org
> > Usertags: gtk2 oldlibs
> > Control: block 947713 by -1
> > 
> > This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
> > binary packages with a Depends on GTK 2.  
> 
> (...)
> 
> Upstream says in 3.0.3 (doc/README.packaging):
> > * Gtk2-client is no longer considered maintained client  
> 
> So I guess the gtk2 client should not be released with bookworm…
> 
> Any thoughts (question directed to the games team)?

It’s gone entirely in 3.0.3, isn’t it? So if you’re upgrading to that
release, it seems the freeciv-gtk package should be dropped (or rather,
turned into a transitional package pulling freeciv-gtk3).

Regards,

Stephen


pgpeaw_jMrz5W.pgp
Description: OpenPGP digital signature

Bug#1018732: mir-core: FTBFS: ERROR: Unable to detect linker for compiler `ldc2 -L=--version /tmp/tmpq8z68wht.d -Wl,-z,relro -O -g -release -wi`

[Sebastian Ramacher]

Source: mir-core
Version: 1.1.111-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=mir-core=arm64=1.1.111-1=1661205784=0

Source dir: /<>
Build dir: /<>/obj-aarch64-linux-gnu
Build type: native build
Project name: mir-core
Project version: 1.1.1

../meson.build:1:0: ERROR: Unable to detect linker for compiler `ldc2 
-L=--version /tmp/tmpq8z68wht.d -Wl,-z,relro -O -g -release -wi`
stdout: 
stderr: ldc2: Unknown command line argument '-Wl,-z,relro'.  Try: 'ldc2 --help'
ldc2: Did you mean '--icp-lto'?


A full log can be found at 
/<>/obj-aarch64-linux-gnu/meson-logs/meson-log.txt
cd obj-aarch64-linux-gnu && tail -v -n \+0 meson-logs/meson-log.txt
==> meson-logs/meson-log.txt <==
Build started at 2022-08-22T22:02:57.759199
Main binary: /usr/bin/python3
Build Options: -Dprefix=/usr -Dlibdir=lib/aarch64-linux-gnu 
-Dlocalstatedir=/var -Dsysconfdir=/etc -Dbuildtype=plain -Ddefault_library=both 
-Dwrap_mode=nodownload
Python system: Linux
The Meson build system
Version: 0.63.1
Source dir: /<>
Build dir: /<>/obj-aarch64-linux-gnu
Build type: native build
Project name: mir-core
Project version: 1.1.1
-
Detecting compiler via: cc --version
compiler returned 
compiler stdout:
cc (Debian 12.1.0-8) 12.1.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


compiler stderr:

Running command: cc -E -dM -
-
Detecting linker via: cc -Wl,--version -Wl,-z,relro -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
linker returned 
linker stdout:
GNU ld (GNU Binutils for Debian) 2.38.90.20220713
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

linker stderr:
collect2 version 12.1.0
/usr/bin/ld -plugin /usr/lib/gcc/aarch64-linux-gnu/12/liblto_plugin.so 
-plugin-opt=/usr/lib/gcc/aarch64-linux-gnu/12/lto-wrapper 
-plugin-opt=-fresolution=/tmp/cchsFxXu.res -plugin-opt=-pass-through=-lgcc 
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc 
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id 
--eh-frame-hdr --hash-style=gnu --as-needed -dynamic-linker 
/lib/ld-linux-aarch64.so.1 -X -EL -maarch64linux --fix-cortex-a53-843419 -pie 
/usr/lib/gcc/aarch64-linux-gnu/12/../../../aarch64-linux-gnu/Scrt1.o 
/usr/lib/gcc/aarch64-linux-gnu/12/../../../aarch64-linux-gnu/crti.o 
/usr/lib/gcc/aarch64-linux-gnu/12/crtbeginS.o 
-L/usr/lib/gcc/aarch64-linux-gnu/12 
-L/usr/lib/gcc/aarch64-linux-gnu/12/../../../aarch64-linux-gnu 
-L/usr/lib/gcc/aarch64-linux-gnu/12/../../../../lib -L/lib/aarch64-linux-gnu 
-L/lib/../lib -L/usr/lib/aarch64-linux-gnu -L/usr/lib/../lib 
-L/usr/lib/gcc/aarch64-linux-gnu/12/../../.. --version -z relro -lgcc 
--push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed 
-lgcc_s --pop-state /usr/lib/gcc/aarch64-linux-gnu/12/crtendS.o 
/usr/lib/gcc/aarch64-linux-gnu/12/../../../aarch64-linux-gnu/crtn.o

-
Detecting linker via: ldc2 -L=--version /tmp/tmpq8z68wht.d -Wl,-z,relro -O -g 
-release -wi
linker returned 
linker stdout:

linker stderr:
ldc2: Unknown command line argument '-Wl,-z,relro'.  Try: 'ldc2 --help'
ldc2: Did you mean '--icp-lto'?


../meson.build:1:0: ERROR: Unable to detect linker for compiler `ldc2 
-L=--version /tmp/tmpq8z68wht.d -Wl,-z,relro -O -g -release -wi`
stdout: 
stderr: ldc2: Unknown command line argument '-Wl,-z,relro'.  Try: 'ldc2 --help'
ldc2: Did you mean '--icp-lto'?

dh_auto_configure: error: cd obj-aarch64-linux-gnu && LC_ALL=C.UTF-8 meson .. 
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=lib/aarch64-linux-gnu --default-library=both 
returned exit code 1
make[1]: *** [debian/rules:11: override_dh_auto_configure] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:8: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2


Cheers
-- 
Sebastian Ramacher

Bug#1010660: britney: Crash with RecursionError: maximum recursion depth exceeded

[Paul Gevers]

Hi,

tl;dr: we need to cook up a similar patch as 
bd375fdd85b4e00b89fb087760369bb6f3df0a20 for the migration phase of britney.


We recently experienced this problem in Debian too.

Traceback (most recent call last):
  File "/srv/release.debian.org/britney/code/b2/britney.py", line 1586, 
in 

Britney().main()
  File "/srv/release.debian.org/britney/code/b2/britney.py", line 1573, 
in main

self.upgrade_testing()
  File "/srv/release.debian.org/britney/code/b2/britney.py", line 1244, 
in upgrade_testing

self.run_auto_hinter()
  File "/srv/release.debian.org/britney/code/b2/britney.py", line 1518, 
in run_auto_hinter

for lst in self.get_auto_hinter_hints(self.upgrade_me):
  File "/srv/release.debian.org/britney/code/b2/britney.py", line 1482, 
in get_auto_hinter_hints

hint = find_related(e, set(), True)
  File "/srv/release.debian.org/britney/code/b2/britney.py", line 1471, 
in find_related

if not find_related(p, hint):
  File "/srv/release.debian.org/britney/code/b2/britney.py", line 1471, 
in find_related

if not find_related(p, hint):
  File "/srv/release.debian.org/britney/code/b2/britney.py", line 1471, 
in find_related

if not find_related(p, hint):
  [Previous line repeated 989 more times]
  File "/srv/release.debian.org/britney/code/b2/britney.py", line 1465, 
in find_related

hint.add(excuse.item)
  File 
"/srv/release.debian.org/britney/code/b2/britney2/migrationitem.py", 
line 79, in __hash__

if not self.version:
RecursionError: maximum recursion depth exceeded

We discussed it on IRC and Sebastian worked around it...

[2022-08-28 UTC+2]

[16:20:20]  elbrus: With the blocks on nginx and 
openimageio/opencolorio removed, britney still crashes

[16:30:11]  s/nginx and//g
[20:34:39]  Sebastinas: so you added hints to "unbreak" britney?
[20:34:48]  yes

[20:35:09]  we should save the current state of the archive for 
britneys test suite

[20:35:22]  but I forgot how that worked
[20:35:55] -*- elbrus will try to figure it out, hopefully in time

[20:36:55]  elbrus: The circular dependency of 
openimageio/opencolorio triggers an endless recursion in the auto-hinter
[20:37:31]  aha, now that's something that sounds like an 
actionaly bug report for britney

[20:37:57]  if we can reproduce the failure in a test

Thankfully Niels joined the discussion as he experienced the issue 
before in the policy phase of britney:


[20:38:12]  I am surprised, I thought the auto-hinter had 
infinite-recursion detection already

[20:38:48]  nthykier: if it's not in a test, it can be broken ;)
[20:39:33]  I think I've seen these kind of errors a couple of times
[20:39:41]   not so much in Debian
[20:48:20]  https://bpa.st/YSQA
[20:56:05]  not sure that is infinite to be honest
[20:56:49]  the other solver had to be rewritten to be 
iterative because it would stack overflow (because some clusters 
involved more then 1000 packages in a grouping)
[20:57:51]  guess that time has come for the legay auto-hinter 
as well now
[21:00:47]  (the net effect is the same - it is just more 
whether you will find a logical bug in the code or the code is "corect" 
and we just surpassed the limit )

[21:00:53]  correct*
[21:01:56]  nthykier: thanks for the information
[21:03:42]  nthykier: but how does making a solver iterative 
prevent recursion limits (it sounds like it's normally the cause of 
recursion)
[21:09:36]  elbrus: the iterative solution replaces the 
recursion (call stack) with a for-loop an a regular stack (python list). 
 The latter "only" limited by the amount of memory you have, where the 
former is much more limited

[21:09:52]  (s/for-loop/loop/)
[21:11:14]  nthykier: do you happen to have a commit ID that was 
involved in that rewrite (to get inpiration from if I need it)

[21:11:38]  bd375fdd85b4e00b89fb087760369bb6f3df0a20
[21:12:40]  thanks
[21:13:11]  5 years ago

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013744: ifenslave 2.13~deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1013744 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: ifenslave
Version: 2.13~deb11u1

Explanation: fix bonded interface configurations

Bug#967353: freeciv: depends on deprecated GTK 2

[Tobias Frost]

On Tue, 04 Aug 2020 11:38:27 +0100 s...@debian.org wrote:
> Source: freeciv
> Severity: normal
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: gtk2 oldlibs
> Control: block 947713 by -1
> 
> This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
> binary packages with a Depends on GTK 2.

(...)

Upstream says in 3.0.3 (doc/README.packaging):
> * Gtk2-client is no longer considered maintained client

So I guess the gtk2 client should not be released with bookworm…

Any thoughts (question directed to the games team)?

--
tobi

Bug#964565: freeciv: City governor choices wrong when loading saved game

[Tobias Frost]

On Mon, Aug 29, 2022 at 08:20:58PM +0300, Marko Lindqvist wrote:
> On Mon, 29 Aug 2022 at 20:15, Tobias Frost  wrote:
> >
> > Control: tags -1 upstream
> > Control: forwarded -1 https://www.hostedredmine.com/issues/857724
> >
> > Hi David,
> >
> > this looks like this could this upstream report:
> > https://www.hostedredmine.com/issues/857724
> >
> > I guess we need to wait until upstream provides a fix,
> > sorry. not much what we can do from here…
> 
> While the issue is not completely resolved,
> https://osdn.net/projects/freeciv/ticket/44304 greatly improved the
> situation for the single-player case. That fix is available in
> freeciv-3.0.2 ( https://www.freeciv.org/wiki/NEWS-3.0.2 )

Thanks for the update!

I'm currently trying to get the new version packaged; if all goes
well, 3.0.3 should land soon(tm) in Debian.

-- 
tobi

> 
>  - ML

Bug#1018731: ghex wants to install document-modified-symbolic.svg which is already installed by gnome-text-editor

[Christian Lauinger]

Package: ghex
Version: 43~alpha-3
Severity: normal

Dear Maintainer,

   * What led up to the situation?
try to install ghex from unstable
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
N/A
   * What was the outcome of this action?
could not be installed
Entpacken von ghex (43~alpha-3) ...
dpkg: Fehler beim Bearbeiten des Archivs
/var/cache/apt/archives/ghex_43~alpha-3
_amd64.deb (--unpack):
 Versuch, »/usr/share/icons/hicolor/scalable/actions/document-modified-
symbolic.
svg« zu überschreiben, welches auch in Paket gnome-text-editor 43~alpha1-1 ist
dpkg-deb: Fehler: »einfügen«-Unterprozess wurde durch Signal (Datenübergabe
unte
rbrochen (broken pipe)) getötet
Fehler traten auf beim Bearbeiten von:
 /var/cache/apt/archives/ghex_43~alpha-3_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

   * What outcome did you expect instead?
package can be installed



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

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

Bug#1018700: After migrating from thunderbird:amd64 da 1:91.10.0-1 -> 1:102.1.2-1 can't see any folder

[Carsten Schoenert]

Am 29.08.22 um 14:12 schrieb Giorgio Volpe:


What do you mean with "upstream TB binary"?


https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues

Point "O.k. a problem related to Thunderbird is still existing. What 
else can I do?", the last section that is about using pre-compiled 
binary package from MZLNA.


--
Regards
Carsten Schönert

Bug#1018302: New Upstream Version

[Kartik Mistry]

On Sun, Aug 28, 2022 at 11:39 PM Barak A. Pearlmutter
 wrote:
> Upstream 2.45 is out, and uses gtk3 and is antialiased.
> I've done a prelim packaging (including reworking the upstream
> autotools stuff in a patch), feel free to cannibalize any or all as
> you see fit; in salsa.debian.org/bap/xdaliclock

Thanks a lot! I should be able to upload a new package tomorrow.

-- 
Kartik Mistry | કાર્તિક મિસ્ત્રી
kartikm.wordpress.com

Bug#1018730: lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure

[Melvin Vermeeren]

Package: lvm2
Version: 2.03.16-1
Severity: important
X-Debbugs-Cc: vermee...@vermwa.re

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Since LVM 2.03.15 or possibly 2.03.16 my system fails to boot during initramfs
because the root LVM LV is not activated. I did some digging and confirmed this
is caused by the new method of using udev rules, which have a big flaw.

In /lib/udev/rules.d/69-lvm.rules a VG is only activated once the VG is fully
complete. However in initramfs my HDD arrays are not yet activated because they
need keyfile stored on root partition for automatic activation. This means the
VG is never complete (missing PVs) so it is never activated, meaning the root LV
is never activated at all, resulting in boot failure with initramfs shell.

I have the following storage stack in use on this system:
Disk partition -> integrity -> mdadm -> luks -> lvm -> ext4
Integrity is not part of Debian, I submitted patches a while ago at:
https://salsa.debian.org/cryptsetup-team/cryptsetup/-/merge_requests/22

My LVM setup is the following.
The fc520 contains root, swap LV and all integritysetup meta LVs.
The nas4 and ex12 PVs are exclusively used by hdd LV.

root@verm-r4e:~# pvs
  PV   VG   Fmt  Attr PSize  PFree
  /dev/mapper/md_ex12_0_crypt  verm-r4e lvm2 a--  10.91t   0
  /dev/mapper/md_fc520_0_crypt verm-r4e lvm2 a--   1.81t  256.77g
  /dev/mapper/md_nas4_0_crypt  verm-r4e lvm2 a--  <3.64t <565.54g
root@verm-r4e:~# vgs
  VG   #PV #LV #SN Attr   VSize  VFree
  verm-r4e   3   9   0 wz--l- 16.36t 822.31g
root@verm-r4e:~# lvs
  LV VG   Attr   LSize
  hddverm-r4e -wi-ao 14.00t
  is_boot_0_meta verm-r4e -wi-ao  8.00m
  is_boot_1_meta verm-r4e -wi-ao  8.00m
  is_ex12_0_meta verm-r4e -wi-ao 11.41g
  is_ex12_1_meta verm-r4e -wi-ao 11.41g
  is_nas4_0_meta verm-r4e -wi-ao  4.14g
  is_nas4_1_meta verm-r4e -wi-ao  4.14g
  root   verm-r4e -wi-ao  1.50t
  swap   verm-r4e -wi-ao 32.00g

Although my integrity setup is not common it's very common for servers with
many encrypted disks is to have something like this:

hdd -> mdadm -> luks -> lvm

With current version udev rules simply having all these disks in the same VG
will result in boot failure, because udev rule will only activate the entire VG
once all PVs are there.

The fix is to use behaviour like in old version and similar to cryptsetup hooks.
Actaully parse what is needed from kernel arg, fstab, etc and try to activate
these LVs directly even if the VG is incomplete. Concretely in my case the hook
should activate verm-r4e/swap (resume device) and verm-r4e/root (root).

This is quite a key regression for servers, as I'm not sure you can access
initramfs shell remotely when it drops into it. Maybe if you have
dropbear-initramfs setup? In my case it's on a workstation.

Could you share thoughts and/or investigate this problem?
Perhaps upstream udev rules are not suited for initramfs and only for regular
system operation once fully booted?

Thanks,

Melvin Vermeeren.

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

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

Versions of packages lvm2 depends on:
ii  dmeventd2:1.02.185-1
ii  dmsetup 2:1.02.185-1
ii  init-system-helpers 1.64
ii  libaio1 0.3.113-2
ii  libblkid1   2.38.1-1
ii  libc6   2.34-4
ii  libdevmapper-event1.02.12:1.02.185-1
ii  libedit23.1-20210910-1
ii  libselinux1 3.4-1+b1
ii  libsystemd0 251.3-1
ii  libudev1251.3-1
ii  lsb-base11.2
ii  systemd [systemd-tmpfiles]  251.3-1

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.9.0-2

lvm2 suggests no packages.

- -- Configuration Files:
/etc/lvm/lvm.conf changed [not included]
Edit: I set issue_discards = 1 only.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEEiu1YAh/qzdXye6Dmpy9idxbqnZYFAmMM7koUHHZlcm1lZXJl
bkB2ZXJtd2EucmUACgkQpy9idxbqnZbDvBAAtOAjlLnoQv6ashtTpuk0b/6MG3UW
BE/we/Z15SC2bsM59zpci9BMsFmfNvS5iVznDC0TRy9P0zaLS+jQ4T4NNd6KPLwe
5mRorEFMI7INwD8vWBkhhCzCXyU6Wp8jCOkngVMND04wU/zq56amKHFnQ9yGaqFl
/jLzTVnUQ2hxJNRvmbghX5x7n4SQw1oSNlBAG8i1Pz2mdMCH2cLWz+ieP2fCYffp
eHkFs+ECTkcnEvDIlRZuIx34+ZZAh2JI/2bPqCtQRZOWOUEujlQDlgEhgp0qORdU
wY2/q1dTsPOwFhgUUvgCtSS0o451E7boZ82EigaGFO/YXWvjiC0eS+rCXokQBJx+
cU89fjgnT/83WlDYN26TiVulX+2peXomZ5c4aCFHQ1jZTbsYePd0ucg2YbwzNAq7

Bug#1018277: gnome-shell-extension-sound-device-chooser: needs update for GNOME Shell 43

[Fabio A. De Muzio Tobich]

Em 28/08/2022 23:53, Jeremy Bicha escreveu:

I think this extension may be obsolete since GNOME Shell 43 now has a
sound device chooser built into the new system status menu.

Thank you,
Jeremy Bicha


Hi Jeremy,

I believe you're right.

I will confirm this and, if applicable, I will take the necessary steps to 
remove the package.

Thanks!

--
⢀⣴⠾⠻⢶⣦
⣾⠁⢠⠒⠀⣿⡁   Fabio Augusto De Muzio Tobich
⢿⡄⠘⠷⠚⠋⠀   9730 4066 E5AE FAC2 2683  D03D 4FB3 B4D3 7EF6 3B2E
⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008240: Inside mmdebstrap hooks, find /dev/ -type f matches irregular files

[Andreas Metzler]

Control: forcemerge 912180 1008240

On 2022-03-25 Johannes Schauer Marin Rodrigues  wrote:
> Quoting Trent W. Buck (2022-03-25 05:15:41)
>> I see a quite odd behaviour where "find ... -type f" inside a
>> customize hook is matching device files.  As a simple test, "find
>> /dev -type f" finds /dev/zero inside mmdebstrap, but not outside
>> mmdebstrap.

> the unshared user doesn't have permissions to run mknod but we still need
> devices like /dev/null in unshare mode. To solve this problem mmdebstrap
> bind-mounts /dev/null to a real file. You can reproduce your findings without
> mmdebstrap like so:

> sudo touch null
> sudo mount -t bind /dev/null null

s/ -t / -o /

> Now run your find and stat calls and you will get the same results as
> you did inside mmdebstrap in unshare mode. So this behaviour is not
> unique to the unshared user namespace but happens outside of it as
> well if you bind-mount device nodes on files.

FWIW this is a duplicate of 912180. Afaiu the upstream bug discussion
find uses getdents() and avoids unecessary stats(). However linux
returns incorrect information. The possible performance penalty might be
huge.

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#1012245: nvidia-graphics-drivers-tesla-470: fails on ppc64el due to transitive GPL symbol usage

[Paul Gevers]

Hi Andreas,

On 29-08-2022 02:13, Andreas Beckmann wrote:
The kernel running on the host should be irrelevant. Building the 
modules only needs the linux-headers-* packages in the chroot.


You probably know much better than I do, but if you want to test those 
modules, don't you need the matching kernel? Or can you build for any 
kernel and test without that kernel? Or are you just testing if you can 
build?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#994625: ITP: carl9170fw -- libre firmware for AR9170 USB wireless adapters

[Bastian Germann]

Do you still want to get carl9170fw into Debian?

Bug#796667: [freeciv-client-gtk] UpDown arrows in new game dialog do too much

[Tobias Frost]

Package: freeciv-client-gtk
Version: 2.6.3-1
Followup-For: Bug #796667
Control: close -1

On Mon, 24 Aug 2015 18:50:59 +0200 Markus Koschany  wrote:
> 
> All in all this seems to be intended and I don't consider this a bug
> myself. I'm therefore inclined to close this bug report.
> 

Doing so now.

Bug#1004870: python-xarray: autopkgtest regression on s390x

[Graham Inggs]

Hi Rebecca, Alastair

I triggered python-xarray's autopkgtest on s390x against pandas from
experimental [1].  See the test results from 2022-08-29 12:40:12 UTC.

I think the intended packages were tested together, based on seeing
the following files fetched in the log:

Get:28 http://deb.debian.org/debian experimental/main s390x
python3-pandas-lib s390x 1.4.3+dfsg-6 [2,852 kB]
Get:29 http://deb.debian.org/debian experimental/main s390x
python3-pandas all 1.4.3+dfsg-6 [2,785 kB]

I still see the same failures that were in the original bug report.

Even if this issue eventually is fixed in pandas, I'd prefer this bug
be assigned back to src:python-xarray in order to track the
autopkgtest regression in testing.

Regards
Graham


[1] https://ci.debian.net/packages/p/python-xarray/unstable/s390x/

Bug#1004471: Fwd: [Pkg-javascript-devel] node-terser_5.15.0-1_source.changes ACCEPTED into unstable

[Jonas Smedegaard]

Quoting Yadd (2022-08-29 17:16:58)
> On 29/08/2022 16:46, Jonas Smedegaard wrote:
> > a) Why is patch 2001 still needed?  You kept parts of if despite terser
> > now being v5.  Yes, testsuite fails without that patch but I don't
> > understand why (suspect the cause being newer-than-expected jest).
> 
> yes this patch should be renamed. The part I kept wasn't related to 
> terser 5 but something else. This seems not be related to jest (existed 
> before jest update). I'll search from where comes this error

Thanks.

Do you mean within hours, or better that I file a bugreport to track
this?

Don't mean to rush you (and fixing this is not urgent), just don't want
to bother with a bugreport if you are as swift as commonly :-)


> > b) Why do binary packages now contain file
> > /usr/share/nodejs/*/pkgjs-lock.json? Bug in pkg-js-tools, perhaps?
> 
> This files are automatically added to all package suspected to embed 
> copies of some other modules (ie built using webpack or rollup). We 
> discussed about that some months ago, it may help in case of CVE

Ohh, I see it now.  And I even commented on it - sorry for my failing
memory!


> > c) Why do testsuite for ascjs emit several errors without failing?
> > Bug in pkg-js-tools, perhaps?
> 
> Here:
>+ node Xascjs/test.js
>ascjs v5.0.1 - 33 tests
> 
>true both import and export can be overwritten 

Ah, I was mistaken: I talk about the instances of "console.error" that
can be seen e.g. at 
https://buildd.debian.org/status/fetch.php?pkg=node-rollup-plugin-terser=all=7.0.2%2B%7E5.0.1-3=1660820526=0

...and I see now that it is (not ascjs testsuite failures, but) main
testsuite explicitly provoking and checking a few failure modes, so it
is not test failures but intended noise.


 - Jonas

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

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

signature.asc
Description: signature

Bug#1018617: rocketcea: build-depends on python3-nose or uses it for autopkgtest

[Bdale Garbee]

tags 1018617 +help
thanks

Dmitry Shachnev  writes:

> Source: rocketcea
> Version: 1.1.18+dfsg-2
> User: python-modules-t...@lists.alioth.debian.org
> Usertags: nose-rm
>
> Dear Maintainer,
>
> Your package still uses nose [1], which is an obsolete testing framework for
> Python, dead and unmaintained since 2015 [2][3].

I noticed that upstream is now at 1.1.29 where our package is 1.1.18, so
I started by freshening the packaging repo to build 1.1.29.  Ironically,
the build fails in the test suite with a probably easy to fix error that
I just don't have time to work on today.

I note that tox.ini in the upstream source seems to imply either pytest
or nose can be used, but I'm not familiar enough with python test suites
to immediately know if this is just left-over boilerplate, or if moving
to pytest would be as simple as changing the tox.ini content?

If someone else who understands python test suites better than I do has
time to patch rocketcea to use a supported test suite and get 1.1.29 to
build to completion, I'd love to have that help. 

Regards,

Bdale


signature.asc
Description: PGP signature

Bug#1018728: dh-nodejs: long description promotes bad control file hint

[Jonas Smedegaard]

Package: dh-nodejs
Version: 0.14.36
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Long description mentions control file hint X-Javascript-Built-Using.

As explained by Mattia Rizzolo at Fri,  4 Feb 2022 16:47:20 +
(Message-ID: ), the hint need tp ue prefix
XB_ (not X-) to get included with metadata of binary packages.

Please adjust (also any code that might auto-inject it) to instead use
XB-Javascript-Built-Using.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmMM55wACgkQLHwxRsGg
ASEwCQ//dCDpdyQ0OYRMXOy897j+4gfvCxNdjQ+yQtGPEXCOyzC9h7rYJdjIv1dA
t6T4Y8yzwO0zMmzMXeBHXVM+URLjTG6ZK6BAitcr+WtRpEdWbu9z1wBBWLoiqgug
Q6s7sFpVv58+AfaIuVTRhELprTF+kJfn1I5hZBWwfJ7QGTKP0FA2BAiE+q1eMg+H
22yIGEcaVJ8oVuSL0BEG7608AiXiofjK0kDYpDApAWCRBGzS14ieeD3ib5/OU/3Z
emOdWHGSK8jLNMSM8T3VGxYogQwXKtJm5ZYYGHhNummNzB6QZ2hg4qakpmN1jywZ
8Mo1lHeIx57u8hbxddPZm9eX2F9QdgFnRSM3Q7wAV5Vp/zTQeImS7y1W3D+n56Ad
5zr+Pzu0kXLXI/AgaRNl6TJytIRjHQEuyYE+A0Zleae+4FJCVI3YuufPIPAT7sV/
Iqvryb1k0nL9eswRNgBAmOR7AtMKvA7oajBAVSW1dIVM/duCx+xifC2RqIqi/xN3
I+CTQBLjLwg+eDAIRy8tmG/J96K+cPdCP/HbQG+axbAaiqLns5TbRr/4vQI6oilr
UaH4pShRm1xOEQynGAgBGcVINDMRI3T9a8nHnFyGs1dAiZMHPT3mp7n/NAweMwGo
u8Cfp8JObpLXrR+w7bxX2vA+BWJS7AxuASmxorRJ+SUZE/XTaLg=
=tfZb
-END PGP SIGNATURE-

Bug#1018727: bash: after upgrade, aliases with embedded $() subcommands don't work

[Jon]

Package: bash
Version: 5.2~rc2-2
Severity: normal

Dear Maintainer,

The new version of bash breaks aliases if the alias has an $()
subcommand embedded inside of it:

$ alias foo='echo $(date)'
$ foo
$
Mon Aug 29 11:52:38 EDT 2022
$ foo
$ ls
Mon Aug 29 11:52:41 EDT 2022ls

The command is actually entering the history as "foo\nls" too:

  505  alias foo='echo $(date)'
  506  foo

  507  foo
ls
  508  history | tail -n 6

The alias appears to be loaded correctly:

$ alias foo
alias foo='echo $(date)'

Under bash 5.1 this worked fine:

$ alias foo='echo $(date)'
$ foo
Mon Aug 29 11:55:26 EDT 2022

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

Kernel: Linux 5.18.0-3-amd64 (SMP w/2 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 /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages bash depends on:
ii  base-files   12.2
ii  debianutils  5.7-0.3
ii  libc62.34-7
ii  libtinfo66.3+20220423-2

Versions of packages bash recommends:
pn  bash-completion  

Versions of packages bash suggests:
pn  bash-doc  

-- Configuration Files:
/etc/bash.bashrc changed [not included]

-- no debconf information

Bug#1004471: [Pkg-javascript-devel] Bug#1004471: Fwd: node-terser_5.15.0-1_source.changes ACCEPTED into unstable

[Yadd]

On 29/08/2022 17:16, Yadd wrote:

On 29/08/2022 16:46, Jonas Smedegaard wrote:

Quoting Yadd (2022-08-25 20:38:08)

could you also push node-rollup-plugin-terser ? I fixed it for terser >=
5 (partial patch revert: 2001_*) and added a "Breaks
node-rollup-plugin-terser (<< 7.0.2+~5.0.1-3~)" in node-terser.


Thanks for looking into this.  I am not happy with current state of
node-rollup-plugin-terser, however:

a) Why is patch 2001 still needed?  You kept parts of if despite terser
now being v5.  Yes, testsuite fails without that patch but I don't
understand why (suspect the cause being newer-than-expected jest).


Hi,

yes this patch should be renamed. The part I kept wasn't related to 
terser 5 but something else. This seems not be related to jest (existed 
before jest update). I'll search from where comes this error


Even with a `npm install && ./node_modules/.bin/jest test/test.js`, the 
same snapshot change is needed. Maybe this is related to node.js update?

Bug#1017132: opentracing-cpp: diff for NMU version 1.6.0-2.1

[Stephen Gelman]

On Aug 29, 2022 at 6:52:06 AM, Luca Falavigna  wrote:

> Il giorno lun 29 ago 2022 alle ore 07:34 Stephen Gelman
>  ha scritto:
>
> Would you be interested in creating a MR for your changes to salsa? If not
> that’s fine, just let me know and I will pull in the changes myself.
>
>
> Sure, here it is:
> https://salsa.debian.org/ssgelm/opentracing-cpp/-/merge_requests/1
>
> --
> Cheers,
> Luca
>

This looks awesome; I merged it. Would you like to cancel your NMU and I
can release 1.6.0-3 now, or would you prefer to wait for your NMU? I don’t
have particularly strong feelings in either direction.

Stephen

Bug#1018726: RM: anjuta -- RoM; unmaintained IDE, use gnome-builder instead

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: anj...@packages.debian.org
Affects: src:anjuta

Please remove anjuta.

Its last upstream release was 3 years ago. It has been archived which
means bug reports, translation updates, and bug fixes are no longer
being accepted. [1]

In contrast, GNOME Builder is very actively maintained and is GNOME's
recommended integrated development app.

[1] https://gitlab.gnome.org/GNOME/anjuta

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#1018725: rlottie: FTBFS on riscv64

[Eric Long]

Source: rlottie
Version: 0.1+dfsg-3
Severity: important
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: i...@hack3r.moe

Dear maintainer(s),

rlottie failed to build on riscv64 due to introduction of atomic operations in
d/patches/Atomic-render.patch, which can be fixed by linking against libatomic.

Attached is a patch that fixes FTBFS on riscv64. Please let me know if I missed
anything.

Cheers,
Eric

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

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Description: Link libatomic on riscv64
 Patch Atomic-render.patch introduces atomic operations, which requires
 libatomic to be linked on riscv64.
Author: Eric Long 
Last-Update: 2022-08-29
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -80,6 +80,10 @@
   )
 endif()
 
+if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "riscv64")
+target_link_libraries(rlottie PRIVATE -latomic)
+endif()
+
 if (LOTTIE_MODULE)
 # for dlopen, dlsym and dlclose dependancy
 target_link_libraries(rlottie PRIVATE ${CMAKE_DL_LIBS})

Bug#1004471: Fwd: [Pkg-javascript-devel] node-terser_5.15.0-1_source.changes ACCEPTED into unstable

[Yadd]

On 29/08/2022 16:46, Jonas Smedegaard wrote:

Quoting Yadd (2022-08-25 20:38:08)

could you also push node-rollup-plugin-terser ? I fixed it for terser >=
5 (partial patch revert: 2001_*) and added a "Breaks
node-rollup-plugin-terser (<< 7.0.2+~5.0.1-3~)" in node-terser.


Thanks for looking into this.  I am not happy with current state of
node-rollup-plugin-terser, however:

a) Why is patch 2001 still needed?  You kept parts of if despite terser
now being v5.  Yes, testsuite fails without that patch but I don't
understand why (suspect the cause being newer-than-expected jest).


Hi,

yes this patch should be renamed. The part I kept wasn't related to 
terser 5 but something else. This seems not be related to jest (existed 
before jest update). I'll search from where comes this error



b) Why do binary packages now contain file
/usr/share/nodejs/*/pkgjs-lock.json? Bug in pkg-js-tools, perhaps?


This files are automatically added to all package suspected to embed 
copies of some other modules (ie built using webpack or rollup). We 
discussed about that some months ago, it may help in case of CVE



c) Why do testsuite for ascjs emit several errors without failing?
Bug in pkg-js-tools, perhaps?


Here:
  + node Xascjs/test.js
  ascjs v5.0.1 - 33 tests

  true both import and export can be overwritten 



The test is launched using "set -e", so if test succeeds, it means that 
both `node Xascjs/test.js` and

`jest --ci --testTimeout 6 test/test.js` succeeds (ie returned 0)

Cheers,
Yadd

Bug#1018724: rust-jemalloc-sys FTBFS on riscv64(gc)

[Blair Noctis]

Source: rust-jemalloc-sys
Version: 0.3.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source
X-Debbugs-Cc: n...@sail.ng

rust-jemalloc-sys is currently FTBFS on riscv64 [1], reporting that riscv64gc
is not recognized.

After some tests I found that its bundled, pre-generated configure script may
be the cause. jemalloc itself successfully builds using its autogen.sh script. I
filed an issue for this upstream [2].

1: https://buildd.debian.org/status/logs.php?pkg=rust-jemalloc-sys
2: https://github.com/tikv/jemallocator/issues/36

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

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

--
Regards,
Blair Noctis



OpenPGP_0xC21D9AD423A39727.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004471: Fwd: [Pkg-javascript-devel] node-terser_5.15.0-1_source.changes ACCEPTED into unstable

[Jonas Smedegaard]

Quoting Yadd (2022-08-25 20:38:08)
> could you also push node-rollup-plugin-terser ? I fixed it for terser >= 
> 5 (partial patch revert: 2001_*) and added a "Breaks 
> node-rollup-plugin-terser (<< 7.0.2+~5.0.1-3~)" in node-terser.

Thanks for looking into this.  I am not happy with current state of
node-rollup-plugin-terser, however:

a) Why is patch 2001 still needed?  You kept parts of if despite terser
now being v5.  Yes, testsuite fails without that patch but I don't
understand why (suspect the cause being newer-than-expected jest).

b) Why do binary packages now contain file
/usr/share/nodejs/*/pkgjs-lock.json? Bug in pkg-js-tools, perhaps?

c) Why do testsuite for ascjs emit several errors without failing?
Bug in pkg-js-tools, perhaps?


Regards,

 - Jonas

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

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

signature.asc
Description: signature

Bug#1018691: reportbug: nheko fails to start. Undefined symbol

[Hubert Chathi]

On Mon, 29 Aug 2022 06:35:57 +0200, Enrique Garcia  said:

> It is not possible to launch nheko in Debian testing:

> $ nheko
> nheko: symbol lookup error: nheko: undefined symbol:
> _ZN6spdlog5sinks18rotating_file_sinkISt5mutexEC1ENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEmmb

This is a bug with spdlog:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015742

I believe it will be fixed the next time nheko gets built (either as a
binNMU or as a new upload -- which I should be doing soon to fix
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881965).

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#1018723: src:tolua: Very old Standards Version

[Tobias Frost]

Source: tolua
Version: 5.2.0-1
Severity: normal

S-V is at 3.9.3 .. from 10 years ago…

Bug#1018722: src:tolua: VCS-' fields still pointing to alioth.

[Tobias Frost]

Source: tolua
Version: 5.2.0-1
Severity: normal

Triggering obsolete-url-in-packaging lintian warnign.

I've created an repo for replacment:

https://salsa.debian.org/debian/tolua

Bug#1018721: src:tolua: Unsupported compat level 7

[Tobias Frost]

Source: tolua
Version: 5.2.0-1
Severity: normal

The package is using compat level 7, which is deprecated since quite a while.

Bug#1018720: fwupd: quesion / suggestion regarding fwupd.postinst at line 33

[Patrice Duroux]

Package: fwupd
Version: 1.8.3-1
Severity: wishlist

Dear Maintainer,

The line 33 is:
EFIDIR=$(awk '/^ID=/ {gsub(/"/,""); split($$0,a,"="); print tolower(a[2])}'
/etc/os-release)

1. I do not understand the need of '$$0' and not simply '$0'?

2. And why not doing something like the following?
EFIDIR=$(sh -c '. /etc/os-release ; echo $ID')
(no awk dep then)

Thanks,
Patrice


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

Kernel: Linux 5.18.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
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 fwupd depends on:
ii  libarchive13   3.6.0-1
ii  libc6  2.34-7
ii  libcurl3-gnutls7.84.0-2
ii  libefiboot137-6
ii  libflashrom1   1.2-5
ii  libfwupd2  1.8.3-1
ii  libfwupdplugin71.8.3-1
ii  libglib2.0-0   2.73.3-2
ii  libgnutls303.7.7-2
ii  libgudev-1.0-0 237-2
ii  libgusb2   0.3.10-1
ii  libjcat1   0.1.9-1
ii  libjson-glib-1.0-0 1.6.6-1
ii  libmbim-glib4  1.26.4-1
ii  libmbim-proxy  1.26.4-1
ii  libmm-glib01.18.10-1
ii  libpolkit-gobject-1-0  0.105-33
ii  libprotobuf-c1 1.4.1-1
ii  libqmi-glib5   1.30.8-1
ii  libqmi-proxy   1.30.8-1
ii  libsmbios-c2   2.4.3-1
ii  libsqlite3-0   3.39.2-1
ii  libsystemd0251.4-3
ii  libtss2-esys-3.0.2-0   3.2.0-1+b1
ii  libxmlb2   0.3.8-1
ii  shared-mime-info   2.2-1

Versions of packages fwupd recommends:
ii  bolt   0.9.3-1
ii  dbus   1.14.0-2
ii  fwupd-amd64-signed [fwupd-signed]  1:1.2+3
ii  python33.10.6-1
pn  secureboot-db  
ii  udisks22.9.4-2

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- no debconf information

Bug#1017535: manuskript: Manuskript does not start, python error

[Jason]

Package: manuskript
Version: 0.12.0-1
Followup-For: Bug #1017535

Dear Maintainer,

   * What led up to the situation? 
   Tried starting manuskript after not having started it for months and
   a few system upgrades of unstable.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   All I did was try to start the app and when that didn't work, then I
   updated my system again to see if the issue was corrected with an
   up to date system.

   * What was the outcome of this action?
   The same error happened again.

   * What outcome did you expect instead?
   Was hoping the issue would be resolved with an up to date unstable
   system.


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

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages manuskript depends on:
ii  libqt5svg5  5.15.4-2
ii  python3 3.10.6-1
ii  python3-enchant 3.2.2-1
ii  python3-lxml4.9.1-1+b1
ii  python3-markdown3.4.1-1
ii  python3-pyqt5   5.15.7+dfsg-1
ii  python3-pyqt5.qtwebkit  5.15.7+dfsg-1
ii  zlib1g  1:1.2.11.dfsg-4.1

Versions of packages manuskript recommends:
ii  pandoc  2.17.1.1-1

Versions of packages manuskript suggests:
pn  texlive-latex-recommended  

-- no debconf information

What happens:
$ manuskript
CRITICAL> An unhandled exception has occurred!
Traceback (most recent call last):
  File "/usr/bin/manuskript", line 30, in 
main.run()
  File "/usr/share/manuskript/manuskript/main.py", line 292, in run
app, MW = prepare(arguments)
  File "/usr/share/manuskript/manuskript/main.py", line 171, in prepare
from manuskript.mainWindow import MainWindow
  File "/usr/share/manuskript/manuskript/mainWindow.py", line 23, in 
from manuskript.models.worldModel import worldModel
  File "/usr/share/manuskript/manuskript/models/worldModel.py", line 11, in 

from manuskript.ui import style as S
  File "/usr/share/manuskript/manuskript/ui/style.py", line 36, in 
highlightLight = F.mixColors(highlight, window, .3)
  File "/usr/share/manuskript/manuskript/functions/__init__.py", line 197, in 
mixColors
return QColor(r, g, b) if not fromString else QColor(r, g, b).name()
TypeError: arguments did not match any overloaded call:
  QColor(Qt.GlobalColor): argument 1 has unexpected type 'float'
  QColor(int): argument 1 has unexpected type 'float'
  QColor(QRgba64): argument 1 has unexpected type 'float'
  QColor(Any): too many arguments
  QColor(): too many arguments
  QColor(int, int, int, alpha: int = 255): argument 1 has unexpected type 
'float'
  QColor(str): argument 1 has unexpected type 'float'
  QColor(Union[QColor, Qt.GlobalColor, QGradient]): argument 1 has unexpected 
type 'float'

Bug#1018719: gpg: incorrect message with "gpg -e --default-recipient-self"

[Vincent Lefevre]

Package: gpg
Version: 2.2.35-3
Severity: minor

When I'm encrypting a file with "gpg -e --default-recipient-self",
I get

gpg: using "..." as default secret key for signing
   ^^^

This should be "encrypting" instead of "signing".

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

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

Versions of packages gpg depends on:
ii  gpgconf2.2.35-3
ii  libassuan0 2.5.5-4
ii  libbz2-1.0 1.0.8-5
ii  libc6  2.34-6
ii  libgcrypt201.10.1-2
ii  libgpg-error0  1.45-2
ii  libreadline8   8.1.2-1.2
ii  libsqlite3-0   3.39.2-1
ii  zlib1g 1:1.2.11.dfsg-4.1

Versions of packages gpg recommends:
ii  gnupg  2.2.35-3

gpg suggests no packages.

-- no debconf information

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

Bug#995714: gnome-shell freezes with error

[Tobias Köck]

No Shell extension enabled.

as mentioned in the last reply it's mainly if I use the packages 
firefox-esr and thunderbird. Is there a way to test a new gnome-shell 
package without breaking the upgradeability to Debian 12?


Greetings
Tobias



On 10/4/21 18:43, Simon McVittie wrote:

On Mon, 04 Oct 2021 at 16:35:10 +0200, tkoeck wrote:

  16:32:01 tron-nb gnome-shell[30171]: pushModal: invocation of begin_modal 
failed
Oct  4 16:32:05 tron-nb gnome-shell[30171]: pushModal: invocation of 
begin_modal failed
Oct  4 16:32:07 tron-nb gnome-shell[30171]: pushModal: invocation of 
begin_modal failed
Oct  4 16:32:07 tron-nb gnome-shell[30171]: pushModal: invocation of 
begin_modal failed

Only a kill with hub to the gnome-shell process helps


Please could you say more about how to reproduce this problem? Is there a
particular application, or a particular UI action, or anything like that,
that triggers this?

Are you using any GNOME Shell extensions? If you are, does this still
happen after you disable the extensions?

Release team: it's possible that this is a regression in
gnome-shell_3.38.6-1~deb11u1, which is queued for inclusion in the Debian
11.1 point release. I'll try to get more information.

 smcv

Bug#995714: gnome-shell freezes with error

[Tobias Köck]

Hello,

unfortunately the same problem still occurs

tron-nb gnome-shell[4951]: pushModal: invocation of begin_modal failed

I reinstalled the system with Debian 11.

It seems to be mainly occurring when I use the Debian included 
Firefox-ESR and Thunderbird version. I installed different kernels with 
bullseye-backports but that didn't change the problems.


Greetings
Tobias

On 10/5/21 20:48, Tobias Köck wrote:
No particular Gnome-Shell Extension just the default Debian 11 
configuration.


It often seems to happen if I login and and I move with my mouse the the 
left upper corner for the Windows zoom out. Or after that with Firefox 
ESR 78 windows zoomed out with the left upper corner (or Windows key).


It seems to happen often with while using the Logitech G Mouse wireless 
but that could be just a coincidence ...


Greetings
Tobias

On 10/4/21 6:43 PM, Simon McVittie wrote:

On Mon, 04 Oct 2021 at 16:35:10 +0200, tkoeck wrote:
  16:32:01 tron-nb gnome-shell[30171]: pushModal: invocation of 
begin_modal failed
Oct  4 16:32:05 tron-nb gnome-shell[30171]: pushModal: invocation of 
begin_modal failed
Oct  4 16:32:07 tron-nb gnome-shell[30171]: pushModal: invocation of 
begin_modal failed
Oct  4 16:32:07 tron-nb gnome-shell[30171]: pushModal: invocation of 
begin_modal failed


Only a kill with hub to the gnome-shell process helps


Please could you say more about how to reproduce this problem? Is there a
particular application, or a particular UI action, or anything like that,
that triggers this?

Are you using any GNOME Shell extensions? If you are, does this still
happen after you disable the extensions?

Release team: it's possible that this is a regression in
gnome-shell_3.38.6-1~deb11u1, which is queued for inclusion in the Debian
11.1 point release. I'll try to get more information.

 smcv

Bug#950687: ITP: depthcharge-tools -- Tools to manage the Chrome OS bootloader

[Jérémy Lal]

Package: wnpp
Followup-For: Bug #950687


Hi,
now that I have three c201 chromebooks running debian/bookworm
thanks to depthcharge-tools, I might be a good candidate to sponsor that 
package.

Do you still care for it ?

Jérémy

Bug#1018718: apache2-doc: despite having been disabled, apache2-doc.conf gets rather silently re-enabled automatically

[Christoph Anton Mitterer]

Package: apache2-doc
Version: 2.4.54-1~deb11u1
Severity: important


Hey.

Unfortunately #977014 has been ignored so far, but no I just noted that even
when one explicitly disabled apache2-doc.conf via a2disconf, it still gets
rather silently re-enabled on upgrading the package, which is IMO quite
unfortunate.


Please fix at least that, or even better #977014, in which case this bug here
would become obsolete.

Thanks :-)
Chris.

Bug#935175: ITP: python-pypdf4 -- PDF manipulation library

[Martin]

Hi Emmanuel,

what is the state of affairs in respect to PyPDF4 (or PyPDF3)?
I'm not sure, which one is "better" at the moment.

Last commit PyPDF3: 2022-02-03 (of 484)
Last commit PyPDF4: 2020-06-22 (of 585)
Last release PyPDF3: 2022-02-03 (version 1.0.6)
Last release PyPDF4: 2018-08-07 (version 1.27.0)

Cheers

Bug#1018717: orage: Segmentation fault

[WhilelM]

Package: orage
Version: 4.16.0-1
Severity: grave
Justification: renders package unusable

Orage crashes at launch with segmentation fault.


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

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
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 orage depends on:
ii  libc62.34-4
ii  libcairo21.16.0-6
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libglib2.0-0 2.73.3-2
ii  libgtk-3-0   3.24.34-3
ii  libical3 3.0.9-2
ii  libnotify4   0.7.9-3
ii  libpango-1.0-0   1.50.9+ds-1
ii  libpangocairo-1.0-0  1.50.9+ds-1
ii  libx11-6 2:1.8.1-2
ii  libxfce4panel-2.0-4  4.16.2-1
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util74.16.0-1
ii  orage-data   4.16.0-1

Versions of packages orage recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-2
ii  dbus-x11 [dbus-session-bus]   1.12.20-2

Versions of packages orage suggests:
pn  sox  

-- no debconf information

Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff

[Christoph Berg]

Re: roucaries bastien
> The problem is the base64 encoded binary.

I agree that base64 there is weird, but does that really need an
explicit mention in the policy? If I were you, I'd just remove that
weirdness and move along.

Christoph

Bug#1004869: python-xarray: autopkgtest regression on i386

[Graham Inggs]

Control: reopen -1

The tests on i386 [1] are still failing in the same way.


[1] https://ci.debian.net/packages/p/python-xarray/unstable/i386/

Bug#1018714: isa-support.deb description doesn't make sense

[Christoph Berg]

Suggested wording:

Description: test for architecture features
 The isa-support package contains test programs that probe for architecture
 features like SSE3. Other packages can use these to prevent installation on
 machines that lack these features. For convenience, there are individual
 packages for each feature that other packages can pre-depend on:
 .
 sse2-support, sse3-support, sse4.2-support, altivec-support, neon-support,
 armv6-support, armv7-support, armv8-support, vfp-support, vfpv2-support,
 vfpv3-support

Christoph

Bug#1018454: py-stringmatching: build-depends on python3-nose or uses it for autopkgtest

[Julian Gilbey]

forwarded 1018454 https://github.com/anhaidgroup/py_stringmatching/issues/78
thanks

On Sun, Aug 28, 2022 at 09:44:26PM +0300, Dmitry Shachnev wrote:
> Source: py-stringmatching
> Version: 0.4.2+git20201204.6a7fb57-7
> User: python-modules-t...@lists.alioth.debian.org
> Usertags: nose-rm
> 
> Dear Maintainer,
> 
> Your package still uses nose [1], which is an obsolete testing framework for
> Python, dead and unmaintained since 2015 [2][3].
> 
> If you received this bug report, it means that your package either has a
> build-dependency on python3-nose or uses that package in debian/tests/control.

I have reported this upstream.  The last upstream commit to this
package was in January, so it may end up having to be a local Debian
patch.  (This only affects the package tests, not the rest of the
package.)

Best wishes,

   Julian

Bug#1018224: src:exempi: fails to migrate to testing for too long: FTBFS on s390x

[Michael Biebl]

Hi Paul

Am 27.08.22 um 13:49 schrieb Paul Gevers:

Source: exempi
Version: 2.6.1-2
Severity: serious
Control: close -1 2.6.2-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1014061

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:exempi has been trying to migrate for 62 
days [2]. Hence, I am filing this bug. Your package failed to build from 
source on s390x while it built the successfully in the past. Reported in 
bug 1014061.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=exempi




As you are probably aware, this issue is known and tracked in [1]. The 
package FTBFS after enabling the test suite. I raised this issue 
upstream but there is no real interest/motivation [2] on their part to 
address these (most likely endianess related) issues.

So I informed the s390x porters as well but got not feedback so far.

To me it seems it's better to not continue ship a known broken package 
on s390x and think a partial architecture removal is probably the better 
alternative.


Let me know what you think

Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014061
[2] 
https://gitlab.freedesktop.org/libopenraw/exempi/-/issues/23#note_1448295


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018642: spyder-unittest: build-depends on python3-nose or uses it for autopkgtest

[Julian Gilbey]

forwarded 1018642 https://github.com/spyder-ide/spyder-unittest/issues/178
thanks

On Sun, Aug 28, 2022 at 09:55:09PM +0300, Dmitry Shachnev wrote:
> Source: spyder-unittest
> Version: 0.5.0-3
> User: python-modules-t...@lists.alioth.debian.org
> Usertags: nose-rm
> 
> Dear Maintainer,
> 
> Your package still uses nose [1], which is an obsolete testing framework for
> Python, dead and unmaintained since 2015 [2][3].
> 
> If you received this bug report, it means that your package either has a
> build-dependency on python3-nose or uses that package in debian/tests/control.
> If that is not the case, please reply and CC me explicitly.
> 
> Please port your package to one of the alternatives: nose2 [4], pytest [5]
> or unittest from Python standard library [6].

This is a plugin for Spyder to support running package tests in other
packages.  It currently supports tests written in pytest or nose, and
the current package requires nose only in its tests.

There seems to be agreement upstream about stopping its nose support
in the next major version (see the request for this from June 2022 at
https://github.com/spyder-ide/spyder-unittest/issues/178), but there
is no indication of when this might happen.

Best wishes,

   Julian

Bug#1018714: isa-support.deb description doesn't make sense

[Christoph Berg]

Package: isa-support
Version: 11
Severity: normal

Hi,

I was just wondering what the isa-support package is doing since it
just got installed here (pulled in by chromium).

The description says:

Description-en: prevent installation on processors without required features
 This is a mostly dummy package, whose only purpose is to detect the presence
 of architecture features.

I can see what the sse3-support package is supposed to be doing, but
what does "isa" support test?

Also, I'd say a package is either a dummy package, or it does
something sensible, so I don't think the description "dummy with a
purpose" makes sense.


Poking around a bit I realized that isa-support is just pulled in
because sse3-support creates this symlink:

/usr/share/doc/sse3-support -> isa-support/

Please update the package description to really say what it is doing,
instead of trying to hide behind a wall of hand-waving.

Christoph

Bug#1013939: python-xarray: autopkgtest regression: Left and right DataArray objects are not close

[Graham Inggs]

Hi Alastair

On Sat, 13 Aug 2022 at 21:39, Paul Gevers  wrote:
> But the log [1] that was generated by the migration trial run has the
> output below and the runs in unstable fail too (so no missing
> *versioned* items).

Please drop the unnecessary versioned build-dependency on
python3-scipy to allow python-xarray to migrate to testing.

In other words:

-   python3-scipy (>= 1.8.1-8)  ,
+   python3-scipy  ,

I would point to the commit to revert on salsa, but it seems recent
changes haven't been pushed.

Regards
Graham

Bug#1018700: After migrating from thunderbird:amd64 da 1:91.10.0-1 -> 1:102.1.2-1 can't see any folder

[Giorgio Volpe]

tks a lot for your quick response!

My answers below

Il giorno lun 29 ago 2022 alle ore 12:56 Carsten Schoenert <
c.schoen...@t-online.de> ha scritto:

> Please use "Reply all" so the BTS (and by this others) gets your
> information too!
>
> Am 29.08.22 um 12:10 schrieb Giorgio Volpe:
> > Tried to restart in safe-mode but the result is the same!
>
> You haven't written anything about your setup, it's quite impossible to
> get an idea what could might go wrong and were to look at.
>
> The tool repoprtbug would help to collect some more and basic
> information about your system in case you will write other bug reports
> in the future.
>
> What DE you are using? Or you use just a tiling manager?
>

I use xfce. It's a LTSP setup ... sorry but i've not installed reportbug on
the clients! I have to do it.



> Which package archive resources you use? Any external non Debian sources?
>

I've installed the standard debian package for thunderbird via aptitude.
I've external source for chrome and for LTSP.



> What filesystem the home directory is using? Is the profile folder
> linked somewhere or is using some network path? How old is your current
> Thunderbird profile?
>


The problem is there also with a newly created profile. The problem is not
related to file position, i think. So it could be a program BUG and not a
debian one.



> How do you have setup a complete new user profile? Do have create also a
> complete new test user with a new home folder?
>

no. Only deleted old .thuderbird directory and restarted TB.
As soon as i can I'll try!



> Have you tried out an upstream TB binary? In both ways, within your home
> and within a complete fresh new home?
>
>

What do you mean with "upstream TB binary"?



> What if you try a live system and create a fresh new profile?
> Is your current system a quite newly installed system or do you have an
> (dist-)updated system?
>

I've a dist-update system! ... production system used in our association by
12 persone on 6 fat-client.
Giorgio



>
> --
> Regards
> Carsten
>

Bug#1009772: armci-mpi: autopkgtest regression on s390x

[Graham Inggs]

Control: tags -1 + patch

Hi Drew

Upon further investigation, it appears that the failing
test-armci-mpich has never passed on s390x, so the failure of this
particular test is not a regression.  In fact, the build-time tests
fail in the same way, although those failures are ignored.

Please consider skipping test-armci-mpich on s390x, as per the patch
below, so at least regressions in test-armci and test-armci-openmpi
can be caught.

Regards
Graham


--- a/debian/tests/control
+++ b/debian/tests/control
@@ -15,3 +15,4 @@
  debhelper, dh-autoreconf,
  gcc
 Restrictions: allow-stderr
+Architecture: !s390x

Bug#1018697: deb-scrub-obsolete: please document the RELEASE names

[Jelmer Vernooij]

tags 1018697 +confirmed
thanks

Hi Martin,

Thanks for the bug report.

On Mon, Aug 29, 2022 at 09:40:58AM +0200, Martin Quinson wrote:
> I am always reluctant to apply the merge requests of deb-scrub-obsolete,
> because I'm not sure of which release I cut off while applying these changes.
> It would be really helpful if the script could augment the changelog to add 
> the
> release name since which the removed versionning is useless, please.

There is a release name in the changelog entry at the moment. Do you
have a proposed format/wording for the changelog?

> Along the same line, it could be helpful to document in the deb-scrub-obsolete
> manpage the list of accepted releases. In particular, I'm wondering whether I
> have to use a codename such as bookworm, or whether an alias such as old-old-
> stable is acceptable.
Both should work, but I've just added a note in the manpage. Thanks!

I'll leave the bug report open for the first issue.

Cheers,

Jelmer

Bug#1017132: opentracing-cpp: diff for NMU version 1.6.0-2.1

[Luca Falavigna]

Il giorno lun 29 ago 2022 alle ore 07:34 Stephen Gelman
 ha scritto:
> Would you be interested in creating a MR for your changes to salsa? If not 
> that’s fine, just let me know and I will pull in the changes myself.

Sure, here it is:
https://salsa.debian.org/ssgelm/opentracing-cpp/-/merge_requests/1

-- 
Cheers,
Luca

Bug#1018259: nmu: libidn2_2.3.3-1

[Johannes Schauer Marin Rodrigues]

Quoting Simon Josefsson (2022-08-29 08:09:59)
> I could upload a real version too, maybe that is faster? Can do today unless 
> someone objects.

libidn2 has already been binNMUed by Sebastian Ramacher -- see the other mail
to this bug.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1018713: mailfilter: Filtering at pop.gmail.com doesn't work

[Elimar Riesebieter]

Package: mailfilter
Version: 0.8.8-1
Severity: grave
Justification: renders package unusable


I enabled pop on Port 995 at gmail. 2FA password is generated and works well 
fetching mails with getmail6. Running mailfilter -r -M mailfilterrc gives

Aug 16 14:18:52 mailfilter: 0.8.8 querying m...@gmail.com@pop.gmail.com.
Aug 16 14:18:53 mailfilter: Error: SSL connection could not be established: 
self-signed certificate
Aug 16 14:18:53 mailfilter: Error: SSL connection could not be established.
Aug 16 14:18:53 mailfilter: Error: Could not establish network connection.

mailfilterrc:

SERVER="pop.gmail.com"
USER="m...@gmail.com"
PASS="blafasel"
PROTOCOL="pop3/ssl"
PORT=995



-- System Information:
Debian Release: bookworm/sid
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.59-baumbart-lxtec-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages mailfilter depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  libc6  2.34-7
ii  libgcc-s1  12.2.0-1
ii  libssl33.0.5-2
ii  libstdc++6 12.2.0-1

mailfilter recommends no packages.

mailfilter suggests no packages.

-- debconf information excluded

Bug#1018712: sddm: Various (harmless?) messages during startup

[Helge Kreutzmann]

Package: sddm
Version: 0.19.0-3
Severity: minor

Hello,
after switching to testing (from stable) some time ago, I see various
messages in the system logs from sddm. 

If these are indeed harmless, then please add an apprpriate logcheck
rule for them.

If not, please ask me if you need any further information for fixing
them.

Thanks

Aug 29 08:37:17 twentytwo sddm-greeter[2042]: QFont::fromString: Invalid 
description '(empty)'
Aug 29 08:37:17 twentytwo sddm-greeter[2042]: QObject::installEventFilter(): 
Cannot filter events for objects in a different thread.
Aug 29 08:37:20 twentytwo sddm-greeter[2042]: Failed to find a Kirigami 
platform plugin
Aug 29 08:37:20 twentytwo sddm-greeter[2042]: 
file:///usr/share/sddm/themes/debian-theme/components/VirtualKeyboard.qml:12:1: 
Type InputPanel unavailable
Aug 29 08:37:20 twentytwo sddm-greeter[2042]: 
qrc:/QtQuick/VirtualKeyboard/content/InputPanel.qml:127:5: Type Keyboard 
unavailable
Aug 29 08:37:20 twentytwo sddm-greeter[2042]: 
qrc:/QtQuick/VirtualKeyboard/content/components/Keyboard.qml:38:1: module 
"QtQuick.VirtualKeyboard.Plugins" is not installed
Aug 29 08:37:20 twentytwo sddm-greeter[2042]: Qt Quick Layouts: Polish loop 
detected. Aborting after two iterations.
Aug 29 08:37:20 twentytwo sddm-greeter[2042]: QDBusConnection: name 
'org.freedesktop.UDisks2' had owner '' but we thought it was ':1.2'
Aug 29 08:37:23 twentytwo sddm-helper: pam_kwallet5(sddm:auth): pam_kwallet5: 
pam_sm_authenticate
Aug 29 08:37:24 twentytwo sddm-helper: pam_env(sddm:session): deprecated 
reading of user environment enabled


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

Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sddm depends on:
ii  adduser 3.128
ii  debconf [debconf-2.0]   1.5.79
ii  libc6   2.34-4
ii  libgcc-s1   12.2.0-1
ii  libpam0g1.5.2-2
ii  libqt5core5a5.15.4+dfsg-5
ii  libqt5dbus5 5.15.4+dfsg-5
ii  libqt5gui5  5.15.4+dfsg-5
ii  libqt5network5  5.15.4+dfsg-5
ii  libqt5qml5  5.15.4+dfsg-4
ii  libqt5quick55.15.4+dfsg-4
ii  libstdc++6  12.2.0-1
ii  libsystemd0 251.3-1
ii  libxcb-xkb1 1.15-1
ii  libxcb1 1.15-1
ii  qml-module-qtquick2 5.15.4+dfsg-4
ii  x11-common  1:7.7+23
ii  xauth   1:1.1.1-1
ii  xserver-xorg [xserver]  1:7.7+23

Versions of packages sddm recommends:
ii  haveged 1.9.14-1
ii  libpam-systemd  251.3-1
ii  sddm-theme-breeze [sddm-theme]  4:5.25.4-3

Versions of packages sddm suggests:
ii  libpam-kwallet5   5.25.4-1
pn  qtvirtualkeyboard-plugin  

-- debconf information:
  sddm/daemon_name: /usr/bin/sddm
* shared/default-x-display-manager: sddm

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


signature.asc
Description: PGP signature

Bug#1018711: qt.qpa.xcb: QXcbConnection: XCB error

[Helge Kreutzmann]

Package: plasma-workspace
Version: 4:5.25.4-3
Severity: minor

During operiation I see a lot of messages of the form twentytwo
plasmashell[718075]: qt.qpa.xcb: QXcbConnection: XCB error: 9 (BadDrawable), 
sequence: 10513, resource id: 27263103, major code: 55 (CreateGC), minor code: 0

I reviewed the logs and I can filter them out with the following
pattern:
twentytwo plasmashell\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 152 
\(Unknown\), sequence: .*, resource id: 27263209, major code: 143 \(Unknown\), 
minor code: 2
twentytwo plasmashell\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 2 
\(BadValue\), sequence: .*, resource id: 0, major code: 53 \(CreatePixmap\), 
minor code: 0
twentytwo plasmashell\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 3 
\(BadWindow\), sequence: .*, resource id: 4194310, major code: 142 \(Unknown\), 
minor code: 3
twentytwo plasmashell\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 3 
\(BadWindow\), sequence: .*, resource id: 48234516, major code: 40 
\(TranslateCoords\), minor code: 0
twentytwo plasmashell\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 9 
\(BadDrawable\), sequence: .*, resource id: 272630.*, major code: 55 
\(CreateGC\), minor code: 0
twentytwo plasmashell\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 9 
\(BadDrawable\), sequence: .*, resource id: 272630.*, major code: 72 
\(PutImage\), minor code: 0
twentytwo plasmashell\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 9 
\(BadDrawable\), sequence: .*, resource id: 272631.*, major code: 55 
\(CreateGC\), minor code: 0
twentytwo plasmashell\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 9 
\(BadDrawable\), sequence: .*, resource id: 272631.*, major code: 72 
\(PutImage), minor code: 0

If these messages are harmless, please provide a logcheck pattern, 
e.g. with the above lines.

If you need further information from my side for tracking these down,
please let me know.


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

Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages plasma-workspace depends on:
ii  dbus-user-session [default-dbus-session-bus]1.14.0-2
ii  dbus-x11 [dbus-session-bus] 1.14.0-2
ii  drkonqi 5.25.4-1
ii  frameworkintegration5.97.0-1
ii  gdb-minimal [gdb]   12.1-3
ii  init-system-helpers 1.64
ii  iso-codes   4.11.0-1
ii  kactivitymanagerd   5.25.4-1
ii  kded5   5.97.0-1
ii  kinit   5.97.0-1
ii  kio 5.97.0-1
ii  kpackagetool5   5.97.0-1
ii  kwin-common 4:5.25.4-2
ii  libappstreamqt2 0.15.5-1
ii  libc6   2.34-4
ii  libcolorcorrect54:5.25.4-3
ii  libcrypt1   1:4.4.28-2
ii  libegl1 1.5.0-1
ii  libfontconfig1  2.13.1-4.4
ii  libfreetype62.12.1+dfsg-3
ii  libgcc-s1   12.2.0-1
ii  libgl1  1.5.0-1
ii  libgps283.22-4
ii  libice6 2:1.0.10-1
ii  libicu7171.1-3
ii  libkf5activities5   5.97.0-1
ii  libkf5activitiesstats1  5.97.0-1
ii  libkf5archive5  5.97.0-1
ii  libkf5authcore5 5.97.0-1
ii  libkf5baloo55.97.0-1
ii  libkf5bookmarks55.97.0-1
ii  libkf5calendarevents5   5.97.0-1
ii  libkf5completion5   5.97.0-1
ii  libkf5config-bin5.97.0-2
ii  libkf5configcore5   5.97.0-2
ii  libkf5configgui55.97.0-2
ii  libkf5configwidgets55.97.0-1
ii  libkf5coreaddons5   5.97.0-1
ii  libkf5crash55.97.0-1
ii  libkf5dbusaddons5   5.97.0-1
ii  libkf5declarative5  5.97.0-1
ii  

Bug#1018710: qt.qpa.xcb: QXcbConnection: XCB error

[Helge Kreutzmann]

Package: kwin-x11
Version: 4:5.25.4-2
Severity: minor

During operiation I see a lot of messages of the form twentytwo
twentytwo kwin_x11[3064]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), 
sequence: 790, resource id: 41943045, major code: 18 (ChangeProperty), minor 
code: 0

I reviewed the logs and I can filter them out with the following
pattern:
twentytwo kwin_x11\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 2 
\(BadValue\), sequence: .*, resource id: 0, major code: 53 \(CreatePixmap\), 
minor code: 0
twentytwo kwin_x11\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 3 
\(BadWindow\), sequence: .*, resource id: \.*, major code: 10 \(UnmapWindow\), 
minor code: 0
twentytwo kwin_x11\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 3 
\(BadWindow\), sequence: .*, resource id: \.*, major code: 15 \(QueryTree\), 
minor code: 0
twentytwo kwin_x11\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 3 
\(BadWindow\), sequence: .*, resource id: \.*, major code: 18 
\(ChangeProperty\), minor code: 0
twentytwo kwin_x11\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 3 
\(BadWindow\), sequence: .*, resource id: \.*, major code: 19 
\(DeleteProperty\), minor code: 0
twentytwo kwin_x11\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 3 
\(BadWindow\), sequence: .*, resource id: \.*, major code: 20 \(GetProperty\), 
minor code: 0
twentytwo kwin_x11\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 3 
\(BadWindow\), sequence: .*, resource id: \.*, major code: 2 
\(ChangeWindowAttributes\), minor code: 0
twentytwo kwin_x11\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 3 
\(BadWindow\), sequence: .*, resource id: \.*, major code: 3 
\(GetWindowAttributes\), minor code: 0
twentytwo kwin_x11\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 3 
\(BadWindow\), sequence: .*, resource id: \.*, major code: 6 \(ChangeSaveSet\), 
minor code: 0
twentytwo kwin_x11\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 3 
\(BadWindow\), sequence: .*, resource id: \.*, major code: 7 
\(ReparentWindow\), minor code: 0
twentytwo kwin_x11\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 9 
\(BadDrawable\), sequence: .*, resource id: \.*, major code: 14 
\(GetGeometry\), minor code: 0
twentytwo kwin_x11\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 9 
\(BadDrawable\), sequence: .*, resource id: \.*, major code: 55 \(CreateGC\), 
minor code: 0
twentytwo kwin_x11\[\.*\]: qt.qpa.xcb: QXcbConnection: XCB error: 9 
\(BadDrawable\), sequence: .*, resource id: \.*, major code: 72 \(PutImage), 
minor code: 0

If these messages are harmless, please provide a logcheck pattern,
e.g. with the above lines.

If you need further information from my side for tracking these down,
please let me know.

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

Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kwin-x11 depends on:
ii  kwin-common4:5.25.4-2
ii  libc6  2.34-4
ii  libepoxy0  1.5.10-1
ii  libgcc-s1  12.2.0-1
ii  libkdecorations2-5v5   4:5.25.4-1
ii  libkf5configcore5  5.97.0-2
ii  libkf5configgui5   5.97.0-2
ii  libkf5configwidgets5   5.97.0-1
ii  libkf5coreaddons5  5.97.0-1
ii  libkf5crash5   5.97.0-1
ii  libkf5globalaccel-bin  5.97.0-1
ii  libkf5globalaccel5 5.97.0-1
ii  libkf5i18n55.97.0-1
ii  libkf5notifications5   5.97.0-1
ii  libkf5plasma5  5.97.0-1
ii  libkf5service-bin  5.97.0-1
ii  libkf5service5 5.97.0-1
ii  libkf5windowsystem55.97.0-1
ii  libkwineffects13   4:5.25.4-2
ii  libkwinglutils13   4:5.25.4-2
ii  libkwinxrenderutils13  4:5.25.4-2
ii  libqaccessibilityclient-qt5-0  0.4.1-1+b1
ii  libqt5core5a   5.15.4+dfsg-5
ii  libqt5dbus55.15.4+dfsg-5
ii  libqt5gui5 5.15.4+dfsg-5
ii  libqt5qml5 5.15.4+dfsg-4
ii  libqt5widgets5 5.15.4+dfsg-5
ii  libqt5x11extras5   5.15.4-2
ii  libstdc++6 12.2.0-1
ii  libx11-6   2:1.8.1-2
ii  libxcb-composite0  1.15-1
ii  libxcb-keysyms10.4.0-1+b2
ii  libxcb-randr0  1.15-1
ii  libxcb-render0 1.15-1
ii  libxcb-shape0  1.15-1
ii  libxcb-xfixes0 1.15-1
ii  libxcb11.15-1
ii  libxi6 2:1.8-1

kwin-x11 recommends no packages.

kwin-x11 suggests no packages.

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.

Bug#1018700: After migrating from thunderbird:amd64 da 1:91.10.0-1 -> 1:102.1.2-1 can't see any folder

[Carsten Schoenert]

Please use "Reply all" so the BTS (and by this others) gets your 
information too!


Am 29.08.22 um 12:10 schrieb Giorgio Volpe:

Tried to restart in safe-mode but the result is the same!


You haven't written anything about your setup, it's quite impossible to 
get an idea what could might go wrong and were to look at.


The tool repoprtbug would help to collect some more and basic 
information about your system in case you will write other bug reports 
in the future.


What DE you are using? Or you use just a tiling manager?
Which package archive resources you use? Any external non Debian sources?
What filesystem the home directory is using? Is the profile folder 
linked somewhere or is using some network path? How old is your current 
Thunderbird profile?
How do you have setup a complete new user profile? Do have create also a 
complete new test user with a new home folder?
Have you tried out an upstream TB binary? In both ways, within your home 
and within a complete fresh new home?


What if you try a live system and create a fresh new profile?
Is your current system a quite newly installed system or do you have an 
(dist-)updated system?


--
Regards
Carsten

Bug#1018709: libsoup3: FTBFS on riscv64 (test timeout)

[Eric Long]

Source: libsoup3
Version: 3.1.3-2
Severity: important
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: i...@hack3r.moe

Dear maintainer(s),

libsoup3 failed to build on riscv64 due to timeout on test 
http2-body-stream-test.
More info can be found on buildd log: 
https://buildd.debian.org/status/fetch.php?pkg=libsoup3=riscv64=3.1.3-2=1661159409=0

(The test multithread-test also failed, but I believe it's accidental (address
already in use))

Attached is a patch that extends http2-body-stream-test's timeout. I also
noticed the TODO in d/rules to reduce the test timeout multiplier. Maybe revert
that commit (9f9572ba) after the patch is applied?

Please let me know if I missed anything.

Cheers,
Eric

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

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/tests/meson.build b/tests/meson.build
index 9bf88bec..50ea66bd 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -79,7 +79,8 @@ tests = [
   {'name': 'forms'},
   {'name': 'header-parsing'},
   {'name': 'http2'},
-  {'name': 'http2-body-stream'},
+  {'name': 'http2-body-stream',
+   'timeout': 1000},
   {'name': 'hsts'},
   {'name': 'hsts-db'},
   {'name': 'logger'},
@@ -212,7 +213,7 @@ foreach test: tests
 env : env,
 is_parallel : test.get('parallel', true),
 depends : test.get('depends', []),
-timeout : 60,
+timeout : test.get('timeout', 60),
 protocol : 'tap',
   )
 endforeach

Bug#1017034: ITP: golang-github-marten-seemann-qtls-go1-19 -- Go standard library TLS 1.30 implementation, modified for QUIC (Go-1.19)

[Nilesh Patra]

Hi William,

On Thu, 11 Aug 2022 16:45:23 -0500 William Wilson 
 wrote:
> > * Package name: golang-github-marten-seemann-qtls-go1-19
> >   Version : 0.1.0
> >   Upstream Author : Marten Seemann
> > * URL : https://github.com/marten-seemann/qtls-go1-19
> > * License : BSD-3
> >   Programming Lang: Go
> >   Description : Go standard library TLS 1.30 implementation, modified
> I have packaged this and uploaded it to a PPA:
> https://launchpad.net/~jawn-smith/+archive/ubuntu/devel-proposed/+sourcefiles/golang-github-marten-seemann-qtls-go1-19/0.1.0-1~ppa1/golang-github-marten-seemann-qtls-go1-19_0.1.0-1~ppa1.dsc
> 
> If someone could sponsor this I'd be very appreciative!

I am sorry to step on your toes, and ended up uploading a new package without 
seeing your existing work, but
I believe this was done by you to get the go transition going to testing.

Would it be OK if I add you in to Uploaders for this package? (Repository on 
salsa)

PS: I also sent a question to the debian go ML pertaining to this package.


-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1018700: After migrating from thunderbird:amd64 da 1:91.10.0-1 -> 1:102.1.2-1 can't see any folder

[Carsten Schoenert]

Hello Giorgo,

Am 29.08.22 um 11:05 schrieb Giorgio Volpe:

Package:thunderbird
Version:1:102.1.2-1

On my Debian bookworm/sid server, After migrating from Thunderbird:amd64 
da 1:91.10.0-1 -> 1:102.1.2-1 I can't see any folder. I can till send 
mail and the configuration is ok.


I've tried everything! Also configure a new user from scratch ... same 
result. It seems a problem of visualization that comes out when I add a 
local account to access IMAP mailbox on local server (no problem with 
gmail account).


do you have reflect these hints?

https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues

In the past it has turned out that quite almost such issues are related 
by $some one or more external Add-ons.


--
Regards
Carsten